Medical Device Threat Modeling

Document and Mitigate Threats to Medical Devices

On top of the usual threats inherent to IT networks, applications, and cloud services, the complexity of medical devices creates a massive, distributed attack surface. The need for effective cybersecurity measures has become increasingly important and is now required by the U.S. FDA.

This FDA guidance helps Medical device manufacturers (MDMs) ensure their devices are sufficiently resilient to cybersecurity attacks. Specifically, MDMs need to deliver a system-level threat model that includes a consideration of risks from its supply chain, design, production, and deployment. We’ve been doing this for a while, we can help.

Download

Leverage our Expertise to Build Customer Confidence

For over two decades, we’ve been conducting software and system threat models on medical devices, robotics, motorcycles, and a plethora of smart home devices.  We understand the IoT ecosystem well and focus our threat modeling efforts on its high-risk areas that attackers love to target: bypassing authentication controls,  programming devices remotely, and tampering with data.

The finished threat model gives you clear insight into:

  • Assets that are most at risk and most likely threats to them
  • How your device could be attacked and steps to realize each threat
  • Conditions under which attacks would be successful
  • Mitigations to address the identified threats

Take our Threat Modeling Course

View
"With threat modeling, Medical Device Manufacturers (MDMs) can prevent bad architectures from being designed and implemented. That’s promising, but we don’t have a scalable workforce to do this for all the MDMs that exist. Security Innovation’s rich history of threat modeling will certainly help"
Josh Corman, Founder of I am The Cavalry, and member of Congressional Task Force for Health Care Industry Cybersecurity

Our credentials

To stay ahead of the threatscape, our IoT Center of Excellence conducts ongoing research on chipsets, crypto, communication protocols, Real-Time OSs (RTOS), and deployment platforms for connected devices. We’ve worked closely with Fortune 500 and SMBs alike to help them address their most critical threats and deliver more resilient products.

Some of our HealthTech customers:

Geoff Vaughan, Sr. Security Engineer, IoT CoE Lead

IoT Center of Excellence(CoE) Lead

Geoff Vaughan

Principal Security Engineer

Geoff is a Software & IT Security expert who specializes in finding exploitable vulnerabilities and reverse engineering binaries to locate vulnerable code.

Our Approach

Effective threat modeling requires intimate knowledge of the software and implementation. Security Innovation has focused exclusively on software security since our inception and we infuse this expertise into our Threat Modeling approach:

Threat Model_designUnderstand architecture and security

To establish critical context, our engineers must understand how patients, clinicians, technicians, and customer support each use the system. This is achieved through documentation, walkthroughs, and interviews.

  • Features and use cases of the component
  • Users of the component and data being consumed by it
  • What data must be protected or is considered sensitive
  • If there is an admin interface, how it is used and protected
  • Any existing security controls, reviews, or considerations
  • Protocols, libraries, frameworks, or other external components used
  • Biggest security concerns as viewed by the teams

Threat Model_designIdentify assets and roles

The system is divided into a series of assets, each representing items of value to the users of the system or to the business that deploys it. The users who interact with the system are categorized based on what actions they can take against these assets. For example, assets include not only sensitive data such as patient health information but also system data such as application credentials, feature administration, and underlying operating system credentials. Roles that encompass authorized users’ permissions in the system will be used to define access rules for each asset.

Threat Model_designBuild an activity matrix

Create explicit mappings specifying what assets each role can interact with and under what conditions. Evaluation of this matrix yields the threats against the system from a requirements perspective. The activity matrix includes authorized users as well as anonymous, unauthenticated, or unprivileged users to define the rules of interaction of the system that can be used during penetration testing to identify failure modes including both vertical and horizontal privilege escalation.

Threat Model_designIdentify threats that put assets at risk

Create a prioritized set of potential threats that put assets at risk by violating the interaction rules identified between actors and assets. This could be the ability to extract and modify the firmware of a device with unauthorized changes or extract credentials that allow connecting to a supporting cloud-based component with administrative privileges.

Threat Model_designIdentify attacks that could be used to realize threats

For each threat, attacks are defined based on the most likely methods by which the threat could be realized. Practical expertise comes into play in identifying the malicious attack or attacks that can realize each threat. Attack trees show the design and deployment conditions under which each attack would be successful, ranging from simply connecting to a device via USB to instrumenting the memory of the device to control its execution.

Threat Model_designIdentify testable conditions that each attack requires to be successful

For each attack defined, a set of conditions required for it to be successful is determined. From these conditions, mitigations can be created to reduce the risk of attack in your system, ranging from network defenses for devices in hostile or unreliable environments to security features of the system such as properly secured communication protocols and physical hardening.
"Nearly 50% of security flaws will be discovered from Threat Modeling because it finds different threats than those found through other assessment techniques"
Michael Howard, Sr. Security Architect , Microsoft