Summer Security Fundamentals Recap: Vulnerability Management

Last updated at Mon, 18 Nov 2024 19:57:11 GMT

Our latest Summer Security Fundamentals training is a wrap, so we wanted to share with you what our expert panel discussed, including common vulnerability misconceptions and tips for creating a successful vulnerability management program, measuring real risk, and advocating for resources internally. Watch the full training or read our recap below.

What a vulnerability is (and isn’t)

People often ask us what the difference is between vulnerability, threat, and risk, so we thought we’d start off this training by clarifying:

• A threat is the potential danger to information or systems.
• A vulnerability describes the circumstances of a system that make it susceptible damage
• A risk is the likelihood of a threat taking advantage of a vulnerability in the environment.

Vulnerabilities are often simply mistakes or bugs in the software that compromise confidentiality, information, or the availability of a resource (such as a website).

The fundamentals of a successful vulnerability management program

The success of a vulnerability management program boils down to software management. This requires being able to understand all the software in your environment along with the systems and services (and all of their versions), and comparing that to known vulnerabilities. From there, it’s a matter of being able to prioritize those vulnerabilities and make decisions about which ones to address, since it’s unrealistic to completely get rid of all risk.

Putting a successful vulnerability management program in place is just as much about the technology as it is the people involved. Prior to implementing a program, it’s important to get executive buy-in both from business and technology owners. Then, it’s a matter of getting all other stakeholders, such as the operations and development teams, on board in order to create a process for not only detecting vulnerabilities, but actually remediating them. At the end of the day, reporting is useless if you can’t measurably reduce the most impactful risks in the environment.

Advocating for vulnerability management resources

The easiest path to getting budget for any security initiative is to tie it back to compliance, because compliance typically equals revenue. Security stands the greatest chance of getting buy-in and budget when it can positively influence revenue. Most executives are interested in checking a box to make sure the company is compliant, and if a security initiative helps get there, even non-technical leadership can get on board with it.

To do this, it’s important to align what the vulnerability management program will do to boost the goals of the business. Being able to translate how a reduction in risk will improve availability and uptime typically resonates well with executives, as it has a direct impact on revenue, reputation, and customer satisfaction.

Another area of the business you need buy-in from is the development and/or operations teams. The biggest reason why remediation work often falls flat is because security wasn’t aligned with IT or operations. But when there is upper-management buy-in that is driving their alignment, both teams will be invested in helping each other achieve their goals. You’ll be much more likely to get their buy-in if you can implement scanning before code goes into production (where it’s faster to fix). Integrating your vulnerability management tools with a ticketing solution like Jira or ServiceNow can help make this a seamless process.

Understanding real risk

One way to address risk is through CVSS, which was created to standardize how vulnerabilities affect companies across the board. With CVSS, vulnerabilities are assessed on a scale of 0–10. But to understand your actual risk, you need to take it to the next level by looking at the vulnerability itself, how it’s being exploited, and how old it is.

Many Rapid7 InsightVM customers enjoy how our Real Risk Score considers the exploits available for a vulnerability through our Metasploit integration. This is the first step to understanding your actual risk. Next, you should look at the age of the vulnerability. If it’s old (e.g., 10 or 20 years old), you should take it seriously, since the older the vulnerability, the more susceptible you are to it since it’s been around for a while.

From here, you can take all of these components and put them into our Real Risk Score within InsightVM to calculate the actual risk that vulnerability poses in your environment. With the help of InsightVM’s robust tagging system, adding a criticality tag to an asset that is particularly important to your organization—such as a system that hosts PII or sensitive corporate data—will weigh its Real Risk score more heavily compared to lower-priority assets. This will make it unquestionably clear what risks need to be prioritized.

When prioritizing the risk of vulnerabilities, context is everything

Context builds understanding, and the more you know about a vulnerability, the better you can make decisions. When you detect a vulnerability, you need to know how important the vulnerable asset is to the operation of your business, who has access to it, what data is stored or processed on it, and so on. For example, a vulnerability on a marketing team member’s laptop is far less of a concern than one found on a payroll employee’s laptop because of the type of data that can be stolen. From a CVSS perspective, both threats would be scored the same, but when you add context, the picture becomes much more clear.

