The first hour: what you do, and above all what you do not

The first ten minutes: is this real

The reflex on an alert is to act. That is the wrong reflex, because the great majority of what comes in is not an incident: an expired certificate, an update that went wrong, an employee on holiday signing in from another country.

So start with three questions, and write the answers down from minute one:

• What exactly do you see, and where? Not "the server is behaving oddly" but which alert, on which system, at what time. That timestamp later becomes the first line of your timeline.
• Is it spreading? One workstation with encrypted files is a different thing from three departments at once. The difference decides whether you contain or look further first.
• Who has already done something? Usually somebody has already rebooted or deleted something before the alert reached you. You need to know that, because it explains later why a trace is missing.

Write everything down with times attached — in a shared document, or on paper if need be, but not in the system that may be compromised. Those notes are not bureaucracy: they are what your insurer, your regulator and your own people will need in three weeks' time, and nobody can reconstruct them afterwards.

At this stage also appoint one person in charge. Not the best engineer — you need them on the technology — but someone who keeps the overview, takes decisions and answers the phone. Without that role, twenty minutes in you have five people talking over each other.

What you do not do, and why

This is the most important part of this article, because the expensive mistakes in the first hour are nearly all well-intentioned.

• Do not power off. Pulling the plug feels like the safest move and it wipes the memory. That often holds the only evidence of what was running and how it got in. Take the device off the network — cable out, wifi off — and leave it on. The exception is an encryption run visibly in progress that you cannot stop any other way; then the damage outweighs the trace.
• Do not reinstall. A system you flatten and restore immediately is a system whose entry route you will never know. You then fail to close the gap, and the attacker is back in a fortnight.
• Do not go poking about on the compromised system. Signing in with an administrator account to "have a quick look" puts those credentials on a machine that is in someone else's hands. That is how an investigating administrator turns one compromised workstation into a compromised domain.
• Do not pay, and do not negotiate, in the first hour. That is a decision for the board together with your insurer. Paying is no guarantee that you get anything back, and there are legal complications around who is on the other end.
• Do not keep it from the board. The temptation to first check whether it is manageable is strong and the outcome is always the same: the board hears too late and then has to explain both the incident and the delay.

There is one thing you do straight away, and that is protecting your backups. In a targeted attack those are the first target, because encryption without a route to recovery is what makes the leverage real. Check that your immutable copy is still there and disconnect the backup environment from the network where the problem is. Why that has to be a copy nobody can erase is set out in immutable backup.

Containing without shutting everything down

Once it is established that this is real, the job is cutting things off. The aim is not clean-up — that comes later — but stopping it from spreading further.

In the order that usually works:

• Network before device. Closing off an infected segment at the switch or the firewall is quicker than walking round twenty desks, and it leaves the systems running.
• Accounts before machines. In nearly every incident an account has been taken over. Replace administrator passwords, revoke active sessions and invalidate tokens — that last one is almost always forgotten, and without it someone stays signed in after you have already changed the password.
• Close external connections. Suppliers with management access, the VPN, links into client systems. This is also the moment to consider whether you are infecting somebody else.
• Isolate backups, if that has not happened yet.

What you accept in doing this is that part of the organisation stops. That is a board decision and not a technical one, and it is precisely why that role has to be assigned in the first quarter of an hour. The question "are we allowed to take the shops off the network" should not be worked out at half past one in the morning.

Who you call, and which clock is running

Several deadlines run at once, and they start not when you understand the incident but when you know about it.

• Your board: immediately. Even when the picture is incomplete. An interim position of "this we know, this we do not" is usable; waiting for certainty is not.
• Your insurer: within a few hours. Many policies prescribe which party carries out the investigation and set requirements around notification. Hire your own investigator first and you risk those costs not being covered.
• The data protection authority: within 72 hours. If personal data is affected, you report it. The deadline runs from when you know, and a report with incomplete information is allowed — you supplement it later.
• The regulator under the NIS2 regime: first signal within 24 hours. If you fall in scope, an early warning is due faster than the report itself, followed by a fuller notification and later a final report. What that means in practice is set out in NIS2: what you must be able to show.
• Clients and suppliers: as soon as you have something to say. Better a message saying you are investigating than a client hearing it from somebody else.

The practical problem is not that people do not know these numbers. It is that they are in the system that has just gone down. A list of phone numbers therefore has to exist outside your environment — on paper in a drawer, or on a phone that is not attached to your domain.

What has to be ready before it happens

Everything above costs time you will not have on the day. What separates a chaotic first hour from a controlled one is four things, and none of them is expensive.

• One page on paper. Who leads, who calls the board, which three numbers you dial, and how you reach each other when mail is down. On paper, because the digital version is in the environment you have just cut off.
• An agreed channel outside your environment. If your mail and chat may be read along by the attacker, you need something else. You agree that beforehand; during an incident there is no time to set something up and get everyone into it.
• Knowing who may decide to take something down. By name, with a deputy behind them for when that person does not pick up.
• Walk through it once a year. Not a large exercise with an external facilitator, but an hour round a table with the question: it is Friday evening and the file server is encrypted — who calls whom. The gaps that appear are always the same: the number is out of date, the person who knew the backup has left, and nobody knows whether the insurance covers this.

That last point is why we rehearse recovery rather than only describing it. A recovery plan that is right on paper and has never been executed is an assumption. The only way to know how long you will be without your systems is to measure it once on a day when it does not matter.