Vulnerability Management

Cole French:

Does looking at your vulnerability scan results immediately fill you with overwhelm and dread? Do you wonder where to even begin? Well, we understand, and best of all, we’ve got some practical solutions for you. Tune in as we demystify vulnerability management equipping you to effectively mitigate the risks that pose the greatest threat to your organization. Welcome to the Cyber Compliance and Beyond podcast, a Kratos podcast that brings clarity to compliance, helping you leverage compliance as a tool to drive your business’s ability to compete in any market. I’m your host, Cole French. Kratos is a leading cybersecurity compliance advisory and assessment organization providing services to both government and commercial clients across varying sectors, including defense, space, satellite, financial services, and healthcare. Now let’s get to today’s episode and help you move cybersecurity forward.

Vulnerability management is quite simply the most important risk mitigation activity an organization performs. Conceptually, it’s quite simple. Remediate the vulnerabilities in the environment. In reality, it is one of the most challenging risk mitigation activities to implement effectively and consistently. Our experience has taught us that there are a few reasons for this. Number one, the sheer number of vulnerabilities can overwhelm, making it difficult to know where to start and how to track progress. Number two, the complexity of the environment, which is especially true for organizations that have large asset inventories spread across asset types, mission functions, and geographical locations. Number three, the subtle nuances that lurk beneath the surface of vulnerability scan tool configuration, such as the depth of scans and how to ensure scans are run with credentials. And number four, the inaccuracy of information and understanding, especially as it relates to the asset inventory, which, as we’ll discuss, is foundational to any successful vulnerability management program. On today’s episode, we’ll demystify vulnerability management by defining some context, outlining an effective vulnerability management program, discussing potential challenges, and tying it all back to compliance. Joining us for today’s conversation is Andrew Overmyer, a subject matter expert and security control assessor here at Kratos, who has worked across multiple security compliance frameworks and is a general cybersecurity jack of all trades. We hope you enjoy this episode. Andrew, thank you for taking the time to join us today on the Cyber Compliance and Beyond podcast.

Andrew Overmyer:

Yeah, thanks for having me. I’m looking forward to this. This is exciting.

Cole French:

Absolutely. Yeah, I’m looking forward to this conversation as well. As I mentioned today, we’re going to talk about vulnerability management. I think what would be most helpful to our listeners today is to level set what is vulnerability management. I think that’s a term a lot of people hear and immediately, “Well, I know I have vulnerabilities in my environment, but exactly how do I manage them? How do I know if they’re vulnerabilities?” Et cetera. We’re going to level set real quick and provide some context to our discussions. Vulnerabilities, we’ll start there. What are vulnerabilities? Quite simply, they’re risks introduced into an organization’s environment. Typically, when we talk about vulnerabilities in this context, we’re talking about flaws or misconfigurations that reside on IT systems in the organization. For the sake of our discussion, we’re going to focus primarily on what we call vulnerability scanning tools and patching tools.

Vulnerability scanning tools quite simply are the tools in your environment that you deploy to scan all the systems to detect vulnerabilities. Pretty simple and straightforward. And then patching tools are used to manage all of the IT assets, typically servers, workstations in your environment. Their primary job is to push out patches, right? Identify the software that resides on the different endpoints, and then they are a tool that can be used to push out updates to those applications. And as we’ll see throughout our discussion, a lot of where vulnerabilities emanate is software applications that reside on endpoints. We have vulnerability scanning tools, patching tools. While they have their own distinct functions, they actually also work to together. Vulnerability scan results compliment what you’re going to see in your patch solutions. While patching solutions are focused on software applications, vulnerability scanning solutions actually will enumerate additional vulnerabilities in your environment.

And those could be related to configurations on your endpoints as well as software that’s installed. We’ll touch on configuration a little bit as we dive into this, but for the most part, we’re going to focus on software applications and vulnerabilities and stay away from compliance. That’s a little bit different, although we are going to talk about compliance frameworks like FedRAMP, CMMC, things like that. Okay, now we’ve provided some definitions. What is a vulnerability? What is a vulnerability scanning tool? What is a patching tool? What’s the vulnerability management part of this exactly? Quite simply, vulnerability management is building a program which is policy, processes, procedures in your organization to effectively remediate vulnerabilities that are found in your environment. Of course, we’re going to go into this in a lot more detail, but this includes things like metrics, right? How do I know that I’m actually making progress on remediating vulnerabilities in my environment?

