Security Content Automation Protocol (SCAP)

What SCAP Is

Our vulnerability scanners need to download information, or possibly interface with other systems within the network, and so they need to understand what that language looks like. That's where SCAP comes into place.

If we have a vulnerability scanner — let's say in this example right here, this is our vulnerability scanner, and we have vulnerability scanning software installed on this server — what it needs to do is download information. Information about different hardware that's out there, different operating systems that are out there. It needs to know about different vulnerabilities, different configurations. It needs to know how to interface with other devices on this network, and know how to do reporting. That's where SCAP comes into place. It allows functionality to our vulnerability scanner by providing a bunch of different types of information to that vulnerability scanner.

SCAP stands for Security Content Automation Protocol. Even though the technical term is S-C-A-P, a lot of us just call this SCAP. SCAP isn't just one protocol or one set of formats. It's actually a bunch of stuff all rolled into one. That way, when we refer to SCAP, we're just referring to all of these different formats and these different ways that we can structure data to pass data back and forth. SCAP is put together by NIST. And SCAP is all these different specifications we see here on the right-hand side, where we can specify things like our common configuration enumeration or common platform enumeration, CPE and CCE.

XML

One of the first things that SCAP defines is just how most of the data is going to be structured, and these specifications are structured in Extensible Markup Language, or XML. XML is a type of file and a type of structure, and really what XML is used for is to define and store data, so it's in a sharable state. It's a way that we can share data back and forth.

Let's give an example of this. Let's say two servers want to exchange information. Server one could format it in XML format and then send it to server 2. Server 2 then can understand what that format looks like and be able to interpret whatever that data is that's being sent back and forth. Or where we use it in a lot of cases, like what we're talking about here, is both these servers can download the same set of information, this XML document, and then be able to ingest it or use it on these two different systems.

XML is what's called a markup language. So we mark it up. This is the markup here, and we're marking up the data, or defining what this data is. At a very, very basic level, this is what XML looks like. Essentially, what we are doing is we're defining an element. We call out what that element is, we give it a value, whatever that value is, and then we close out that element.

Here's a little deeper look into what XML could look like. We have a root element right here, in which case then we close out that root element. From that root element, we have a child element. In fact, we have child one element and then child two element. And then within that we have some sort of subchild element. So within this is where our values are going.

Let's just say that we have some sort of checklist. We're going to call out that this is a checklist, then we close out the checklist at the end here. In between these two items right here is our checklist. Our checklist in this one is very simple. We've just defined two items within our checklist. The first item maybe is our password length. We're checking the password length, and this gives a little description of it. So we see that it's a description. The description is that there's some sort of minimum length of password, and we're defining the value of that minimum length as being 10. Or maybe we want to implement some sort of password complexity. Then we say, is password complexity on? So that's a description. This is a yes or no, or true or false, and so the value of this we want to be true. So this is our checklist that we've created using an XML format.

Now that was a very simplistic example of this. This is a little more complex example where we see quite a bit more detail in here, but the same structure really exists as what we just covered.

The Components of SCAP

Here I'm on the NIST website looking at SCAP. As I mentioned before, SCAP is actually a lot of other components all rolled up into this one title of SCAP. So we've got a protocol that's associated with it. We've got tools, languages — we're going to take a deeper dive into these languages and what these languages look like. We also got identification schemes, so we're going to take a deeper dive into that, and also metrics.

From the identification schemes in here, we see the common configuration enumeration. We see the common platform enumeration, and we see the common vulnerabilities and exposures. We've already covered that in a prior lesson where we saw CCE, CPE and CVE. We also have these metrics which I covered in prior lessons as well: the common vulnerability scoring system and the common configuration scoring system.

Just a reminder that the common platform enumeration system out there identifies different hardware, operating systems and software, whereas the common configuration enumeration identifies configuration of that hardware, operating systems and software, and also the common vulnerabilities and exposures list identifies vulnerabilities of certain hardware, operating systems and software. We also have those metrics, such as the common configuration scoring system, which lets us know how urgent or how much of an issue certain configurations can be. We also have the common vulnerability scoring system, which lets us know how urgent or how concerning certain vulnerabilities are.

