The list of security vulnerabilities is constantly growing, and ensuring that your systems are not vulnerable to currently known security flaws is a continuous process.
Security researchers are reporting their findings on a daily basis; new weaknesses in software products are constantly being identified either using automated tools designed to uncover security flaws, or while performing code reviews. [1]
Once an exploit [2] [3] [4] for a particular flaw is published, it becomes easy for an attacker to take advantage of the flaw and cause problems such as data leaks or arbitrary code execution. At the same time, known vulnerabilities are also commonly shared in exploit databases.
Any organization wishing to protect itself against these attacks must set up a proper and sustainable vulnerability management policy. A good policy satisfies multiple key concepts, which include:
Detailed knowledge of the underlying computer infrastructure
Continuous delivery of certified information about currently known security flaws and their impact
Quick identification of the current security status of each system (security analysis)
Prompt reaction — capability to instantly perform corrective operations where necessary (remedial action)
Possibility to perform security analysis in automated,unattended way on regular basis, regardless of the infrastructure’s complexity
Availability of proper software tools to carry out these tasks with minimal effort while preventing or at least minimizing outage periods
Table #1 Sample result of a single vulnerability assessment run on a particular computer environment |
||||
---|---|---|---|---|
System Identifier hostname or IP address | ||||
Vulnerability ID | Package | Impact | Result | Alternative Name |
CVE-2014-0160 | openssl | High | Not Vulnerable | Heartbleed |
CVE-2014-6271 | bash | Urgent | Not Vulnerable | Shellshock |
CVE-2014-7169 | bash | High | Not Vulnerable | Shellshock |
CVE-2015-0235 | glibc | Urgent | Vulnerable | GHOST |
CVE-2015-3456 | Various | High | Vulnerable | VENOM |
CVE-2015-0204 | openssl | Medium | Not Vulnerable | FREAK |
CVE-2015-4000 | Various | Medium | Vulnerable | Logjam |
… |
Today’s software is often composed of multiple components rather than being monolithic, and it is important to note that security flaws typically do not impact an entire infrastructure, but only relatively small parts of it – and the severity also often varies with specific usage of the affected component. This means it’s crucial to properly analyze the entire environment as well as individual components, so that vulnerabilities can be properly assessed and a proper remediation strategy can be developed for each flaw.
Many software vendors are taking security of their provided solutions very seriously, and publish security errata as well as notifications advising users to update once a fix is available. A few examples include Debian, Gentoo, Mageia, Red Hat, SUSE, and Ubuntu. These advisories are typically published in the form of RSS feeds or OVAL documents (Red Hat, SUSE), which are quickly applicable in many vulnerability assessment solutions including OpenSCAP. Security advisories being provided directly by software vendors are numerous. They are:
Software tools for performing vulnerability assessment are the best candidates for establishing a proper vulnerability management policy. These tools allow you to perform audits in a completely automated, unattended way on a regular basis. Security analysis performed in automated way ensures that the immediate security state of a system will be inspected without delays. Since information about the flaw’s impact usually included in the provided security advisories, it is possible during the initial scan to immediately report which components need updating and how urgent an update is. If multiple vulnerabilities are found at the same time, the scanner can build a prioritized list of updates, and then pass this information to other tools which then perform corrective operations, starting with the most exposed parts of the system [6].
Previously we mentioned the importance of detailed knowledge about your computer environment when creating and implementing vulnerability assessment strategies. Most environments are composed of many different applications and systems, making them difficult to assess manually — a manual analysis would take valuable time and potentially leave systems in a vulnerable state while it is being completed. In order to facilitate analysis, software vendors produce Common Platform Enumeration (CPE) tags for their solutions. CPEs provide a unique, unambiguous and standard way of identifying specific software products. Vulnerability assessment tools like OpenSCAP can then compare these tags with tags retrieved from vulnerability databases, and quickly identify flaws present in your environment.
The following table demonstrates how various tools from the OpenSCAP ecosystem can be utilized to assist in establishing and maintaining of the sustainable vulnerability assessment process. Refer to the Tools page for a more detailed description and usage examples for the various tools from the suite.
Performing vulnerability assessment on newly installed Red Hat Enterprise Linux 6 Update 7 system using Red Hat’s OVAL content
Performing vulnerability assessment on newly installed Red Hat Enterprise Linux 6 Update 7 system using the SCAP Workbench tool using the Red Hat’s XCCDF content retrieved using the following commands:
# wget http://www.redhat.com/security/data/metrics/com.redhat.rhsa-all.xccdf.xml
# wget http://www.redhat.com/security/data/oval/com.redhat.rhsa-all.xml
Performing vulnerability assessment on newly installed openSUSE 13.2 system using SUSE’s OVAL content
Snippet from an OVAL report created from an XML results file using the following command:
# oscap oval generate report /tmp/results.xml >/tmp/report.html