Nothing is Certain Except Death, Taxes, and IT System Vulnerabilities

Jocasta Norman
SEEK blog
Published in
5 min readMar 21, 2024

vulnerability /ˌvʌln(ə)rəˈbɪlɪti/ (n) — the quality or state of being exposed to the possibility of being attacked or harmed

If I were a betting type, I’d suggest that if Benjamin Franklin was re-penning his 1789 words in 2024 it might read something like this “Our new Constitution is now established, everything seems to promise it will be durable; but, in this world, nothing is certain except death, taxes, and IT system vulnerabilities.”

New vulnerabilities in IT systems and software are being discovered all.the.time by both ethically and unethically motivated parties. In 2023 alone the Common Vulnerability and Exposures (CVE) Program, a catalog of publicly disclosed cybersecurity vulnerabilities, clocked up 28 961 of them. And the number has been trending upward, doubling in just 6 years. Not all vulnerabilities are added to the CVE catalog however it provides a good framework as a basis for the process I’m about to describe. Even if only a small fraction of CVEs apply in your environment you need a way to prioritise what matters most.

triage /ˈtriːɑːʒ/ (v) — preliminary assessment in order to determine urgency

Much like when a hospital emergency department receives patients and assesses their needs to prioritise who needs treatment first, this triage stage is crucial in handling vulnerabilities too. Not all CVEs are created equally or will be applicable to your organisation. Even though they come with a handy scoring system, designed to help understand the severity, that score may not reflect the severity for you. There could be a number of factors, including controls you may have in place, which mean it’s a lower risk in your environment.

CVSS /siː-viː-ɛs-ɛs/ (acronym) — Common Vulnerability Scoring System, a free and open industry standard for assessing the severity of computer system security vulnerabilities

A fan of keeping it simple, I’d like to propose a triage process using the 5 question words the English language graced us with, in a slightly different order to that which we are typically taught: what, how, why, who, when. (Or if you like the WaHoWyWoWe Method for short, I’m kidding, although wa-howy-wowe does have a bit of a ring to it, doesn’t it?)

So jump in if you like and see if this can help you swim ahead of the CVEs coming your way too. The assumption here is that you have the means, such as scanning tools, that alert you to vulnerabilities in your environment. The what, how, why, who, when process is triaging CVEs you know apply to you. Usually the scanning tool will categorise severity based on the CVSS and/or also their in-house evaluations, however triage in the context of your environment is still needed.

  1. What: Identify and define the vulnerability
    When a new CVE alert comes on your radar, first questions are the what ones: what does this impact, what is known so far about attack vectors, what is the CVSS, what remediation is available, and what, if anything, might need to be done next. Here it’s also important to have a what criteria for determining if this jumps straight from vulnerability to an incident. This may be the case with a zero-day, where there is a vulnerability that is already being exploited in the wild and there is no patch for it yet.
  2. How: Evaluate attack vectors in context
    This is arguably the most important and likely the most time-consuming step, evaluating how that vulnerability could be exploited in your environment. It requires in-depth understanding of your landscape and what controls you already have in place. Depending on the size of your organisation and complexity of the tech eco-system, answering this question is when you pull out your best cross-functional collaboration skills. Lean on the subject matter experts (SMEs) around you to better paint a picture of the CVE in context.
  3. Why: Assess the business impact
    Once you have a better understanding of how the vulnerability could be exploited in your environment it’s time to assess why it matters. Why should other stakeholders be concerned if it was exploited? Or why does this vulnerability not matter in your environment, maybe you already have other mitigation controls in place. This is where you can re-score it, maybe recast it from Critical to Medium for example.
  4. Who: Determine responsible stakeholders to remediate and inform
    Time to get clear on who needs to take an action. Do you need all users to take an action to apply a patch, or can you push it from centralised platform management. Who else needs to know about this too? It’s always good to keep people informed and this step relies on the why being clear in order to better articulate why people need to take action.
  5. When: Establish timeline for remediation
    Work to an established baseline within your organisation’s risk appetite as to when the different levels of severity need to be addressed. Have agreed Service Level Objectives (SLOs)/Service Level Agreements (SLAs) to be met and processes in place to alert those who need to take action. Maybe a Critical CVE has an SLA of 14 days for example, keeping in mind that the patch needs to be available and there may be a testing timeframe tolerance to work within. If a CVE is deemed to require out of cycle, or immediate, remediation know your criteria in advance as there are other impacts to consider. It’s better to be prepared for different scenarios, think log4j, than making impulse decisions.

Stay safe out there in Cyber Land’s new constitution, where it is as certain as death and taxes that there will be vulnerabilities in every IT system that seems to have a promise it will be durable. Lean on the SMEs in your team, no one knows everything especially in complex environments. Cross-functional collaboration is key. As is making sure communication is clear, focusing on the why it matters and by when an action needs to be taken.

Understand what the threat is, classify how or if it could be exploited in your context, and articulate why it matters. Define who can remediate it, and then prioritise when it needs to be done to remain within risk appetite. By effectively triaging the CVEs that come your way you’ll be better positioned to get to of the ones that matter most before they are potentially exploited.

Further Reading
CVE Org
Vulnerability Metrics

--

--

Jocasta Norman
SEEK blog

Security Analyst at SEEK | Forever curious | Always learning | Idea sharer | Knowledge builder | Fuelled by kindness | Driven by community