Security operations teams (SOC) are under fire as attacks grow more sophisticated while defenders face mounting operational strain. Notably, 63% of security alerts go unaddressed, exposing the widening gap between what SOC teams must manage and what they can realistically investigate. Over the past year, my conversations with customers have led me to conclude that the need for SOC automation is twofold.
Since the concept of a SOC came into existence, there has been the ever-present desire to automate workflow. Alert fatigue among analysts and the difficulty of hiring and retaining SOC talent have consistently been cited as key concerns.
And given that cybersecurity is an inherently adversarial contest, the rate at which attackers are improving their tradecraft and overall effectiveness has a material effect on the rate and sophistication of inbound attacks. Some automation on the defensive side is necessary simply to keep up with these increases.
The recent rapid improvements in attackers’ capabilities have created a sense of urgency to shift defensive automation into higher gear. And almost everyone seems to agree that the increase in automation will be assisted by AI.
Rapid Evolution or Revolution?
The existing SOC pipeline and stations were built around the model of a human-run assembly line. While we may have improved each of the stations in that assembly line over the last decade or two, the assembly line design is still firmly centered on maintaining complete human control over every station.
The problem with keeping humans in every decision loop and offloading all the grunt work to an AI agent quickly becomes evident. The analyst is presented with one case report after another (the vast majority of which are benign true positives or false positives) and is expected to make the perfect decision by swiping left or right, all while not zoning out.
The goal should be to reduce the number of decisions analysts need to make in the first place. Investing in AI investigative agents can do much of the tier 1 analyst dog work while making tier 2 analysts far more efficient. The goal is to increase speed and to add nuance to the analytics. If the organization can handle more tickets and investigations by automating more of the analyst work, they can even let more signals into the SOC pipeline and hopefully gain coverage in areas where the presence of noise makes pursuit of low-and-slow attacks challenging.
The Principles Upon Which to Construct a Revolution
It’s natural to want to keep humans in the loop for the small number of response actions that the system decides should be taken. However, given the increase in the speed of attacks, eventually most of these response actions (within guardrails prescribed by the system’s human overseers) should be taken without requiring human approval.
The same shift should happen earlier in the security pipeline. A detection engineering process that decides whether an individual signal is even worthy of investigation is a broken paradigm. Every signal available in the environment should be made available to the system. Choosing to begin investigations only once a reasonably noise-free signal is triggered inevitably misses attacks where multiple weak signals would have revealed malicious activity much earlier.
Rather than evaluating alerts in isolation, the system should reason over chains of signals that represent attack progression. Signal chains provide a much clearer picture of attacker intent and make it possible to extract value from noisy-but-important signals.
Since early-stage signals create the most opportunity to prevent an attack, the system should intentionally spend more of its noise budget on them than on indicators that arrive only after significant attacker progress, such as exfiltration.
The SOC is an economic system
It’s easy to assert that since the system will not depend on scarce human capital, every signal should be investigated to the maximum degree possible. While it’s easy to internalize that such an approach might run up a large AI inference bill, it would also render systems needed to carry out the investigation (SIEM, EDR, NDR, etc.) unusable by flooding them with progressively less valuable requests.
The system should have a budget for each resource it needs and should seek to operate within that budget. Over time, the system will learn to predict whether a given line of inquiry is important enough to warrant spending some of its budget on. It will be able to suggest increases to one or more of its budgets that would yield more accurate and more timely outcomes.
SOCs are about risk arbitrage rather than binary decisions
SOC response is rarely a simple decision between benign and malicious, but really an exercise in risk calculus. Over time, the system must become proficient at this risk arbitrage by weighing how likely a signal is to be real, whether there’s time to wait for additional evidence or the distance to boom is too short, and the collateral damage associated with each available response before deciding whether to act or wait.
It will not be easy to build such a SOC but building one consistent with these principles provides a reasonably resilient architecture for the uncertain future ahead.
____
About Oliver Tavakoli
Oliver Tavakoli is Chief Technology Officer at Vectra AI. He sets the technical strategy for the company. Oliver has overseen the adoption of technology in cybersecurity for over 2 decades, the last thirteen of which have been at Vectra AI. Prior to Vectra AI, Oliver was the CTO for the security business of Juniper Networks. He joined Juniper as a result of its acquisition of Funk Software, where he was the CTO.
Join our LinkedIn group Information Security Community!
