Most security operations centers are good at answering what happened. The logs are there, the alerts fire, the analyst investigates. That work is reactive, and for most organizations, it's where the capability stops.
The problem with stopping there is that a reactive posture leaves you behind. By the time you've answered "what happened," you've already lost time. The more interesting questions, why did it happen, what's likely to happen next, what should we do about it, require a different analytic posture entirely.
At SuriCon 2018 I walked through the analytics maturity model as it applies specifically to security operations, because the gap between where most teams are and where they could be is wide.
Descriptive analytics (what happened) is where everyone starts. It's dashboards, summaries, alert counts, all of which are necessary but not enough on their own. The next stage is diagnostic: not just that an event occurred, but why the pattern looks the way it does. That requires correlation and enough historical context to distinguish signal from noise.
Predictive analytics is where the ML conversation becomes substantive. You're no longer asking what has happened; you're asking what is likely to happen given the current state of observable data. For security, that means things like: given this sequence of authentication events, what's the probability this is a credential-stuffing campaign? Given this network flow profile, how similar is this host's behavior to known botnet patterns? Those aren't answerable by a signature. They require a model trained on historical examples.
The fourth stage, prescriptive, is where organizations want to be and where many stall out. Prescriptive analytics doesn't just predict; it recommends and, in some configurations, acts. That might mean automatically isolating a host that a model has flagged with high confidence, or triggering a specific remediation workflow based on the predicted incident type. Organizations that stall here usually aren't blocked by the technology. Prescriptive automation requires a level of model confidence and operational trust that takes time to build. You can't automate remediation if your model is wrong 20% of the time; the cost of false positives in automated action is too high.
The path from reactive to prescriptive runs through data quality and feedback loops. A model that fires alerts is only as useful as the signal you're feeding back when those alerts are correct or incorrect. Operationalizing ML in the SOC means building that feedback mechanism: tracking analyst dispositions, retraining on confirmed incidents, retiring features that stop being predictive. None of that happens on its own; it requires treating the ML pipeline as infrastructure, not a one-time project.
Suricata is a useful data source for this kind of work precisely because its output is rich. Network flow data, alert metadata, protocol anomalies: that's the feature set that behavioral models need. The talk covered how to move from raw Suricata events in Splunk through the stages of that maturity model, with specific attention to what automation is actually viable at each stage versus what requires more organizational groundwork first.
Download Slides
Watch Video
Presented at SuriCon 2018