Intro to Cybersecurity, defenders, attackers, and what they're fighting over.

Most ML domains involve data drawn from nature — images of cats, sentences from books, sensor readings from machines. Cybersecurity data comes from people who are actively trying to defeat your defences, who change their behaviour as soon as they notice you're watching, and who succeed at scale when they get it right and disappear without consequence when they don't. The adversarial framing is what makes security its own discipline rather than a special case of fault detection, and once you internalise it, the methodology of the next chapter — and most of what security organisations actually do — makes much more sense.

The adversarial mindset

Defenders think about systems in terms of failure modes. Attackers think about systems in terms of failure modes too — but as opportunities. The same buffer-overflow bug that a defender wants to patch is what the attacker wants to weaponise. The asymmetry is severe: a defender must protect every door, an attacker only needs one. The discipline of security is the discipline of imagining how systems can be broken, before someone else does.

This shapes everything from how systems are designed (assume hostile inputs, default-deny over default-allow) to how they're tested (penetration testing, red teaming, fuzzing) to how they're operated (continuous monitoring, incident response). It is also why security professionals tend to write differently than other engineers — they spend their days thinking about adversaries, and the framing colours their language.

The asymmetry problem

The defender's problem is fundamentally harder than the attacker's. A defender must close every vulnerability across thousands of machines, hundreds of applications, and dozens of network paths, all while keeping the systems usable. An attacker needs to find one weakness, one moment of inattention, one user who clicks the link. This is the defender's dilemma, and it has substantial methodological consequences: defence is necessarily probabilistic, never absolute; security is a continuous process rather than a one-time configuration; and the right metric is "raise the cost to the attacker" rather than "be uncrackable."

Defence in depth

The dominant design principle for serious security architecture is defence in depth: layer many imperfect controls so that an attacker who defeats one still has to defeat the next. A network firewall is not enough; an endpoint detection system is not enough; multi-factor authentication is not enough. Combine all of them, plus monitoring and response, and an attacker who gets through the firewall still has to evade the endpoint detector, who gets past the endpoint still has to defeat MFA, who defeats MFA still has to evade the SOC's monitoring. Each layer is fallible; the combination is much harder to defeat than any one layer alone.

The principle has a corollary that ML practitioners new to security sometimes miss: there is no such thing as a "secure" system in absolute terms, only systems that are more or less expensive to compromise. The cost of an attack — in terms of the attacker's time, money, technical skill, and risk of getting caught — is the right metric. Security work raises this cost; it does not eliminate it.

Risk versus threat

Two terms that ML practitioners often conflate but that mean different things in security. Risk is the expected loss from an event — probability times impact, in classical terms. Threat is the source of potential harm — a person, group, or capability that could attack you. Threat-based reasoning ("what would a nation-state attacker do? what would a financially-motivated criminal do?") is the dominant frame in operational security, while risk-based reasoning is more common in compliance and insurance contexts. The next sections develop both views.

Why this matters for ML

ML for cybersecurity inherits all of these constraints. A malware classifier that achieves 99% accuracy on a benchmark may collapse when malware authors notice it and start evading. An anomaly detector that flags 1% of events as suspicious may produce so many alerts that defenders ignore them. A phishing detector that can be defeated by a small change to the email's wording is not actually a defence. The methodology of the next chapter is shaped throughout by these constraints — and it is shaped by the conceptual machinery of this chapter, which the rest of the sections develop.

If you ask a security professional what they're trying to protect, the answer is almost always some combination of three things: confidentiality (only authorised parties can read the data), integrity (only authorised parties can modify the data), and availability (the system is usable when needed). These three goals — the CIA triad — are the standard framework for stating security objectives, and almost every security control can be classified by which combination of CIA properties it protects.

Confidentiality

Confidentiality is about keeping data secret from those who shouldn't see it. The classical examples are personal information (medical records, financial accounts, communications) and proprietary information (trade secrets, business strategy, source code). Encryption is the most direct confidentiality control — TLS for data in transit, disk encryption for data at rest — but access control, network segmentation, and physical security are also confidentiality measures. Failures of confidentiality are the typical headlines: "breach exposes 100M records."

Integrity

Integrity is about ensuring data has not been tampered with. The classical example is financial transactions — a payment of $1,000 must not be modified to $1,000,000 in transit. Cryptographic hashes (Section 4) are the technical foundation of integrity protection, with digital signatures and message-authentication codes building on top. Beyond data, integrity also covers system integrity (the operating system has not been compromised) and code integrity (binaries have not been replaced with malware). Failures of integrity are often more dangerous than failures of confidentiality because they can persist undetected.

