Category Archives: Uncategorized

Use ML and AI to automate IT operations

Use ML and AI to automate IT operations

Gartner is the world’s leading research and advisory company for IT. They pretty much invented the space. Gartner often invents new models — one of them is AIOps. The idea is to use machine learning to drive IT operations.

  • Performance management (“Observe”)
  • Automation (“Act”)

What’s AIOps?

Besides combining AI with a short catchy word like Ops (which sounds like Black Ops, IT Ops, Clinical Ops) — AIOps is the evolution of IT operational analytics (ITOA). It evolved out of the extreme growth in cloud computing.

  • The amount of data that we need to retain is exponentially increasing. Performance monitoring is generating exponentially larger numbers of events and alerts. Service ticket volumes experience step-function increases with the introduction of IoT devices, APIs, mobile applications, and digital or machine users. Again, it is simply becoming too complex for manual reporting and analysis.
  • Infrastructure problems must be addressed at ever-increasing speeds. As organizations digitize their business, IT becomes the business. The “consumerization” of technology has changed user expectations for all industries. Reactions to IT events — whether real or perceived — need to occur immediately, particularly when an issue impacts user experience.
  • More computing power is moving to the edges of the network. The ease with which cloud infrastructure and third-party services can be adopted has empowered line of business (LOB) functions to build their own IT solutions and applications. Control and budget have shifted from the core of IT to the edge. And more computing power (that can be leveraged) is being added from outside core IT.
  • Developers have more power and influence but accountability still sits with core IT. As I talk about in my post on application-centric infrastructure, DevOps and Agile are forcing programmers to take on more monitoring responsibility at the application level, but accountability for the overall health of the IT ecosystem and the interaction between applications, services, and infrastructure still remains the province of core IT. ITOps is taking on more responsibility just as their networks are getting more complex.

Automation does not replace humans

It should be noted that an acknowledgement that cloud computing is exceeding human scale does not mean that the machines are replacing humans. It means we need automation to deal with the new reality. Humans aren’t replaced, but operations people will need to develop new skills. New roles will emerge.

The elements of AI-driven operations

I’m going to take a moment here to go through the elements of AIOps as represented in the Gartner diagram above.

  • Aggregated big data platform. At the heart of the platform, the center of the above graphic, is big data. As the data is liberated from siloed tools, it needs to be brought together to support next-level analytics. This needs to occur not just offline — as in a forensic investigation using historical data — but also in real-time as data is ingested. See my other post for more on AIOps and big data.
  • Machine learning. Big data enables the application of ML to analyze vast quantities of diverse data. This is not possible prior to bringing the data together nor by manual human effort. ML automates existing, manual analytics and enables new analytics on new data — all at a scale and speed unavailable without AIOps.
  • Observe. This is the evolution of the traditional ITOM domain that integrates development (traces) and other non-ITOM data (topology, business metrics) to enable new modalities of correlation and contextualization. In combination with real-time processing, probable-cause identification becomes simultaneous with issue generation.
  • Engage. The evolution of the traditional ITSM domain includes bi-directional communication with ITOM data to support the above analyses and auto-create documentation for audit and compliance/regulatory requirements. AI/ML expresses itself here in cognitive classification plus routing and intelligence at the user touchpoint, e.g., chatbots.
  • Act. This is the “final mile” of the AIOps value chain. Automating analysis, workflow, and documentation is for naught if responsibility for action is put back in human hands. Act encompasses the codification of human domain knowledge into the automation and orchestration of remediation and response.

The future of AI-driven operations

As IT moves beyond human scale, we need to automate even more. But simply reacting defensively is not enough.

  • The automation of technology, and, hence, business processes: Costs lower, speed increases, and errors decrease while freeing up human capital for higher-level achievement.
  • Enterprise ITOps gains DevOps agility: Continuous delivery extends to operations and the business.
  • Data becomes currency: The vast wealth of untapped business data is capitalized, unleashing high-value use cases and monetization opportunities.

 

Originally published on Medium.

Tell your friends and colleagues about us. Thanks!
Share this

Auditing healthcare IT security and privacy with multiple threat scenarios

Is there a way to break out of the security checklist mentality?

IT security auditors commonly use  standard/fixed checklists, often based on the compliance regulation being audited: the HIPAA Security Rule or  ISO 27001 for example;

In this article we suggest considering an alternative approach based on generating and analyzing multiple threat scenarios for the particular organization/business situation being audited.

Large organizations may reap significant benefits from this approach since they tend have many unconnected stovepipes of compliance and data governance.  Multiple threat scenarios enable security analysts to side-step large scale self-assessment checklists and problematic integration of data across stovepipes and focus on key assets, attacks and common vulnerabilities in key business processes.

Small to mid-size hospitals, nursing homes, medical device vendors, and healthcare applications software development teams have by definition much simpler  audit requirements.

A small business or development team is primarily interested in how cheaply the audit can be done and how much money they can save by getting it right.  For a small business unit – using the technique of multiple threat analysis will help show the best and most cost-effective way to progress from audit to HIPAA compliance and more secure systems.

