Medical software development – where safety meets security

The medical industry is seeing increased scrutiny for both safety and security in devices. Cyber security is becoming a must-have feature. Fortunately, there is significant overlap between the practices for safety and security, and it is vital to understand both the similarities and differences between the two principles.

Andrew Caples, Senior Product Manager, Embedded Systems Division (ESD), Mentor Graphics

At a time when device software is becoming more vital and complex, medical device manufacturers see increasing scrutiny over the safety and security of these devices. Safety standards such as IEC 62304 provide regulatory guidance that is followed by both device manufactures and COTS software suppliers.

However, safety standards have little to tell us about security.

Cyber security is now an important consideration that must be met by device manufacturers. Regulatory agencies are demanding device manufacturers secure and protect medical systems and patients from cyber attacks. And even though regulatory guidance is available, the recommendations do not specify the process or implementation required to improve security.

Fortunately, there is significant overlap between the development practices for both safety and security.

Standards for safety

From a software perspective, safety is based on defining and adhering to rigid processes through the complete development life cycle. Many industries have such well-defined safety standards, for example, DO-178C for airborne systems.

Although each standard differs in particulars, each shares a common thread in defining a similar safety development lifecycle, which serves as a framework to meet regulatory approval. The standards provide guidance for safety development that defines both the concept and the scope for each development phase. However, the standards do not define specifically how development will be done or which documents are required. By leaving this to the individual manufacturer, the standard allows the development of a tailored process that helps developers work as efficiently as possible while still mandating that complete information is available at the end.

As an example, for medical devices adhering to IEC 62304, the Software Life Cycle Plan (SLCP) is a plan for the development, test, and support of the safety software. Because of the scope of the SLCP, it can be a standalone plan that covers all development phases. Or, it can be supported with detailed plans for each phase for which the aggregation of all the plans meets the requirements for the standard. Thus, the SLCP can be supported by the Software Development Plan (SDP), Software Quality Assurance Plan (SQAP), Software Configuration Management Plan (SCMP), Software Verification Plan (SVP), and other plans.

Hazard and risk management
However, safety is not necessarily a byproduct of good planning and sound development; it also involves proactively managing hazards and the associated risk. A model is required to assess hazards to introduce mitigation solutions. Therefore, a model for a Safety Development Process should include the following:

Hazard Analysis => Risk Assessment => Damage Assessment => Device Classification => Risk Mitigation

Various tools and standards can guide developers for each phase. For example, a Fault Tree Analysis (FTA) can be used for hazard analysis. The FTA analytical approach helps identify each hazard and trace its lineage to the root cause. The process for FTA is to define each hazard and list the preceding events that can lead to the identified outcome. By capturing each event in a systematic manner, a fault tree can be built for each hazardous event in a hierarchal manner starting from the root cause.

A Fault Tree Analysis can help guide developers.

A process for medical risk management is well defined in ISO 14971. Risk management is required to determine the level of risk considered acceptable. Plus, it aids the understanding of how well risk mitigation techniques work.

Risk is the combination of the probability of an occurrence of harm and severity of that harm while hazard is the potential cause of the harm.

Risk = Function [Probability (harm), Severity]

One way to think of this is that a hazard can be detected before it causes harm; however, detecting harm means a hazard has already occurred. Risk analysis is the systematic use of available information to identify hazards, the severity of harm, and estimate the associated risk. The goal is to manage or mitigate risk to reduce risk to tolerable levels since total risk elimination is not achievable.

To reduce risk, protective measures can be taken that span the spectrum from documenting potential hazards, to software redesigns or adding warning lights.

There is no predetermined level of risk that is acceptable, and there is no equation or regulatory guidance for acceptable risk. This decision is somewhat subjective, but must take into consideration the potential hazard and harm that can result.

Once the hazard and risk analysis are completed, the device can be classified based on the severity of the potential harm using industry specific methodology.

Hazard as a function of the probability and severity. The Hazard Matrix is representative of the challenges associated with determining areas of acceptability.

For medical devices, the IEC 62304 standard provides the following Software Safety Classifications:

  • Class A: No injury or damage to health is possible
  • Class B: Non-serious injury is possible
  • Class C: Death or serious injury is possible

