Medical Device Manufacturer Must Do’s for Cybersecurity

At Harbor Labs, one of our most common services is reviewing the cybersecurity content of the premarket submissions of Medical Device Manufacturers (MDMs). When we provide this service, my team is brought in to perform a third-party review of the client’s cybersecurity processes, procedures, and overall product cybersecurity posture. This review will result in the production of a Cybersecurity Threat Assessment (CTA) — our process for creating a threat model, performing a cybersecurity risk assessment, mapping cybersecurity requirements, mitigating and compensating controls, and performing pen testing/cybersecurity testing.

In our many engagements performing this type of analysis, we have had a unique opportunity to see a broad variety of MDM submissions and the resulting FDA feedback. And in the process, we have noted a pattern of common pitfalls that cause MDMs to be delayed or disqualified from receiving regulatory approvals. In this blog post, I have compiled an outlined list of must do’s to avoid the common cybersecurity obstacles that hinder regulatory approval.

1. Threat Model
   1. You must have a threat model.
   2. The FDA outlines this requirement and advises how to perform it in the following resources:
   1. Content of Premarket Submission for Management of Cybersecurity in Medical Devices
   2. Playbook for Threat Modeling Medical Devices.
   3. Threat model methodologies include:
   1. STRIDE
   2. Attack Trees
   3. Kill Chain
   4. DREAD
   4. Your threat model must also include:
   1. Assets
   1. For example, assets include servers, end-user devices, smartphones, laptops, PCs,embedded systems, cloud services, virtual machines, etc.
   2. Communication or data flows
   1. For example, define the type of data, its sensitivity (e.g., PHI), and the assets that send and receive it.
   3. Risk actors
   1. For example, define insider threats such as rouge developers or cloud admins.
   4. Threats
   1. For example, an attacker with physical access to a medical device may connect to its JTAG interface.
   5. Trust boundaries
   1. For example, a medical device does not need to trust the network that it transmits data on.
   5. You must create a threat model diagram.
   1. Your threat model diagram must depict assets, communication flows, and trust boundaries.
2. Cybersecurity Risk Assessment
   1. You must perform a risk assessment that considers cybersecurity vulnerabilities, defects, and exploits impacting patient safety.
   2. You must also risk assess general cybersecurity risks that do not impact patient safety.
   1. Confidentiality
   2. Integrity
   3. Availability
   4. Privacy
   3. You must create cybersecurity requirements, mitigation controls, and compensation controls.
   1. Cybersecurity requirements prescribe how a device is secured.
   1. For example, "All device network communication shall be secure."
   2. Mitigating and compensation controls implement the requirement to remove or reduce risk.
   1. For example, "HTTPS using TLS 1.3 shall be used to ensure data is encrypted in transit."
   4. The FDA outlines this requirement and advises how to perform it in the following resources:
   1. Content of Premarket Submission for Management of Cybersecurity in Medical Devices
   2. The FDA also describes how to perform threat modeling in the Playbook for Threat Modeling Medical Devices.
   5. The FDA recommends following and implementing risk assessment methodologies described in
   1. NIST SP 800-30
   2. IEC 62304
   3. ISO 14971
   4. Mitre's Medical CVSS Rubric
   6. You must include several types of cybersecurity risk assessment documentation, including, but not limited to:
   1. Security Requirements Traceability Matrix
   2. Device hazard analysis
   3. Penetration Testing (see Cybersecurity Testing below)
