Introduction
Secure design best practices (and various standards and guidance) recommend penetration testing (pentesting) be included in the secure development life cycle and conducted by a team independent of the product developers and testers. Testing should begin when a stable design is testable, but before design freeze, to allow time to address any findings with appropriate design controls. Pentesting should be repeated for the final product including periodic retesting following market launch to ensure the device remains secure.
Your Goal
The goal of penetration testing should be to confirm any issues you know about in your architecture design or suspect might be lurking in third-party hardware, microcode/firmware, and software components, and exercise your threat mitigations to determine their effectiveness. Additionally, pentesting may find unknown weaknesses and vulnerabilities – but if your design is robust, hopefully not! The pentest should also confirm there are no unmitigated (or unsuccessfully mitigated) known anomalies and vulnerabilities in your device at the time of the test.
Locate Pentesters
The pentest organizations you interview will need to be approved suppliers according to your supplier management procedures. If your device contains software, the selected firm should be experienced in penetration testing of embedded systems (e.g., aerospace, automotive and/or medical device). If your device is Software as a Medical Device (SaMD), your selected penetration testing firm should be experienced in penetrating the types of infrastructure and platforms on which your device runs. Personnel conducting the testing should hold a significant cybersecurity credential like Certified Ethical Hacker (CEH) and be familiar with the standards, guidance and regulations governing medical devices (including understanding of related regulations like HIPAA).
In addition to appropriate qualifications to conduct penetration testing and report the findings, look for an organization that can provide appropriate recommendations to address findings and perhaps assist with remediation activities.
Test Scope
Define the device in scope for the testing. You may want to limit the test approach to device aspects in your control, e.g., hardware, firmware and/or software; configuration files; databases; etc. For an application the user installs on their own consumer/business platform (e.g., Windows, Android, iOS), the attack should probably be scoped only to the application to avoid excessive noise caused by finding vulnerabilities in the non-device platform. If you provide specific hardware to use with the application (e.g., a probe, a kiosked tablet, etc.), then that should be included in the scope. If your device includes an embedded operating system, then the hardware, operating system and any firmware or application software provided by you is probably in scope. If your device is hardware only but includes an ASIC or FPGA you may want to focus on that hardware and any microcode.
If your device includes Software as a Service (cloud) components, the scope should not exceed areas under your direct control. Testing may need to be conducted after normal operating hours to minimize potential impact. The duration of the engagement should be defined, as should the specific reporting requirements (e.g., to align with AAMI TIR57, ANSI/AAMI SW96, etc.).
Engage your technical team and security risk managers in conversations with the pentest vendor to help refine the scope to ensure full coverage of safety and security issues and device vulnerabilities while respecting the technical boundaries of the test. Note that changes of scope after the contract is signed will likely significantly delay the project and add substantial costs.
Test Approach
Pentesting should probably cover intended use cases as well as foreseen security misuse cases. Determine whether testing should be “blinded” (“black box testing”), where the attackers have no information regarding the device (other than anything they can glean through open source intelligence) or open (“white box testing”), where full design information is provided to ensure known vulnerabilities and misconfigurations are exercised (or perhaps a hybrid approach, where limited knowledge of the system is provided such as might be provided to a partner or service organization). Each approach has advantages and disadvantages; the team should discuss pros and cons in detail before deciding.
Regardless of the specific approach here, the pentesters should conduct a vulnerability assessment before diving into attempted exploitation. Depending on the nature of the device, there may be differing needs to attempt physical, local, and remote attacks (or a mix of approaches). If a device to be tested is at your production site, or installed at a customer site, very specific rules of engagement must be ironed out in advance and included in the contract. And local security personnel must be informed to avoid legal misunderstandings.
Reporting
After completion of the testing, a report must be provided documenting what was tested, how it was tested and the results including CVSS score and recommended remediations. The test report should conform to requirements in specific standards or guidance required in regulatory regions where the device will be marketed upon clearance, including documentation of the testers and dates of testing.
Follow Up
There should be a project review meeting to discuss preliminary test results and review the report. The final report should be approved by the pentest organization as well as the device manufacturer. The device manufacturer’s team should then develop an action plan to address the report findings, e.g., through CAPA, design change, etc.
Conclusion
Penetration testing is an integral part of the secure medical device development life cycle. Plan to do penetration testing early and continue verifying your device’s security after it is on the market. Find and qualify an experienced, ethical penetration testing organization with whom you can work over the long term. Attackers will never stop trying to hack your device – you should never stop ensuring its security.
MEDIcept has cybersecurity experts who can assist you with your penetration testing. Reach out to us today at sales@medicept.com to learn more about how we can help you.
Gregg Van Citters – Senior Software Quality Engineer