I recently created a blog post where I proposed the OODA loop as part of a central SOC strategy. I've received lots of positive feedback from others on the usage of this model in this particular blog post, therefore I will compound onto that post as i have in the past used the OODA extensively for designing Security Operation Center's (SOC) processes and metrics. The way I used OODA during that time was with a higher generalization version within the context of a SOC. The usage of the model within the SOC context will function as a compass for Cyber Security leaders to judge any situation quickly and strategically. Thus enabling the leader to respond quickly when he sees a "Strategic Inflection Point" on the cyber battlefield.
What is a Strategic Inflection Point?
"A strategic inflection point is a time period when an organization must respond to disruptive threats in the threat landscape effectively or face deterioration. An inflection point, in general, is a decisive moment in the course of some entity, event or situation that marks the start of significant change."
Once a strategic inflection point is observed by the cyber security leader there is a possibility for a "coup d'oeil"
What is a COUP D'OEIL?
"The coup d'œil refers to the ability to discern at one glance the tactical advantages and disadvantages of the terrain"
Another practical definition might be:
"A selective projection of past elements into the future, in a new combination as a course of action that might or might not fit your previous goals, with the personal commitment to follow through and work out the details along the way" - William Duggan
In essence: doing things differently
When the emergence of a strategic inflection point and coup d'oeil plays out, the need for cyber response to do something different quickly comes up. To be able to do things differently on the cyber battle field and implement change quickly within the SOC, it is required to make use of an adaptive type of life-cycle that is flexible to change on short notice, for example: OODA or SCRUM.
Within the SOC there has always been "light" development activities like: Use Case Development (any form of Detection rules for SIEM, EDR, IDS, IPS etc.) but generally it is quite rare to see this treated as a official development activity. With the emergence of SOAR tooling and automation within the SOC, python developers are getting more and more required within the team. This in turn will also increase the development workload that is associated with SOAR and automation.
Generally people working in SOC's do not have a extensive development background and creating these development processes and working like a developer do not always comes naturally, therefore it's important to properly teach SCRUM (and use a scrum master) within the team before starting of with such initiatives.
Putting PDCA, OODA and SCRUM together
In this article I will propose to cyber security leaders an idea to put services in three major camps PDCA, OODA, SCRUM. The reason why I make this proposal is because some cyber security leaders still treat everything as one big ISMS with PDCA controls that periodically get reviewed, this does not work in a SOC that is adaptive by nature and tries to model the threat landscape proactively on a daily basis.
What are the differences between the three?
In the following table i've tried to capture the difference between the three.
|Plan, Do, Check, Act
|Observe, Orient, Decide, Act
|Analyze, Design, Construct, Integrate, Test (on an increment level)
|Quick working deliverables
|Working product Focus
|Bare-Minimum Workable Data
To visualize this concept I've created the following diagram where the key life-cycles are integrated:
Critical Note: There are definitely other services within Security that do development (like within IAM) but i left these out of scope for this article, as my main focus is SOC.
Critical Note2: Threat hunting has two forms: 1. hypothesis based (PDCA) and 2. CTI Validation Based (OODA) didn't really work in this model unfortunately
To go a little bit more in detail on OODA and it's alignment of potential sub processes within the SOC, the following model was created:
For the development processes within a SOC they will be aligned to a micro increment within SCRUM.
Critical Note: Please interpret this as a increment of a sprint that is backlog driven (as in the normal scrum process).
Now I have shown the alignment of the traditional SOC processes with OODA and SCRUM life-cycles. Following this I want to show the value of using OODA as a framework to derive metrics from inside a SOC.
What does the OODA Loop really want?
If you look at the cycle closely you can derive two competing priorities on every OODA iterative loop:
1. Faster iterations of the loop
2. Higher quality iterations of the loop
Higher quality generally means more time spend on the activities thus slowing down the loop. This can only really be countered with automation to again speed up the loop. Speed and Quality are in this case on a tension field with each other.
To go deeper on what these OODA loop steps mean for a SOC, I've created the following diagram to explain it's desires for the SOC:
Using this as a framework for designing metrics for your SOC, one can start determining metrics aligned with the processes and the life-cycle. In the following example I've combined the development and the operations processes in one view to measure performance.
Critical Note: These metrics can be diversified by measuring per time period, in relation to each other or overall quarterly trend.
Critical Note2: Depending on your preference and organizational context one might put more emphasis on Quality or more on speed focused metrics.
Using OODA and SCRUM as lifecycle processes within an organization's cyber security program, keeps things A. Simple, B. Agile and C. Allows for quicker and more qualitative response during a strategic inflection point and coup d'oeil of emerging cyber threats in the fast-changing environment of the organization.