SIEM, AI, and the Mythical ‘Solved SOC’

I’ve spent 25 years in information security. Long enough to see SIEM rise from the old audit requirements of “aggregated, network based logging”, with the birth of the “correlation” buzzword, and with its fall seen the rise of the “normalisaton” buzzword. I’ve built SOCs, tuned them, fought alert noise, and tried to control the spiralling cost that comes with doing security badly at scale.

And through all of that, one principle has never changed.

Know your environment. Know your security strategy. Understand your threat model. Build a picture of normal. Alert on what is truly abnormal—and truly risky.

The Sacred Cows of the SOC

If you follow the above-described approach, something interesting happens. A number of “must-haves” in modern SOC conversations start to look… negotiable:

  • SOAR is not always mandatory
  • Threat hunting is cool
  • More analysts does not equal better outcomes
  • Expensive threat intelligence feeds are mandatory

These are not heretical views—they’re just uncomfortable ones. Because they challenge a model where complexity and cost are often mistaken for maturity.

In reality, a well-understood environment with sharply defined risk tolerance will outperform a bloated SOC every time.

Enter AI: The New Buzzword Cycle

Now we have a new layer: AI, and if you read the current wave of content, you’ll notice a pattern. The most confident “AI success stories” tend to avoid talking about SIEM at all!

Instead, we get familiar phrases:

  • “Enriching data feeds”
  • “Augmenting analysts”

Let’s pause on one of those.

“Enrichment” of Data

“Enrichment” has quietly joined the long list of SIEM buzzwords. But what does it actually mean? Better data? According to whom? Data quality is not universal. It is entirely dependent on your environment, your systems, and your risks. An event that is critical in one organisation is meaningless in another.

You can train an AI model to process data. But can you teach it what matters in a specific, messy, evolving environment? That’s not just a data problem. That’s a context problem.

The Analyst Productivity Argument

Another popular claim:

“AI won’t replace analysts, but it will make them more productive.”

It sounds reasonable. It’s also mostly unproven in the SIEM context. Take “noise reduction”—a classic SOC problem. Who defines noise?

That decision requires:

  • Knowledge of the environment
  • Understanding of business risk
  • Familiarity with attacker behaviour

That’s not magic. But it does require experience and judgement. Can an AI learn this? Possibly, in constrained scenarios. Can it generalise this across real-world environments without introducing blind spots? That’s much harder to believe.

The Missing Layer: Technical Depth

What’s consistently absent from “AI transformed my SOC” narratives is technical depth.

Where are the discussions about?:

  • Operating systems
  • Network behaviour
  • Application logic

Even in fully SaaS environments, you are still dealing with operating systems, identity layers, protocols, and execution paths.

Can AI Fix a Broken SOC?

AI can easily flog a dead horse that is a cost-sinkhole SOC (plenty of those around on all continents – it needs a collective noun), but can it get a SOC to rise phoenix-like from the ashes of its dark history? That is as close to a ‘no’ as you’re ever going to get without it actually being a ‘no’.

I remain open minded, but i want to see technically grounded discussions in order to change that position. The SIEM community has long conversations for the long nights of winter e.g. “do i want to use sysmon if i have a CIS benchmark compliant Audit Policy service?”. This is the level that the conversation has to be, at, without perhaps the same volume.

AI can absolutely make those SOCs more efficient at being inefficient. can it transform a fundamentally flawed SOC into an effective one? That’s very close to a “no.” Not because AI is weak—but because the problem is structural.

If you don’t understand your environment, your risk, and your attack surface, no amount of automation will fix that.

The Hard Problem: Teaching an Attack Mindset

At its core, effective detection relies on an attack mindset.

That comes from:

  • Understanding how systems really behave
  • Knowing how they break
  • Seeing how attackers chain small weaknesses into real impact

We’ve seen early attempts to automate parts of this—especially in areas like network path analysis and automated penetration testing.

But anyone who has participated in real-world red teaming or unrestricted penetration testing knows the truth: This is not a linear process. It involves intuition, creativity, and adapting to incomplete information. Teaching that to an AI agent is not impossible—but it is a very hard problem.

Final Thought

