I have described some of the logical problems with vulnerability scanners. False positive and false negative errors. Additionally, the worry that problems exist but our tool hasn't even tried looking for them.
Let's try to make this practical!
I'm working on a consulting job as a sub-sub-contractor on a U.S. Department of Defense project. I'm building self-installing Linux media that can then harden itself to meet DoD requirements.
Let me show you how non-DoD projects can also take advantage of this technology.
A U.S. Department of Defense information system must comply with a STIG. That stands for "Security Technology Implementation Guide". There are STIGs for various operating systems, for database systems, web servers, DNS servers, routers and other network gear, and so on. You can browse the STIG documents here. DISA (or the Defense Information Systems Agency) manages these.
You can download manual STIG archives from the public site. Each contains an XML file which you can view with a web browser.
A manual STIG is a long list of rules. Each rule indicates its severity. Then the "Discussion" section explains what the rule tests and why it matters. Next, the "Check Content" describes how to test whether the system satisfies this rules. Finally, the "Fix Text" explains how to fix it. That could involve running commands, modifying configuration files, or adding or deleting software packages.
Automation with SCAP
You may have heard of SCAP, or the Security Content Automation Protocol.
However, it's much more than just a protocol. It's a method for managing security policy compliance. SCAP uses several specific standards. If you've taken Learning Tree's System and Network Security Training or studied for certifications like CompTIA Security+ or CASP, or (ISC)2 CISSP, you will have heard of some of this.
SCAP components include, among others:
- CVE or Common Vulnerabilities and Exposures
- CPE or Common Platform Enumeration
- CCE or Common Configuration Enumeration
- CVSS or Common Vulnerability Scoring System
- OVAL or Open Vulnerability and Assessment Language
- OCIL or Open Checklist Interactive Language
- XCCDF or Extensible Configuration Checklist Description Format
To simplify, we need:
- Common terminology, a dictionary (CVE, CPE, and CCE)
- A "how bad is it?" measurement (CVSS)
- A common language so tools can interact (OVAL and OCIL)
- An interface for our tool (XCCDF)
Making SCAP Practical
We need the SCAP data, but it's just data. In addition, we also need a tool.
Enter OpenSCAP. It can use a SCAP Security Guide, a collection of SCAP data files, to evaluate. What's more, it can automatically remediate the system. It can correct the problems that it finds. And on top of that, OpenSCAP is totally free. Learn more on the project's web site.
Red Hat Enterprise Linux includes OpenSCAP. Let's see what it contains. The SCAP content provides six files per platform:
Let's see what the RHEL 7 one can do. Use the
oscap command, and refer it to the XCCDF file:
There's the DISA STIG, which is what I need for my project! Furthermore, profiles for PCI-DSS, HIPAA, the FBI's Criminal Justice Information Services security policy, the general U.S. Government Configuration Baseline, and more! The PCI-DSS and HIPAA profiles are very useful for other non-DoD consulting clients of mine.
To evaluate a RHEL 7 system, and then automatically mitigate what it has found, use the following syntax. The command is
oscap. And as I mentioned, you tell it to operate on the XCCDF file:
# oscap xccdf eval --remediate --profile stig-rhel7-disa \
--report /root/oscap-remediating.html \
That creates an HTML report in root's home directory, and then you view it with a browser.
Where Else Can We Run OpenSCAP?
OpenSCAP is included with Ubuntu. What's more, you can build it from source on Debian. However, things diverge here.
First, here is the result of building the SCAP Security Guide on Debian:
There is SCAP content for Debian 8, although not 9 or later. Also the Department of Energy's Scientific Linux (SL 6 and SL 7), and two versions of Ubuntu.
DISA has defined a STIG for Ubuntu 16.04, so let's see what OpenSCAP can do for us:
OpenSCAP has no STIG profile for Ubuntu. Why?
The RHEL 7 SCAP content was created with a lot of help from Red Hat, and then ported to CentOS. It's in Red Hat's interest to do this work.
Canonical has not (yet) built a STIG profile for Ubuntu. However, there are SCAP profiles for both Ubuntu and Debian for 4 levels of the ANSSI DAT-NT28 security standard. ANSSI is Agence nationale de la securite des systemes d'information, the National Cybersecurity Agency of France.
So, yes, OpenSCAP does run on Ubuntu and Debian, and can both evaluate and automatically mitigate. But not to a standard you probably use.
Even if you don't use OpenSCAP to harden a system, you can learn a lot from its evaluation. We follow best practices in Learning Tree's Linux server course, but it's helpful to see someone else's viewpoint on this. Even if it's the viewpoint of an automated process!
Back to RHEL, How Good Is OpenSCAP?
It's not perfect, but as I explained last week, none of these tools are. It is very helpful.
If you simply install RHEL 7, it only passes about 33% of the STIG tests using the tool we have for this project.
OpenSCAP can improve that to about 86% with one command. Then you write scripts to fix the remaining issues.
However, OpenSCAP outperforms what we got from DoD in some ways. For example, it notices if you have not yet installed anti-malware scanning software. The DoD tool doesn't mention that at all.
We will need to have everything fixed when DISA comes to audit the systems.
If you've taken Learning Tree's Linux Administration and Support Training }you know how to add packages and even build OpenSCAP from source if needed.
Experiment with it in eval-only mode. Leave off the
--remediate option unless you're testing with a virtual machine. If you're using Ubuntu or Debian, try that French government standard. You might find one of its profiles useful.[:]