Foundations of Offensive and Defensive Security

Foundations of Offensive and Defensive Security

The "castle-and-moat" mental model that dominated security architecture for thirty years collapsed sometime between 2018 and 2022, and most organizations are still drawing their defensive lines on the floor plans of a fortification that no longer exists. A modern enterprise might authenticate users through Okta, host its source code on GitHub, run production workloads on AWS, process payroll on Workday, ship code through CircleCI artifacts stored in S3 buckets, and ship physical goods through a logistics provider whose warehouse management system runs on Windows XP. Every one of those trust relationships is part of the attack surface, and none of them sit inside the perimeter that your firewall protects. If you do not yet have a working definition of "attack surface" that includes identity, code, third-party services, and the supply chain that stitches them together, the rest of this book will feel abstract. If you do, you can skip the throat-clearing and dive into Chapter 2.

This chapter is the foundation under everything else. We will map the modern attack surface as it actually looks in 2024–2026, define the primitives you need to reason about it (assets, threats, vulnerabilities, impacts, likelihood), introduce the attacker and defender mindsets as two halves of the same discipline, and lay out the legal and ethical guardrails that determine whether any of this is permissible. By the end you will have built a reproducible home range on your laptop, written your own Rules of Engagement template, and understand the kill-chain spine that organizes the remaining fourteen chapters.

1.1 Mapping the Contemporary Attack Surface

The phrase "attack surface" is so overused that it has almost lost its meaning. Reclaim it. An attack surface is the set of all points where an adversary can attempt to enter or extract data from a system, and—critically—the set of trust relationships that determine what they can do once they are inside. The set is not a list of IP addresses. It is a graph.

1.1.1 Cloud Workloads as First-Class Targets

When an application moves from a datacenter to AWS, Azure, or GCP, the set of components it depends on explodes. A single EC2 instance behind an ALB might be fronted by CloudFront, authenticated through Cognito, writing logs to CloudWatch and S3, querying RDS, calling Lambda functions over private API endpoints, retrieving secrets from Secrets Manager via an instance profile, and pulling container images from ECR. Each of these is an attack surface element. The ALB's TLS configuration is one. The Cognito application's redirect URIs are another. The IAM role attached to the instance is a third, and it is the most interesting of the three, because it determines what the attacker inherits if they achieve code execution.

Public cloud also introduces control-plane attacks that have no on-premises analog. `iam:PassRole`, `sts:AssumeRole`, Lambda function URL misconfiguration, EBS snapshot exposure, S3 bucket policy errors, and IMDSv1 versus IMDSv2 are not edge cases—they are the *core* of cloud attack surface. The Capital One breach of 2019 remains the canonical example: an SSRF vulnerability in a Web Application Firewall let an attacker reach the EC2 metadata service and retrieve temporary credentials for an over-privileged role. The lesson was not "patch your WAF." The lesson was that every workload that can reach `169.254.169.254` is a credential exfiltration target by default.

For intermediate practitioners, the practical takeaway is: treat every cloud resource as if it has two identities, a workload identity and a human identity, and audit both. Tools such as `enumerate-iam`, `pacu`, `ScoutSuite`, `cloudmapper`, and `prowler` exist precisely because this surface is too large to reason about manually.

1.1.2 SaaS, Identity Providers, and the Trust Web

A typical mid-sized company runs 200–400 SaaS applications. Most employees interact with three to five of them daily and are unaware of the rest. Every one of those applications is a target because every one of them is wired into the corporate identity provider through SAML or OIDC, and the IdP is the keys to the kingdom.

The SolarWinds and Okta incidents (both 2022–2023) demonstrated that the modern kill chain runs through identity. Once an adversary compromises an IdP tenant, they can issue tokens for downstream applications without ever touching the customer's network. The target organization may have a perfect patch cadence and a zero-trust internal network; it does not matter, because authentication happens outside both.

The attack surface here is not just the IdP configuration but the *federation graph*: which IdPs trust which service providers, which service providers can act on which data, which users can consent to which scopes, which refresh tokens outlive the user account that minted them. The October 2023 Okta breach—where attackers accessed support case files containing session tokens for unnamed customers—is a perfect illustration of how support infrastructure becomes a pivot into the trust graph.

For your mental model, draw the trust graph first, before you draw the network. Every node that can issue a token, mint a cookie, or grant a capability is part of the attack surface, even if it never accepts a TCP connection.

1.1.3 The Software Supply Chain

If the IdP is the keys to the kingdom, the software supply chain is the bakery that bakes the keys into the bread. Every modern application is an assembly of components: open-source libraries, container base images, build toolchains, CI/CD pipelines, package registries, and signed artifacts. Each link in that chain is a potential injection point.

The SolarWinds SUNBURST attack (December 2020) inserted malicious code into the build process of a widely deployed network monitoring product. The Codecov bash uploader breach (April 2021) tampered with a script used in thousands of CI pipelines. The 3CXDesktopApp trojan (March 2023) was a downstream effect of the X_TRADER compromise. The `xz` backdoor (March 2024) attempted to embed a remote-execution payload inside an open-source compression library that ships in most Linux distributions. These are not isolated incidents. They are a category.

The practical implication is that defending an application now requires defending its entire build graph: who can commit to which repository, who can approve which pull request, which GitHub Actions have write permissions on which branches, which package versions are pinned, which container images are signed, and which artifacts are reproducible. SLSA (Supply chain Levels for Software Artifacts) is the emerging vocabulary for this, and we will return to it in Chapter 11. For now, internalize that "we use open source" is a deployment decision, not a security posture.

1.1.4 Mobile Endpoints, IoT, and Operational Technology

The three remaining categories are often grouped under "endpoints," but they have very different threat profiles.

Mobile endpoints are not the desktops of 2010. A modern smartphone is a hardware-rooted trust anchor containing biometric-protected keys, a baseband processor running firmware you cannot audit, a hypervisor separating corporate and personal profiles, and dozens of background services reaching out to dozens of cloud APIs. Attackers target the MDM enrollment profile, the certificate pinning implementation, the IPC between sandboxed apps, and the unmanaged apps that leak data through the clipboard or screenshots. The Pegasus family of exploits demonstrated that a sufficiently resourced adversary can compromise an iPhone with a single iMessage—no user interaction required.

IoT devices are everywhere and are almost universally under-defended. The Mirai botnet (2016) and its successors demonstrated that millions of devices with default credentials and unpatched firmware can be corralled into record-breaking DDoS attacks. The Verkada b