Availability

Availability is about keeping systems usable when needed. The most-reported availability failure is the denial-of-service (DoS) attack, where attackers overwhelm a service with traffic to make it unusable for legitimate users. Distributed denial-of-service (DDoS) attacks coordinate many sources for amplified effect. Beyond DoS, availability is threatened by ransomware (locks data until paid), infrastructure failure (which security frameworks treat alongside attacks), and supply-chain disruptions. Availability is typically the most "operational" of the three goals — it overlaps substantially with site-reliability engineering.

AAA: authentication, authorisation, accounting

Beyond CIA, a second framework — AAA — describes the operational machinery of access control. Authentication answers "who are you?" (verifying identity via password, key, biometric). Authorisation answers "what are you allowed to do?" (granting permissions to authenticated users). Accounting answers "what did you do?" (logging actions for later audit). Section 7 develops AAA in detail; the framework is universal in modern security architecture and shows up everywhere from operating-system permissions to cloud-IAM policies.

Beyond CIA: non-repudiation and privacy

The basic CIA triad is sometimes extended with two more properties. Non-repudiation means a party cannot later deny having performed an action — supported cryptographically through digital signatures. Privacy is conceptually distinct from confidentiality: confidentiality means the data is hidden from unauthorised parties; privacy means individuals retain control over their own data even when sharing it with authorised parties. The 2018 GDPR and parallel regulations made privacy a first-class concern alongside CIA in most modern security programs.

Trade-offs between goals

The three CIA goals trade off against each other. Strong confidentiality (encryption, access restrictions) reduces availability when the encryption key is lost or the access system fails. Strong integrity (signatures on every operation) reduces availability through latency. Strong availability (replication, backups) creates more copies that need to be protected for confidentiality. Mature security architects don't pursue all three to the maximum — they understand which matters most for which assets and weight the controls accordingly. This is the risk-based approach that Section 3 develops via threat modelling.

A security architect designing a system needs to ask: what attackers are we worried about, what assets are they after, and how might they attack us? Threat modelling is the discipline of asking these questions systematically, and it produces the design constraints that shape what controls need to be built. The methodology has several standard frameworks, all of which give different angles on the same underlying problem.

STRIDE

STRIDE (Microsoft, late 1990s) is a mnemonic that enumerates six categories of threats: Spoofing (impersonating a legitimate identity), Tampering (modifying data or code), Repudiation (denying having performed an action), Information disclosure (revealing information to unauthorised parties), Denial of service, and Elevation of privilege. Each category maps to a CIA-triad violation: spoofing and ID-theft attack authentication; tampering attacks integrity; repudiation attacks accountability; information disclosure attacks confidentiality; DoS attacks availability; elevation of privilege gives the attacker access they shouldn't have.

The STRIDE workflow: enumerate the components of the system, draw the data flows, walk each component and each flow asking "could an attacker do each of the six things here?" The exercise produces a list of potential threats that drives the choice of controls.

Attack trees

An attack tree is a structured representation of how an attacker could achieve a goal. The root is the attacker's objective ("steal customer credit cards"). The children are sub-goals required to achieve it ("get database access" OR "intercept payment forms"). Each sub-goal can be decomposed further. Branches can be AND (all required) or OR (any sufficient). The leaves are concrete attack steps that defenders can either prevent, detect, or respond to.

Attack trees were popularised by Bruce Schneier in the late 1990s and remain a standard tool in security architecture. They produce a more tactical view than STRIDE — STRIDE asks "what could go wrong?", attack trees ask "how might an adversary actually proceed?"

MITRE ATT&CK

