Computer security is the discipline of protecting computers, software, and data from unauthorized access, modification, destruction, or disruption. The term cybersecurity is broader and typically refers to the protection of networks, online services, and connected infrastructure. Security aims to ensure that systems behave as intended, information remains protected, and services are available when required.

We expect computers to produce correct results and to keep stored information safe from theft or corruption. Achieving these guarantees requires deliberate effort. Security supplies the principles, mechanisms, and policies that make these expectations possible.

The foundational model for computer security is the CIA triad: confidentiality, integrity, and availability. Despite its name, the model is unrelated to the U.S. Central Intelligence Agency. Additional important properties are authenticity, which verifies that an entity or message is genuine, and accountability, which connects actions to the responsible individuals or systems.

The CIA Triad

Confidentiality

Confidentiality restricts access to information so that only authorized people and processes can view it. For example, a password controls access to your online bank account, while network encryption prevents outsiders from reading the traffic between you and the bank.

Confidentiality, privacy, anonymity, and secrecy are related, but they are not the same thing:

• Privacy governs how personal information is collected, used, stored, and shared, as well as the rights individuals have over these practices. For example, a patient’s records may be confidential, but privacy issues arise if a hospital collects unnecessary information or uses it for purposes unrelated to care.

• Anonymity hides a person’s identity even when their actions are observable. For example, survey responses may be accessible, but the respondent’s identity remains hidden.

• Secrecy is the deliberate act of hiding information, sometimes even concealing its very existence. For example, a classified government program may be known only to a select group.

Efforts to protect confidential messages go back thousands of years. Julius Caesar used a substitution cipher for military orders. Two millennia later, Germany relied on the Enigma machine to encrypt wartime communications until the Allies broke it. Today, Transport Layer Security (TLS) encrypts most web traffic and keeps credit card numbers private as they travel over networks to merchants.

When attackers gain access to protected data, they often attempt to move it to a location under their control. This unauthorized transfer is known as exfiltration. For example, malware (malicious software) may upload sensitive company files to an external server.

Attackers can use stolen data in several ways:

Espionage

Competing companies or countries may want strategic plans, production schedules, employee records, and intellectual property.

Obtaining credentials

Attackers search for unprotected login credentials and any other data usable for authentication. A login and password on an online store may be the same pair used to access a bank.

Extortion

Companies may pay to keep stolen information from being published and damaging their reputation.

Impersonation

Attackers may use personal details such as employer, birthdate, or address history to impersonate someone and gain access to company resources or bank accounts.

Integrity

Integrity ensures that data and systems remain accurate. Only authorized people or processes should be able to make changes. For example, when money moves through a payment app, integrity protects both the recipient and the amount from being altered in transit. In a hospital, a malicious change to a patient’s blood type record could have fatal consequences.

Integrity has several facets:

• Data integrity prevents unauthorized modification or deletion of information.

• Origin integrity means that the claimed source of information has not been substituted. Digital signatures can help establish it.

• System integrity means the hardware, software, and processes work as expected. System-integrity failures can be difficult to detect because a compromised system may use its own altered code to check itself and report that nothing is wrong.

Authenticity means having evidence that a person, system, or message is what it claims to be. Integrity asks whether information has been altered, while authenticity asks whether its claimed source is genuine. A message can arrive unchanged yet still be forged. Spoofing a caller ID or email sender address is an authenticity failure.

Integrity failures are not limited to someone editing a database record. Malware may modify system files to hide its activity. A virus that overwrites executable files is an integrity failure, as is redirecting network traffic by changing routing tables or DNS records.

Corruption is often difficult to detect and often not disclosed publicly. Breach-disclosure laws and news coverage tend to focus on stolen personal information, so a harmful change to business data may receive less attention than the theft of customer records.

Availability

Availability means that systems and data are usable when needed. A system that protects its data perfectly but cannot be used is not useful.

Many attacks aim to make a service unavailable. A denial-of-service (DoS) attack prevents a service from working or makes it too slow to be useful. An attacker might exploit a bug that crashes the service or overwhelm the server with requests. In a distributed denial-of-service (DDoS) attack, traffic comes from many machines at once. A collection of compromised machines controlled by one attacker is called a botnet.

On October 21, 2016, a botnet sent three waves of traffic at Dyn, a company that operated DNS servers. Those servers translated names such as netflix.com into the numeric Internet Protocol (IP) addresses computers use. When Dyn’s servers stopped responding, Twitter (now X), Netflix, Spotify, Reddit, and GitHub all became unreachable. Their computers were still running, but users could no longer find them by name.

