Incident Response

The Second Building Block for the SOC of the Future: An Open Integration Framework

The SOC of the future must be data driven, so it’s essential that systems and tools can work together

<p style="text-align: center;"><span><strong><span>The SOC of the future must be data driven, so it’s essential that systems and tools can work together</span></strong></span></p>

The SOC of the future must be data driven, so it’s essential that systems and tools can work together

As we turn the page on another year and read the columns on “what’s in/what’s out”, one of the trends in cybersecurity that is definitely “in” is Security Operations Center (SOC) modernization. Evidence continues to mount that it isn’t a matter of if, but when and how an organization will be attacked. With that, we see SOCs narrowing the focus of their mission to become detection and response organizations, and they need certain building blocks in place to prepare their SOC for the future.

Previously, I talked about data as the first building block for SOC modernization. Data is the lifeblood of security because it provides context from a wide range of internal and external sources, including systems, threats, vulnerabilities, identities and more. When security is data-driven, teams have the context to focus on relevant, high-priority issues, make the best decisions and take the right action. Data-driven security also provides a continuous feedback loop that enables teams to capture and use data to improve future analysis. 

Building on top of data, the second building block is an open integration architecture to ensure systems and tools can work together and that data flows throughout the infrastructure. Jon Oltsik of ESG reinforced the need for such an architecture when he tweeted: “In 2022, the industry will recognize that XDR must be an open and flexible architecture.” As the SOC becomes a detection and response organization, extended detection and response (XDR) becomes a key capability and can only be effectively executed when based on an open architectural approach. Openness is important for several reasons:

There are no clean slates. The data that teams need for analysis comes from multiple, disparate technologies, threat feeds and other third-party sources. A recent study finds that, on average, organizations have more than 45 different security tools that for the most part don’t talk to one another. This happens naturally over time with different teams, budgets and departments making independent decisions. They may rely on a few “large vendors” to handle the bulk of their security tasks, but usually they also use best-of-breed vendors for controls the larger vendors do not have or do not excel in. There’s also the issue of dealing with on-premises tools that teams still need to use, at least in the short term before transitioning fully to the cloud. And some organizations have tools that require in-house integration (think classified systems used by a federal agency), which means they need APIs so they can write their own integrations. An open integration architecture will address all these scenarios: working with what security teams have today, enabling integration with proprietary tools, and supporting new vendors and tools that emerge as use cases and threats evolve.  

Mergers and acquisitions (M&A) happen. Many organizations grow through M&A and rather than unifying their security technology to conform to the parent organization, they maintain separate systems in the near term at least. Organizations may also permit business units a certain amount of autonomy to deploy tools they need to support their unique requirements. Integration must be broad to cover any tool the enterprise has from anywhere.

New use cases require collaboration. The SOC of the future must be able to address normal operations and additional use cases, including threat detection and monitoring, investigation, incident response and hunting. Support for these use cases requires teams and tools working together quickly and efficiently. The data, teams and tools to support these use cases are spread throughout the typical organization. An open architecture with bi-directional integration enables teams to bring data and tools together for analysis and decision making into a common work surface. 

Ultimately, it’s about taking the right actions faster. Comprehensive response requires looking beyond one file or system to find all related events and data across the organization. Connecting the dots and contextualizing with additional intelligence requires deep integration across tools so teams can fully understand how to remediate and respond to the incident. Bi-directional integration enables data to flow in as well as out, sending associated policies and commands back to the right tools across the defensive grid immediately and automatically to accelerate response.  

Advertisement. Scroll to continue reading.

Communication back allows for continuous improvement. Coming full circle, bi-directional integration supports the ability to capture and store data from the response for learning and improvement over time. The ability for teams to share comments and observations in a common work surface, together with the inbound flow of new data as it becomes available, helps the SOC continue to strengthen detection and response as threats evolve.

The SOC of the future must be data driven, so it’s essential that systems and tools can work together. An open integration architecture provides the greatest access to data from technologies, threat feeds and other third-party sources, and the ability to drive action back to those technologies once a decision is made. But there’s one more building block modern SOCs need to be efficient and effective – the ability to balance automation with human involvement. We’ll discuss that next time.

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version