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

MedCrypt makes it easier to patch cryptography-related vulnerabilities, by abstracting the cryptography software into a device-based agent. We compare MedCrypt-enabled devices in the field to the CVE database, and alert the medical device manufacturer (MDM) when a device is affected by a CVE.

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 MDMs to establish transport layer secure connections quickly and easily.

With MedCrypt Guardian, you can implement application-layer data authentication as a redundancy over a TLS 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 manage an organization-specific private key that only your organization has access to.

MedCrypt Guardian can be used to sign firmware and software, which 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 manage an organization-specific private key that only your organization has access to.

MedCrypt Guardian can be used to sign firmware and software, which can be verified on the device before a software or firmware update.

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 Guardian makes certain cryptography functions, like Sign / Verify, available via an easy to use API / ABI. This allows signing code, data, instructions, configurations, etc. and verifying 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 dynamically generates a SBOM in multiple formats.

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

MedCrypt delivers encryption in transit throught the implementation of an agent on the device.

MedCrypt Guardian can be used to encrypt data at rest in the application layer.

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 Guardian makes certain cryptography functions, like Sign / Verify, available via an easy to use API / ABI. This allows signing code, data, instructions, configurations, etc. and verifying 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

MedCrypt's event monitoring system alerts MDMs based on configurable settings, which include displaying an error message of choice to the device 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 Guardian makes certain cryptography functions, like Sign / Verify, available via an easy to use API / ABI. This allows signing code, data, instructions, configurations, etc. and verifying these data structures before they are loaded into an active device.

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 standardized design documentation for our cryptography framework, with descriptions of various security features that can be included in a MDM's FDA submission as appropriate.

MedCrypt dynamically generate a SBOM in multiple formats to support security documentation requirements.

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

Using MedCrypt Guardian, 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 by the device manufacturer.

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 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 authentication, to configuration 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 sign the provisioning files that contain the allow list, thus ensuring communication is only happening with trusted sources

READY TO START WORKING TOWARDS A MORE
SECURE HEALTHCARE FUTURE?

CONTACT US