Data breaches and log analysis

After an intrusion the question that matters is not whether you were attacked but what left the building. Between «data was reachable» and «data was copied» lies the same distance that separates a risk from a compensable loss.

The first hours

The instinctive response to an incident is to restore everything and get going again. It is understandable and it almost always destroys the evidence: reinstalling a server overwrites the disk that held the answer, restarting it clears the volatile memory where the running state lived, and restoring from backup makes the compromised state disappear.

Three things come before anything else: isolate the system from the network without powering it down, capture volatile memory if possible, and suspend log rotation — which otherwise erases the very window of interest within days. An organisation that manages those three steps has already preserved most of what will be needed.

What the logs say

The reconstruction is built by cross-referencing sources, each illuminating a different part:

• Authentication — successful and failed logins, times, origins. A successful login from an address never seen before, at an unusual hour, after a run of failures, is an entry point.
• Web and application servers — the requests received. This is where the technique of entry can be read and, often, the volume of data returned.
• Databases — which queries ran and how heavy they were. This is the source that best distinguishes a lookup from a bulk extraction, assuming query logging was enabled: in most cases it was not, and that absence is itself a finding.
• Network traffic — outbound volume towards external destinations. A spike of data towards an address never contacted before is, where available, the closest thing to proof of exfiltration.

The method is always the same: start from a certain indicator — a foreign file, an anomalous login, an alert — fix its time, and widen the window across every available source, building a single timeline. Time-zone inconsistencies and clock drift between systems must be normalised first, not afterwards: it is a frequent and insidious source of error.

The distinction that decides the case

Where the data does not allow the question to be settled, the correct answer is that it cannot be determined from the available information — together with a statement of what information would have settled it. That too is something a court uses, and it often bears on the assessment of the security measures in place.

The compliance side

The General Data Protection Regulation requires the controller to notify a personal data breach to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; where the risk is high, the breach must also be communicated to the data subjects. The controller must additionally document every breach, including those not notified.

My contribution here is technical and supports the lawyer: establishing which categories of data were involved and for how many subjects, which measures were in place at the time, and providing the documented reconstruction that supports — or refutes — the risk assessment. The legal decisions remain with counsel and the controller.

When the incident is already old

I am sometimes called in months later, often because a claim has arrived. By then the logs may be gone and a full reconstruction may be foreclosed. Useful work remains: verifying what was preserved, assessing how solid the reconstruction made at the time by others actually is, and establishing whether the conclusions drawn from it were supported by the data. Challenging a weak reconstruction is frequently more effective than attempting a new one on material that no longer exists.