Computer security deals with protecting computer-related assets against a variety of threats. The NIST definition frames it as:
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. (NISTIR 7298)
This definition introduces three fundamental questions that drive the entire field:
The security of a system is not binary. It is measured by the amount of time, money, and probability needed for an attacker to break it. The adversary is often rational with an economic goal, though government-sponsored attackers may have different motivations.
Understanding the NIST definition and the three fundamental questions is essential. The exam expects you to frame security discussions around what we protect, from whom, and why.
The CIA triad (Confidentiality, Integrity, Availability) is the backbone of computer security. These three objectives are formally defined in FIPS 199:
| Objective | Definition | Loss means |
|---|---|---|
| Confidentiality | Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. | Unauthorized disclosure of information. |
| Integrity | Guarding against improper information modification or destruction, including ensuring information nonrepudiation and authenticity. | Unauthorized modification or destruction of information. |
| Availability | Ensuring timely and reliable access to and use of information. | Disruption of access to or use of information or an information system. |
The textbook draws a finer distinction within integrity:
FIPS 199 defines three levels of impact should a breach occur:
| Level | Effect |
|---|---|
| Low | Limited adverse effect; minor damage, minor financial loss, minor harm to individuals. |
| Moderate | Serious adverse effect; significant damage, significant financial loss, significant harm not involving loss of life. |
| High | Severe or catastrophic adverse effect; severe mission degradation, major damage, major financial loss, loss of life. |
Explore different real-world scenarios to see how CIA requirements vary by asset type and context.
Be prepared not only to define the CIA triad but also to assign impact levels (Low/Moderate/High) to specific assets in a given scenario. This is a common exam question pattern.
The CIA triad is foundational, but modern security analysis requires additional concepts. Two are commonly listed as extensions to the triad, and Ferretti’s course adds several more.
The property of being genuine and verifiable. It means verifying that users are who they say they are and that each input came from a trusted source. FIPS 199 includes authenticity under integrity.
The security goal that requires actions of an entity to be traced uniquely to that entity. This supports nonrepudiation, deterrence, fault isolation, intrusion detection, and after-action recovery. Systems must keep records for forensic analysis.
Privacy is the right of individuals to exercise control over how their personal data is collected, processed, and shared. It differs from confidentiality:
| Concept | Focus | Mechanism |
|---|---|---|
| Confidentiality | Access control: who can see the data? | Encryption, access control lists |
| Privacy | Inference control: what can be inferred? | Differential privacy, data minimization |
Confidentiality prevents unauthorized access to data. Privacy prevents unauthorized inference from data — even if you are allowed to see certain information, you should not be able to derive sensitive facts about individuals.
Privacy applies across the data lifecycle:
Fairness ensures that information systems and algorithms operate without creating or reinforcing bias. It implies equitable treatment of all users and data subjects, preventing discriminatory outcomes. Two contexts:
The ability to verify system behavior through logs and records. Logging improves auditability but may reduce privacy, illustrating the inherent tension between these objectives.
Systems should be analyzed along two fundamental axes besides performance:
| Dimension | Question |
|---|---|
| Trustworthiness | Can we rely on data, models, and system behavior? |
| Privacy | Can we use data without exposing sensitive information? |
These dimensions are not independent and often introduce trade-offs. Improving one objective may weaken the other:
The AI revolution amplifies these tensions. More data means more knowledge (correlation, patterns, insights) but also more exposure (inference, re-identification, hidden sensitivity). The Netflix Prize dataset (2006) is a classic example: “anonymized” movie ratings were cross-referenced with IMDb ratings, leading to user re-identification.
Aggregation is both power and risk. The same data that enables powerful analytics also creates new privacy vulnerabilities. This duality is a recurring theme throughout the course.
One of the most important lessons in computer security is this: secure systems do not exist.
This is a fundamental principle that the professor emphasizes repeatedly. The “unbreakable system” is a myth, just like the impenetrable bank vault or the unsinkable boat (RMS Titanic).
The security level of a system is determined by three factors:
Most attackers are rational with an economic goal. The key questions when designing security are:
This informal process is the basis of threat modeling, a structured process for identifying and analyzing potential threats and vulnerabilities.
A concrete example: WhatsApp RCE vulnerability CVE-2022-36934 demonstrated that even widely-used, heavily-audited software has exploitable flaws.
More complexity → Less security. A linear increase in complexity means a super-linear increase in insecurity.
The corollary of “no secure systems” is that system complexity directly undermines security. This leads to the KISS rule:
This does NOT mean the systems being secured cannot be complex. It means the protection system itself must be as simple as possible. Unnecessary complexity in security mechanisms leads to design, implementation, and usage errors — and each error is a potential vulnerability.
Most systems are composed of three types of entities, each with distinct security considerations.
Software has a large exposed attack surface that can often be accessed remotely (from the Internet, wireless networks, or user interfaces). Modern programs are made of thousands or millions of lines of code — each line is a potential vulnerability. Interestingly, attacking software requires technical skills, but the other entity types may be easier targets.
All modern hardware includes firmware (software embedded in hardware). The hardware can be tampered with by an attacker. The evil maid attack is a classic example: an attacker with brief physical access can flash modified firmware on a device. The time required to flash tampered firmware is very short.
The evil maid attack illustrates that physical security is as important as logical security. An attacker does not always need to exploit software bugs — sometimes the easiest path is through the hardware or the human.
The “human in the loop” is often the weakest link in the system. Social engineering attacks exploit human psychology rather than technical vulnerabilities. Reasons for human vulnerability include:
Social engineering: the use of deception to manipulate individuals into divulging confidential or personal information that may be used for fraudulent purposes (e.g., phishing emails).
Is goodwill a problem? Yes, when abused by attackers. This is why security awareness training is essential.
Securing a system is a never-ending process, not a product. A system that is “secure” today will not be tomorrow — new faults are discovered every day. The lack of updates leads to fragile and insecure systems.
Even updating is not easy:
What we need is a cost/benefit evaluation that is costly (time-consuming) and often based on partial information (lack of detailed update content descriptions). This trade-off is examinable.
Real security is based on deep knowledge of the system being protected. This principle has major implications for software:
Open specifications (e.g., for interoperability) are generally preferable, but openness does not guarantee security. Open specifications can still have design or implementation faults.
Open Source allows code to be inspected, verified, and validated by the global community. However, it does not guarantee security: even if it is theoretically possible to check all the code (e.g., GNU/Linux with millions of lines), this is not practically possible.
In most cases it is a matter of trust: do you prefer to trust a community (Open Source) or a company (Closed Source)? Neither is inherently secure, but both offer different trust models.
The practical importance of this is underscored by real-world policy decisions. For example, eleven countries have used legal powers to restrict high-risk telecom suppliers such as Huawei and ZTE for 5G network infrastructure.
Knowledge also means user education. Investing in education is good but faces challenges:
A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
Shannon reformulated this more bluntly: “The enemy knows the system.”
A cryptosystem is a mechanism (hardware or software) used for encrypting information to preserve confidentiality. The principle states that the security of the system should 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 the details of a system does not make it secure. It only gives a false sense of security. However, this does not mean you should publish all internal details — that would be strategically unwise. The point is that security mechanisms should be designed so that even if an attacker knows everything about them except the key, the system remains secure.
Having established the foundational principles, we turn to the textbook’s systematic analysis of threats and attacks.
| Term | Definition |
|---|---|
| Asset | A system resource (hardware, software, data, communication lines) that users and owners wish to protect. |
| Vulnerability | A weakness that could be exploited by a threat source. |
| Threat | A potential security harm to an asset. |
| Attack | A threat that is carried out (threat action). |
| Countermeasure | A means to deal with a security attack (prevent, detect, recover). |
| Risk | A function of the adverse impact and the likelihood of occurrence. |
| Classification | Description |
|---|---|
| Active attack | Attempts to alter system resources or affect their operation. |
| Passive attack | Attempts to learn or make use of information without affecting system resources. |
| Inside attack | Initiated by an entity inside the security perimeter (an “insider”). |
| Outside attack | Initiated from outside the perimeter by an unauthorized user. |
Table 1.2 from the textbook (based on RFC 4949) organizes threats by consequence:
| Consequence | Threat to | Attack Types |
|---|---|---|
| Unauthorized Disclosure | Confidentiality | Exposure, Interception, Inference, Intrusion |
| Deception | Integrity | Masquerade, Falsification, Repudiation |
| Disruption | Availability or Integrity | Incapacitation, Corruption, Obstruction |
| Usurpation | Integrity | Misappropriation, Misuse |
Different asset categories face different threat patterns (from Table 1.3):
| Asset | Availability Threat | Confidentiality Threat | Integrity Threat |
|---|---|---|---|
| Hardware | Equipment stolen or disabled | Unencrypted drive stolen | — |
| Software | Programs deleted | Unauthorized copy made | Program modified to cause failure or unintended behavior |
| Data | Files deleted | Unauthorized read; statistical analysis reveals underlying data | Files modified or fabricated |
| Communication Lines | Messages destroyed or lines disabled | Messages read; traffic pattern observed | Messages modified, reordered, or fabricated |
In network contexts, passive attacks (eavesdropping, traffic analysis) are difficult to detect but can be prevented by encryption. Active attacks (replay, masquerade, modification, denial of service) are difficult to prevent but can be detected and mitigated.
Despite decades of research, we still cannot build systems that are provably free of security flaws. Instead, we rely on a set of widely-agreed design principles that guide the development of protection mechanisms. These principles are jointly sponsored by the NSA and the U.S. Department of Homeland Security through the National Centers of Academic Excellence.
Test your knowledge by matching each principle to its definition below.
Then click its matching definition on the right. Each correct match turns green.
The textbook extends the original eight with five more:
| Principle | Description |
|---|---|
| Isolation | Public access systems isolated from critical resources; user processes/files isolated; security mechanisms isolated. |
| Encapsulation | Protecting data by encapsulating procedures and data in a domain; internal structure accessible only to the protected subsystem. |
| Modularity | Security functions as separate, protected modules; modular architecture allows upgrades without redesign. |
| Layering | Multiple overlapping protection approaches (defense in depth). Failure of one layer does not leave the system unprotected. |
| Least Astonishment | A program or user interface should respond in the way least likely to astonish the user. |
You must be able to list and explain the fundamental security design principles (Review Question 1.4 from the textbook). Be especially prepared for the first eight (Saltzer & Schroeder, 1975) as they are classic. The textbook adds Isolation, Encapsulation, Modularity, Layering, and Least Astonishment.
An attack surface consists of the reachable and exploitable vulnerabilities in a system. Examples include open ports on servers, services inside a firewall, code processing incoming data, web forms, and employees vulnerable to social engineering.
Three categories of attack surfaces:
| Category | Examples |
|---|---|
| Network attack surface | Network protocol vulnerabilities, denial-of-service, communication link disruption. |
| Software attack surface | Vulnerabilities in application, utility, or OS code (especially web servers). |
| Human attack surface | Social engineering, human error, trusted insiders. |
Attack surface analysis is a technique for assessing the scale and severity of threats. Making the attack surface smaller makes the adversary’s task more difficult. Layering (defense in depth) and attack surface reduction complement each other.
An attack tree is a branching, hierarchical data structure representing potential techniques for exploiting vulnerabilities. The root is the attacker’s goal; branches represent subgoals. Nodes are either AND-nodes (all subgoals must be achieved) or OR-nodes (at least one subgoal must be achieved). Branches can be labeled with difficulty, cost, or other attributes.
The tree below, based on Figure 1.5 from the textbook, analyzes attacks on an Internet banking authentication application. Explore the five attack strategies by clicking the nodes.
Click an attack strategy above to explore it.
The attack tree guides security design by revealing vulnerabilities and helping prioritize countermeasures. The example considers three components: user terminal/user (UT/U), communication channel (CC), and Internet banking server (IBS).
A comprehensive security strategy involves three aspects:
What is the security scheme supposed to do? A security policy is a set of criteria for providing security services. It considers:
Key trade-offs in policy design:
Four complementary courses of action:
| Action | Description | Example |
|---|---|---|
| Prevention | No attack succeeds | Encryption with secure algorithm and key protection |
| Detection | Identify ongoing or successful attacks | Intrusion detection systems |
| Response | Halt ongoing attacks, prevent further damage | Automated firewall rule updates |
| Recovery | Restore after successful attack | Backup restoration |
Assurance provides grounds for confidence that the system enforces its security policy. It encompasses both design and implementation correctness. Evaluation is the process of examining a system against defined criteria (e.g., NIST standards).
Security policy is ultimately a business decision, influenced by legal requirements and risk tolerance. Technology alone cannot solve security problems — management and operational controls are equally important.
Professor Ferretti’s slides present four substantial use cases that demonstrate how the theoretical concepts apply to real-world systems. This section synthesizes the key lessons from each.
Smart transportation systems implement crowdsensing-as-a-Service. Data from vehicles is used for traffic analysis, route optimization, and safety alerts. The system must guarantee:
Architecture options include central entity, distributed local storage, ledger-based, and decentralized file systems (DFS). Each option makes different trust assumptions.
Key threats and mitigations:
| Threat Type | Examples | Mitigations |
|---|---|---|
| Integrity | Injection of false mobility data, hash substitution, replay attacks | Digital signatures at source, hash anchoring on DLT, verifiable timestamps |
| Confidentiality | Re-identification via mobility traces, linkability, key leakage | Strong encryption, key rotation, minimal metadata |
| Availability | DoS against DFS nodes, ledger congestion, incentive collapse | Replication policies, multi-node anchoring, layered fallback |
Key lesson: Data is distributed, but risks are centralized through aggregation. Integrity, privacy, and availability must be designed together. Architecture choices directly impact trust assumptions.
A diagnostic model predicts ICU readmission risk using federated learning across hospitals. Patient records remain local; model updates are transmitted to a central aggregator. Labels are produced by external annotation contractors.
Threat modeling framework:
| Threat | Attack Surface | Mitigation |
|---|---|---|
| Data Poisoning | Training labels from external contractors | Inter-Rater Reliability (IRR): each record labeled by 3+ annotators; discard samples below agreement threshold |
| Poisoned Federated Updates | Model updates from hospitals | Robust aggregation (Krum, coordinate-wise median, trimmed mean); bounded influence of outliers |
| Membership Inference | Public inference API | Differential privacy (DP): mathematically rigorous guarantee that output distribution does not change significantly whether any individual record is included or not |
| Adversarial DoS | Cloud inference API | Rate limiting, input validation/anomaly detection, resource caps per request |
ML systems introduce new attack surfaces (training + inference). Security is data-dependent, not only system-dependent. Privacy risks persist even without direct data access. The trade-offs (annotation cost vs. integrity, DP vs. accuracy) are examinable.
A traffic sign recognition model deployed on an embedded ECU (4GB RAM, limited compute, infrequent updates). The system must remain reliable under sensor noise, physical adversarial manipulation, and supply-chain risks.
Threat modeling:
| Threat | Description | Control / Mitigation |
|---|---|---|
| Physical Adversarial Patches | Adversarial stickers on road signs cause misclassification | Certified robustness (longer training, smoother boundaries, accuracy trade-off) |
| Annotation Supply-Chain Poisoning | Systematic label corruption or backdoor triggers from 3 external vendors | Redundant annotation (3+ per sample), agreement scoring, vendor drift monitoring |
| Adversarial Sensor Inputs | Inputs crafted to trigger worst-case compute paths, latency spikes, frame drops | Input validation, worst-case latency profiling, resource isolation |
| Model Tampering on ECU | Unauthorized firmware modification, parameter replacement, backdoor injection | Secure boot (SHA-256 integrity check), TEE, remote attestation |
The physical world becomes an attack surface. Constraints (latency, memory) limit defenses. The supply chain is part of the threat model. The robustness-capacity trade-off is a key concept.
Future AI infrastructures will be distributed, autonomous, cooperative, and heterogeneous. Each agent runs a Small Language Model (SLM) and interacts over an overlay graph. System behavior is emergent and topology-dependent.
Agent interaction model: Each agent maintains a state updated using neighbor information, implemented via SLM reasoning. Security implication: local compromise can cause global instability.
| Threat | Description |
|---|---|
| Compromised High-Centrality Agent | If a node with high degree/betweenness/eigenvector centrality is compromised: rapid misinformation propagation, cascading behavioral drift, system-wide instability. |
| Coordinated Minority Attack | A subset behaves adversarially, causing biased consensus, polarization, or decision boundary shift. Is there a phase transition threshold for success? |
| Topology-Driven Amplification | Scale-free networks and highly clustered communities amplify perturbations. Small perturbations may propagate exponentially. |
Mitigations:
Security is emergent and topology-dependent. Local compromises can cause global failures. Trust must be distributed and dynamic. This requires understanding network theory, distributed consensus under adversaries, and dynamical systems analysis.
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.
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.
Unauthorized disclosure (threat to confidentiality): exposure, interception, inference, intrusion. Deception (threat to integrity): masquerade, falsification, repudiation. Disruption (threat to availability/integrity): incapacitation, corruption, obstruction. Usurpation (threat to integrity): misappropriation, misuse.
The eight original principles are: (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 textbook adds: Isolation, Encapsulation, Modularity, Layering, and Least Astonishment.
An attack surface consists of the reachable and exploitable vulnerabilities in a system. Network attack surface: open ports, protocol vulnerabilities. Software attack surface: application and OS code vulnerabilities, web server flaws. Human attack surface: social engineering, human error, trusted insiders.
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 attack initiation events. Branches can be labeled with difficulty, cost, or other attributes.
Prevention: no attack succeeds (e.g., encryption). Detection: identify ongoing attacks (e.g., intrusion detection). Response: halt attacks to prevent further damage. Recovery: restore after a successful attack (e.g., backup restoration). These form a comprehensive security strategy.
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. Unlike a product you buy once, security demands perpetual investment.