4 Common Goals For Vulnerability Risk Management Programs

4 Common Goals For Vulnerability Risk Management Programs

At Rapid7, we have made it our top priority to uncover unmet customer needs and create value in new product development that addresses these needs. This post will give you a glimpse into the research that was conducted to pinpoint under-served and unmet customer needs in the vulnerability risk management space.

The Rapid7 team approached this research by leveraging the Jobs To Be Done framework, which follows the belief that people hire products and services to get a job done. To complete a job, people strive to achieve functional and emotional outcomes. In other words, people want products and services that will help them get a job done better and/or cheaper.

To start, Rapid7 completed a UX exercise with security professionals from 18 different companies. Based on that work, we derived 74 outcomes that security professionals were trying to achieve within their vulnerability and attack surface management programs and for their businesses.

In this UX exercise, we also asked about detection and response (D&R) programs..

Today, I’ll be providing some commentary on the top three customer outcomes for vulnerability risk management identified through Rapid7’s research. As a career security professional, I’ve done the work, built the capabilities, and seen the impact of not having a balanced investment in both attack surface management and detection and response.

The Rapid7 team structured desired outcomes identified through the Jobs To Be Done research by using the following statement formula:

4 Common Goals For Vulnerability Risk Management Programs

Without further delay, here are the top four desired outcomes from security professionals in the vulnerability risk management space:

  1. Minimize the time it takes to respond to a critical situation.
  2. Minimize the likelihood that your environment is breached.
  3. Minimize the time that your software is down for your customers, so that you can be compliant with your SLAs.
  4. Minimize the likelihood that you are introducing new vulnerabilities into your environment.

“Minimize the time it takes to respond to a critical situation”

I find it particularly interesting to see a response-shaped outcome for VM. For comparison, the top outcome for D&R was around reliably detecting threats. Taking a step back and putting myself in the mindset of an enterprise security professional, I can surmise that VM and attack surface management programs have typically been around for longer than D&R programs. As such, much of the operating uncertainty around data collection and analysis, as well as decision making has been figured out. This shows that VM programs may be at higher maturity overall.

So, how does an organization tackle this outcome? First, we need to establish a metric. What gets measured gets done, right? Thanks to our awesome UX researchers, the outcome has the metric—time and the direction—down.

What are we timing? That very much depends on who you’ll be reporting metrics to. Your executives want to know how long it took from the time we knew about it to the time it was resolved and no longer an issue. Speaking from experience, you’ll also want to be ready with a metric that measures when the situation arose and when you found out about it. Your business managers will want to know which teams and individuals are performing well at their assigned tasks, so assignment open/close metrics are great. The point is that metrics can be hierarchical and feed each other. Imagine being able to present this at the next board meeting, “We resolved this critical event within five hours, which is a 3% improvement, which we can attribute to the patching team driving a 25% improvement in their time to roll out the patch.”

Great! So how do we get better? Plan, practice, execute, and measure. The spirit of this outcome is disaster recovery. It’s an emergency that multiple teams need to come together and restore normal business operations. The planning phase gets the leaders and decision makers in a room to agree on process and roles. Coordination is impossible if the process isn’t written down. Measuring the efficiency and effectiveness of the process can’t happen if there is no start/end.

Next is practice. Sports teams get ready for the big game by running two times a day and hitting the gym in between. Security and IT teams are no different. Conduct regular critical situation exercises where you run through the process, check your tools, identify success/failure, and tweak the process.

Execution becomes easy when you plan and practice. That’s the idea of practice: remove the pressure and build muscle memory. I know the sports analogies are tired, but they work.

“Minimize the likelihood that your environment is breached.”

Again, imagine my surprise when I found that the second most important outcome for VM is actually a D&R outcome! That being said, it makes sense, and the priorities are in the right place. Everything we do in VM and attack surface management is to minimize the possibility that the environment is breached. We do that with good reason: VM and attack surface management are preventative measures. Preventative measures are best implemented with technology to minimize the amount of work needed to detect and respond to threats. D&R measures are typically very people-heavy, which nets in a higher cost to detect and respond than to prevent.

While I would love to explore the specific items that make up this outcome, it’s just too big. But it is also the focus of much of my research around effective security programs for different levels of maturity.

Here is my 50,000-foot view: In order to minimize the likelihood that your environment is breached, all aspects of your information security program, from how you planned the program on paper all the way through to how you capture lessons learned and improve your program, must work in unison. The five key areas of investment for effective security programs are:

  • Preparation: Gathering information and planning the security program on paper
  • Threat prevention: How are you using technology to minimize the likelihood and impact of threats, and how are you using process and people to mature that capability?
  • Breach detection: How are you using people and technology together to catch the breaches that make it through your prevention layer?
  • Incident response: How are you using people, process, and technology to quickly restore normal business operations?
  • Security-as-a-service (to the business): As the impact of effective security programs starts weighing on the business, how are you using your security program to help inform business level decisions?
  • Continuous improvements: How are you using lessons learned from real threat, breach, and incident events, along with simulation exercise findings, to improve your program over time?

Within each of those categories, you can put a number of different functional areas (like endpoint threat prevention, network breach detection, etc.) with capabilities (full network packet capture, full reach into each endpoint) and performance areas (time from breach detection to mitigation, number of breach indicators promoted to prevention, etc) to build out your program.

So how do you get started? Read our blog post on the three most important questions for your security program, and stay tuned as we explore the topic in future blog posts.

“Minimize the time that your software is down for your customers, so that you can be compliant with your SLAs.”

Yes, you should demand uptime from your critical tools and have redundancies for your redundancies.

“Minimize the likelihood that you are introducing new vulnerabilities into your environment”

This is a very loaded outcome. Think about the nearly endless ways that vulnerabilities can be introduced, such as:

  • Vendor disclosure with patch
  • Zero-day that only attackers know about
  • Unpatched personal devices
  • Unpatched SaaS
  • Misconfiguration (human error)
  • M&A activities
  • New facilities

Thinking about the six areas of investment listed above, to achieve this outcome, you need to perform remarkably in the preparation, prevention, security-as-a-service, and continuous improvements.

Wrapping this one up, achieving outcomes in security programs is really hard. Just about everything is stacked against the defender. Attackers only need to be right once, while defenders need to be right 100% of the time. The one advantage that we do have is that these attacks are happening in our environments (or that we own through proxy, like SaaS). Why are we letting the only advantage that we have go to waste by not making it as hard as possible for the attackers to get what they want?

We get myopically focused on the fine details of the security programs, while forgetting to take a step back to remember that the goal of our security programs is prevent a breach from causing material damage to the organization, and to do so as economically as possible. Do you really need to buy a couple million dollars worth of software right now, or can you use your existing networking devices to create network segmentation around your most prized data? Do you really need to have the best security program in the world, or is there risk that the business is willing to accept that would end up costing less?

As security professionals, we often forget that we serve the businesses we work for. Sometimes we’re able to shift the tide; sometimes the right business decision is not the best security decision. We need to accept that (in some cases).

Need support developing your security program? Learn more about our advisory services.

Get Started

Original Source