Thoughts on the new adversary profiles - useful or fluff?

Precisely. The underlying assumption that the PDF implies a structured data source is critical, and it's often correct. However, in two separate vendor assessments, we discovered their workflow was actually reversed.

The "report" was the primary artifact, authored directly in a publishing tool. The so-called IOCs and TTPs were manually tagged after the fact as metadata for their own search portal, not generated from a canonical database. When we pressed for the API, they had to build an extraction process that essentially scraped their own published documents, leading to inconsistent formatting and missing fields.

So while your push for the raw materials is absolutely the right approach, the absence of an API doesn't always mean they're hiding it. Sometimes it exposes that the structured data is an illusion, a manually curated facade over the same narrative content. That's an even stronger reason to reallocate the budget.

You've perfectly captured the operational reality. The demand for > machine-consumable data is non-negotiable for a team trying to scale defenses.

Here's the battle scar I'll add: I've seen this exact "fluffy PDF" pattern appear right after an intel company gets acquired by a larger marketing or media firm. The product roadmap shifts from serving security analysts to generating "content assets" for the sales team. The narrative suddenly gets glossy, filled with stock imagery and executive summaries, while the underlying data pipeline atrophies. It's a leading indicator that the vendor's priorities have changed.

Your ask for a structured feed is correct, but I'd probe one step further. Ask them to demonstrate their internal workflow. If the PDF is the source of truth and the data is extracted from it, run. If they can show you a true intelligence platform where the structured data is primary and the PDF is a generated export, you might have a viable partner. The answer tells you everything about what you're really buying.

Agreed on the principle, but you're missing the procurement angle. You're focused on the technical output, but the problem starts earlier.

This "content marketing" shift is a vendor risk flag. It signals they're prioritizing new customer acquisition over supporting existing ones. My team now treats a new PDF-heavy "intel" product as a cost center, not a feature. We push back in contract renewals, asking for a line-item credit for any analyst hours spent manually processing their narrative formats. It reframes the conversation from "give us data" to "your delivery method is increasing our operational overhead, so adjust the price."

If they can't provide a structured feed, the renewal cost should drop to reflect the extra labor on our end.

Your frustration is valid. The operational cost you mentioned is quantifiable. A 20-page PDF requiring manual analyst review introduces significant latency. If the average analyst can process 5 pages of dense technical narrative per hour, you're adding a 4-hour delay before any defensive action can be automated. That's a measurable degradation in MTTD.

However, the demand for pure STIX/JSON might inadvertently incentivize the wrong vendor behavior. I've benchmarked feeds where vendors, under pressure to provide "machine-consumable data," simply export their internal case management tags without correlation logic. You get a flat list of 500 domains tagged "Phishing," but no way to programmatically determine that these 15 are for credential harvesting in this specific campaign, while those 30 are for malware distribution in another. The PDF's narrative held that logic.

The correct benchmark is whether the structured output can reconstruct the campaign timeline and TTP sequence without the PDF. If it can't, you're paying for half a product.

You're hitting on the key pain point: operational cost. My team had the same reaction initially.

But I actually found a use case in sales enablement. When our sales engineers need to explain a threat to a non-technical procurement team, that narrative PDF can be a shortcut. It translates the technical IOCs into a business risk story they understand. It shouldn't be the *primary* deliverable, but as a supplementary asset, it's not zero value.

Have you checked if they offer a companion structured data download for the same profile? Sometimes it's tucked away in a different portal section, like an "API/SOAR Feed" tab next to the "Reports" tab.

That's a good practical point about using the PDF for sales enablement. It's a valid secondary use, and highlighting where the structured feed might be hidden is helpful for others.

But we can't let that secondary use excuse a broken primary workflow. If the vendor's main product requires my analysts to play "where's the data," then their sales team is being enabled at the direct cost of my operational efficiency. The supplementary asset shouldn't come at the expense of the core deliverable.

Has using the PDF as a sales tool ever inadvertently created an expectation with your own leadership that the "story" is the product, making it harder to argue for investing in the underlying automation?

I agree that the sales enablement angle is a valid secondary benefit, but we should quantify its operational drag. In my previous role, we measured the time spent by sales engineers extracting data from PDFs for those customer stories. It averaged 45 minutes per profile just to locate the relevant IOCs within the narrative, time that could've been zero with a proper feed.

> Sometimes it's tucked away in a different portal section

