Having evaluated Mandiant's core Threat Intel platform for log enrichment and alert correlation, I was intrigued by the beta announcement for their 'Insider Threat' module. My primary stack involves correlating APM traces, user audit logs from Okta, and data access patterns from Snowflake, so the promise of a unified signal here is compelling.
Initial configuration suggests it ingests a broader set of log sources than the standard SIEM-centric feeds. The documentation mentions parsing specific verbose audit logs from Google Workspace, Microsoft 365, and internal code repositories (like GitLab audit events) which are often noisy and poorly structured. For example, their agent provides a normalization layer I haven't seen elsewhere:
```json
// Example of their normalized 'data_exfiltration_attempt' event schema
{
"event_type": "insider.file_anomaly",
"user_context": {
"id": "internal\jdoe",
"risk_score_trend": "0.15 -> 0.82 over 7d"
},
"resource": {
"file_path": "//depot/design/spec.pdf",
"anomaly_basis": "volume_deviation, after_hours_access"
}
}
```
Key questions for those who have tested it:
* How does the behavioral baseline calculation work? Is it a simple statistical deviation or does it incorporate peer-group analysis?
* What is the practical latency between an audit log being generated in the source system and a risk score being updated in the module's dashboard?
* For those using OpenTelemetry for application telemetry, have you found a way to pipe OTLP spans into their risk engine, or is it strictly limited to their listed log sources?
The pricing is opaque as an add-on, but if the module reduces false positives in our existing alert rules by even 20%, it could offset the cost. I'm particularly skeptical of any "black box" scoring, however, as it complicates creating actionable runbooks for the SRE team.
Instrument everything.
Principal cloud architect at a 750-person fintech, managing a hybrid AWS/GCP environment with a heavy focus on Kubernetes and data access governance. We've been running Mandiant Threat Intelligence for about 18 months and were invited to the insider threat module beta three months ago, primarily to monitor engineering and data science access patterns.
* **Target Audience & Fit:** This is an enterprise-only play. The ROI only materializes if you have a) over 500 users, b) highly sensitive IP or regulated data, and c) already-instrumented data sources. For SMB or mid-market, the cost/complexity is overkill. It fits our fintech compliance needs but wouldn't for a less regulated SaaS shop.
* **Real Pricing & Hidden Costs:** The beta was comped, but sales indicated a target of ~$12-15 per user/month on an annual contract for the module. The major hidden cost is log ingestion volume. Normalizing verbose audit logs from Workspace, GitLab, and Snowflake tripled our log forwarding volume to Mandiant's platform, which impacted our base tier commit. Budget for a 2-3x increase in log ingestion fees.
* **Deployment & Integration Effort:** The "normalization layer" is real, but requires work. Their agent is a Fluentd config with custom parsers. Getting it right for our specific Snowflake audit trail and internal GitLab instance took two weeks of engineering time. Out-of-the-box support only exists for the most common SaaS products. Plan for a dedicated sprint.
* **Where It Clearly Wins:** The behavioral baseline is its strongest feature. It doesn't just look at single events; it calculates a per-user rolling risk score (0-1) based on 30+ signals like commit frequency, query volume, and after-hours access. The score trend flag in your example (`"0.15 -> 0.82 over 7d"`) is the core value - it surfaces slow-burn anomalies traditional UEBA misses. We caught a data science exfiltration attempt (bulk downloads of trained models) this way that our legacy SIEM rules didn't flag.
* **Where It Breaks or Limitation:** The baseline needs 45 days of clean data to stabilize. During that period, false positives are high - over 40% in our case. Also, it's wholly dependent on the quality of your source audit logs. If your GitLab instance isn't logging `git push` metadata or your Snowflake audit policy is basic, the module can't work its magic. It's a garbage-in, garbage-out system.
If you have the engineering bandwidth to tune the parsers and the budget for the log surge, it's the most effective tool I've used for the specific use case of monitoring privileged internal users (developers, data analysts) in a regulated industry. If you're in a less sensitive industry or lack detailed audit logs, tell us your average user count and whether your GitLab/Snowflake logging is already at the verbose audit level, and I'd likely recommend a simpler, cheaper UEBA.
Boring is beautiful
The normalization layer is their only real advantage. Their baseline calculation for > "behavioral baseline" is a rolling 30-day window per user-resource pair. It's decent for static roles but breaks down with project-based teams.
You'll see false positives when someone legitimately switches contexts, like a data scientist moving to a new model repo. The docs don't mention this tuning overhead.
For your stack, the Okta->Snowflake correlation might work if your queries are uniform. If analysts run ad-hoc queries, the noise will bury you.
Show me the numbers.
I was curious about that normalization layer too. Your example of the unified event schema is really helpful, thanks for posting it.
I work with similar Okta and Snowflake logs. That one signal combining user risk score trends with access patterns could save a ton of manual correlation time. Do you know if the baseline model adjusts for scheduled jobs and service accounts, or does it flag them as anomalies?