Is loss of availability automatically a security incident?

Question

Suppose you need to define for an organization what should be considered an information security incident which, when observed, triggers security incident response (investigate, contain, eradicate, recover – details of which might also need to be defined).

The definition of a security incident typically includes security breaches (i.e. loss of confidentiality, integrity or availability). For example, ISO27000 defines an information security incident as:

single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security

and information security as:

preservation of confidentiality, integrity and availability of information

Then there is the non-security definition of incident. For example, according to ITIL, an Incident includes any loss of availability (also failures of components that do not immediately cause downtime, such as a single disk in a RAID or one out of multiple nodes in a redundant configuration).

My reading of the ISO definition is that any loss of availability would be considered an information security incident. Now consider the following scenarios:

• A software bug (which QA failed to catch) causes a network service to crash sporadically, but not in a way that would be exploitable by attackers.
• After running 24/7 for several years, a server is shut down for maintenance work on the power supply. When it is switched on again, its hard disk fails to spin up (assuming the disk is not redundant, or both disks of a mirror set are affected). A new disk must be installed and the last backup restored.
• A network adapter stops working due to a hardware defect.

They are clearly incidents in the ITIL sense, but I would not necessarily count them as security incidents. However, the ISO definition would be broad enough to include them.

Is there any textbook definition as to when loss of availability is not an information security incident? If not, what is a good practice to deal with this? Should the security folks really be called to investigate any hardware failure or the like?

Answer 1

Is there any textbook definition as to when loss of availability is not an information security incident? If not, what is a good practice to deal with this?

The problem with textbook definitions is that they are often very black and white, which means that if you try and follow them in the real world they don't work very well. Because as you say, if you follow those strict definitions to the letter than all kinds of things become "security incidents" (such as a user spilling coffee on their laptop and breaking), to the point that "security incident" becomes fairly meaningless.

And then what you end up with is a huge flood of "security incident" reports about trivial things, which means that the security team is much less likely to be able to identify and respond to more serious incidents.

Should the security folks really be called to investigate any hardware failure or the like?

Absolutely not, because that's not their skill set. In the same way that if the power goes out to the server room, you wouldn't expect the security folks to start poking around in the UPS and breakers to try and fix it.

Which isn't to say that they shouldn't be involved - for instance if the hardware that's failed in one of your central log collectors then you should be talking to the security team to understand what the impact of that would be on the wider security of the organisation. But if it's the TV screen stuck on the wall showing a slideshow of corporate branding then you probably shouldn't be.

So the questions I would be asking are:

• Was this incident a deliberate attack?
• Does this incident have a knock-on impact on the security of other systems?
• Are the knowledge and skills of the security team relevant in responding to this incident?

If the answer to all three of those questions is "no", then it's probably not useful to call it a "security incident" and get the security team involved.

Granted, it's a bit of a woolly definition - but most of the real world is made up of greys rather than being black and white. Because ultimately, the point of recording something as a "security incident" isn't to try and meet some textbook definition - it's to allow the organisation to respond to it in an effective way. And thus your definition of a "security incident" should be one which supports that goal.

Answer 2

It depends on your definition.

If you're going the ISO 27001 or other ISMS route, you somewhere define your security goals. If availability or rather a certain level of availability is defined as a security goal, then a loss of availability beyond that level should be considered a security incident, because it affects your defined security goals.

In defining your goals, you would take common scenarios such as the occasional drive or power adapter failures into account. That's why we don't see "100% availability" but rather "99.9xx" numbers.

If your downtime goes lower than your defined goal, you definitely do want to look at why and change something. Note that in ISO 27001 that change can well be lowering the security goal if your analysis indicates the goal was unrealistic.

Now consider the following scenarios:

The thing is that in the real world, you often don't know immediately why something went down. Identifying the cause is already part of the incident response.

But yes, once you found that, say, a hardware defect caused the issue, the security people can usually go and do other stuff and leave fixing to the operations people.

You would still want to have an incident report that documents these facts.

---

tl;dr: "availability" is not binary. Define the desired availability level as a security goal and only treat outages violating that goal or where analysis identifies a security breach as the cause as security incidents while other outages are operational incidents.

Answer 3

These all can be technically considered incidents. One has to triage the time they have, to follow up, prevent or mitigate incidents that matter the most, and ignore the least significant ones.

The risk weighting model I personally like is "severity, occurrence, detectability" from FMEA.

• Severity: how much damage this can do. A broken network adapter can cause downtime. The severity of this can be greatly reduced by installing two.
• Occurrence: how likely is this to happen again. If it's part of an attack, max out this number. Lost passwords happen frequently, so require a policy for handling them. Global disruptions are relatively rare.
• Detectability (reversed): how much time passes between detection and actual damage. A rootkit is the worst case: can stay undetected after the damage. Network adapter failure is in the middle: immediate detection. Drive failure in an array gives one plenty of time to respond and avoid data loss.

Use any scale you like (low/mid/high, 6-point, 10-point) and multiply the three to get a risk priority number. That's a good starting point for what to address. There are other frameworks to choose, it's more important to have one than which specific one it is.

While availability is, in a broad sense, part of information security, it's a part large enough to be normally split into its own field, Reliability Engineering. So most availability concerns are handled by hardware or SRE teams, and Infosec is only involved when they're connected to confidentiality or integrity loss, or to actual or possible attacks. Infosec is usually most concerned with high severity, low detectability events.