The most-used modern threat-modelling framework is MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), maintained by the MITRE Corporation. ATT&CK catalogues real-world attacker behaviours observed in incidents, organised into tactics (the attacker's high-level goals: initial access, execution, persistence, privilege escalation, defence evasion, credential access, discovery, lateral movement, collection, command-and-control, exfiltration, impact) and techniques (specific methods within each tactic).

The framework has become the lingua franca of operational security. Threat-intelligence reports map observed attacker behaviour to ATT&CK techniques. Detection-engineering teams build detections aligned to specific techniques. Red teams emulate attacker behaviour by selecting techniques to exercise. The ATT&CK matrix — a grid of tactics across columns and techniques in rows — is the most-cited single image in 2026 security operations, and the next chapter's malware-classification and intrusion-detection sections both work within ATT&CK's vocabulary.

Kill chains

A complementary framework is the cyber kill chain (Lockheed Martin, 2011), which describes a typical intrusion as a sequence: reconnaissance → weaponisation → delivery → exploitation → installation → command-and-control → actions on objectives. The framework is more linear than ATT&CK (which is a matrix of independent techniques) but it captures the temporal flow of an attack. Modern operational practice uses both: kill chains for sequence-of-events thinking, ATT&CK for technique-level detail.

Threat actors and motivations

Threat modelling also requires thinking about who the attackers are. The standard taxonomy distinguishes nation-state attackers (well-funded, patient, sophisticated, often pursuing intelligence or sabotage objectives), organised crime (financially motivated, increasingly professional, ransomware and fraud the dominant patterns), hacktivists (ideologically motivated, often public defacement or DoS), insider threats (employees with legitimate access, hardest to detect), and script kiddies (low-skill opportunists using off-the-shelf tools). Each has different capabilities, motivations, and indicators, and a defender's controls should be tuned to the actors most likely to target them.

Cryptography is the mathematical substrate of confidentiality and integrity protection — and a subject of substantial depth that practitioners can spend careers in. This section gives the conceptual minimum: the difference between symmetric and asymmetric encryption, what hashes do, what PKI is, and how these primitives compose into the protocols (TLS, signed software updates, digital signatures) that everything else rests on.

Symmetric encryption

Symmetric encryption uses the same secret key to encrypt and decrypt. The dominant modern algorithm is AES (Advanced Encryption Standard) with 128-, 192-, or 256-bit keys; ChaCha20 is a popular alternative for software-only environments. Symmetric encryption is fast (gigabytes per second on modern CPUs with hardware acceleration) but requires both parties to share the same key, which creates a bootstrapping problem — how do you exchange the key securely in the first place?

Asymmetric encryption

Asymmetric (public-key) encryption solves the key-exchange problem. Each party has a key pair: a public key they share freely and a private key they guard. Data encrypted with the public key can be decrypted only with the private key (so anyone can send a secret to the holder of the private key). Data signed with the private key can be verified by anyone using the public key (so the holder of the private key can prove authorship). The dominant algorithms are RSA (older, larger keys, simpler math) and elliptic-curve cryptography (ECC, smaller keys, more efficient), with post-quantum schemes (lattice-based, hash-based) being standardised in 2024–2026 in anticipation of quantum-computing attacks.

Asymmetric encryption is much slower than symmetric. In practice, the standard pattern is hybrid encryption: use asymmetric to exchange a short-lived symmetric key, then use symmetric for the bulk data. TLS works exactly this way, and so does almost every secure communication protocol.

Hash functions

A cryptographic hash is a function that maps arbitrary input to a fixed-size output, with three required properties: pre-image resistance (given the output, finding an input that produces it is infeasible), second pre-image resistance (given an input, finding a different input with the same output is infeasible), and collision resistance (finding any two inputs with the same output is infeasible). The dominant hash function is SHA-256 (and its larger siblings SHA-384, SHA-512); SHA-3, Blake2, and Blake3 are alternatives. MD5 and SHA-1 are deprecated for security purposes due to discovered collision attacks.

Hashes are the substrate of integrity protection. Storing the SHA-256 of a downloaded binary lets users verify it hasn't been tampered with. Hashes also underpin password storage (with appropriate salting and key-derivation functions like Argon2 or bcrypt), Merkle trees in blockchains, and many other constructions.

Public Key Infrastructure

Asymmetric cryptography requires solving a trust problem: how do you know the public key you're using actually belongs to who you think? Public Key Infrastructure (PKI) is the answer. A trusted certificate authority (CA) signs certificates that bind public keys to identities; if you trust the CA, you trust the certificates it issues. Modern web browsers ship with a list of trusted root CAs; when you connect to https://example.com, the browser verifies that the server's certificate is signed by a trusted CA, that the certificate names example.com, that the certificate hasn't expired or been revoked, and that the server proves it has the corresponding private key.

The 2010s and 2020s have seen substantial PKI evolution: Let's Encrypt (founded 2014) made TLS certificates free and automated; Certificate Transparency logs allow anyone to audit issued certificates; the WebPKI's increasing strictness has eliminated several historical attack patterns. PKI's complications — certificate revocation, key compromise, root-CA compromise — remain operational headaches.

TLS and the secure-channel pattern

TLS (Transport Layer Security, formerly SSL) is the protocol that establishes encrypted channels for almost all internet communication. The handshake combines the primitives above: server presents a certificate (asymmetric authentication), client and server agree on a session key (asymmetric key exchange), all subsequent data is encrypted symmetrically with the session key (efficient bulk encryption). The current major version is TLS 1.3 (RFC 8446, 2018), which simplified the handshake substantially and removed several legacy weaknesses.

TLS is nearly invisible — a green padlock in a browser — but it is the substrate of essentially every web service, API call, and email exchange in 2026. Understanding what it does and what it doesn't (it protects the channel; it does not protect the endpoints, the user's credentials, or the application logic) is essential for understanding the rest of security architecture.

