When an application vulnerability is exploited, all your most confidential data could be left exposed. You could be hit with huge fines. Your customers could lose faith. And your entire organisation could fall apart.
Or, in other instances, it might not.
That’s the thing about application vulnerabilities. Some are worse than others. As a result, you need to carefully prioritise your response, dealing with the most dangerous vulnerabilities first.
Of course, we know all this. Not every vulnerability is critical. But it’s not just the vulnerabilities themselves. To make a truly informed decision about patching, you can’t stop with an understanding of each vulnerability.
You need to understand the assets that they could affect.
Your IT assets aren’t all the same
Your IT assets cross the applications you run, the hardware you run them on, and the data they’re used to process. If it’s in your organisation’s IT, it’s an asset.
That covers a huge array of different things.
It includes legacy workstations sitting in a corner, with no connection to the internet. And the servers your business depends on to do business every single day. It includes data with no real value to anyone. And all your most confidential information.
And it includes the assets covered by the demands of compliance and regulation, where the implications of a breach could be more serious.
Your assets are all different. As a result, they have different categories of risk, just as vulnerabilities have different levels of criticality. In order to prioritise your patching effectively, you need to give each asset the individual treatment it requires.
Assessing assets and application vulnerabilities together
When a vulnerability is discovered, it’s not enough to glance at a criticality rating. Because what’s a critical vulnerability on paper may not be so critical in the context of your infrastructure.
For example, picture a critical vulnerability that allows root access to a workstation. Worse, it can be exploited remotely, by anyone, anywhere. Sounds serious, right? But, if you know the vulnerable application only exists on a single node that’s isolated from the internet, there’s less risk involved. Suddenly, this critical vulnerability doesn’t seem so critical.
To get an accurate idea of how important it is to take action on a vulnerability, you need to see:
- Which vulnerabilities affect which assets?
- How many assets are affected?
- What are the nature of the assets – are they particularly high-risk?
- How critical are the vulnerabilities themselves?
- What are the potential attack vectors?
Armed with that information, you can plan a course of remedial action, eliminating the vulnerabilities that pose the highest risk first.
Understands your asset
Vulnerability intelligence is good. After all, you want to know whenever a vulnerability has been discovered, and what you need to do to resolve it.
But across all your assets, that intelligence can come thick and fast. Before you know it, you’re drowning in a sea of alerts, which makes it harder for the most important ones to catch your attention.