Precise language makes security findings easier to investigate and act on. These concepts describe different parts of a security situation: who might act, how they could reach a target, what weakness exists and what is exposed.
Core security concepts
Threat actor
A threat actor is a person, group or organization capable of actions that can harm systems, information or operations. Identifying a particular actor is an attribution question; responding to harmful behavior does not require that attribution to be complete.
Attack vector
An attack vector is a route or method through which an actor can attempt to reach a target or produce an unauthorized effect. Describing the vector precisely connects an abstract weakness to the access conditions that matter in a real environment.
Vulnerability
A vulnerability is a weakness that a threat could exploit. Establishing one in a particular system requires evidence of the affected condition; evaluating its risk requires additional context about access, controls and consequences.
Exposure
Exposure describes a condition that makes an asset, function or information accessible to a potential threat. It can be intentional, unnecessary or uncertain. The useful assessment asks what is reachable, by whom and under which controls.
What it is
A security glossary provides a shared vocabulary for describing conditions, activity and decisions. It should do more than replace one unfamiliar word with another. A useful definition explains the boundary of the concept, gives a concrete example and identifies what the term does not establish.
This library focuses on external exposure and related security workflows. The dedicated pages cover threat actors, attack vectors, vulnerabilities and exposure, while other articles explain technical signals such as CVE, CVSS, EPSS and KEV. These concepts connect, but none is a substitute for evidence about a particular asset.
How it works
Describe a situation in layers. Identify the asset and business function. State the observed condition. Explain the possible access path and the weakness, if confirmed. Distinguish attempted activity from a successful unauthorized action. Then describe the potential or demonstrated consequence.
Condition, event and conclusion
“A service is public” is a condition. “A login attempt was rejected” is an event. “An attacker accessed customer data” is a conclusion requiring evidence of identity misuse and data access. Reports become misleading when they move between these levels without showing the supporting facts.
Severity, likelihood and risk
Severity describes the seriousness of a weakness under stated assumptions. Likelihood concerns a defined event and time frame. Risk combines relevant likelihood and consequences in context. A numerical score is useful only when the reader knows which of these questions it answers and how it was produced.
Observation and assurance
An observation describes what a method saw from a particular perspective. Assurance is confidence supported by a body of evidence and a defined scope. One successful check can support a narrow conclusion without proving that every related system or future state is safe.
| Term | Question answered | Example |
|---|---|---|
| Threat actor | Who could cause harm? | An actor using a compromised account |
| Attack vector | Through which route or method? | A reachable authenticated API |
| Vulnerability | Which control is weak? | Missing object-level authorization |
| Exposure | What is accessible, and to whom? | An administrative interface reachable externally |
| Incident | What unauthorized activity occurred? | Evidence shows a private record was accessed |
| Risk | What likelihood and consequences matter here? | A contextual decision about the affected business workflow |
Technical references: NIST · Cybersecurity Glossary · UK NCSC · Cybersecurity Glossary
How attackers use it
The vocabulary does not cause or prevent an attack, but it helps defenders understand how an attacker could use an actual condition. A threat actor may seek an access path; that path may encounter a vulnerability; the resulting action may have a business consequence. Each relationship should be examined rather than assumed.
An attacker does not need to fit a familiar label to cause harm. Teams should respond to supported behavior and access even when motive or attribution remains uncertain. Conversely, a dramatic actor label should not make weak technical evidence appear stronger.
Warning signs
Review reports that call every open port a vulnerability, every vulnerability a breach or every certificate change malicious. Also review statements that call a service safe solely because a scan found nothing. These phrases hide missing evidence or overstate what a particular observation can establish.
Better questions
What exactly was observed? Which asset and time does it describe? What permissions or conditions are required? Is the action attempted or confirmed? What evidence would change the conclusion? These questions improve both technical analysis and communication with owners.
Business impact
Consistent terminology reduces unnecessary escalation and prevents premature closure. Engineering can act on a specific failed control, while leadership can understand the business consequence without interpreting every technical label as an incident.
Inconsistent wording can distort metrics. A report that mixes candidate matches, confirmed vulnerabilities and accepted exceptions in one count may imply a level of certainty the evidence does not support. Define the states and counting rules before comparing trends.
Prevention and remediation
Use explicit definitions in templates and review findings for unsupported jumps in certainty. Keep the raw observation, interpretation and decision separate. When a term belongs to a particular framework, preserve that framework and version where relevant.
Writing a precise finding
- Name the asset and observed condition. - Identify the source, time and material collection limits. - State the confirmed weakness or the unresolved applicability question. - Explain the relevant access path and possible consequence. - Distinguish observed activity from hypothetical impact. - Assign the next action and the evidence needed for closure.
Language should become more precise as evidence improves. Updating “suspected” to “confirmed” requires a reason; downgrading or rejecting a finding should preserve the evidence that explains the change. This makes the review history useful rather than merely tidy.
How Ariema detects or handles it
Ariema connects external observations, possible vulnerability context and follow-up evidence. The distinction between an observation, a candidate relationship and a confirmed finding is important to interpreting that workflow accurately.
Ariema’s public evidence should not be described as complete incident attribution or proof that every attack is detected. The dedicated glossary pages explain the terms needed to state what the evidence supports and where owner confirmation, authorized testing or other telemetry is required.
Common questions
Are threat, vulnerability and risk interchangeable?
No. A threat concerns potential harm, a vulnerability is a weakness and risk considers the likelihood and consequences in context. Keeping them distinct improves decisions.
Can one finding involve all these terms?
Yes. An exposed service may contain a vulnerability that a threat actor could reach through an attack vector. Evidence is still needed for each link.
Why do definitions differ between standards?
Standards use terms within particular scopes and models. Retain the relevant context and avoid assuming that a definition from one framework applies identically everywhere.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
NIST · Cybersecurity GlossaryUK NCSC · Cybersecurity GlossaryOWASP · Attack Surface Analysis