Anticipate software patches

FDA Guidance

Section V.B.2.(b), Line 532 “The device should be designed to anticipate the need for software patches and updates to address future cybersecurity vulnerabilities.”

Section V.B.2.(c), Line 534 “The device should be designed to facilitate the rapid verification, validation, and testing of patches and updates.”

Section V.B.2.(d), Line 536 “The design architecture should facilitate the rapid deployment of patches and updates.”

MedCrypt Solution

We monitor MedCrypt-enabled devices in the field and detect when a device is affected by a newly disclosed vulnerability (per CVE database). Cryptography-related vulnerabilities are easily patched since we have abstracted the cryptography software into a single library.

Authenticate all external connections

FDA Guidance

Section V.A.1.(b)(iv), Line 417 “Authenticate all external connections.”

Section V.A.1.(b)(vii), Line 435 “Devices should be designed to “deny by default,” i.e., that which is not expressly permitted by a device is denied by default. For example, the device should generally reject all unauthorized connections (e.g., incoming TCP, USB, Bluetooth, serial connections).”

Section V.A.2.(b)(ii), Line 458 “Ensure capability of secure data transfer to and from the device, and when appropriate, use methods for encryption and authentication of the end points with which data is being transferred.”

MedCrypt Solution

MedCrypt allows users to establish TLS connections quickly and easily, as well as implement application-layer data authentication. This adds a layer of redundancy over your TLS connection, keeping data secure if the TLS connection is vulnerable / compromised. (Note the FDA’s statement that this authentication should happen “even if the connection is initiated over one or more existing trusted channels”. We interpret this to mean securing communications even inside a VPN connection.)

Authenticate software and firmware

FDA Guidance

Section V.A.1.(b)(v), Line 421 “Authenticate firmware and software. Verify authentication tags (e.g., signatures, message authentication codes (MACs)) of software/firmware content, version numbers, and other metadata. The version numbers intended to be installed should themselves be signed/have MACs. Devices should be electronically identifiable (e.g., model number, serial number) to authorized users.”

MedCrypt Solution

MedCrypt can be used to sign firmare and software with an organization-specific private key that only your organization has access to. These signatures can be verified on the device before a firmware update, or as an application or configuration is loaded.

Authenticate software and firmware updates

FDA Guidance

Section V.A.1.(b)(ii), Line 411 “Require user authentication before permitting software or firmware updates, including those affecting the operating system, applications, and anti-malware.”

Section V.A.2.(a)(i), Line 445 “Only allow installation of cryptographically verified firmware/ software updates. Use cryptographically signed updates to help prevent unauthorized reduction in the level of protection (downgrade or rollback attacks) by ensuring that the new update is more recent than the currently installed version.”

MedCrypt Solution

MedCrypt can be used to sign firmare and software updates with an organization-specific private key that only your organization has access to. These signatures can be verified on the device before a firmware update, or as an application or configuration is loaded.

Capture forensic evidence

FDA Guidance

Section V.B.1.(c), Line 505 “Ensure the design enables forensic evidence capture. The design should include mechanisms to create and store log files for security events. Documentation should include how and where the log file is located, stored, recycled, archived, and how it could be consumed by automated analysis software (e.g. Intrusion Detection System, IDS). Examples of security events include but are not limited to configuration changes, network anomalies, login attempts, and anomalous traffic (e.g., sending requests to unknown entities).”

MedCrypt Solution

The event data we capture is stored off of the device, and can be used to support incident detection and response. This data is available only to your organization, and will not be shared without your permission.

Code integrity

FDA Guidance

Section V.A.1.(b)(i), Line 408 “Use authentication to prevent unauthorized access to device functions and to prevent unauthorized (arbitrary) software execution.”

MedCrypt Solution

MedCrypt’s embedded library makes certain cryptography functions, like Sign / Verify, available via an easy to use API / ABI. This allows a user to sign code, data, instructions, configurations, etc. and verify these data structures before they are loaded into an active device.

Cybersecurity Bill of Materials (CBOM)

FDA Guidance

Section V.B.1.(g), Line 526 “The device design should provide a CBOM in a machine readable, electronic format to be consumed automatically.”

MedCrypt Solution

MedCrypt matches versions of its software and component open source libraries to specific devices. Users can also import lists of other component software libraries to be tracked within MedCrypt. This allows us to dynamically generate a SBOM for any MedCrypt enabled device and track software component vulnerabilities on a per device basis.

Detect security compromises

FDA Guidance

