Monitoring & incident response

Key takeaways You can’t prevent everything, so you plan to detect + respond. That rests on logging — you can’t investigate what you never recorded — feeding centralized monitoring that alerts on trouble. When an incident is confirmed, contain first: stop the spread before you investigate. And tested backups are what let you recover from ransomware or destruction. This is the “detect and respond” half of defense in depth made concrete.

Earlier lessons stacked up controls to keep attackers out. This one accepts that some of them will fail anyway, and asks the next question: when a control fails, how do you notice, and how do you get back on your feet? That’s detection and response — the unglamorous half of security that decides whether a breach is a bad afternoon or a company-ending event.

Why detection matters

Prevention eventually fails. Not because your controls are bad, but because no set of controls is perfect and attackers only need one gap. If you’ve internalised assume breach, the logical next step is to accept that something will get through — and to make sure you find out when it does.

The reason this matters so much is the gap between breach and discovery. An attacker who gets in doesn’t do all their damage in the first minute; they explore, escalate, and spread. Every day they go unnoticed is another day to reach more systems and steal more data. Studies of real breaches routinely find intruders sitting undetected for weeks or months. That dwell time is where the damage compounds — which is exactly why detection is half the job, not an afterthought.

Logging and monitoring

Everything downstream depends on one habit: recording what happens. You cannot investigate, alert on, or even prove an incident from data you never captured. So the foundation is collecting logs from every layer:

Systems — logins, privilege changes, process starts, and errors on each host. (This is the everyday material of monitoring & logs.)
Network — connections, DNS lookups, and traffic to and from the outside world.
Applications — what your own software records about who did what, which is part of observability & monitoring.

Scattered logs are nearly useless in an incident — you can’t correlate a suspicious login on one box with an odd connection on another if they live in ten different places that each roll over and overwrite themselves. So you centralize them, classically into a SIEM (security information and event management system): one place that gathers logs, keeps them safely out of an attacker’s reach, and alerts on anomalies and known-bad signs. Good alerting is the difference between logs you read after the disaster and a system that taps you on the shoulder while there’s still time to act.

Detection

Centralized logs are the raw material; detection is turning them into a signal that something is wrong. A few of the workhorses:

Intrusion detection — systems that watch network or host activity for patterns that match known attacks or that simply look wrong for your environment.
Unusual logins or traffic — a login from a new country at 3 a.m., an account suddenly touching servers it never uses, a machine quietly uploading gigabytes at night. None of these prove an attack, but each is worth a look.
Integrity checks — comparing files against known-good hashes so that tampering with a system binary or a config file gets flagged, even when the change itself looks routine.

The aim isn’t to catch everything — nothing does. It’s to raise a flag early enough that response has time to work.

The incident response cycle

When an alert turns out to be real, you don’t want to be inventing a process on the spot. Teams work a repeatable cycle, usually drawn as six stages:

Prepare — before anything happens: have a plan, know who to call, and make sure your logging and backups actually exist.
Identify — confirm it’s a real incident and understand its scope: what’s affected, and how badly.
Contain — limit the spread and damage. Isolate affected machines, cut attacker access, and stop it from getting worse.
Eradicate — remove the cause: kick the attacker out, remove malware, close the hole they came through.
Recover — restore clean systems and data, verify they’re healthy, and return to normal operations.
Learn — review what happened and fix the gaps so the next one is caught sooner.

One point is worth stating loudly because people get it wrong under pressure: the first move on a live incident is containment, not investigation. It is tempting to dig into exactly how the attacker got in while they are still inside — but every minute you spend investigating is a minute they spend spreading. Stop the bleeding first; understand it fully afterward.

Backups and recovery

Recovery is only as good as your backups, and backups are where a lot of otherwise-solid plans quietly fail. Two properties matter most:

Tested — a backup you have never restored from is a hope, not a plan. Rehearse the restore, so you learn it’s broken on a calm Tuesday and not during a crisis.
Offline or immutable — ransomware specifically seeks out and encrypts every backup it can reach, and an attacker with the run of your network will delete the ones they can. A copy that’s offline, or that cannot be altered once written, survives them.

This is what makes recovery from ransomware or outright destruction possible: not paying a ransom, but restoring from copies the attacker never touched. A recovery plan you’ve never rehearsed will fail at the exact moment you’re relying on it — so rehearse it.

Learn from it

The cycle ends where it began, on purpose. Every incident is expensive; the least you can do is get a lesson out of it. After the dust settles, run an honest review: how did they get in, why didn’t detection fire sooner, and what would have contained it faster?

Then close the gap, add detection for the thing you missed, and update the plan so the next response is smoother. A team that does this turns each incident into a permanent improvement — which is the whole point of the “learn” stage, and the reason mature security programs get harder to breach over time rather than repeating the same mistakes.

Quick check: you've confirmed an active intrusion. What's the FIRST priority?

Recap

Prevention eventually fails, so detection and response are half of security — the gap between breach and discovery is where damage compounds.
Logging from systems, network, and applications is the foundation: you can’t investigate what you never recorded.
Centralize logs (a SIEM) and alert on anomalies and known-bad signs; add intrusion detection and integrity checks that flag tampering.
The incident response cycle runs prepare → identify → contain → eradicate → recover → learn — and on a live incident, contain first.
Tested, offline or immutable backups are what let you recover from ransomware or destruction; an unrehearsed plan fails when you need it.
Every incident becomes a lesson: close the gap, add detection, and update the plan.

Next up: privacy & data protection