Since Harbor Labs performed its first medical device cybersecurity assessment in late 2015, there has been a consistent and obvious trend in the origins of our client engagements.

More than half of all clients (62%) who have contracted with Harbor Labs for an assessment in support of a regulatory submission did so after one of the following conditions had occurred:

1. Negative premarket feedback
2. Rejected submission
3. Discovery of a postmarket vulnerability

Because each of these rejections represents misspent time and resources by both manufacturers and regulators, and in some cases imposed avoidable delays in getting clinical products to market, it is worth examining the leading factors that result in a rejected regulatory submission.

Our cyberscience staff recently met to compare experiences and identify the most common issues we have observed that ultimately led to bad regulatory outcomes. The following observations are anecdotal, but are nonetheless real-world examples of the more common assumptions and procedural oversights made by device manufacturers in their submissions that we have seen lead to FDA rejection:

“We use a proprietary communications protocol, which is in itself a sufficient security measure.”

Examiners have consistently rejected this argument. Proprietary mechanisms are security by obscurity. An attacker with unbounded time can circumvent them, a fact that has been proven through research by FDA staff themselves. Only use well-vetted, known, secure cryptographic algorithms, methods, or systems.

“After performing our own internal risk assessment and threat model, we concluded that a penetration test was not necessary to support our 510(k) submission.”

A risk assessment that does not trace or include cybersecurity testing will likely be rejected.  All medical devices that incorporate software should include comprehensive cybersecurity testing. Moreover, the testing should trace back to cybersecurity requirements, and the requirements back to the risk assessment.

“We provided regulators with exhaustive documentation and our submission was still rejected.”

This typically occurs when different elements within a large organization produce the components of a submission independently. The content can become fragmented, and very often lacks traceability. Avoid providing document dumps that overwhelm the examiner. Logical sequencing, format consistency, organization, and cross-document traceability are more compelling than volume.

“Regulators questioned the qualifications of my testing group.”

It is not enough to simply provide a table of test descriptions with each column marked “Passed”. Examiners want to know who specifically performed the tests, details on the analysis performed, and the credentials of the test engineers. Identify your testing group by name and wherever possible, include their attestation letter in your submission.

“We don’t need to perform robustness testing (DoS, DDoS) because our service platform or cloud provider offers this protection as part of their subscription service.”

It is important to understand whether the cloud resources where medical software and data reside automatically scale and provide firewall and anomaly detection functionality. When it is determined that these services are not provided by a particular cloud resource (an AWS EC2 instance, for example), robustness testing should be performed and included in the submission. In most cases, executing robustness testing will also require the permission of the cloud provider. In any case, when a component of a medical system resides in the cloud, vendor documentation specifically identifying the cloud service being used and citing the security features it provides is essential for the reviewer.

“Our secure communication protocol was rejected.”

Nonsecure protocols such as Telnet and FTP are obvious red flags to an examiner. But, even secure protocols can be rejected if they are subject to a deprecated or insecure configuration. A common example is TLS 1.2, which is considered insecure because it supports many insecure or deprecated ciphers in its cipher suite.

It is often the case that public clouds and third-party web services and platforms do not support the latest version of TLS. In this case, it must be documented and made clear that the manufacturer, as the client, will negotiate the highest protocol and strongest cipher suite.

“We had a cybersecurity consultant perform in-depth, independent pen testing but the examiner felt the test data lacked sufficient detail.”

Submissions are sometimes rejected because they lack a specific type of cybersecurity test. At a minimum, testing should include penetration testing, static analysis, dynamic analysis, fuzz testing, and robustness testing. A true pen test that comprises only the output of COTS pen test tools will rarely be sufficient for approval. Customized testing that exercises the unique clinical features of a device is more likely to demonstrate the thoroughness and thoughtfulness that examiners are looking for.

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

   • You must have a threat model.
   • The FDA outlines this requirement and advises how to perform it in the following resources:
     • Content of Premarket Submission for Management of Cybersecurity in Medical Devices
     • Playbook for Threat Modeling Medical Devices.
   • Threat model methodologies include:
     • STRIDE
     • Attack Trees
     • Kill Chain
     • DREAD
   • Your threat model must also include:
     • Assets
       • For example, assets include servers, end-user devices, smartphones, laptops, PCs, embedded systems, cloud services, virtual machines, etc.
     • Communication or data flows
       • For example, define the type of data, its sensitivity (e.g., PHI), and the assets that send and receive it.
     • Risk actors
       • For example, define insider threats such as rouge developers or cloud admins.
     • Threats
       • For example, an attacker with physical access to a medical device may connect to its JTAG interface.
     • Trust boundaries
       • For example, a medical device does not need to trust the network that it transmits data on.
     • You must create a threat model diagram.
       • Your threat model diagram must depict assets, communication flows, and trust boundaries.

