Was the Data Breach Preventable? Moving from Timeline to Causation

Reconstruct the intrusion

• Initial access and the exploited weakness
• Credential use, privilege escalation and lateral movement
• Persistence, command-and-control and data access
• Detection, containment and recovery actions
• The systems and information actually affected

Test preventability

• Was the vulnerability known and practically remediable?
• Were authentication and access controls reasonably configured?
• Would the proposed patch, alert or policy have stopped this attack path?
• Did a vendor or third party control the failed component?
• Was the event driven by misconfiguration, ignored warning, known vulnerability, zero-day or a sophisticated technique not reasonably preventable at the time?

Avoid outcome-based reasoning

The occurrence of a breach does not by itself establish unreasonable security. The analysis should use information and feasible controls available before the event, test counterfactual claims and separate a policy gap from a gap that actually caused the loss.

How Leo can help

Leo began securing and investigating internet-facing servers long before leading telecom companies. His hands-on work included tracing intrusions, identifying exploited weaknesses, removing malicious code and persistence, restoring systems and determining what the available evidence could support. His law degree helps translate that record into causation and liability questions.