As concerning as cyberattacks and suspicious incidents are, they also provide opportunities to reinforce your cyberdefense implementation, configuration, and strategy. Innovative techniques and the discovery of unknown, unmonitored vulnerabilities generally preempt successful cyberattacks. As a result, organizations need to investigate these events and their surrounding scenarios to optimize detection and response and prevent recurrences. The investigation’s results are compiled in a root cause analysis report.
What is a Root Cause Analysis Report?
A root cause analysis (RCA) is a team-facilitated, in-depth examination of any cybersecurity event. RCA comprises one of the critical concluding stages of the response processes initiated after detecting active attacks or suspicious activity. These efforts are necessary for determining what factors led to a given event’s occurrence (successful attack or otherwise). The root cause report presents a clear and concise breakdown of a given event, across these components:
- Introduction or root cause analysis summary
- Description of the events being studied
- Chronology of events (i.e., event timeline)
- Forensic methodology used to investigate the events
- Findings (i.e., the root cause) and any remaining detailed descriptions
- Corrective actions and strategies for cyberdefense optimization
The report serves as guidance material for actionable measures to better identify and manage vulnerabilities, prevent event recurrence, and will help guide ongoing cybersecurity strategies.
RCA Component #1: Introduction
The introduction provides the audience with background information about the event, the report’s purpose, and the essential points covered throughout the document. Since RCA reports should be compiled per event, their scope should be narrow and their introduction brief. Some reports will have a “problem statement“—or a one-sentence summary of the event.
RCA Component #2: Event Description
Here you will find an in-depth recap of the event—usually in paragraph form—based on the information gathered by the RCA team.
The description should include:
- Date and time of the event
- What occurred
- How the event was discovered
- Who reported the event
- Response actions taken and by whom—before, during, and post-event
- Communications regarding event reporting—internal and external
- Impact of the event (e.g., financial, regulatory compliance)
RCA Component #3: Event Timeline
The best format to view all activities that occurred or did not occur leading up to and after an event is chronologically. The timeline should not be overloaded with details, only factual data.
For example, activities may be logged in an RCA report’s event timeline as follows:
- February 21, 2021 @ 0200: SIEM event occurred on Server X
- February 21, 2021 @ 0317: SIEM event Acknowledged by Operator Mills
This example shows a one-hour and 17-minute gap between the event occurring and the operator’s acknowledgment. The significance of that gap (e.g., reasons for response delays, recommendations to reduce delays) will be covered elsewhere in the report when providing more thorough event descriptions and the RCA team’s complete analysis. As a timeline entry, you only need the basic facts.
Request a Free Consultation
RCA Component #4: Analytical Methodology
The methods used in your root cause analysis can vary based on the nature of the event. The RCA team’s investigation may employ any of the following techniques:
- Barrier – Examines the pathways a threat can take toward a target or asset that can cause an undesired outcome
- Cause Factor Tree – Uses a hierarchical or tree design to display the actions, conditions, and contributing factors that lead to an adverse event
- Change – Systematic approach to review impact and risk management strategies involving change within an organization, especially how expected and recent changes affect cybersecurity effectiveness
- Failure mode and effects – An review of product or process failures, strictly from an engineering perspective
- Fault tree analysis – Known as the “tree of logic,” this method examines an event using a logical tree of “AND,” “OR,” or “NOR” logic gates to show the contributing factors of an incident where the undesired event is the root.
- Fishbone – An analytic tool for examining effects and the contributing factors that create the effect. Often referred to as fishbone because the display of opposing lines for causes and effects resembles a fish skeleton.
- Pareto – A statistical cause analysis summary that looks at selected actions or tasks that produce a significant result (i.e., the incident being investigated). With this method, you can distill many factors down to those contributing the most towards an incident’s occurrence.
- The Five “Why” Analysis – A problem statement is established (the incident), and a series of “Why” questions are asked until a root cause is found.
Your root cause analysis report should include one of the above or similar methods to properly investigate all contributing factors.
RCA Component #5: Findings and Root Causes
The fifth component of your root cause report is the findings and presentation of the determined root cause. Here is where the RCA team delivers the root cause of an event after objectively conducting some of these activities:
- Reviewing logs, reports, and other documents about the incident
- Identifying precursors or indicators as evidence leading to the incident
- Determining any impact to the organization before incident detection
- Stating whether the actual cause was identified
- Determining if the incident is the recurrence of a previous incident
- Estimating the damages attributed to the incident (e.g., noncompliance, financial, reputational)
- Comparing initial impact findings to final impact findings
- Presenting security program advisory and recommending preventive measures based on the incident
In most reports, you will see a root cause stated alongside summaries of contributing and connected factors. When documenting your analysis summary, root cause statements should follow five rules:
- Root cause statements must present the event’s cause and effect.
- Do not include negative statements about personnel involved or condemnations.
- A cause precedes every incident of human error.
- Procedural violations don’t constitute root causes in and of themselves; they must have preceding causes.
- Any determination of a “failure to act” may only be considered a root cause if there is a pre-existing duty to do so (e.g., documented policies or responsibilities).
RCA Component #6: Corrective Actions
Your root cause analysis report should include a corrective actions section to guide any further remediation efforts and standard cybersecurity strategy (once normal operations and conditions resume). This section leverages the RCA findings to help prevent incident recurrence.
The RCA team will offer actionable tasks relevant to the root cause and its contributing factors, which inform daily or periodic responsibilities, baseline configurations, and your change management program. Once the RCA team presents their advisory in the root cause report, your organization must determine the feasibility of these corrective action recommendations.
You may also find an “improvement plan” with built-in accountability and milestone markers to track progress. Typically, improvement plans contain the following headings:
- Area of improvement
- Corrective action (from the root cause analysis summary)
- Responsible party (individual or department)
- Expected start date
- Anticipated completion date
How Root Cause Analysis Reports Help Your Organization
Your organization should consider RCA reports as opportunities for growth instead of a “failure report.” They help prevent you from focusing on a single causality when there are likely several areas contributing to the event and requiring adjustment. Any findings and recommendations should acknowledge cybersecurity as a complex, holistic endeavor comprising people, processes, and technologies.
The primary benefit of root cause analysis reports is that your organization retains the documentation for future reference (e.g., ongoing security program refinement, compliance reporting). Archived RCA reports can also be used during security team training and mock-incident walkthroughs.
Additionally—and the details of a given event aside—RCA reports also provide concrete examples of:
- Logical methods for problem-solving, using internal or pre-existing data within the organization.
- Repeatable, step-by-step processes designed to address specific problems and provide actionable remediation tasks.
Root cause analysis reports may be necessary for compliance reporting following any security incidents, depending on applicable frameworks (e.g., HIPAA).
Go Beyond RCA Reports with RSI Security
Whenever a cyberattack or security incident occurs, your organization should conduct a root cause analysis and compile the findings into a root cause analysis report. The reports provide essential guidance for future security program strategy, compliance reporting documentation, and informational briefs for non-technical audiences in your organization.
RSI Security’s expertise helps your organization begin a root cause analysis, compile a report, or begin implementing recommendations from one.
Get started on your corrective actions and contact RSI Security today!