Reading a Deflecto incident report (part 3)

We get asked about reading a Deflecto incident report more than almost anything else, so here is the long answer.

Testing in production, safely

Every rule starts in log mode. We replay the previous seven days of traffic through it and show exactly which requests it would have affected before anyone can promote it to challenge or block.

This one feature has prevented more incidents than any detection we have ever shipped.

Protecting the origin

None of this matters if the attacker can reach your origin directly. Historical DNS records, certificate transparency logs and misconfigured subdomains leak origin addresses all the time.

Allow-list the edge ranges, enable authenticated origin pulls and treat any origin IP that ever appeared in public DNS as burned.

What we got wrong

Our first version challenged too eagerly on mobile networks, where thousands of real users share a handful of carrier-grade NAT addresses. Reputation that is shared is reputation that is noisy.

We now weight fingerprint consistency and session behaviour far more heavily than IP reputation for traffic from known mobile carrier ranges.

Compliance is a side effect

Regulators increasingly ask for evidence of resilience, not just promises. An incident timeline with start, peak, vectors and impact is exactly the evidence DORA and NIS2 ask for — and it falls out of good observability for free.

We export incident reports in formats auditors can file without anyone rewriting them.

We will follow up with the numbers from the next quarter.

10 thoughts on “Reading a Deflecto incident report (part 3)”

  1. We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top