Vulnerability Management

All software used on your organization’s hardware assets need to be searched for common weaknesses (CWE) and common vulnerabilities (CVE).  For primary packages acquired in whole these searches are done after the product has been released. However, for organic and customized software packages these searches should be performed during development and prior to release. Tools like Common vulnerability and Exposures (CVE), Common Vulnerability Scoring System (CVSS), and Open Vulnerability and Assessment Language (OVAL) are key to identifying and managing your organization’s vulnerabilities effectively in a vendor independent manner that enable automation.

The basic process for addressing unexpected security-relevant weaknesses in any self-developed, commercial or open source software used in any organization starts with the discovery of a security-relevant weakness in that software that leaves the software vulnerable. The discoverer could be the software creator, an outside researcher, or a software user. For commercial and open source software the next step is usually for the software creator to be informed of the potential vulnerability by the discoverer to confirm it is an actual vulnerability, start evaluating it, and then look for potential resolutions.

Eventually, a fix or possible workaround to the vulnerabilities are released to software customers and often, the public. This is usually done via a security advisory, errata, or bulletin from the software creator and/or by the researcher who discovered the vulnerability. More and more those advisories include CVE identifiers, CVSS base scores, and OVAL definitions as well as being formatted in accordance to the Common Vulnerability Reporting Format (CVRF). Subsequently, the community of security tool developers that checks for security vulnerabilities in deployed software starts the task of figuring out how to check for this new public security vulnerability and its fixes. Where OVAL definitions are included in the public advisory the tools can start the checking immediately.

Tool developers that don’t support ingesting OVAL definitions have to start their creation of new checks using the narrative from the security advisory or bulletin. In short order, most security assessment tools will be updated to look for and report systems status regarding this new vulnerability. Exactly how each tool checks for the vulnerability and its possible mitigations are usually not known to the tool users.

Within the U.S. Department of Defense (DoD), the priority of vulnerabilities is conveyed to the operational users and system administrators through their Information Assurance Vulnerability Management (IAVM) system which consists of Information Assurance Vulnerability Alerts (IAVAs), Information Assurance Vulnerability Bulletins (IAVBs) and Technical Alerts (TAs). The mapping between IAVMs and CVE Identifiers is available from the Information Assurance Support Environment (IASE) group at Defense Information Systems Agency (DISA).

For more information about dealing with potential vulnerabilities in self-developed software as well as software developed for your organization see Application Security and Software Assurance.