The importance of threat intelligence and vulnerability remediation prioritization

In this podcast recorded at RSA Conference 2018, Jimmy Graham, Director of Product Management, Vulnerability Management at Qualys, talks about the importance of threat intelligence and vulnerability remediation prioritization.

Here’s a transcript of the podcast for your convenience.

Hi, my name is Jimmy Graham and I’m the Director of Product Management, Vulnerability Management at Qualys. In this Help Net Security podcast I’ll be talking about the importance of threat intelligence and vulnerability remediation prioritization.

So, organizations often find themselves in one of two states, or in a transition between the two regarding their vulnerability management program. You see some organizations that are more mature and more proactive, where they’re performing routine patching, routine vulnerability scanning, and you see organizations that are a little bit less mature, a little bit more reactive, where there’s no real routine patching across the board. There’s intermittent scanning, or scanning that’s less than then monthly or less than weekly, and some of these are in transition between the two states. Some organizations you’ll see have a mix of these in their environments it may vary by business unit, it may vary by technology area you may see more maturity in Windows patching and remediation, less maturity in Linux or vice versa, depending on the organization.

Qualys’ research shows that there are organizations of both types. We saw a lot of organizations patching as soon as the patch was available, basically within 30 days of Microsoft releasing a patch. Others were patched after the exploit was public, which was about 30 days after the Microsoft patch was released. So, based on the exploits availability we saw some increase patching. And then others waited until WannaCry was spreading before they began patching and treated as an emergency patch scenario, and that would then just right around 60-day mark after the patch was made available.

While WannaCry was a fairly recent vulnerability in terms of vulnerability release and exploit release and malware spreading, old vulnerabilities still get exploited. You see vulnerabilities that may have been released years ago that either have a new exploit or just still being leveraged in active attacks, so it’s not that only new vulnerabilities should be the focus for this this type of patching and remediation prioritization. Old vulnerabilities must be assessed based on the threat data.

Prioritization and threat intelligence and prioritization are needed for both types of organizations and any organizations in between. If you have a proactive vulnerability management program and patching program, you still need to prioritize to set SLAs and OLAs on patching and vulnerability remediation. It’s still important to be able to utilize threat data to determine whether or not you need to decrease the amount of time that you’re allowing to accept a certain amount of risk based on a vulnerability or an exploit.

The more reactive organizations that have a less mature vulnerable management program you need to prioritize to minimize risk because there may be a large vulnerability backlog that you need to handle and address. Those vulnerabilities need to be organized and grouped, and just filtering on severity from your vulnerability management vendor or CVSS score is not enough information to really bucketize those into something that that’s manageable. A lot of vulnerabilities still fall into CVSS 9s and 10s, a lot of times that’s still a major effort to try to prioritize and treat all of those the same just based on the vulnerability severity.

So how do you prioritize? You really need three things to really prioritize your remediation program. You need asset information, and asset information is things like asset risk and asset type, what kind of asset is this, and I’ll speak about why that’s important next we talk about threat intelligence. That asset information is often in a CMDB, if there’s no CMDB the vulnerability scanning tool often is a great place to start. You can sync your vulnerability tool with your CMDB if you have a CMDB, so you can do bi-directional syncing. Bidirectional is important because a lot of times your CMDB may have gaps where the vulnerability scanner was able to find assets that’s not in the CMDB. There may be gaps in the vulnerability scanning coverage, so there may be situations where you’re not scanning a specific segment of the network, and that could be made available by doing bidirectional syncing.

The second thing that you need on top of asset information is vulnerability information, and that includes things like vulnerability severity that’s important, but you also need visibility. That means you need to be scanning often and using things like agents to be able to collect this vulnerability information. Because most organizations today are perimeterless so they have physical assets, virtual public cloud, private cloud, we’re seeing large growth in containers, roaming assets, mobile workers who may be working at a coffee shop or at home, as well as mobile devices. And it’s important to have vulnerability scanning coverage or a vulnerability management agent on those devices so you can collect this vulnerability data and get full visibility into your entire environment and understand the severity of those vulnerabilities.

And the third thing that you need is threat intelligence. And that threat intelligence can be applied differently based on asset type. So threat intelligence about a vulnerability may tell you that it’s being used in something like an exploit kit. Exploit kits target workstations, they don’t target they don’t target servers, so it’s important to understand that if we’re prioritizing vulnerabilities based on the fact that’s being used in an exploit kit, that should be focused on workstation type assets, denial of service vulnerabilities is a higher risk for external facing assets, but not for not as much for internal assets. So different assets are at risk to different types of threats and it’s important to do that. And this really can’t be manual you need to have some vulnerability feed, it needs to be embedded into your vulnerability management solution because you’re not going to track all this data manually. Combining those three data points is really what’s needed to properly prioritize. You should be setting SLAs and OLAs for remediation based on these three things.

And like I said, not just vulnerability severity, vulnerability severity might set a minimum which is fine, but combining the asset data and the threat intelligence should raise the priority of the remediation efforts and shorten those SLAs. You should be setting a vulnerability remediation standard, as well as a patching standard. A lot of times patching, and vulnerability management are two separate groups, they need to have their own standards and they can they can correlate, they can have commonalities, but it’s important that there be ownership of those standards and that there be clear requirements and OLAs.

Taking this information once you’ve gathered it, it’s important to be able to track it in a way that’s manageable through things like dashboards and widgets. This data can’t really be read in just spreadsheets. You need to be able to visually track it in a dashboard, look at trends to show progress, and call to attention areas of focus. You can be dividing that information up by business unit, technical group, software type and so on, just to help you call it attention where you need focus on your vulnerability or remediation program.

We should be moving beyond the concept of trying to track this information in spreadsheets, downloading large CSVs, emailing them out to the different technology areas for remediation. This should be as automated as possible. Automation is key to having a mature vulnerability management program. The vulnerability remediation tickets should be delivered automatically into your ticket tracking systems. You should be able to track these visually inside of a dashboard to make sure that you do see downward trends on these vulnerabilities so you can track the different areas, as I said break them down by different areas whether that’s business unit or technology area, it’s important to have that kind of visibility and have it in a visual format to be able to call attention to these different trends.

You should report on your adherence to the OLAs. You should you should break that down by software type, by operating system, by business units or technical groups, whatever makes sense in terms of OLA adherence, you should have routine reporting on that. And you shouldn’t be scared of lots of red. If you’re in a situation where you’re in a less mature environment, you do need to draw a reasonable line. That doesn’t mean that you need to set unreasonable goals, but you do need to draw a line that is reasonable for your organization. You can always pull it back as needed, but if you’re in a situation where you have a large amount of backlog vulnerabilities, then you still need to set a reasonable standard. Patching should be within you know at minimum 30 days for normal types of assets. And most likely dependent on the different threat information it should be much shorter than that, you know for externally exposed systems even shorter.

Because the goal here is to minimize your risk so you should work on the problem areas if you have gaps in asset information, if you have gaps in threat information, vulnerability management coverage, then you should be working on those different problem areas and see where you can leverage things like your vulnerability tool for asset discovery if you’re lacking a CMDB. The biggest thing here is to build a plan to get where you need to be, because each step in gathering these data points minimizes your risk and gives you some insight.

The goal should be having full coverage of all three of these but as you progress and as you grow out your vulnerability scanning coverage, your asset information building out a CMDB, pulling in threat information into your vulnerability management tool you’ll be able to begin prioritizing.

Thank you for listening, and for more information on Qualys and our products please go to Qualys.com.