Managing Security Risks With 80001

Transcription

1 Managing Security Risks With Nick Mankovich and Brian Fitzgerald Healthcare delivery organizations (HDOs, or hospitals) will soon begin to use IEC : to assist them in managing risks associated with medical IT networks IT networks in their facilities that incorporate medical devices. Recent attention has been given to the dangers of and poor outcomes occasionally experienced when in-hospital interconnection of medical devices is performed without due care. 2 Cooper and Eagles related how the new standard will help to provide safer, more effective, and more secure operation of a medical IT network. 3 Of course, the problems of incorporating a medical device onto an IT network are not confined to hospitals. With the global movement toward electronic medical records, it is likely that soon even the single practitioner may have a fairly sophisticated network as an integral part of the practice s infrastructure. It will be unlikely that the smaller practices will have the resources to maintain an aggressive cybervigilance stance and might be grateful for much of the complexity associated with the incorporation of medical devices into their infrastructure to be managed by a transparent, open process. One of the first challenges in managing risk is assembling information essential to the initial assessment of risk. For medical devices, this effort involves obtaining documentation One of the first challenges in managing risk is assembling information essential to the initial assessment of risk. and understanding of the device s intended use, instructions for use, security disclosures, and any other safety or effectiveness disclosures that might be possible. Similar documents must be obtained or created for the target IT network where the information sources may be internal or from both internal service providers and from IT vendors. This paper discusses the nature and use of security risk disclosures under IEC with an emphasis on the use of common terminology to group together and discuss the security capabilities and/or requirements for medical devices that are risk managed during the entire life cycle of connection to the medical IT network. It does not assume nor promote any particular security controls framework for the HDO or medical device manufacturer (MDM). Instead, it simply outlines a grouping of security capabilities of the medical device that are relevant to securing the IT network connected device throughout its life cycle. The article is an overview of an upcoming Technical Report from the IEC (publication likely in late 2011) and provides some information that may change before the release of the final report. However, we hope it provides an overview for HDOs, both big and small, to start to think about organizing their IT network risk management activities to include security About the Authors Nick Mankovich is senior director of product security and privacy with Philips Healthcare. Nick.Mankovich@ Philips.com. Brian Fitzgerald is deputy division director of the division of electrical and software engineering within the U.S. Food and Drug Administration s Center for Devices and Radiological Health. brian. fitzgerald@fda.hhs.gov Horizons Fall

2 Delivering safe and effective healthcare depends increasingly on having a secure medical device system and data. aspects. This report focuses on disclosure around the medical device and thus to MDMs throughout also talks about risk disclosure from IT vendors or manufacturers and this could follow a similar pattern of disclosure; but, for clarity, this text uses only MDMs as the disclosing entity. Rationale Securing a medical device system and its data is essential to delivering safe and effective healthcare. In a complex, Internet-connected world where malicious software is ubiquitous, careful design, rigorous implementation, and full-lifecycle care are the hallmarks of organizations that maintain the confidentiality, integrity, and availability of medical systems and their data. Over the past decade very few of us who use In a complex, Internet-connected world computers have not where malicious software is ubiquitous, been impacted by some careful design, rigorous implementation, sort of malicious and full-lifecycle care are the hallmarks of software propagated by organizations that maintain the networks and removable media. In confidentiality, integrity, and availability healthcare, probably of medical systems and their data. the most impactful malicious software for healthcare was the Conficker worm that led to an outage of approximately 10% of Sweden s healthcare IT infrastructure 4 and a similar shutdown of a large portion of healthcare IT in New Zealand. 5 An active, thoughtful, and participatory risk management program provides a means to the successful life cycle management of an IT-connected medical device. The complexity of modern healthcare IT networks and that of the sophisticated attached medical devices requires a disciplined risk management methodology provides a high-level process-based approach for risk management in the interconnection of medical devices to IT networks and it specifically addresses data and system security, which is defined in as an operational state of a medical IT network in which information assets (data and systems) are reasonably protected from degradation of confidentiality, integrity, and availability. In the world of medical devices, good risk management leads to well-informed design decisions that minimize hazards while fulfilling the healthcare mission provides a first-of-its kind elaboration of harm that includes consideration of security while keeping safety clearly in focus. Specifically, it expands the concept of harm by defining it as physical injury or damage to the health of people, or damage to property or the environment, or reduction in effectiveness, or breach of data and system security. The standard requires that the MDM disclose the technical specifications of the network connection of the medical device including security specifications. This disclosure fits into other aspects of the process of risk assessment including both basic asset security descriptions and the means to obtain and to react to cybersecurity notices from both MDM and IT vendors. With these few clear references to data and systems security in the standard, security-related hazards must be identified and risk managed in the planning for interconnection, the maintenance of the device on the medical IT network (including change management), and disconnecting the device from the medical IT network. The starting point for all of this is the pre-connection collection and evaluation of security capabilities of the device often done as part of purchasing. This paper (and the upcoming IEC Technical Report on Security Disclosure) eases this process by providing a common semantic framework and language for 28 Horizons Fall 2011