The botnet was Mirai, assembled from home routers and security cameras that still used factory-default passwords. A Rutgers undergraduate and two friends wrote Mirai and released its source code a few weeks before the Dyn attack. Whoever attacked Dyn used that released code.

An availability failure can cause enormous damage even when little or no data is stolen. After Jaguar Land Rover (JLR) detected an intrusion on August 31, 2025, it shut down its information technology systems. Three British plants remained idle for roughly five weeks. The UK’s Cyber Monitoring Centre estimated £1.9 billion in damage across more than 5,000 organizations, most of them suppliers that had no part in the original breach. JLR itself reported £196 million in incident-related costs.

An attacker is not required for availability to fail. In December 2021, a faulty backup software update at Kyoto University caused a cleanup script to delete 77 terabytes of research data. Fourteen research groups lost files, and four never recovered them. Recovery systems are software, too.

These goals can conflict. A computer that is powered off and locked in a safe has excellent confidentiality but no availability. Confidentiality also loses much of its value if there is no way to verify whether the protected data has been changed.

Security System Goals

Security work is often organized around three practical goals:

1. Prevention aims to stop attacks before they succeed. Examples include password authentication, access controls, and encryption.

2. Detection identifies and reports attacks. Intrusion detection systems, for example, alert administrators to unauthorized activity. Even when prevention succeeds, detection provides visibility into attempted attacks.

3. Recovery focuses on restoring systems after an attack or failure. This includes backups, incident response plans, and forensic investigation.

The 2021 ransomware attack on the Colonial Pipeline involved all three of those factors. Prevention failed because the attackers logged into a remote-access virtual private network (VPN) account using a compromised password. After detecting the intrusion, Colonial halted pipeline operations as a precaution while it determined whether the attack had reached its operational network. That action helped protect part of the system, but it also caused an immediate availability issue.

The recovery process included restoring the systems, safely restarting the pipeline, and dealing with the ransom. On May 8, Colonial paid 75 bitcoin, which was equivalent to about $4.4 million, and one month later, the Federal Bureau of Investigation (FBI) seized 63.7 bitcoin from the attackers’ wallet, worth about $2.3 million at the time. The seizure recovered some of the money, but it did not restart the pipeline.

Defense in Depth

Bruce Schneier, a well-known cryptographer, writer, and security consultant, put the systems view bluntly: “Security is a chain; the weakest link breaks it.”

Defense in depth is a technique that uses multiple layers of protection so that one weak or failed control does not compromise the entire system. For example, a web application might validate input and restrict permissions. An intrusion detection system might watch for suspicious activity. Backups can provide a recovery path if prevention fails.

The layer that saves an organization is sometimes one nobody planned.

In June 2017, a compromised update to a Ukrainian tax package brought the NotPetya wiper into Maersk, one of the world’s largest shipping companies. A wiper is malicious software designed to erase data. NotPetya destroyed 49,000 laptops, 3,500 of Maersk’s 6,200 servers, and its central employee and machine directory. Seventeen of its 76 port terminals stopped working.

One clean copy of the directory survived on a server in West Africa because a power cut had taken it offline before the malware arrived. The connection was too slow to transfer the data, so employees copied it to a disk and carried it by air to the recovery site in England. Maersk restored its core infrastructure in ten days and rebuilt the laptops over about four weeks. The incident cost the company between $250 million and $300 million. Replicated copies had not protected the directory because the same destructive event could reach all of them.

Policies, Mechanisms, and Assurance

Securing a system involves two decisions. First, someone must decide what actions are allowed. Second, the system must enforce those decisions.

A policy defines what is allowed. A mechanism enforces the policy. Mechanisms fall into two groups:

• Technical mechanisms include operating system access controls, cryptography, and intrusion detection systems.

• Procedural mechanisms include ID checks, audits, and separation of duties.

A policy can be written in ordinary language. For complex systems, using a precise specification or a formal policy language helps reduce ambiguity.

Every security mechanism depends on assumptions. We assume that authentication identifies the correct account, that the compiler produces the intended instructions, and that administrators configure the system correctly. If any of these assumptions is incorrect, the mechanism may stop enforcing its policy without any clear sign of failure.

Assurance measures our confidence that a system correctly enforces its policies. Formal proofs are rare for systems with millions of lines of code. Most assurance comes from design reviews, testing, code audits, and penetration testing, where someone is paid to attack the system and report how they succeeded.

OpenSSL, a library that implements TLS, the secure protocol used for websites, once accepted a claimed message length without checking it against the amount of data received. A request containing 1 byte could claim to contain 64 kilobytes, causing a server to return almost 64 kilobytes of nearby memory. That memory might hold passwords or TLS private keys.

