Why the AI SOC will struggle unless it is re-engineered | #hacking | #cybersecurity | #infosec | #comptia | #pentest | #ransomware

AI has been a real asset in the Security Operations Centre (SOC), assisting with triage, enrichment, summarisation, correlation and providing recommended courses of action. The technology has significantly helped with workloads, with a survey by the Cloud Security Alliance finding that AI assisted SOC analysts completed escalated investigations 45-61% faster and were 22-29% more accurate than their manual counterparts. 
But these findings fail to take into account that we’re only just entering the curve when it comes to AI-powered attacks. Evidence of the weaponisation of AI by nation state actors, for instance, has only recently been detected, with Anthropic revealing foreign scientists, hackers and security services have attempted to subvert its Claude model. Once threat actors begin to build their own models, we can expect the floodgates to open and for those attacks to increase in volume and tenacity.
The alert gap creates a chasm
At that tipping point, the AI SOC as we understand it will struggle to detect these attacks because today AI is applied too late in the process. It’s used to examine existing alerts so inherits the gaps in the detections that produced them. 
The chain of causation for an alert runs from a series of events that live upstream in raw telemetry, process trees, authentication flows, network sessions, package execution traces, cloud control-plane activity, endpoint state, and identity context. They’ve already happened and been filtered by a correlation rule before they get to the AI. Anything the AI then needs to know outside that rule’s original window has to be fetched, joined, tokenised, and reasoned after the fact. The alert is not useless but it is bounded and an AI investigation nearly always needs to break those bounds by querying backwards through indexes that were usually optimised for storage, search, and retention rather than reasoning.
However, when the AI queries backwards from the alert, the raw events needed may no longer be available at the resolution or in the form required. This could be in the form of an unaggregated process tree, the full DNS stream, a network session, an identity sequence before the suspicious action, a package execution path or the host state at the moment of execution. Typically these may have been summarised, normalised, downsampled, moved to a colder tier, or split across schemas so the AI does not see the full causal chain, only that part that survived the economics of storage and indexing, plus the alert itself.
Decision context is also key. When an event occurs on the stream, the system knows the process that spawned it, the identity which was authenticated, the session it came from, the patch level of the host, the parent-child execution path. Against that it will also know recent authentication patterns and the normal behaviour of the user/host/workload/service account. But once the event is written into an indexed store, that state has to be reconstructed so that logs must be joined, schemas normalised, time windows inferred and missing fields explained. The result is that the AI sees a sanitised version of the situation for the first time and that degrades its reasoning.
How the SOC can become AI first
But if events can be examined as they occur and behaviour connected across the estate it becomes possible for AI to connect the dots from the outset. Delivering this kind of capability will require the SOC to be completely re-engineered, with AI put up front to become part and parcel of the detection piece. This then enables the SOC use AI-assisted reasoning together with live/new threat intelligence from sovereign local AI models and expert human oversight to enable predictive modelling and millisecond detection of known and emerging indicators of compromise. 
A local model layer can handle environment-specific detection and analysis, a security intelligence layer then aggregates and correlates threat data at scale, and a frontier model layer is used for non-sensitive enrichment and broader analytical tasks. This structure ensures that sensitive data remains contained while still enabling advanced AI capability where appropriate, so that both compliance and performance requirements are met.
This type of AI SOC can utilise dedicated local large language models (LLMs) that are trained on the organisation’s specific environment, enabling accurate, context-aware reasoning that reflects the realities of the estate. Because inference occurs within this controlled infrastructure, organisations can retain full sovereignty over their security data and reduce their reliance on third party services. 
In addition, utilising AI for threat detection and response allows the SOC to check its own homework. Multiple AI models can be used in conjunction with one another to cross-check every investigation from different perspectives, building an auditable view of each alert. And an anti-hallucination layer can validate findings against threat intelligence and deterministic detection engines before results are passed to an analyst for final judgement. 
Built for purpose
Redesigning the AI SOC in this way so that ingestion, detection, and response are AI-first sees AI read every chapter as it happens, in order, with full context from the start. It reasons forward on the event stream, not backwards from an alert. And crucially this sees the SOC move from being reactive to a proactive and now predictive form of defence. That’s because context is continuously created as security data is generated, enabling early identification of threats and vulnerabilities before incidents occur. In fact, the ability to head off threats before they can manifest has led to this being dubbed a Zero Day SOC.
Yet, while AI has moved up the stack, the Security Incident and Event Management (SIEM) platform integral to any SOC remains the system of truth. It will continue to provide a deterministic, evidence-grade record of every event, reasoning forward with the attacker in real time, not backwards from an alert. AI runs in parallel, on top of it, and the final call always rests with a human on the loop.
It’s only by rethinking how we approach threat detection and incident response in this way that we can hope to combat and defend against weaponised AI. Simply tagging AI on at the end of an alert-driven process won’t achieve that – we need to make completely overhaul and redesign the SOC to fight fire with fire.
 
 

Join our LinkedIn group Information Security Community!

——————————————————-
Click Here For The Original Source.

Related