Automating Security

One would be surprised at the number of companies that claim to perform vulnerability management, but lack proper asset management. Asset management sounds like a very basic concept that many would assume has already been implemented at most enterprises. But vulnerability management cannot be performed without asset management. Let’s take a look at why.

Without asset management your vulnerability management program cannot identify rogue devices. My definition of rogue device is: Any server on your network that does not have an identified owner. Your asset management program is essential in determining who owns what asset. Keep in mind that when identifying rogue devices, you typically integrate network-based scanners with your asset management data. This requires direct access your asset management data via scripts and applications. Make sure you can acquire asset management data in CSV, XML, web services, or even via direct database access.

Risk assessment is another key aspect of asset management that directly impacts SCAP. Each asset should be assessed for risk (preferably matching the CIA model for risk). By risk-assessing a device you can more accurately measure vulnerability severity using CVSS Environmental scoring. With CVSS Environmental scoring, the same vulnerability would have a unique severity rating per server depending on the server risk rating. I have a lot more to say regarding risk ratings, but I’ll save that for another blog post. The point I want you to take from today’s post is that the risk rating should be located within your asset management system.

And finally, the most important reason for asset management is… accountability! Without accountability, how do you know who is responsible for remediating the vulnerabilities for a particular application or system? Even more pressing, without documented accountability within your asset management system, how would you automate assignment of vulnerability remediation tasks?  Identifying “who is supposed to fix what” never seems to make it onto the list of features to be delivered by vendor’s vulnerability scanning  software. The information security industry’s lack of focus on identifying remediation ownership is one of my biggest pet peeves.

I realize that if you don’t have asset management in place, it’s a daunting task to implement. In fact, if it takes less than six months to implement, then you may be doing it incorrectly. Implementing asset management is not a technical challenge; the challenging part of deploying asset management has to do with the information technology processes required. You’ll have to find a way to integrate asset management into the server build process, the decommissioning process, the software delivery process, etc. If you are only deploying asset management software without deploying IT process change, you are doing it wrong.

So who owns this asset management system within your environment? The easy and correct answer is, “anybody but the information security department.” Think of it this way: the business owns the policy that states asset management must occur. Information technology owns the process that enables the business to properly track assets. If the information security department owned asset management, all that would be left for information security to own would be the asset management software itself. Therein lies the fallacy: we don’t need information security to become the custodian of some random piece of software. Information security should give guidance on changes to asset management that will boost information security.  A great example of this is device and application risk ratings. Information security should be creating the policies that determine how a device is risk-rated.

In conclusion, if you are performing vulnerability management without proper asset management:

• You are not identifying rogue devices
• You are not accurately measuring the severity of vulnerabilities, which should take the device risk scoring into account (CVSS Environmental)
• You are not able to automatically determine who should remediate identified vulnerabilities (accountability)

If you are not doing this today, maybe your time would be better spent implementing asset management?

We all should know that SCAP stands for “Security Content Automation Protocol”.  Let’s look behind the acronym and into what actually defines an SCAP implementation.

The problem with defining an SCAP implementation is that there really isn’t an industry standard definition for the term.  This problem is compounded by the current NIST SCAP validation program.  It’s great that NIST has taken the initiative to validate products to individual SCAP standards.  That said, the security vendors and NIST could do a better job at defining the various validations they may confer onto products.  For example, a security vendor can be awarded the validation of “Asset Scanner” or “Unauthenticated Vulnerability Scanner” by NIST.  These vendors can simply claim that they are “SCAP validated”.  The truth is, while these accreditations do mean the products comply to some of the component of SCAP standards, they do not necessarily provide any sort of security automation.  Can you have SCAP without automation?  It’s at this point that a subjective assessment must be made.  Personally, I believe that applying component protocols which, when used alone, do not perform automation, one is simply measuring risk.  Without automation, we end up with Security Content Automation Measurement.  Not as nice of an acronym, now is it?