The vulnerability became public on April 7, 2014, under the name Heartbleed. Netcraft, a company that surveys the software running on public web servers, found the heartbeat extension enabled on 17.5 percent of HTTPS sites. Those sites were serving roughly half a million certificates issued by trusted authorities, and every one of those private keys had to be treated as exposed and reissued. The fix added two bounds checks totaling four lines of code. The policy was reasonable, but the mechanism did not enforce it. Assurance work exists to find gaps like that one.

Security Engineering

All engineering involves tradeoffs. Buildings have a limit to the earthquakes and hurricanes they can resist, and circuits have a limit to the voltage and current they can handle.

Security engineering applies this engineering mindset to building and operating secure systems, beginning with those tradeoffs. A Medeco M4 Maxum deadbolt costs several hundred dollars, while a basic residential Kwikset deadbolt costs around $20. The expensive lock resists picking, bumping, and drilling for longer, but most homeowners still choose the cheaper option.

Moreover, the deadbolt does not have to work alone. An alarm system and a barking dog provide additional layers of protection if a burglar gets through the door. This is defense in depth.

We assume that defenses can be circumvented given enough skill, time, and effort.

Safes resistant to burglary can have a TL rating under UL 687, which covers resistance to tool attacks. A TL-15 rating indicates that two skilled technicians were unable to open the safe within fifteen minutes of net working time. Only the time a tool is in contact with the safe is counted, and the clock stops when the technicians change tools, move their equipment, or consider what to try next, so the test actually takes longer than fifteen minutes.

Software security works the same way. Attackers can study a design, and the appropriate protection depends on who they are and what a failure would cost. Sometimes restoring from a tested backup is cheaper than trying to prevent every event that might require one.

Security engineering spans three kinds of work:

• Architecture involves designing secure systems, anticipating threats, and identifying weaknesses.

• Implementation involves incorporating the mechanisms and policies into actual systems.

• Operations include deploying, monitoring, patching, responding, and recovering throughout the system’s lifetime.

Attackers are not limited by the system’s intended design and expected use. They can exploit bugs, misconfigurations, forgotten services, or human error. Thinking like a hacker means using the system in ways that the designer never intended. Security engineering must consider all of these paths, including those the original designers did not anticipate.

Risk Analysis

Three terms in this section are covered fully in Part 2, and short definitions are enough for now. A threat is any circumstance or event that could cause harm, including accidents and equipment failures. A vulnerability is a weakness that could allow a security property to fail. An attack vector is the path or method used to reach a target.

An asset is anything valuable that a system must protect. Assets include data, equipment, money, reputation, or the ability to keep a service running. A security control, or countermeasure, is a safeguard that reduces the likelihood of harm or limits the damage if something goes wrong.

Risk analysis connects these concepts. It is the process of identifying assets, determining which threats and vulnerabilities expose them, assessing the likelihood of harm and the severity of consequences, and then prioritizing which controls are worth implementing. Protecting a laptop from accidental deletion or a curious coworker is one problem. Protecting the same laptop from a well-funded intelligence agency that is determined to access its contents is a different problem with a different budget.

The environment affects the risk. A machine that never connects to a network has little exposure to remote attackers, while a public server accepts traffic from anywhere. Risk also changes over time as new vulnerabilities are discovered in deployed software.

Risk analysis must also consider usability. Requiring two people to approve every email login would make unauthorized access harder, but it would also make email nearly unusable. A security control provides little protection if people routinely bypass it to get their work done.

A threat model is a structured account of how a specific system could be harmed. Building one means breaking the system into its parts, identifying where data or control crosses between parts that are trusted differently, and asking what could go wrong within each part and at each boundary. The model records what must be protected, who or what could cause harm, how the harm could occur, which controls reduce the risk, and the assumptions behind those decisions. A control designed for an opportunistic attacker, one who takes whatever proves vulnerable, may provide little protection against an intelligence agency that can spend years pursuing the same target.

Dealing With Risk

Once a risk has been identified, an organization must decide how to address it. Most responses fall into four categories:

• Mitigate the risk by adding controls that reduce its likelihood or impact. Examples include patching a server, restricting network access, and maintaining tested backups.

• Avoid the risk by stopping the activity that creates it. For example, an organization might shut off an Internet-facing service rather than continue operating it.

• Transfer part of the risk through insurance, contracts, or outsourcing. This can shift some financial loss, but it does not transfer all operational damage, legal responsibility, or reputational harm.

• Accept the risk when it falls within the organization’s tolerance or when further reduction would cost more than the expected harm. Acceptance should be explicit and made by someone with authority to bear the consequences.

