Strategic Cybersecurity | Making Intelligent Cybersecurity Investment Decisions

Studies show that in the face of cyber-crime costing the global economy ~$450 billion per year, organizations are investing in cyber security safeguards on an unprecedented scale. A 2017 Accenture / Ponemon study indicated that current spending priorities are often misdirected toward security capabilities that fail to deliver the greatest efficiency and effectiveness. The quality of cyber security decision making can be improved dramatically with some basic initial focus on a true risk-based approach.

This was the subject of my webinar today with members of the College of Healthcare Information Executives (CHIME).

Listen to the recorded session below to learn what Boards and Executive Teams are demanding from their privacy, security, compliance, risk management and procurement teams to improve their return on security investments (ROSI).

Read More

Panaceas, Shiny Objects and the Importance of Managing Risk in a Healthcare Environment – Part 3

Is there a more challenging position anywhere in information security than that of a healthcare organization’s cyber risk management leader? If there is, I can’t think of what it would be. Whether your title is CISO, CSO, CTO, CIO or some variation thereof, the task is daunting.

As we mentioned in Part 1 of this series, healthcare as an industry has a huge target on its back. Cyber attackers focus on healthcare not only because patient information is valuable, but also because patient lives are at stake. That can make threats such as ransomware attacks more effective. Cyber attacks in other industries – banking, for example – can have devastating financial consequences, but people’s lives aren’t generally at risk, as they are in healthcare.

At the same time, healthcare IT environments are exceedingly complex, which makes managing information security that much more complicated. The healthcare IT ecosystem typically includes dozens – if not hundreds – of applications, including the electronic health record (EHR) system, administrative and operational applications (scheduling, patient tracking, billing, claims, insurance and payer systems and interfaces), clinical applications (patient monitoring systems, radiology information systems, lab results reporting, clinical decision support, patient portals, etc.) and others too numerous to mention.

On top of this, add the countless devices that connect to a healthcare organization’s network, from the desktop computer at the registration desk, to the tablet the physician or nurse uses, to the smart infusion pump at the patient’s bedside, to BYOD devices like the smartphone a patient uses to access lab results through a patient portal.

Enterprise-wide Cyber Risk Assessment

Because of this complexity, no single “shiny object” or new security tool will be sufficient to mitigate all of the critical information security risks in a healthcare environment. As we discussed in Part 2 of this series, the only way to approach cyber risk management in a complex healthcare organization is to begin with a comprehensive, OCR-quality, security risk assessment and analysis.

Healthcare organizations must conduct this type of analysis in order to be HIPAA-compliant. But just as important is the fact that healthcare organizations cannot begin to develop a meaningful and effective cyber risk management program without first gathering the information that a comprehensive risk analysis provides.

As mentioned in the previous post, a security risk analysis essentially boils down to three tasks:

1. Identifying risk
2. Rating risk
3. Prioritizing risk

The HIPAA Security Rule, OCR Guidance, and resources developed by NIST provide plenty of details on how to properly conduct a risk assessment and complete these tasks. These resources are freely accessible on the internet. In theory, any healthcare organization could use these resources to conduct and complete an OCR-quality risk analysis without any outside support. However, that’s easier said than done.

Task 1: Identifying Risk

Risk identification begins with creating an information asset inventory that documents each asset that creates, receives, maintains or transmits electronic Protected Health Information (ePHI). This includes not just the obvious choices, such as laptops, servers, and enterprise applications, but also less obvious choices, including medical devices, backup media, and nonclinical, internet-connected assets such as building management applications and networks.

As noted in my previous post, creating an asset inventory is only the first step in risk identification. Risk has three components: an asset, a threat and a vulnerability. OCR guidance specifies that healthcare organizations must identify and document threats and vulnerabilities to each asset, in addition to creating an inventory of information assets.

Task 2: Rating Risk

Once you have exhaustively inventoried every aspect of risk – including every asset, and each of the threats and vulnerabilities associated with each asset – the HIPAA Security Rule and subsequent OCR guidance specifies that you must also estimate the likelihood (probability) and impact (magnitude of loss) of potential harm from each asset/threat/vulnerability combination. This is the risk rating.

NIST provides guidance for these tasks. NIST SP 800-30, Appendix G, includes several examples of assessment scales related to threat event likelihood. Appendix H, in the same publication, offers examples of scales for measuring impacts.

Task 3: Prioritizing Risk

After all information assets have been identified; after all potential threats and vulnerabilities have been documented; and after the likelihood and impact of each asset/threat/vulnerability combo has been calculated, each asset/threat/vulnerability combination will have an assigned risk rating.

