Has anyone successfully used Anomali for non-security IT monitoring?

Having spent considerable time in the SOC, I’ve seen Anomali (now part of Accenture) deployed in its classic role: threat intelligence, IOC matching, and security event enrichment. However, the platform's core mechanics—aggregating, correlating, and scoring disparate data streams against known patterns—got me thinking about its applicability beyond the security fence.

In a recent multi-cloud migration engagement, we explored using Anomali's ThreatStream platform for a non-traditional purpose: monitoring cloud service configuration drift and compliance. The hypothesis was that misconfigured S3 buckets, overly permissive IAM roles, or deviations from hardened baselines could be treated as "Indicators of Compromise" against a "threat" model of operational failure or compliance violation.

We ingested normalized logs from AWS Config, Azure Policy, and our internal CMDB into ThreatStream. Instead of malware hashes or malicious IPs, we created "CTI" feeds of our own:

* **"IOCs" for operational risk:** JSON objects representing forbidden resource configurations (e.g., `{"resourceType": "aws:s3:bucket", "property": "publicAccessBlockConfiguration", "value": "DISABLED"}`).
* **Custom observation rules:** Scoring logic that assigned higher severity to deviations in production environments versus development.
* **Enrichment via internal APIs:** ThreatStream would enrich a finding about an EC2 instance by pulling owner and cost-center data from our internal inventory system.

The results were mixed, leading to a pragmatic assessment.

**Advantages:**
* **Correlation Power:** It successfully correlated a misconfigured database instance with a recent change ticket and an anomalous access pattern from the app tier, presenting a unified "incident" that spanned security, operations, and change management.
* **Flexible Data Model:** The ability to define custom observables and create bespoke "threat" feeds was powerful once set up.
* **Existing Integration Fabric:** Leveraging existing security data pipelines (Cribl, SIEM connectors) avoided building new ones.

**Significant Pitfalls:**
* **Cost Justification:** Licensing a premium threat intelligence platform for this is hard to justify unless you already own it and have spare capacity. The per-observable pricing model can become prohibitive.
* **Operational Mindset Gap:** The UI and terminology (Campaigns, Threat Actors, IOCs) are deeply security-oriented, causing confusion for SREs and ops teams. We had to build a custom facade.
* **Performance Overhead:** The complex correlation engine is overkill for simple, high-volume state-change notifications. It added latency where simple event-rules would have been instantaneous.

**Verdict:** It's technically feasible and demonstrated impressive correlation capabilities for cross-domain IT issues. However, I would only recommend this path if Anomali is already deeply embedded in your organization's security practice and you have the engineering bandwidth to create the necessary custom feeds, rules, and abstractions for ops teams. For greenfield non-security monitoring, dedicated ITOM or observability platforms (like Splunk ITSI, Dynatrace, or even robust open-source stacks) will provide a better ROI and a more intuitive experience for the teams who need to use them daily.

I'm curious if others have pushed Anomali into similar unconventional territories—perhaps for fraud detection, compliance auditing, or supply chain monitoring—and what your architectural compromises and lessons learned were.

- Mike