Characterising threats and vulnerabilities: intelligence, scoring and what to fix first

Objective 2.1 is new in SY0-801, and its verb is explain. It gathers in one place two things the previous exam scattered: how you learn about threats and weigh them, and how a vulnerability is named, scored and ranked. This lesson covers both halves, and it ends on the question every team actually faces: of all the things that are wrong, which one do we fix first?

Why this matters

Every organisation has more known vulnerabilities than it has time to fix, and it hears about more threats than it could ever act on. The work is not finding problems; it is ranking them. A team that patches in score order, or reacts to every alarming headline, spends its effort in the wrong place and still gets breached through the item it left at the bottom of the list.

The exam tests this as vocabulary plus judgement. You need the terms exactly — CVE is not CVSS, likelihood is not impact — and you need to recognise the scenario in which the "obvious" answer, the highest score, is wrong.

The lesson

Threat feeds and intelligence sources, and how to judge one you did not write

Threat intelligence is information about adversaries — who they are, what they target, the tools and techniques they use, and the evidence they leave — gathered so that you can make better decisions. A threat feed is a stream of that information, usually machine-readable, that your tools can consume.

The sources fall into a few families:

• Open-source intelligence (OSINT) — government advisories, vendor security bulletins, researchers' write-ups, public reporting. Free, broad, and of very uneven quality.
• Commercial or proprietary feeds — paid services that curate, de-duplicate and add context. You are paying for analysis and for lower noise.
• Sharing communities — sector groups such as information sharing and analysis centres, where organisations facing the same adversaries exchange what they have seen.
• Internal sources — your own incidents, logs, detections and honeypots. Often the most relevant intelligence you have, because it is about attacks on you.

Feeds also differ in what they carry. Some are lists of indicators — file hashes, IP addresses, domains. Others describe behaviour: the techniques an actor uses and the sequence they follow. Indicators are easy to block and age quickly, because an attacker can change an address in minutes; behaviour is harder to act on but far more durable. Formats such as STIX (a language for describing threat information) and TAXII (a way of exchanging it) exist so that feeds can be ingested automatically by a SIEM or firewall.

Judging a feed you did not write comes down to four questions:

• Is it timely? An indicator list that is a week old may describe infrastructure the attacker abandoned days ago.
• Is it relevant? A feed about attacks on a sector you are not in, or on technology you do not run, is noise.
• Is it accurate? Blocking on a feed full of false positives blocks real customers, and teams learn to ignore it.
• How confident is the source? Good intelligence states its confidence and where it came from. One that never admits uncertainty is the one to trust least.

Likelihood and impact, the two numbers every threat discussion reduces to

However a threat is described, deciding what to do about it comes down to two questions: how likely is it to happen to us, and how bad would it be if it did? Risk is the combination of the two.

Likelihood is driven by things you can reason about: whether an actor with the capability and the intent exists, whether the weakness they would use is present and reachable, whether a working exploit is available, and what controls stand in the way. Most security likelihood is a judgement expressed on a scale — rare, unlikely, possible, likely, almost certain — because attacker behaviour does not produce the clean statistics that hardware failure does.

Impact is the consequence, and it has several dimensions worth assessing separately: financial loss, operational disruption, reputational harm, regulatory and legal exposure, and, for some organisations, physical safety.

The useful habit is to notice which of the two a piece of information changes. Threat intelligence mostly moves likelihood: a report that a vulnerability is now being exploited widely makes the same flaw more urgent without changing what it would do to you. Knowing what a system holds and how the business depends on it moves impact. The risk management lesson in Domain 5 turns these two factors into a register and a treatment decision.

The threat life cycle, from first report to exploitation in the wild

Threats are not static. A typical vulnerability moves through a recognisable life:

1. Discovery — by a researcher, a vendor, or an attacker. If an attacker finds it first and uses it before anyone else knows, it is a zero-day.
2. Disclosure — ideally privately to the vendor, under a coordinated disclosure policy, followed by a public advisory and an identifier.
3. Fix — the vendor releases a patch or a workaround.
4. Weaponisation — working exploit code appears. Publication of a patch often speeds this up, because a patch shows where the flaw was.
5. Exploitation in the wild — first targeted use, then, for attractive flaws, automated mass exploitation of everything still unpatched.
6. The long tail — the flaw stays in use for years against systems nobody updated.

