Les Bell

Welcome to today's daily briefing on security news relevant to our CISSP (and other) courses. Links within stories may lead to further details in the course notes of some of our courses, and will only be accessible if you are enrolled in the corresponding course - this is a shallow ploy to encourage ongoing study. However, each item ends with a link to the original source.

Opinion

A break from the usual round of news briefs; today I've decided to opine on a common topic for discussion or even debate.

Event or Incident? Or is it a Breach? Definitions, definitions . . .

I was recently amused to read a discussion on a security-related forum about whether or not various things that happened on a network were incidents or events. There was much debate, but not much getting to the heart of the matter, i.e. the security implications which might make definitions useful.

In fact, there are no clear definitions of these terms in the cybersecurity field - in part because it is constantly evolving, but also different because regulators tend to define the terms in ways that make sense for their interests, and also because SIEM product vendors do the same thing for their product interfaces.

We could also usefully add the term, 'breach', here.

In the past, and still today, I have been guided by my experience with aviation safety, where regulators generally have very clear definitions which distinguish between an accident and an incident. (Security, to my mind, is very like safety and quality - they all have to be designed in, and cannot be added as an afterthought.)

Take, for example, the US NTSB, for the terms are defined in USC 49 vol 7 section 830.2:

The term 'occurrence' is not defined, but it is pretty obviously synonymous with event; there are lots of other occurrences or events, but many or most of them are not safety-related.

The Australian Transportation Safety Bureau used (until recently) slightly more granular definitions (ATSB, 2023):

(From 1 January 2023 their definitions have been even more specific, but the intent is the same for our purposes.)

The distinction between accident and incident is very clear. So, in the security world, what's an event?

Our systems log an absolute torrent of events and many of them end up in SIEM databases. One obvious difference is that aviation events tend to be noticed by humans (flight crew or cabin crew) - engine failures, instrument failures and the like generally get pilots' attention quickly - whereas computer systems and networks generate torrents of event information, most of which are not security-related. Nonetheless, they need to be logged, because their security significance might only become apparent later, during incident response and analysis.

Which leaves us with 'breach'. Regulators have historically been more concerned with privacy than with the confidentiality of corporate data, leaving companies free to manage risk as they see fit. So, for example, the Office of the Australian Information Commissioner (OAIC, 2022) says,

That's probably not enough for our purposes. Let's fall back on the CIA triad, which defines the three primary security properties of the information we store and process:

• Confidentiality
  
• Integrity
  
• Availability

I'd suggest that if any of these properties is compromised (assuming it is one we are trying to protect) then that counts as a breach. It means that our controls have failed (or if there were no controls, that's a failure of security management, which is itself a control).

We might therefore map the aviation safety terms to infosec terms as follows:

A breach clearly equates to an accident. It means what we were trying to avoid has, despite our efforts, happened. In risk management terms, it's a loss event. Some inicidents unfortunately escalate into breaches - so every breach is an incident.

An incident is an attempt - successful or not - to defeat one or more controls. It indicates an attack and it requires us to respond - which is, of course, where our incident response plans and playbooks enter the picture. The failure of a single control, or even multiple controls, should not result in a breach, especially if we are employing a strategy of cyber resilience or defence in depth. It might be signalled by an IDS/IPS alert, or the SIEM triggering on events, or even after the fact when a batch process analyses logs.

In other words, we expect to have to activate incident response plans before the Bad Guys have achieved their objectives; penetrating just one or two layers of defences should not allow compromise of an information asset.

I've parenthetically inserted a tentative definition of 'serious incident' in the table above, just for completeness. It might be that, having repelled an intrusion attempt, you find that the same attacker tries again, perhaps with a variation of the TTP's that almost worked for them before. This indicates a persistent attacker running a targeted campaign; you may not have had a breach yet, but it's time to harden the security posture considerably. Alternatively, a 'serious incident' might be the failure of a number of controls indicating an underlying system problem that needs attention: something like poor planning, an inadequate budget or perhaps a lack of attention to security education, training and awareness.

A SIEM captures a lot of event information and allows analysts to correlate them as they investigate incidents. Events have meta-features (timestamp, result, affected resources) and features (IP addresses, email addresses, exploits, etc.) and analysts will use techniques like analytic pivoting to identify the other related events, building up a picture of the adversary's tactics, techniques and procedures and extracting indicators of compromise. SOC level 1 analysts will do the initial work of filtering out non-security related events, while level 2 analysts and threat hunters use more advanced techniques.

I would not be so bold as to claim these definitions as authoritative, but I think they - and the related discussion - are useful. I'm going to try to stick to these definitions in my own writing in future. Incidentally, there are many more useful parallels to be usefully drawn between the worlds of aviation safety and cybersecurity, and I may write some more on this topic in the future.

Australian Transportation Safety Bureau, Occurrence category taxonomy and terminology, web page, January 2023. Available online at https://www.atsb.gov.au/avdata/terminology.

Office of the Australian Information Commissioner, Notifiable data breaches, web page, 2022. Available online at https://www.oaic.gov.au/privacy/notifiable-data-breaches.

These news brief blog articles are collected at https://www.lesbell.com.au/blog/index.php?courseid=1. If you would prefer an RSS feed for your reader, the feed can be found at https://www.lesbell.com.au/rss/file.php/1/dd977d83ae51998b0b79799c822ac0a1/blog/user/3/rss.xml.

Copyright to linked articles is held by their individual authors or publishers. Our commentary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License and is labeled TLP:CLEAR.