I’m not anti-AI. Far from it. But I am sceptical of narratives that skip over the hard parts.

Can AI replace the fundamentals?:

  • Understanding your environment
  • Defining risk properly
  • Thinking like an attacker

Until AI can operate meaningfully at that level, it remains a tool, of sorts, hopefullly not a very expensive tool.

Exorcising Dark Reading’s Cloud Demons

Dark Reading recently covered what it says are Cloud “blind spots”. Really, there is some considerable FUD here. Is there really anything unique to cloud with the issues called out?

I’m not pro or anti-cloud. It is “just another organisation’s computer platform” as they say, and whereas this phrase was coined as a warning about cloud, it also serves as a reminder that the differences with on-premise aren’t as much as many would have you believe. In some areas cloud makes things easier and its a chance to go greed field and fix the architecture. Some fairly new concepts such as “immutable architecture” will change security architecture radically but there is nothing carved in stone which says this can only be implemented in cloud. In case it needed calling out – you can implement microservices in your data centre if microservices are what does it for you!

Migrating to cloud – there’s a lot to talk about regards infosec, and i can’t make an attempt at doing that comprehensively here. But some points to make based on what seems to be popular misconceptions:

  • Remember you will never get access to the Cloud Service Provider’s (CSP) hypervisors. Your hardware is in their hands. Check your SLA’s and contract terms.
  • SaaS – it many cases it can be bad to hand over your operating systems to CSPs, and not just from a security perspective. In the case of on-premise, it was deemed a good business choice to have skilled staff to administer complex resources that present many configuration options that can be used and abused for fun and profit. So why does moving to cloud change that?
  • Saas and SIEM/VA: Remember this now means you lose most of your Vulnerability Assessment coverage. And SaaS and SIEM is getting more popular. Due to the critical nature of a SIEM manager, with trust relationships across the board, personally i want access to the OS of such a critical device, but that’s just me.

So picking out the areas covered briefly….

  • Multi-cloud purchasing – “The problem for security professionals is that security models and controls vary widely across providers” – if it takes a few weeks to switch from on-premise to Cloud, then for example, from Azure to Google, or AWS, chances are they were struggling with on-premise. Sorry but there’s no “ignorance” here. A machine is now a VM but it still speaks TCP/IP, and a firewall is now not something in the basement…ok i’ll leave it there.
  • Hybrid Architecture – tracking assets is easier in cloud than it is on-premise. If they find it hard to track assets in cloud, they certainly find it hard on-premise. Same for “monitoring activity”.
  • Likewise with Cloud Misconfiguration – they are also finding it hard on-premise if they struggle with Cloud.
  • Business Managed IT – not a cloud specific problem.
  • Containers – “new platforms like Kubernetes are introducing new classes of misconfigurations and vulnerabilities to cloud environments faster than security teams can even wrap their arms around how container technology works. ” – WHAT!!? So does the world hold back on these devops initiatives while infosec plays catch up? There is “devsecops” which is supposed to be the area of security of security which is specialised in devops. If they also struggle, then what does it say about security? I have to say that on a recent banking project, most of the security team would certainly not know what Docker is. This is not a problem with Cloud, its a problem with security professionals coming into the field with the wrong background.
  • Dark Data – now you’re just taking the proverbial.
  • Forensics and Threat-Hunting Telemetry – show yourself Satan! Don’t lurk in the shadows! Ignore the fancy title – this is about logging. “Not only do organizations struggle to get the right information fed from all of their different cloud resources” – This is a logging problem, not a cloud problem. Even SaaS SIEM solutions do not present customers with issues getting hold of log data.

What happened Dark Reading? You used to be good. Why does’t thou vex us so? Cloud is just someone else’s computer, and just someone else’s network – there are a few unique challenges with cloud migrations, but none of those are mentioned here.

Clouds and Vulnerability Management

In the world of Clouds and Vulnerability Management, based on observations, it seems like a critical issue has slipped under the radar: if you’re running with PaaS and SaaS VMs, you cannot deliver anything close to a respectable level of vulnerability management with these platforms. This is because to do effective vulnerability management, the first part of that process – the vulnerability assessment – needs to be performed with administrative access (over SSH/SMB), and with PaaS and SaaS, you do not, as a customer, have such access (this is part of your agreement with the cloud provider). The rest of this article explains this issue in more detail.

