The whole chapter is one chain. Read it as a single story and every term snaps into place:
asset → vulnerability → threat → attack → consequence (CIA) → countermeasure / risk / design principles
The entire discipline hangs off three questions, asked in order. They are also the backbone of this lesson:
Computer security is the precise answer to all three at once. The canonical NIST definition: measures and controls that ensure confidentiality, integrity, and availability of information system assets including hardware, software, firmware, and information being processed, stored, and communicated. Notice the definition is built from the same three pieces we will keep meeting: the objectives (CIA), the assets, and the means (controls). The plain reading: security is not only about keeping secrets, it is about keeping the whole system doing the right thing for the right people.
Cyber-01 owns the framing layer — the three questions as a way of thinking, the attack surface, and attack trees as a modelling habit. This lesson (Cyber-02) owns the concept and terminology chain: every word the exam can ask you to define, threaded onto that chain. The two cross-reference rather than repeat.
Security is a process, not a product: you cannot buy it once and be done. The attacker needs to find one hole; the defender must close all of them. That asymmetry is why everything downstream is hard, and it is examined directly.
Before you can talk about threats or defences you have to say what is worth protecting — every other term in the chapter is defined by its relationship to the asset, so we start here. What is an asset, exactly? A system resource (asset) is data, a service provided by a system, a system capability, an item of system equipment, or a facility that houses system operations and equipment. In plain terms, an asset is anything an owner places value on and would lose something if it were harmed.
Those assets all fall into exactly four categories, and the exam expects you to attack each one across all three CIA properties. Keep this table countable — 4 rows, 3 columns:
| Asset category | Availability attack | Confidentiality attack | Integrity attack |
|---|---|---|---|
| Hardware | Equipment stolen or physically disabled | Unencrypted USB drive stolen | (rarely a primary target) |
| Software | Programs deleted (denial of service) | Unauthorised copy made (piracy) | Program modified to fail or to do an unintended task |
| Data | Files deleted | Unauthorised read; statistical inference | Files modified or fabricated |
| Communication lines & networks | Messages destroyed; lines made unavailable | Messages read; traffic patterns observed | Messages modified, delayed, reordered, duplicated; false messages injected |
The asset sits at the left edge of the chain, and everything downstream points back to it: a vulnerability is a weakness in an asset; a threat is the potential to harm an asset; the CIA tag names which way the asset was harmed. So when a question gives you a scenario, your first move is always the same: which asset, and which CIA property of it?
The WannaCry ransomware lights up the table all at once: it encrypted data (integrity/availability of data), locked users out until they paid (availability), and spread through a network vulnerability (communication lines). One real attack, multiple asset categories, multiple CIA properties — which is exactly how to reason about impact.
Data is usually the most exposed asset (it can be read, changed, and deleted), but never forget hardware: a stolen laptop defeats every clever software control on it.
“Harm to an asset” is too vague to act on, and CIA is what makes it concrete: there are only three ways an asset can be harmed, so every attack in the whole course resolves to one (or more) of them. CIA is therefore the consequence node of the chain — the answer to “which property just broke?”, the reflex graded on every scenario question.
Click each ring to study its precise definition, its sub-concepts, the canonical “loss” statement, and example threats.
The triad, kept countable (3 members):
Two often-added properties. Many professionals extend CIA with two more — not a second triad, just a fuller picture:
The same idea graded as “in what circumstances is a loss very damaging?”: a defaced one-off poll is trivial; a downed public university site is embarrassing; a corrupted hospital allergy database can kill someone and create massive liability. Reach for the hospital-allergy case for a high-integrity example and a bank-login outage for high-availability.
The same CIA frame carries into the AI chapter. Model-stealing and membership-inference attacks break confidentiality (recovering a proprietary model or its training data); adversarial examples and data poisoning break integrity (forcing wrong predictions); flooding an inference endpoint breaks availability. The asset is just a model and its training data — same chain, same three properties.
CIA is derivable, not memorised in isolation: ask “was something read (C), changed (I), or made unusable (A)?” Every later attack type in this lesson is just a labelled path to one of these three.
These three words are the heart of the chain and the most common source of exam confusion. They are not synonyms — they are three points on a single timeline, from latent weakness to realised damage.
Read them as one sentence, with the classic unlocked-door analogy:
Behind most of this sits an attacker. An adversary (threat agent) is the entity that attacks or threatens a system — an individual, group, organisation, or government with the intent to do harm. Crucial nuance kept from the chain: not every threat has an intelligent adversary. A flood threatens availability with no attacker; some denial-of-service is crude rather than “intelligent.” That is exactly why threat and adversary stay separate words.
The distinction the exam keeps probing is exactly this one: threat = potential; attack = realisation. A vulnerability is the weakness the attack exploits; the threat is the looming possibility; the attack is the act. State all three relationships and you have the high-grade answer.
Once an asset has been successfully attacked it ends up in one of three states, and these map straight onto CIA — a favourite question:
| State | Meaning | CIA broken |
|---|---|---|
| Corrupted | The system does the wrong thing or gives wrong answers; stored values differ from what they should be. | Integrity |
| Leaky | Someone who should not have access to information obtains it. | Confidentiality |
| Unavailable / very slow | Using the system becomes impossible or impractical. | Availability |
Pulling the terms together gives the relationship model the chapter keeps returning to: owners value assets and want to minimise risk; threat agents give rise to attacks that exploit vulnerabilities and raise risk; countermeasures lower risk but may add cost or new weaknesses. Some residual vulnerability always remains — the realistic goal is minimising residual risk, not eliminating it.
flowchart TD
O[Owners] -->|wish to minimise| R[Risk]
O -->|value| A[Assets]
A -->|wish to abuse| T[Threats]
A -->|may damage| TH[Threat Agents]
T -->|increase| R
TH -->|give rise to| AT[Attacks]
V[Vulnerabilities] -->|increase| R
AT -->|exploit| V
C[Countermeasures] -->|reduce| R
C -->|impose| O
Vulnerability is a noun about the asset; threat is a possibility; attack is a verb that happened. If you can place a scenario on that timeline, you can answer almost any “threat vs attack” question.
Once an attack happens we sort it, because the category dictates the defence: passive attacks you mostly prevent, active ones you mostly detect and recover from. There are two axes (active/passive, inside/outside) plus the online/offline distinction.
Passive attacks try to learn or use information without affecting system resources. They are hard to detect (nothing changes), so the emphasis is prevention, typically encryption. Two types, both CIA-tagged to confidentiality:
Active attacks involve modification of the data stream or the system itself. They are hard to prevent, so the emphasis is detection and recovery. Four types:
Subtle mapping the professor flags explicitly. Replay gains no new information beyond what plain traffic analysis already gives (so it is not a confidentiality loss), and it does not take the service down (so it is not availability). What it does is cause an unauthorised effect — an action that should not have happened — which is an integrity violation. Countermeasure: session tokens / nonces or timestamps so a captured message cannot be reused.
DoS = Denial of Service, an active attack on availability (e.g. flooding a web server’s open HTTP ports). Modern systems rate-limit per host; a DDoS (Distributed DoS) defeats that by using many compromised hosts — a botnet — at once. The Mirai botnet (compromised IoT devices) is the textbook example. Note: misappropriating the botnet machines is itself usurpation (section 6).
Inside attack — launched by an entity inside the security perimeter (an insider) who is authorised to access resources but uses them in unauthorised ways. Outside attack — launched from outside the perimeter by an unauthorised user, ranging from amateur pranksters to organised crime, terrorists, and hostile governments. Insiders are dangerous precisely because they start past the front door.
A cross-cutting distinction (it returns in Chapter 3 for password cracking). An online attack interacts with the live target in real time — e.g. trying passwords against a login page — so it can be throttled by rate limiting and account lockout (at the cost of enabling a lockout-based DoS). An offline attack works on captured material with no live interaction — e.g. cracking a stolen password-hash file — countered by strong hashing, salting, and denying access to the captured asset in the first place.
The classification is the defence strategy: passive → prevent (encrypt); active → detect and recover; insider → least privilege and accountability; offline → protect the captured asset.
Section 5 sorted attacks by how they operate; here we sort them by their result instead. There are exactly four threat consequences, each is a successful attack’s outcome, and each maps to a CIA property. For full marks you must, per family: (1) name it, (2) give its CIA tag, (3) list its sub-types, (4) give an example. Keep it countable: 4 families, with 4 + 3 + 3 + 2 sub-types.
| Consequence (CIA) | Sub-types | Each, briefly + example |
|---|---|---|
| Unauthorised Disclosure Confidentiality |
Exposure, Interception, Inference, Intrusion (4) | Exposure: sensitive data released, deliberately or by error (an insider leaks card numbers). Interception: directly accessing data in transit (sniffing a LAN). Inference: deducing data indirectly from characteristics (traffic analysis). Intrusion: circumventing access controls to reach data. |
| Deception Integrity (data or system) |
Masquerade, Falsification, Repudiation (3) | Masquerade: posing as an authorised entity (Trojan horse, stolen credentials). Falsification: altering valid data or inserting false data (a student changes a grade). Repudiation: falsely denying having sent or received something (e.g. a customer denies authorising a payment that the transaction logs clearly record, or claims a digitally signed e-mail was forged to escape a contract). |
| Disruption Availability or system integrity |
Incapacitation, Corruption, Obstruction (3) | Incapacitation: disabling a component (physical destruction, malware). Corruption: malicious modification that alters how the system behaves (backdoor logic). Obstruction: hindering operation by overloading or cutting communication links (DoS). |
| Usurpation System integrity |
Misappropriation, Misuse (2) | Misappropriation: assuming unauthorised control of a resource (theft of service via a DDoS botnet). Misuse: making a component perform a function that subverts security (e.g. a rogue system administrator disables the password-expiration policy and audit logging to plant persistent backdoor accounts). |
These families are not a new list to learn cold — they are the section-5 attacks re-sorted by outcome. Masquerade appears both as an active attack and as a deception sub-type; DoS appears as an active attack and as the obstruction sub-type of disruption. The professor’s shorthand “unauthorised disclosure of information” is simply the confidentiality family by another name.
Four families, four CIA hooks: Disclosure → C, Deception → I, Disruption → A, Usurpation → system-I. If you can recover the sub-types under each, you own one of the most-asked areas of Chapter 1.
Before defending, you have to see where you can be hit and how an attacker would chain steps together. The attack surface answers “where?” and the attack tree answers “how?” — both are the bridge from threats (sections 4–6) to countermeasures (section 8).
The attack surface is the set of reachable and exploitable vulnerabilities in a system — every door and window, locked or not. Examples: open ports and the code listening on them; services inside a firewall; code that parses incoming data (email, XML, PDFs, office docs); APIs, SQL queries, web forms; and an employee who can be socially engineered. It sorts into three categories:
Vulnerabilities reachable over the enterprise network, WAN, or Internet: protocol flaws, DoS, link disruption, remote intruders.
Vulnerabilities in application, utility, or OS code — web-server software especially.
Vulnerabilities from people: social engineering, human error, trusted insiders.
An attack surface analysis is a systematic assessment of the scale and severity of these threats. It tells developers where mechanisms are needed and how to prioritise testing and hardening. Two complementary defensive moves follow from it: attack-surface reduction (remove doors — the KISS instinct from section 9) and defense in depth / layering (guard each door more than once).
An AI system widens the attack surface with doors that classical software does not have: the training data (poisoned to plant backdoors), the model inference endpoint (probed for adversarial examples or to steal the model), and exposed gradients / confidence scores (leaked to mount membership-inference attacks). Mapping these onto the same network/software/human categories — and back onto CIA — is exactly the modelling habit this section trains.
A pharming attack redirects a victim’s traffic to a fake server — e.g. by editing /etc/hosts, running a rogue DHCP server, or poisoning DNS, and for HTTPS by subverting the browser’s trusted certificate store. It is a masquerade (the fake site poses as the real one), hence a deception consequence threatening integrity/authenticity, and it leans on the human attack surface. (Scanning the surface in practice is a tooling exercise — nmap, nikto — covered in the tutorials, not here.)
An attack tree is a branching, hierarchical structure of the techniques for reaching a goal. The root is the attacker’s overall goal; internal nodes are progressively more detailed sub-goals; the leaves are the concrete ways to initiate an attack. Nodes combine in two ways:
Branches can carry values (cost, difficulty, probability) so analysts can rank attack paths and aim countermeasures at the cheapest ones. The example below models compromising Internet-banking authentication, built by considering three components: the user terminal/user (UT/U), the communication channel (CC), and the Internet banking server (IBS).
flowchart TD
R[Bank Account Compromise] --> A[User credential compromise]
R --> B[User credential guessing]
R --> C[Injection of commands]
R --> D[Security policy violation]
R --> E[Use of known authenticated session]
A --> A1[User surveillance]
A --> A2[Theft of token and notes]
A --> A3[Malicious software installation]
A3 --> A3a[Hidden code]
A3 --> A3b[Worms]
A3 --> A3c[E-mails with malicious code]
A --> A4[Sniffing]
A --> A5[Social engineering]
A5 --> A5a[Web page obfuscation]
B --> B1[Brute force attacks]
C --> C1[Pharming]
C --> C2[Active MITM]
E --> E1[Session hijacking with preset session ID]
You may be asked to draw a small tree (e.g. open a physical safe). Remember: root = goal, leaves = ways to start, AND = all children needed, OR = any child enough.
This is the right edge of the chain — the answer to question 3. Having identified assets, threats, and the surface, we now decide what to do, and the logic runs in order: estimate risk, write a policy, deploy mechanisms, and gain confidence through assurance and evaluation.
Risk is an expectation of loss, expressed as the probability that a particular threat exploits a particular vulnerability with a particular harmful result — note it is built from the very terms of section 4. It is usually plotted on a risk matrix (likelihood × impact). A countermeasure is any action, device, procedure, or technique that reduces a threat, vulnerability, or attack — by preventing it, minimising the harm, or discovering and reporting it. Countermeasures can themselves add cost or new vulnerabilities, so the goal is to minimise residual risk, never to reach zero.
A security policy is a set of rules and practices specifying how a system or organisation provides security services to protect sensitive and critical resources (a password policy — strength, expiry — is the classic example). Writing one weighs three factors — the value of the assets, the system’s vulnerabilities, and the threats and their likelihood — and balances two trade-offs: ease of use vs security, and cost of security vs cost of failure and recovery. Ultimately it is a business decision.
A security mechanism exists to do four things, and they are also the four implementation courses of action — an ordered fallback from ideal to last-resort:
No single mechanism covers every service, and prevention is not always possible — which is exactly why detection and recovery are first-class, not afterthoughts.
Assurance is the degree of confidence (not proof) that the design meets its requirements and the implementation meets its specification. Evaluation is the process of examining a product or system against defined criteria, via testing and possibly formal/mathematical analysis. Together they let you justify trust rather than assume it.
You cannot prevent everything, so good security is a layered loop: prevent → detect → respond → recover, sized by risk and written down as policy. That loop is the operational face of “security is a process, not a product.”
No technique prevents all unauthorised actions, so we fall back on principles that have survived decades of practice — rules for designing mechanisms that are themselves hard to defeat. The exam can ask you to list all 13 and define any one, so keep them countable, clustered:
Keep security measures as small and simple as possible — the KISS rule. What is not there cannot break; simple designs are easier to test, verify, and maintain. Directly serves attack-surface reduction (section 7). Example: a single-purpose packet-filtering firewall has far less code — and far fewer exploitable bugs — than an all-in-one security appliance bolting together VPN, antivirus, and content filtering in one box.
Base access on permission, not exclusion; the default is no access. A mistake then fails by refusing (safe) rather than granting. Example: a deny-by-default firewall rule or access-control list blocks a newly added employee until permissions are explicitly granted; an allow-by-default system would expose resources to everyone until someone remembers to revoke access.
Check every access against the access-control mechanism; never trust cached decisions. Rarely fully implemented because it is resource-intensive — a live tension with performance. Example: checking permissions only when a file is first opened, but not on each subsequent read, is faster but lets a user keep reading after their access has been revoked.
The mechanism should be open, not secret; security rests on the key, not on hiding the algorithm. Open designs get reviewed by many experts. This is Kerckhoffs’s principle, revisited as the foundation of public crypto standards in Cyber-03. Example: the AES algorithm is fully published, yet its security depends entirely on the secret key (128–256 bits), not on hiding how it works — whereas proprietary “secret” ciphers (e.g. the GSM A5/1 and the Mifare Crypto-1 schemes) were broken soon after being reverse-engineered.
Require multiple privilege attributes for a restricted resource. Example: multi-factor authentication demands both a password and a one-time code from a smart card or phone, so a stolen password alone is useless. Links forward to Cyber-04 authentication.
Every user or process runs with the minimum privileges needed. Example: a web server runs under an unprivileged www-data account so that a code-execution exploit cannot immediately become root; role-based access control and admins using ordinary accounts for daily work follow the same rule. Tension: least privilege vs usability.
Minimise functions shared between users to cut unintended communication paths and ease verification. Example: giving each tenant its own database instance instead of one shared table removes a covert channel through which one customer could infer or corrupt another’s data.
Mechanisms must not unduly burden users, or they will switch them off; security must fit the user’s mental model. Example: a password policy demanding 20-character strings rotated weekly backfires — users write them on sticky notes or pick predictable patterns — whereas a passphrase plus a one-tap push prompt is secure and usable. Tension: acceptability vs strict security.
Three contexts: (1) public access isolated from critical resources, (2) user processes/files isolated from each other, (3) security mechanisms isolated from tampering. Example: running an untrusted browser tab or email attachment inside a sandbox (or a public web server in a DMZ separated from the internal database) so a compromise cannot reach the rest of the system.
A form of isolation from object-orientation: internals reachable only through designated entry points. Example: a hardware security module (HSM) or TPM holds private keys and exposes only a sign/decrypt operation — application code can use the key but can never read it out.
Build security functions as separate, protected modules so parts can be upgraded without a full redesign. Example: one shared, audited cryptographic library (e.g. OpenSSL) serves TLS, SSH, and disk encryption, so patching a single vulnerability (such as Heartbleed) fixes every protocol at once instead of touching each application.
Use multiple overlapping protections (people, technology, operations) so one failure does not expose the system. Example: a sensitive server sits behind a network firewall, then a host firewall, then requires authentication, then encrypts its data at rest — an attacker who defeats one layer still faces the next. The complement to attack-surface reduction.
A program or interface should respond in the way least likely to astonish the user, so security goals map intuitively to behaviour. Example: a “Delete account” button that actually deletes (rather than merely deactivating) the account, and a permission prompt that names the exact app and access requested, prevent users from unknowingly granting more than they intend.
The principles pull against each other — and naming the tension is what earns the high grade: complete mediation vs performance; least privilege vs usability; psychological acceptability vs strict security. Design is choosing where on each line to sit, for this asset and this risk.
Two theses tie the chapter shut: open beats closed (open design / Kerckhoffs — secrecy of mechanism is fragile, secrecy of the key is not), and the weakest link is the humanware (psychological acceptability and the human attack surface exist because people, not hardware, are easiest to bypass). Security is a process, not a product — and it is only as strong as that weakest link.
The following questions are drawn from real past exams. Use them to test your preparation. Each answer is grounded in the slides and textbook.
Computer security (NIST definition) is the protection afforded to an automated information system to attain the objectives of preserving the integrity, availability, and confidentiality of information system resources. It includes hardware, software, firmware, information/data, and telecommunications.
Confidentiality covers two related concepts: (1) data confidentiality — private or confidential information is not made available or disclosed to unauthorised individuals; (2) privacy — individuals control what information related to them may be collected, stored, and to whom it may be disclosed.
Integrity guards against improper information modification or destruction, including ensuring non-repudiation and authenticity. Data integrity ensures that information and programs are changed only in a specified and authorised manner. System integrity ensures that a system performs its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorised manipulation.
Availability ensures timely and reliable access to and use of data and services. A loss of availability is the disruption of access to or use of information or an information system.
Confidentiality, Integrity, and Availability. These three concepts embody the fundamental security objectives for both data and for information and computing services.
Authenticity is the property of being genuine and being able to be verified and trusted. It provides confidence in the validity of a transmission, a message, or a message originator. FIPS 199 includes authenticity under integrity.
Accountability generates the requirement for actions of an entity to be traced uniquely to that entity. It supports non-repudiation, deterrence, fault isolation, intrusion detection and prevention, and after-action recovery and legal action.
KISS stands for “Keep It Simple, Stupid” and corresponds to the principle of Economy of mechanism: security measures should be as simple and small as possible. Simple designs are easier to test, verify, and maintain, and have fewer exploitable flaws.
Security requires regular and constant monitoring. It is not something you buy and install once; it is an ongoing process of assessment, adaptation, and improvement. Good security is invisible when working, and bad security only becomes visible after a security incident. Additionally, security is costly and often seen as an impediment, but this ongoing process view is essential.
Examples: an insider releases credit card numbers; unencrypted data is intercepted on a network; statistical analysis reveals underlying personal data. Loss of confidentiality is very damaging for assets with a high confidentiality rating, such as student grade information (regulated by FERPA) or patient medical records.
Examples: a student alters grades; a database of patient allergies is falsified. Loss of integrity is very damaging when the consequences are severe or catastrophic, such as the hospital allergy database example — inaccurate information could result in serious harm or death and expose the hospital to massive liability.
Examples: files are deleted; communication lines are rendered unavailable; authentication services are interrupted. Loss of availability is very damaging for critical services such as authentication systems for banking, where interruption causes large financial loss and prevents customers from accessing resources.
An adversary (threat agent) is an individual, group, organisation, or government that conducts or has the intent to conduct detrimental activities against a system.
An attack is any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself. It is a deliberate attempt to evade security services and violate the security policy of a system.
A threat is a potential for violation of security — a circumstance or event that could breach security and cause harm. An attack is a threat that is actually carried out (threat action). In other words, the threat is the potential; the attack is the realisation. Some threats are not very “intelligent,” for example certain Denial of Service attacks are rather simple.
A countermeasure is an action, device, procedure, or technique that reduces a threat, vulnerability, or attack by eliminating or preventing it, by minimising the harm it can cause, or by discovering and reporting it so that corrective action can be taken.
Risk is an expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result. It is often visualised using a risk matrix that maps likelihood against impact.
A security policy is a set of rules and practices that specify or regulate how a system or organisation provides security services to protect sensitive and critical system resources. Example: an organisation’s password policy (strong passwords, expiration) is part of its security policy.
A system resource (asset) is a major application, general support system, high-impact program, physical plant, mission-critical system, personnel, equipment, or a logically related group of systems. More broadly: data, a service provided by a system, a system capability, an item of equipment, or a facility.
A threat is any circumstance or event with the potential to adversely impact organisational operations (including mission, functions, image, or reputation), organisational assets, individuals, other organisations, or the nation through an information system via unauthorised access, destruction, disclosure, modification of information, and/or denial of service.
A vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. Example: a software bug, or users not properly educated to deal with email phishing.
A system is corrupted when it does the wrong thing or gives wrong answers, because data values have been improperly modified. This is a loss of integrity. It can be serious depending on the criticality of the data (e.g., hospital records).
A system is leaky when someone who should not have access to information obtains such access. This is a loss of confidentiality. It can range from minor (directory information) to catastrophic (exposure of classified data).
A system is unavailable when using it becomes impossible or impractical (e.g., very slow or completely unresponsive). This is a loss of availability. It affects both data availability and services availability.
Passive attacks attempt to learn or make use of information but do not affect system resources. They are difficult to detect; emphasis is on prevention (encryption). Active attacks involve modification of the data stream or the attacked system. They are difficult to prevent; emphasis is on detection and recovery.
Inside attacks are initiated by an entity inside the security perimeter (an “insider”) who is authorised to access system resources but uses them in unauthorised ways. Outside attacks are initiated from outside the perimeter by an unauthorised or illegitimate user.
Unauthorised disclosure is a threat to confidentiality. Exposure: sensitive data directly released (deliberate or by error). Interception: unauthorised entity directly accesses data in transit. Inference: indirect access by reasoning from characteristics (e.g., traffic analysis). Intrusion: unauthorised access by circumventing security protections.
Deception is a threat to integrity (data or system). Masquerade: posing as an authorised entity (e.g., Trojan horse). Falsification: altering or replacing valid data or introducing false data. Repudiation: falsely denying responsibility for an act.
Disruption is a threat to availability or system integrity. Incapacitation: disabling a system component (e.g., physical destruction, malware). Corruption: unauthorised modification that alters system functioning (e.g., backdoor logic). Obstruction: hindering system operation (e.g., overloading, disabling communication links).
Usurpation is a threat to system integrity. Misappropriation: assuming unauthorised logical or physical control of a resource (e.g., theft of service via botnet). Misuse: causing a component to perform a function detrimental to security (e.g., disabling security functions).
The four categories are: Hardware, Software, Data, and Communication lines & networks. Each can be attacked across all three CIA dimensions: availability (e.g., theft/destruction), confidentiality (e.g., unauthorised copy/read), and integrity (e.g., modification/fabrication). See Table 1.3 in the textbook for a full breakdown.
Traffic analysis is a passive attack in which the attacker observes the pattern of traffic on a network (e.g., the amount of traffic between particular pairs of hosts, frequency and length of messages) to infer information, even when the message contents themselves are encrypted.
A replay attack involves the passive capture of a data unit and its subsequent retransmission to produce an unauthorised effect. A typical example is a Man-In-The-Middle (MITM) attack where authentication sequences are captured and replayed.
1) Economy of mechanism, 2) Fail-safe defaults, 3) Complete mediation, 4) Open design, 5) Separation of privilege, 6) Least privilege, 7) Least common mechanism, 8) Psychological acceptability, 9) Isolation, 10) Encapsulation, 11) Modularity, 12) Layering (defense in depth), 13) Least astonishment.
Security measures should be as simple and small as possible. Simple designs are easier to test and verify thoroughly, have fewer exploitable flaws, and require less maintenance. This is also known as the KISS principle.
Access decisions should be based on permission rather than exclusion. The default situation is lack of access. A design mistake in a permission-based mechanism tends to fail by refusing permission (safe), while an exclusion-based mechanism tends to fail by allowing access (unsafe).
Every access must be checked against the access control mechanism. Systems should not rely on cached access decisions. In practice, this is resource-intensive and rarely fully implemented (e.g., once a file is opened, permission changes are not rechecked on each read).
The design of a security mechanism should be open rather than secret. Encryption algorithms should be public and subject to expert review, even if keys must remain secret. This is the philosophy behind NIST’s standardisation of encryption algorithms.
Multiple privilege attributes should be required to achieve access to a restricted resource. Example: multifactor authentication requires both a password and a smart card. It can also refer to dividing a program into parts with limited privileges.
Every user or process should operate using the least set of privileges necessary to perform the task. Example: role-based access control. System administrators should use ordinary accounts for daily activities and only use privileged accounts when necessary.
The design should minimise the functions shared by different users, providing mutual security. This reduces unintended communication paths and the amount of shared hardware/software, making it easier to verify security implications.
Security mechanisms should not interfere unduly with users’ work. If mechanisms are too burdensome, users may disable them. Security must reflect the user’s mental model of protection to avoid errors.
Isolation applies in three contexts: (1) public access systems isolated from critical resources, (2) individual user processes/files isolated from each other, (3) security mechanisms isolated from tampering. Physical or logical isolation may be used.
Encapsulation is a specific form of isolation based on object-oriented functionality: data objects are accessible only through the procedures of the protected subsystem, and procedures may be called only at designated entry points.
Security functions should be developed as separate, protected modules (e.g., a common cryptographic module used by many protocols). A modular architecture allows individual parts to be upgraded without redesigning the entire system.
Layering (also called defense in depth) uses multiple, overlapping protection approaches addressing people, technology, and operations. If one layer fails, others still provide protection. Example: multiple firewalls based on different technologies.
A program or user interface should always respond in the way least likely to astonish the user. The authorisation mechanism should be transparent enough for the user to intuitively understand how their security goals map to the provided protections.
An attack surface consists of the reachable and exploitable vulnerabilities in a system. Examples: open ports, services inside a firewall, code processing incoming data (e-mail, PDF, etc.), APIs, employees with access to sensitive data. Three categories: Network attack surface (network vulnerabilities), Software attack surface (application/OS code vulnerabilities), Human attack surface (social engineering, human error).
Attack surface analysis is a systematic assessment of the scale and severity of threats to a system. It makes developers and security analysts aware of where security mechanisms are required and guides priorities for testing, strengthening security, or modifying the service.
An attack tree is a branching, hierarchical data structure representing a set of potential techniques for exploiting vulnerabilities. The root is the attacker’s goal. Leaf nodes represent ways to initiate an attack. Nodes are either AND-nodes (all subgoals must be achieved) or OR-nodes (at least one subgoal must be achieved).
A security policy is a set of rules specifying how a system provides security services. Factors: value of assets, system vulnerabilities, potential threats and likelihood. Trade-offs: ease of use vs security; cost of security vs cost of failure and recovery. Security policy is ultimately a business decision.
Prevention: stopping attacks from succeeding (ideal but not always possible). Detection: identifying attacks when prevention fails (e.g., intrusion detection). Response: halting an ongoing attack. Recovery: restoring correct operation after an attack succeeds (e.g., backup restoration).
Assurance is the degree of confidence that the security system design meets its requirements and that the implementation meets its specifications. It is expressed as a degree of confidence, not an absolute proof.
Evaluation is the process of examining a computer product or system against certain criteria. It involves testing and may involve formal analytic or mathematical techniques.
Unauthorised disclosure is a threat consequence in which an entity gains access to data for which it is not authorised. It is a threat to confidentiality. It can result from exposure, interception, inference, or intrusion.
DoS stands for Denial of Service. It is an active attack that prevents or inhibits the normal use of communication facilities. A DDoS (Distributed Denial of Service) uses multiple compromised systems (a botnet) to launch the attack simultaneously, making it harder to block. Example: the Mirai botnet.
An online attack interacts directly with the target system in real time (e.g., attempting passwords on a login page) — countermeasures include rate limiting and account lockout. An offline attack works on captured data without interacting with the system (e.g., cracking a stolen password hash) — countermeasures include strong encryption and salting. In the context of the textbook, this distinction applies to brute force and password guessing attacks.
Test your knowledge with these quick self-assessment questions:
Confidentiality, Integrity, and Availability.
Passive attacks are difficult to detect because they do not alter data. The emphasis is on prevention, typically through encryption.
An AND-node requires all of its subnodes’ goals to be achieved. An OR-node requires at least one.
Fail-safe default. The default situation is lack of access, so mistakes tend to fail safely.
A threat is a potential for security violation; an attack is a threat that is actually carried out (threat action).
Unauthorised disclosure (exposure, interception, inference, intrusion) is a threat to confidentiality.
Layering — using multiple, overlapping protection approaches so that the failure of any single layer does not leave the system unprotected.
Network attack surface, Software attack surface, Human attack surface.
Security requires regular and constant monitoring. It is not a one-time purchase or installation but an ongoing activity of assessment, adaptation, and improvement.
Data integrity ensures information is changed only in authorised ways. System integrity ensures the system performs its intended function in an unimpaired manner.