Index
- An attack starts quietly
- Defence buys time, not certainty
- Where technology ends, preparedness begins
- A plan built from data, not documents
- Start small, keep improving
When people think of a cyberattack, they usually picture one dramatic moment: screens go black and a ransom demand appears. But that moment is only the end of a long story. Its beginning is quiet, often inconspicuous and that is precisely what makes it so dangerous. For companies, it always comes down to the same question: how do we remain operational when nothing works any more?
An attack almost always starts quietly
The point of entry is rarely spectacular: a well-crafted phishing email, a password from an earlier data breach or a forgotten, unpatched server. Once inside the network, the attacker settles in without haste, establishes a covert connection to the outside world and expands their privileges step by step.
What makes this so insidious is that, from the outside, much of it looks like perfectly normal operations. The attacker logs in with genuine credentials and uses the same tools as the company’s own IT department, as unremarkable as a colleague going about their work.
Moving from system to system, they work their way deeper into the network – in search of administrator accounts, backups and exploitable information. It is not unusual for weeks to pass between initial access and the actual damage. Only then is data exfiltrated or are systems encrypted and specifically those supporting the business-critical processes whose failure hits operations directly.
There are certainly traces – logins at unusual times, newly granted administrator rights or an unusually high number of file accesses are inconspicuous on their own, but together they form a clear pattern. This pattern only becomes visible once such events are brought together and analysed, for example through centralised log analysis. That is why many attacks are deliberately carried out outside business hours, at weekends or before public holidays, when monitoring is more thinly staffed.
Good defence buys time, but offers no guarantee
Of course, a great deal can be done to prevent attacks. Multi-factor authentication renders stolen passwords largely worthless, and the principle of least privilege prevents a single compromised account from opening up the entire network. Well-designed segmentation slows the spread, while up-to-date systems and vigilant employees close further doors.
If an attack does occur, every minute counts: isolate affected devices, lock accounts, contain the spread. All of this is indispensable, but there is no such thing as complete protection. Sooner or later, the day will come when an attack succeeds despite all safeguards, and then it is preparation that makes the difference.
Where technology ends, preparedness begins
The attack is long over, and the systems are encrypted. The question now is not how the attacker got in, but what happens next, and this is exactly where hesitation sets in. In what order should the critical business processes be restored? Who is authorised to approve the recovery, who acts as deputy, and which alerting channel can be used to reach staff if email and the corporate network are themselves affected? Answering these questions is the task of business continuity management (BCM).
At this point, it is not the technology that costs the crucial hours, but the lack of a plan. The knowledge is usually there; the weak spot lies elsewhere: an emergency plan is only as good as it is up to date.
After all, most emergency plans exist as a collection of separate Word and Excel files. The same piece of information – a phone number, a deputy, a process’s dependency on a particular server – then appears in several places at once: in the emergency manual, in the contact list, in the recovery plan. The more files there are, the greater the risk that a change, a personnel change, a new number, a different service provider, is not updated everywhere.
On paper, the plan remains complete, yet individual details can become outdated without anyone noticing. Often this only comes to light in a real emergency, when a number goes unanswered or the named deputy is no longer with the company.
The plan must be built from data, not documents
An emergency plan only becomes robust when the data forms the foundation and the documents are generated from it. Instead of many files maintained in parallel, there is then a single data foundation in which processes, roles, dependencies and contacts are each recorded only once. The emergency manual, contact cards and recovery plan are generated from this foundation and together make up the emergency plan – free of contradictions, because they all come from the same source. A change is thus applied everywhere at once, with no more searching and cross-checking across different files.
The same data foundation supports more than just the documents. In a business impact analysis (BIA), processes and dependencies can be used to determine how severely an outage affects the business, the order in which recovery takes place and the recovery time objective (RTO) for each process – calculated rather than estimated. This also brings weaknesses to light, such as a time-critical process that depends on a single, non-redundant resource – a single point of failure.
Continuous validation also flags anything that is still missing or contradictory, right through to a clear statement on whether the plan is ready for approval. And because roles are maintained only once, they are the very same ones that need to be alerted in an emergency: if planning and alerting are fed from a single source, an emergency can be triggered via a channel that is independent of the affected network, with a traceable record of who acknowledged the alert. This is the approach we take with NICA BCM.
Start small, improve consistently
Getting started does not have to be a major undertaking. A prioritised approach makes sense: choose a realistic attack scenario, define the critical business processes and the order in which they are to be restored, appoint responsible persons and their deputies with clear authority, set up an alerting channel that is independent of the corporate network – and run through the whole thing once in a tabletop exercise. Even this one run-through reveals whether the phone numbers are correct and whether decisions are made quickly. The results then form the basis for the next improvement step.
In this way, a document gathering dust in a cupboard becomes a genuine capability: at the decisive moment, everyone knows what to do. This saves time, limits damage and keeps the company operational – as an essential complement to any technical defence.