// Monitoring and incident response · Düsseldorf & the Rhine-Ruhr region
Security monitoring and incident response
Attacks announce themselves, usually in logs nobody reads. We read them, raise what does not fit the picture, and hold a procedure for the worst case that does not have to be invented on the spot.
// Sources
What the picture is built from
-
Sign-ins
Who signs in from where, how often it fails, and whether the same account appears in two places far apart at once.
-
End devices
Reports from managed machines: processes started, protective functions switched off, a device that has said nothing for days.
-
The network edge
Connections outwards, unusual destinations, and volumes of data moving at hours when nobody in the building is working.
-
Backup jobs
Whether the backup ran and whether anybody tried to alter it. Attacks look for the way back first.
-
The baseline
Without a known ordinary picture every alert is just noise. That is why the first phase is mostly spent listening.
// On the day
Four steps, in this order
Improvisation under pressure rarely goes well. So the procedure is fixed beforehand — including who is allowed to make which call.
An oddity becomes an alert
Something drops out of the running picture. The alert does not join a queue; it goes to a person who looks at it, at night as well.
False alarm or incident?
First the comparison against the known: planned maintenance, a business trip, a new contractor. If it stays unexplained it escalates, along a path agreed in advance.
Stop it spreading
Affected devices and accounts are separated and logs secured before they roll over. Cleaning up comes later — first you stop the bleeding.
Back up in order
Systems come back in a set sequence, from verified states, and only once the way in has been closed. Otherwise it starts over.
// Afterwards
An incident is over once you know how it began.
An incident is only over once you can say how somebody got in. While that stays open, the restart was a pause and nothing more — and the same door is still standing there.
Backup and recoveryWithout that answer you can neither close the gap nor report defensibly what was affected.
Whatever snagged on the day — a wrong number, a missing account — is fixed straight away.
Course of events, scope and measures, written so that directors and regulators follow it too.
A tabletop run finds gaps far more cheaply than the real thing does.
// Questions about monitoring and response
What should be settled before the worst case
01 Do you offer monitoring around the clock?
Yes. Monitoring and on-call cover run continuously, at night and on public holidays too. Which alert reaches you immediately and which one waits until the next working day is something we agree beforehand — otherwise the phone rings at three in the morning over a full disk.
02 What response times do you commit to?
Response times are set out in the contract, graded by urgency. The grading does not follow the technology, it follows what has stopped at your end — a single workstation carries different weight from order intake.
03 How is this different from ordinary IT monitoring?
Operational monitoring asks whether something is running: disk full, service stopped, backup job failed. Security monitoring asks whether something is unusual: a sign-in from a country where you have no site, an account pulling data at night, a desktop suddenly hunting for server services.
04 What happens in the first minutes of an incident?
Containment first, tidying later. Affected devices and accounts come off the network so nothing spreads further. In parallel we secure the logs before they roll over — whoever cleans up immediately destroys the trail and afterwards cannot say what left the building.
05 Do we need our own team in-house for this?
No, but you do need named people. We handle the technical side; calls such as shutting down a production system or notifying the regulator are business decisions. Who makes them, and how that person can be reached at night, is better settled in advance.
06 Can the worst case be rehearsed?
Yes, and we recommend it. A tabletop run shows in a short time whether the contact list is right, whether somebody holds the credentials outside the affected systems, and in which order systems should come back. That is exactly what otherwise goes wrong on the day.
Related
Cybersecurity overview
Who does your team call at two in the morning?
If nobody can answer that off the cuff, what is missing is the procedure, not the technology. We work through it with you and take on the monitoring behind it.