.com[Part 3 of 3 in the Enterprise Security Vulnerability Management series. Part 1 | Part 2]

Enterprise Security Vulnerability Management – Quick Wins and Gotchas

Implementing and executing an enterprise security vulnerability management program requires both time and/or money to be successful. This last part of the Enterprise Security Vulnerability Management series describes a couple of quick wins and some gotchas to look out for while dedicating your time or money.

It doesn’t have to be expensive

But, here is the caveat to that claim – the less you spend on your “enterprise” vulnerability management system, the less functionality in “management” features you get in the solution.  For a relatively cheap price, an enterprise can implement a vulnerability scanner such as Nessus with their Professional feed.  However, the reporting and data management features are really not “enterprise” solution capable.  This is where the tradeoff between money and resources really plays out – you pay less money, but it requires more work to create those reports and manage the data.
As an alternative to dedicating 25-50% of a full-time resource to operate your enterprise vulnerability management program, purchase vulnerability management as a service.  VM as a service should offer weekly threat and vulnerability analysis, monthly internal vulnerability scans, and quarterly external vulnerability scans.  The ongoing care and feeding of the vulnerability scanning solution is outsourced.  Some solutions only provide scan results in a dashboard, others spend time on site working with you to understand and remediate the identified vulnerabilities. Pick whatever works best in your situation.

Mine your own data

If you aren’t happy with the quality of the default reports in Nessus and you can’t afford the Tenable SecurityCenter data management, analysis, reporting and alerting tool, there might be some free tools that can help.  Again, it is the tradeoff between money and resources.  Three potential vulnerability data management tools are listed below.  The evaluation of these tools will be available in a future blog entry.
Risu (formerly known as NessusDB) from Jacob Hammack

• Risu is an open-source Ruby-based Nessus parser, that converts the generated reports into an ActiveRecord database, this allows for easy report generation and vulnerability verification.
• Risu requires a Ruby environment and a database such as MySQL or SQLite.  It can run on Windows and Linux.

MagicTree from Gremwell

• MagicTree is a closed-source Java penetration tester productivity tool. It is designed to allow easy and straightforward data consolidation, querying, external command execution and report generation. In case you wonder, “Tree” is because all the data is stored in a tree structure, and “Magic” is because it is designed to magically do the most cumbersome and boring part of penetration testing – data management and reporting.
• MagicTree is a Java client application that can run on Windows and Linux.

Dradis from Security Roots

• Dradis is an open source framework to enable effective information sharing, especially during security assessments.
• Dradis is a self-contained web application that provides a centralized repository of information to keep track of what has been done so far, and what is still ahead.  The Dradis server requires Ruby and SQLite and runs on Unix-like systems – installation guides for BackTrack, Ubuntu, FreeBSD and OSX are available.

Dig deeper

The quality of your enterprise vulnerability management program is highly dependent on the data it is based on.  The amount and quality of the data can be enhanced by two factors:
1)      Use more network and application vulnerability scanning tools.  This provides greater breadth in the vulnerabilities tested and can also provide corroboration in the findings.
You can always try security vulnerability testing tools on LiveCD distributions such as BackTrack, the Network Security Toolkit (NST), or the Security Tools Distribution (STD).  I recommend limiting your testing to systems in your designated test / development network prior to testing production systems.  The results from these tools could supplement or confirm the results from your regular vulnerability scanner.
2)      Don’t rely on network-only vulnerability scans.  Configure your vulnerability scanner with credentials.  Credentialed scans produce much better results regarding patching status and local host security configuration items that aren’t generally available from a network-only vulnerability scan.
However, even with credentialed scans, don’t believe you are scanning for “every” vulnerability out there.  Credentialed scanning allows the vulnerability scanner to log in to the target and determine application version information using meta-information from the Windows registry or other package management databases. This allows the scanners to be much more accurate and also provides much greater coverage than an unauthenticated scan. Using this local information, a credentialed scan can determine specific versions of libraries being used or versions of client software that have no listening services, among other granular security checks that can only be performed using credentials.  But even then, only approximately 25% of reported vulnerabilities make it into the signature database of vulnerability scanners.
3)     If time and resource skill-sets are on your side, leverage manual penetration testing to identify issues and vulnerabilities within your environment. Typically targeted towards your application stack, this can vary from source code analysis, application architecture reviews, threat modeling, business logic analysis, database schema and permission analysis, to automated database configuration reviews.

Don’t trust, verify

The “trust, but verify” signature phrase of Ronald Reagan doesn’t really apply to vulnerabilities scanners.  Inevitably, some reported vulnerabilities are false positives.  A false positive is when you think you have a specific vulnerability in your system or application but in fact you don’t.  You might consider running a second, more specialized security testing tool to test the vulnerability finding.  Tracking these down can be a hassle, but don’t blindly assume that because the vulnerability scanner identified a vulnerability, that it actually exists.
For instance many Linux-based operating systems leverage backporting which increases the number of false positives as many vulnerability scanners rely upon version numbers in requests. To “verify” that there are outstanding patches, you will need to get the output from the relevant system. On a RHEL based system (CentOS, Fedora, etc) the “yum list available ‘httpd*'” would provide output for any available Apache httpd patches that need to be installed. To list all of the currently installed patches on the same type of systems you can simply review the list of installed packages “rpm -qa|grep httpd” and manually compare them to the relevant Linux distribution errata.
As another example, the OS detection function of vulnerability scanners is not 100% accurate.  While you may be able to find some weird system types on your network, don’t assume that the OS detection function of vulnerability scanners is infallible, they might not be what they look like.   To help validate, look at all the headers retrieved in service detection plug-ins.  Try running NMAP or telneting to the open ports to see what is returned.  Verify.

Address the core problem early

If you want to make your job easier in minimizing the results from your enterprise vulnerability scan, work to eliminate the problems before they occur.  Here are four ideas:
1)      In your IT Standard Project Development Methodology or System Go-live Checklist, make sure there is a required vulnerability scan, with allowed remediation time prior to go-live approval.
2)      This is kind of like closing the barn door after all the horse have left, but make sure that there is an owner for each new system and application. Confirm that they know what their responsibilities are regarding on-going maintenance and patching.  Anytime you review a project implementation plan and do not see an operational process in the maintenance phase for patching, do not approve.
3)      Develop an active threat and vulnerability intelligence process identifying vulnerabilities and providing remediation steps that can be implemented prior to the vulnerability scanner pointing out the problems.  This requires a philosophical shift from reactive (don’t touch it unless it is broken) to proactive (preventative maintenance planning).
4)      Implementing well-defined Minimum Security Baselines (MSBs) as part of the system build procedure will eliminate some of the meticulous items like default accounts/passwords, incorrect SSL version, weak ciphers, and other easily fixed vulnerabilities. If you scour the Internet, there are many available publicly or you can leverage guidelines offered by NIST, CIS, NSA, or Tenable (Nessus .audit policies).
This ends our 3 part series on Enterprise Security Vulnerability Management.  If you are struggling with your current enterprise security vulnerability management program, or if you need to implement one, contact us at Pondurance for assistance.