Natural disasters

Information security is about three things: that data is not seen by the wrong people, that it is not changed by the wrong people, and that it is there when it is needed. Natural disasters attack the third, availability, which is why they belong in a security glossary and not only in a facilities manual.

What sets them apart from the rest of the glossary is that there is no adversary. An earthquake, a flood, a wildfire or a storm does not pick a target, does not change tactics when you defend yourself and does not learn. That makes them easier to model and, for exactly that reason, less forgivable when they catch an organisation with nothing in place.

It also changes the kind of defence. Against an attacker you detect and respond; against a natural disaster you anticipate and rebuild. There is nothing to detect, because the warning comes from the weather or the ground rather than from a security log.

And there is an overlap worth keeping in mind: the preparation that works for a natural disaster is almost the same as the one that works for ransomware. Both are answered with copies the incident cannot reach and with a return-to-service plan somebody has rehearsed.

Physical infrastructure. Datacentres, comms cabinets and electrical panels sit in a specific place, and that place can end up underwater, without power or without access. What you lose is not just the equipment: it is the time it takes to have another one running.

Connectivity. A service can be perfectly alive in the cloud and unreachable because the fibre into the office has been cut or the local mobile network is saturated. Continuity does not depend only on where your servers are, but also on how you reach them.

Physical security. An evacuation leaves empty buildings, open doors and unattended equipment, and an emergency is precisely the moment when nobody is watching who walks in. Laptops and backup media carried out by hand in a hurry are among the things that most easily end up unaccounted for.

People. A disaster hits the responders first. A plan that depends on one person who knows how something is restored is a plan that fails on exactly the day that person is dealing with their own emergency.

And judgement. Under pressure, shortcuts get taken: a temporary access is opened, a password is shared, a service is stood up without its usual restrictions. Those shortcuts tend to outlive the disaster, and that is where an event with no adversary ends up opening the door to one with an adversary.

First, knowing what you have and how long each thing can be down. Without an asset inventory nothing can be prioritised, because nobody knows which system holds up which business process. It is the step most often skipped and the one that makes the rest useless.

Second, the copies. Out of the reach of the event, meaning in another geography, and with at least one that cannot be deleted from the same place the original is administered from. See backup and immutable backup.

Third, the two numbers that order everything else: how long you can be down, and how much data you can afford to lose. Once those two exist and are agreed with the business, the technical decisions stop being a matter of taste.

Fourth, the rehearsal. A restore nobody has performed is not a backup, it is an intention. Restore for real, with a stopwatch, into a separate environment, and with the person who would actually be on call rather than the one who designed the system.

And fifth, writing down who decides. Most of the time lost in a crisis does not go on restoring: it goes on working out who has the authority to declare the contingency and to decide what gets sacrificed first.

The case is hypothetical and exists to show the order of the decisions, not to describe any real incident.

A company keeps its primary datacentre in a region exposed to severe storms. The warning arrives with hours to spare.

With the preparation done, those hours go on what they are worth: checking that the latest copy is complete and reachable from outside the area, confirming the alternate environment starts, telling customers which services may degrade, and sending people home before travelling gets dangerous.

Without the preparation done, the same hours go on discovering that one system’s backup had been failing quietly for weeks, that nobody knows the credentials for the alternate environment, and that the only person who has ever restored it is on holiday.

The difference between those two paragraphs is not decided during the storm. It was decided months earlier, on the day somebody rehearsed the restore or the day somebody decided it was not necessary.

Keeping the copy in the same place as the original. It is the classic mistake and it still turns up. A copy in the same room as the server protects against a deletion, not against a flood.

Assuming the cloud already handles it. A provider replicates within its own remit and under its shared responsibility model, not under yours. If all your resources live in one region, you have the same problem on somebody else’s invoice.

Confusing high availability with recovery. Duplicating servers inside the same building covers one of them breaking, not the building disappearing. They are two different costs solving two different problems.

Rehearsing the restore and not the whole process. A file coming back does not mean the service comes back: DNS, certificates, integrations and the credentials of the neighbouring systems are all still missing.

Not touching the plan for two years. A continuity plan ages at the speed the infrastructure changes, which is fast. A plan naming servers that no longer exist is worse than no plan, because it inspires confidence.

Compliance schemes require continuity, and they require it rehearsed rather than declared. An ISO 27001 certification rests on evidence that the organisation has practised getting back into service, not on a document containing the plan.

In the Spanish public sector the requirement runs the same way: the Esquema Nacional de Seguridad grades continuity and backup measures according to the level of the information and of the service, so the auditor’s question is not whether you have copies but whether you have the ones your level demands and whether you have shown they work.

What usually fails is not the absence of a plan. It is the absence of the evidence: the date of the last restore, how long it took, what went wrong during the rehearsal and what was fixed afterwards. That record is the asset, and it is produced by rehearsing.

What an offensive security engagement adds here is the other half of the question: if your recovery plan leans on an administration console or a backup repository, somebody has to check that an attacker moving through the network does not reach that console before you do. That is what an internal penetration test measures.

Is a natural disaster a security incident? Yes, if it affects the availability, integrity or confidentiality of information. It is handled through the same incident response procedure, even though there is nobody to attribute it to.

How often should recovery be rehearsed? Often enough for the result to still be true: at least once a year, and always after a significant infrastructure change. The calendar matters less than the fact that somebody actually runs it.

Are backups worth anything if they have never been restored? Less than they look. A copy nobody has restored has an unknown value, and the day of the disaster is not the moment to find out.

Does Asperis do this? Asperis does not provide business continuity or disaster recovery services. We do review, within an ISO 27001 or ENS engagement, that the backup and continuity controls the standard requires exist and have been tested.