As we’re going to discuss, there’s a lot of vulnerabilities all the time. How do I figure out? Am I actually making progress on this? Because last week I had 1,500 vulnerabilities, and this week I have 1,600 vulnerabilities, but I patched a whole bunch of vulnerabilities in between. We’ll get into that and then we’re going to talk about some of the challenges that come along with vulnerability management, like what are the headaches that we run into? What are the key components, key things you need to be aware of as you’re implementing your vulnerability management program? Then finally, we’ll talk about, okay, I can build a vulnerability management program, but how does that factor into compliance initiatives I may have like FedRAMP, CMMC, other compliance frameworks that are out there. Now that we’ve laid the groundwork for that, Andrew, when it comes to building a strong robust vulnerability management program, what would you say are some of the key tenets of such a program?

Andrew Overmyer:

Yeah, Cole, I think the biggest thing that I like to hone in on when I’m talking to organizations and teams that are discussing this is something that I feel is overlooked a lot, is that key word at the end of the title. It’s a vulnerability management program, right? This is a process that involves multiple steps, very similar to those that are familiar with incident response, right? It is intended to be a top-down approach that you need to have step-by-step processes in place to make sure that you’re getting all perspectives covered when it involves vulnerabilities within your information system. From the ground up, you need to establish almost like a project management guide. Some of the key tenets of these programs would involve things like what goals exist, not only for the security of your environment depending on the classification that you have or how secure your data needs to be but also what other requirements exist, like frameworks? Right?

Are you beholden to FedRAMP? Are you beholden to CMMC? Do you have specific controls that you need to implement for vulnerability management? There’s also some clients out that, you know, organizations may have customers or contracts that have very specific and unique requirements. Maybe there’s reporting. Maybe there’s a specific timeframe. Those types of goals need to be brought into perspective when you are building out a vulnerability management program because that’s going to shape how your processes are developed and then how they flow, right? Once an organization can get those metrics documented on paper and tangible, they then can develop the metrics for that, right? Those metrics exist with things like, “Do you have any infrastructure that takes priority? Do you have a cluster of servers that is containing more sensitive data than the others?” Those require more definitive strategies to protect and to scan against it, to monitor.

The other aspect is vulnerability risk ratings and how you prioritizing it. Once you’ve got scanning in place, you’re going to find you’ve got lows, moderates, highs, criticals. How is your organization going to address those in a different manner? We get into that here in a little bit, but to continue on with how the program is developed, once you’ve got metrics, you’ve got your goals. Then the objective is to develop a scope, right? You need to be able to generate a digestible amount of information because a common issue that we see with some organizations is they bite off more than they can chew when it comes to vulnerability management. One thing you definitely want to avoid when developing a program like this is that you don’t want to throw everything into one bucket, right? You don’t want to create a /16 and scan everything and just try to dive into that output from the vulnerability scanner.

You really want to organize your architecture in a manner that enables you to not only continue to prioritize, but also ensure that you can provide reports on those different frameworks, right? Because in some larger organizations and some cross-functional teams that work together, you may find that one group of components is beholden to, like we mentioned, FedRAMP versus another group that’s beholden to CMMC, and those may have different requirements. If you’ve got everything going through one single scan, your output, you’re going to have to segment that and change it up and modify the reports, versus developing a solid scope that allows you to differentiate between the two very easily. We’ve got your goals for security, your frameworks, your metrics. You’ve now developed a scope. Your next objective with your scope is to assign priorities, right? You want to prioritize based on those metrics and those security requirements, and your admins are the first line of defense.

Oftentimes, we see organizations that you’ve got higher up that just say, “This is all going to be classified.” Right? That’s not the best option. Organizations should be relying on their admins to help form that discussion around what the priorities should be, right? The admins are there, they’re managing the information systems and the components and the endpoints themselves. They’re going to tell you, “Hey, this network segment, this is the most vulnerable. We’re seeing a lot more bot traffic on these websites, on this web server cluster.” Use the admins to help shape the conversation around your vulnerability management program because they’re going to be the ones with eyes on the systems. Finally, once you’ve got a solid plan, all of these steps will walk you up to a solid program on paper. But ultimately, you can’t get anywhere without executive sponsorship.

Arguably, this is probably the foundational point of building a program, right? If you as a security leader cannot take your program to the executive sponsorship and translate it from the technical specifics, if you can’t get it out of the weeds and put it into that corporate jargon that your C-suites will understand, they’re not going to know why they need to function. It’s an unfortunate reality that a lot of folks see security as a funding black hole, right? You don’t generate money with security. It’s imperative that when building out of vulnerability management program, you are able to secure that executive sponsorship and make sure they are on board and understand why it’s so critical that you have a solid program in place. Those are my steps to building a solid program. What do you think of that, Cole?

Cole French:

