CVE - If It's Not Critical Forget It!

A common dilemma among security professionals is what do to with Common Vulnerabilities and Exposures (CVEs) that fall outside of the "critical" categorization.

Here's your ratings:

1.  Critical (aka High)
2.  Moderate (aka Medium)
3.  Low

There are others but let's stick with these for now.  We know we have to mitigate Critical vulnerabilities and exposures like NOW!  But shouldn't we also review and/or eliminate those that are moderate or low?  Shouldn't we give moderate CVEs to our junior SAs to resolve.  And save the low CVEs for our new admins?  Aren't ALL CVEs worth fixing?  Can we ever achieve 100% resolution?

Good questions.  How do you handle CVEs in your world?

Let's take a CVE that affects Google's Chrome browser.  Browsers are all susceptible to vulnerabilities while at the same time a must have utility to search the Internet.  This vulnerability was released March 22, 2012.  See http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1845  It affects Google Chrome version 17.0.963.66 and earlier versions.  It allows a remote attacker to bypass the Data Execution Prevention (DEP - prevents the execution of code from a non-executable memory region) and Address Space Layout Randomization (ASLR - randomly arranges the positions of key data areas in memory - and randomization is a good security methodology) protection mechanisms and execute arbitrary code!  Credit goes to (and this is important) to VUPEN during a Pwn2Own competition at CanSecWest 2012.   A couple points to clarify before we dive deeper.  One, this is a zero-day vulnerability which means there was no solution (a patch) released yet to fix it.  Two, like other browsers and web-based applications this application runs in a sandbox - and Google has a what is considered the most secure sandbox among all browsers - a place where code can be executed safely without negatively affecting resources and your system overall.  The impact of this CVE allows unauthorized disclosure of information, and/or allows unauthorized modification, and/or disruption of service.

So what do we do to avoid or mitigate this risk?  We could simply not use Google's browser but then that might expose us to vulnerabilities in another browser.  Firefox and Google collaborate and have built some of the most secure browsers available for us to download and use for free (while they collect valuable data about us - but that's another topic - see my Privacy page).  We might limit our time browsing until a fix is released.  Most companies (not Adobe) are quick to correct critical flaws like this. Unfortunately we cannot guarantee safety online.  All software is flawed.  What we can do is limit the risk as much as we can given the tools, time and knowledge available to us.  This CVE affects the end user - the person using the browsers from his or her laptop, PC, or mobile device.  Our servers on the other hand are immune to this vulnerability - because they don't have Chrome installed.

I always recommend signing up with some national cyber alert and vulnerability tracking system like US-CERT/NIST, Mitre and with vendors to receive alerts.  Knowing the danger is half the battle to protecting yourself online.

Back to our original thought - how do we tackle CVEs that are Critical, Medium or Low?  Several new CVEs come out daily.  We barely have time to get the change request filled out or the notification sent before we have to turn around the next day and stamp out new fires.  One school of thought is to concentrate, monitor, inventory and automate resolutions to Critical threats - so we have more time to sift through all those security logs stacking up by the gigabyte!  You can see the job of a security professional can be extremely busy and never ending.  You need to know your environment.  Not every CVE that rolls through your inbox is going to impact your company directly.  Ok, so first take a good inventory - here's where standards come in.  You really need to standardize your OS images.  Every build should come from the same hardened master image.  Changes need to be rolled out to everyone consistently.  Monitor your environment.  I once made the comment in a meeting that we can't monitor too much.  An un-aware DBA took exception to that comment and disagreed.  I stick to my words still today.  You really can't monitor enough.  You can (and should) manage the notifications so not to overwhelm your recipients that is true.  However, if I have a mobile android user that is out of compliance and suddenly vulnerable I want to send and update out immediately.  That's where automation comes in.  Part of your Enterprise Architecture should include the ability to push out updates and/or configuration changes in a matter of seconds to your entire audience.  That capability should be "built in" that master image.  You need to build systems with business continuity and disaster recovery in mind.  That is to say - begin with the end in mind!

Aren't all ALL CVEs (including Low) worth fixing?  Yes and no is the short answer.  If you look at the description of a low CVE you'll notice few of them are worth fixing or eliminating.  While it's a good idea if versions are removed from software banners AND that's an easy resolution there are other ways for someone to discover the version of software you are running.  Sometimes low CVE findings are so low they are simply not worth your time to mitigate.  You should still review them and do your best to eliminate them from showing up in your next scan.

Most organizations will never achieve 100% compliance with Nessus or Symantec scanning tools. Some reasoning for that may be considered job security while Risk Assessment dictates you have limited time/talent/resources - best focus your efforts where it counts.  This is, after all the art of cyber war. Attack your critical vulnerabilities or it'll be easy to fall behind.  And risk only goes up from there.  A robust Vulnerability Management (VM) program must be at the heart of your enterprise.  One of the best classes I taught recently was a vulnerability management course.  We looked at Nessus, Nmap and Metsploit.  Students really enjoyed knowing how to take apart a system methodically in order to find its weaknesses and choose the best way to mitigate them.   The job of a professional VM is rewarding and never ending.  Leave your Medium and Low vulnerabilities to your junior staff.  It is a great training opportunity for them to learn a lot about the entire system.  The fact is you will never achieve 100% resolution to CVEs - but we should all aspire to do as much!  We owe it to our employers to pay due diligence in the cycle of vulnerability management.  I challenge you to achieve the highest level of mitigation possible.  You'll impress your friends and claim valuable bragging rights!