A vulnerability management framework is necessary for providing structure and focal points to properly address ongoing information risks. Documenting specific standards and policies, ensuring proper execution of the necessary steps, and keeping the right
people on board with vulnerability management initiatives is the recipe for success. Most importantly, it all takes time and diligence. This piece presents the areas to consider when formalizing a vulnerability management program and offers guidance
for getting it right.
Basics of Vulnerability Management
A healthy vulnerability management program both sets expectations and ensures ongoing oversight. The standards, policies and procedures needed vary depending on specific risks and organizational
needs.
Standards
Standards are aspects of a vulnerability management program that involve specific approaches and configurations that are “standardized.” At a minimum, this should include:
- Systems and applications in scope.
- Tools used for vulnerability scanning and penetration testing, security intelligence and patch management.
- Asset criticality ratings defining the relative importance of specific hosts, applications and information, with efforts focused initially on the most critical assets.
- Vulnerability ratings, ideally unique to the specific business’s needs, which will likely focus on “criticals” and “highs,” rather than simply going with vendor recommendations and/or addressing everything at once. These
should include:
- Vulnerabilities creating tangible business risks.
- Flaws requiring further penetration testing.
- Weaknesses that can be considered acceptable.
- Vulnerability metrics that help measure areas such as exploitability, tangible risk and compensating controls.
- Information included in technical reports shared with technical team members (i.e., DevSecOps and network administrators) and summary reports to management.
Policies
Policies are documented rules that leverage the standards and outline what must be done to effectively manage identified risks. These include:
- Schedule/cadence for vulnerability scanning and manual testing, such as weekly, monthly or quarterly.
- Allocation of compensating controls, such as firewall rules, patch management or endpoint protection when necessary.
- Follow-up patching requirements that address “criticals” in a certain number of days, “highs” in a certain number of days, and so on.
- Reporting testing and remediation results to stakeholders.
- Remediation testing to determine which of the previously identified flaws have been addressed.
- Requirements for outside parties involved with vulnerability testing or oversight, such as testing tools and methodologies used.
Procedures
Procedures are the implementation of security standards and policies and are unique to each organization. You should document your procedures, along with the associated standards and policies, and store them so they are readily accessible to all team
members.
Vulnerability Management Lifecycle Considerations
Vulnerability management is not a one-time exercise. Vulnerability scanning, additional penetration testing (when required) and remediation must be carried out on a periodic and consistent basis.
The core element of vulnerability management is identifying specific areas of weakness – the focal points – that must be addressed to provide the greatest return to the business. A vulnerability management lifecycle is often made up of the
following components:
- Scanning
- Manual testing
- Risk analysis
- Patching
- Reporting
- Follow-up/success measurement
The end goal should be to minimize vulnerabilities and risks to a tolerable level, and nothing more. Those who strive for perfection in vulnerability management end up realizing fewer benefits than those who focus their time, money and efforts on their
highest payoff tasks.
Staffing Considerations
Success is typically achieved using dedicated resources (where possible) for each of the lifecycle tasks above. Some find getting system owners/administrators involved in the risk analysis process and remediation efforts works well. Others don’t,
and see little success in doling out the responsibilities of risk analysis and remediation, especially to staff members outside of IT who might have less security buy-in.
Tooling Considerations
Using risk analysis capabilities from an outside provider can help streamline efforts and keep costs to a minimum. However, such a tool might not provide all the functionality needed. A third-party risk analysis tool from a vendor may need to be used.
Dedicated risk analysis tools can help with asset classification, overall risk analysis and integration with other tools that might be used for vulnerability testing. This additional functionality and insight often helps enterprises take their vulnerability
management program to a more advanced stage, where they can focus on risk, rather than simply addressing individual vulnerabilities uncovered by a single vulnerability scanner time and again.
The best way to determine whether a third-party risk analysis tool is needed is to look at how existing vulnerability management efforts are working and, specifically, which blind spots still exist. Identifying these gaps and opportunities can provide
information on whether existing tools and processes can be adjusted to accommodate, or if a third-party tool is the only way to meet specific needs.
READ: How to Coordinate CTI and Vulnerability Management
Vulnerability Management Remediation
Issues in the remediation (patching) phase of vulnerability management often leave critical vulnerabilities present on the network for extended periods of time. For example, teams often try to patch too many systems at once or focus on patching vulnerabilities
that might not need attention compared to other, more urgent findings. In the event of an incident or breach, these issues might be considered indefensible.
Criticality ratings must be created for systems and information assets, as well as the vulnerabilities themselves. For operating systems, it’s easy to assume all patches should be applied across the board, regardless of the urgency of the vulnerability,
importance of the asset or related contextual information. However, this ends up creating distractions and unnecessary work that can negate any benefits of vulnerability management efforts.
Common goals for operating system patch deployment are as follows:
- Criticals: Within 7 days, sometimes up to 30 days.
- Highs: Within 30 days, sometimes up to 60-90 days.
- Mediums: Within 60-90 days, if ever (initial and, perhaps, ongoing efforts will likely not include these vulnerabilities).
These timelines should not be arbitrary, nor should they be set in stone. Risk tolerance and patching resources dictate what is best for the business, and that may change over time.
Consider using an enterprise patch management tool. Another important consideration is whether the patch management tool supports software patching for third-party vulnerabilities involving Adobe Reader, Chrome, iTunes and the like. Vulnerabilities impacting
third-party software often create greater risks than those impacting the operating system itself.
Communicating Vulnerability Management to Management
One of the biggest barriers to strong vulnerability management and the success of the overall information security program is technical staff attempting to take on vulnerability management without the involvement of leadership and other stakeholders.
Often, a security committee either does not exist or is not providing direction. This approach ends up creating a false sense of security on the part of leadership, because it assumes all is well, since technical staff are not seeking feedback or
involvement. All successful vulnerability management programs must have strong management buy-in. This not only ensures ongoing communication about program efforts, but also keeps stakeholders in the loop and likely more interested in positive outcomes.
A common challenge is not fully understanding what to report on and how often this information should be communicated. This aspect of vulnerability management takes time to develop, based on experience and feedback from stakeholders. The same goes for
system owners and administrators.
The rule of thumb on what to report and how often is simply to ask. Obviously, what is communicated to technical staff will be different from what is communicated to management. The most important thing is to communicate only what’s necessary. Less
is more, especially in the beginning. It’s important to remember stakeholders outside the vulnerability management team might not place the same level of importance on the tasks involved. They might not have the time to manage it either.
Once vulnerability management efforts are more mature, and stakeholders are getting on board with both what is being accomplished and what is being asked of them, adjustments can be made to ensure everyone is getting what they need and in the proper doses.
Creating a Vulnerability Management Framework
Developing a framework can improve your vulnerability management program by helping provide structure and focal points to assist team members and properly address ongoing information risks.
To get started:
- Get management buy-in: This ensures your program is supported and stakeholder communications is optimized to keep the program on track.
- Lay a strong foundation: Put optimal standards, policies and procedures in place.
- Focus on lifecycle management: Get the right staffing and tools in place, and ensure the focus is on minimizing risk to a tolerable level, not perfection.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.