Five Steps to Building a Successful Vulnerability Management Program I. Why is vulnerability management so difficult? Vulnerability management poses a unique challenge for businesses. Despite proven technology solutions and the best efforts of multiple IT teams, unresolved vulnerabilities consistently serve as a source of friction and frustration. Regardless of how many vulnerabilities are fixed, there are always those that can’t be easily remediated. Infighting between IT teams and business groups is common, each pointing fingers as to who is responsible for the potential risk these vulnerabilities pose to the environment. To deal with their frustration, companies often switch vulnerability management tools every few years, trying to use the latest technology to tighten control. While this may make sense if your security needs have changed, new tools won’t help if it is your processes that are broken. To build a successful vulnerability management program, you need to determine what matters to your organization, and then create a program designed to best address those specific issues. That sounds simple, but it’s actually incredibly difficult. No two organizations are the same, so there is no standard playbook to follow that can tell you what to care about. Take the example of a European bank operating in the United States that fails several security audits because they did not patch operating system vulnerabilities. They could lose their ability to hold and handle currency in the U.S., costing them billions in revenue. To that bank, those vulnerabilities are mission critical. Alternatively, for a car manufacturer or grocery store chain, the exact same set of vulnerabilities might require no urgency at all. It’s all about understanding how vulnerabilities relate to your business. To start building a successful vulnerability management program, you need to focus on the right set of vulnerabilities in the right context. Tenable™ has identified five key steps that will help you create a personalized blueprint for addressing your unique vulnerability challenges. Following these steps will align your remediation and response actions with business priorities, help reduce friction and frustration between IT groups and provide more reliable information on the security state of your complete environment. II. Step 1: Set the right goals When most organizations start talking about vulnerability management program goals, they immediately state that their goal is “lowering risk.” This isn’t terribly surprising, since business leaders like CFOs are focused on managing business risk all the time – how much to invest in different areas for a quantifiable return. Unfortunately, security teams have a different vocabulary when it comes to risk. Managing market forces is not the same as managing the interdependency of Oracle, Java and ColdFusion on a web application that is accessed by 30,000 users a minute. There is no sliding “risk scale” of zero to 100% that a security team can track. The idea of “zero risk” in and of itself is a dangerous concept, because it’s impossible for any organization to remove all risks. When companies talk about lowering risk, what they generally want is to tie vulnerabilities to some monetary value. The amount, or risk, would be the potential financial impact that a vulnerability could have on the business. Unfortunately, most businesses simply don’t know what is most important to protect in their environment. Which 20 or 30 systems and applications generate 80% of the company’s revenue? If anyone has this information, it most likely isn’t the security team. But even if they did, to build a comprehensive risk management program, you would not only have to account for those 20 or 30 critical systems, but everything else that touches those systems. This includes all of the applications on those systems, all of the connected systems or devices that access them, all the people who use those systems or devices, all of the buildings where those people and devices reside and so on. The interconnectedness and changing nature of technology systems make vulnerability risk nearly impossible to quantify. Imagine that kind of effort in a huge organization like the military – you would have to factor in every building, every truck, every guard station, every vendor that services the base and more. The inventory alone – being able to identify all these assets that factor into the risk equation – is unmanageable. If your goal is this broad, you can end up failing before you even get started. Copyright © 2016-2017. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 3 Instead of focusing on the very broad goal of risk management, you can break your risk problem down into specific components that are measurable and meaningful. We recommend starting with the areas of attack surface hardening, asset inventory and patch auditing. While not trying to provide an overall picture of risk, these categories help you concentrate on where vulnerabilities can create exposure, then define what it means to successfully mitigate that exposure. How can I make that exposure as small as possible? Do I know what needs protecting? Are my systems up to date? You can define specific metrics to answer each of these questions – which become clear, meaningful goals to track your success. Potential Vulnerability Management Program Goals Category Description Goal Example Metric Attack Surface Hardening How exposed is my organization? Make attack surface as small as possible % exploitable vulnerabilities on internet-facing systems Asset inventory Do I know what needs protecting? Effectiveness at collecting accurate accounting of vulnerabilities – including for systems that require credentials % of systems discovered vs scanned in last 30 days Patch auditing Are my systems up to date? Effectiveness of patch process for security, feature/functionality and warranty needs % of systems patched in last 30 days In order to be successful, you not only need to set the right goals and metrics, you also have to take into account the staff you have to work toward those metrics. If you ask a CISO which of the above areas– attack surface hardening, asset inventory or patch auditing – that they want to focus on, they are going to undoubtedly answer “all three!” But trying to do everything – and doing it poorly – is another reason why vulnerability management programs fail. Without dedicated personnel assigned to track and improve each of these areas, some are likely to fall behind. It is a more effective strategy to decide which one or two priorities to focus on for a 6 to 12-month period. At the end of that period, you can adjust or expand goals based on results and changing business requirements. III. Step 2: Make sure vulnerability data is accurate, actionable and timely Bad data – false positives and Please complete the form to gain access to this content Access Now Related Resources Vulnerability Intelligence Report Cyber Defender Strategies: What Your Vulnerability Assessment Practices Reveal Quantifying the Attacker's First-Mover Advantage Cyber Exposure for Dummies eBook_Mighty Guide_Reducing Cyber Exposure from Cloud to Containers Tenable & IDG Whitepaper_Building a Secure Foundation to Reduce Cyber Risk Thirteen Essential Steps to Meeting the Security Challenges of the New EU General Data Protection Regulation 3 REASONS: Why DevOps is a Game-Changer for Security Reducing Cyber Exposure from cloud to containers ECONOMIC, OPERATIONAL & STRATEGIC BENEFITS OF SECURITY FRAMEWORK ADOPTION Using Security Metrics To Drive Action 2017 Trends in Security Metrics and Security Assurance Measurement
I. Why is vulnerability management so difficult? Vulnerability management poses a unique challenge for businesses. Despite proven technology solutions and the best efforts of multiple IT teams, unresolved vulnerabilities consistently serve as a source of friction and frustration. Regardless of how many vulnerabilities are fixed, there are always those that can’t be easily remediated. Infighting between IT teams and business groups is common, each pointing fingers as to who is responsible for the potential risk these vulnerabilities pose to the environment. To deal with their frustration, companies often switch vulnerability management tools every few years, trying to use the latest technology to tighten control. While this may make sense if your security needs have changed, new tools won’t help if it is your processes that are broken. To build a successful vulnerability management program, you need to determine what matters to your organization, and then create a program designed to best address those specific issues. That sounds simple, but it’s actually incredibly difficult. No two organizations are the same, so there is no standard playbook to follow that can tell you what to care about. Take the example of a European bank operating in the United States that fails several security audits because they did not patch operating system vulnerabilities. They could lose their ability to hold and handle currency in the U.S., costing them billions in revenue. To that bank, those vulnerabilities are mission critical. Alternatively, for a car manufacturer or grocery store chain, the exact same set of vulnerabilities might require no urgency at all. It’s all about understanding how vulnerabilities relate to your business. To start building a successful vulnerability management program, you need to focus on the right set of vulnerabilities in the right context. Tenable™ has identified five key steps that will help you create a personalized blueprint for addressing your unique vulnerability challenges. Following these steps will align your remediation and response actions with business priorities, help reduce friction and frustration between IT groups and provide more reliable information on the security state of your complete environment. II. Step 1: Set the right goals When most organizations start talking about vulnerability management program goals, they immediately state that their goal is “lowering risk.” This isn’t terribly surprising, since business leaders like CFOs are focused on managing business risk all the time – how much to invest in different areas for a quantifiable return. Unfortunately, security teams have a different vocabulary when it comes to risk. Managing market forces is not the same as managing the interdependency of Oracle, Java and ColdFusion on a web application that is accessed by 30,000 users a minute. There is no sliding “risk scale” of zero to 100% that a security team can track. The idea of “zero risk” in and of itself is a dangerous concept, because it’s impossible for any organization to remove all risks. When companies talk about lowering risk, what they generally want is to tie vulnerabilities to some monetary value. The amount, or risk, would be the potential financial impact that a vulnerability could have on the business. Unfortunately, most businesses simply don’t know what is most important to protect in their environment. Which 20 or 30 systems and applications generate 80% of the company’s revenue? If anyone has this information, it most likely isn’t the security team. But even if they did, to build a comprehensive risk management program, you would not only have to account for those 20 or 30 critical systems, but everything else that touches those systems. This includes all of the applications on those systems, all of the connected systems or devices that access them, all the people who use those systems or devices, all of the buildings where those people and devices reside and so on. The interconnectedness and changing nature of technology systems make vulnerability risk nearly impossible to quantify. Imagine that kind of effort in a huge organization like the military – you would have to factor in every building, every truck, every guard station, every vendor that services the base and more. The inventory alone – being able to identify all these assets that factor into the risk equation – is unmanageable. If your goal is this broad, you can end up failing before you even get started. Copyright © 2016-2017. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 3 Instead of focusing on the very broad goal of risk management, you can break your risk problem down into specific components that are measurable and meaningful. We recommend starting with the areas of attack surface hardening, asset inventory and patch auditing. While not trying to provide an overall picture of risk, these categories help you concentrate on where vulnerabilities can create exposure, then define what it means to successfully mitigate that exposure. How can I make that exposure as small as possible? Do I know what needs protecting? Are my systems up to date? You can define specific metrics to answer each of these questions – which become clear, meaningful goals to track your success. Potential Vulnerability Management Program Goals Category Description Goal Example Metric Attack Surface Hardening How exposed is my organization? Make attack surface as small as possible % exploitable vulnerabilities on internet-facing systems Asset inventory Do I know what needs protecting? Effectiveness at collecting accurate accounting of vulnerabilities – including for systems that require credentials % of systems discovered vs scanned in last 30 days Patch auditing Are my systems up to date? Effectiveness of patch process for security, feature/functionality and warranty needs % of systems patched in last 30 days In order to be successful, you not only need to set the right goals and metrics, you also have to take into account the staff you have to work toward those metrics. If you ask a CISO which of the above areas– attack surface hardening, asset inventory or patch auditing – that they want to focus on, they are going to undoubtedly answer “all three!” But trying to do everything – and doing it poorly – is another reason why vulnerability management programs fail. Without dedicated personnel assigned to track and improve each of these areas, some are likely to fall behind. It is a more effective strategy to decide which one or two priorities to focus on for a 6 to 12-month period. At the end of that period, you can adjust or expand goals based on results and changing business requirements. III. Step 2: Make sure vulnerability data is accurate, actionable and timely Bad data – false positives and
