SCAP: computer security for the rest of us

Software vendors makes users responsible for secure configurations. They have to. If Red Hat shipped with every recommended security configuration change already in place, users would mutiny. They'd resent all the additional work required to make their system useful. Choosing default configurations that are secure enough, but not so secure that they annoy users is a delicate balance, and vendors will never get it exactly right. So the responsibility falls to the users.

Unless the user is very security-conscious, they're not going to do anything with that responsibility. This isn't their fault, really. It's hard to find the "right" guidance for your particular system. Even if you find the appropriate guidance, you'll have to make all the recommended changes by hand. The whole process is incomprehensibly tedious, and you'll almost certainly do it wrong.

Millions of badly configured systems are connected to the Internet. They're targets for botnets, hackers, and viruses. The Confickr worm demonstrated how dire the problem can be — and nobody feels this pain more than the Federal government. So the Office of Management and Budget (OMB) had to do something about it.

Here come the acronyms

The Federal Desktop Core Configuration (FDCC) was born. Based on the good work already performed by the Air Force, FDCC is a set of OMB-mandated configuration changes for every Windows desktop in the Federal government. OMB knew they couldn't solve the problem with a strongly-worded memo, though. The guidance requires hundreds of configuration items to be checked. Asking humans to methodically check each item on millions of machines is error-prone, impractical and cruel. So OMB asked the National Institute of Standards and Technology (NIST) to make FDCC easy.

NIST offered the "Security Content Automation Protocol", or SCAP. SCAP (pronounced S-cap) is composed of an alphabet soup of specifications that NIST had already been working with: CVE, CCS, OVAL, XCCDF, and many more. With SCAP, you can describe a security configuration policy in a way that computers can understand. So instead of requiring a human to read through dozens of pages of technical documentation, a computer can read the instructions and tell you what's right and what's wrong with your system.

If you're at all like me, you read that and said to yourself, "Why didn't anyone think of this before?" This reaction is the hallmark of a good idea. We can now describe a "secure" configuration unambiguously, and then feed that description to a tool which will tell us if we've done everything properly. That's very nearly a perfect solution.

Wisely, the FDCC program decided it was not NIST's best and highest use to decide what these configurations should be. Instead, vendors like Red Hat collaborate with NIST, NSA, and other government bodies, and the vendor publishes the SCAP content on their website. These SCAP documents can be pulled down by SCAP tools on my machine which then verify that the machine meets the standard. It's like magic. NIST has pointers to all kinds of SCAP content at the National Checklist Program website.

Every system is a beautiful and unique snowflake

Cleverly, the SCAP content (technically, an XCCDF document) lets you define different "profiles" that cover different kinds of scenarios. Using these profiles, an organization can refine the baseline SCAP document with their own changes. You could define standards for a workstation, for a web server, a database, and so on. You could get even more specific: a "low security" webserver, a "high security" database, etc.

This flexibility allows an organization to pull down the baseline SCAP from the vendor, craft that to a company standard, the company standard to a department standard, department to project, and so on, without losing track of the original recommendations. If the baseline is updated, it's a relatively simple matter to push that change down the chain.

SCAP can eat itself

When an SCAP tool performs an audit, it can spit out an XCCDF report. This is great, because well-structured audit reports can be stored, aggregated, and analyzed by a central authority. This is much better than the current approach, which forces a human to go through reams of mind-numbingly bad prose:

[gunnar@willa ~]$ rpm -Va
missing     /var/lib/nfs/statd/sm (Permission denied)
missing     /var/lib/nfs/statd/sm.bak (Permission denied)
..?......    /usr/bin/chfn
..?......    /usr/bin/chsh

..and so on, forever. You can even imagine a tool vendor offering sophisticated audit and reporting tools that measure your relative safety over time. Folks like McAfee and Tripwire are already doing this. Obviously, this is as useful to the home user as it is to corporate users.

