Building functional safety while minimizing security vulnerabilities

If you are responsible for the development of a product that includes complex software and connectivity to the Internet, you may have many considerations, including but not limited to, quality, features, market/consumer needs, competitor landscape, etc. However, all that deliberation is futile without ensuring device security.

Security vulnerabilities can expose your devices, your customers, and yourself to several adverse consequences, including:

• Loss of confidential business data
• Exposure of customer or end-user data, which could lead to identity theft, HIPAA violations, and other dire consequences
• Infiltration of the device by malicious actors which can cause loss of property, injection of ransomware, etc.

Significant security vulnerabilities, once discovered, are documented as Common Vulnerabilities and Exposures, or CVEs. The CVE database is a repository of known exploitable security issues that exist (or existed) in products. CVEs are published and maintained in a joint effort between the MITRE Corporation and the US National Vulnerability Database (NVD), which is maintained by the US Department of Homeland Security. 

When a CVE is discovered, NVD assigns it a CVE identification ID. Further, if the CVE is determined to be an issue, it is also assigned a Vulnerability Score. This is a number between 1 and 10; the higher the number, the more serious the vulnerability will be to devices that contain the vulnerability. The NVD also contains any other known information about the issue, as well as links to pertinent sites that further describe the issue, and the existing fixes available for it.

But how do we find them? CVEs are discovered either as a result of damage caused (a postmortem of an adverse effect discovered the underlying issue), or as a result of a conscientious engineer who discovers a potential exploit.  The good news is that most exploits are discovered without causing damage. The bad news is once an exploit is communicated to the world through the CVE process, it can be easily exploited by hackers world-wide, so time is of the essence.

There are a number of tools available to help you identify if important CVEs are included in your product, the most important of which is called cve-check (https://github.com/clearlinux/cve-checktool). This tool generates reports that include which packages contain CVEs that are not resolved in the versions you are using, by performing version checking. You can use this information to determine if any preemptive action is required before your product is considered complete

There are other considerations that could cause your device to be more open to exploitation including:

• Access Control – Have you designed-in the ability to define roles that can access various types of data (user level, management level, maintenance level, etc.), and are you certain that only authorized roles access the data? 
  
• Encryption – Is the data stored on your device (both in memory and in storage), as well as that transmitted between your device and others, protected, and encrypted so that it can only be deciphered by those meant to see it? 
  
• Hardware security assistance – Many features of modern processors help in ensuring the security of your devices and applications, but it is the responsibility of the system designer to take advantage of them?

What about future vulnerabilities? Once the product is released, your work is not complete, just because you have protected yourself against all known exploits. The number of known exploits increases every day; in 2019, there were 12,174 CVEs created, which is over 30 per day. 

Of course, most of these do not turn out to be issues, and, of the ones that are issues, many will not apply to your device (many CVEs are reported against versions of open source components older than what you might deploy or will be against components you are not using). That said, at least a few of them will lead to exploits against your device. 

While there is no way to prevent this from happening, you need to know that it WILL happen, and you need to make sure your device is prepared. The time to prepare your device for the future is during development, so that you can prepare the device to be updated as new exploits (and significant product defects) are found and fixed. The most important consideration while future-proofing your device, is the ability to securely update your system. 

Security vulnerabilities are in every product, but you can learn how to protect your device from issues that are known, make it difficult for vulnerabilities that you do not know about to be exploited, and establish processes for known issues to be discovered and fixed.

When trying to develop devices that are as secure as possible, it can be helpful to think of it in terms of a safety vault:

• Closing the Door – Protecting your devices from known types of issues, security issues and product design
• Keeping the Door Closed – Protecting your devices from the future
• Make the Door Hard to Open – Apply preventative development techniques

Today, we explored closing the metaphorical door. Next time, let’s examine how to keep that door closed and make it hard to open.

Download these whitepapers on device security.

Medical device security: achieving regulatory approval

Minimizing Device Security Vulnerabilities using Embedded Linux

Building Functionality Safety and Security into Medical Devices