This is the framing lesson of Chapter 1. It sets up the whole problem of computer security — what we protect, how it is threatened, and what we can do — and follows one connected chain from end to end:
asset → vulnerability → threat → attack → consequence (CIA) → countermeasure / risk / design principles
Both Cyber-01 and Cyber-02 map to textbook Chapter 1. To avoid repeating ourselves: this lesson owns the framing (the three questions, attack surfaces, attack trees, design principles, the security strategy). Cyber-02 owns the concept/terminology chain in full — the precise FIPS/RFC definitions of the CIA triad, asset, vulnerability, threat, attack, the four threat consequences, and the asset×CIA table. Where this lesson needs those terms, it states the working definition and points to Cyber-02 for the precise one.
Problem. Computers hold things worth protecting and sit in a hostile world. Before any mechanism, you need a way to frame what you are even trying to do. That frame is the whole point of this lesson.
Computer Security: measures and controls that ensure confidentiality, integrity, and availability of information system assets including hardware, software, firmware, and information being processed, stored, and communicated.
Read that definition as a set of three questions — this is the framing the professor wants you to reach for in any scenario:
So the three questions are the backbone chain, stated as a checklist. Notice what the definition implies: security is not binary. The security level of a system is measured by the amount of time, the amount of money (resources), and the probability of success needed for an attacker to break it. You are not buying “secure”; you are buying “expensive enough to break that nobody bothers.”
Security is always relative to an adversary and a budget. Every later concept in this chapter answers one of the three questions: what, from whom, or what do we do about it.
Problem. We need a shared vocabulary for how security breaks down, or every discussion drifts. The backbone chain — from asset to countermeasure — is that vocabulary. Everything in Chapter 1 hangs on one timeline. Here it is in one breath, with the working intuition and a concrete cyber example per node; Cyber-02 carries the precise FIPS/RFC definitions for each term, so this lesson does not re-derive them.
| Node | Working meaning | Door analogy | Concrete cyber example |
|---|---|---|---|
| Asset | A system resource worth protecting: hardware, software, data, communication lines. | The thing behind the door. | A customer database on a web server. |
| Vulnerability | A weakness in the asset or its controls. Inert on its own. | An unlocked door. | An unpatched SQL library (a known CVE in the DB driver). |
| Threat | The potential that the weakness is used; a circumstance with the potential for harm. | The door might get tried. | A ransomware gang scanning the Internet for that exact unpatched version. |
| Attack | The potential made real — a threat carried out (a threat action). | The handle is actually turned. | A SQL injection that extracts the customer table. |
| Consequence (CIA) | What the harm looks like: a loss of Confidentiality, Integrity, or Availability. | Something was seen, changed, or denied. | The customer records are exfiltrated (loss of Confidentiality). |
| Countermeasure / risk / principles | What we do back: prevent / detect / respond / recover, weighed by risk, guided by design principles. | Lock, alarm, guard, insurance. | Parameterized queries (prevent) + WAF alerts (detect). |
The Four Asset Categories (countable set of 4). When the question is “what do we protect?”, the answer enumerates exactly four: (1) Hardware — the computing devices and physical infrastructure; (2) Software — the programs, OS, and firmware; (3) Data — information stored, processed, or in transit; (4) Communication lines / network — the links and protocols that connect everything. (Section 6’s Software/Hardware/Humanware is a different lens — the attack-surface perspective on where you get hit, not the asset categorization.)
Behind most attacks sits an adversary (threat agent) — the actor at the chain’s middle: an individual, group, organization, or government acting with malicious intent (for example, a financially-motivated cybercriminal renting a botnet). But not every threat has an adversary: a flood threatens availability with no attacker, which is exactly why “threat” and “attack” stay separate words. Risk is the integrating node that ties the chain together as a number: risk = probability that a threat exploits a vulnerability × impact if it does (e.g. a 30% chance of a breach costing $500k). It is the number by which you weigh every control decision. At the chain’s end sit countermeasures — your response arsenal of prevention, detection, response, and recovery (e.g. parameterized queries to prevent SQL injection), detailed in Section 13.
For the exam-precise FIPS/RFC definitions of asset, vulnerability, threat vs. attack, active/passive, inside/outside, the four threat consequences (Unauthorized Disclosure, Deception, Disruption, Usurpation) and the asset×CIA table — see Cyber-02. This lesson introduces and labels those terms (see the Attack & Threat Taxonomy section and the asset×CIA matrix in Section 3) and tags CIA wherever an attack appears.
The chain’s whole job is to separate what could happen (threat — inert potential) from what does happen (attack — made real) — the distinction that shapes every defense decision.
Problem. “Harm” is vague. We need a small, fixed vocabulary for what kind of harm just happened, so that every scenario maps to the same handful of properties. That vocabulary starts with the CIA triad and grows from there.
The CIA triad is the backbone of the field and the answer to “what does harm look like?” The reflex graded on every scenario is: which of these three just broke?
Integrity splits into two testable targets. Data integrity = the information itself has not been altered (a bank balance still reads the correct number). System integrity = the system performs as designed, unimpaired (the OS kernel is not corrupted by malware). Both are attacked by unauthorized modification, but the target differs — the data vs. the behaviour. (Precise FIPS wording: Cyber-02.)
Cyber-02 holds the verbatim FIPS definitions and the impact levels. Here, use the explorer below to drill the reflex that actually scores: tie an asset to its CIA needs at a sensible severity.
Question 31 in the bank pairs the four asset categories with the three CIA properties — a countable enumeration of 12 cells. Each cell says what a loss looks like for that asset:
| Asset | Confidentiality loss | Integrity loss | Availability loss |
|---|---|---|---|
| Hardware | A stolen device exposes the data it holds. | Tampered firmware (evil-maid) on a device. | Physical damage or theft — a DoS by destruction. |
| Software | Source/IP piracy; unauthorized code access. | A trojaned or altered binary. | A crash or DoS that disables the program. |
| Data | Records intercepted or exfiltrated. | Records corrupted or falsified. | Data deleted or made unreadable (ransomware). |
| Communication lines | Eavesdropping / traffic sniffed. | Man-in-the-middle modifies messages in transit. | Links flooded or cut (DoS on the network). |
The triad is necessary but not sufficient for modern (and AI-driven) systems. Ferretti’s framing adds five properties — each testable on its own, and several deepen in Module 2 (Cyber-05):
Confidentiality is access control (who may see the data — enforced by encryption, ACLs). Privacy is inference control (what may be inferred, even by someone allowed to see it — enforced by data minimization, differential privacy). The classic cautionary tale: the “anonymized” Netflix Prize ratings (2006) were re-identified by cross-referencing public IMDb ratings — no access to names was needed; the leak was by inference.
Besides performance, analyze any system along two axes: trustworthiness (can we rely on the data, models, behavior?) and privacy (can we use data without exposing sensitive information?). These are not independent — pushing one often weakens the other. The shared problem is that every protective control has a cost paid elsewhere:
Aggregation is both power and risk: more data → more knowledge, but also more exposure. Naming the right property (and the cost of protecting it) is the connection the high grade rewards. The same duality reappears in the AI-security material in Cyber-05.
Problem. Beginners look for the “secure” product. There isn’t one. Internalizing that changes how you design.
SECURE SYSTEMS DO NOT EXIST. Software is full of implementation bugs and design errors, and so are protocols. The “unbreakable system” is a myth — like the impenetrable vault or the unsinkable boat (RMS Titanic).
Because nothing is absolutely secure, you reason about cost to break: the time, the money/resources, and the probability of success needed by an attacker (the same security-level yardstick from Section 1). To set that bar you ask the threat-model questions:
Most adversaries are rational with an economic goal ($$$) — which means raising the cost above their expected payoff is often enough. The exception is a government adversary, whose motivation may not be economic. Answering these three questions informally is threat modeling: a structured process for identifying and analyzing the threats and vulnerabilities of a system.
Concrete example. WhatsApp’s remote-code-execution flaw (CVE-2022-36934) showed that even hugely popular, heavily audited software ships exploitable bugs. Heavy review lowers the probability of a hole; it never reaches zero.
You can never make an attack impossible — only uneconomical. Design to the rational adversary’s wallet, and treat a determined government as a different (often unwinnable) game.
Problem. If bugs are inevitable, the lever you control is how many places a bug can hide.
MORE COMPLEXITY → LESS SECURITY. A linear increase in complexity causes a super-linear increase in insecurity.
The design response is the KISS rule — Keep It Simple, Stupid (also rendered “Simple and Stupid” / “Short and Stupid”). What you don’t build, you can’t break.
This does not mean the system being protected must be simple — real systems are complex. It means the protection mechanism itself must be as simple as possible. Unnecessary complexity breeds design, implementation, and usage errors — and each error is a potential vulnerability (back to the chain).
Concrete example. OpenSSL’s Heartbleed bug (CVE-2014-0160) lived in the complexity of the TLS heartbeat handling — a missing bounds check let an attacker read server memory (private keys, passwords). A simpler heartbeat path would likely never have shipped the flaw. (CIA: Confidentiality.)
KISS is the same idea that reappears formally in Section 12 as the design principle Economy of Mechanism: a small, simple mechanism is easier to test, verify, and maintain, and offers fewer places for a flaw to hide.
Problem. “What do we protect / where can we be hit?” has a structural answer: most systems are built from three kinds of entity, and each is a distinct part of the attack surface (Section 10).
The classic target: a large, exposed attack surface, often reachable remotely (Internet, wireless, a user interface). Programs run to millions of lines of source code, and each line is a potential vulnerability. Attacking software needs technical skill — which is precisely why attackers often prefer the other two entities. (CIA: any — disclosure, modification, or denial.)
All modern hardware is hardware plus embedded software (firmware), and it can be tampered with (“interfere with something to cause damage or make unauthorized alterations”). Physical security is hard to guarantee. Concrete example: the evil maid attack — an attacker with brief physical access flashes a modified firmware; the time needed is very short. (CIA: Integrity / Authenticity of the device, then Confidentiality of whatever it later handles.)
The “human in the loop” is often the weakest link. The exploit here is social engineering: the use of deception to manipulate individuals into divulging confidential or personal information for fraudulent purposes (e.g. phishing emails). Attacking the human needs skills that are not about computing. Humans fail for many reasons:
Is goodwill a problem? Yes — when abused. (CIA: typically Confidentiality, then whatever the stolen access unlocks.)
The weakest link sets the strength of the chain, and the weakest link is usually humanware. An attacker takes the cheapest path — frequently the person, not the code — which is why the human attack surface (Section 10) and user education (Section 8) matter as much as patching.
Problem. A system that is “secure” today is not secure tomorrow — new faults are discovered every single day.
So securing a system is a never-ending process, not a one-time purchase. A reasonably secure system needs endless work on the system and on education. The lack of updates leads to fragile, insecure systems — but updating is itself hard:
What you actually need is a cost/benefit evaluation — itself costly (time-consuming) and usually based on partial information (vendors rarely disclose full update contents). Framing the update decision as a risk trade-off is the examinable point, not the slogan.
“Security is a process, not a product.” You do not reach security; you maintain it — through design, development, and never-ending maintenance.
Problem. You cannot protect what you do not understand. Real security rests on deep knowledge of the system being protected — which raises the open-vs-closed debate for software.
Open specifications are preferable (e.g. for interoperability), but openness does not guarantee security — an open spec can still carry design or implementation faults.
Open source can be inspected, verified, and validated by anyone — yet this too does not guarantee security. Even if checking all the code is theoretically possible (e.g. GNU/Linux), it is not practically possible at millions of lines.
Concrete example. Microsoft shared Windows source segments with governments and large partners (the Shared Source / Government Security Program); the extra eyes found no new major class of flaw — openness did not, by itself, create vulnerability. Conversely, the Linux kernel is fully open yet still ships exploitable bugs. Openness is a trust model, not a guarantee.
In most cases the real question is a matter of trust: do you prefer to trust a community (open source) or a company (closed source)? Neither is inherently secure; they are different trust models. This is not academic — eleven countries have used legal powers to restrict high-risk telecom suppliers (e.g. Huawei, ZTE) from 5G infrastructure, precisely a decision about whom to trust.
Investing in education is good but not simple: it is costly; people under-perceive security’s importance; wrong habits persist (“we have always done it this way”); there is ideological resistance (“information anarchism”); and security procedures compete with “productive investments” for budget.
“Open > closed” is the practitioner’s version of the Open Design principle (Section 12) and of Kerckhoffs’s principle (next): security must come from knowledge and keys, never from hiding the design.
Problem. Is it safe to base security on keeping your design secret? No — and cryptography is the sharpest case.
A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Shannon’s blunter reformulation: “the enemy knows the system.”
A cryptosystem is a mechanism (hardware or software) that encrypts information to preserve confidentiality. Kerckhoffs says its security must rest entirely on the secrecy of the key, not on hiding the algorithm.
Security through obscurity means relying on the secrecy of the design or implementation as the main method of providing security. Hiding internals only buys a false sense of security: once the secret leaks, all protection is gone. Important nuance: this does not mean you should publish every internal detail — that would be strategically foolish. The point is that the system must remain secure even if the attacker knows everything except the key.
Concrete example (obscurity failing). The CSS scheme that “protected” DVDs leaned on a secret algorithm; once reverse-engineered it was broken within days (DeCSS, 1999). The secrecy bought only a false sense of security, exactly as Kerckhoffs predicts. Contrast AES/DES, whose algorithms are public and still unbroken because security lives in the key.
A secret algorithm, once broken, is total and permanent failure; a secret key, once broken, is one incident you recover from by rotating the key — so bet your security on keys, not on hiding the design.
This is the conceptual root of Open Design (Section 12) and connects forward to the symmetric/asymmetric cryptography in Cyber-03, where “security in the key, not the algorithm” becomes concrete (DES/AES are public; only the key is secret).
Problem. “How are we threatened?” needs a measurable answer. The attack surface turns the threat question into something you can map and shrink.
An attack surface consists of the reachable and exploitable vulnerabilities in a system. Examples: open ports on outward-facing servers (and the code listening on them), services inside a firewall, code that processes incoming data (e-mail, XML, documents), SQL and web forms, and an employee susceptible to social engineering. Note how this maps straight onto the three entities of Section 6.
Attack surfaces fall into three categories (countable set of 3):
| Category | What it covers | Maps to |
|---|---|---|
| Network attack surface | Vulnerabilities over an enterprise network, WAN, or the Internet: protocol flaws, denial-of-service, disruption of communication links, intruder attacks. (CIA: Availability via DoS; Confidentiality via eavesdropping; Integrity via man-in-the-middle.) | Communication lines |
| Software attack surface | Vulnerabilities in application, utility, or OS code — web-server software especially. (CIA: any — disclosure, modification, or denial.) | Software entity |
| Human attack surface | Vulnerabilities created by personnel or outsiders: social engineering, human error, trusted insiders. (CIA: typically Confidentiality first, then Integrity via the access it unlocks.) | Humanware entity |
Attack surface analysis is a technique for assessing the scale and severity of threats. A systematic survey of the points of vulnerability tells developers where security mechanisms are required and where to set testing priorities. Once the surface is mapped, designers try to make it smaller — which makes the adversary’s task harder. Layering (defense in depth) and attack-surface reduction complement each other: reduce what can be reached, and stack barriers in front of what remains.
You can’t defend what you haven’t enumerated. The cheapest security win is often subtraction: a smaller attack surface beats a cleverer defense.
Problem. Once you know where you can be hit (the surface), you need to reason about how an attacker would actually chain steps to reach a goal — and which path is cheapest. That is what an attack tree models.
An attack tree is a branching, hierarchical data structure representing potential techniques for exploiting vulnerabilities. Its parts:
Every non-leaf node is either an AND-node (the parent goal is reached only if all its subgoals are achieved) or an OR-node (the parent is reached if at least one subgoal is achieved). Branches can be labeled with difficulty, cost, or other attributes, so alternative attacks can be compared and the cheapest path found.
The root goal is “compromise a user’s bank account.” The analysis considers three components — user terminal/user (UT/U), communications channel (CC), and Internet banking server (IBS) — and in this tree every non-leaf node is an OR-node. Explore the five attack strategies:
Click an attack strategy above to explore it.
Mapping to the four threat consequences (detailed in Cyber-02). Every strategy also falls under one of four consequence categories — Unauthorized Disclosure, Deception, Disruption, Usurpation — and naming which one is testable: User Credential Compromise / Guessing = Unauthorized Disclosure (Interception/Intrusion), threatening Confidentiality; Injection of Commands and Known Authenticated Session = Deception (Masquerade/Falsification), threatening Integrity; Security Policy Violation (insider abuse) = Usurpation (Misuse), threatening System Integrity. The full taxonomy with all sub-types is in the Attack & Threat Taxonomy section below.
The attack tree turns the attack surface into ranked threats: by labeling branches with cost/difficulty you find the adversary’s cheapest path, then aim countermeasures and the design principles (next) exactly there. CERT-style advisories feed the tree with real attack patterns.
Problem. The chain (Section 2) tells you the shape of a breach; the exam also tests the standard labels for attacks. The precise FIPS/RFC definitions live in Cyber-02; here is the countable vocabulary with a CIA tag on each, so you can name any scenario under time pressure.
A passive attack tries to learn or use information without altering system resources; it is hard to detect, so the defense is prevention (encryption), not detection. Its two forms are release of message contents (reading the payload, e.g. packet sniffing) and traffic analysis (below). (CIA: Confidentiality.) An active attack deliberately alters resources or operations — e.g. brute-forcing an admin password, or a man-in-the-middle modification — and is easier to detect but harder to prevent. (CIA: Integrity and/or Availability.)
An inside attack is launched by an entity inside the security perimeter — an authorized insider using their access in an unapproved way (the trusted insider). An outside attack comes from an unauthorized, illegitimate source outside the perimeter (from pranks to organized crime). The axis is where the actor sits relative to the trust boundary; insiders are dangerous precisely because they start past the controls. (CIA: any.)
Traffic analysis is the passive activity of observing the patterns of network traffic — who talks to whom, when, how much, packet sizes — to infer useful information even when the payload is encrypted (it can hint at message structure to help break the crypto, Enigma-style). Because nothing is altered, it is a sub-type of passive attack and of Unauthorized Disclosure (Interception). (CIA: Confidentiality.)
A replay attack (record-and-playback) is an active attack: the attacker captures valid packets, optionally tweaks them, and re-sends them to provoke an unwanted effect (e.g. re-submitting a captured “transfer funds” message). (CIA: Integrity ONLY — and the “why not the others” matters: it gains no new information beyond what traffic analysis already gave, so not Confidentiality; and it does not deny service, so not Availability.) Countermeasure: session tokens or timestamps/nonces so each message is fresh and cannot be reused. (Reappears in Cyber-04 user authentication.)
An online attack goes through the live system over its communication lines — e.g. brute-forcing a login portal that has no lockout. Countermeasure: lock the account after N failed attempts (note this itself opens a denial-of-service avenue). An offline attack needs no live connection: the attacker works on stolen material (e.g. a captured password-hash database) on their own hardware, at their own pace. Countermeasure: prevent access to the material in the first place (authorization, encryption, salting). The axis is whether the target system is in the loop. (CIA: Confidentiality/Integrity depending on the goal.)
A Denial of Service (DoS) is an active attack that consumes a resource (bandwidth, connections) to make a system slow or unreachable — e.g. flooding an exposed web port with requests. A Distributed DoS (DDoS) uses many compromised hosts (a botnet) to overwhelm the per-host rate limits that would stop a plain DoS. (CIA: Availability.)
The bank tests this enumeration (Q27–30). Precise definitions: Cyber-02; here is the labeled set with CIA tags:
| Consequence | Sub-types | CIA |
|---|---|---|
| Unauthorized Disclosure | Exposure, Interception, Inference, Intrusion | Confidentiality |
| Deception | Masquerade, Falsification, Repudiation | Integrity (data & system) |
| Disruption | Incapacitation, Corruption, Obstruction | Availability & system Integrity |
| Usurpation | Misappropriation, Misuse | System Integrity |
Every attack the exam can name reduces to two reflexes: active or passive? and which CIA property broke? Get those two right and the precise label follows.
Problem. We still cannot build provably flaw-free systems. In the absence of foolproof techniques, the field relies on a set of widely agreed design principles to guide protection mechanisms — the answer to “what do we do about it?” at the design level. The set has 13 members: the first 8 are the classics (proposed 1975 and never displaced), and the textbook adds 5 more.
Drill the first eight by matching each principle to its definition:
Then click its matching definition on the right. Each correct match turns green.
Keep it small & default-deny:
Check everything, hide nothing:
Limit power:
Fit the human:
| Principle | Meaning |
|---|---|
| Isolation | Three contexts: keep public-access systems away from critical resources; isolate users’ processes/files from one another; isolate the security mechanisms themselves from tampering. |
| Encapsulation | A form of isolation from object-orientation: a subsystem’s data and procedures are reachable only through designated entry points. |
| Modularity | Build security functions as separate, protected modules (e.g. one common crypto module) and use a modular architecture so parts can be upgraded without a full redesign. |
| Layering | Multiple, overlapping protections (defense in depth) so the failure of any one layer does not leave the system unprotected. Complements attack-surface reduction (Section 10). |
| Least astonishment | A program or interface should respond in the way least likely to astonish the user, so the security model matches their intuition. |
The principles pull against each other — naming the trade-off is what scores: complete mediation vs. performance (checking every access is costly); psychological acceptability vs. strict security (too strict and users disable it); least privilege vs. usability (too locked-down and work stalls). There is no free principle.
Problem. Principles and countermeasures need to be organized into a coherent plan. A comprehensive security strategy answers three questions — the closing of the whole chain:
A security policy is a formal statement of rules and practices that specify or regulate how a system or organization provides security services to protect sensitive and critical resources. In writing one, the manager weighs three inputs (exactly the chain): the value of the assets, the vulnerabilities of the system, and the potential threats and the likelihood of attacks. And two trade-offs:
Hence: security policy is ultimately a business decision, possibly shaped by legal requirements — technology alone never settles it.
The mechanisms come in four complementary actions. Read them as a timeline relative to the attack, each with a purpose and a CIA target:
| # | Action | Purpose (when) | Example |
|---|---|---|---|
| 1 | Prevention | Before: no attack succeeds. The ideal but not always feasible. | Encryption with a secure algorithm + protected keys (preserves Confidentiality). |
| 2 | Detection | During/after: notice an attack you could not prevent. | Intrusion detection systems; spotting a DoS. |
| 3 | Response | During: halt an ongoing attack and prevent further damage. | Halting a detected DoS; automated firewall-rule updates. |
| 4 | Recovery | After: restore what was lost. | Reloading a correct copy from backup (restores Integrity/Availability). |
The four map onto the role of countermeasures in the chain: ideally prevent, otherwise detect, then respond and recover.
The strategy closes the loop: policy says what (driven by assets, vulnerabilities, threats, and risk); prevention/detection/response/recovery does it; assurance + evaluation check it — and then, because security is a process, you start over. Assurance is confidence, never proof.
Confidentiality: Preserving authorized restrictions on information access and disclosure. A loss is unauthorized disclosure. Integrity: Guarding against improper information modification or destruction. A loss is unauthorized modification or destruction. Availability: Ensuring timely and reliable access to and use of information. A loss is disruption of access. (Precise FIPS definitions and the data/system-integrity split: see Cyber-02.)
Confidentiality is about access control — who can see the data. Privacy is about inference control — what can be inferred from the data, even by authorized parties. Privacy requires confidentiality but goes further, addressing data minimization, inference protection, and individual control over personal data.
Principle 1: Secure systems do not exist. Security is measured by time, resources, and probability to break it. Principle 1 (corollary): More complexity means less security (super-linear relationship). Principle 2: Systems are composed of software, hardware, and humanware — the human is often the weakest link. Principle 3: Security = knowledge. Real security requires deep knowledge of the system, favoring open specifications and open source, but trusting a community vs. a company is a matter of judgment.
Kerckhoffs’s principle (1883) states: “A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.” Shannon reformulated it as “The enemy knows the system.” Security through obscurity (relying on secrecy of design) is wrong because it provides a false sense of security — once the secret is discovered, all security is lost. True security should rest on the key, not on hiding the mechanism.
KISS = “Keep It Simple, Stupid.” A linear increase in system complexity causes a super-linear increase in insecurity, because unnecessary complexity breeds design, implementation, and usage errors — each a potential vulnerability. The rule applies to the protection mechanism, not the protected system: the security mechanism must be as simple as possible. This is the same idea as the Economy of Mechanism design principle.
Because new vulnerabilities are discovered every day. A system that is secure today will not be tomorrow. Maintaining security requires continuous monitoring, updates, and education. The updating process itself is risky (fixes can introduce new bugs), requiring ongoing cost/benefit evaluation based on partial information. Unlike a product you buy once, security demands perpetual investment.
An attack surface consists of the reachable and exploitable vulnerabilities in a system. Network attack surface: open ports, protocol vulnerabilities, DoS. Software attack surface: application and OS code vulnerabilities, web-server flaws. Human attack surface: social engineering, human error, trusted insiders.
A systematic technique for assessing the scale and severity of threats by surveying a system’s points of vulnerability. It tells developers where security mechanisms are required and how to prioritize testing, and it guides efforts to make the attack surface smaller, making the adversary’s task harder. It complements layering (defense in depth).
An attack tree is a branching hierarchical structure where the root represents the attacker’s goal, and branches represent subgoals. AND-nodes: all subgoals must be achieved to reach the parent goal. OR-nodes: at least one subgoal must be achieved. Leaf nodes represent specific ways to initiate an attack (the concrete attack events). Branches can be labeled with difficulty, cost, or other attributes so alternative attacks can be compared.
The eight classics: (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. The five added by the textbook: (9) Isolation, (10) Encapsulation, (11) Modularity, (12) Layering, (13) Least Astonishment.
A formal statement of rules and practices that specify how a system or organization provides security services to protect critical resources. It must consider the value of the assets, the system’s vulnerabilities, and the potential threats and likelihood of attacks. Trade-offs: ease of use vs. security, and cost of security vs. cost of failure and recovery (weighted by risk = probability × impact). It is ultimately a business decision.
Prevention: no attack succeeds (e.g. encryption). Detection: identify ongoing or successful attacks (e.g. intrusion detection). Response: halt attacks to prevent further damage. Recovery: restore after a successful attack (e.g. backup restoration). Together they form a comprehensive implementation strategy.
Assurance is an attribute giving grounds for confidence that a system operates such that its security policy is enforced, covering both design and implementation — expressed as a degree of confidence, not a formal proof. Evaluation is the process of examining a product or system against defined criteria, involving testing and possibly formal/mathematical techniques.
A passive attack learns/uses information without altering resources — release of message contents (sniffing) and traffic analysis; hard to detect, so prevented (encryption). CIA: Confidentiality. An active attack alters resources or operations — brute force, man-in-the-middle, replay, DoS; easier to detect, harder to prevent. CIA: Integrity and/or Availability.
An inside attack is launched from inside the security perimeter by an authorized insider misusing access. An outside attack comes from an unauthorized, illegitimate source outside the perimeter. The axis is the actor’s position relative to the trust boundary.
A replay (record-and-playback) attack captures valid packets and re-sends them (optionally modified) to provoke an unwanted effect. It threatens Integrity only: it gains no new information beyond traffic analysis (not Confidentiality) and does not deny service (not Availability). Countermeasure: session tokens or timestamps/nonces.
A passive attack that observes traffic patterns (who, when, how much, packet sizes) to infer information even when payloads are encrypted. CIA: Confidentiality; it is a sub-type of Unauthorized Disclosure (Interception).
A Denial of Service (DoS) is an active attack that exhausts a resource (bandwidth, connections) to make a system slow or unreachable. CIA: Availability. A Distributed DoS (DDoS) uses many compromised hosts (a botnet) to overwhelm the per-host rate limits that stop a plain DoS.
An online attack runs against the live system over its communication lines (e.g. brute-forcing a portal with no lockout); countermeasure: lock after N failed attempts (which itself risks a DoS). An offline attack needs no live connection — the attacker works on stolen material (e.g. a password-hash file) on their own hardware; countermeasure: prevent access to that material (authorization, encryption, salting).
Unauthorized Disclosure (Exposure, Interception, Inference, Intrusion) — Confidentiality. Deception (Masquerade, Falsification, Repudiation) — Integrity. Disruption (Incapacitation, Corruption, Obstruction) — Availability & system Integrity. Usurpation (Misappropriation, Misuse) — system Integrity. (Precise definitions: Cyber-02.)
Four categories: Hardware (theft/firmware tampering/physical DoS), Software (piracy/trojaned binary/crash), Data (interception/corruption/deletion), Communication lines (eavesdropping/man-in-the-middle/flooding). The asset×CIA matrix (4×3 = 12 cells) is in Section 3.