Cybersecurity at a crossroads: Time to shift to an architectural approach

According to ESG research, 45% of cybersecurity professionals believe that security operations are more difficult today than they were two years ago, while another 11% claim that things are about the same.

When asked why they felt this way, security pros pointed to a growing attack surface, a continuously evolving threat landscape, the volume and complexity of security alerts, and the collection and analysis of increasing volumes of data.

It is my firm belief that every one of these issues will grow substantially more complex over the next two to three years. Between cloud-native applications, partner ecosystems, and new device types, attack surface growth and changes will be difficult to keep up with, leading to an explosion in vulnerable assets.

Generative AI will help security teams with basic hygiene, leading adversaries to get more creative with exploits across growing attack paths. Security alert volume will skyrocket, making it difficult to piece together random events with seemingly no connections.

Finally, data volumes will vastly increase as security teams are asked to closely monitor cyber-risk data, identity data, social media, physical, and digital security signals, and incorporate all forms of digital risk protection (DRP) into their security operations oversight.

Cybersecurity market conditions are shifting fast

Oh, and it’s also worth stating that the security operations data above isn’t new or unique. Indeed, anyone who has conducted research like this over the past 10 years would come to similar conclusions.

During this timeframe, security technology vendors have responded to these issues with numerous technology solutions like next-generation SIEM systems, SOAR, XDR, and UEBA, yet these issues continue, resulting in shifting market dynamics and upheaval.

Just recently, Cisco acquired Splunk, Exabeam merged with LogRhythm, and IBM and Palo Alto Networks partnered to migrate QRadar cloud customers to XSIAM. Other vendors are in deep trouble, looking for an exit, and likely not far from the end of the line.

All of this foretells massive changes in security operations. To be clear, I’m not talking about incremental product tweaks or functionality gaps addressed by generative AI. I’m talking about fundamental architectural changes.

Big organizations must shift to an architectural security approach

Over the next few years, large organizations must transition from a product-centric to an architectural approach to security operations. To be clear, no vendor will deliver the whole enchilada. Therefore, CISOs must focus their teams on architectural components, such as those listed below:

Cloud scale

Unless you are Amazon, Google, or Microsoft, you won’t have the compute, network, or storage capacity to address security operations requirements. This means that organizations with on-premises systems must plan for cloud migrations as soon as possible. Note that I’m not talking about “lift and shift.’ Rather security operations systems must be built on top of modern cloud-native technologies like containers, serverless functions, infrastructure as code, and APIs, capable of scaling capacity exponentially over the next few years.

All things data

There’s lots to unpack here. First, the notion of moving all the data to one repository is completely outdated due to data volume and constant change. Future security operations must adhere to a federated data model.

Of course, some data will still need to be streamed, moved, and processed on the fly, leading to a requirement for improved data pipelining technologies. Think CRIBL for cybersecurity.

Finally, data standards like the open cybersecurity framework (OCSF) and STIX/TAXII will become even more important. Large organizations should insist that their vendors observe these standards as they emerge.

Note that I do see large organizations standardizing with data lake technologies like Databricks and Snowflake, and I also see a role here for things like the Amazon security lake. While this makes sense today, we’ll see new data management platforms in the future with compelling security use cases. Enterprise security operations architectures must have the flexibility to migrate or integrate data in the future.

Connectivity

This one is fairly simple — everything has to connect with everything else through APIs, transport protocols, and industry standards. In the case of APIs, they must be well documented and built for flexible use cases, not vendor-based black boxes.

I’d really like to see the industry come together with some standards here. For example, a standard EDR API for accessing endpoint data regardless of the EDR vendor. On that note, CISOs should push back on closed vendor ecosystems or one-off vendor-to-vendor integration. This type of historical industry lock-in is at odds with current and future dynamic security operations systems.

Core automation

Rather than bolting automation into tools after the fact, everything that can be automated should be automated. This is especially true of basic actions like looking up IP addresses, associating assets with owners, enriching alerts with threat intelligence, and checking file samples against VirusTotal.

Beyond these, security operations systems must be instrumented with flexible workflows and runbooks that can be used for all types of Level 1 through 3 analyst activities that can be easily customized or integrated with IT service management tools or CI/CD pipelines. Again, a common language standard for workflows/runbooks would be especially useful here for sharing across the architecture.  

Engineering

As many others have suggested, today’s security analyst structure is fundamentally broken. We don’t need eyes on glass, we need hands on keyboards. As part of this, continuous detection engineering/detections as code are critically important. This process should be tightly coupled to ongoing red teaming with the goal of establishing a threat-informed defense guided by things like the MITRE ATT&CK framework.

Layers of analytics

The thought that we can bring all security signals together and figure out what’s happening across a hybrid IT infrastructure is the wrong approach. We should address problems locally as much as possible through technologies like CASB, EDR, ITDR, NDR, and SSE as much as possible, while sharing data across the architecture. I also believe that we’ll need some type of Palantir-like link analysis technology layer for looking across vast, distributed, and seemingly unrelated data sets for particularly gnarly cyber-attack investigations.

It is difficult to summarize here as this is a big topic I’ve been researching for years. But I do have a few closing thoughts.

Many or most organizations won’t have the resources to build and maintain this type of security operations architecture, turning to MSSPs as an alternative. Okay, but remember that MSSPs will be on the hook to build their own architectures with the scale, intelligence, and automation capabilities to service a community of customers.

Once again, not all MSSPs will get this right. CISOs must choose carefully here.

Generative AI will be a mixed blessing

What about generative AI? In my humble opinion, it’s a mixed blessing. It will help with analyst knowledge and efficiency, but its benefits will be obvious to adversaries who will engineer around it.

I also believe that gen AI will come into enterprise through the back door, on top of existing products. This will lead to balkanization. The gen AI engine on top of EDR will know a lot about endpoint security, but won’t have visibility into what’s happening on routers, appliances, or other types of assets.

Get ready to hear the term, “collective defense” much more often. This may be where GAI can be very helpful by monitoring threats and responses across multiple organizations and then sharing best practices throughout their customer bases.

This is one area where MSSPs will have a distinct advantage. My hope is that they will be willing to share what they learn from their installed base across the entire cybersecurity community.

Look for security operations consolidation across disparate communities. Several US states are already pursuing “all-of-state” efforts, offering security operations services to under-resourced local governments, state agencies, universities, hospitals, etc.

The OmniSOC, a shared security operations center (SOC) for higher education and research, is a good example as well. I expect more of this type of cooperation/collaboration moving forward.

Finally, I see a new category of companies I call SIEM (or more accurately security operations) supplementals. This includes detection engineering tools/services, threat intelligence aggregation firms, advanced analytics systems, and the like.