The key elements of a vulnerability management program

Many security teams don’t realize that the first step is actually to decide how you’ll measure the success of your vulnerability management program before you start building it. What the success of that looks like and how you get there can be a gray area unless you really map it out, especially if you’re trying to align vulnerability management back to business objectives.

To begin, meet with the business executives who are ultimately funding this program to see what results they want to see. From there, you can translate how to get those results by implementing your program and different technologies. You also want to think about what you want in your reports and what you need to be able to prioritize. The answers to these questions will inform what systems you need and what risks are most important to keep tabs on.

Another thing to consider early on is asset management. The saying goes that you don’t know what you don’t know, so if you don’t know that something is on your network, how can you qualify and measure it? Often the assets you don’t even know you have end up being the riskiest ones because if they’ve circumvented normal processes, checklists, and controls, they could be rogue software. CIS controls 1 and CIS controls 2 outline how to discover what is on your network, and tools like InsightVM help you bring this to life.

How the cloud and IaaS impacts vulnerability management

When it comes to addressing vulnerabilities in the cloud and on infrastructure, most of the fundamentals are the same. Things like asset management actually become easier because you can quickly run a report in AWS, Google, or Azure and get a list of all of your assets within seconds. But where things get tricky is when different teams have different accounts, such as on AWS. Security is often left in the dark and many accounts aren’t monitored because of this.

When starting out, it’s important to create an overarching policy of what you will and won’t allow (e.g., don’t let any account have port 22 or 80 exposed to the public). You also need to ensure things are configured properly, including security groups and file permissions. AWS has Organizations, which allow you to create accounts under a single organization. This way, every account has its own alerts, vulnerability scanning, and logging, and gets funneled into a single point within the organization.

How to hire a vulnerability management team

If you have the budget to build a full- or part-time team for vulnerability management, there are a few important criteria you want to look for. The first is technical aptitude and a willingness to think outside the box. You need someone who wants to continually learn when new vulnerabilities are disclosed or why something is happening and why it works that way.

Another key criteria is someone with knowledge of the basics of software development who can help you automate things. You’ll also want to look for someone who knows their way around Ruby, Python, or other scripting languages.

In security, it’s easy to feel like your efforts are futile when work just keeps piling up and you focus on the bad, but when you can hire people who are hungry and have a strong work ethic, they can lead the charge in changing the dynamics of the security team.

Validating whether a vulnerability has been fixed

Sending a vulnerability report or alert over to your development or operations team is one part of the equation, but the other is validating whether it’s been fixed—properly. Ideally, you can use one of your vulnerability management tools to do this. For example, with InsightVM, once a developer marks that an issue has been resolved, an automation process kicks off to assess whether the work was done and the vulnerability is gone. It can also account for compensating controls, meaning that even if a vulnerability still exists on the device, some action from the team to mitigate it may be sufficient, depending on your thresholds.

This is where penetration testing comes in, where someone actually attempts to exploit the vulnerability like an attacker would to see if it is susceptible to exploitation. InsightVM can also track remediation progress so that anyone can go in and see how far along it is, eliminating any need to nag or sit up at night wondering.

The ideal scenario is to have a closed-loop system in which a piece of software gets scanned before it’s released. If everything looks good, ship it, but if not, a Jira or ServiceNow ticket is created and sent to the development team along with the results of the scan for context. As soon as they close the support ticket, it will scan one more time and push the piece of software to production if the vulnerability is gone. If not, a ticket is opened again, and the loop continues. This same process holds true for hardware, such as a system.

What’s next in vulnerability management?

Our three panelists unanimously agreed that scripting and automation will be the next big things for vulnerability management. Eventually, issues will be fixed automatically, but we’re not quite there yet. Another upcoming trend is container orchestration where you can validate whether container images are assessed and where images are being accessed.

In a day and age where everything is about the code, security teams need to be savvy to understand what the code is doing and how to make processes more streamlined to catch up. This is where security orchestration and automation (SOAR) comes in, automating repetitive and manual tasks so you can shift your time to things like remediating vulnerabilities.