Smarter Threat Detection Q&A (21 Aug 2026)
The following questions were raised during the Smarter Threat Detection: Using ML Anomaly Detection with SIEM in StackOps webinar held on 21 August 2026.
SIEM and anomaly detection
ML anomaly detection does not reduce the number of SIEM alerts by itself. Instead, it provides an additional detection layer that identifies unusual behaviour which may not be covered by existing static rules.
The value is in using ML to surface high-risk or unexpected behaviour and provide extra context for investigation, rather than replacing or reducing existing SIEM alerts. Over time, ML findings can also help analysts identify where existing rules can be tuned or improved.
No. StackOps ML and SIEM are not an approved alternative for ABLR.
While, Elastic ML and SIEM can help detect anomalies, correlate events, and support security investigations. However, they are not currently an approved direct replacement for ABLR.
Suitability as an alternative depends on the specific use case and applicable security, governance, and compliance requirements. Agencies must engage their Security team for the necessary assessment and approval before considering it as an alternative for ABLR (if any).
Pricing and sizing
For Elastic ML anomaly detection, the cost is mainly based on the compute resources used to run the ML jobs rather than a charge for each anomaly generated.
For Elastic Cloud Hosted, ML jobs run on dedicated ML capacity, so additional ML nodes or resources may increase the deployment cost. The amount required depends on factors such as the number of concurrent jobs, data volume, model complexity, and memory usage.
There is no fixed cost per anomaly or alert. The actual cost depends mainly on the ML workload being run and the resources it consumes.
For pricing details, refer to Elastic Cloud pricing.
ML nodes are required for capabilities that perform machine learning workloads, such as generating embeddings for unstructured content used by Knowledge Base capabilities. ML nodes are not enabled by default.
As a starting point, a minimum ML node size of 2 GB x 2 zones is recommended. The appropriate node size should also take into account factors such as the model size, workload complexity, data volume, and the number of entities being processed.
As a general reference:
| Memory | Suitable for |
|---|---|
| 10 MB–128 MB | Simple single-metric jobs with low cardinality and no split fields. |
| A few hundred MB | Multi-metric jobs with moderate split cardinality (for example, fewer than 1,000 entities). |
Actual sizing requirements may vary depending on the specific use case and workload. Agencies are encouraged to monitor resource utilisation and adjust ML node capacity as needed.
Serverless
StackOps is currently running on Elastic Cloud-hosted deployments (SaaS), with Serverless as the next step in the product evolution.
The transition to Serverless aims to introduce capabilities such as Agent Builder, Workflows, Model Context Protocol (MCP) support, and enhanced automation tools to StackOps.
For updates, stay tuned to the StackOps Product Roadmap.
Compliance and governance
Yes, a waiver is required for agencies using StackOps or another ABLR-equivalent tool instead of ABLR for privileged activity review of their own applications.
Agencies may seek a waiver if the solution meets the applicable IM8 requirements. For specific use cases or waiver requirements, consult the IM8 Secretariat and relevant Governance teams.
For further details, refer to the ABLR and CAM Circular Minutes FAQ on the IM Portal - Circular Minutes 3/2021.