For an example of the latter, suppose you outsource failed drive replacement. Now there's outsiders handling your hardware, so do they need IDs, should you encrypt your data (yes), should they be watched full-time, what to do with a failed drive, should you keep an inventory to confirm it's the same drive? That's security concerns beside availability.

Even more globally, both Infosec and SRE can be part of a overall Risk Management framework, which covers financial, reputational, technical, strategic et cetera risks. Separating reliability from security is just specialization, since they require different skillsets.

Answer 4

Obviously, defining a "security incident" may be different than an "incident". These are very fluid definitions which will get different answers from many people. From a cybersecurity standpoint, You are generally covered if you have adequately defined the parameters for what you define as an incident and have a defined, in writing, reasoning behind that definition that complies with the standards. Record keeping and routine standards reviews are a must to ensure you meet the "letter of the law" so to speak.

If you are looking for CYA coverage, it may be prudent to hire a third party cybersecurity firm to review all of your documentation and procedures including definitions, maintenance procedures, decommissioned hardware procedures, incident response plan, incident recovery plan, employee training, pentesting, etc. This ensures and proves that you have exercised due diligence by contracting a certified third party to conduct a review.

Just to address one of the scenarios you brought up, "After running 24/7 for several years, a server is shut down for maintenance work on the power supply. When it is switched on again, its hard disk fails to spin up (assuming the disk is not redundant, or both disks of a mirror set are affected). A new disk must be installed and the last backup restored." Is this a cybersecurity incident? I would say the answer is "Yes". My reason is simply that, although no threat existed that caused this issue, disposition and destruction of the failed drive presents a "possible" security threat that must, at a bare minimum, be tracked, managed, remediated and reported.

Answer 5

We get this type of question a lot around Availability as being part of the CIA triad.

Defintions

Keep going in your exploration of definitions and look at "Availability": https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en

3.28
information security
preservation of confidentiality (3.10), integrity (3.36) and availability (3.7) of information

3.7
availability
property of being accessible and usable on demand by an authorized entity

Note that it says "property of" not "state of". The loss of the "property" of availability is different from the loss of the "state" of availability.

According to ITIL (which you mention), Availability is:

The ability of an IT service or other configuration item to perform its agreed function when required.

Can you see the logical separation between the two different types of Availability? One is a property, the other is a state/ability. And the infosec and service delivery management processes and goals are different.

Is all Availability the domain of Security?

My reading of the ISO definition is that any loss of availability would be considered an information security incident.

However, the ISO definition would be broad enough to include them.

So, let's take your argument that all Availability concerns fall under the ISMS and are managed by the security department and the ISMS. And let's also consider that we're talking about the management system (ISMS or ITIL) that has the primary responsibility since that appears to be what you are talking about.

That would mean, in this argument, that all Availability Management in ITIL is now a subset of the ISMS. Power, electrical code compliance, operating environment, humidity, static management, network and storage capacity, service load, hardware faults, SLAs, anticipating customer requirements, delivery design, availability reporting and metrics, etc. are now all managed in the ISMS.

First, let's do a sanity check: do you believe that that is what 27000 intended in the definition and in the rest of the document family?

Second, does the rest of the 27000 family support all this activity?

Third, does that mean that only Availability Management in ITIL gets subsumed by the ISMS, or does all of ITIL get subsumed? If only part, why just a part? Are all operational concerns now to be managed under an ISMS?

Fourth, does it make more sense that there are categories of Availability, one related to the security of information and another related to service delivery, even though the wording isn't specific?

Let's test that last one. Let's look at the definition of "audit scope":

3.4
audit scope
extent and boundaries of an audit (3.3)

To use the same broad brush of interpretation, does "audit scope" include the size of the room that is used to conduct audits, as the walls of a room are included in the undefined term "boundaries"?

The definitions in 27000 are very light, as you can see.

So, let's circle back on that sanity check.

The understanding is that there are categories of Availability; one is around security (and can include BCP/DRP) and one is around operations. And that is alluded to in the 27000 definition: "property of being accessible and usable on demand by an authorized entity".

Having the property to be used by an authorized entity is the key differentiation.

• A blown capacitor on a network card is an operational concern (i.e. the "ability to perform" (a la ITIL)).

• The "property to be used by an authorized entity" (and by extension, not by an unauthorized entity) covers whether systems and information should be accessible. Should that device have a network card? What network should it be on? What access (availability) should it have to other networks and nodes? etc.

So, I go back to my comment: "all poodles are dogs, not all dogs are poodles". Infosec Availability is a form of Availability, but not the sole category of Availability.

Confusions

There are some confusing elements in reality, for example:

• DDoS is a flooding of network capacity: is that a a security concern or an operational concern?
• BCP/DRP is about getting services running again: is that a security concern or an operational concern?
• Secure coding/system design is about building things in a way to meet security requirements.

The reality is that some Availability concerns tend to fall under security because of various side issues.

DDoS is purely a capacity and throttling issue, but tends to fall under Security because Security resources tend to understand the "properties" of the causes and tools to create the problem. But, ultimately, it is an operational issue.

BCP/DRP is often championed by Security, but should not be solely in the domain of security, at all (it's a Management issue, really). But just because security pros tend to be the most experienced in the process of creating and testing BCP/DRP, that does not make it purely a security topic.

Secure coding/system design is monitored and tested by security, but is the domain of the developers and designers. It's not security's job to make those things secure. However, security professionals tend to lead those discussions due to lack of training and knowledge of developers/designers.