MedISAO introduces Coordinated Vulnerability Disclosure process for members
Does your organization have a Coordinated Vulnerability Disclosure Process as advised by the FDA's Postmarket Cybersecurity Guidance?...
MedISAO introduces Coordinated Vulnerability Disclosure process for members
Back to Basics: Part I
FDA Postmarket Cybersecurity Guidance Released
Medical Device Security 101 Conference
Hippocratic Oath for Connected Medical Devices
Automated Vulnerability Alerts for Embedded Linux
Back to Basics: Part II
This is a continuation of a previous post on Basic Cybersecurity Hygiene. These are common, simple mistakes that many device developers still make today.
As a reminder, the tips from Part I are:
Do NOT use hard-coded user credentialsSanitize any inputs from outside your software (e.g. check your XML processing libraries for vulnerabilities!)
Let's continue!
Never, ever, create your own cryptographic scheme or implementation. Always use established cryptography libraries for password protection, authentication, encryption, etc.
Need to encrypt data sent over a network? Need to encrypt it on disk? Need an authentication scheme to be sure users are who they say they are? Don't try to make your own! Cryptography is extremely difficult to design and implement correctly. There are established methods and off-the-shelf libraries available for any conceivable cryptographic task.
There is a well-known saying in the cryptography community:
Anyone can create a crypto-system that they themselves cannot break.
Determine all network services running on your device, and disable any that are not explicitly necessary. Got a SSH server on your device for development? Remember to turn it off before you release for production!
You can run a port scan on your device to determine what TCP and UDP ports it has open. You should understand and approve of any open ports on your device. See https://nmap.org/book/man-port-scanning-techniques... for more detailed information on using the popular open-source tool “nmap” to perform port scans.
It is often the case that devices are vulnerable because they include software libraries that have publicly known (and patched) vulnerabilities. The vulnerability has been published, which means that hackers know about it. A fix for the software is available, which means that if the device has the fix, it isn’t vulnerable. However, the device developers aren’t aware that there is a vulnerability, so the vulnerability goes unfixed, and now hackers have a roadmap to compromise the device.
For example, the National Vulnerability Database lists this critical flaw in OpenSSL 1.1.0a that can allow a hacker to completely take over a device. Do you have the OpenSSL library on your device? Which version? Are you sure?
The answer is that you must create a "Software Bill-of-Materials (BOM)" for your device. This is a list of all software packages, and their versions, that are installed on the device. Then, you should monitor the National Vulnerability Database for vulnerabilities that affect any item on your Software BOM.
Does your organization have a Coordinated Vulnerability Disclosure Process as advised by the FDA's Postmarket Cybersecurity Guidance? MedISAO can take care of that for you! We recently launched a Co
Let's take a moment to get back to the basics of cybersecurity in medical product design. The goal is to prepare a solid list of things to be on the lookout for when doing a cybsecurity risk analysis.
In an uncharacteristically quick move, the FDA released this official guidance less than a year after the draft was released for comments. This guidance for medical device manufacturers "recognizes to