Automating Security

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