Section V.B.1.(a), Line 499 “Implement design features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use.”

MedCrypt Solution

This is the single biggest advantage to using MedCrypt. MedCrypt-enabled devices send behavior and security event metadata to an event monitoring system (that can be located in the cloud or on-prem), and these events are monitored for suspicious behavior. The behavior baselines are built around healthcare-specific data, that would be difficult or impossible for your organization to capture internally.

Encrypt data at rest and in transit

FDA Guidance

Section V.A.2.(b)(i), Line 455 “Verify the integrity of all incoming data (ensuring it is not modified in transit or at rest, and it is well-formed/compliant with the expected protocol/specification).”

Section V.A.3, Line 478 “Lack of encryption to protect sensitive information “at rest” and “in transit” can expose this information to misuse that can lead to patient harm.”

MedCrypt Solution

Encrypt data at rest and in transit at the application layer preventing exposure of your data and partners data and creating redundancy against unknown network security controls.

Ensure code, data and execution integrity

FDA Guidance

Section V.A.2.(c), Line 462 “Protect the integrity of data necessary to ensure the safety and essential performance of the device.”

Section V.A.2.(b)(iii), Line 471 “Where feasible, use industry-accepted best practices to maintain/verify integrity of code while it is being executed on the device.”

MedCrypt Solution

MedCrypt’s embedded library makes certain cryptography functions, like Sign / Verify, available via an easy to use API / ABI. This allows a user to sign code, data, instructions, configurations, etc. and verify these data structures before they are loaded into an active device.

Incident response management

FDA Guidance

Section V.B.2.(a), Line 530 “The device should be designed to notify users upon detection of a potential cybersecurity breach.”

MedCrypt Solution

In one specific example, should an application on your device experience a signature verification failure of a command, our event monitoring system is altered, and your application can initiate a failure mode (as appropriate for the user) and display an error message of your choosing to your user.

Password parameters

FDA Guidance

Section V.A.1.(a)(v), Line 398 “Strengthen password protection. Do not use credentials that are hardcoded, default, easily-guessed, easily compromised (i.e., passwords which are the same for each device; unchangeable; can persist as default; difficult to change; and vulnerable to public disclosure). Limit public access to passwords used for privileged device access.”

MedCrypt Solution

MedCrypt-enabled devices send behavior metadata to an event monitoring system (that can be located in the cloud or on-prem), and these events are monitored for suspicious behavior. The behavior baselines are built around healthcare-specific data, that would be difficult or impossible for your organization to capture internally.

Per device unique secure communication key

FDA Guidance

Section V.A.2.(b)(v), Line 467 “Use unique per device cryptographically secure communication keys to prevent leveraging the knowledge of one key to access a multitude of devices.”

MedCrypt Solution

MedCrypt makes it easy to have each endpoint in your medical device system or network generate unique key pairs, and use the public keys of these endpoints to authenticate before commands are accepted.

Backup and disaster recovery

FDA Guidance

Section V.B.2.(b), Line 542 “The design should provide methods for retention and recovery of device configuration by an authenticated privileged user.”

MedCrypt Solution

MedCrypt’s embedded library makes certain cryptography functions, like Sign / Verify, available via an easy to use API / ABI. This allows a user to sign and instruction, and verify it originated from a trusted source, and has not been modified.

Security Documentation

FDA Guidance

Section VII. A. 1. Line 658 “For Tier 1 devices, documentation that addresses each recommendation in Section V .”

Section VII. A. 2., Line 660 “For Tier 2 devices, documentation that addresses each recommendation in Section V or include a risk-based rationale for why a cybersecurity design control was not necessary. Risk- based rationales should leverage an analysis of exploitablity to describe likelihood instead of probability.”

Section VII. A. 3, Line 664 “System Diagrams sufficiently detailed to permit an understanding of how the specific device design elements (from section V) are incorporated into a system-level and holistic picture. Analysis of the entire system is necessary to understand the manufacturer’s threat model and the device within the larger ecosystem.”

Section VII. A. 4, Line 685 “(a) Network, architecture, flow, and state diagrams. (b) The interfaces, components, assets, communication pathways, protocols, and network ports. (c) Authentication mechanisms and controls for each communicating asset or component of the system including web sites, servers, interoperable systems, cloud stores, etc. (d) Users’ roles and level of responsibility if they interact with these assets or communication channels. (e)Use of cryptographic methods should include descriptions of the method used and the type and level of cryptographic key usage and their style of use throughout your system (one-time use, key length, the standard employed, symmetric or otherwise, etc.). Descriptions should also include details of cryptographic protection for firmware and software updates.”

