At the ELC + OpenIoT Summit, Intel Security Architect Ryan Ware will explain how to deal with the flood of vulnerabilities and manage your product’s security.
When developing open source software, the security vulnerabilities you need to consider may overwhelm you. Common Vulnerabilities and Exposures (CVE) IDs, zero-day vulnerabilities, and other vulnerabilities seem to be announced every day. With this flood of information, how can you keep from falling behind?
Intel Security Architect Ryan Ware said: “If you release a product based on Linux kernel 4.4.1, as of today there are 9 CVEs for that kernel. These will all affect your product, despite the fact that you didn’t know about them when you deployed them.”
At ELC + OpenIoT Summit, Intel Security Architect Ryan Ware’s presentation will introduce strategies for implementing and successfully managing product security. In his presentation, Ware discussed the most common developer mistakes, strategies for keeping up with the latest vulnerabilities, and more.
Linux.com: Let’s start from the beginning. Can you briefly introduce Common Vulnerabilities and Exposures (CVE), zero-days, and other vulnerabilities? What are they and why are they important?
Ryan Ware: Good question. Common Vulnerabilities and Exposures (CVE) is a database maintained by MITRE Corporation (a non-profit organization) at the request of the U.S. government. It is currently funded by the U.S. Department of Homeland Security. It was created in 1999 to contain information about all published security vulnerabilities. Each of these vulnerabilities has its own identifier (CVE-ID) and can be referenced. The term CVE has evolved from referring to the entire database to representing a single security vulnerability: a CVE vulnerability.
Many vulnerabilities that appear in the CVE database were initially zero-day vulnerabilities. These vulnerabilities, for whatever reason, did not follow a more orderly disclosure process such as “Responsible Disclosure.” The key is that if no software vendor can respond through some type of fix (usually a software patch), then they become public and exploitable. These and other unpatched software vulnerabilities are critical because vulnerabilities are exploitable before the software is patched. In many ways, releasing a CVE or zero-day is like firing a gun. Your customers are vulnerable before the race ends.
Linux.com: How many vulnerabilities are there? How do you determine which ones are relevant to your product?
Ryan: Before discussing how many there are, anyone who releases software in any form should remember. Even if you take every effort to ensure the software you release has no known vulnerabilities, your software will have vulnerabilities. They just aren’t known yet. For example, if you release a product based on Linux kernel 4.4.1, as of today, there are already 9 CVEs. These will all affect your product, despite the fact that you didn’t know about them when you used them.
At this point, the CVE database contains 80,957 entries (as of January 30, 2017), including all records dating back to 1999, when there were 894 recorded issues. To date, the largest number appearing in a year was 2014, when 7,946 issues were recorded. That said, I don’t think the decrease in numbers over the past two years is because of fewer security vulnerabilities. This is something I’ll talk about in my presentation.
Linux.com: What strategies can developers use to keep up with this information?
Ryan: Developers can keep up with this flood of vulnerability information in various ways. One of my favorite tools is CVE Details. It presents information from MITRE in a very easy-to-understand way. Its best feature is the ability to create custom RSS feeds so you can track vulnerabilities in components you care about. Those with more complex tracking needs can start by downloading the MITRE CVE database (available for free) and updating it regularly. Other excellent tools, like cvechecker, can let you check for known vulnerabilities in software.
For key parts of the software stack, I also recommend a very useful tool: participating in the upstream community. These are the people who understand the software you’re using best. There are no better experts in the world than them. Work with them.
Linux.com: How do you know if your product has addressed all vulnerabilities? Are there recommended tools?
Ryan: Unfortunately, as I said above, you can never remove all vulnerabilities from your product. Some of the tools mentioned above are key. However, I haven’t mentioned a part that’s critical for any product you release: the software update mechanism. If you can’t update product software on the spot, you can’t solve security issues when customers are affected. Your software must be able to be updated, and the easier the update process, the better protected your customers will be.
Linux.com: What else do developers need to know to successfully manage security vulnerabilities?
Ryan: There’s a mistake I see repeatedly. Developers always need to keep in mind the idea of minimizing the attack surface. What does this mean? In practice, this means only including what your product actually needs! This not only includes ensuring you don’t add irrelevant software packages to your product, but also compiling projects with configurations that turn off unneeded features.
How does this help? Imagine it’s 2014. You just got to work and saw technical news about Heartbleed. You know you included OpenSSL in your product because you need to perform some basic encryption functions, but you don’t use TLS heartbeat, which is related to the vulnerability. Would you rather:
a. Spend time working with customers and partners to fix this high-security issue through critical software updates?
b. Just tell your customers and partners that you compiled the OpenSSL product using the “-DOPENSSL_NO_HEARTBEATS” flag, they won’t be harmed, and you can focus on new features and other production activities.
The simplest way to solve a vulnerability is to not include it.
(Image: Creative Commons Zero Pixabay)
Reposted from: Developer Relations »
