The last few years within the Cyber Security Operations Center (SOC) Domain, several new technologies having been trending that enhance SOC capabilities. In particular I want to talk about EDR (Endpoint Detection & Response) in combination with SOAR and SIEM.

This technology (EDR) enables the organization to collect and correlate very intimate details of an endpoint within the organization's network. It also provides a response capability that provides instant mitigation and forensic functionality on the endpoint itself (gives the SOC "teeth" to bite into the incident).

EDR helps the SOC mitigate and investigate much quicker when it comes to cyber security incidents. Still one of the most important key KPI's measured within security operations centers is the time from detection to eradication of cyber security incidents.

Within some SOC builds there is still intense focus on the SIEM and making sure massive volumes of logs are on-boarded inside the tool. This in turn requires a relative amount of time spend followed by a series of use cases being badly configured which gives rise to the following time consuming issues:

   A. Flood of alerts to Analyze
   B. Extensive time spend on Manually Escalating to the right team
   C. Time consuming and limiting capabilities for mitigating the potential threat on the endpoint directly*

Therefore I would like to propose an alternative OODA-Driven SOC Strategy to building or expanding SOC capabilities within an organization. Instead of focusing on the Traditional SOC Strategy with on-boarding log sources, focus on Integration and Quickly responding to cyber security incidents.

How does the OODA Loop apply to a SOC?

The OODA Loop is an agile iterative learning and operations cycle used in the military and the cyber security domain. More information about this model is on the wiki: https://en.wikipedia.org/wiki/OODA_loop . Below here you can see the OODA loop translated to general activities associated with building and running a SOC.

OBSERVE - Data Collection (logs from the endpoint or the device)

ORIENT - Data Analysis (correlation, Dashboarding, Reporting)

DECIDE - Playbooks (Manual, Semi-automated or fully automated tasks)

ACT - Automate (Isolate, Disable, Remove or Change Device/Device Configuration)

Traditional SOC Strategy vs. OODA-Driven SOC Strategy

What is the difference between Traditional SOC Strategy vs. OODA-Driven SOC Strategy?

	Traditional SOC Strategy	OODA-Driven SOC Strategy
Technology Focus	SIEM	SIEM, SOAR and EDR
People Focus	SIEM Admin, SOC Analyst, Incident Responder	SIEM Admin, SOAR Admin, EDR Admin
Process Focus	L1, L2 Alert Analysis	Overall OODA Loop
Metric Focus	Amount of log sources onboarded	Amount of (partially) automated OODA Loops
Governance Focus	Log source onboarding	OODA Automation & Integration
Use Case Focus	Rules, manual analysis & response	Rules, Playbooks & Automation Integrations

Key Critical Notes

This proposed OODA-driven SOC strategy comes with some critical notes that should be taken into account before deciding on this strategy.

Any SOC initiative should be driven through in-depth Information Risks Analysis and in-depth Cyber threat intelligence (CTI) threat modeling analysis. This is the best and ideal way to build, run and drive a SOC.

Unfortunately this is not the case for some organizations, where due to lack of resources a technology-centric "just buy the box" approach is executed.

This strategy is best for these "buy-the-box" group of organizations as it keeps things simple, and allows the procurement process to be re-balanced for better cost-savings in the long term (automation helps in the long term).

EDR is an endpoint centric tool which does not (or only in limited degree) cover the network monitoring, this should be kept in the back of the mind of the Cyber Security leader when focusing on log source on-boarding.

The way to push down on SIEM spending and reallocate spending to the EDR and SOAR solutions is to have a 80/20 analysis of the most critical assets you want to protect. This allows for prioritization and focus on key areas within the SOC.

The diagrams used in this article are used as example to get across an way of thinking it is not backed by actual data, just rational logical pragmatic thinking.

Time spend estimates compared

These two pie charts attempt to illustrate the 100% time spend by a SOC team in it's build and run activities. The OODA-Driven approach proposes spreading time allocated out evenly over the full cycle, while traditional approaches might stick with an over focus on Observe and Orient.

	Traditional SOC Strategy	OODA-Driven SOC Strategy
OBSERVE	50% of time focused on Log source onboarding	25% time spend on log source onboarding (12,5% endpoint and 12,5% on network)
ORIENT	30% of time spend alert analysis	25%: 5% time spend on alert analysis, 20% spend on additional rules
DECIDE	10% of time spend on deciding for a response	25%: 5% time spend on deciding, 20% spend on new playbooks
ACT	10% of time spend on manual mitigation	25%: 5% time spend on mitigation, 20% spend on integration

Time spend over 6 Month period time

The following diagram tries to illustrate that with a "log source onboarding focus" you end up spending a lot of time manually handling incidents through analysis and response. While focusing on "OODA Automation" will provide more free time to increase capabilities overtime.

How do EDR, SOAR and SIEM fit in?

The following diagram attempts to illustrate the integration between, SIEM, SOAR and EDR following the OODA-Driven SOC strategy.

Conclusion

The main point I have tried to make in this article is that: investing less in SIEM and more in EDR and SOAR (a balanced approach across all three) will provide more room for reducing the overall time of the: "Detection till eradication" KPI through the means of automating the OODA Loop with SOAR and EDR tooling.

Menu

An OODA-driven SOC Strategy using: SIEM, SOAR and EDR