Section VII. B. 2, Line 704 “A summary describing the design features that permit validated software updates and patches as needed throughout the life cycle of the medical device to continue to ensure its safety and effectiveness.”

Section VII. B. 3, Line 710 “A summary describing the design features that permit validated software updates and patches as needed throughout the life cycle of the medical device to continue to ensure its safety and effectiveness.”

Section VII. B. 4, Line 719 “A specific list of all cybersecurity risks that were considered in the design of your device. We recommend providing descriptions of risk that leverage an analysis of exploitablity to describe likelihood instead of probability. If numerical probabilities are provided, we recommend providing additional information that explains how the probability was calculated.”

Section VII. B. 5, Line 735 “A specific list and justification for all cybersecurity controls that were established for your device. This should include all risk mitigations and design considerations pertaining to intentional and unintentional cybersecurity risks associated with your device, including: (a) A list of verifiable function/subsystem requirements related to access control, encryption/decryption, firewalls, intrusion detection/prevention, antivirus packages, etc. (b) A list of verifiable of security requirements impacting other functionality, data, and interface requirements.”

Section VII. B. 6, Line 738 “A description of the testing that was done to ensure the adequacy of cybersecurity risk controls (e.g., security effectiveness in enforcing the specified security policy, performance for required traffic conditions, stability and reliability as appropriate).

A traceability matrix that links your actual cybersecurity controls to the cybersecurity risks that were considered in your security risk and hazard analysis.

A CBOM cross referenced with the National Vulnerability Database (NVD) or similar known vulnerability database. Provide criteria for addressing known vulnerabilities and a rationale for not addressing remaining known vulnerabilities, consistent with the FDA’s final guidance, Postmarket Management of Cybersecurity in Medical Devices."

MedCrypt Solution

We provide standards-compliant design documentation for our cryptography framework, with descriptions of various security features that can be included in a vendor’s FDA submission as appropriate.

MedCrypt also matches versions of its software and component open source libraries to specific devices. Users can also import lists of other component software libraries to be tracked within MedCrypt. This allows us to dynamically generate a SBOM for any MedCrypt-enabled device.

Software configuration management

FDA Guidance

Section V.B.1.(e), Line 519 “The device design should enable software configuration management and permit tracking and control of software changes to be electronically obtainable (i.e., machine readable) by authorized users.”

Section V.B.1.(d), Line 514 “The device design should limit the potential impact of vulnerabilities by specifying a secure configuration. Secure configurations may include endpoint protections such as anti- malware, firewall/firewall rules, whitelisting, defining security event parameters, logging parameters, physical security detection.”

MedCrypt Solution

Device configurations can be signed, and verified on application start. Should this configuration be changed, a desired failure mode (error message, warning, alert, etc.) can be specified.

Use cryptographically strong authentication

FDA Guidance

Section V.A.1.(b)(iii), Line 414 “Use cryptographically strong authentication resident on the device to authenticate personnel, messages, commands and as applicable, all other communication pathways.”

MedCrypt Solution

MedCrypt makes it easy to choose and implement a cryptographic algorithm that is appropriate for your device, and allows you to change and patch these algorithms as vulnerabilities are found (keeping your device "Cryptographically Strong" over the life of the device). This cryptography can be implemented in various areas of your device, from communication encryption, configuration signing, to device-to-device authentication.

Use recommended standard for cryptography

FDA Guidance

Section V.A.2.(b)(iv), Line 464 “Use current NIST recommended standards for cryptography (e.g., FIPS 140-2, NIST26 Suite B27), or equivalent-strength cryptographic protection for communications channels.”

MedCrypt Solution

In addition to allowing the use of FIPS 140-2 compliant cryptography algorithms, medcrypt makes it easy to patch and update algorithms in the future, without changing the business logic of your device.

Whitelist based on digital signature

FDA Guidance

Section V.A.2.(a)(ii), Line 451 “Where feasible, ensure that the integrity of software is validated prior to execution, e.g., ‘whitelisting’ based on digital signatures.”

MedCrypt Solution

MedCrypt can dynamically generate whitelists of endpoints a particular device should be able to communicate with, and sign that whitelist with a private key. This whitelist signature can be verified, and the list used to ensure communication is only happening with trusted sources.

READY TO START WORKING TOWARDS A MORE
SECURE HEALTHCARE FUTURE?

CONTACT US