Yeah, I think those are great initial steps. Like you mentioned, getting your program on paper, getting it approved. I think something to keep in mind here, and we talked about this, if you go back and listen to our episode on the FedRAMP exception case. We talked about this is where security breaks down actually a little bit, is we get ahead of ourselves. We get excited about the tools we’re putting in our environment and all the cool things that they can do, and we forget that we actually got to think through, “Well, what is it that we actually want to do? What are the metrics we want to meet? Do we have leadership buy-in?” And I like, Andrew, that you included that at the end because the executive sponsorship with something like vulnerability management is so important. It is in general, right? You always want to have leadership buy-in, especially when there’s money to be spent.

But with vulnerability management, something to keep in mind is you’re going to have to do hard things. You’re going to have systems that... Like Andrew, I think, touched on earlier in the scope section of what he was talking about, some of the real things in there are, what about high value assets? I got to be really careful. I got this asset that is supporting this extremely critical mission business function to patch it and remediate vulnerabilities on it. It means I got to push something out to it, which creates a risk, right? Patches do have been known to bring systems down. When I push that patch out too, let’s say it’s successful, it’s good. Most often, I got to reboot that server as an example. That’s a risk to the business that requires people to come in after hours. It requires a lot of different things.

It requires actions of users to make sure that these vulnerabilities are remediated effectively. You definitely want to have that leadership buy-in because you’re actually introducing some level of operational risk to your systems when you’re performing vulnerability remediations. Just to switch, we’ve talked about the program and building out that program, putting it on paper, getting that buy-in. Then what are the elements of vulnerability management? First we have asset management, which we’ll talk more about here in just a bit. But just to set this up, asset management is, and Andrew touched on this, understand what your assets are, where they are, and how they’re grouped without having that scope defined and understanding these assets are here, these assets are here, and the business requirements associated with them, your vulnerability management can be really hard to do. We have that, I want to make sure your assets are managed and that you have a solid asset inventory that is accurate and that is well maintained.

Then you want to have a patch management solution. We talked about this at the beginning. Patch management solution in place that’s managing all of your assets, enumerating software, deploying software, deploying updates, et cetera. Then you want to have a vulnerability scanning tool in place that’s scanning all the systems on your network, and we’ll talk a little bit more about some of the nuance of vulnerability scanning tools and things to look out for, because you can deploy a vulnerability scanning tool, have it up and running in no time, but there’s a lot of nuance and a lot of things you got to be aware of and things that can trip you up as you go along. Then compliance scanning, which typically is a part of vulnerability scanning tools. Vulnerability scanning tools will obviously enumerate vulnerabilities on endpoints.

However, they typically have another component which is compliance scanning. This is scanning endpoints against a configuration baseline. Center for Internet Security is a popular one. We see a lot DISA STIGs, stuff like that. That’s another element or another scanning component that you can include in your environment. That’s important to identify misconfigurations. That’s a little bit outside of the scope of this conversation, but it is something to keep in mind as a piece of a vulnerability management program. I would say that if you have compliance scanning that is mature and robust, that is a very, very mature and robust vulnerability management program that you have in place. But if you hit the first three, asset management, patch management and vulnerability scanning. If you can hit those and really hit them strong, you’re in a great place.

Now that we’ve outlined what a vulnerability management program looks like from putting it on paper, getting it sponsored, and putting some of those tools and components in place. Now, Andrew, if you could just go into some headaches, pain points, things like that, that organizations run into when they’re actually executing this vulnerability management process from putting it into place to actually performing those vulnerability management activities.

Andrew Overmyer:

Oh yeah, definitely. I know for a fact that one of the biggest headaches for organizations that are both just starting out with developing a vulnerability management program, but also those that have had one in existence for years, even decades. It’s grinding them to a halt. They have so many inefficiencies because of this one single problem, and that’s inventory management, right? Asset management. Being able to track your inventory effectively and efficiently. There are so many roadblocks that are generated if your admins and your vuln management leaders do not have the correct information. Some of the biggest things here, it’s not simply just knowing the name of the device, the IP address and where it lives, right? It is critical to have operating system information, manufacturer information. There are so many pieces of metadata that are important to inventory management, and having those digestible will make your vulnerability management program so much more effective, because of the fact that if you have this data in a solid inventory, whether you’re using a workbook or an application, you then are not spending time trying to identify this stuff, right?

If you’re using Microsoft WSUS and it comes back and tells you that you’ve got all these applications out a date and you’ve got to apply all these patches, you can go and effectively find and categorize those groupings of machines based on what they have. This links back to what I was talking about with having a bite-sized scope, right? With a solid inventory, you can identify similar endpoints and already have them pre-grouped to make your patching process effective. The same goes for scanning. If you’ve got a cluster of servers that are all running the same software and you know that they are the only cluster running those software, you know exactly what to look for on your vulnerability management scan.