As part of the cyber risk assessment/analysis process, every healthcare organization should establish a risk threshold. Establishing a risk threshold is part of the information security governance process. The risk threshold will be unique to the organization and will take into account the organization’s unique risks and resources. For example, using the 25-point scale, one organization might establish 15 as their threshold, meaning that any risk with a rating of 15 or below falls into the acceptable risk category, and will not be a priority with respect to mitigation.

A comprehensive information security risk analysis, combined with the organization’s established risk threshold, enables a healthcare organization to make informed, strategic decisions about which cyber security risks require urgent mitigation versus those that can be put on the “back burner” until more resources are available.

The Bottom Line

Conducting a comprehensive risk assessment is necessary for both HIPAA compliance and for establishing the foundation for a healthcare organization’s enterprise cyber risk management system (ECRMS). It is challenging, but not impossible, for a healthcare organization to conduct this analysis using only internal resources and guidance that is available on the internet.

Alternatively, healthcare organizations can use the specialized solutions and professional expertise to quickly and efficiently conduct a comprehensive cyber risk analysis. Because ultimately, completion of the analysis is only the first step. The sooner a comprehensive security risk analysis is completed, the sooner a healthcare organization can begin addressing vulnerabilities and mitigating high priority risks.  

Read more in this series:

• Panaceas, Shiny Objects and the Importance of Managing Risk in a Healthcare Environment–Part 1

• Panaceas, Shiny Objects and the Importance of Managing Risk in a Healthcare Environment–Part 2

Read More

Medical Device Security and CIO Insomnia

During a conversation over drinks with a number of CIOs at a recent healthcare conference, I discovered that the number one concern that keeps most healthcare executives up at night is the security of their medical devices. That was somewhat unexpected, especially following press-grabbing headlines last year about ‘WannaCry’ and other ransomware attacks rendering a large part of the British NHS and other health systems useless for several weeks or months.

Reason 1: Management

Part of their concern is that medical devices are not typically managed by hospital IT (overseen in most cases by the CIO) but by clinical / biomedical engineering staff who power on and attach devices to hospital networks but have little understanding of the cybersecurity risks that are created by connecting an unprotected medical device to the hospital business clinical network. Connected medical devices can by-and-large be compromised easily, used as a foothold on hospital networks, or re-programed to execute patients or hold them to ransom.

This is not fiction! It has been demonstrated numerous times at security conferences most recently by McAfee at BlackHat and Defcon in Las Vegas last month. New Zealand ethical hacker Barnaby Jack started the trend of exposing medical devices vulnerabilities, when in 2011 at the MacAfee Focus Conference he demonstrated a hack of a wireless insulin pump causing the pump to deliver its entire reservoir of insulin into a mock patient. In 2012 he followed this performance up with a hack of a Pacemaker causing the device to administer an 815volt shock directly to the heart of the mock patient. Both demonstrations would have been fatal to a real patient and that might explain why in 2007 Vice President Dick Cheney had the wireless interface disabled to his own pacemaker at the insistence of Doctors and the US Secret Service. Jack demonstrated the ease at which a patient could be harmed or executed once their Implantable Medical Device or IMD had been hacked. Others followed at subsequent security conferences with hacks of network-attached infusion pumps, reprogramming the device to give a continuous maximum dose of Morphine till the reservoir was empty and the patient likely dead.

Reason 2: Lack of Security

The CIOs second concern is that medical devices have almost no built-in security found on a typical workstation or laptop and cannot readily be patched or upgraded. Nor can security tools and supplicants like anti-malware or a host firewall be installed as the limited capacity of devices will not support the additional memory or processing requirements needed.

To compound these issues, medical device manufacturers are notoriously reluctant and slow to release patches for their devices even when known security vulnerabilities have been discovered. This has resulted in some high profile shaming of manufactures as in the case of Muddy Waters Capital, an Options Trader, against St Jude Medical and the first ever FDA recall of a medical device as a result of the public disclosure. Would the Food and Drug Administration (FDA) have acted if it weren’t for the very public disclosure? It’s hard to tell. Would St Jude Medical have spent any time fixing known security vulnerabilities in some of its pumps? Based upon past performance, it’s highly unlikely. In fact, that was the reason for Muddy Waters penetration test in the first place, thus driving down the share price of St Jude Medical stock, allowing Muddy Waters to profit from its options trades.

The fact of the matter is that most medical devices unless afforded extra layers of protection and defense-in-depth security, are extremely vulnerable to cyberattack. Especially if connected to the main hospital network, let alone allowed to talk to the Internet.

Why are Medical Devices so Vulnerable to Attack and Compromise?