2. Cybersecurity Risk Assessment

   • You must perform a risk assessment that considers cybersecurity vulnerabilities, defects, and exploits impacting patient safety.
   • You must also risk assess general cybersecurity risks that do not impact patient safety.
     • Confidentiality
     • Integrity
     • Availability
     • Privacy
   • You must create cybersecurity requirements, mitigation controls, and compensation controls.
     • Cybersecurity requirements prescribe how a device is secured.
       • For example, “All device network communication shall be secure.”
     • Mitigating and compensation controls implement the requirement to remove or reduce risk.
       • For example, “HTTPS using TLS 1.3 shall be used to ensure data is encrypted in transit.”
     • The FDA outlines this requirement and advises how to perform it in the following resources:
       • Content of Premarket Submission for Management of Cybersecurity in Medical Devices
       • The FDA also describes how to perform threat modeling in the Playbook for Threat Modeling Medical Devices.
     • The FDA recommends following and implementing risk assessment methodologies described in
       • NIST SP 800-30
       • IEC 62304
       • ISO 14971
       • Mitre’s Medical CVSS Rubric
     • You must include several types of cybersecurity risk assessment documentation, including, but not limited to:
       • Security Requirements Traceability Matrix
       • Device hazard analysis
       • Penetration Testing (see Cybersecurity Testing below)

3. Cybersecurity Testing

   • You must perform cybersecurity testing against your device and related systems.
     • 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.
     • Types of testing include:
       • Network enumeration
         • For example, identify computing devices reachable from a network. Perform port scans and OS fingerprinting.
         • Tools include:
           • Nmap
           • Testssl
       • Penetration Testing
         • For example, passively eavesdrop on network communication and actively insert, modify, drop, or jam network communication.
         • Tools include:
           • Nmap
           • Nessus
           • Metasploit
           • Burp Suite
           • Charles Proxy
           • Wireshark
           • Scapy
       • Static analysis
         • Software Component Analysis (SCA)
           • Tools include:
             • npm-audit
             • bundler
             • OWASP dependency-check
         • Static Application Security Testing (SAST) or Source Code Analysis Tools
           • Tools include:
             • SonarQube
             • Bandit
             • Brakeman
       • Dynamic Analysis
         • For example, perform input injection on running software.
           • Tools include:
             • Charles Proxy
             • MITM proxy
             • Burp Suite
             • ZAP
             • Scapy
       • DDoS and performance testing
         • Empirical analysis of network performance under artificial or malicious load
           • Throughput
           • Latency
           • Packet loss
           • Jitter
           • Tools include:
           • Hping
       • Fuzzing
         • Dynamic analysis technique to provide random, invalid, and unexpected inputs to a running software program or service
           • Example tools:
             • BooFuzz
             • AFL
             • Scapy
   • You must identify OTS software and SOUP incorporated in your device and related systems, and you must perform a vulnerability assessment of it.
   • You must create a Software Bill of Materials (SBOM).
     • You should determine software vulnerabilities using the NIST National Vulnerability Database.

4. Cybersecurity Monitoring

   • You must implement audit and logging capabilities in your devices and related systems.
     • Auditing and logging functionality include detecting, monitoring, logging, and alerting.
     • 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

   • You must create a plan that describes your overall cybersecurity approach.
     • This approach must incorporate the threat model, cybersecurity risk assessment, and testing procedures above.
     • This approach must also include a process and procedures for:
       • Continuous software vulnerability analysis
       • Incident response to a vulnerability or compromise
       • Software patching and updating

6. Device Configuration and Deployment

   • You must set your device’s default configuration to the most robust security setting.
     • 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.
   • You must also clearly label and inform your device’s users on operating and configuring their device based on cybersecurity best practices.
     • 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.
     • The FDA outlines this requirement and advises how to perform it in the following resources:
       • Content of Premarket Submission for Management of Cybersecurity in Medical Devices