I think the next big one is scheduling. I think this impacts almost every organization. I have not met an IT person that has not had a headache at least once in their life about patch scheduling. Patch Tuesday, everybody hates that term. It’s a nightmare for everybody. Getting a solid schedule in place is extremely difficult. But if you can get it done, it will make your vulnerability management program that much smoother. That also ties back to having a fully developed scope, because without a good scope, without good metrics in place, it’s going to be very difficult to get a schedule done. If you can create good organization when it comes to what you are scanning and what you are patching, it will enable you to have a very smooth flow, right? You cannot do a one-size-fits-all. It’s going to cause you more headaches than it’s worth.

Ultimately, more roadblocks leads to more overhead, and nobody wants to try to explain why they have to spend that much more time doing patch management. Then finally, one of the other biggest roadblocks I can think of is the remediation effectiveness. Cole, you made a very good point earlier, you had a scan last month and it showed 1,500 vulnerabilities and your organization goes through and does a solid Patch Tuesday, and you get all of these pushes and everything’s fixed up. Then the next month, now you’re up to 1,700. Even though two weeks ago you pushed X amount, you pushed 1,100 patches out. You’ve now got more than you did last month. I think the critical part there is that there is the aspect of overlap that comes from failing to accurately identify corrective actions, and effectively patching within appropriate timelines, right?

In the past, there have been instances of Windows patches, Windows updates that need to get pushed, but they required registry key edits. And a lot of times admins might overlook that. It might not be clear that they need to actually go in and apply a registry edit to enable the fix that the patch was applying. I know from my personal experience, about a decade ago, I had this issue when I was an IT admin, when I was working with my own set of systems, is we would have these patches and all of a sudden next month we’re now at the 30-day mark of, “Why weren’t these vulnerabilities fixed?” And it’s because we had a simple reg key that didn’t get adjusted correctly.

That’s one aspect of the effectiveness that needs to be identified and why testing is such an important part of vulnerability management. Why you need to ensure that your patches are tested prior to be pushed to production. Then the other aspect is the compliance requirements, right? I mentioned earlier, if you’re beholden to frameworks, if your system has FedRAMP or CMMC requirements, it’s important to make sure that you’re getting those patches done appropriately, because otherwise that opens you up to compliance failures, right? If you have high vulnerabilities that are not being remediated within that 30-day timeframe, that can really mess with your metrics quite a bit. I think inventory management, patch scheduling and the effectiveness of remediations are probably some of the biggest headaches.

Cole French:

Yeah, absolutely. I’ve seen each of those play out in my experience. I think the scheduling one, just to add some color to what you shared, appreciate that, Andrew, is with scheduling. This, again, ties back to your sponsorship, your executive buy-in, right? You got to get those windows of time when you can push patches out and do vulnerability remediation activities. Building that schedule is going to go hand in hand with having that executive leadership buy-in. Then when it comes to remediation effectiveness, I like the example that you gave, Andrew, of the regex entries that need to be updated in addition to a patch being pushed out for a particular vulnerability. But I think another aspect of that, and it’s kind of similar, is something to keep in mind is a lot of times software vulnerabilities have what I like to call a cascading effect.

What this is is I may push out a patch for a particular version of software, but the version that I’m pushing out to patch also has vulnerabilities because it may not be the most recent version. We see this a lot with Java and in software development. Anyone on any security team hears the word Java and they’re like, “Oh my gosh, this is the worst software to manage.” Because it has this cascading effect where being six versions behind creates multiple vulnerabilities, and patching doesn’t necessarily take care of that from a reporting and metrics perspective. That’s something to keep in mind, that you can actually have an instance where patching will introduce additional vulnerabilities because the software that you pushed out to patch itself has vulnerabilities. One other thing to add onto this and, Andrew, you touched on it as you went over the headaches and roadblocks that you see is those remediation timelines or what I call remediation timeliness.

When it comes to compliance, this is a key component, every framework is a little bit different. With FedRAMP, there’s requirements, and I guess, Andrew, you could probably go into more of the FedRAMP side of it, and we’ll get into compliance frameworks more specifically in a bit. But, what if I don’t meet my remediation thresholds? If I’ve defined as an organization that all my criticals need to be patched within seven days of detecting them on the network, but I have several vulnerabilities that are critical and they’re not patched. Does that mean I fail? What do I do? And I think that’s another area in which organizations sometimes fall down and they get overwhelmed and they’re like, “Well, I don’t even know how to tackle this problem. I’m so far behind.” I think the key here, and you can put this one back up towards our building out a robust vulnerability management program, is build out a process for vulnerabilities that have exceeded their remediation timeframe.