Most attacks travel over networks, and most defences operate at network boundaries. The classical network-security architecture — perimeter firewalls separating "inside" from "outside" — has been substantially superseded by zero-trust models, but the conceptual building blocks (firewalls, intrusion detection, segmentation) remain central. This section covers the minimum a practitioner needs to understand network-based attacks and defences.

The TCP/IP model and where security lives

Network communication is layered. The classical four-layer TCP/IP model stacks: link (Ethernet, Wi-Fi — physically connecting devices), internet (IP — routing packets between networks), transport (TCP for reliable streams, UDP for datagrams), and application (HTTP, SMTP, DNS — what users care about). Security controls operate at all layers: physical security at the link layer, IP filtering at the internet layer, port-based firewalls at transport, application-layer firewalls and content inspection at the top. Different attacks target different layers, and a defender's model of "where in the stack is this happening?" is essential for understanding both attacks and controls.

Firewalls

A firewall is a network device that filters traffic based on rules — allowing some flows, blocking others. The simplest firewalls operate at the IP/port level: "allow incoming TCP traffic to port 443, block everything else." More sophisticated stateful firewalls track connection state to distinguish initiated-by-inside from initiated-by-outside traffic. Application firewalls (also called next-generation firewalls) inspect application-layer content — looking inside HTTP requests, for instance — and can apply rules based on URLs, file types, or content patterns.

Firewalls are the iconic "perimeter" defence. Their fundamental limitation is that they can't see what's happening inside a connection they've allowed, and they assume traffic that's allowed in is benign. The 2010s and 2020s saw a substantial migration away from pure perimeter firewalls toward more granular controls.

Intrusion detection and prevention

An intrusion detection system (IDS) monitors network traffic or system events for patterns indicative of attack. An intrusion prevention system (IPS) does the same and additionally blocks the offending traffic. Detections come in two flavours: signature-based (match traffic against a database of known attack patterns — fast and precise but only catches known attacks) and anomaly-based (model "normal" behaviour and flag deviations — catches novel attacks but often produces high false-positive rates).

The next chapter's intrusion-detection material lives directly in this space: ML-based IDS approaches are the modern attempt to make anomaly-based detection actually work at scale, with most systems combining ML signals with classical signature databases.

Network segmentation

Segmentation is the practice of dividing a network into separate zones with controlled communication between them. A retail company might have separate zones for their corporate network, their point-of-sale network, their HR systems, and their public-facing web servers, with strict rules governing traffic between zones. The goal is to limit lateral movement — if an attacker compromises one zone, segmentation prevents them from reaching everything else. The 2013 Target breach famously demonstrated the cost of weak segmentation: attackers entered through an HVAC contractor's account and reached the point-of-sale system because there was no real boundary between them.

The zero-trust transition

The classical network-security architecture assumed "inside the firewall is safe, outside is dangerous." Modern security architecture is increasingly zero-trust: assume any network connection might be hostile, even from "inside," and verify each request explicitly based on identity and context rather than network location. The Google BeyondCorp paper (2014) was an influential early articulation; the 2020 NIST 800-207 publication formalised the zero-trust architecture as the recommended federal pattern.

Zero-trust has real teeth. It requires strong identity verification (MFA, device certificates), continuous authorisation evaluation, encrypted communication everywhere, and detailed logging. Production zero-trust deployments at major tech companies and increasingly across regulated industries are the dominant 2026 security architecture.

An endpoint is a device that participates in the network — a laptop, server, phone, IoT sensor, or anything else with computational and network capabilities. Even with perfect network controls, a compromised endpoint can do real damage: it has legitimate network access, legitimate user credentials, and is often in a position of trust within whatever segmentation exists. Endpoint security is the practice of protecting these devices, and modern environments treat it as one of the highest-priority controls.

Operating-system hardening

Most endpoint compromises start with attackers exploiting weaknesses in the operating system. OS hardening reduces this attack surface: disable unused services, restrict privilege levels (the principle of least privilege), configure logging, apply security baselines (CIS benchmarks, DISA STIGs). Modern operating systems ship with substantial default protections — address space layout randomisation (ASLR), data execution prevention (DEP), exploit-mitigation features in kernel and userspace — that didn't exist in earlier eras. Patching is part of this: known vulnerabilities have known fixes, and endpoints that aren't patched are exploitable in well-known ways.