3 clear communication about the security capabilities of a medical device. How Secure is the Medical Device? The logical question How secure is the medical device? is basically unanswerable. Fortunately, that is not a question being answered in risk management. Instead, the HDO risk management team identifies known hazards and understands the hazard context sufficiently to design, implement, and verify controls that reduce the final risk to an acceptable level. Once that is done as much as reasonably practical, the HDO team summarizes and reports any remaining risks to executive management. HDO top management then decides if these risks of operation are acceptable in the context of the benefit accrued by putting the networked medical device into service. For risk management to succeed, the risk management team focuses on the basic intended use of the device, the capabilities of the device, hazardous situations, and the potential sources of harm. To include security into this broad methodology, it is necessary to obtain the security attributes of the device and to foresee hazardous situations arising in its networked operational state thus engaging in security risk management. In considering the process of risk management for data and systems security, a computer system vulnerability can constitute a hazard, defined as a potential source of unintended consequence. This might be, for example, a newly discovered way of obtaining direct access to a medical device by never changing a factory-installed user name and password combination that is easily guessed for example user ADMIN with password SECRET. If the computer system permits remote login via a network, and if the ADMIN account can read patient data, then we have a hazardous situation where compromise to a person s health data could lead to unwanted disclosures (thus causing harm to the individual). However, in examining this hazardous situation, if a service engineer disables the ADMIN account, she has mitigated the hazardous situation. An alternative mitigation could be for the IT network security officer to employ a network appliance external to the medical device that does not permit remote access. Both solutions offer a means to lower the risk but ABBREVIATION ALOF AUDT AUTH CNFS CSUP DTBK EMRG DIDT IGAU STCF MLDP NAUT PAUT PLOK SGUD SAHD RDMP TXCF TXIG UUID SECURITY CAPABILITY Automatic logoff Audit controls Authorization Configuration of security features Cyber security product upgrades Data backup and disaster recovery Emergency access Health data de-identification Health data integrity and authenticity Health data storage confidentiality Malware detection/protection Node authentication Person authentication Physical locks on device Security guides System and application hardening Third-party components in product lifecycle roadmaps Transmission confidentiality Transmission integrity Unique user ID Table 1. A list of medical device security capabilities used in risk-managing the connection of the device to a medical IT network. See the final IEC Technical Report on Security Guidance for the final standardized list. each solution must be examined to determine if there may be unintended consequences to the method of control. For example, by disabling the ADMIN account or blocking remote login, perhaps the device service provider can no longer provide rapid remote diagnosis. This might lead to increased down-time of the device a situation that can be seen as a hazard to the effectiveness of care or safety. This simple set of steps of surfacing potential hazards, understanding hazardous situations, proposing mitigations, and checking for newly introduced hazards is at the heart of risk management as outlined in ISO 14971: Ultimately, the connection, operation (including change management) and decommissioning of a medical device on an IT network will entail the appropriate selection of a set of security controls realized as technical, administrative, and physical controls on the networked device. If risk management is properly done, the only answer to the how secure question should be secure enough. For risk management to succeed, the risk management team focuses on the basic intended use of the device, the capabilities of the device, hazardous situations and the potential sources of harm. Horizons Fall

