liveBook · Manning

Cause analysis

As explained in Data-Driven Cybersecurity

A systematic technique for identifying the underlying reasons an adverse event occurred so that its problems can be addressed and recurrence prevented.

Cause analysis identifies why an adverse event occurred so the underlying problem can be corrected, rather than only its symptoms. In cybersecurity, it follows the assessment of unusual activity: analysts first determine whether an event is a benign anomaly or a genuine threat, then investigate how it happened and where controls failed. section 8.6 section 9.5

A practical investigation moves from evidence to action:

  • Collect relevant incident information and examine it for patterns and possible causes. section 9.5
  • Ask why the problem occurred, repeatedly if needed. The Five Whys helps move past symptoms toward a primary factor, such as a vulnerability, misconfiguration, or attacker exploit. section 9.5
  • Implement corrective actions that address the identified weakness and reduce the likelihood of recurrence. section 9.5

Tracing a data breach

At a financial institution, investigators traced an unusual data transfer through a timeline of phishing, subsequent logins, and exfiltration. The phishing email was the entry point; missing multifactor authentication for remote access allowed stolen credentials to be used. The institution added multifactor authentication, improved email filtering and network monitoring, and trained staff to recognize phishing. Each action addressed a finding from the investigation rather than the data transfer alone. section 9.5.1

Track whether investigations become faster and whether fixes last. In one incident-analysis exercise, average root cause analysis time fell from 12 to 4 hours, while the incident re-occurrence rate fell from 20% to 5% after process improvements. A separate adverse-event exercise reported an 80% root cause resolution rate after strengthening investigative tools and procedures. These measures give leaders a way to judge progress, but the decision remains whether identified weaknesses are being addressed. section 9.5.3 section 8.6.2

Figure 9.4 The left side shows SecureTech’s incident analysis dashboard before improving the incident management process. The right side shows the dashboard after improvements.

Compare the before-and-after incident dashboard, particularly analysis time and incident re-occurrence, to see whether investigations and corrective actions improved. section 9.5.3

How Data-Driven Cybersecurity covers it

How deep it goes
Outlines data collection, pattern analysis, the Five Whys, cause identification, and corrective action without prescribing a specific investigation tool.
Examples
Traces a financial institution’s breach from phishing and stolen credentials to missing multifactor authentication and targeted fixes.
What it assumes
Introduces the investigative steps from data collection onward without requiring a particular forensic tool.
What you can do after
Diagnose/debug with it by identifying an incident’s primary cause and choosing corrective actions aimed at preventing recurrence.
How it connects
Links adverse event analysis and incident triage to the Five Whys, corrective actions, and incident recurrence metrics.

Also explained in

Compare how 3 books explain cause analysis →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Data-Driven Cybersecurity. The section links point to the parts of the book it draws on.