3. Cybersecurity Testing
   1. You must perform cybersecurity testing against your device and related systems.
   1. Related systems refer to computers, servers, cloud platforms, and software services that communicate and, generally, integrate with your device. This concept is referred to as a system of systems.
   2. Types of testing include:
   1. Network enumeration
   1. For example, identify computing devices reachable from a network. Perform port scans and OS fingerprinting.
   2. Tools include:
   1. Nmap
   2. Testssl
   2. Penetration Testing
   1. For example, passively eavesdrop on network communication and actively insert, modify, drop, or jam network communication.
   2. Tools include:
   1. Nmap
   2. Nessus
   3. Metasploit
   4. Burp Suite
   5. Charles Proxy
   6. Wireshark
   7. Scapy
   3. Static analysis
   1. Software Component Analysis (SCA)
   1. Tools include:
   1. npm-audit
   2. bundler
   3. OWASP dependency-check
   2. Static Application Security Testing (SAST) or Source Code Analysis Tools
   1. Tools include:
   1. SonarQube
   2. Bandit
   3. Brakeman
   4. Dynamic Analysis
   1. For example, perform input injection on running software.
   1. Tools include:
   1. Charles Proxy
   2. MITM proxy
   3. Burp Suite
   4. ZAP
   5. Scapy
   5. DDoS and performance testing
   1. Empirical analysis of network performance under artificial or malicious load
   1. Throughput
   2. Latency
   3. Packet loss
   4. Jitter

   Tools include:

   1. Hping
   6. Fuzzing
   1. Dynamic analysis technique to provide random, invalid, and unexpected inputs to a running software program or service
   1. Example tools:
   1. BooFuzz
   2. AFL
   3. Scapy
   2. You must identify OTS software and SOUP incorporated in your device and related systems, and you must perform a vulnerability assessment of it.
   3. You must create a Software Bill of Materials (SBOM).
   1. You should determine software vulnerabilities using the NIST National Vulnerability Database.
4. Cybersecurity Monitoring
   1. You must implement audit and logging capabilities in your devices and related systems.
   1. Auditing and logging functionality include detecting, monitoring, logging, and alerting.
   2. Depending on your architecture, for example, a cloud-based backend, you may use standard IDS, IPS, and SEIM solutions to meet the requirement.
5. Cybersecurity Plan
   1. You must create a plan that describes your overall cybersecurity approach.
   1. This approach must incorporate the threat model, cybersecurity risk assessment, and testing procedures above.
   2. This approach must also include a process and procedures for:
   1. Continuous software vulnerability analysis
   2. Incident response to a vulnerability or compromise
   3. Software patching and updating
6. Device Configuration and Deployment
   1. You must set your device's default configuration to the most robust security setting.
   1. For example, a firewall may be enabled that blocks all ports except for those running services. Only TLS 1.3 is enabled. MFA is required to authenticate users accessing services external but integrated with the device, etc.
   2. You must also clearly label and inform your device's users on operating and configuring their device based on cybersecurity best practices.
   1. For example, make it clear that disabling the firewall creates severe risks for your device. Allowing TLS 1.0 compromises the integrity and confidentiality of your network-based communication. Password-only authentication is susceptible to phishing and brute-force attacks, etc.

   In many cases, you may forgo allowing your end-user to reduce security. In our experience, there is a lot of concern around this approach from MDMs.

   3. The FDA outlines this requirement and advises how to perform it in the following resources:
   1. Content of Premarket Submission for Management of Cybersecurity in Medical Devices
7. Cryptography, Risk Assessment, and Software Generally
   1. Risk assess known vulnerabilities for OTS software and SOUPs and provide a rationale if you decide not to update immediately.
   2. Use TLS 1.3 or TLS 1.2 with cipher suites that use authenticated encryption with associated data (AEAD) for bulk encryption.
   1. See RFC 8446.
   3. Digitally sign and verify software updates using FIPS 140-3 approved algorithms such as ECDSA.
   1. See FIPS 140-3
   2. See NIST SP 800-140C
   4. Enforce access controls (authentication and authorization) server-side.
   5. Risk assess cloud services regarding access control, security configuration (e.g., encryption at rest and transit), etc. Don't assume that using a third-party cloud provider is good enough.
   6. Enable encryption at rest wherever possible.
   7. Apply and enforce the principle of least privilege.
   8. Use hardware security modules and critical management services on the backend where
      possible.
   9. Do not hardcode any password, credential, secret, API key, etc.

To summarize, the MDM must create processes and procedures memorialized in the cybersecurity plan. As a part of that plan, you must describe your threat modeling, cybersecurity risk assessment, and cybersecurity testing process. Then, you must execute these processes when developing and assessing your device. Lastly, you must provide this information and the testing results in your formal submissions to the FDA, regardless of whether it’s a Pre-Sub, 510(k), or PMA.

Our advice–be clear, consistent, and concise when describing your cybersecurity. Perform testing and provide the results as evidence that support your position that your device and its related systems are secure.