Medical devices take 5 to 6 years to go through testing and clinical trials before they receive FDA approval. The same is true in most other countries. That means that brand new devices arriving in hospitals today were designed at least 5 or 6 years ago using technology that was available at the time. Anyone connecting their 2012 era Windows computer to the Internet tomorrow without any security software or updates would more than likely be compromised inside 10 minutes, yet that’s what we do with medical devices. Only with medical devices, we use them not to surf the web or check email, but to monitor and treat patients - and in some cases keep them alive. That’s where unmitigated risks surface that results in CIO insomnia.

The HIPAA Security Rule (45 CFR (§164.308(a)(1)(ii)(A)&(B) requires a Risk Analysis and ongoing Risk Management be conducted of any and all devices that create, maintain, transmit, or receive ePHI or other sensitive data. Yet most hospitals don’t even have an accurate inventory of their medical device assets so how can they possibly assess their risks? The identification and profiling of medical devices has not been easy for hospitals, most of which have had to rely upon labor-intensive ad-hoc manual discovery processes. New tools and services from IoMT / HIoT vendors in the space that can identify and profile medical devices is beginning to change this however. A full asset inventory and medical device profile can now be exported from these tools and entered into enterprise risk analysis tools to perform compressive risk analysis to meet the very strict requirements of OCR and HIPAA.

The concern however is a lot deeper than mere HIPAA Compliance and the protection of PHI. Patient safety has become a major worry for healthcare providers where changes to the integrity and programming of medical devices can have far reaching effects. Hackers have already demonstrated the removal of safety limits and have over-written calibration data and dosages and changed drug libraries. Not only is the integrity of medical devices a growing concern but also their resiliency. Most devices will crash or blue screen when a simple virus or multi-cast traffic appears on the subnet. In particular, device availability for patient telemetry systems is critical to alert care staff to patient Codes or other conditions where speedy action on their behalf is required to save a life. Integrity and availability attacks are far more concerning than confidentiality attacks against PHI, and is where the real damage can be done.

To date, the OCR has only issued written guidance on the risk analysis of medical devices containing PHI, although audits show that OCR is beginning to take a broader look at all medical devices regardless of whether they create, receive, store or transmit PHI. The FDA continues to issue guidance, NCCoE and NIST have written a guide to secure medical infusion pumps resulting in NIST Special Publication 1800-8, and the Cloud Security Alliance (CSA) and Open Web Application Security Project (OWASP) recently joined forces to publish a revised Medical Device Deployment Guide. The fact remains however, that numerous medical devices are extremely vulnerable and are not being adequately managed from a risk perspective.

The average cost of a data breach according to Ponemon is $3.8 million. The damage and impact to a hospital’s reputation following a medical device attack resulting in patient death is pretty much unlimited. This may sound a little far-fetched but a recent study by the University of California Cyber Team found that several hospitals had self-reported adverse events from compromised healthcare infrastructure cybersecurity events, like ransomware, malware, or compromised EHRs. The study found that adverse events impacted between 100 and 1,000 patients. Furthermore, the 80 percent of survey respondents that reported risks in medical devices, is way higher than what the FDA reports.

Risk Management

Once identified, risks to critical systems should be addressed immediately. When remediation or retirement of a medical device is not possible, effective compensating security controls should be implemented to isolate and protect the device from attack and compromise. Many of the larger hospital systems are turning to micro-segmentation of their medical device network assets using Cisco TrustSec or other tools to essentially white-list network communications to and from each medical device and drop all other traffic. GE Health and Unisys do this by routing all medical device traffic through proxy servers. Others have segmented their medical device VLANs by use of internal firewalls. These solutions all increase the complexity of networks and leave many smaller hospital systems with tight budgets and limited capabilities out in the cold.

What’s being done to harden medical devices and prevent them from being hacked?

Guidance (and its only guidance to date) has been published by the FDA, NIST, NCCoE, CSA/OWASP and others to improve the deployment and security of medical devices. The onus however is squarely being placed upon healthcare providers to secure the medical devices they procure and utilize. At the same time manufacturers are being pressured to improve the security design of their devices and now have to perform a risk analysis of medical devices before FDA approval. But with a 5 to 6-year development cycle, the results of ‘improved security by design’ may take many years to reach hospitals and patients. With a 15 to 20-year lifespan for many medical devices, the security problem is not about to go away any time soon. That means hospitals need to implement compensating security controls immediately and keep them there for the foreseeable future.

Somewhat alarmingly however, a recent Ponemon Report on Medical Device Security showed that despite known vulnerabilities “roughly one third of device makers and healthcare delivery organizations (HDOs) are aware of potential adverse effects to patients due to an insecure medical device, but despite the risk only 17 percent of device makers and 15 percent of HDOs are taking significant steps to prevent such attacks.”

Healthcare IoT and the Internet of Medical Things currently presents perhaps the single biggest open back door to securing healthcare the world over. 

Read More