14,000+ CVEs were discovered in 2017. In April of 2018 the CVE list had surpassed 100,000 entries, and that number grows every day. So how do you protect your embedded devices and open source embedded systems in IoT and IIoT deployments from this endless onslaught of security threats?
With unpredictable and fast-paced discoveries, managing endless threats and maintaining the security of your embedded software throughout the product lifecycle can be a significant challenge — and a time-consuming one. If your plan is to weather the vulnerability storm yourself, then you’ll need to ask yourself the following questions:
1. Are there new CVEs to be aware of?
The answer to this question is essentially always going to be yes. In order to stay on top of current potential threats, your team must constantly monitor security databases and mailing lists for all the new CVEs discovered each day.
The National Institute of Standards and Technology’s National Vulnerability Database (NVD) is a good place to start watching, as is cve.mitre.org. And groups like the CERT Coordination Center may keep track of other CVEs not listed by others.
In order to have a complete picture of what threats exist for your device, you have to remain up-to-date with each of these sources as well as others.
2. Are there CVEs specific to your product?
It’s a given that you want to avoid spending time evaluating CVEs you don’t actually have to worry about. To make sure you’re focusing only on genuine threats to your specific software configuration, keep a BOM/manifest of your project’s open source software components throughout its lifecycle. If you know the version of each software component you use, you’ll be able to differentiate between CVEs that put your projects at risk and those you can safely ignore.
3. How severe is the CVE?
CVEs are given a score so you can prioritize which vulnerabilities are most important to fix. The score takes into account things like how the vulnerability is accessed — locally? through the network? — how easy it is to exploit, how often an attacker must authenticate to the target, and how confidential the data at risk is. These elements should all factor into whether or not you take the time and effort to address a vulnerability.
More trivial vulnerabilities don’t always have to be addressed, especially if you’re trying to decrease time to market for new products or quickly handle the most pressing vulnerabilities in products already in the field. But if a vulnerability is being actively exploited in the wild, can lead to attacks on other systems when breached, or affects something critical to device operation, it’s important to fix it as soon as possible.
4. Does an update exist? Does a patch?
Sometimes vulnerabilities can be fixed by updating your software, and sometimes you’ll need to apply a patch. If you’re lucky, one of these fixes will already exist, and you can address the issue immediately. Otherwise, you’ll have to keep a lookout until a fix is created, so you can apply it when it becomes available.
5. Where can the patch be found?
If a patch does exist, it can be found on software package websites, security mailing lists, upstream packages, or NVD feeds. Often, it will take a great deal of searching just to locate a patch that addresses the vulnerability concern.
6. How will you test the patch after applying?
Once you’ve tracked down a patch and applied it to your software, you’ll have to test it to make sure it doesn’t affect the overall function of your product. If anything breaks, you’ll have to find a way to fix it — while making sure you don’t compromise security in the process.
7. How will you maintain the patch throughout the product’s lifecycle?
Even after you’ve applied a fix, you can’t know that your product will remain safe from this particular vulnerability. You’ll need to monitor updates to fixes to make sure you’re aware of any further action you need to take down the road.
A More Efficient Solution
That’s a huge list, and unless you have almost unlimited time and resources, it’s just not feasible to continuously follow these steps alone.
Luckily, developers don’t have to weather the ever-expanding storm of vulnerabilities by themselves. Timesys’ Threat Resistance Security Technology (TRST) Product Protection solutions include our Security Vulnerability and Patch Notification service, designed to automatically identify CVEs that will affect your project and their existing fixes — so you don’t have to wade through lists of irrelevant ones. We are committed to helping you reduce the time and cost you devote to security.
Our Security Vulnerability service takes on the task of CVE monitoring for you. It scans security databases and mailing lists for you, highlighting vulnerabilities that apply to your unique build and categorizing them based on severity, so you can choose which to address.
Then, our Patch Notification service provides you with fixes that put you on the road to a solution. You can add or update the meta-timesys-security layer to apply fixes to your software, and configure your recipes to selectively include only the patches you want. You’ll also have access to old build configurations in LinuxLink, so you can see how the threats to your product have evolved over time.
We can’t make the vulnerability storm go away. But we can help you weather the threats and protect your embedded IoT, IIoT systems and other embedded devices from the fallout.
About Timesys
Timesys has extensive experience with embedded system development and lifecycle management. Timesys has been instrumental in working with global leader semiconductor manufacturers with smart, quick and quality solutions for highly complex systems with accelerated product innovation and multiple product variants.
