SCAP: computer security for the rest of us

No readers like this yet.
A maze

Opensource.com

I'm setting up a new computer. I get through the registration screens, install my software, change my wallpaper, and everything's working fine. I'm left, though, with a lingering, uneasy feeling: I don't know if this machine is secure. I'm a computer guy, so I know how to set up strong passwords and firewalls, but I'm still not sure if I've done everything right. I turn to my vendor, who has hopefully published a hardening guide. If I'm very enthusiastic, I might even follow the NSA's Security and Network Analysis Center Guides. If I do any of these things, I'm already being more diligent that 95% of users out there. And that's a problem.

Personal responsibility and its sworn enemy, "I have something better to do."

A bike wheel locked to a bike rack.
When users are responsible for their own security, things go wrong. (Photo courtesy of billselak on flickr, licensed CC-BY-ND)

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

A snowflake.
This, for instance, is my web server. (Photo courtesy of CaptPiper on flickr, licensed CC-BY-NC)

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.

User profile image.
I'm the Chief Strategist for Red Hat's US Public Sector group, where I work with systems integrators and government agencies to encourage the use of open source software in government. I'm a founder of Open Source for America, one of Federal Computer Week's Fed 100 for 2010, and I've been voted one of the FedScoop 50 for industry leadership.

7 Comments

Great article. Thanks for introducing this in a very nice way. How can one contribute to the OpenSCAP project? I'm not an expert but I would like to help in whatever way I can.

Yes! You can find information on how to help here: http://www.open-scap.org/page/Contribute

The real fault here lies with lazy ISPs and network admins. You can't expect John Doe to know or care anything about security. However, the people we pay to be the IT guys aren't doing the job either. Why is it that every computer in the world needs a public address? Most ISPs have a policy forbidding you from running a server anyway. There is no reason that every cable modem and DSL modem made shouldn't also have the ability to do NAT. With a default setting of having no o pen ports, you eliminate 75+% of the problems. Another action that needs to be done is quarantining infected computers until they are fixed. I can't drive a car that sprays oil all over the road, why should we let computers spew filth on the internet?

"what's really needed is a set of cross-platform and open source tools to drive adoption"

How about http://www.g2-inc.com/escape? I've been digging around in the guts of SCAP for a month or so and stumbled across that SCAP editor. Its GPLv3 and Java based.

It's not the be all end all of editors, but it was a decent start. I had issues with pulling a full SCAP stream (XCCDF, OVAL, etc) together with it. But I did get very close! I have a feeling that could also be content related since I was digging around in several sources to try to build something. Could use a bit of doco on default files it's looking for too. Had to dig through stack traces to determine file names and locations.

@Gary Scarborough: I'm for better firewall management of course, but Firewalls and NAT are not the same thing. Firewalls are good. NAT is bad. The proliferation of NAT as you describe violates one of the core principles of the internet (end-to-end connectivity) and make the internet a much more closed system. Why shouldn't I be able to run a server from my house? Once IPv6 becomes mainstream, the need for the ugly hack that is NAT will be greatly alleviated.

Great news!

There already exists a neat GUI for developing SCAP Content. It has been developed by The MITRE Corporation (who have also developed most of the individual standards that SCAP encompasses) and it is open sourse. It can be found here:

http://sourceforge.net/projects/rectracker/

Steve Boczenowski

Thanks for the very clear explanation of these complex topics. Very helpful.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.