It is good practice to start out classifying devices at a Class Level C as the default assumption until a hazard and risk analysis proves the device to be of a lower risk.

Developing the software
With the hazard and risk assessments completed and the device classified, a plan for software development is required. The Software Life Cycle Plan (SLCP) as defined in IEC 62304 is a plan for the development, test, and support of the safety software. The hazard and risk analysis will become composite artifacts along with other requirement documents that will be used to define the function and design of the software. The comprehensive scope of the plan can serve as a framework for use in other areas such as the development of security software.

Similar to the development of safety software, security requires proactive management. However, instead of managing for hazards, security is about managing vulnerabilities and their associated risk. There are general guidelines and industry specific standards for cyber security that are starting to become more commonplace such as FIPS140, NIST 800-53, and IEC 62443 to name a few.

Differences between safety and security.

Also, consider the FDA non-binding guidance on securing medical devices throughout the product life cycle. Manufacturers are encouraged to boost cyber security measures by adding functions to monitor and detect vulnerabilities as well as update devices with software patches.

Even though there are many security standards, there are common themes among them that include identity management, authentication/authorization, detection, protection, secure communication, and mitigation. All of which can be boiled down to two security aspects: 1) how the device should protect itself, and 2) and how the device should be developed.

Developers have access to an array of hardware security features embedded in modern system-on-chip (SoC) architectures for device protection. Features such as high-assurance boot, root of trust, cryptography acceleration engines, secure key storage, and trusted execution environments can be leveraged to meet security requirements. Software protocols can encrypt to protect data at rest or in transit. And there are technical control standards for identification and authentication such as X.509 certificates and passwords. The specific security functions to build into the device will be defined by the results of a vulnerability and risk assessment.

As with safety, security requires a plan to manage the risk. However, for security, the goal is to manage the risk associated with each vulnerability, which requires a detailed assessment.

The vulnerability assessment
The objective of vulnerability assessment is to identify potential security concerns within the system. This calls for a comprehensive investigation of security threats and vulnerabilities. Tools such as the hazard and operability (HAZOP) analysis can be used to conduct vulnerability analysis. HAZOP uses guidewords for specific situations that are parsed into a list of intentions and deviations. The deviations are analyzed, and if significant, have a mitigation plan to reduce the risk.

HAZOP analysis example.

The following guidewords for vulnerability analysis are provided as an example: a) Probe – access a target to learn characteristics; b) Flood – access target incessantly to overload system; c) Spoof – masquerade by assuming the identity of a different entity; and d) read – obtain the data in device storage, etc. As further example, the guidewords are then parsed into a list to highlight the potential impact.

Upon completion of the vulnerability analysis, a risk assessment is required for each vulnerability. There are varying methodologies for determining risk including formulas; however, most agree, risk determination is a function of the threat, vulnerability, and severity.

Risk = Function [Threat, Vulnerability, Severity]

The goal is to understand the risk to determine if it is acceptable. The ability to determine risk is not always as straight forward as using a simple formula. As an example, for a vulnerability with a risk occurrence of 1%, should you factor in the impact of a determined hacker focusing on that single vulnerability 100% of their time? When determining risk, if the assessment shows that the risk is not acceptable, then risk mitigation is required and a new vulnerability analysis should be completed.

Determining risk.

The vulnerabilities should be classified using industry specific methodology. Many security engineers use High, Medium, and Low for vulnerability classification. Once the vulnerability and risk assessments are completed, then the requirements to mitigate the vulnerabilities can be defined.

As with safety, the development of a medical device requires a plan to realize the software for the device and to validate that the vulnerability requirements were fulfilled. The defined processes must include a plan to service the device post production to address vulnerability issues as they are found.

Safety vs. Security Development Process.

With the increased scrutiny from regulatory authorities, cyber security is becoming an important consideration that must be met by device manufacturers. Fortunately, there is significant overlap between the development practices for safety and security, and it is vital to understand both the similarities and differences between the two principles. Doing so will make you, and your company better prepared to handle today’s safety and security needs, as well as what may come along tomorrow.

Mentor Graphics

Speak Your Mind