Antivirus and the EDR transition

The historical endpoint protection product was antivirus — software that scanned files for known malware signatures. Antivirus's fundamental limitation: it only catches malware whose signature is already known, and modern attackers routinely produce novel variants that evade signature detection.

The 2010s replacement is Endpoint Detection and Response (EDR). EDR products run lightweight agents on endpoints that collect detailed telemetry (process executions, file modifications, network connections, registry changes, memory allocations) and ship it to a central analysis platform. Detections are based on behavioural patterns ("a Microsoft Word process spawning PowerShell, downloading a script, and connecting to a non-corporate IP") rather than file signatures. Major EDR products (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, Carbon Black) are now standard at enterprises with serious security programs, and ML is central to their detection logic.

Vulnerability management

Vulnerability management is the operational discipline of finding and fixing known weaknesses. The substrate is the CVE (Common Vulnerabilities and Exposures) database, which catalogues publicly-disclosed vulnerabilities with unique identifiers (CVE-2024-12345). Each CVE typically has a CVSS (Common Vulnerability Scoring System) score from 0–10 that summarises severity. Vulnerability scanners (Tenable Nessus, Qualys, Rapid7) probe endpoints and applications to identify which CVEs apply, producing remediation backlogs that operations teams work through.

The hard problem in vulnerability management is prioritisation. A typical enterprise has thousands of CVEs across thousands of endpoints, and the team can fix only a fraction. Modern approaches use exploit-likelihood data (which vulnerabilities are actually being attacked in the wild), business-context scoring (which systems are most critical), and increasingly ML-based prioritisation models.

Patching and supply-chain risk

Most vulnerabilities are fixed by applying vendor-supplied patches. Patching is operationally fraught: patches occasionally break things, downtime windows are limited, and large environments have thousands of patches to coordinate. The 2017 NotPetya outbreak exploited a Windows vulnerability for which a patch had been available for two months — the failure was operational, not technical.

Software supply-chain risk is the modern complication. The 2020 SolarWinds breach showed that even vendor-signed software updates can be compromised if the vendor itself is compromised. The 2021 Log4Shell vulnerability showed that a tiny dependency deep inside many applications can suddenly become a critical security issue. The 2024 XZ-utils backdoor — a deliberate, multi-year insertion of malicious code into a widely-used open-source library — demonstrated that even community-maintained software can be a supply-chain target. The methodology of supply-chain security (SBOMs, vendor risk management, build-pipeline hardening) is rapidly evolving.

Most modern attacks don't break security technology — they steal credentials and use them legitimately. The 2024 Verizon Data Breach Investigations Report found that compromised credentials were involved in roughly half of all reported breaches. Identity is the new perimeter, and understanding how it's verified, granted, and revoked is essential for understanding any modern security program.

Authentication: knowing who someone is

Authentication verifies that a user (or system) is who they claim to be. The classical taxonomy is three factors: something you know (password, PIN), something you have (phone, hardware token, smart card), and something you are (fingerprint, face, voice). Single-factor authentication relies on one of these; multi-factor authentication (MFA) requires two or more.

Passwords remain the most-common first factor and are well-known to be weak. Users reuse them across sites; databases of breached passwords circulate freely; phishing extracts them at scale. The standard mitigations are password managers (which let users have unique strong passwords without remembering them), passwordless authentication (passkeys, FIDO2 hardware tokens), and MFA layered on top. The 2024 industry trend has been a substantial push toward passkeys, with Apple, Google, and Microsoft all rolling out compatible implementations.

Multi-factor authentication

MFA dramatically reduces credential-theft attacks but isn't a complete defence. SMS-based MFA can be defeated by SIM swapping. Authenticator apps can be defeated by phishing pages that capture the second-factor code. Push-based MFA can be defeated by "MFA fatigue" attacks (repeated push notifications until the user approves to make them stop). The strongest MFA methods are phishing-resistant — hardware tokens implementing FIDO2/WebAuthn, where the cryptography binds the authentication to the specific origin so phishing pages can't proxy the response.

Authorisation: deciding what they can do

Authorisation determines what an authenticated user is allowed to do. The classical framework is role-based access control (RBAC): users have roles (admin, finance, engineer), roles have permissions (read this database, deploy to production), and access decisions look up the user's roles and check whether any role grants the requested permission. Modern variants include attribute-based access control (ABAC), which evaluates rules over arbitrary attributes (time of day, location, device security posture), and just-in-time access that grants permissions for short periods rather than persistently.