I know I’ve worked with organizations that it’s as simple as they have a monthly meeting where they look at all their vulnerability scan results that are outside their remediation thresholds, and they make action decisions in that meeting. It’s a two to four hour meeting, because it takes that long to go through some of these, but they go through them and they figure out, “Okay, what’s the next step? What’s the action I need to take?” It could be actually reaching out to a user to figure out what is going on with this machine? Why is it not on the network? Whatever the case may be, but build a process to address those vulnerabilities, and yet they’re always going to have them. There will always be issues that exceed the remediation timeframes. It’s just the world we live in. It’s way too complex, unless you’re running five machines on a network and you’re just sitting there patching every day, you’re always going to have vulnerabilities, and you’re always going to have some that push past the remediation timeframe.

But the key is, what am I doing about that? Am I taking action, number one. And number two, from a compliance perspective, can I substantiate that I took that action, right? Do I have tickets for each of these systems that I’m taking action on? Things like that, that helps to substantiate. As part of my program, I’m taking action on these ones that linger and are the most difficult. That last mile, so to speak, when it comes to effectively remediating vulnerabilities. Now that we’ve talked through inventory management, vulnerability scanning and patching, and I think pretty well established that those are the common pillars of IT, if you will. Andrew, what are some specific issues leaders should be aware of when it comes to each of these?

Andrew Overmyer:

Sure. Yeah, I want to go through three of the ones that I mentioned. With inventory management, I touched on it a bit earlier, the lackluster information, if you don’t have what you need to know and it’s easily digestible, you’re going to miss stuff, right? If you are segmenting or chunking up your patching based on groups of information system components, you need to have solid inventory information on those components. Then some other aspects that go into inventory management are insufficient automation. I think missing network segments is a big part of it too. These get a little bit more into the weeds, and I don’t want to have any scope creep here looking at how they should be managing their inventory too much. But these are key points that directly impact vulnerability management and vulnerability scanning. If you’ve got bad automation for your inventory, you’re going to miss systems, right? Very, very critical with inventory applications or inventory tools that utilize agent-based scanning.

If your agents are not configured or installed correctly, you’re going to miss endpoint systems. There’s even been instances where I’ve worked with organizations that were not performing vulnerability scans on entire network segments purely because they did what we call a set it and forget it. Somebody three years ago configured their vulnerability scanning, but instead of doing entire network segments, instead of doing, let’s say, a /24, they did very key drilled down targeted scans of specific IP addresses or even specific subnets. And because of that, after a couple of years, they set it, nobody’s reviewed it. Now all of a sudden there’s new information system components out there that aren’t even being scanned and those get missed. That can be a huge risk, a huge attack vector that’s opened up if you have unpatched systems that you’re just not aware of. Inventory management is a massive pillar to vulnerability scanning.

One of the biggest issues that I think leaders need to be aware of for patch scheduling is, again, looking at insufficient automation or relying too much on automated processes. I’m going to harp on WSUS one more time, because from my experience that’s something I’ve seen quite often, is a lot of IT leaders, especially, I think, this is a little bit more prominent in smaller organizations, is they’re going to take their WSUS server and just say, “Install every update.” But that’s not always a valid method of doing it, because of bad patching. Just like you mentioned, Cole, if the patches aren’t tested prior to being done and they’re just applied shotgun style against the wall to try and fix everything, that automated process can cause severe cascading effects down the road.

We see this a lot with third party smaller applications. A Windows patch gets applied, and all of a sudden that breaks a vendor software that then can’t be fixed for a while. There are testing needs to be done, and if you rely on automated processes alone without admin intervention, you’re going to have an issue with your patch scheduling. Yeah, Cole, I think those two that I just touched on, inventory management, patch scheduling, my perspective is that those are the two issues that leaders should be super focused in on and super aware of.

Cole French:

Yeah, absolutely. I agree with that, because those are the foundational things. If I have solid inventory management and I have solid patch management in place, that alone reduces my vulnerability landscape. Then the vulnerability scanning tool is just something I’m bolting on to those things that are already firmly in place, and I’m managing it well to begin with. That’s going to help my vulnerability management efforts. I’ll add on to what you shared as things leaders should be aware of. I think those are the two most foundational things, but then I think once those are in place and you move down to your vulnerability scanning set up and schedule, I think this is actually one where it’s pretty clear cut as to what a vulnerability scanning schedule should look like from an industry best practice standard.

Within vulnerability scanning, we have what are called asset scans. Their only purpose is they’re actually not vulnerability scans, really, they’re scans to enumerate assets on the network. I’ll talk in a second about agent scanning, which is a newer concept and does change things a bit. Think of this from a network perspective. Whatever my network segments are, every day I’m going to scan them with an asset scan, and the only purpose of that is to enumerate what is on my network, and it should enumerate enough to identify what that asset is. Is it a Windows laptop? Is it a firewall? What is it? What is the asset? Then I take that information and that feeds into the buckets of asset types that Andrew was talking about earlier in that inventory management part. If it’s a Windows laptop, I want to scan that for vulnerabilities, so I should be doing that once a week.

