Tuesday morning, I walked in and my phone was already ringing, never a good sign. Someone had just shared that a new Zero Day would be announced in just three days, and of course everyone was panicking. This is the type of news I really hate, a pre-announced Zero Day. No real details were shared upfront, other than the product name and that it was susceptible to a Zero Day. As I sat there trying to analyze my situation, a hundred thoughts ran through my mind, even DREAD - of course the Damage Potential, Reproducibility, Exploitability, Affect Users, and Discoverability were all high given that this was a Zero Day. But then I began to worry about the real question – Is this something my infrastructure is exposed to?
"Most organizations have two problems with software supply chain management; knowing when the components have vulnerabilities and knowing which components are in the product "
You probably recognize this scenario. You may even realize that the traditional questions of, ‘Where is it in my infrastructure?’ and ‘Is that area exposed?’ are no longer as effective as they once were. Why? Nowadays the Zero Day can be a product, component, or both. If it is a highly leveraged component, you may not even know that it is in your infrastructure and thus you cannot track your exposure or even plan for the mitigation. The ability to know and track software, including the components and all elements of it in your environment is often referred to as Software Supply Chain Management. This article will provide strategies for Software Supply Chain Management with respect to ways to detect potential issues and finally how can you respond to the potential issues.
Before we begin with the details of software supply chain management, we first must understand what it is and why it needs to be done. Most products leverage third party components, such as Java or OpenSSL, to provide features that are secondary to the basic functionality of the product. In some cases the components may not be present in the user’s environment and software developers may include them for convenience. One may wonder why the developer uses these components and why the vulnerabilities are not detected.
While products are thoroughly tested, re-tested, evaluated, scanned, and tested again before they are released, developers may not detect any vulnerability. This is because the developer tests in the deployment configuration they have specified. Unfortunately, the developer cannot know your exact environment i.e., they do not know if you have another product installed in the same infrastructure that can be exploited to create a vulnerability in their architecture. A second possibility is that if you have deployed the product in an infrastructure that is less secure than what was anticipated. Consider the scenario of a software developer that creates a package for environmental monitoring (heating and cooling). Because the package runs on a network, the company decides to allow access to it from the internet. Unless stated as supported by the software developer, this is probably not part of the usage or security model for the product. Hence, the product may now be exposed to attacks beyond what was anticipated by the software developer.
Most organizations have two problems with software supply chain management; knowing when the components have vulnerabilities and knowing which components are in the product. It is not hard to determine if there is a known vulnerability in a component. This is because of the Common Vulnerability and Exposure (CVE) records in the National Vulnerability Database (NVD). Information about CVEs can be found in one of two places. The first
is the CVE MITRE site (cve.mitre.org). This database is fairly high level, but can be used to get basic information. The second database, the NVD, can be found at web.nvd. nist.gov. The NVD database provides common names, descriptions, rankings, sources for where they were discovered, and components that have the vulnerability. The rankings are very important in determining the potential impact. Unfortunately, sometimes the description of the vulnerability is somewhat vague. A recent CVE had the following description:
Unspecified vulnerability allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Libraries, a different vulnerability than CVE-2015-.
In addition to the MITRE and NIST sites, you can also subscribe to the CERT site for announcements. The subscription information can be found on the bottom of page: www.us-cert.gov.
The second problem involves creating a list of components. Under normal circumstances, identifying the product is easy to do. Identifying some third party components is also easy, if the component requires attribution. If the component requires attribution, it may be placed in the product literature (hard copy), the help about or even in a file on the disk. If the component doesn’t require attribution, finding it can be trickier. It may require that you look at the product shipping manifest, locate the files, and examine them for copyright, product names, owners. Lacking this information, one could generate a hash of all the components and look them up in either of the places below:
• US National Software database: www.nist.gov
• National Software Reference Library: www.nsrl.nist.gov
While these are complex ways to determine if products may be susceptible, an easier way would be to subscribe to a product’s security announcement list. If the vendor does not have one, you may want to ask them to implement one.
There are two alternatives to the component enumeration process. The first is a proposed bill, which requires companies to publish component lists. Unfortunately the bill lacks sufficient details to make it useful and effective. The second is a proposed UL software stamp. This UL stamp requires vendors to provide the following:
1- Product component bill of materials.
2- Statement attesting, at release time, there are no known vulnerabilities in the product.
3- Defined mitigation / release process if a vulnerability is found.
This makes more sense, but may also be used as attack input for hackers.
Going forward, a component list allows us to monitor the NVD for potential issues. Don’t panic when you see the results, as not all vulnerabilities will impact you. Impact may have been mitigated by the way the component was incorporated in the product or in your product deployment. The best way to determine this is to examine the vendor site to see if they mention it, or to ask the vendor, “Are you impacted by CVE-YYYY-?” Don’t ask vendors about unannounced vulnerabilities because most vendors, contrary to popular belief, get the information along with everyone else. They will need details to determine if they are impacted and to provide a solution.
In all cases, the ability to track CVEs and find component information can be used if we need to worry about a particular vulnerability. This information relieves some of the stress as we wait for the details. Gone are the easy days of identifying the vulnerable program. We live in a time where we are forced to ask, ‘‘What’s in your software?’’