A word of warning: This article contains an above average number of acronyms. This has nothing to do with the fact that I like to save time while I’m writing articles; it has more to do with the fact that the IT world loves abbreviations and that this trend becomes more extreme the more academic and official the topic. And, if government organizations have their say in defining standards, things start to get really serious – but more on that later. Whatever happens, just remember, I warned you.

If you are interested in configuring a computer system to ensure basic security standards and you live in Germany, as I do, you begin with the basic IT protection standards issued by the German federal office for security in information technology (BSI). How you proceed will be determined by the laws and regulations of your country and the industry in which you work.

ISO Security

No matter where you begin, a common endpoint often is applying for ISO 27001 certification. A variety of tools can help you investigate your own IT landscape and implement corresponding measures. A popular tool in the open source world for this task is Verinice by SerNet GmbH, Göttingen, Germany. Verinice is an Information Security Management System (ISMS) that helps you work through the various steps needed to meet ISO 27001 compliance. Because this goes much further than configuring IT systems, you need to watch out for a variety of individual requirements, so having a tool that helps you do so is worth its weight in gold.

Even though the many local standards for basic IT protection are correct and meaningful, implementing them is way over the top if you are not interested in gaining the corresponding certification for your environment. Instead, you might simply want to ensure that your own IT systems have been installed and configured in a secure way.

For this type of environment, you will probably want to use the popular security guides or checklist issued by the NSA or the Defense Information Systems Agency (DISA). The DISA provides a kind of de facto standard in the form of the Unix Security Technical Implementation Guide (STIG) if you are looking into the secure configuration of Unix and Linux systems. With the help of these very detailed checklists, administrators can investigate their own systems for correct and secure configuration, starting with correct partitioning of the hard disk through correct assignment of permissions for individual system files.

These System Readiness Review (SRR) scripts even let you process the checklist automatically. Using this approach, whole legions of administrators have battled their way through their systems in a constant search for possible incorrect configurations. Attentive readers will probably already have discovered the downside here: This approach doesn’t scale particularly well because IT systems change constantly and are thus in a dynamic state.

Issuing new guidelines and configuration recommendations involves an enormous amount of effort. Thus, it comes as little surprise that, when Red Hat Enterprise Linux 6 was released, the currently available DISA STIGs were still based on RHEL4. Administrators will tend to work through the checklist manually in a process that is obviously prone to error, doesn’t scale well, and thus becomes impossible.

DISA recognized this problem and published a document called “STIGs, SCAP, and Data Metrics” just a year ago, admitting that their procedure might pose some “maintenance challenges.” Early in 2010, DISA then released a FAQ clarifying that in the future its own guidelines would be based entirely on the use of the Security Content Automation Protocol (SCAP) by the National Institute of Standards and Technology (NIST). SCAP encompasses various standard methods for describing system configurations and security management. Assuming you have the right tools, it is possible to read these XML-based files and compare them with the local system configuration.

In the Jungle

SCAP encompasses standards such as CVE, CCE, CPE, CVSS, OVAL, and XCCDF. The latter two standards in particular play an important role. The Extensible Configuration Checklist Description Format (XCCDF) helps define guidelines for the secure configuration of IT systems. Various tests are required to verify them, and you can define how they run using the Open Vulnerability and Assessment Language (OVAL).

OVAL definitions can be deployed on their own; however, XCCDF makes it easier to define mandatory standards, say, for a meaningful configuration of a desktop system or a web server running on Red Hat Enterprise Linux. Red Hat and various other Linux distributions started providing their own patch definitions in OVAL format a while back. By deploying corresponding scanners, you can easily check the system to discover whether all the existing patches have been installed.

OpenSCAP is an open source variant of this type of scanner. OpenSCAP can easily handle the SCAP standards and generate neat, HTML-based reports. An RPM package for the tool has been available since Fedora 14 and RHEL6, and it is available as part of the standard package with both of these distributions. Additionally, Fedora also offers a package called openscap-content that contains both OVAL definitions for the system and a prebuilt profile by called “F14-Default,” which references a subset of all available OVAL definitions in order to validate the system. The command for doing this is as follows:

oscap xccdf eval --profile "F14-Default" --results fedora.xml --report fedora.html /usr/share/openscap/scap-xccdf.xml

The HTML report this produces can be viewed in a web browser. That said, you should only use the XCCDF profile file here for test purposes. However, Linux distributors are not being forthcoming with profiles thus far and rely on content providers such as DISA or NIST. Instead, distributors tend to provide a collection of security messages for their own software packages in OVAL format. If you have Red Hat Enterprise Linux, you can download these online.

The oscap --id option also gives you the ability to search a system for a specific bug fix. For example, to check to see whether the Advisory “RHSA-2012:0017: libxml2 security update” has been installed on your system, use:

oscap oval eval --id oval:com.redhat.rhsa:def:20120017 com.redhat.rhsa-all.xml

Of course, the OpenSCAP scanner will only provide meaningful results if the content you want it to process is correct and up to date. For example, neither DISA nor NIST will give you appropriate profiles for Red Hat Enterprise Linux 6; the latest profiles are still based on RHEL5. Red Hat and other distributions will provide their own OVAL definitions; however, this process does not give you the system profile, it only lets you investigate patch versions.

To avoid relying on the well-known content providers, the community will eventually be forced to develop and release its own XCCDF profiles. Linux distributors will not be able to provide these profiles themselves; this didn’t work for virus or IDS signatures either.

The OpenSCAP project takes an initial step in the right direction, and the first (unofficial) profiles for RHEL5, RHEL6, Fedora, and Solaris are available online. It would be desirable for the community to pick up on these beginnings and provide more profiles for various server and desktop installations.

If you are not tired of this acronym marathon and still want to experiment with the various SCAP standards, try out the eSCAPe Java tool. It gives you a rapid option for creating your own content files, and it lets you decide what they look like and which tests they perform.