We’ve been playing with presenting Indicators of Compromise: when, how, and why. Amongst the staff, opinions vary. We thought we’d open the question to the community. Well, several questions.
Do you want Indicators of Compromise listed on topics about active incidents?
How do you use the indicators?
Do you want IFIN to maintain a feed of machine-ingestable indicators for major incidents?
Do you want IFIN to publish indicators to existing platforms like AlienVault OTX or VirusTotal?
We will certainly provide any indicators we can for home-grown intelligence. This question is really about how we interface with reports from others. What’s missing/needed that we can provide? What don’t we need to reproduce?
I’m a small team that needs to be scrappy. I also live in the PacNW and often mitigate Himalayan Blackberries; covered in thorns, they grow and spread quickly, even from the smallest root. You don’t cut HBBs with a weed eater; they’ll grow right back, you dig out the roots, repeatedly.
How I use IOCs depends on the type, but the process is generally the same: what’s the root of this IOC?
David Bianco‘s Pyramid of Pain was excellent when he published the idea in 2013, but I think it’s now out-dated.
For most of us, it is not more painful to block a TLD than the domain.
Your users will not miss .top .sbs .click.
We absolutely know Stark Industries is rotten. Block all CIDRs in ASN 44477.
Most organizations do not need access to Vercel’s free-tier subdomains.
Your users won’t miss Win+R.
finger.exe has no functional purpose in 2026.
I’d like to push us to a state of linking IOCs to the supply chain from which they come from. Bonus, it will also hold these service providers accountable, similar to credit, scored accordingly.
We can’t always block the root, but we can start calling out the LOTS, ASN, TLD, cloud and email providers.
So instead of pain, we should start thinking “mitigations of low regret.”
You can read more about this methodology here by The Johns Hopkins University Applied Physics Laboratory: