Embedded systems are often at the heart of life and safety critical products. As such, they fall under a range of regulations and standards that govern their safety. Manufacturers analyze them for a wide range of potential hazards coming from sources such as component unreliability, user error, physical misuse and possible design errors. Adding a network to these devices, however, introduces security as a new risk to device safety.
Securing embedded systems that are accessible remotely via a network creates a challenge for many manufacturers. The traditional embedded systems developer is not familiar with security technology or assessing risk of a potential hacker exploiting a device vulnerability. Unfortunately, the conventional Information Technology (IT) world is not much help because experts in that field are not familiar with real-time embedded control systems, safety risk management or regulated software development.
An Approach
The addition of “networked” to embedded systems increases the scope of this system to the network and potentially everything connected to it. A variety of processes have been developed that can be applied to efficiently and effectively analyze such a system and make informed, intelligent decisions on addressing the security threat. The National Institute of Standards and Technology (NIST) has published two such processes, SP-800-30 and SP-800-39.
A security analysis begins with a threat model created by enumerating the threats, vulnerabilities, and assets in the context of the full system. A formal risk-driven approach is then used to guide decision making for where additional security controls may be required, and what parts of the system contain the greatest security risk. Security risk is traditionally analyzed along the “CIA Triad” – Confidentiality (ensuring the system (including data) is accessed only in defined ways), Integrity (ensuring the system is changed or manipulated only in defined ways), and Availability (ensuring the system is accessible and operational when needed).
Also critical to the development of secure embedded systems is implementing a secure development lifecycle to continually manage the risk. NIST’s SP 800-39 and others recognize the importance of establishing security requirements and to do so at the outset and over the lifecycle of the device. This may take the form of augmenting the normal “Use Case” with a set of “Abuse Cases” that document what an attacker might attempt, that must be rejected in the design.
The risk analysis and decision-making must continue throughout the lifecycle. The hardware/software architecture should be analyzed for weak points, and security controls put in place to mitigate potential vulnerabilities. Strategies must be developed for code analysis, and security-based testing, such as fuzz testing and penetration testing.
It is important to remember that, when addressing security risk, it is not possible to prove a device is secure. All that is possible is to raise the bar to increase the confidence that the easy exploits will not bear fruit. Consequently, it is important to design methods to collect information from fielded devices to identify undetected vulnerabilities, and put in place a mechanism to securely deploy patches when newly discovered issues cross the risk threshold for response.
An Example: Medical Devices
The issues discussed above are particularly critical and timely in the case of medical devices. The Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 has incentivized the use of integrated Electronic Health Record systems, and with that, the push to integrate a wide range of medical devices to these health records systems.
The opportunities that come with such integration are obvious – elimination of paper and transcription errors, reduced clinical workload, and continuous monitoring with alerting, to name a few. The risks may not be as obvious. Since an embedded electronic medical device is either collecting information that will be used to diagnose a patient (e.g. bedside monitors), or may directly provide therapy to a patient (e.g. infusion pump), incorrect functioning of an electronic medical device can lead to patient harm. Malicious (or incompetent) users can affect the patient.
As a specific example, consider a bedside drug infusion pump designed to provide a measured flow of a drug into a patient. Overdoses and underdoses may be hazardous and even fatal. In fact, the independent research group ECRI lists “Infusion Pump Medication Errors” as the #2 health technology hazard for 2014 in a recently released report1. As a stand-alone device, many sophisticated features, such as local alarms for under/overflow/blockage/refill required/etc., have been added to mitigate many of these safety hazards.
To supplement the local alarms, a network interface has been added to communicate alarms to a remote nursing station. To minimize errors in getting the right drug/right dose/right patient, drug dictionaries, bar code scanners, and remote access to patient weight and prescription status have been added. Returning to the CIA Triad, here are some issues that the newly networked device faces.
Confidentiality
An infusion pump will contain information such as patient name, an identifier for the patient (possibly their hospital record ID), and information on the drug being delivered and its dosage. Due to HIPAA privacy laws, this information is Protected Health Information (PHI) and must be kept confidential. Clearly, when that information is being sent over the network, in either direction, it must be suitably encrypted. The analysis needs to extend to the data kept in the device – particularly when the pump is removed from the patient and sent to storage or a new patient.
Integrity
Ensuring pump integrity involves analysis of the mechanisms that control access to the pump from the network. Clearly, the infusion settings that drive drug delivery need to be protected, and modification only allowed through authorized means. The drug dictionary and the process to update it must similarly be protected. The protocols to access patient information, such as patient weight and prescribed drug must be designed to eliminate false information being provided to the pump. The source of the data needs to be appropriately authenticated, as the wrong weight/wrong patient/wrong prescription can all result in patient harm.
A less obvious asset to ensure is trusted is the pump software itself. If an attacker can modify or replace the device software, then the protections built into the legitimate software are irrelevant. Authentication mechanisms should be used that protect access to patch/reprogramming functionality. Low-cost hardware options such as the Trusted Platform Module2 (TPM) can be added which provides a high- confidence confirmation of software integrity during the boot process.
Availability
Availability considerations include ensuring that the pump continues to perform its normal operation even if a malicious actor interferes with the network connection. While a denial of service attack on the connection may disrupt the ability to change the pump to a different drug/different patient, a robust design should eliminate dependence on the network for regular operation. If the network is used for remote alarm reporting, warnings can be provided on the device if a secure connection cannot be maintained with the downstream alarm manager.
Conclusion
As this case study shows, once an embedded electronic device is connected to a network, security becomes an important consideration of device safety. At the same time, system complexity also increases dramatically. Fortunately, processes and procedures are available, such as the NIST examples cited above, that provide a formal methodology for assessing the security risks in a system and prioritizing mitigations for addressing those risks.