the basics - vulnerability management

In an earlier post, I talked about getting “back to the basics.” One component of a basic security program must include a thoughtful vulnerability management process. What follows is a generic, high-level example of what a vulnerability management process could look like.

Purpose

A vulnerability is a flaw or weakness in the design, implementation, configuration, procedures, or internal controls of an information system that may be exploited, resulting in a security breach.

Vulnerability management is therefore the iterative process of identifying, classifying, and mitigating vulnerabilities in an information system.

The vulnerability management program (VMP) should provide a standard framework for timely discovery and mitigation of a vulnerability to reach a state of efficient and effective vulnerability risk management.

VMP Components

Asset inventory and detection

You can’t manage what you can’t measure. Knowing what you have, where it is, and its desired state will not only allow you to be thorough with your vulnerability scanning procedures, but will also enable more effective discovery of rogue devices - which, by virtue of their existence, also create a vulnerability.

How you execute asset discovery and manage inventory is beyond the scope of this article. However, there are numerous commercial and open source tools available for this; additionally, a simple home-grown, scripted toolset could be sufficient and is certainly better than no asset discovery/management.

Vulnerability discovery

Vulnerability scans should be executed in your environment on a regular basis. Some scans may be authenticated, some unauthenticated; some should scan externally-facing resources, while others scan internal assets. The configuration and cadence with which an environment is scanned can take on many forms.

Depending on the size of the environment and the complexity of the systems being scanned, vuln scanning may be done as frequently as daily, which is preferred if it is possible. Sometimes, however, the size and/or complexity of a system is such that daily scanning is not feasible; in which case, weekly scanning should be the goal.

Some scanners that you may want to look into using include Qualys, Nessus, Nexpose, or OpenVAS.

Patch management

In its basic form, a vulnerability scan takes newly-discovered vulnerabilities and assesses a system’s resiliency to those vulnerabilities. If the system is found to be exploitable, a decision should be made to either execute a round of emergency patching, or accept the risk until the next normal patch window.

Reporting

Unfortunately it seems that most of the reports that come out of off-the-shelf tools lack truly meaningful metrics. While dashboards, graphs, and charts may look pretty, often times the actual metric that they reflect isn’t all that useful.

Useful metrics should give the InfoSec team the following information:

• How resilient is the environment, quantitatively?
• How is our MTTR (Mean Time to Resolution) improving or worsening over time?
• How many vulnerabilities exist within the environment for which we have risk acceptance?
• How vulnerable are we with regards to various levels of vulns (Critical, High, Medium, Low), quantitatively?
• What does our trend analysis tell us about how effectively (or ineffectively) our patch management program is operating?

Automation

Once you have reached a fairly high level of maturity with your VMP, you can begin automating the process(es). Specifically how this is done is beyond the scope of this article, but I’ll try to address this in more detail in a future post.

Conclusion

Again, this is a brief, high-level outline of a basic vulnerability management process. Do you have other items that you feel should be added? Are there other metrics that you like to see in your reporting? I’d love to hear about them; leave them in the comments.

In my view, Leonardo da Vinci said it best (assuming the Internet has accurately attributed this quote to him) when he said, “Simplicity is the ultimate sophistication.”

As with all things InfoSec, don’t overcomplicate this. As the maturity of your security program evolves you can add to this process as you see fit. However, in my experience, a simple and consistently-followed process will outperform a complex and haphazardly-executed process every time.