In the early 2000s, the US Marine Corps' Combat Hunter training program introduced, among many other concepts, the ‘left of bang’ idea as a way to improve situational awareness and save lives.
The way ‘left of bang’ works is simple.
Any critical event that causes significant disruption, loss, or other negative outcome -- an attack, injury, or breach of security -- can be mapped out and analyzed on a timeline. The actual occurrence of the event -- the thing that happened -- falls directly in the middle of the line, equidistant from both sides, at a point labeled “bang”.
To the left of the bang are the things that happened before the event. Everything that was done in the past, all proactive measures, the planning and preparation -- or lack thereof -- live left of bang.
On the right of the bang is everything that followed the event. It’s the time for cleanup, remediation, and reactive measures. It’s the reflection period or in much more serious cases, the aftermath.
Patrick Van Horne and Jason A. Riley, two former active-duty Marines, took the concept further in their 2014 book Left of Bang: How the Marine Corps' Combat Hunter Program Can Save Your Life. The book dives into the idea, exploring the left side of the timeline. The authors dig far into the concept, illustrating how detecting early warning signs and recognizing oncoming danger left of bang can help disrupt, prevent, or avoid attacks altogether.
Horne and Riley show how shifting left isn’t simply about ‘an ounce of prevention’ but how the concept can literally save lives.
But what does this have to do with your DevOps program, and can the fundamental ‘left of bang’ principles improve your security?
In software development, the concept of ‘shifting left’ is not new. In its simplest form, ‘shifting left’ refers to testing earlier in the life cycle. This tactic helps prevent costly delays and improve product quality.
When applied in DevSecOps environments, earlier testing can identify potential vulnerabilities and improve security.
While shifting left is a great starting point, it isn’t enough to guarantee your program is left of bang.
Consider your SDLC is moving along smoothly, you have shifted your testing left, and you have implemented security tests earlier and more often. Suddenly, you’re seeing reports of a data breach and your application has been compromised.
In this scenario, you have encountered a “bang” event.
Fortunately, there are some simple proactive steps you can take to improve your cyber situational awareness and keep your program left of bang.
Knowing the Threat: Identify What “Bang” Looks Like
Identifying bang events is an important step that is often taken for granted. If you were put on the spot and asked to identify what critical events could disrupt your service or cause significant loss to your organization or customers, could you answer?
Let’s take a look at some of the more common bang events that could affect your organization and why they are important to identify.
Data Breaches
You don’t have to look very deep in the news to find reports of significant data breaches. Take for example the 2020 Marriott breach that exposed personal data for over 5 million guests. It’s safe to say that this breach was a bang event for the Marriott team. But not all data breaches are the same.
When considering what a data breach would mean for your organization, it is important to consider what kind of information you are responsible for and how that information could be used.
Does your application hold financial data? Personally Identifiable Information (PII)? Protected health data? If you were to experience a data breach, what would the result be?
Answering these and similar questions can start you off on the right path to better protecting your organization and your customers.
Phishing Attacks
Successful phishing attacks are a unique type of bang event in that they are almost always a stepping stone to a much larger data breach. Phishing attacks are often an attempt to obtain user credentials, financial information, or other sensitive data. The attacker then uses that information to pivot and elevate the attack.
According to Verizon’s 2020 Data Breach Investigations Report, 22% of data breaches in 2019 involved phishing attacks, while 37% of breaches stole or used credentials.
It’s important to identify phishing attacks as a bang event separate from the larger data breach. Even if a phishing attack is successful, there are ways to mitigate the damage and reduce the risk of a more serious compromise.
Staying left of bang for phishing attacks takes unique measures, starting with targeted training for employees who do not deal directly with security, ensuring strong credential protections and limiting credentialed access to data.
Disasters
Some bang events may seem completely out of your control, like natural or geopolitical disasters. Even so, it’s important to identify reasonable risks and potential outcomes for these events while you’re left of bang so that your team can recover quickly if you encounter them.
Take for example, the recent pandemic that forced many organizations to have their employees work remotely. Most were significantly underprepared for this bang event, having never considered the possibility.
Security threats boomed during the lockdown period of the pandemic and organizations such as the World Health Organization (WHO) experienced dramatic increases in cyber attacks. Despite this, according to a recent report from Tanium, 93% of surveyed organizations said they delayed security priorities during lockdown.
It may be hard to predict what disasters your organization may face. Consider what disasters are most likely to happen in the areas where your employees, servers, and other critical infrastructure are located. Knowing the bang events that are possible will help you craft solid recovery strategies that will allow your organization to remain operational.
Know Your Assets: Understanding What You Have
Another important step in ensuring your DevOps program stays left of bang is to identify and inventory your assets. Different types of assets can pose different types of risks, and must be managed accordingly.
Hardware Assets
Knowing the type and location of hardware used within your organization will help shape your left of bang strategies. Remote laptops will require different security than in-house PCs, and a receptionist’s system poses different access threats than one in a locked office.
Third-Party Software
DevOps environments generally rely heavily on third-party software, from IDEs to third-party testing tools, communications software, deployment applications, code repositories, and more. Having a complete catalog of all third-party software will inform your decisions on acceptable risk. It will also help you understand potential threats that may come from a source outside of your control, and how to respond if the vendor is compromised.
Consider what happened to General Electric in 2020. GE used Canon Business Process Servers for HR purposes. Canon experienced a data breach that exposed PII for GE’s employees and their beneficiaries. Although GE’s systems were unaffected, the breach posed a significant risk to their own organization.
Knowing the third-party software within your organization and understanding their security posture will help improve your own security. It will also help you identify legitimate vendor communications as well as malicious communications masked as coming from your vendor.
Human Assets
While technology is an essential component to any DevOps program, it’s the people that make it all work. It’s those same people who pose a significant risk to the organization. A 2019 report from Kaspersky shows the most frequent incident targeting enterprise and SMBs is inappropriate IT resource use by employees, followed by malware infection of company owned devices.
Understanding where people sit in the organization structure, what data they have access to, and how they use that data is key to building your left of bang strategies. Segmenting data access by job requirement, ensuring secure use of company devices, and providing efficient methods of reporting suspicious emails are some simple steps to help keep your essential human assets from becoming your biggest liability.
Knowing Your Setup: Properly Manage Your Tools
Shifting your testing left might feel like a solid proactive step, but it means nothing if your tools are not selected, distributed, and configured with security in mind.
Tools are an important part of any DevOps program. They can make the SDLC run infinitely smoother, but they can also cause problems.
When selecting tools for your team, it’s easy to simply consider functionality. But applying left of bang fundamentals means also considering security risks associated with the tool itself, how it’s used within your environment, and how the vendor addresses security.
Once you are confident with the tools you have selected, consider who needs to have access to them. Ensure that anyone who is given access is either familiar with the tool already or is given proper training on how to securely use the tool.
The next step is to ensure all tools are properly configured with security in mind. Ensure any default credentials are changed immediately and that the tool is tailored to your specific environment.
It can be beneficial to use automated security testing tools, but ensure the results are reviewed and verified. Some configurations may dismiss low or medium threat findings. Depending on how your environment is connected, however, those lower threats could be pivot points for attackers to gain deeper access into your systems.
What’s Next? Make a Plan
Armed with all this knowledge, you can collect your current policies and procedures and assess if they match up to your left of bang goals. There’s a number of things you’ll need for this process.
Our list of starters include:
- Cyber security
- Strong Credential Policy
- Third-Party Software Policy
- Security Testing Policy
- Social Media Policy
To learn more about making a plan and what to do next, read our white paper.