All of your endpoints in your environment should be scanned for vulnerabilities at least once a week. Then we talked about compliance scanning briefly a little bit outside of the scope of what we’re talking about here today, but scan for compliance misconfigurations on at least a monthly basis. Anything that has a baseline configuration applied to it that can be measured, like a DISA STIG or CIS benchmark, scan against those benchmarks monthly for all the assets in your environment for which that applies. And to go back to what I mentioned a second ago about agents and network scans and things like that, which is something you’ll hear a lot of when it comes to vulnerability scanning. This is just some of the nuance, some of the things that, like I said earlier, if you deploy a vulnerability scanning tool and you turn it on and you start scanning everything, and I’m good to go. Well, not really because there’s a lot of nuance to this.

There’s two concepts in vulnerability scanning. One is network based scans, like I mentioned, that’s scanning a network. That’s actually pinging every device on that network, for lack of a better term. Then there’s agent scans now. That is simply you deploy an agent to your workstations, servers. Devices that can support it. Then you don’t have to scan those devices anymore. That agent actually performs the scan locally on that device, bundles up the results of that scan, ships it off to the centralized console where you can look at it. From the console or the administrative interface, you can initiate an agent scan on an endpoint, if that were to be necessary. But I’ve perceived that there’s a movement towards “Well, I’m just going to use agent-based scanning,” and I think it’s important to highlight you need both.

Now, it depends. If you’re an entirely cloud-based environment, you don’t have an actual network, then that’s one thing. You can do entirely agent-based scanning. However, if you have any sort of network presence at all and you manage that network, you need to be scanning that network. Because rogue devices, that’s a huge concern in the world we have today where things get deployed on my network, get plugged in on my network, I don’t even know what they are, and if I’m not scanning my network to see if anything’s on my network, I’m never going to know. Then it just sits there. We hear a lot about vulnerabilities that were perpetrated simply because someone got on the network and they were never detected.

A vulnerability scanning tool is actually a great tool to detect devices that are unauthorized on your network. I think it’s key to keep in mind that you need both agent-based scanning, that does make things a lot easier to manage, but you still need that network-based scanning to inform a fully robust and mature vulnerability management and vulnerability scanning program. I think that’s a good segue into, “Okay, what does an effective vulnerability remediation program look like?” Andrew, could you elaborate a little bit on what an effective remediation of vulnerabilities looks like?

Andrew Overmyer:

Yeah, I think an effective remediation of vulnerabilities is somewhat situationally dependent on the organization. For those familiar with vulnerability scanning as it is or those getting into it, you’re going to find yourself face to face with a lot of different classifications for those vulnerabilities. The effectiveness of your remediation efforts is going to be heavily influenced by the vulnerability rating system that’s used. When a vulnerability is rated, we talked about before when it’s classified. We’ve talked about before about how it could be low, moderate, high, critical, et cetera. Oftentimes we’ll see even some additional numerical systems applied, right? CVSS 4.0 just came out within the past year, and they’ve now also added not only a numerical system of 0-10, but they’ve also added a subcategory that gets into more of an alphanumeric system, a little bit convoluted to go into right now. I don’t want to get too far into it, but those systems exist to help organizations and administrators effectively remediate through appropriate planning. The intent there is twofold. These rating systems look at perspective risk, where they believe from an outside perspective what the risk is to the system that has this vulnerability, and it applies that vulnerability rating to the CVE or to the vulnerability that will allow the organization to prioritize them. There’s three big rating systems that are industry standard, for lack of a better term, that are used in almost every major vendor. Those are CVSS 4.0, which I just mentioned. That’s been developed by the first organization, which is a group of international incident response. They got together, they took over the CVSS framework and they’ve updated it to 4.0. I think that was November 2023 was when 4.0 came out.

Still relatively new, but it was mostly just an update to 3.0 which has been the most common. Then we have two smaller less well-known frameworks for vulnerability rating, which is EPSS, the Exploit Prediction Scoring System, and the SSVC, which is the Stakeholder-Specific Vulnerability Categorization. EPSS attempts to determine the real value of an exploit potential. That’s a quote directly from the definition for you. And EPSS will take that and look at a couple different ratings, specifically involving metrics from industry, from real world situations of how difficult that vulnerability is to effectively exploit, right? If somebody had access to the system, how difficult is it for them to run that CVE to exploit it and to deliver whatever payload is expected? EPSS assigns a rating based on the presumed real world exploitability.

