How to deal with the rising rate of vulnerabilities

On the continuously evolving front lines of security, one trend that shows no signs of slowing down is the rate of vulnerability discovery and disclosure. The Common Vulnerability Enumeration’s April 29, 2018, database update of known vulnerabilities shows that 2018 has so far seen 10,718 issues (7,543 reserved, 3,150 confirmed, and 25 disputed).

That means that known vulnerabilities in 2018 are certain to surpass the 15,000 reported in 2016 and likely to exceed the 20,000 of 2017.

Vendors advertise “silver bullet” solutions that promise enterprise-class vulnerability management or auto-magical in-line protection of apps and containers that they say could have prevented the <insert company’s name> breach. But these tools are only as good as your team's ability to tune and manage them.

There has yet to be a solution that can protect every technology chosen, and every piece of open source used. More than being dependent on any specific tools, your approach to vulnerability management should be process-oriented. Focusing on the process will mean fewer emotional peaks and valleys when a zero-day hits.

To prevail in the continuous battle that is vulnerability management, here are three practical steps to start or supplement your approach.

Gartner Magic Quadrant for Application Security Testing 2018

1. Create an inventory

The first step in any security program is to know what you have—i.e., what is your attack surface? If you don’t have a good handle on the basics of asset management or what type of technology stacks you have, you can become too reliant on your scanning technology. This can be a waste of your engineers’ time if you are not presenting high-confidence findings.

Until you understand what you need to protect, you can't start to develop a baseline for your attack surface. A company that has a single mobile application with two public endpoints is drastically different from one that has thousands of microsites that are hosted on open-source solutions. So start with the basics of knowing your public IP ranges, internal VLANs, cloud-based instances, key third-party providers, etc.

2. Have a process

If you can’t afford commercial tooling, there are plenty of open-source solutions that can get you a long way, depending on your technology stack and what it can integrate. But whether you go paid or free, you may need wrench time to ensure a smooth ingestion process for your engineering team.

Further, it helps to have a simple procedure on to how to handle vulnerabilities that is thoroughly documented to ensure self-service education. Integrating that documentation as part of the reference materials used during training and awareness sessions, or simply including a link to it when the subject arises in emails, will help it become part of the technology culture, and not just another security ask.

Perform as much heavy lifting as possible to make your engineers efficient. This means selecting the appropriate tools, executing the scans, reviewing and refining the results, and then integrating them into existing defect management processes. The analogy I like for vulnerability management is to make sure everyone is going to the same watering hole to stay hydrated; do your best to fit vulnerability management into existing practices with bug/defect management systems.

Yes, this will require you to contour your activities and capabilities to align with the rest of the organization, but it will allow everyone to go to the source of truth easily. If that requires you to create custom labels, define "T-shirt sizing" for the team (S, M, L, etc.), and attend a standup to present high-priority issues, it will pay dividends in the time it takes to fix bugs. It's counterproductive to place defects in need-to-know file shares and not let everyone know who has to fix what by when.

3. Remediate and monitor

As things start to flow, analyze what is needed. In my years of building product, application, and information security programs, I’ve learned that metrics are a necessary evil. I’ve always been a huge fan of the Goal-Question-Metric (GQM) method. Identify what’s important to the organization and understand what is plausible, but avoid getting into analysis paralysis. You don't want measurements, intelligence, and metrics to become a higher priority than actual work.

Keep things as simple as you can with basic measurements. Then, when a new widely spread vulnerability hits, you will have confidence in your process-driven capability to manage the onslaught.

Key challenges for solutions

Most solutions don’t address the problem of false negatives, which are the things you can miss as you attempt to continuously assess your thousands of endpoints. If you are managing thousands or hundreds of thousands of vulnerabilities, identifying the gaps represented by false negatives can be difficult. If you have figured this out already and have everything 100% automated into a vulnerability management tracking system, stop reading this article, because you are well ahead of the game, my friend.

On the other hand, false positives from tooling and scanning solutions can lead to engineer mistrust and exhaustion. You definitely do not want to alienate the team that will be doing a significant amount of work to patch systems, fix code, or decommission systems. If you bring them well-documented, tangible intelligence that fits into their existing work pipeline, your relationship will be much better.

Vulnerability management is intimidating, but it does not have to be hard. 2018 is ramping up to be another record-setting year. Stay process-oriented and stay ahead. 

Share your team's vulnerability management best practices in the comments below.

In my next article, I'll focus on the stresses of cybersecurity fatigue and how to manage burnout.

Topics: Security