“Left of Bang”

The term “Left of Bang” may be familiar to those with military background or experience, especially if that includes experience of the US military. But the concept is simple enough. There’s even a decade-old book all about it with the same title (ISBN-13: 978-1936891306, published June 2014, easily obtainable).

What is “Left of Bang”?

Once an incident – whether that is an IED or an ambush in a combat situation, or a cyber attack against a government or commercial system – has happened, your activities mainly boil down the those on the right-hand side of the infographic: React, Recover, and Regret. Talk to JLR, M&S, or the Co-op about those. There really are not the “Three Rs” that you want to be putting your efforts into – disaster has already struck.

But before the incident, we are “Left of Bang”; it hasn’t happened yet, and we may still be able to prevent it. Here we are able to perform activities on the left-hand side of the infographic: Threat Detection, Pre-emptive Action, and Prevention.

Situational Awareness

The key element differentiating these two different scenarios is Situational Awareness. How we achieve that is different for cybersecurity than for a hostile military environment, but the principles are the same.

“Plug and Play” works half the time: “Plug” always works!

With an IT system, situational awareness comes from Protective Monitoring. But, as with the old joke above, all too often that is only a half-done job.

Protective Monitoring requires that events and information be logged. But logging by itself is NOT Protective Monitoring. Those logs need to be processed, in real-time or near-real-time, to extract the all important indicators from the plethora of log entries.

Protective Monitoring: Logging and Log Analysis

Logging is science, but log analytics is more akin to an art. Done properly, it gives you advanced warning – “Left of Bang” – with a fighting chance of avoiding a successful attack or disastrous incident taking place at all. But it is rarely given the attention and ongoing consideration that is required to achieve this.

Creating the analytical rules requires some Big Brain thinking; a combination of forward thinking (“What can we detect through log correlation that indicates a risky situation developing?”) and reverse thinking (“If there is a successful attack of type XYZ, what indicators might foreshadow it, and can we look for them in real time?” – a bit like starting from the end of a game of chess and working out what moves led to that result: Reverse Chess!)

Presence and Absence: Both Matter

You need to look for both the presence of certain indicators, which may point to an attack of some sort, but also, importantly and very often neglected, the absence of certain indicators.

A simple example: lots of failed authentications in the logs may indicated a password grinding attack. But an absence of any authentications (even successful ones) in the logs, over a period long enough for that to be statistically highly unlikely, indicates that the logs are not being recorded correctly – so we are currently blind to at least some event types.

Ignore the negative use-cases and you risk missing important and dangerous activities taking place right under your nose, and that reduces your chances of staying “Left of Bang”.

What Can I Do?

Even if your role is managerial rather than technical, you can ask questions – some suggestions follow. You can even introduce AI as part of your analytics if you like – but that absolutely does not remove the need for Big Brain thinking in the first place!

When were our Protective Monitoring or Log Analytics Rules last thoroughly reviewed and updated?

This is something which needs to be undertaken on an ongoing basis. It’s not a task to give to your least experienced staff either. You’ve probably spent a lot of money on your log collection and analytics system; don’t waste it by failing to use them to best effect.

Ensuring that sufficient resources are allocated on an ongoing basis for this is also a very good idea.

Are the use-cases we have for log processing created for, or tailored to, our specific system, data, and threat profile?

Out-of-the-box use-cases will be generic and have little relevance for your specific system and threats. It takes and investment of time and effort to tailor them, but this is what gives you genuine situational awareness rather than just a smoke & mirrors tickbox.

How many negative use-cases have we implemented?

If the response is “What’s a negative use-case?” then you have identified a gap in your situational awareness. Get it fixed!

Are there meaningful absences from the logs which could be detected but are not being looked for?

What advanced warning alerts did we get for each of the security incidents over the last year?

If the answer is “few or none”, then it’s time to consider what indicators could have been spotted, and to implement use-cases to look for them.

If the answer is “loads” (or similar), then it’s time to consider whether those indicators were acted upon in time to avoid the “bang” – or not.