Somebody Asked for MISP in a Feedback Box. Here Is the Feed — and a Tag on Every Single Record Telling You Which Ones Are Actually Ours.
- Patrick Duggan
- 1 hour ago
- 5 min read
We ship a STIX 2.1 feed, a TAXII endpoint, CSV blocklists and an OPNsense format. We did not ship MISP, and MISP is the format that most CERTs, ISACs and national teams actually run.
We know that because somebody told us. Not in a sales call — in the rate-this box at the bottom of a post. A reader gave us a ten and added, unprompted, that MISP was about all they could take but they could work with the other formats. That was the second time the same format had come up by name.
So it exists now, and this post is mostly about the one design decision in it that we think matters.
The feed
The manifest lives at analytics.dugganusa.com/api/v1/misp/manifest.json. That is the URL you paste into a MISP instance as a feed source. There is a hashes.csv alongside it for quick lookup, and each event resolves at its own UUID.
A MISP feed is not the MISP application — it is a static directory served over HTTPS, which means this is a serialization of intelligence we already publish rather than a new product. If you already pull our STIX feed, this is the same corpus wearing a format your instance can eat without a translation layer.
Two structural choices worth stating.
One event per campaign. Not one per day, not one per indicator type. Our ingest rules already require every record to carry a campaign-specific source field, because that field is the only reliably searchable attribution handle we have. So the thing that makes a campaign auditable internally is the same thing that makes it a coherent event externally. A feed grouped by date hands an analyst a pile; this hands them a story with a name on it.
The UUIDs are deterministic. Event and attribute identifiers are derived from stable inputs, so pulling the same campaign twice does not create it twice. A feed whose identifiers drift between fetches quietly poisons every subscriber's instance, and that failure is invisible from the publishing end.
The part we actually want to talk about
A MISP event carries an organisation field. Ours says DugganUSA. A reasonable person reads that as: DugganUSA observed this.
For most of this feed, that would be false.
We hold 150 campaigns. Eighteen of them come from our own hunting, scanning, honeypot and edge telemetry. One hundred and thirty-one are somebody else's research that we harvested — Talos, Volexity, Check Point, Kaspersky, ESET, CISA advisories, vendor write-ups. Useful to carry. Not ours to claim.
Withholding them would be the wrong answer. A CERT genuinely benefits from receiving a Talos indicator set in a format their instance can ingest today rather than next quarter. But serving it unqualified, under our name, is laundering — and we have spent a lot of words on this blog criticising vendors who do exactly that.
So every event and every attribute in this feed carries a provenance tag. First-party. Ingest. Or unknown.
You do not have to trust our characterisation of that split. Filter on the tag and count it yourself. That is the entire point of putting it there.
Why the small number is the interesting one
Eighteen events out of a hundred and fifty is not a flattering headline. We could have written this post about 5,020 indicators and never mentioned the ratio.
But the honest pitch is stronger, because it is checkable. Anyone can redistribute a public list. The reason to read us is the eighteen.
The row we would point at is Handala-MOIS, an Iranian MOIS-linked operation that appears in this feed four separate times under four different internal source strings — a GitHub hunt, a DNS pivot, live reconnaissance, and a DNS hunt. That is not four copies of one finding. It is the same actor surfaced by four independent methods, and it is the kind of thing that does not exist in a feed you can mirror for free.
Same for the Apothecary domains our precursor-detection work caught, and for NrodeCodeRAT, which we documented before it was renamed by a major vendor.
While we were checking, we found our own test data in it
The first time we pulled the live manifest, one of the events was called e2e-test.
That is our own end-to-end smoke test, published to subscribers as though it were intelligence. Nobody consuming a feed can tell a vendor's test fixture from a finding — it arrives in the same shape, in the same event list, with the same organisation attached.
It is also the third time this month that a piece of our own instrumentation turned up inside a product surface. Our reader-feedback score was counting our own test submissions and reading several points higher than reality. And a naive count against our own index reported over a thousand indicators for a campaign that actually held sixteen, because the search matched a substring rather than the field.
The pattern is the same every time. Instrument exhaust looks exactly like product until somebody reads the artifact instead of the dashboard. There is now a filter that strips test-shaped sources from this feed at both screening points, because that belongs in code rather than in somebody's memory.
What we deliberately do not serve
Raw mirrors of public feeds. If a record's source is abuse.ch, ThreatFox, OpenPhish, OSV, Spamhaus or the OTX era, it does not become a DugganUSA MISP event. You already pull those directly, and re-serving them under our organisation would inflate our apparent contribution while double-counting in your instance.
Indicators we would not block ourselves. In MISP, the to_ids flag means this is safe to turn into a detection. We gate it at the same confidence threshold that governs our CSV blocklists, so an indicator that does not qualify for our own blocklist cannot arrive in your instance flagged for automatic detection. Lower-confidence records still ship — they arrive as context, with the flag off.
That distinction did real work this week. A recent advisory for an actively-exploited PLM vulnerability published thirty-three network indicators. Five were observed in live incidents. The other twenty-eight came with the publisher's own caution that some may be shared or ephemeral hosting. Those twenty-eight are in the feed, at a confidence below our blocking line, marked not-for-detection. A feed that had shipped all thirty-three as blockable would have looked more generous and been worse.
If you run a MISP instance
Add the manifest URL as a feed, pull it, and then immediately filter on the provenance tag to see the shape of what you just took in. If the eighteen are not useful to you, the other hundred and thirty-one probably were not either — and you should tell us that, because the last person who told us something in the feedback box got a feed format out of it inside a fortnight.
Was this useful, or did we miss something? Rate this post below — we read every one, and the low scores are the ones that change what we build.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=somebody-asked-for-misp-in-a-feedback-box-here-is-the-feed-and-a-tag-on-every-single-record-telli
Comments