7. Cryptography, Risk Assessment, and Software Generally

   • Risk assess known vulnerabilities for OTS software and SOUPs and provide a rationale if you decide not to update immediately.
   • Use TLS 1.3 or TLS 1.2 with cipher suites that use authenticated encryption with associated data (AEAD) for bulk encryption.
     • See RFC 8446.
   • Digitally sign and verify software updates using FIPS 140-3 approved algorithms such as ECDSA.
     • See FIPS 140-3
     • See NIST SP 800-140C
   • Enforce access controls (authentication and authorization) server-side.
   • 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.
   • Enable encryption at rest wherever possible.
   • Apply and enforce the principle of least privilege.
   • Use hardware security modules and critical management services on the backend where
   • 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.

It is an increasingly common practice in the medical device industry to integrate third-party smart devices such as phones and tablets into medical device architectures and operational models.

After examining several such systems, Harbor Labs has identified a broad set of unique cybersecurity risks in smart devices that may impact patient safety and privacy. To understand these risks, let us examine the design and function of a fictitious insulin delivery system called FakePump.

FakePump is a medical device that can read a patient’s blood glucose levels and in response, administer the appropriate insulin therapy. The patient wears the device at all times. FakePump has a Bluetooth Low Energy (BLE) wireless interface that can pair to the patient’s iPhone and send and receive data. The patient must install the FakePump iOS App on their iPhone to enable device communication.

Data sent from FakePump includes periodic blood glucose levels and events such as an insulin injection. Data received from the FakePump app contains commands such as inject N-units of insulin. The app forwards all received data to a content delivery network (CDN) managed by the device manufacturer called FakePump.io. The CDN stores patient data and exposes APIs for mobile and website applications to access and manipulate collected data.

A physician, caretaker, or patient may access this data via the application or CDN.

In the FakePump architecture, the iPhone is untrusted. The manufacturer has limited or no control over the smart device, while the patient has complete control. The manufacturer can minimally influence a patient’s iPhone’s hardware and software capabilities by setting a minimum iOS version supported by its iOS app. For example, the FakePump manufacturer may set the minimum iOS version to 11. This setting guarantees that Secure Enclave is available, and SFSafariViewController enforces cookie space separation between Safari and iOS apps. These features provide secure storage for the iOS app’s private crypto keys and restrict access to web-based access tokens.

However, this constitutes minimal control. A patient may jailbreak his or her device, thereby ignoring iOS app requirements. A jailbroken device may enable an attacker to access all app data previously subject to application sandboxing. More troubling, an attacker may access the FakePump iOS application binary and reverse engineer it.

These risks are inherent to any architecture that requires a smart device, including both iOS and Android devices. A reverse-engineered FakePump iOS app is a serious risk, as the effort would reveal all implementation and protocol-level app defects. These defects include hardcoded credentials, secrets, keys, improper or lack of input sanitization, rolling credential practices, insecure fallback mechanisms for data transmission, improper use of system libraries and functionality and outdated software dependencies with known vulnerabilities.

A reverse-engineering effort puts FakePump user safety at risk. It reveals details about the iOS app and the pump and CDN, such as tokens, passwords, keys and authentication methods. An attacker may use this to their advantage to spoof or tamper with data and commands.

Even when we assume the iPhone to be unmodified, cybersecurity risks related to software implementation are manifold. For instance, if the FakePump iOS app implements any of the following, it directly impacts patient safety and privacy:

The iOS app stores configuration data such as user credentials using UserDefaults.

• Sensitive data must never be stored using UserDefaults. Encryption is not enabled, and other applications may access the data even if application sandboxing is enabled (e.g., using app extensions).
• Instead, the Keychain Services API should be used to encrypt and store sensitive data.

The iOS app copies sensitive data, including PHI and PII, to the UIPasteboard (also called clipboard).

• Sensitive data must never be copied to the UIPasteboard because it is accessible to all iOS apps.

The iOS app does not protect against screenshots when PHI is displayed.

• Protecting against screenshots is a unique requirement that is only really been explored by apps like Snapchat. Currently, the iOS application can receive a notification when a user takes a screenshot. At a minimum, the iOS app should log the action.

The iOS app does not use Certificate Transparency (CT) when establishing TLS connections.

• Apple prescribes that all certificates issued after October 15, 2018, must meet its CT policy.

It should be noted that the cybersecurity risks presented in this paper were encountered in the course of Harbor Labs’ medical security analysis consulting, and were present in actual medical device architectures that included smart devices. Presenting these risks through a fictitious medical device is intended to illustrate the breadth of the patient safety and privacy issues that can be present in such architectures so that they may be avoided in future deployments.