Single sign-on and federation

Enterprise users have access to dozens of applications. Re-authenticating to each is operationally painful and produces password reuse. Single sign-on (SSO) lets users authenticate once to a central identity provider, then access multiple applications without further authentication. The dominant protocols are SAML (older, widely deployed in enterprises) and OAuth 2.0 + OIDC (more modern, dominant for consumer and mobile applications). Identity providers like Okta, Microsoft Entra ID, Auth0, and Google Workspace are the substrate of modern enterprise authentication.

SSO concentrates risk: compromise the identity provider, and all the applications it federates to are accessible. The 2023 Okta breach demonstrated this — a relatively small compromise of Okta's customer-support system enabled attackers to access many downstream Okta-protected applications. Identity providers are now treated as among the highest-value targets in any environment.

Zero-trust identity

Zero-trust architecture (Section 5) requires identity to do work that the network perimeter used to do: every request must be authenticated and authorised explicitly. The implications are operational. Service-to-service communication needs identity (service accounts, workload identities, mutual TLS). Device posture needs verification (is this laptop patched, is its disk encrypted, is its EDR active). Continuous evaluation replaces session-once-and-trust models. Modern identity-and-access-management platforms (IAM in cloud parlance) handle these dimensions; configuring them well is a substantial 2026 security-engineering discipline.

Attacks come in recurring patterns. The methodology of defence is largely the methodology of recognising those patterns and addressing them systematically. This section surveys the major classes of attack — what they do, how they work, and why they keep happening despite decades of fixing them.

The OWASP Top 10

For web applications, the canonical reference is the OWASP Top 10, a list of the ten most-common web-application vulnerability classes maintained by the Open Web Application Security Project. The current (2021) list includes broken access control, cryptographic failures, injection (SQL injection, command injection), insecure design, security misconfiguration, vulnerable components, identification and authentication failures, software and data integrity failures, security logging and monitoring failures, and server-side request forgery. The list is updated every few years; the categories shift but the underlying patterns recur.

SQL injection remains a remarkable recurring offender — application code that includes user input in SQL queries without proper parameterisation. The 2024 MOVEit Transfer breach affected tens of millions of records via an SQL injection in a widely-used file-transfer product. Decades of awareness, secure-coding practice, and tooling have not eliminated SQL injection because the underlying programming pattern is too common and too easy to get wrong.

Malware families

Malware — malicious software — comes in several recurring families. Viruses attach to legitimate executables and propagate when the host is run. Worms spread autonomously across networks. Trojans appear legitimate but contain malicious functionality. Spyware exfiltrates data. Adware displays unwanted advertisements. Rootkits hide their presence by modifying the operating system. Ransomware encrypts the victim's data and demands payment for the decryption key. The 2017 WannaCry and NotPetya outbreaks were ransomware (or ransomware-styled) events that caused billions in damages globally.

Modern malware is increasingly modular — a small initial payload that downloads additional capabilities once installed, with each module specialising in persistence, lateral movement, data exfiltration, or specific attack stages. The next chapter's malware-classification methodology operates at this complexity level: signatures of individual files are insufficient; behavioural patterns across the kill chain are required.

Social engineering and phishing

Many of the most-effective attacks bypass technical controls entirely by manipulating people. Phishing — emails or messages crafted to trick users into entering credentials or running malware — is the most common initial-access technique in modern intrusions. Spear phishing targets specific individuals with personalised content. Business email compromise (BEC) impersonates executives to direct fraudulent wire transfers. Vishing (voice phishing) and smishing (SMS phishing) extend the techniques to phone calls and text messages.

The 2024 generation of attacks increasingly uses AI-generated phishing — LLM-generated messages that are personalised, grammatically perfect, and contextually appropriate. Voice cloning enables convincing CEO-impersonation calls. The defender's response combines technical controls (email authentication via DMARC, link-checking, attachment sandboxing) with user education and behavioural monitoring.

Insider threats

Not every attacker is external. Insider threats — employees, contractors, or partners with legitimate access who abuse it — are particularly difficult because their actions look superficially legitimate. The Snowden disclosures (2013) and various banking-fraud cases are well-known examples. Detection focuses on behavioural anomalies (unusual data access patterns, off-hours activity, large data transfers) rather than the access itself, since the access is by definition authorised.

Zero-days and the exploit lifecycle

A zero-day is a vulnerability not yet known to the vendor or defenders, with no patch available. Zero-days are particularly valuable to attackers and command high prices on private markets — major nation-state attackers maintain stockpiles. Once a zero-day is used in an observable attack, it eventually gets discovered, reported (or rediscovered), patched, and the patch gets deployed. The window between discovery and patch deployment is when most exploitation happens; aggressive patching is a defender's main mitigation.

