Detecting & Responding to a Breach
What actually happens in the first hour after something looks wrong.
On this page5 sections
This lesson is the capstone for the track: every earlier lesson here - hardened defaults, managed secrets, scanning, a locked-down network - exists to prevent needing this one. When it's needed anyway, speed and discipline matter more than anything else.
Contain first, root-cause second
The same "mitigate before you fully explain" discipline from incident response in general applies here, with extra urgency: revoke or isolate first. Rotate every credential that might have been exposed, cut network access to a compromised host, disable a leaked API key - immediately, before fully understanding how the attacker got in. A breach that's still active gets worse every minute it's merely being studied instead of stopped.
Logs are the evidence trail
journalctl -u ssh -n 20
Every lesson on logging and observability earlier in this curriculum pays off directly here: logs are frequently the only record of exactly when access happened, from where, and as whom. This is also precisely why centralized logging (from the Observability track) matters so much for security specifically - an attacker with access to a single compromised host can delete its local logs; they generally can't reach a separate, centralized log store they were never given access to.
Assume compromise is broader than it looks
A good habit under pressure: assume the blast radius is larger than the first signal suggests. If one credential leaked, what else did that credential have access to? Rotate broadly, then narrow down with evidence - not the other way around.
DevSecOps, in one sentence
Every lesson in this track has been building toward the same idea: security isn't a gate at the very end of a pipeline, checked once before a release ships. It's hardened defaults, managed secrets, automated scanning, and a locked-down network, each built into its own stage of the exact same CI/CD pipeline covered earlier in this curriculum - continuous, not occasional.
Try it
journalctl -u ssh -n 20
When you're ready, hit Mark complete. You've completed the Security & DevSecOps track!
Challenge
Check the last 20 log lines for the ssh service - exactly what you would review first after a suspected unauthorized-access attempt.
Want to experiment first? Try things in the practice terminal (opens in a new tab), then enter the command that solves the task here.
Quiz
Lock in the concepts. Score at least 80% to mark the lesson complete.
Done with this one?
Skipped the challenge? You can mark the lesson complete by hand.