With the HIPAA Final Rule,  HIPAA  compliance and securing patient data is now central to your business and almost every business in the healthcare supply chain.

You can do some research online and then hire a HIPAA security and compliance consultant who will walk you through the security safeguards in CFR 45 Appendix A and help you implement as many items as possible.  This seems like a reasonable approach, but the more safeguards you implement, the more money you spend and moreover, you do not necessarily know if your security has improved –since you have not examined your value at risk – i.e how much money it will cost you if you have a data security breach.

If you read CFR 45 Appendix A carefully, you will note that the standard wants you to do a top-down risk analysis, risk management and periodic information security activity review.

The best way to do that top down risk analysis is to build probable threat scenarios – considering what could go wrong – employees stealing a hard disk from a nursing station in an ICU where a celebrity is recuperating for the information or a hacker sniffing the hospital wired LAN for PHI.

Threat scenarios as an alternative to compliance control policies

When we perform a software security assessment of a medical device or healthcare system, we think in terms of “threat scenarios” or “attack scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance. The threat scenarios are not “one size fits all”.  The threat scenarios for an AIDS testing lab using medical devices that automatically scan and analyze blood samples, or an Army hospital using a networked brain scanning device to diagnose soldiers with head injuries, or an implanted cardiac device with mobile connectivity are all totally different.

We evaluate the medical device or healthcare product from an attacker point of view, then from the management team point of view, and then recommend specific cost-effective, security countermeasures to mitigate the damage from the most likely attacks.

In our experience, building a security portfolio on attack scenarios has 3 clear benefits;
  1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
  2. Executives related well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.
  3. Threat scenarios are a common language between IT, security operations teams and the business line managers

This last benefit is extremely important in your healthcare organization, since business delegates security to IT and IT delegates security to the security operations teams.

As I wrote in a previous essay “The valley of death between IT and security“, there is a fundamental disconnect between IT operations (built on maintaining predictable business processes) and security operations (built on mitigating vulnerabilities).

Business executives delegate information systems to IT and information security to security people on the tacit assumption that they are the experts in information systems and security.  This is a necessary but not sufficient condition.

In the current environment of rapidly evolving types of attacks (hacktivisim, nation-state attacks, credit card attacks mounted by organized crime, script kiddies, competitors and malicious insiders and more…), it is essential that IT and security communicate effectively regarding the types of attacks that their organization may face and what is the potential business impact.

If you have any doubt about the importance of IT and security talking to each other, consider that leading up to 9/11, the CIA  had intelligence on Al Qaeda terrorists and the FBI investigated people taking flying lessons, but no one asked the question why Arabs were learning to fly planes but not land them.

With this fundamental disconnect between 2 key maintainers of information protection, it is no wonder that organizations are having difficulty effectively protecting their assets – whether Web site availability for an online business, PHI for a healthcare organization or intellectual property for an advanced technology firm.

IT and security  need a common language to execute their mission, and I submit that building the security portfolio around most likely threat scenarios from an attacker perspective is the best way to cross that valley of death.

There seems to be a tacit assumption with many executives that regulatory compliance is already a common language of security for an organization.  Compliance is a good thing as it drives organizations to take action on vulnerabilities but compliance checklists like PCI DSS 2.0, the HIPAA security rule, NIST 800 etc, are a dangerous replacement for thinking through the most likely threats to your business.  I have written about insecurity by compliance here and here.

Let me illustrate why compliance control policies are not the common language we need by taking an example from another compliance area – credit cards.

PCI DSS 2.0 has an obsessive preoccupation with anti-virus.  It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control policy that is not rooted in a probable threat scenario that creates additional vulnerabilities for the business.

Now, consider some deeper ramifications of compliance control policy-based security.

When a  QSA or HIPAA auditor records an encounter with a customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the  compliance posture of the business  needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.

Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities.

This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

  • Lack of overview of the the security threats and vulnerabilities that really count
  • No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed
  • No connection between controls and security events, except circumstantial
  • No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise  firewalled services).
  • No archiving or demoting of less important and solved threat scenarios (since the data models are control based)
  • Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed.  Is Bank of America getting better at data security or worse?
  • An excess of event data that cannot possibly be read by the security and risk analyst at every encounter
  • Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.

Using value at risk to figure out how much a breach will really cost you

Your threat scenarios must consider asset (your patient information, systems, management attention, reputation) values, vulnerabilities, threats and possible security countermeasures. Threat analysis as a methodology does not look for ROI or ROSI (there is no ROI for security anyhow) but considers the best and cheapest way to reduce asset value at risk.

And – as we opened the article – the question is  “How can I do this for as little money as possible?”

Tell your friends and colleagues about us. Thanks!
Share this

Cloud security assessment

A customer case study – cloud security assessment

Faced with a steep bill for securing a new cloud application, a client asked us to help find a way to reduce their risk exposure at the lowest possible cost. By using the Business Threat Modeling methodology and PTA (Practical Threat Analysis) software, we were able to build a risk mitigation plan that mitigated 80% of the total risk exposure in dollars at half the original security budget proposed by the vendor.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this