The 2024 generation of vulnerability research increasingly uses ML — fuzzing guided by neural-network coverage prediction, LLM-based code review for vulnerability detection, the various automated-bug-finding pipelines from Google's Project Zero and equivalent groups. The arms race between offensive and defensive vulnerability research is one of the most active intersections of ML with security.

Building defences is half the problem. Operating them — continuously monitoring for indicators of compromise, investigating alerts, responding to confirmed incidents — is the other half. This section surveys the operational machinery: the security operations centre, the SIEM, the incident-response lifecycle, and the disciplines that make defence work in practice.

The SOC and SIEM

The Security Operations Centre (SOC) is the team and infrastructure responsible for monitoring an organisation's security posture in real time. SOCs run 24/7 (or close to it), staffed by analysts who triage alerts, escalate incidents, and coordinate response. Most SOCs are tiered: Tier 1 analysts handle alert triage, Tier 2 handles investigations, Tier 3 includes specialists for advanced threats.

The substrate of the SOC is the SIEM (Security Information and Event Management) platform — Splunk, Elastic, Microsoft Sentinel, Sumo Logic, the various open-source equivalents. SIEMs aggregate logs from across the environment (firewalls, endpoints, applications, identity providers) into a queryable index, run detection rules continuously, and produce alerts when patterns match. Modern SIEMs are increasingly augmented with XDR (Extended Detection and Response) platforms that correlate signals across multiple data sources and apply ML-based detection.

The incident-response lifecycle

The standard incident-response lifecycle (NIST SP 800-61) has six phases: preparation (have plans, tools, contact lists ready before an incident), identification (recognise that an incident is in progress), containment (limit the spread of damage), eradication (remove the threat from the environment), recovery (restore systems to normal operation), and lessons learned (post-incident review to improve future response).

Each phase is its own discipline. Identification leans on detection engineering and threat hunting (Section 9 below). Containment under time pressure is delicate — too aggressive and the business stops, too cautious and the attacker exfiltrates more data. Eradication often requires substantial forensics to ensure all attacker footholds are removed. Recovery includes both technical restoration and external communication. Lessons learned is the phase most often skipped under pressure but most valuable for organisational improvement.

Detection engineering and threat hunting

Detection engineering is the discipline of building detections — SIEM rules, EDR queries, network signatures — that identify malicious activity. The MITRE ATT&CK framework (Section 3) provides the structure: detection engineers map their organisation's coverage to the matrix and prioritise detections for techniques relevant to their threat model. The Sigma project and various detection-as-code repositories provide community-shared detections that organisations adapt to their environments.

Threat hunting is the proactive search for threats that automated detections may have missed. Hunters formulate hypotheses ("if this attack pattern is happening here, we'd see X in the logs") and search for evidence. The skill set blends technical depth, attacker-thinking, and SIEM query expertise. Hunting catches attacks that automated detection didn't, and the findings often produce new automated detections.

Forensics and digital evidence

When investigations require detailed evidence — for legal proceedings, regulatory reporting, or full-scope incident understanding — digital forensics takes over. Forensic disciplines include disk imaging (preserving evidence in a court-defensible way), memory analysis (extracting information from RAM dumps), network forensics (reconstructing what happened from packet captures), and malware reverse engineering (understanding what a malicious binary does). Tools like Volatility, Autopsy, Wireshark, and Ghidra are the standard arsenal.

Threat intelligence

