-
Medical Device cybersecurity and Safety go hand-in-hand.
-
Growing demand for up-to-date methods in security audits.
-
Our approach: Five steps to cybersecurity.
Ten years ago, probably the only kind of medical device network would have been the nurse call system. Today, both in hospitals and for home healthcare devices, it’s a very different picture.
More and more devices are connecting to the same shared networks, and with an increasingly broad range of interfaces and data, basic IT security is becoming ever more important. Cybersecurity is now a key part of medical device development.
Why is cybersecurity so important for the medical device sector?
• More devices mean more connectivity
• More data interfaces mean more attack surfaces
• Public awareness of IT risks is leading to greater regulation
• New technology is resulting in more complexity
The threat to medical device systems from hackers and other bad actors is becoming ever more acute. There are a number of standards dealing with medical device security, but each tackles the issue from specific angles only. The ISO 27000 series of standards, Common Criteria and OWASP, for example, deal with technical and organisational measures for improving the security of IT systems. These standards do not look at the specific case of medical devices, in particular they do not consider the impact of cybersecurity on safety. ISO 80001 is limited to managing risks relating to the networks used by medical devices. AAMI Technical Report TIR 57, however, offers a combined security and safety risk management procedure specifically for medical devices (see figure 1). Safety management, in particular documenting product safety, is a key issue in medical device development.
The foreword to AAMI Technical Report TIR 57 neatly illustrates the interrelationship between safety and security: “The objective of this TIR is to provide guidance on how medical device manufacturers can manage risks from security threats that could impact the confidentiality, integrity, and/or availability of the device or the information processed by the device.”
TIR 57 offers a recognised process framework for managing security risks in the specific context of medical devices (AAMI TIR 57, FDA Recognition Number 13-83, published June 27, 2016). Given the fast-paced IT sector, the TIR 57 doesn’t specify concrete methods for security analysis or security measures. Whilst a variety of standardised approaches have been developed for industries ranging from air travel to IT services, there are none for the medical technology sector. It’s a similar picture when it comes to device safety. Here at Zühlke we have therefore developed a cybersecurity management toolkit specifically designed for medical device development. Our approach is based on IT best practices, the Common Criteria (ISO/IEC 15408) and AAMI TIR 57.
Cybersecurity management and the software development life cycle
Our procedure for cybersecurity management is designed so that it can be applied early in the project cycle and so that results can be incrementally completed. As development progresses, the security concept (see below) matures in tandem with the product. It allows factors relating to security to be identified, analysed and monitored at each phase of the software life cycle:
• starting with the product vision
• during elicitation of user needs
• during technical requirements engineering
• during implementation
• during unit and integration testing
• during rollout planning
• during operational support and monitoring
The key document for managing cybersecurity activities is the security risk management plan. This is drafted early in the project cycle and updated regularly. The procedural model set out in the security risk management plan can be tailored to the development project as required.
Initial security analysis identifies key application-specific assets and vulnerabilities based on the system context, external interfaces and intended use. As the project progresses, security analysis becomes more concerned with technical details. Technical details become more important once we reach the point of analysing the solution architecture and key system components such as libraries and connectivity. Once the implementation stage is reached, security analysis remains an important element for identifying vulnerabilities and changes. Security analysis also includes ongoing penetration testing during the development process.
Cybersecurity activities give rise to the following documentation:
• Security concept: A combination of underlying assumptions, constraints and policies affecting IT security, plus constructive security measures for the product
• Security analysis
• Vulnerability analysis of the tools and libraries used
• Retirement plan: Policy for archiving and deleting data (taking into account any legal requirements)
• Final report on and evaluation of cybersecurity.
Five steps to better cybersecurity
For cybersecurity analysis, we use an incremental five-step iterative model. It can be used to perform initial analysis as early as the project definition phase – even where only a few key functions have been identified, the overall scope is still under discussion and technical details are still largely up in the air. Our model is also excellent for producing a lightweight review of the security concept in ongoing projects.
1. Define assets
2. Identify potential threats
3. Analyse attack scenarios
4. Define security measures and security objectives
5. Detail intrinsic security measures (security requirements)
These five steps iterate throughout the project, leading to an increasing level of detail as the project progresses.
Assets:
A list of assets represents the starting point for security analysis. Assets are those data, functions or properties of a system that need protecting. Sources for identifying assets include lists of data items, performance requirements (such as system availability), or things which the product owner believes should be encrypted. Significant new assets will usually be added to the system during development and when adding new features to the system. These assets then need to be analysed and the steps below repeated. When identifying assets, a defined taxonomy can help to ensure that common function types are not overlooked.
Threats:
Similar to an FMEA, which considers specific error scenarios (failure, incorrect results, delayed results), threat analysis looks at a range of typical attack scenarios for each asset. Microsoft published its STRIDE model for threat analysis in 2005 (see the article “Sicherheit ist Risikomanagement” – only available in German):
The acronym STRIDE relates to the following six attack scenarios:
- Spoofing of identity
- Tampering of data
- Repudiation
- Information disclosure
- Denial of service
- Elevation of privilege
Detailed descriptions of these six categories can be found online – see for example this STRIDE chart on the Microsoft blog.
Threat anaylsis:
Detailed threat analysis involves examining potential attack scenarios relating to the various threats. What potentially exploitable vulnerabilities are there in the system? Once these have been described, they can then be assessed. Assessing how critical they are involves looking both at the consequences of an exploit and at the exploit likelihood. From this it is possible to determine the magnitude of the security risk and to decide whether further action needs to be taken.
Ordinarily, security analysis is principally concerned with avoiding financial losses. For medical applications, however, it’s important that we do not lose sight of the patient. A key question for threat analysis, therefore, is: could an attack impact patient safety? If the answer to this question is yes, this needs to be dealt with in the safety analysis.
Security objectives:
Security objectives describe actions and objectives for countering threats. Security objectives can relate to the system itself or the system environment. Examples of system-related objectives include signatures for firmware updates or secure cryptographic key storage. Implementation of these system-related objectives involves determining security requirements.
Security requirements:
Security requirements are based on system objectives and describe specific additional functions which the product under development needs to include. In the above example, this might mean specifying the signature procedure and defining requirements for the Trusted Platform Module. Security requirements are fed into the requirements management system and traced as per the process specifications. With this, the planned verification procedures can also be documented.
A comprehensive approach to cybersecurity
As with safety analysis also in cybersecurity management new functions of devices can again throw up new assets and attack scenarios. Consequently, security analysis should not be a one-time event, but should be performed repeatedly.
This systematic approach to cybersecurity management delivers a comprehensive security concept which is in full compliance with regulatory requirements. Requirements tracing and the integration with safety analysis are easily incorporated into existing development processes. By feeding security requirements into system design at an early stage, the risk of being forced to make time-consuming changes late in the project is minimised.
