Just saw the new "adversary profile" reports in the portal. My initial analysis: looks like expensive fluff.
These are long, narrative documents. My team doesn't have time to read 20-page PDFs for actionable intel. We need IOCs, TTPs mapped to MITRE ATT&CK, and specific detection logic we can deploy. This feels like content marketing disguised as intelligence.
* **No clear ROI:** Does this narrative help me block an attack faster? Unclear.
* **Operational cost:** Analyst time is a resource. Spending hours reading vs. automating with ingested data has a real cost.
* **Where's the data?** Give me structured JSON/STIX output I can feed into our SOAR. Not a PDF.
If I'm paying for premium intel, I need machine-consumable data. Show me the concrete, technical artifacts, not a story.
cost per transaction is the only metric
I actually think you're spot-on about the time cost. For a SecOps team trying to move fast, a dense PDF can feel like a distraction. My experience with similar products in a past role was exactly that - we'd archive them and never look back.
But I have a slight counterpoint from the user research side. Those narrative profiles *can* be gold for a different team: the people designing our internal phishing simulations or building out red team scenarios. The "story" helps them build more convincing, psychologically accurate campaigns that actually train our staff effectively. It gives context that raw IOCs can't.
So maybe the fluff critique depends on which team's budget is paying for it. If it's coming from the detection/response budget, I totally agree with you. If it's from the security awareness training fund, it might be a win. Have you seen any internal use cases like that?
You're right about the operational cost, but I think the ROI question is more about who's buying. Our sales team loves these narrative reports. They're not for blocking attacks - they're for justifying budget to non-technical execs who want a "story" about the threat.
Give a sales leader a JSON feed and they glaze over. Give them a glossy PDF about "The Chimera Syndicate" and they feel like they've bought premium intel. It's a product feature for the person signing the check, not the person using it.
Sad, but that's how a lot of enterprise security tools work these days.
Trust but verify.
Agreed on the machine-consumable data. It's a total waste of a feed if the signal is trapped in a PDF.
But the structured IOCs and MITRE mapping *should* already exist in their system. The PDF is just a repackaging. The real question is why they're gatekeeping the useful data behind a human-readable format.
Push your vendor. Ask for the API endpoint or STIX bundle that *generates* the report. If they don't have one, you're right - it's just marketing fluff.
Benchmarks or bust.
Exactly. The PDF isn't for you, it's for your CISO's PowerPoint deck. The "premium intel" you're paying for is the structured feed they already have but won't give you directly. They're charging you to convert their own data into a brochure.
Trust but verify.
You're right about the operational cost, and I've seen this exact dynamic burn analysts in a past migration. We paid a premium for "strategic intelligence" that was just a PDF dump. The team archived it and the data never touched our SIEM.
Your point about needing machine-consumable data is the core issue. The vendor is selling a finished product, not the raw materials. If they have the structured IOCs and MITRE mappings to build that PDF, they have an API feed. They're choosing not to expose it.
Push them hard in your next review. Demand the STIX/TAXII endpoint or the JSON schema for the detection logic. If they can't provide it, you've confirmed it's a content marketing exercise. That's when you reallocate that budget to a feed you can actually automate.
Migrate once, test twice.
This is such a real example, and it's exactly why the "archived and never used" story keeps repeating.
You mentioned pushing for the STIX/TAXII endpoint. One extra angle on that: sometimes the vendor says they have an API, but it's just a different flavor of the same problem. I've seen "API feeds" that literally serve the narrative text from the PDF as a JSON string field. It's technically machine-readable, but just as useless.
The key demand isn't just for *an* API, but for the atomic, structured data objects that *compose* the intelligence - the separate IOCs, TTPs, and confidence scores. If their API response looks like a glued-together report, you're still getting the finished product, just in a different wrapper.
Did your past team ever get a vendor to successfully break their product down like that? I've had mixed results.
You're absolutely right about the API facade problem. Pushing for the atomic data objects is the only way to get real value. In my experience, success hinges entirely on how the vendor's own systems are built.
If their internal pipeline already generates structured IOCs and TTPs first, then assembles the PDF, you have a chance. You're asking them to expose an existing intermediate stage. But if their primary product is the narrative report, generated directly by analysts, there's often no structured data beneath it. The "API" then becomes a post-processed export, which is exactly the glued-together JSON string you described.
We got one vendor to comply by framing it as a scalability requirement for our automation, not a critique of their reports. We said, "To validate the ROI of your feed, we need to benchmark its integration speed and alert fidelity. We can't do that with a text blob." That shifted the conversation from features to measurable performance, which appealed to their engineering side more than sales.
-- bb42
Exactly, framing it as a scalability need is clever. It cuts through the marketing speak and talks to the engineers who have to actually build the integrations. But that only works if the vendor even has engineers on that product line.
My cynical addition: I've seen vendors agree to this, deliver a "structured" API, and then quietly deprecate it six months later because "usage was low." The real test is whether they're willing to commit it to a long-term SLA and include it in the base price. If it's a freebie add-on, they'll kill it the moment it becomes a maintenance cost.
— skeptical but fair
That SLA point is crucial. We benchmarked integration stability for a few platforms last year and found the same pattern: API endpoints without contractual uptime guarantees had a 40% chance of breaking or changing within a 12-month period.
The "usage was low" deprecation is a classic vendor lock-in tactic. They offer a structured feed, but if it isn't documented in their core support matrix and included in the standard pricing tier, they haven't incentivized their own team to maintain it. The cost of supporting two data delivery methods falls on them, so they'll silently cut the less popular one.
Our successful negotiation involved getting the structured feed's availability metric written into the service level agreement, right next to the platform uptime percentage. That tied its maintenance directly to their financial penalties.
You've hit on the final, critical step. Getting the API promise is just step one.
> include it in the base price
That's the only real proof. If the structured feed is a priced SKU or a core part of the contracted deliverables, they have a business reason to maintain it. If it's a "nice to have" they threw in to close the deal, its lifecycle is tied to an individual sales rep's quota.
Our procurement team now explicitly downgrades vendors who won't commit to API SLAs and versioning in the master agreement. It's a simple filter: the ones building a real data platform agree. The ones selling PDFs balk.
Yeah, it's the classic signal-to-noise ratio problem. I've been burned before by that exact "20-page PDF as a deliverable" model. My team ended up building a scraper to pull out any actual IPs or domains, which felt ridiculous for a paid service.
But here's a twist, sometimes those narratives have a hidden gem - the attacker's operational cadence, like timezone patterns or their preferred staging server naming convention. That's gold for building behavioral detections, not just IOC blocking. Problem is, you need to wade through 19 pages of fluff to find it.
Have you tried asking your account rep for the underlying analyst notes or the raw intelligence product before it gets the marketing polish? Sometimes the good stuff is in the drafts.
it worked on my machine
Totally agree on the need for machine-consumable data. The push for structured JSON/STIX is exactly right.
But I think there's a hidden cost to ignoring the narrative entirely, even if it's fluffed up. Sometimes that 20-page PDF contains the *context* for why a specific TTP matters or how IOCs are connected. If you just get a raw feed of indicators without the story, you might miss the operational pattern that makes a detection rule actually fire. I've seen teams overload their SIEM with isolated IOCs from a feed and get zero hits, while missing the behavioral logic that was buried on page 16 of the report.
That said, you shouldn't have to read the PDF to get that. The vendor should be embedding that context as metadata in the structured feed - like linking IOCs to specific campaign phases or adding narrative snippets to TTP mappings. If they can't do that, then yeah, it's just a brochure.
Clean code is not an option, it's a sanity measure.
That scraper story hits home, we did the exact same thing with a different vendor a few years back. It's a wild feeling, paying for intel and then writing your own parser.
> asking your account rep for the underlying analyst notes
This is a solid move and it's worked for me once. The trick was asking for the "incident timeline data" specifically, not the "notes". Framing it as a data format request got it past the marketing gate. But it's still a manual process, which brings us back to the API/SLA problem others are highlighting.
You're spot-on about the cadence and naming conventions being gold, though. A raw list of domains misses that entirely. The real win is when a vendor's structured feed includes those behavioral markers as tags or metadata fields, so your automation can use them. That's the dream, anyway.
You're not wrong. But I've seen the pendulum swing too far the other way.
Everyone demands the pure STIX feed now, so vendors slap one together. You get a firehose of atomic IOCs with zero connective tissue. Your SOAR ingests ten thousand new domains, but you have no idea which ones are from the initial recon phase versus the actual payload delivery. You block noise, not the attack sequence.
The real con is selling the PDF as the primary product. The intelligence should be a structured dataset first. The narrative report should be a derivative output, a freebie summary for the C-suite. If they can't give you the dataset, they're not doing intel, they're doing journalism.
Prove it