A properly designed SCAP implementation can save time and money by accurately measuring and automating detection using open standards.  What if a consumer seeking to implement an SCAP tool purchases an unauthenticated vulnerability scanner that is labeled as “SCAP validated”?  While the consumer may get accurate vulnerability measurement from this tool, they more than likely will not get time-saving automation from it.  I could even argue that, since the unauthenticated vulnerability scanner is using proprietary technology to detect vulnerabilities, the consumer may actually expend more time trying to identify false positives.  Implementing individual components of the SCAP standard does not guarantee automation or time savings.

So what is my definition of an SCAP implementation?  Aharon’s definition of an SCAP implementation is: an implementation that uses the individual components of the SCAP standard to accurately measure vulnerabilities and automate detection.  An SCAP implementation for vulnerability management must include implementation of at least CVE, CVSS, CPE, and OVAL.  When we only implement a single component of SCAP, we are not implementing automation; and without automation, we only have measurement.  I believe that the spirit of SCAP is to provide this valuable, time-saving automation.

I would like to see vendors state the true and specific SCAP validation they acquire from NIST.  If companies release tools that use a mix of SCAP standards and proprietary product standards, it could inadvertently give SCAP a bad reputation.  If a product doesn’t work as expected, was it the proprietary product standard that broke, or was it the SCAP standards?  NIST could also help by:

• Allowing vendors to claim only the specific SCAP components for which their product is certified, instead of stating “SCAP validated”.
• Requiring that products display the highest awarded SCAP Requirement ID on the product marketing material.
• Reserving the broad term “SCAP validated” exclusively for products that use SCAP components for both accurate measurement and automation.

A colleague once told me that if you truly understand a concept, it’s easy to explain it in striaghtforward, simple terms.  If you try to find this information online you will find hundreds of pages of white papers that are more likely to confuse you than anything else.

I am not trying to downplay the complexity of these standards. I am simply trying to downplay your need to understand every bit of detail surrounding these standards the first time you use them.  Yes, these standards can be contained within complex XML documents.  But are you an application developer who will actually be writing applications that use XML documents?  If not, don’t worry yourself with understanding the format of the XML the first time around.  Are there some standards you just don’t see the need for?  You may be right — not every standard needs to be implemented; or maybe your information security organization has not matured to the level of needing that particular standard.  With this thought process in mind, lets discuss a few of the acronyms we use to measure information security.

Below is a list of commonly used acronyms that Mitre calls, “Making Security Measurable”.  Instead of giving you a white paper to read that defines the acronym, I will give you a couple sentences that describe everything you need to know (in “normal people speak”) about these standards at this point in the blog.  Note: this is not about how to use these standards, I simply want to provide my definitions.

The acronyms:

• CVE – (Common Vulnerability Enumeration)
  A way to talk about a vulnerability to someone else. Without standardizing on CVE , all the security industry vendors would call the same vulnerabilities different names.  So in essence, the CVE could be known as the vulnerability name.  And within a CVE record are other describing factors like the title of the vulnerability, a brief summary of the vulnerability, etc.
• CPE – (Common Product Enumeration)
  A way to talk about hardware or software using a common language.  Without this protocol, security industry vendors would all call the same piece of software different names.  For example: Security Vendor A may call your operating system XP, while Security Vendor B may call your operating system Windows XP.
• CVSS – (Common Vulnerability Scoring System)
  A way for the security industry to standardize on vulnerability severity.  This helps reduce confusion related to security vendors claiming a CVE as high, medium, or low severity.
• CCE – (Common Configuration Enumeration)
  A way to describe a system or application configuration item.  Think compliance…
• CWE – (Common Weakness Enumeration)
  Think of CVE for application development weakness.
• OVAL – (Open Vulnerability Assessment Language)
  A language used to define a test that can identify the existence of a CVE, CPE, or CCE.  Wouldn’t it be cool if we could find a CVE instead of just talking about is?  This also gives security vendors the ability to standardize on vulnerability detection.
• XCCDF – (Acronym Soup)
  A way to logically group CCEs and their OVAL detection counterparts.  In the compliance world, it is common to group configurations into policies.

Yes, there are more acronyms than this.  But for now, this is all I will focus on for the next couple of weeks.

It’s almost Monday.

Aharon