Availability

Confidentiality, integrity and availability are always stated together, but they are not defended the same way. The first two are defended by adding controls. The third is often defended by removing controls or duplicating systems, which is why it collides with the other two rather more than the slide deck admits.

The collision is an everyday one. Encrypting a backup protects confidentiality and introduces a key that can be lost. Requiring a second factor protects access and locks out whoever loses their phone on a Sunday. Strict change control protects integrity and delays the urgent patch. None of those decisions is wrong, but every one of them is taken at the expense of availability, and it is better to take them knowing that.

In Spain the framework that forces the question into the open is the Esquema Nacional de Seguridad, which does not rate a system as a whole but by dimensions, and availability is one of them. Placing a service in a security category means writing down how long it can be down before the harm stops being acceptable.

The attacks aimed squarely at it are few and well known. Distributed denial of service exhausts a resource until the service stops answering the people who are entitled to use it. And ransomware is first of all an attack on availability: it encrypts so you cannot use your own data, and the leak came later as extra leverage.

Most outages, though, are not attacks. They are a disk filling up, a certificate expiring, a supplier nobody realised the service depended on, a change deployed on a Friday afternoon. The discipline that prevents them is the same one that prevents half the security incident list, which is why patch management and change control turn up in both places.

And there is a third category that is nearly always forgotten: recovery that does not work. A backup nobody has ever restored is not a backup, it is an assumption. When the incident is the one in the paragraph above, the copy also has to be immutable, because the backup repository is precisely the first thing the attacker goes looking for.

Availability is expressed as an objective rather than a wish, and it is three separate numbers that get conflated. The uptime percentage says how long it may be down in total: a 99.9% annual target is 8.76 hours of downtime a year, because 0.1% of the 8,760 hours in a year is exactly that.

RTO, the recovery time objective, says how long a service that has gone down may take to come back. RPO, the recovery point objective, says how much data you accept losing, measured in time: an RPO of one hour means accepting the loss of the last hour of work. Both are set service by service and by the business, not by the systems team, because the people who know what an outage costs are the people it happens to.

The usual mistake is setting the same three numbers for everything. A billing system and an internal file server do not deserve the same objective, and promising the second what the first needs is the quickest way to miss the target on both.

A penetration test does not knock anything over. Denial of service stays out of scope unless it is expressly agreed, and that is written into the rules of engagement before the work starts. What does get measured is the surface something could be knocked over through, and above all whether recovery is real or is a document.

The questions are specific. Does the backup console live inside the same domain as the servers it backs up? Can a compromised account delete the copies or shorten their retention? When was the last restore test, and who signed off the result? Is there a list of services ordered by what an outage costs, or will that be decided during the incident? That last one is what separates an incident response plan from an intention.

On ENS compliance work those answers stop being good practice and become named, numbered requirements, because the availability dimension is what determines which measures are mandatory for that system and which are not.