Topic
Incident Analysis
Post-incident writeups of real breaches and actively exploited vulnerabilities, traced past initial access to the data the attacker could actually read.
23 posts
Incident analysis is the structured review of a real breach or exploited vulnerability to determine which control failed, what the attacker reached, and which architecture would have contained it. It works backward from confirmed facts in vendor advisories, regulatory filings, and exploitation catalogs. The output is an architectural conclusion, not a timeline.
Reviews stop too early. Most writeups end at initial access, name the unpatched appliance or the stolen session, and recommend faster patching, which leaves the more useful question unasked: once the attacker was inside, why was the data readable? Edge devices, federation servers, and endpoint agents keep appearing as entry points precisely because they sit above the data and inherit its trust.
Posts under this hub analyze vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalog across VPN concentrators, file transfer appliances, collaboration platforms, browsers, and network controllers, alongside breach writeups from healthcare, education, and AI platform providers. Each traces the blast radius to the data layer and asks what fail-closed enforcement would have changed. Disclosure obligations get the same treatment.
Frequently asked questions
What is the CISA Known Exploited Vulnerabilities catalog?
The CISA Known Exploited Vulnerabilities catalog is a public list of vulnerabilities with confirmed active exploitation. Federal civilian agencies must remediate entries by assigned due dates under Binding Operational Directive 22-01, and other organizations use it to prioritize ahead of severity scores. Inclusion means exploitation is observed in the wild, a far stronger signal than a CVSS rating alone.
When does the SEC cybersecurity disclosure clock start?
The four business day clock starts when a registrant determines an incident is material, not when it is discovered. The materiality determination itself must be made without unreasonable delay, so a company cannot postpone that decision to delay the filing. The disclosure covers the nature, scope, and timing of the incident plus its material impact on operations and financial condition.
Why do breaches keep succeeding when identity controls hold?
Identity answers who authenticated, not what the data permits. Federation token forgery, session theft, and unauthenticated application flaws all produce sessions the identity layer considers valid, and everything downstream trusts them. When authorization is evaluated once at login and data sits in plaintext behind it, a valid session becomes a full read. Object-level policy re-decides on every access.
What should a post-incident review produce?
A confirmed sequence of events, an evidence-backed blast radius naming which data objects were reachable and readable, the specific control that failed and why, and one architectural change that would have narrowed the outcome. Vague remediation such as improved monitoring signals an incomplete review. Name the enforcement boundary that was missing and where it belongs.
