IT Security 101: Vulnerabilities
Introduction
Vulnerability is a word heard far too often, but it is an important concept. A successful IT pro will know how to properly identify and prioritize vulnerabilities, and then apply the appropriate controls for effective remediation.
So, what exactly is a vulnerability?
Vulnerability Defined
I could provide a simple answer to that question, but being that language is another of my interests, I think it will be more fun to dissect the term to begin with.
The usual and logical starting point for any definition is Merriam-Webster (M-W). This well-known source defines a vulnerability as the noun form of the word vulnerable:
“1: capable of being physically or emotionally wounded
2: open to attack or damage : assailable
3: liable to increased penalties but entitled to increased bonuses after winning a game in contract bridge
vulnerability ”
By applying the first definition, a vulnerability can be simplified nicely as… an “ouchy”.
“Hey, that’s sensitive, don’t touch it!” Or, “Don’t scratch it, you’ll just make it worse.”
This is further supported by the word’s origin in Latin vulnus, meaning “wound”. (I suggest reading the section in M-W’s definition “The History of Vulnerable” for a clever take on the etymology.)
However, the second definition is probably more accurate for our purposes, if less fun to interpret.
The alternative to M-W is of course the Oxford English Dictionary (OED). However, their (very surprisingly modern) website requires a subscription. So…
The alternate alternative to M-W, and the alternative to OED, is of course (is it?), the Cambridge Dictionary. It defines vulnerability as:
“the quality of being vulnerable (=able to be easily hurt, influenced, or attacked), something that is vulnerable”
Thank you, very helpful indeed. This aligns with M-W’s second definition.
Now, let’s take a look at the word’s meaning in a more technical context.
The National Institute of Standards and Technology (NIST) is the de facto standards organization for all things tech. Funnily, they appear to offer two definitions:
“Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.”
“A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability. Mitigation of the vulnerabilities in this context typically involves coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”
It seems that their first definition is offered in the context of general risk management, where the second is specific to their National Vulnerability Database (NVD), and is actually the definition offered by MITRE for their CVE standards. As NIST utilizes CVE identifiers in their NVD, they have chosen to adopt the definition for that case.
In conclusion, a vulnerability can be simply defined as:
“a weakness with the potential to cause a negative outcome if realized.”
Common Vulnerability Enumeration (CVE)
I briefly mentioned something that is actually very important: The Common Vulnerability Enumeration (CVE). Developed by MITRE, this has become the de facto standard for cataloging vulnerabilities. The CVE Program Mission statement is a simple one:
“ Identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.”
The mission statement explains exactly what CVE does: it standardizes the identification and definition of vulnerabilities. The program provides a search feature on their site, and a downloadable version of the catalog, which at the time of this post, contains 271,349 records!
What makes this so useful, apart from the standardization, is that it is vendor agnostic, and centralizes vulnerabilities regardless of the technology involved. So, instead of relying on vulnerability reports from every system, application, and device vendor, many of whom do not publish the information, an IT security pro has a single source for reference. Adding to the benefit of this system is its open community of researchers who submit vulnerabilities that may not even be known to vendors.
I will now dig into a an example: https://www.cve.org/CVERecord?id=CVE-2025-2476
As seen in the example, each CVE is named according to a standard format:
CVE - [year published] - [unique id]
I could explain each field of the record, but luckily, they have provided a handy User Guide to assist. I suggest bookmarking it for reference.
Some of the critical information to focus on includes:
Severity
Product
Affected Versions
References
The first three items will help in identifying and prioritizing, and references typically include any additional resources such as vendor advisories, fixes, and work-arounds.
This standardization has been adopted by the de facto authority on tech standards, The National Institute of Standards in Technology (NIST), who has created another useful resource, the NVD.
The NIST National Vulnerability Database (NVD)
Another valuable resource and the primary central repository for vulnerabilities is NIST’s National Vulnerability Database (NVD). It contains a searchable archive of all known vulnerabilities, with their details.
It also offers useful information that aligns with the CVE standards, as well as assigning each vulnerability with a score and severity rating based on a standard system known as CVSS.
The Common Vulnerability Scoring System (CVSS)
Created by the Forum of Incident Response and Security Teams (FIRST), the CVSS is designed to provide a standard scoring system for vulnerabilities. In their own words:
“The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.”
At the writing of this post, CVSS v4.0 is the current scoring standard, however it has not been fully adopted. It is still more common to see vulnerabilities represented by v3.x scores with many still having v2.0 scores available. CVSS scores are also referred to as severity scores.
I will focus on the latest version of 3.x which is v3.1, as well as v4.0.
The standard format that describes a CVSS score is:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:N
Don’t worry. I will explain.
Each section separated by “/” represents a metric name and value pair. The two letters before the “:” represent the metric name, and the letter after the “:” represents the metric value. Think of it like this:
metric:value
The possible values of a metric are assigned a numerical value that is not displayed, but is used in calculating a score. The value then is a descriptive representation that makes it easier for humans to understand the factors that contribute to a vulnerability’s score.
The CVSS Metrics and Values
Here are the metrics and their possible values for v3.1.
Attack Vector (AV) : Network (N), Adjacent (A), Local (L), Physical (P)
Attack Complexity (AC) : Low (L), High (H)
Privileges Required (PR) : None (N), Low(L), High(H)
User Interaction (UI) : None(N), Passive(P), Active(A)
Confidentiality (C) : None (N), Low(L), High(H)
Integrity (I) : None (N), Low(L), High(H)
Availability (A) : None (N), Low(L), High(H)
There are additional, optional metrics that can further enrich the score, but are slightly beyond the scope of this post. The above metrics are referred to as the “base” metrics. The optional metrics are “environmental” and “temporal”. See the resources section at the bottom of this post for more information on the optional metrics.
As previously stated, the values describe various aspects that determine a score. The values have a range, making it easier to visualize why a vulnerability might have a higher or lower score, or severity than another.
For example: AV describes the distance an attacker could be from a target. A value of N indicates an attacker could be anywhere on a connected network, including the Internet. A vulnerability with this AV value it also referred to as “remotely exploitable” and will most likely have a higher score and severity in comparison with one that has an AV value of P, which indicates that an attacker must have physical access to a device.
From the AV metric example, it is easy to see how severity is determined. Given the vastness of the Internet, more potential malicious actors could access the target and attempt an exploitation, versus the number of potential malicious actors with physical access to the target.
Not only can we derive severity which in turn aids in prioritization, but we can also infer potential responses and controls. Following the AV metric example, if a target is remotely accessible, we can reduce the risk by cutting off its access to the Internet.
Note: A single metric alone does not determine severity, as multiple metrics contribute to the score. In general, a remotely exploitable vulnerability is going to be of higher concern for a defender; however, remember that other factors contribute to the final score, and should factor into prioritization, such as whether or not a known exploit is available, as well as factors specific to the target.
Prioritization techniques, control selection, and risk reduction, are beyond the scope of this post. Watch for future entries on these topics.
Returning to the CVSS format, it can be seen that v3.1 is less sophisticated than v4.0:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:N
CVSS v3.1 is a simple formula for determining exploitability components and impact. The first four metrics (AV:L/AC:L/PR:L/UI:N) describe the factors required for a successful exploit. The other three metrics (C:H/I:H/A:H) describe the potential impact. A quick aside, these three metrics should be familiar as they are very important concepts for IT security pros: Confidentiality, Integrity and Availability, or the CIA Triad. Look for future posts on this topic.
In comparison, CVSS v4.0 has a more complex, granular formula. It allows for a more nuanced severity range, and a more descriptive representation. Part of the reason for developing v4.0 is to “reinforce the concept that CVSS is not just the Base score.” - https://www.first.org/cvss/v4-0/
However, to limit the scope of this post, I will focus only on the base score. In CVSS v4.0 the base score is broken down into three categories. Here are the metrics and possible values for v4.0.
Exploitability Metrics
Attack Vector (AV) : Network (N), Adjacent (A), Local (L), Physical (P)
Attack Complexity (AC) : Low (L), High (H)
Attack Requirements (AT) : None (N), Low (L), High (H)
Privileges Required (PR) : None (N), Low(L), High(H)
User Interaction (UI) : None(N), Passive(P), Active(A)
Vulnerable System Impact Metrics
Confidentiality (VC) : High(H), Low(L), None(N)
Integrity (VI) : High(H), Low(L), None(N)
Availability (VA) : High(H), Low(L), None(N)
Subsequent System Impact Metrics
Confidentiality (SC) : High(H), Low(L), None(N)
Integrity (SI) : High(H), Low(L), None(N)
Availability (SA) : High(H), Low(L), None(N)
Again there are additional metrics categorized as “threat”, “environmental” and “supplemental”, but are out of scope for this topic. See the resources section for more information.
CVSS Score Severity Matrix
As briefly mentioned, the metrics and subsequent scores can be used to derive severity. Severity is a qualitative representation of the score. The following is a matrix provided by NIST showing the score ranges and their associated severity:
“*Note: The CVSS specification allows for the application of vector strings that result in a 0.0 severity score. However, NVD enrichment does not assess CVSS vector strings that have no impacts. Per the CVE Program's definition of a vulnerability, there should not be a CVE record counted that does not cause an impact to confidentiality, integrity, or availability.”
-https://nvd.nist.gov/vuln-metrics/cvss
Luckily, the severity ratings have not changed between v3.x and v4.0.
CVSS Scores in the Action
Now, I will present some real world examples to help bring it all together.
Here are two Microsoft-related vulnerabilities from this year:
CVE-2025-21333
CVE-2025-24984
Here are their v3.1 scores:
- https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
CVE-2025-21333 has a CVSS v3.1 Base Score of 7.8 giving it a severity rating of High.
- https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
CVE-2025-24984 has a CVSS v3.1 Base Score of 4.6, giving it a severity rating of Medium.
The details of each CVE can be further analyzed through cve.org or nvd.nist.gov. The affected system, as well as a description of the vulnerability, and resources such as vendor advisories, as well as available fixes and workarounds.
Conclusion
All defenders should know how to identify, categorize, prioritize and remediate vulnerabilities. It is important to understand how to utilize the CVE and CVSS frameworks effectively. In future posts I will provide more guidance on vulnerability management.
Resources
https://www.cve.org/
https://www.cve.org/CVERecord/UserGuide/
https://learn.first.org/
https://www.first.org/cvss/
https://www.first.org/cvss/training/
https://www.first.org/cvss/calculator/3-1/
https://www.first.org/cvss/calculator/4-0/
https://www.first.org/cvss/v3-1/specification-document
https://www.first.org/cvss/v4-0/specification-document
https://nvd.nist.gov/vuln-metrics/cvss/
https://nvd.nist.gov/vuln-metrics/cvss/v4-calculator/
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator/
Daily Cuppa
Today’s cup of tea is Organic Earl Grey provided by Equal Exchange.
Fair Trade, organic, and bursting with bergamot!
If you enjoyed this post or found use from it, feel free to buy the author a cup of tea.