4 Security Capabilities Disclosure And Communication The management of risk for medical devices entails a long-term relationship between the operators of the device and the organization that both sells and/or services (maintains) it. This relationship, at best, is a partnership that provides the top-quality risk management that supports the healthcare mission of the HDO. Although security capability disclosure is likely to be done as part of a product offering, the full dialogue of capabilities and needs often leads to activities and actions for both the HDO and the MDM. This living dialogue and longer-term partnership is supported by a Responsibility Agreement that carefully details what each party brings to the activities around the management of risk. It forms the basis for a clear understanding of how the three organizations work together to realize the value of the medical device while maintaining the quality of service and continuity of care. For the MDM, the first step is to summarize the basic security specifications of the medical or IT product. The team is creating a technical report that provides a basic 20-category structure for the security capabilities of the device (Table 1). Abbreviations are provided to assist in the discussion of any one of the security features that might be detailed under these 20 categories. To provide a context for the security capability, the technical report provides reference material detailing applicable standards, policies, or other material. It also provides the fundamental security goal and provides simple statements of what the HDO wishes to achieve by having one or more controls that realize the security goal. It does not try to map these to any particular method or process of managing controls (such as ISO/IEC :2005, :2005, 27799:2008). 7 The healthcare organization can use whatever controls implementation framework that is most convenient to them. Consulting with IT network vendors (e.g., Cisco, Hewlett-Packard, Aruba) and/or MDMs might be helpful in choosing a framework. An example of a security capability description might be: MLDP: Malware detection/protection Applicable: Local HDO IT Policies Quote from regulation: Reference material: Requirement Goal: User need: Protection from malicious software (addressable). Procedures for guarding against, detecting, and reporting malicious software. NEMA Defending Medical Information Systems Against Malicious Software i Product supports regulatory, HDO and user needs in ensuring an effective and uniform support for the prevention, detection and removal of malware. This is an essential step in an in-depth approach to security. Malware application software is updated, malware pattern data files kept current and operating systems and applications are patched in a timely fashion. Post-updating verification testing of device operation for both continued intended use and safety is often necessary to meet regulatory quality requirements. HDOs need to detect traditional malware as well as unauthorized software that could interfere with proper operation of the device/system. The MDM would then typically present the actual security status of the product in this format, perhaps with many particular features under Malware detection/protection such as the extent of antivirus scanning, the means to get updates to the software and malware patterns, the frequency or operational conditions under which scans are performed, etc. Once this detail is disclosed, HDO staff may have questions. There begins a dialogue so that the HDO security specialist on the risk analysis team clearly understands what risks are mitigated directly in the device and which should be i NEMA/COCIR/JIRA Joint Security and Privacy Committee Defending Medical Information Systems Against Malicious Software. Available at 30 Horizons Fall 2011

5 The first Security Technical Report (TR) to follow the publication of the standard will provide a simple categorization of the security capabilities of a medical device as it operates on a medical IT network. mitigated by device-external (possibly network) security controls. It is this pattern of disclosurediscourse-decoupling-design which empowers the HDO security specialist to reduce risks to acceptable limits. As an example, the MDM would typically make a statement about the evaluation and validation of any operating system updates that would mitigate a newly discovered vulnerability (e.g., Microsoft Operating System patches). Because medical devices are highly complex and are subject to rigorous regulatory quality system-based controls like design change control, design verification and design validation, 8 many upgrades/patches cannot be applied without lengthy testing. So, the MDM would indicate to the HDO the overall structure of their internal patch verification and would indicate how the customer is kept up-to-date on the progress of testing. Occasionally, the MDM may indicate that testing is still underway much to the chagrin of the HDO Security Specialist. To the specialist, this means that a device simply connected to a large, Internet-connected network could pose quite a significant risk for malicious software attack. To mitigate this, it is generally accepted in the healthcare IT community that it is prudent to put many medical devices on a so-called medical device isolation network. 9 This sub-network, when accompanied by appropriate security controls (e.g., security appliances at the point of larger network interconnection), can be an effective local risk mitigation providing protection in the operational environment during the MDM s patch evaluation period that only the HDO can provide. So by setting expectations at a practical level during the disclosure phase, the additional risk incurred by the HDO during the patch evaluation period is offset by the addition of the isolation architecture intended to provide time for this evaluation. Conclusion The first Security Technical Report (TR) to follow the publication of the standard will provide a simple categorization of the security capabilities of a medical device as it operates on a medical IT network. This paper has given a sense of the way security risk is integrated into the overall risk management of the IT network. The creators of the security TR expect that it will provide a basis for communication between MDMs, IT vendors, and HDOs. We believe that during the purchase and subsequent installation process, the following steps will likely be followed: 1. MDMs and IT vendors provide summary statements of their product s security capabilities (the security disclosure) arranged under the 20 security capabilities titles. This would enhance and replace the current generation of Manufacturer Disclosure Statement for Medical Device Security (called the MDS2 form ) HDOs will review the security disclosure and question the MDM where more detail is necessary to the purchasing decision. Pre-sales information will be provided as necessary, perhaps under non-disclosure agreements. 3. In the device purchasing process, there will be a responsibility agreement created that articulates the roles and responsibilities in the planning, installation, and perhaps the maintenance process. This will include certain elements of collaboration in risk management. For more information see the Responsibility Agreements Ensure Accountability Under article in this publication. 4. The HDO s medical IT network risk manager forms a risk management team to perform risk analysis and engage in a control process during the installation and operation of the connection of the medical device to the medical IT network. This process may involve active participation of an MDM s representative(s) to quickly respond to technical questions during the initial process. Some of the risk management may need advanced security technical input. 5. The execution of the full risk management process has its first milestone after the acceptance of the residual risks and the connection of the device to the medical IT network. Full elaboration of the steps with examples can be found in the companion Horizons Fall