So back to SCAP here. When we scroll down here we see that it identifies these different schemes here, such as the common configuration enumeration. So this is kind of a subset of SCAP. Same thing with common platform enumeration. Same thing with common vulnerabilities and exposures, the CVE, and those metrics we talked about, the CVSS and the CCSS. But also we see that it identifies different languages here. So let's identify some of these different languages and how it plays a role in SCAP and finding vulnerabilities on our network.

Asset Report Format (ARF)

ARF, or asset report format. Not a surprise, this is all just about reporting of assets. So what does that look like? We may have different systems within our network that need to share information about assets and communicate back and forth about these different assets. So that's what it's all about, is just reporting of assets.

NIST has a document outlining the specifications of asset reporting format, or ARF. So let's take a look at what it has to say. In this document, it shows a diagram of a use case for ARF. And what we see here is we have some sort of sensor manager. A sensor manager is those that's going and detecting things out there and determining what are the different systems out there. So it's identified several assets on the network. We also maybe have some sort of asset manager, things that we're tracking all of these assets on. We've also want to do some risk analysis, so we've got a machine over here doing some risk analysis. And then we've got in the middle of all this some sort of task manager. So essentially this task manager is taking this reporting of all these different assets and coordinating it amongst all of these machines. And we can do that because we have a certain format in which we track all of these different assets. And this document also then outlines the format and how it's going to report on all these different assets. And not surprisingly, it's all in XML.

Enumerations Versus Languages

Not only do we have this asset reporting format, but there's two others we should look at. We should look at OVAL, open vulnerability and assessment language, and OCIL, open checklist interactive language.

So what is the big difference between enumeration — things like CPE, CCE, CVE — and languages? Well, when it comes to enumeration, what we're doing is we're identifying and classifying different components. So whether it's a piece of hardware, we give it an ID so we can represent that hardware, or maybe it's the operating system and we give it an ID to represent the operating system. Versus language is a communication that happens back and forth, like a reporting language or asset reporting language. It's a way that we can communicate assets back and forth. A couple other languages that we have is OVAL, the open vulnerability and assessment language, and OCIL, the open checklist interaction language.

OVAL

Let's really take a bigger look into this OVAL and what open vulnerability and assessment language looks like. Let's say we have a vulnerability scanner set up on this server right here. What it's going to need to do is check the hardware, the operating system, and the software to see what it is and if there's any vulnerabilities with that. It also needs to check the configurations of them to see if the configurations are off. Well, that communication that happens, happens through this assessment language.

This OVAL, not surprisingly, is set up as an XML file as well. And what it does is it has four different components to it. The first one is definition, which is just like a description so we can understand what it's doing, what it's actually testing. Then we have the test. What is it that it's testing, and a specific object of that test? What is the specific configuration that it's testing, and what state is it looking for? Is it looking for true or false, or some sort of number? What is the state that it's looking for?

Here's an example of one of those OVAL XML files. And what we see if we go through here, we see the definition, what it is that it's testing, and it gives some information and description around that. It also has the test part of it, of what it's testing, and the object that it's testing, and the state that it's looking for. So this is just one example of an OVAL file.

Another example here is from the MITRE site, mitre.org. And we see here that there are several definitions. This is much more complex, and what it's doing is it's looking for what is the platform this is on. Is it Windows 7, Server 2008, Windows 8? So it's checking against those different systems, and what it's testing. So here's what it's testing, the specific object that it's testing, and the state that it's looking for.

So essentially what this is, the open vulnerability and assessment language, is a way for the server to query or ask for this information from the client and then get information back from it. So that way it can understand what the settings and configuration and vulnerabilities are of that individual machine.

OCIL

Now OVAL really does automated testing. So it's a way to automatically be able to check a machine. But not all of our security compliance really is something that you can automate, that you can check, and that's where an open checklist interactive language, or OCIL, comes into play.