With all this promise, the trick for SCAP now is widespread adoption. There's a danger that SCAP could be consigned to the world of obscure government security standards, even though it's so obviously useful. That would be a catastrophe. If SCAP content is difficult to use, or difficult to improve or create, the mainstream user and administrator won't bother. So how can we ensure widespread SCAP adoption?

Make It ubiquitous and invisible

The target is the user who can't be bothered to read through a security guide. They're going to manage security by exception, assuming that everything's fine until a popup on their screen tells them that something's wrong. This is as it should be. If we rely on the average user's attentiveness to make a security tool useful, we'll be disappointed.

Operating systems should ship with basic SCAP auditing tools. SCAP-based audits and reporting should happen in the background. Tools should download the SCAP content automatically, by default. End-user SCAP tools should let the user express their security preferences, and then disappear. The user should only be aware the tool is running when it needs them to do something.

Make it easy to create

Right now, SCAP content must be created by hand. It looks like this:

<Rule id="UNIX-STIG-3-2-9-8" selected="false" weight="10.0">
 <title xml:lang="en">Manual Page File Permissions</title>
 <description xml:lang="en">Manual page file is more permissive than 644.</description>
 <reference>
 <dc:type>DISA PDI Number</dc:type>
 <dc:source>GEN001280</dc:source>
 </reference>
</Rule>
<Rule id="UNIX-STIG-3-2-9-9" selected="false" weight="10.0">
 <title xml:lang="en">Library File Permissions</title>
 <description xml:lang="en">Library file is more permissive than 755.</description>
 <reference>
 <dc:type>DISA PDI Number</dc:type>
 <dc:source>GEN001300</dc:source>
 </reference>
</Rule>

The sooner we have a market for GUI tools that turn this into checkboxes, pulldowns, and radio buttons, the better. The easier it is for a security officer or novice home user to describe their preferences, the more likely it is that the standard will be adopted. There are already a number of proprietary tools that know what to do with XCCDF and SCAP, but what's really needed is a set of cross-platform and open source tools to drive adoption. The tools could even be web-based — anything to encourage folks to experiment with the standard in their organization.

Good SCAP should be shared

With the proper creation tools in place, it should be a simple matter to help SCAP content creators find each other. They can compare notes, work out best practices, and build on each other's successes. NIST already has a great start in its SCAP Community and National Checklist Program websites.

A meta-note on the importance of process

By defining a standard in collaboration with vendors, and then mandating government use of that standard, NIST, DOD, and OMB have not only solved a pernicious problem, but created a market for tools that surround the standard. Everyone is rightfully wary of government intervention and overreach, but I think this is the correct approach to a "commons" problem. No single security tool vendor or operating system vendor can solve this problem. It takes the collective purchasing power of something as large as the US government to drive adoption of a standard like this.

And rather than throw their weight around, these government folks decided to use their "soft power," and ensured that the tools and protocols were so useful that a vendor would have to be crazy to not adopt the standard in their own products.

Obviously, this SCAP movement would never get off the ground if the government handed a bunch of configuration guidance to its users without consulting the vendor of the software in question. This is what happens already, and it doesn't work. The DOD STIGs, the IAVAs, the various civilian baselines — they all conflict with each other, they're out of date, and sometimes contradict the guidance provided by the vendor. Once everyone is speaking a common language like SCAP,  it will be much easier to arrive at consensus on reporting and remediation strategies.

So what can we do?

If you're read this far, you're probably sold on the value of SCAP. There are a few ways to get involved, and move this standard forward.

First, check out NIST's SCAP website. There's a lot of great content there, and there are a bunch of mailing lists you can join.

Next, the OpenSCAP project would welcome your help. It's a low-level library that handles some of the rude mechanics of the SCAP protocol. There's a wonderland of opportunity for folks who want to create a GUI, a web interface, or otherwise build on the excellent work that's already been done. The secstate project is a good place to start.

Finally, you can attend (or at least read the proceedings of) the SCAP conference that NIST is holding in Baltimore on September 27-28th. I'll see you there.