Why IT Asset Discovery Is the Foundation of a Risk-Based Vulnerability Management Program
With over 236,000 total vulnerabilities currently known – and an average 61 new vulnerabilities added every day to the NVD – it’s impossible to remediate every single CVE or threat vector that appears. So, how do everyday organisations handle the continuously growing threats to their organisation’s end users, customers and data – especially across an increasingly hybrid and remote Everywhere Workplace?
First and foremost, it’s critical to map out your risk surface by understanding what assets are connected to your network at all times. We asked two experts - John J. Masserini, Senior Security Analyst at TAG Cyber, and Chris Goettl, Ivanti’s Vice President of Security Product Management, how to figure out organisation’s unique cyberrisk factors for vulnerability prioritisation.
Check out part of their conversation below and if you’d like to listen to the full discussion, where they share more best practices from real‑world RBVM programs – go to the webinar recording.
Discover every (also the unknown) endpoint on your network
Chris Goettl: I think everybody's got security frameworks that they rely on to help them understand and develop their cybersecurity roadmap. If you look at all of the major cybersecurity frameworks, whether it's NIST, CIS, pick your regional, you know, the cyber essentials, you know the ASD top 20, all of these will have an element in there around discovery and asset management. The reason for this is if we don't know what's in our environment, we cannot secure it. So, discovery is a foundational piece of any security program - active, passive, the ability to connect to multiple data sources and really aggregate a lot of information around your environment.
Ivanti has a lot of capabilities around discovery, and what we have found through engagement with customers and some security surveys that we've done is most organisations have between a 20-30% gap in their understanding of all devices that are actually being managed in their environment.
So, if you take six or seven data points throughout your environment - look at the endpoint management solution, the asset management solution, your endpoint protection - whether it's EDR or threat protection platform of some type - each of those are going to have a set of managed machines. Match that up with your procurement team and I guarantee you, between those different data sources, you're going to start to see double digit percentages of machines that are managed in one, not in another. So that upwards of 30% of my environment is blind to me from any one data source.
One of the most important reasons for this to be in, you know, the base and the foundation of these cybersecurity frameworks is because we need to get a view on that upwards of 30% of our blind spots in our environment because if we don't, threat actors will.
Why unknown IoT devices can pose a threat to your IT environment
Chris Goettl: A couple of things that could be a concern. One, if there's a vulnerability on that device - I mean, we've seen light bulbs used in widespread DDoS attacks. That's just one example of how a simple IoT device that no one would ever expect could be a threat could become part of a much larger scale attack.
There's a possibility that if there's a flaw on that device, could somebody remotely force that device into a state where the heating elements are turned on and left on and could it start a fire. There's a variety of ways that devices like that could be used against us.
There was a recent medical related kind of IoT device. These robots are in hospitals and they're able to move around and assist the staff in doing a variety of things, whether it's, you know, bringing the things they need to work with a patient or delivering something to a lab or something along those lines. A set of vulnerabilities were discovered in those that made it so that somebody could listen to the conversations that that device was in proximity of. Those devices could be forced to stop. They were large enough where they could block a doorway. In a medical facility, blocking a critical doorway and forcing that device to basically lock itself up and be a barrier could be detrimental at times as well.
Each of those types of devices, no matter how benign it may seem, pose potential risks to the environment. And that's where discovery in this case found a device that should be there but could be segmented out because it's something that is not manageable from a - can you patch it? Well, not really. It might have some firmware updates, but it's something that you're not going to take that level of management on. Segment those away, but make sure that you understand what's in your environment and what can be used against you.
How asset information helps prioritise patching
John Masserini: Understanding what's there is kind of like the foundation of building a vulnerability management program. I would argue, though, the next step is really understanding the criticality of those devices to, you know, fundamentally the revenue streams of the organisation.
When we look at what we're patching, how we were patching it, regardless of the program, it really all was around what outages could we afford, what was a level of revenue that was being generated by that device or that stream of devices, and how were we going to manage the outage and or who was going to accept the risk if we chose not to close the vulnerabilities? So really getting that understanding of how critical the devices are to the business lines, I think is a major driver in any kind of risk metric. When we're talking about risk-based vulnerability management, understanding how we can leverage those risks around individual devices, individual workstreams is critical.
I always leveraged a BCP program to provide that. Doing a business impact analysis, which is critical for a business continuity program, is equally as valuable to a vulnerability management program when you're trying to understand the risk of whether it's an application or an environment, whatever. When you do a business impact analysis, it's incredibly enlightening for the business as well as valuable for the IT side of the house.
Every time you walk into a business, you're going to say: ‘We want instant response time. We never want to go down and we want to guarantee customer satisfaction.’ All this kind of stuff. And you go: ‘Okay, well here's the price tag for that.’ And they go, ‘Whoa, whoa, whoa, we don't have that kind of money!’ So, you very quickly get into this discussion about, what is the minimal, acceptable standard for this? How much are you willing to say...we can afford a two-hour outage window from 2 to 4 am every other Friday or something along those lines. And really understanding that this drives 80% of the revenue of the company, so we have to be very sensitive about that. Maybe we roll patches quarterly, but we certainly do a different level of testing on those patches for environments like that compared to some internal site that we use just share memes, or whatever.
There's just fundamentally different criticality around different devices in our infrastructure that really should be evaluated and measured to make sure that we're performing the risk analysis correctly.
A lot of those things are, believe it or not, a lot of legacy things. Whether you're running old mainframes, whether you're running AS/400s, whether you're running brand new devices, but the vulnerability has to be a new firmware flash, rather than just rolling out a patch to a library. They're very different models, very different pieces of very different risk analysis. Patching an application - if you have to patch Chrome on a Windows laptop is a very different risk profile than saying: ‘Okay, I'm going to go out to this critical router and flash the firmware overnight.’ They're just completely different risks.
So, understanding how all of that plays together, I think really is between the asset discovery and the risk analytics that come out of BIA, I think the two of them, really are a phenomenal foundation on building any kind of long-term strategy around risk-based vulnerability management.
Knowing what’s on your network is the first step to understanding how to prioritise your security efforts. Taking a risk-based approach to your vulnerability management ensures you focus on your weakest links – and with asset discovery, you can identify all of them, even the hidden ones.
Continue exploring best practices from real‑world RBVM programs by watching the rest of this discussion.
