‘Noise to signal’ isn’t just a tooling problem; it’s a charter problem.
Cyber resilience is broader than ransomware; therefore, the signals we care about are broader than security events, and the team that owns the SIEM might not be the team that owns the resilience and governance outcomes. Especially when you add identity, along with AI agents doing goofy stuff with no bad actor involved, the question of who needs the information and who acts on it gets a lot less obvious.
This week: the security, production, and protection layers, and why none of them have a complete answer yet.
video transcript
Everyone wants to talk about noise to signal when it comes to cyber resilience and AI governance, but everyone assumes that theirs is the aggregator of the noise and the discerner of signals.
Even if we only talked about cyber resilience, think about all the places where signals (and noise) come from. If you’re running a SIEM, then you’re probably aggregating from your firewalls and your detection tools; so, that’s part of it. Alternatively, we’ve got the backup-DR-cyber resilience tech stacks and most of them have the potential to discern, identify, or notify when bad actor behavior is observed. Some even talk to that SIEM we mentioned.
And if we were just talking about cyber security, that might be the end of the discussion. But if we add identity, is the SIEM still the right aggregator or discerner? Maybe … because that’s where all the other data is going in, except … not all signals or noise are going into a SIEM. In fact, not everyone has one (on-prem or as-a-service). And even when they do, the primary operators of a SIEM may not be the same folks who’re thinking holistically about other endeavors.
That’s just security and identity … now add AI. We’ve got this whole new category where agents are authorized by you, to act on your behalf, across all of your production workloads. Even if there was never a bad actor, no Bitcoin was ever demanded, and no exfiltration ever occurred … even if it was just AI doing goofy stuff: is that bubbled into a SIEM? Could it? Should it?
One of my first Forbes pieces talked about how we have to expand the definition of cyber resilience because too many people still treat ransomware as a synonym for cyber resilience. Cyber resilience is broader than ransomware; so, the signals we care about are broader than security events; therefore, the team that owns the SIEM might not be the team that owns the outcome or its accountability to the org.
So, where does that leave us?
Maybe the real question isn’t which console aggregates the signals, but which teams carry the charter to monitor and act. Here’s the challenge: there isn’t a clean product category for where that should happen. If the scenario doesn’t fit the security layer…
Is it the production layer? Dell‘s visibility extends from endpoint to server to storage to data protection; I’ve called that their cyber resilience superpower. But if you’re not a Dell shop, that end-to-end view is harder to get.
Or is it the protection layer? If you’re running an overarching solution like Cohesity, Rubrik, or Commvault, each has options that touch cyber, identity, and AI, but the average org runs 2.8 backup tools. 2.8 backup tools means 2.8 consoles; then add in production storage consoles, and the security consoles. Maybe you’re supplementing with Druva, for AI governance, or HYCU aiR, to correlate identity behaviors.
Bottom line: there isn’t an obvious center of gravity, from production to protection, and from cyber to AI. So, start with which teams carry the charter to act, then route the signals to them (not the other way around). Ask yourself:
If an AI agent quietly corrupts a system of record tonight, whether malicious or just errant,
who in the org is accountable, and what lenses are they most capable of acting through?
There’s no perfect answer, so leave your thoughts on the LinkedIn article.
Leave a Reply