Threat intelligence is information about active threats — attacker groups, their techniques, their infrastructure, indicators of compromise. Sources include commercial feeds (Mandiant, Recorded Future, CrowdStrike), open-source projects (MISP, the various ATT&CK group profiles), industry information-sharing groups (the FS-ISAC for financial services, H-ISAC for healthcare), and government feeds (CISA, the FBI's IC3). Integrating threat intelligence into detection and response is what makes security operations contextual rather than purely reactive — defenders know what attacks to expect before they arrive.

The security skills gap

Operational security requires people. The well-documented security skills gap — the shortage of qualified analysts and engineers — is one of the dominant operational constraints in 2026. Organisations cope through automation (SOAR platforms, ML-based triage), managed services (MSSPs, MDR providers), and outsourcing of specific functions. The next chapter's AI-for-cybersecurity material is significantly motivated by this constraint: the goal isn't always to be more accurate than human analysts, it's to free them up for the work where their judgement actually matters.

Security doesn't operate in a vacuum. Regulations, frameworks, contractual requirements, and industry standards shape what organisations must do, what evidence they must produce, and how breaches must be reported. This final section surveys the governance landscape and points to where ML enters the security stack — the bridge into the next chapter.

Standards and frameworks

Several frameworks structure how organisations approach security holistically. The NIST Cybersecurity Framework (CSF) organises security activities into five functions: identify, protect, detect, respond, recover. Each function decomposes into categories and subcategories, providing a checklist-style assessment of an organisation's security maturity. ISO 27001 is the international standard for information security management systems, with formal certification widely required by enterprise customers. The CIS Controls (Center for Internet Security) offer a more prescriptive list of 18 controls organised by priority. SOC 2 is the audit standard for service organisations, and SOC 2 Type II reports are increasingly a B2B sales requirement.

Regulatory landscape

Compliance obligations vary by sector and jurisdiction. GDPR (EU, 2018) imposes data-protection requirements with substantial fines (up to 4% of global revenue) and breach-notification duties (72 hours). HIPAA (US healthcare) imposes parallel requirements for protected health information. PCI DSS applies to anyone handling payment-card data. SOX (US public companies) imposes financial-reporting integrity controls including IT systems. CCPA (California) and parallel state laws extend privacy obligations. Sector-specific frameworks (NERC CIP for electric utilities, MARSEC for maritime, etc.) layer additional requirements.

The 2020s have brought a wave of new regulations specifically addressing cybersecurity: SEC cybersecurity disclosure rules (US public companies, 2023), the EU's NIS2 Directive (2022) and DORA (2022) for financial services, the UK's Online Safety Act, China's cybersecurity laws. The compliance burden continues to grow, and security teams spend substantial effort managing it.

CISA and the public-private interface

In the US, the Cybersecurity and Infrastructure Security Agency (CISA) is the federal agency leading civilian-side cybersecurity defence. CISA publishes guidance (the Known Exploited Vulnerabilities catalogue, the Secure-by-Design framework), coordinates incident response, runs information-sharing programs (the JCDC), and increasingly imposes binding obligations on federal agencies and critical-infrastructure operators. Equivalent agencies exist in other jurisdictions (NCSC in the UK, BSI in Germany, ANSSI in France).

The 2024–2026 trend has been substantially toward more public-private collaboration — CISA's JCDC working with major tech companies and CIs operators, the various sector-ISACs sharing threat intelligence, the FBI's outreach to victims of ransomware. Modern security is rarely an isolated organisational concern; it's part of an ecosystem of regulators, industry peers, and government agencies.

Where ML enters cybersecurity

Returning to the chapter's purpose: the next chapter develops AI for cybersecurity. With this conceptual foundation, the reader should now recognise the canonical applications. Intrusion detection (Section 5's IDS/IPS) increasingly uses ML to find anomalous patterns in network and endpoint telemetry. Malware classification (Section 8) uses ML to identify malicious binaries, scripts, and behaviours from features that signature-based detection misses. Phishing detection uses NLP and email-header analysis to flag suspicious messages. User behaviour analytics (UBA) detects insider threats and credential abuse by modelling normal user activity. Threat-intelligence enrichment uses ML to triage and prioritise the firehose of threat data. Vulnerability prioritisation uses ML to predict which CVEs are likely to be exploited.

The next chapter also covers the harder, more ML-distinctive topic of adversarial robustness in security contexts: how ML models themselves become attack surfaces, what evasion attacks look like in security applications, and what makes security-grade ML different from generic ML.

What this chapter doesn't cover

Several adjacent areas are out of scope. The deep mathematics of cryptography — block-cipher design, lattice-based cryptography, zero-knowledge proofs, post-quantum cryptography — is its own substantial discipline. Hardware security (Trusted Platform Modules, Secure Enclaves, side-channel attacks) intersects security but has its own engineering tradition. Physical security and operational security in the intelligence-community sense are largely outside the technical scope. Cyber warfare and the strategic policy questions around it (offensive cyber operations, attribution, deterrence) are policy questions rather than technical ones. The substantial human-factors-and-usability literature on why users do insecure things despite being told not to is essential context but its own field.

Reading order for the next chapter

For navigation: Section 5's network security is the foundation of the next chapter's intrusion-detection material; Section 6's endpoint security and Section 8's attack vectors set up malware classification; Section 7's identity and Section 8's social-engineering coverage support phishing and credential-abuse detection; Section 9's SOC and SIEM material is the operational context where most AI-for-security actually lives; this section's regulatory framework is what shapes how security ML can be deployed. The next chapter develops the methodology; this chapter is the substrate.