The main reason for the clouding (sorry) of this issue, is what is still, after 20+ years, a fairly widespread lack of awareness of the ineffectiveness of unauthenticated vulnerability scanning. More and more security managers are becoming aware that credentialed scans are the only way to go. However, with a lack of objective survey data available, I can only draw on my own experiences. See – i’m one of those disgraceful contracting/consultant types, been doing security for almost 20 years, and been intimate with a good number of large organisations, and with each year that passes I can say that more organisations are waking up to the limitations of unauthenticated scanning. But there are also still lots more who don’t clearly see the limitations of unauthenticated scanning.

The original Nessus from the late 90s, now with Tenable, is a great product in terms of doing what it was intended to do. But false negatives were never a concern in with the design of Nessus. OpenVAS is still open source and available and it is also a great tool from the point of view of doing what it was intended to do. But if these tools are your sole source of vulnerability data, you are effectively running blind.

By the way Tenable do offer a product that covers credentialed scans for enterprises, but i have not had any hands-on experience with this tool. I do have hands on experience with the other market leaders’ products. By in large they all fall some way short but that’s a subject for another day.

Unauthenticated scanners all do the same thing:

  • port scan to find open ports
  • grab service banners – this is the equivalent of nmap -sV, and in fact as most of these tools use nmap libraries, is it _exactly_ that
  • lets say our tool finds Apache HTTP 14.x, it looks in its database of public disclosed vulnerability with that version of Apache, and spews out everything it finds. The tools generally do little in the way of actually probing with HTTP Methods for example, and they certainly were not designed to try, for example, a buffer overflow exploit attempt. They report lots of ‘noise’ in the way of false positives, but false negatives are the real concern.

So really the tools are doing a port scan, and then telling you you’re running old warez. Conficker is still very widespread and is the ultimate player in the ‘Pee’ arena (the ‘Pee’ in APT). An unauthenticated scanner doesn’t have enough visibility ‘under the hood’ to tell you if you are going to be the next Conficker victim, or the next ransomware victim. Some of the Linux vulnerabilities reported in the past few years – e.g. Heartbleed, Ghost, DirtyCOW – very few can be detected with an unauthenticated scanner, and none of these 3 examples can be detected with an unauthenticated scanner.

Credentialed scanning really is the only way to go. Credentialed based scanners are configured with root/administrative access to targets and are therefore in a position to ‘see’ everything.

The Connection With PaaS and SaaS

So how does this all relate to Cloud? Well, there two of the three cloud types where a lack of access to the operating system command shell becomes a problem – and from this description its fairly clear these are PaaS and SaaS.

 There are two common delusions abound in this area:

  • [Cloud maker] handles platform configuration and therefore vulnerability for me, so that’s ok, no need to worry:
    • Cloud makers like AWS and Azure will deal with patches, but concerns in security are much wider and operating systems are big and complex. No patches exist for 0days, and in space, nobody can hear you scream.
    • Many vulnerabilities arise from OS configuration aspects that cannot be removed with a patch – e.g. Conficker was mentioned above: some Conficker versions (yes its managed very professionally) use ‘at’ job scheduling to remain present even after MS08-067 is patched. If for example you use Azure, Microsoft manage your PaaS and SaaS but they don’t know if you want to use ‘at’ or not. Its safer for them to assume that you do want to use it, so they leave it enabled (when you sign up for PaaS or SaaS you are removed from the decision making here). Same applies to many other local services and file system permissions that are very popular with the dark side.
  • ‘Unauthenticated scanning gets me some of the way, its good enough’ – how much of the way does it get you? Less than half way? its more like 5% really. Remember its little more than a port scan, and you shouldn’t need a scanner to tell you you’re running old software. Certainly for critical cloud VMs, this is a problem.

With PaaS and SaaS, you are handing over the management of large and complex operating systems to cloud providers, who are perfectly justified, and also in many cases perfectly wise, in leaving open large security holes in your platforms, and as part of your agreement with them, there’s not a thing you can do about it (other than switch to IaaS or on-premise).