No controls will eliminate all risk. The exposure that remains after treatment is called residual risk. The organization must either accept this residual risk or add more controls.

Trusted Computing Base (TCB) and Supply Chain Security

There are components in every system that must be trusted, since they ultimately enforce the rules for all the rest. The hardware, firmware, and software components that applications rely on together make up the Trusted Computing Base (TCB). The TCB may consist of the processor’s protection facilities, the boot firmware, the operating system kernel, device drivers, system libraries, and services, depending on the system.

Once the TCB has been compromised, the safeguards that rely on it can no longer be trusted. For instance, malware that alters the software that starts the operating system can also alter the operating system as it loads. The operating system cannot depend on its own checks to detect that change because those checks may have been altered too. Compilers and build tools create a similar risk: a compromised tool could insert malicious changes before a component becomes part of the TCB.

A trust boundary is a point where data or control moves between trusted and untrusted parts of a system. A request on the Internet crosses such a boundary when it reaches a server, which is why the server has to verify the input rather than assume it is safe. Many serious vulnerabilities begin with a bad assumption at one of these boundaries.

Security software often belongs to the TCB because it needs broad access to monitor the system. On Windows, some security products have operated inside the kernel, the most privileged part of the operating system. A normal application can crash alone. A kernel fault can halt the entire machine.

At 04:09 Coordinated Universal Time (UTC) on July 19, 2024, CrowdStrike published a routine configuration update for Falcon, its Windows security agent. One input description contained an extra field. Falcon read past the end of the data, and because it ran in the kernel, Windows crashed and repeated the crash during startup.

CrowdStrike withdrew the file 78 minutes later, but roughly 8.5 million devices had already received it. Repair often required someone to start each machine in recovery mode and delete the file. Around 5,000 flights were canceled that day, and New Hampshire lost its entire 911 service for about two and a half hours. The access that enabled Falcon to monitor Windows also allowed a single malformed file to stop millions of machines.

The supply chain includes the people, tools, vendors, and components involved in building and delivering a system. Supply chain security protects that process. Modern software may incorporate code obtained from public software repositories and commercial vendors. That code may in turn rely on other packages. A compromised library, compiler, build server, or update channel can therefore infect software before it reaches the organization that will run it.

The 2020 SolarWinds compromise demonstrates this risk. Attackers entered the company’s build system and inserted malicious code into Orion, a product used to manage IT infrastructure. SolarWinds then signed and distributed the affected updates through its normal process.

About 18,000 organizations downloaded the update. That figure counts downloads rather than compromises: some customers never installed the update, and SolarWinds later estimated that fewer than 100 customers were actually hacked through it. Victims included the Treasury Department, the Department of Homeland Security, parts of the Pentagon, Fortune 500 companies, and universities.

The code signing worked correctly. The signature proved that the update was provided by SolarWinds. However, it could not show that an attacker had taken control of the SolarWinds build system.

An increasingly common supply chain attack is the contamination of software packages. In August 2026, a worm that appeared in npm, a public repository for JavaScript software, used that structure to spread. When someone installed an infected package, a script searched the developer’s machine and automated build system for stored credentials.

If the script found credentials that allowed the developer to publish software, it inserted the worm into every other package that the developer maintained. It increased each version number and published the infected releases. A developer or build system that installed one of those releases could become the next carrier if it also stored publishing credentials. After the first release, the worm spread without anyone directing it.

Singapore’s Cyber Security Agency counted more than 1,300 affected package versions with a combined total of 2 billion monthly downloads. Many reached developers indirectly because software they selected relied on the affected packages. Package managers installed the malicious versions because they had been published by authorized accounts.

Security Theater and Misaligned Incentives

Security decisions are shaped as much by cost and incentive as by what is technically possible.

Some defenses create more reassurance than protection. Bruce Schneier coined the term security theater for measures that look protective but do little to reduce risk. Password rules that demand both complexity and frequent changes are a common example because they encourage predictable variations and the writing down of passwords. Outside of computing, removing shoes at airport checkpoints and limiting the amount of liquid in carry-on bags are often criticized in the same terms.

An organization that decides how much protection to purchase may not have to pay the full amount when that protection fails and may have no legal responsibility. A retailer breach can result in costs for customers and card issuers. A software license may shift liability to users, and insurance might only cover part of a loss. These arrangements can make additional protection seem like a bad investment for one company, even when an incident would impose costs on others.

Next: Part 2: Threats, Vulnerabilities, and Attacks

Lecture 1: Part 1 | Part 2 | Part 3 | Part 4
Lecture 1 Study Guide | List of terms