I've been evaluating Mandiant's threat intelligence for a potential integration into our security data warehouse (we're a Snowflake shop, so pulling in structured threat data is key). While the content depth is impressive, I keep hitting a conceptual snag.
Their taxonomy and terminology feel like they're operating on a different plane compared to MITRE ATT&CK, which our SOC and detection engineering team uses as the common language. For example, mapping a Mandiant-reported activity to a specific ATT&CK technique often feels like an interpretive exercise, not a direct lookup. It adds an extra transformation step in our ETL pipeline that feels... messy.
Has anyone else built a bridge between these two systems? I'm specifically wrestling with:
* The granularity mismatch. Is a Mandiant "malware family" best represented as a tool, a set of techniques, or its own custom dimension in our intel fact table?
* Maintaining historical consistency when Mandiant's own classifications evolve (which they should), while keeping our ATT&CK mappings stable.
* Whether it's better to force-fit Mandiant data into the ATT&CK model early in the pipeline, or store it natively and map only at the analytics/BI layer.
I'm curious if others have designed data models or dbt transformations to harmonize these sources. The goal is clean, joinable tables for analysis without losing the nuance of the original intel.
I'm a security analyst at a mid-sized e-commerce company, and we've been running both Mandiant Advantage intelligence and a custom ATT&CK platform in production for about a year.
Here's the breakdown from trying to merge them:
**Mapping effort**: We dedicated a part-time analyst for 6 weeks just to build the initial crosswalk. The main friction is Mandiant's focus on actor-centric reporting versus ATT&CK's technique-centric model. It's not 1:1.
**Schema evolution**: Mandiant's taxonomy updates quarterly. We've had to version our mapping tables and keep historical snapshots, which adds about 20% overhead to our pipeline maintenance.
**Pipeline design**: We settled on storing the native Mandiant JSON in Snowflake, then creating a separate view that applies our mapping logic to produce ATT&CK technique IDs. Forcing early transformation lost too much granular context.
**Cost of integration**: Beyond the license, factor in the engineering time. For us, it was roughly 4 person-months from initial POC to stable, automated ETL into our warehouse.
I'd actually recommend pulling in the Mandiant data natively first. Build your ATT&CK mapping as a separate, versioned layer. That works if your primary goal is enriching internal alerts with external intel. If your goal is purely to populate a standardized ATT&CK knowledge base, a different feed might be cleaner. Tell us more about the use case for the data warehouse - is it mostly for automated alert enrichment or for manual analyst research?