By Yair Knijn · December 10, 2025

The CISO standing in front of the board after a phishing hit, explaining why a known-bad domain wasn't blocked

The credential-harvesting page that took the finance lead had been sitting on a public phishing feed before the email ever arrived. The CISO knew the feeds existed. His threat intel platform pulled them, the SOC enriched alerts with them, a dashboard somewhere flagged the indicator as known-bad. None of that reached a single endpoint's DNS resolver, so the lookup returned a normal answer and the session opened.

That is the gap the board asks about, and most security programs are not built to answer it. The wrong assumption was that having the intelligence and acting on it are the same thing. They are not even the same system.

The post-incident question: a known-bad domain, unblocked

What makes this one sting is the forensic timeline. The domain appears in the threat platform's ingestion log on Tuesday. The user clicks it on Wednesday. When the SOC pulls the record afterward, the indicator is right there, correctly scored, in a feed nobody disputes. No detection failure to hide behind, no zero-day — the control was simply never wired to the resolver.

Boards do not punish the existence of an unknown threat. They punish the distance between "we had this" and "we stopped it" — and that distance is a process choice, exactly what governance is supposed to catch.

Feeds that inform versus feeds that enforce

A feed that informs lands in a SIEM, raises an alert, and waits for a human to triage it. A feed that enforces sits inline at name resolution and returns NXDOMAIN or a sinkhole address before the connection opens. Same indicators, opposite outcomes: one produces a ticket after the click, the other stops the click.

URLhaus, OpenPhish, and PhishTank are built to be machine-consumed for precisely this. The mistake is treating them as reading material for analysts rather than a deny-list the resolver reads every few minutes.

Wiring URLhaus, OpenPhish, and PhishTank into DNS blocking

Enforcement at the endpoint turns the feed into a rule the local resolver applies, not a report a human reviews. In practice, a short loop:

• Pull the feeds on a fixed interval and normalize each URL down to the host you can block at DNS.
• Strip out anything on your own allow-list, so a feed false positive never blackholes a domain you depend on.
• Push the resulting host set to every endpoint resolver, not just the gateway, so off-VPN laptops are covered.
• Log every block with its source feed and timestamp, because that record is your audit evidence and your tuning signal.

The off-gateway part matters most. A blocklist that lives only on the corporate firewall abandons the laptop in the airport lounge, where the phishing click usually happens.

Latency: how fast a new indicator becomes a live block

Enforcement is only as good as its slowest hop. A community phishing feed refreshes on its own schedule, so an indicator can already be hours stale before you fetch it; sync once a day on top of that and the domain may have rotated by the time you block it. Measure the real number end to end, from indicator to a blocked answer at the endpoint. Pulling frequently and pushing to resolvers within minutes closes the window the Wednesday click lived inside.

Closing the 'we knew but didn't act' gap

The fix is structural, not heroic. Move the feeds from the report side of the house to the enforcement side, give the resolver authority to refuse a name, and keep the evidence trail that proves it ran. Then the post-incident answer stops being an apology and becomes a timeline: indicator ingested, block applied, lookup refused.

ClearScreen consumes URLhaus, OpenPhish, and PhishTank directly into endpoint DNS enforcement, applies a per-tenant allow-list before anything is blackholed, and logs every block with its source feed, so the control is auditable rather than aspirational. To see the enforcement path and indicator latency, start with the feature breakdown.