Let's say we're dealing with a particular server and we want to make sure that it's secured. We want to make sure it's secured in a room that has air conditioning, has some sort of power backup, has some sort of door access so that way not everybody can get into it. Well, we don't necessarily know where the server is at from a physical standpoint just by doing an automated query. So in this case right here, we need some sort of checklist that we go through.

So essentially open checklist interactive language, or OCIL, is a way that we can have a similar type of structure to it, an XML document, but we specify things like equipment is locked behind closed doors, or equipment has adequate battery backup, or battery backup has been tested in the last 90 days — something that we could manually go through and make sure yes, we've done these things. Now OCIL is not used as much as our automated testing, but it's something that we could use because it's a standardized format that's out there. So we can download these and utilize them.

XCCDF

Now enumeration is going to count what we have, or understand what we have on our network and what the configurations are and also what the vulnerabilities are, and standards are going to hold each of these items to a different standard. But we do have different standards for our different sets of items. We might have some systems that we have a very high standard for that we need to really protect, where other systems are maybe just publicly accessible, and some assets that are publicly accessible we have a lower standard for those. And so really what we need to do is define these certain profiles or certain groups right here, and then what are the security parameters we're going to put around those groups. That's where the extensible configuration checklist description format, or XCCDF, comes into play.

In this case right here, what we do is we define certain profiles and we attach certain assets to these profiles, and then we can attach the standards to those profiles. You can think of XCCDF as being our policies, what we're applying to certain machines, what standards we're holding them to. And so what we have here is we have a group of machines here that we want to put in a profile set, and as part of that profile set, then we will apply those policies to those profile sets.

So what does this look like in action? Well, let's say there is a grouping of machines here and we're going to have this as a high security profile. We'll create a high-security profile. So we need to query certain information from them. We're going to use OVAL to be able to query certain information from these machines to make sure that they are in compliance with our policies. So what we're doing is we're creating our policies with this format, and then we're querying to make sure that they're complying with that format using OVAL. Or perhaps we're using OCIL, where we go in and do some manual checks on these machines to make sure that they're in compliance.

So here's an example of an XCCDF document, the XML file. And so as you can see, it's structured a little differently, and we see some pass/fails here of what's going to be acceptable and what's not acceptable. So it's looking for specific things on the system. And it's also referencing a lot of OVAL documents here, because the OVAL is going to be what's going to be doing the querying of the machine to understand what the settings are for this machine. So this is just a quick example of an XCCDF XML document.

How It All Works Together

So your vulnerability scanning most likely is using some sort of SCAP on the back end. It needs to know of the vulnerabilities and what your standards are and all sorts of information in order to be able to understand what your network is and where the vulnerabilities are.

So for starters, maybe it does some sort of scan of your network to figure out what are the devices on the network, or perhaps it queries what your asset inventory is using this asset reporting format, so it understands what assets are on your network. And then from there it can start scanning those assets to figure out more information, to start identifying it. Maybe it does some sort of identifying through a common platform enumeration to understand what hardware is on that device, understand what operating system is on that device, understand what certain applications and software is on that device.

From there, then it knows exactly what it needs to test, because it has this XCCDF, the policies, what standards you're holding those different devices to. So we have this extensible configuration checklist description format, and what it will need to do is it will need to probably do some sort of automated testing or automated request of that information. And so that's where open vulnerability assessment language comes into place, where it's going to actually query that device and say, "Hey, what is going on on the device and what is the status of these different checks?"

And it knows what to check because what it can do is, based off of what the common platform enumeration is, it can look up what the common configuration enumerations are. What are the configurations of that different software, what of that operating system? It can also look up common vulnerabilities and exposures based off of that as well. And in addition to that, it can also take a look at what is the risk of each one of those configurations, what is the risk of each one of those vulnerabilities, through the common vulnerability scoring system and the common configuration scoring system.

And then if there's any manual checks that need to be done, then you can use open checklist interactive language, or OCIL, to be able to go and manually do those checks. So this all works together to really understand the vulnerabilities on your network.