Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
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.
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
Standards are aspects of a vulnerability management program that involve specific approaches and configurations that are “standardized.” At a minimum, this should include:
Policies are documented rules that leverage the standards and outline what must be done to effectively manage identified risks. These include:
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
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
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.
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.
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
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:
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.
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.
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:
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.
December 7, 2023
By IANS Research
Learn how to create an actionable CISO dashboard with meaningful security metrics using the three C’s principle that supports informed decision-making.
December 5, 2023
By Bryson Bort
As the year draws to a close, IANS Faculty provide their 2024 Cyber Predictions. Watch our video with Bryson Bort for tips on planning your 2024 IT/OT security strategy.
November 30, 2023
CISOs, find guidance on what to focus on within the first 30 days, 6 months and first year of your tenure to ensure a fast, successful start.