Then SSVC is very similar to CVSS 4.0, but the Stakeholder-Specific Vulnerability Categorization attempts to provide a workflow that leadership, senior admins, even C-suite that have sponsored you, they can come in and they can use the SSVC to try to determine the priority of unique vulnerabilities. We saw this a lot with Log4j, which was probably one of the largest, most well-known or prolific vulnerabilities that came out in the last decade. SSVC allows you to come in and look at it and try to determine, “Okay, it looks at real world situations. It applies a couple different metrics. It looks at what is actually impacted within your environment.” All three systems provide a similar functionality of trying to help you as an organization determine what is your best course of action. When it comes to remediation effectiveness, it really just depends on what you want to use.

What can you translate or speak to more effectively. CVSS 4.0, I think CVSS as a framework is probably the most common, and I believe is going to be used by almost every major vendor. That leads me to also mention that vendor tools, the software applications that actually perform vulnerability scans, those often will have their own form of internal metrics as well. They’re going to have their own vendor specific frameworks. Realistically, you’ll see, most likely, depending on which vendor you work with, you’re going to see them provide CVSS 4.0 score, which is the industry standard, and then they’re going to apply their own score to that CVE, to that vulnerability to add additional context. More often than not, they’re intended to be used side by side. We see organizations do that. They’re going to look at the CVSS score, then they’re going to look at the vendor score, and they’re going to make their determination based on those two.

Because the critical thing with remediation effectiveness here is that the system may determine something as a moderate, right? If you have a very small patch that, “Hey, it’s a quick fix and this exploit isn’t necessarily massively damaging to the system, but it could be bad.” So it’s a moderate vulnerability. A moderate to one person may be a critical to another, simply because of the level of security necessary for the environment. The intent of these frameworks is to help you identify those key metrics and identify the aspects of this vulnerability and make your own determination as an organization. I think those scores are intended to help organizations determine the effectiveness of the remediation efforts.

Cole French:

Absolutely, and I think a couple of important things to mention on that, Andrew, are also that the CVSS is actually a web-based database. If you’re actually curious about a particular product or a particular piece of software, you can actually look it up and you can see all the CVSS scores, information, vulnerabilities, all that kind of stuff. Yeah, it comes baked into a lot of these vulnerability scanning solutions, but it’s also a tool you can use to do research ahead of time, things like that. As far as remediation effectiveness, I think, an important thing to keep in mind with this and why these scoring systems... If you really learn them and you leverage them, like Andrew was talking about, particularly EPSS and SSVC, is it helps you to make risk informed decisions on what to do about a particular vulnerability.

Because I may have a vulnerability on a system, but it’s really only exploitable... The threat of that vulnerability is particularly present if that’s a public-facing system. But if in my environment that’s not a public-facing system, if I have all my protections in place and that is on a server that is internal to my network, well, yeah, that vulnerability still needs to be patched, but maybe I don’t need to patch it as quickly as I would if this is a public-facing server that is accessible over the internet. Just to give an example there of remediation effectiveness as part metrics, how am I measuring vulnerability remediations on one hand, and then, also, how am I making decisions on some of those remediation cases, so to speak? How am I making decisions on is this a vulnerability I need to attack right away, or is this one that I have some compensating or mitigating controls in place?

Now that we’ve talked through remediation effectiveness, and appreciate your perspective on that, Andrew. Now I want to switch to what we talked about going back to our outline of this discussion. We are going to close up with what does this mean from a compliance perspective? I know we’ve talked about compliance a lot from a vulnerability management and compliance scanning and things like that, but when I say compliance now, I’m talking my FedRAMP ATO, my CMMC Level 2 certification. What do my vulnerability management programs need to look like to meet those compliance standards? Andrew, I know you have a lot of experience in the FedRAMP world and the CMMC world as well, but if you could speak to from a FedRAMP perspective, what do I need to keep in mind to ensure that my vulnerability management program is compliant, not just once, but continuously compliant from a FedRAMP perspective?

Andrew Overmyer:

Yeah, the biggest and most critical metric for vulnerability management programs is going to be your remediation timeframes. FedRAMP requires a 30, 90, 180. For those that may not be familiar, that changed recently. If you’re coming up on Rev5 and still new to it. The 30 days for highs, 90 for moderates and 180 for lows. I think that that is probably the most important metric. That is to say one of the critical things to keep in mind here is that those timeframes are not necessarily full remediation, right? Those are addressing it. Having a remediation plan in place. From a FedRAMP perspective, that’s going to be the biggest thing. You cannot go month to month with continuous monitoring and not have at least addressed a previous month’s vulnerability. That’s going to be a big red flag for any auditor, any assessor that comes in looking at your FedRAMP program.

