Vulnerability Management Program Best Practices – Part 1

Image

An enterprise vulnerability management program can reach its full potential when it is built on well-established foundational goals that address the information needs of all stakeholders, its output is tied back to the goals of the enterprise, and there is a reduction in the overall risk of the organization. Such vulnerability management technology can detect risk but it requires a foundation of people and process to ensure that the program is successful. There are four stages to a vulnerability management program:

• The process that determines the criticality of the asset, the owners of the assets and the frequency of scanning, as well as establishes timelines for remediation;
• The discovery and inventory of assets on the network;
• The discovery of vulnerabilities on the discovered assets; and
• The reporting and remediation of discovered vulnerabilities.

The first stage focuses on building a process that is measurable and repeatable. Stages two through four focus on executing the process outlined in stage one with an emphasis on continuous improvement. This is a three-part series that will examine each stage to building a successful vulnerability management program.[i] In Part One, we will examine the first stage.

Stage 1: The Vulnerability Scanning Process

1.    The first step in this stage is to identify the criticality of the assets in the organization. To build an effective risk management program, one must first determine what assets the organization needs to protect. This applies to computing systems, storage devices, networks, data types, as well as third-party systems on the organization’s network. Assets should be classified and ranked based on their true and inherent risk to the organization. Many facets need to be considered in developing an asset’s inherent risk rating, such as physical or logical connection to higher classified assets, user access and system availability. For example, an asset in the DMZ with logical access to an account database is going to have a higher criticality than an asset in a lab. An asset in production is going to have a higher criticality than an asset in a test environment. An internet routable web server will have a higher criticality than an internal file server. However, just because an asset is a lower criticality, remediation on that asset should not be ignored. The remediation effort should always be based in relation to overall risk.

2.    The second step is to identify the system owner(s) for each system. System owners are ultimately responsible for the asset, its associated risk and the liability if that asset becomes compromised. This step is critical in the success of the vulnerability management program as it drives the accountability and remediation efforts within the organization. If there is no one to take ownership of the risk, there will not be anyone to drive remediation of that risk.

3.    The third step is to establish the frequency of scanning. The Centre for Internet Security in their Top 20 Critical Security Controls recommends that an organization should “run automated vulnerability scanning tools against all systems on the network on a weekly or more frequent basis.” Tripwire releases vulnerability signature (ASPL) updates on a weekly basis. Scanning this frequently allows the owners of the assets to track the progress of remediation efforts, identify new risks as well as reprioritize the remediation of vulnerabilities based on new intelligence gathered. When a vulnerability is first released, it may have a lower vulnerability score because there is no known exploit. Once a vulnerability has been around for some time, an automated exploit kit may become available which would increase the risk of that vulnerability. A system that was once thought to not be vulnerable, may become vulnerable to a vulnerability or set of vulnerabilities due to new software installed or a patch roll back. There are many factors that could contribute to the risk posture of an asset changing. Frequent scanning ensures that the owner of the asset is kept up-to-date with the latest information. As an outer limit, vulnerability scanning should take place no less frequent than once per month.

4.    The fourth step in building this process is to establish and document timelines and thresholds for remediation. Vulnerabilities that are able to be exploited in an automated fashion that yield privileged control to an attacker should be remediated immediately. Vulnerabilities that yield privileged control that are more difficult to exploit or are currently only exploitable in theory should be remediated within 30 days. Vulnerabilities lower than this can be remediated within 90 days. In the event of a system owner being unable to remediate a vulnerability within the approved time frame, a remediation exception process should be available. As a part of this process, there should be a documented understanding and acceptance of the risk by the system owner along with an acceptable action plan to remediate the vulnerability by a certain date. Vulnerability exceptions should always have an expiry date.

Interested in learning more about building a mature vulnerability management program? Click here for part two! [i] A special thank you to Chris Banta, CISSP, ITIL and Ric Walford, CISSP for their contributions! _{Title image courtesy of ShutterStock}