Originally published by New Context.
The OODA loop diagram is a military strategy that has been popularized and applied to other stressful, high-risk situations, including network and cloud security breaches. The OODA loop was originally conceptualized by US Air Force Colonel John Boyd to help fighter pilots in combat scenarios gain an advantage over their opponents by responding to events with greater agility. Though your cloud security team likely won’t be facing armed opponents, they will need to respond to security incidents quickly and decisively to prevent major breaches from occurring, which is why the OODA loop diagram can be remarkably helpful in a cloud security context.
The OODA loop diagram refers to a continuous cycle of four stages—Observe, Orient, Decide, and Act—that can help you respond to a high-risk incident, whether in a military operation or a cloud security breach. The idea is to respond and act quickly enough that your attacker won’t be able to catch up, disorienting them and forcing them to play their hand before they’re ready and in a way that you can predict and mitigate with minimal damage to your organization. Let’s examine each stage of the loop so you’ll understand the basic philosophy behind OODA before we look at how it can be applied to your cloud security strategy.
During the observation stage, you must collect information about the incident so you can gain the insight you need to move on to the orientation step. Observation requires the ability to quickly differentiate between relevant and irrelevant information even while the situation is presently unfolding.
During the orientation stage, you must analyze the relevant information you’ve collected to paint a clear picture of the situation. You’ll need to discard internal biases if you want to obtain an objective view of the incident and the potential courses of action.
The decision stage is when you’ll choose a course of action. In an effective OODA loop, your decisions should be similar to a scientific hypothesis—flexible, testable, and recorded—so rather than making the same decision every time you go through the OODA loop, you’ll be adapting based on the results of your previous decisions.
During the last stage of the OODA loop, you’ll act upon the decision you’ve made, testing your hypothesis and receiving feedback about how to proceed next. This feedback will inform your observation stage as you go through the next iteration of the OODA loop. Your next OODA loop may occur during the present incident, or it may be in the future when another cloud security breach occurs.
Now that you understand each stage of the OODA loop diagram, you can start applying this philosophy to your cloud security strategy.
In the event of a cloud security breach, you’ll use the observation stage to collect data from your monitoring sensors and system logs. Depending on the sensitivity of your logging, there may be a lot of irrelevant data to sort through to find the pertinent information.
During the orientation stage, you’ll need to make sense of all the data you’ve collected and try to find patterns or clues to help inform your decisions. You should know what the expected behavior/state of your application or system is. A baseline level of understanding of all system behavior is crucial to understanding any changes which have led to the current situation. Analytics tools can help correlate malicious or suspicious events that may point to the source, method, or motive of the attack. However, it’s also possible for your analytics to generate false positives, which can act as red herrings and confuse your investigative and decision-making process.
At the decision stage, you’ll need to plan and document a hypothesis for how to respond to your cloud security incident. In this type of scenario, your decision will likely involve an entire workflow, rather than an individual action, because you’ll need your teams to stop the attack, mitigate any damage that’s been done, and patch the vulnerabilities that allowed the hack to occur. Your workflows need to be flexible enough that your teams can adapt on the fly to new information or changes in the attacker’s predicted behavior, but documentation is still critical to ensure that feedback from previous OODA loops is being incorporated into your present and future decisions.
You need to move to the action stage of the OODA loop as quickly as possible if you want to effectively remediate the incident before too much damage is done. In a cloud security context, that means revoking any compromised credentials to cloud accounts or environments, blocking the attacker’s connection, stopping rogue processes or services, quarantining infected files, and finding and patching security vulnerabilities. Once again, documentation is crucial so you can incorporate this information into your next OODA loop and refine your strategy as necessary.
One of the biggest reasons the OODA loop works so well both on battlefields and in cybersecurity is because it accounts for and emphasizes human nature. When it comes to cloud security, we tend to focus on the technological causes and solutions, forgetting that both the attackers and defenders are human beings. The OODA loop focuses on human decision making, both to bolster defenses and to take advantage of the attacker’s human reactions. Combining an OODA loop philosophy with technological security solutions will result in the most secure cloud environment for your organization.