6 Step-by-Step Risk Management for Medical IT Networks article included in this publication. 6. Operation of the medical IT network will continue with risk management activities during changes and, in the case of security, when new vulnerabilities need to be considered for mitigation. Of course, it is impossible The application of risk management to predict exactly how the healthcare industry will decide in the use of information technology to take up the standard to interconnect medical devices and the data and system remains an important milestone in security elements. It is likely the improvement of care. that the larger institutional HDOs may provide the driving force, especially in the light of emerging enforcement activities for breach of confidentiality. 11 We also believe that a cottage industry may emerge to service the medical IT networking needs of small practices. As for the question where do you start? It is easy to see that the first step might be a solicitation for a quote with specifications from the HDO that list the desired security controls organized under the 20 categories of the technical report. Increasingly, commercial pressures will ensure the quote will contain the MDM s boilerplate security capabilities for input to the risk management process. The application of risk management in the use of information technology to interconnect medical devices remains an important milestone in the improvement of care. Technology provides many benefits but some risks and, as the technology grows in ability and complexity, organizations will learn how to manage the risks and costs to provide the best healthcare for their target populations. References 1. IEC :2010. Application of risk management for IT-networks incorporating medical devices Part 1: Roles, responsibilities and activities, Shuren J. Testimony before the Health Information Technology (HIT) Policy Committee, Adoption/Certification Workgroup. Washington, DC, February 25, Available at hhs.gov/portal/server.pt/gateway/ptargs_0_107 41_910717_0_0_18/3Shuren_Testimony pdf. 3. Cooper T, Eagles S. IEC SC62A Joint Working Group 7: Application of risk management to information technology (IT) networks incorporating medical devices. January 9, Available at www/f?p=102:14:0::::fsp_org_id: Wiinberg, Stig. e-virus ett ständigt hot mot patienten! (e-viruses a constant threat to the patient!). Notes from the MTF seminar on e-viruses in Stockholm January 19, Available at reportage_e_virus htm. 5. NZPA. Computer virus cripples Waikato DHB. New Zealand Harald nzherald.co.nz Available at article.cfm?c_id= &objectid= ISO 14971:2007. Medical devices - Application of risk management to medical devices. 7. ISO/IEC 27001:2005 Information technology Security techniques Information security management systems Requirements; ISO 27799:2008 Health informatics Information security management in health using ISO/ IEC 27002; ISO/IEC 27002:2005 Information technology Security techniques Code of practice for information security management. 8. U.S. Food and Drug Administration. Quality System Regulation 21CFR820. Available at www. fda.gov/medicaldevices/resourcesforyou/ Industry/ucm htm. 9. Haislip H, et al. Medical Device Isolation Architecture Guide, v2.0. Washington, D.C. : US Department of Veterans Affairs, August Available at: FocusDynamic.asp?faid= HIMSS Medical Device Security Work Group. Manufacturer Disclosure Statement for Medical Device Security MDS2 Version 1.0. HIMSS Medical Device Security Manufacturer Disclosure Statement for Medical Device Security. December 17, Available at files/mds2forminstructions.pdf. 11. McAndrew S, Holtzman DS. Health Information Security Rule: Trends in Enforcement. NIST/OCR HIPAA Security Assurance Conference. Available at May2011_workshop/presentations/day2_HIPAAconference2011-OCR-Enforcement-Activities.pdf. 32 Horizons Fall 2011