The words that get used interchangeably and must not be

Six words, one composition

These six terms are used interchangeably in ordinary speech and are marked strictly on the paper. They are not synonyms; they compose.

• Adversary (threat agent) — the entity that mounts an attack. A person, a group, a competitor, an automated botnet.
• Vulnerability — a flaw or weakness in a system's design, implementation, operation or management that could be exploited. A property of the system.
• Threat — a potential for a violation of security that exists when there is an entity, circumstance, capability or event that could breach security and cause harm. A possibility, not an event.
• Attack — an assault on system security: a deliberate attempt to evade security services and violate the policy. A threat carried out.
• Countermeasure — anything that reduces a vulnerability, a threat or an attack — by preventing it, detecting it, or enabling recovery from it.
• Risk — an expectation of loss, expressed as a function of two factors: the adverse impact if the event occurs, and the likelihood of occurrence.

Two consequences of those definitions decide most exam answers.

A risk requires both a threat source and a vulnerability that source can reach. A severe flaw in a service that no adversary can reach carries little risk; a trivial flaw in an internet-facing service that is being scanned continuously may carry a great deal. This is why a scanner's severity score is not a risk assessment. Impact alone is not risk; likelihood alone is not risk.

A countermeasure can introduce a new vulnerability of its own, and residual risk always remains. Countermeasures do not zero risk; they change its shape. Design proceeds until the residual risk is one the organisation has decided to accept, which is a business judgement, not a technical one.

Vulnerability categories map one-to-one onto the triad

A vulnerable system is one of three things, and the mapping is the memory hook:

• Corrupted — it does the wrong thing or gives wrong answers → an integrity problem.
• Leaky — unauthorized parties obtain information from it → a confidentiality problem.
• Unavailable or very slow → an availability problem.

Consequences and actions are two different levels

RFC 4949 organises threats into four consequences, each realised by named threat actions. The level confusion — offering an action where a consequence is asked, or the reverse — is a standard exam trap.

1. Unauthorized disclosure (hits confidentiality) — exposure (data released directly to an unauthorized entity, deliberately or by error), interception (an unauthorized party accesses data in transit between authorized endpoints), inference (indirect access by reasoning from characteristics or by-products of communication — traffic analysis, or repeated limited database queries), intrusion (access gained by circumventing the protections).
2. Deception (hits system or data integrity) — masquerade (acting as an authorized entity), falsification (altering or replacing valid data, or injecting false data), repudiation (falsely denying responsibility for an act).
3. Disruption (hits availability or system integrity) — incapacitation (disabling a component), corruption (adversely modifying system functions or data so services behave unintendedly), obstruction (hindering delivery by cutting links, altering control information, or overloading).
4. Usurpation (hits system integrity) — misappropriation (seizing unauthorized control of a resource), misuse (causing a component to perform a function detrimental to security).

Two pairs get swapped, every year. Incapacitation versus obstruction: incapacitation disables the component; obstruction interferes with delivery or overloads it. Misappropriation versus misuse: the first seizes control of a resource, the second perverts a component's function.

Passive versus active, and the asymmetry that follows

Passive attacks attempt to learn or make use of information without affecting system resources: release of message contents and traffic analysis. Active attacks alter resources or affect operation: replay, masquerade, modification of messages (alter, delay, reorder) and denial of service.

The consequence is an asymmetry that is the crispest analytic point in the whole chapter, and it is the point most often reproduced backwards:

• Passive attacks alter nothing, so there is nothing to detect — but encryption prevents them outright. Emphasis: prevention.
• Active attacks are very hard to prevent absolutely, because absolute prevention would require physically protecting every path at all times. But they leave traces. Emphasis: detection and recovery — with detection acting as a deterrent, and therefore as partial prevention.

One more axis: an attack is inside or outside. An insider is any entity inside the security perimeter that is authorised to access resources but uses them in a way its authorisation does not permit — not a synonym for "employee", and invisible to every perimeter defence by construction.

Worked example — one unpatched web server, decomposed

Northreach runs its course-catalogue site on a web server whose application framework is eleven months behind on security patches, and a working public exploit for that version exists. Separate the terms.

• The vulnerability is the unpatched framework: a weakness in the system's operation that could be exploited. It is a property of the server, and it exists whether or not anybody knows about it.
• The threat is the potential for that flaw to be exploited — which is not hypothetical, because opportunistic scanners sweep the address space continuously and the exploit is public. Still a possibility, not yet an event.
• The adversary is whoever runs the scanning infrastructure: no relationship to the university, no interest in it specifically.
• The risk is both together: impact if it happens (defacement is embarrassing; a pivot from the catalogue server into the records network is severe) multiplied by likelihood (high, because the exploit is public and the host is internet-facing). Notice that neither number alone gave an answer.
• The attack is the request that arrives at 03:12 and carries the exploit payload. That is the threat becoming an event.

Now apply a countermeasure: put a web application firewall in front of the server, since patching means a release freeze nobody will approve mid-term.

This blocks the known exploit's shape, so the likelihood drops sharply and the risk with it. But look at what it also does. The firewall is a new internet-facing component with its own management interface and its own patch cycle, and it terminates TLS, so plaintext requests now exist somewhere they did not before. The countermeasure has introduced new vulnerabilities. And after all of it, an unknown exploit for the same unpatched framework would still work — the framework is still unpatched. That leftover is residual risk, and there is always some. The security question is never "is it now safe"; it is "is the residual risk one we have decided to accept, and who decided".

Now do it yourself. Decompose these two the same way, naming all six terms: (a) a shared marker account whose password is written on a note in a shared office; (b) a backup appliance that replicates to an off-site host over an unencrypted link. Then classify these six as passive or active and give the threat consequence for each: reading a message off an unencrypted wireless link · replaying a captured payment instruction · deducing which two departments are negotiating by watching message volumes · flooding the submission endpoint on deadline night · a marker denying they entered a grade · installing backdoor logic in the grading service that leaves it running normally.