I think from there, once you’ve identified and your program is set up to have your timeframes met, once you’re addressing and having a plan put together for how you’re going to mitigate or remediate these vulnerabilities within the appropriate timeframe, I think the biggest thing I can harp on, again, is having too big of a bite, right? Organizations that try to get every single component under one vulnerability scan per month and then call it a day, that’s not going to fly. You have to have clearly defined boundaries or clearly defined scopes for each of your scans. They have to be scheduled appropriately, and I highly recommend that they go by classification of your inventory.

You’ve got to have them grouped in a digestible manner, because not only is that going to affect your actual remediation program, not only is it going to help your admins effectively treat and triage any vulnerabilities they find, but when it comes time for your FedRAMP and even your CMMC assessments, you’re going to have to sit down and explain your program year after year, your continuous monitoring program to these assessors, to these auditors, depending on which framework you’re working with. And if your scans are a mess, it’s just going to cause a headache for you and your auditor or assessor. Yeah, making sure you have your stuff organized and making sure you have your scheduling done appropriately and that you’re meeting your remediation timeframes. Those are the key aspects to meeting the compliance requirements of your frameworks.

Cole French:

I would add too, and you can correct me on this if I’m wrong. FedRAMP has a continuous monitoring component as well. And from what I understand, that requires you to perform scans on a continuous basis and report on that accordingly. One of the requirements of that continuous monitoring scanning and the reports that you provide is that your asset inventory... Going back, again, to what we talked about throughout this conversation, your asset inventory and your scan results have to match.

Andrew Overmyer:

Absolutely correct.

Cole French:

Just keep that in mind. Yeah, what you provide, an auditor is actually going to look at it and go, “Okay, these are the assets that you had in scope for your scan.” Then they’re going to look at those scan results. And if it’s off by one, then those scan results won’t fly. Got to do it over again.

And to Andrew’s point, we see this a lot with organizations biting off more than they can chew. They don’t have the scope, and they’re just trying to throw a vulnerability scan at everything and hope that it encapsulates the inventory that they have in scope, but it just creates a lot of overhead and a lot of back and forth. It really doesn’t move security forward. Appreciate you going over those, Andrew, on the FedRAMP side. I’ll mention CMMC real quick as we close things up here. From a CMMC perspective, it’s not as well-defined from a framework perspective as Andrew just described with FedRAMP. For instance, the CMMC framework does not define the remediation timeframes, but they do require that an organization does define those remediation timeframes. The remediation timeframes that Andrew mentioned, they’re pretty industry standard. You could go with those from a CMMC perspective.

As an auditor, if I’m looking at a CMMC organization or an organization that is seeking CMMC certification and I’m evaluating their vulnerability management program, I’m going to look at did they define the remediation thresholds. Then I’m going to look do they actually have vulnerability scanning in place? Is it appropriate? Is it configured properly? We’re also going to look at asset inventory. Then, I think, a key component, and this is the Cybersecurity Maturity Model Certification. That’s what CMMC stands for, and what we’re really pushing for is maturity in organizations. What about those vulnerabilities, I went over this previously, that are outside that remediation threshold or remediation timeframe that you’ve established? I think the biggest thing with CMMC compliance from a vulnerability management perspective is what are you doing about the vulnerabilities that are outside of your remediation timeframe?

You need to have a process in place to address those, and you need to be able to demonstrate that that process is effective and that it’s implemented and that it’s fully in place and part of the way you operate from a cybersecurity perspective. Those are just a couple of the cybersecurity frameworks out there. There’s a lot of different frameworks, but FedRAMP, CMMC, those are two of the biggest. I think the two that probably have the biggest impact... Well, CMMC is going to have a larger impact as it rolls out, but FedRAMP is pretty big for all the cloud service providers, and as we move towards leveraging cloud services more and more. Those are the big ones we wanted to hit as we wrapped up this conversation here today. Andrew, just wanted to say thank you again for taking the time to join us on the Cyber Compliance and Beyond podcast today. It was great having you. Appreciate your perspective on this topic that is so important to every organization fighting this cyber battle every single day.

Andrew Overmyer:

Absolutely. Thank you for having me. This is great.

Cole French:

Thank you to all of you out there for joining us for today’s episode. The Cyber Compliance and Beyond podcast is dedicated to answering as many unanswered questions as we can. If you have a question you’d like answered or you’d like to offer us some feedback, we’d love to hear from you. You can find us on Twitter and LinkedIn at Kratos Defense, or you can shoot us an email at ccbeyond@kratosdefense.com. Be sure to check out the show notes for additional material related to today’s episode. We hope you’ll join us again for our next episode. Until then, keep building security into the fabric of what you do.