For the past three weeks, I've been arguing that after 22 years, it's time to retire Cybersecurity Awareness Month and replace it with Cybersecurity Readiness Month. Not because awareness is bad, but because awareness isn't enough. Knowing something terrible might happen isn't particularly useful if you haven't figured out what to do when it does.
In Part One, I explained why the name needs to change. In Part Two, we looked at personal readiness, protecting what matters and preparing for things to go wrong. In Part Three, we moved into organizations, where having security tools, policies, and incident response plans doesn't necessarily mean any of them will work.
Now we get to the uncomfortable part. What happens when an attacker actually gets in?
It's Not If. It's When.
Security people have been saying "it's not if, but when" for decades. It's practically a requirement for getting your first cybersecurity conference badge. Yet much of the industry still behaves as though preventing every compromise is an achievable goal.
It isn't.
You can have excellent security controls, well-trained employees, properly configured infrastructure, and developers who take security seriously. Somebody will eventually make a mistake, a trusted dependency will turn malicious, or an attacker will find something nobody knew was vulnerable.
Prevention still matters. A lot. But preventing the initial compromise is only one part of security. Limiting how far an attacker can spread and how much damage they can cause is just as important, and sometimes more important, than keeping them out in the first place.
A stolen credential shouldn't provide access to every system. A compromised developer workstation shouldn't expose production secrets. One infected application shouldn't take down an entire business. If a single mistake can unravel everything, your problem is bigger than the mistake.
Stop Building Security Around the Front Door
Modern environments are full of connections between systems, applications, identities, and services. An attacker who compromises one account may discover credentials for another. A malicious dependency might steal tokens from a build environment. An overly privileged service account can turn a small intrusion into a much larger problem.
The solution isn't a stronger perimeter. It's making sure that getting through one door doesn't unlock every other door in the building.
Use least-privilege access, separate development and production environments, limit service account permissions, and avoid storing powerful credentials where every process can reach them. Segment sensitive systems and monitor unusual access between them.
Most importantly, test those boundaries. If you compromise a test account, what can it reach? If a developer laptop is infected, which credentials and systems are exposed? Don't assume the separation exists because somebody drew boxes on an architecture diagram.
Detection Is Only Useful If Someone Responds
Security teams have become remarkably good at collecting alerts. We're considerably less consistent about doing something useful with them. An alert sitting in a queue for three days while an attacker explores your network isn't helpful, especially when it's buried under hundreds of false positives.
Good detection needs context. What happened? Which systems are affected? What can the attacker access? Are they still active? Those answers help determine whether you're dealing with an emergency or something that can wait until morning.
This is where automation earns its keep. Revoke compromised tokens, disable suspicious accounts, quarantine malicious packages, and isolate affected systems when there's enough confidence to act. Keep humans involved when decisions could disrupt critical operations, but don't waste their time on repetitive tasks that machines can handle faster.
Back in April, Jayson DeLancey and I wrote up a response workflow for a wave of malicious npm and PyPI packages. It holds no matter which package shows up next: determine exposure, scan, rotate every credential if you’re affected, pin your dependencies, and get back to work. The principle applies well beyond software dependencies. Finding a problem is only useful if you already know what you’ll do about it.
Containment Matters More Than Heroics
Once an attacker gets in, time matters. Every minute they retain access is another opportunity to steal data, establish persistence, or compromise additional systems.
That's why containment deserves as much attention as detection. Security teams should know how to revoke credentials, isolate machines, disable compromised integrations, and restrict access without spending hours tracking down the person who has permission to approve it.
This doesn't mean shutting down everything at the first suspicious login. Overreacting can cause more damage than the original incident. It means understanding your systems well enough to make fast, informed decisions.
When attackers started going after security vendors earlier this year, my colleague Kurt Boberg wrote up how our team checked whether we were next. The useful part is the sequence: map what an attacker could reach, test the likely entry points, patch what turned up, and then plant canary tokens so the next intruder gets caught right away.
That's the kind of readiness organizations should practice before they're under attack.