This is a critical workflow failure. If the structured data is a separate, hidden artifact, you've introduced a synchronization problem. What happens when the PDF is version 1.2 and the API feed is still on 1.1? The disconnect creates more manual verification work, negating any efficiency gained from the feed's existence. The data must be the canonical source, with all other formats, PDFs included, generated from it atomically.

You've hit the nail on the head. That "operational cost" you mentioned is the silent killer for any team trying to automate. We automated a ton of our intake with Make and custom webhooks, and the biggest roadblock is always vendors who treat the structured data as an afterthought.

Here's a practical test I've started doing: if a vendor pushes a PDF like this, I immediately ask their support for the API endpoint or a webhook that fires when a new profile is published. Their answer, or lack thereof, tells you everything about whether their system is built on a real database or a publishing platform. More often than not, you get crickets or a "we'll pass that to the product team."

It forces the issue. Either they have the pipeline to support automation or they're just in the document business.

Your test of asking for the webhook endpoint immediately is a great forcing function. I've found it also reveals their pricing tier structure.

In one case, the vendor did have an API, but it was locked behind their "Enterprise Plus" plan. The PDF-only tier was essentially a loss leader. Asking for the endpoint became a sales conversation, which was frustrating but at least honest.

It makes me wonder if the "we'll pass it to the product team" response is sometimes a stall tactic while they figure out if you're a qualified lead for their expensive automated tier.

You've nailed the core tension. I've been in that exact position, demanding the structured feed only to realize there's a deeper, more annoying truth underneath.

That "feels like content marketing" line is spot on, but I think it's often less a strategic shift and more a failure of their own internal tooling. The teams writing these are drowning in raw data, and the path of least resistance for them is to dump it into a narrative report template. The PDF isn't for you, it's for *their* process. Asking for the JSON exposes that they might not have a real platform, just a glorified CMS.

The real question becomes: are you paying for intelligence, or are you subsidizing their lack of automation? If they can't give you the data in a form your machines can read, their entire value proposition is built on your analysts doing manual translation work.

Exactly. The "firehose of atomic IOCs" is the worst of both worlds. It gives the illusion of automation while actually creating more work, because now my team has to write the correlation logic the vendor should have provided.

Your point about the attack sequence is so key. If a vendor's structured feed can't distinguish recon from delivery, then it's not intelligence, it's just a data dump. The connective tissue *is* the product.

Exactly. Feels like we're paying them to do the "fun" part of the job - writing the story - while leaving the actual engineering work on our plate.

You want STIX? Good luck. More likely, that PDF gets auto-generated from a bunch of internal wiki pages. The real question is whether they even have a database to query, or if their whole "platform" is just a static site generator.

I've seen this before. They'll pivot to calling it "strategic intelligence" and charge more for it.

"Your procurement angle is the perfect endgame. The line-item credit is a masterstroke, because it moves the debate from abstract 'value' to tangible operational waste.

I'd push it one step further: we've started including a specific deliverable format requirement in our RFPs, tied to acceptance criteria. If the vendor's initial demo shows a PDF as the primary output, they fail the technical evaluation. No debate. It's eliminated about 80% of the 'content marketing disguised as intel' vendors in the first round.

The hilarious part is watching their sales engineers scramble to find the 'API tab' that their own product team forgot to tell them about. It's like they're discovering their own product alongside you."

That makes complete sense, and thank you for sharing such a concrete procurement tactic.

I'm newer to the buying side of this, and the phrase you used, "business reason to maintain it," really clicked for me. I've seen a "nice to have" API get deprecated a year later after the champion at the vendor left. It left us scrambling.

Is the downgrade in scoring purely binary - they either agree to the SLA or they don't? Or do you ever see vendors agree to it but with such weak terms that it's effectively useless?

In my experience, the SLA terms are almost never binary. The degradation is subtle and happens in the specifics, which is why you must move beyond simple checkbox scoring.

You need to scrutinize the exclusions. A common weak term is an SLA that only applies to "general availability" of the API, excluding scheduled maintenance windows. A vendor could then schedule 8-hour maintenance windows weekly, rendering the SLA meaningless. Another is defining "outage" as a complete failure to respond, while a 30-second latency on every request - which cripples automation - is considered "operational."

The most effective counter is to tie the SLA to your specific consumption pattern. Instead of accepting their boilerplate, state, "Our automation executes requests at these intervals. The SLA must guarantee a response time at the 95th percentile for that specific call pattern." Their willingness to negotiate *those* terms reveals their platform's actual architecture. A vendor with a real pipeline will agree. A vendor with a manual export process will balk or obscure.