The defender's job is to close the gap between stages 3 and 5 for their own estate. The dangerous period is not the zero-day, which is rare; it is the days and weeks after disclosure, when the flaw is public and your systems are not yet fixed.

The term is also used for the intelligence life cycle — the process that produces intelligence in the first place: set requirements (what do we need to know?), collect, process, analyse, disseminate to the people who act on it, and gather feedback to refine the requirements. If an exam question frames life cycle as steps an intelligence team follows, that is the cycle it means.

CVE identifiers, CWE weakness classes and the NVD, and what a CVSS base score leaves out

Four names that are routinely confused:

• CVE (Common Vulnerabilities and Exposures) is an identifier — a unique name for one publicly known vulnerability, in the form CVE-2024-12345. The number is assigned by a CVE Numbering Authority, typically the vendor or a coordinating body. It is a label, not a severity.
• CWE (Common Weakness Enumeration) is a catalogue of weakness types — SQL injection, cross-site scripting, missing authentication, and hundreds more, each with its own number. A CVE is one instance; its CWE says what kind of mistake caused it.
• NVD (National Vulnerability Database), run by the US National Institute of Standards and Technology, takes published CVEs and adds analysis: severity scores, the CWE, and which products and versions are affected.
• CVSS (Common Vulnerability Scoring System), maintained by the forum of incident response teams known as FIRST, is the score: 0.0 to 10.0.

CVSS base metrics describe the vulnerability itself. In version 3.1 they are: attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction, scope, and the impact on confidentiality, integrity and availability. The qualitative bands are low 0.1–3.9, medium 4.0–6.9, high 7.0–8.9 and critical 9.0–10.0. A flaw reachable over the network, with low complexity, no privileges, no user action and high impact on all three properties scores 9.8. CVSS 4.0, published in 2023, keeps the same bands and renames the temporal group as threat metrics.

What the base score leaves out is everything about you. It does not know whether the flaw is being exploited, whether your vulnerable system is internet-facing or isolated, what the system holds, or what controls already protect it. FIRST itself says CVSS measures severity, not risk. The threat and environmental metric groups exist to add some of that context, and in practice most organisations add it outside the score.

Vulnerability types and prioritisation: why the highest score is not always first

Vulnerabilities come in recognisable types, and the type tells you who can fix it and how: flaws in application code, in the operating system, in hardware and firmware, in configuration, in cryptography, in third-party components you depend on, and the zero-day for which no fix yet exists. Objective 2.4 takes these one at a time, in the lessons on application, code and operating-system vulnerabilities and on attack surfaces.

Prioritisation combines the score with the context it lacks:

• Is it being exploited? Public lists of vulnerabilities known to be exploited — the US government's KEV catalogue is the best known — answer this directly. Probability models such as EPSS estimate how likely exploitation is in the near future.
• Is it exposed? Internet-facing beats internal; reachable beats segmented.
• How critical is the asset? What it does, what data it holds, what depends on it.
• What already protects it? A compensating control can lower urgency without fixing the flaw.

The reasoning the exam expects: an internet-facing, actively exploited medium-severity flaw is more urgent than an internal critical with no known exploit. The score tells you how bad the flaw could be; the context tells you how likely it is to hurt you this month. The vulnerability management lesson in Domain 4 takes the ranked list and turns it into remediation, validation and reporting.

What to take into the exam

• CVE names a vulnerability; CWE names its type; NVD enriches it; CVSS scores it. Bands: low 0.1–3.9, medium 4.0–6.9, high 7.0–8.9, critical 9.0–10.0.
• A CVSS base score measures severity in the abstract. It says nothing about exploitation, exposure or asset value.
• Judge a feed on timeliness, relevance, accuracy and stated confidence. Indicators age fast; behaviour lasts.
• Intelligence mostly changes likelihood. The asset changes impact.
• The dangerous window is between public disclosure and your patch, not the rare zero-day.
• Exploited and exposed outranks a higher score that is neither.