Well Measured is Half Done
In today’s rapid-fire world of attack and react, security analysts are often too busy triaging and resolving incidents to think about building relevant post-mortem reports. Most organizations have these reports, but they are more of an afterthought than a critical goal. And while sometimes not explicit, sub-optimal reporting harms SOCs across functions.
If SOCs don’t follow a robust, standardized reporting format, it becomes tougher to detect linkages between incidents across time, leading to repeat attacks slipping under the cracks. Moreover, if reporting is incomplete, analysts can forget the nuts-and-bolts of the investigation and potentially make the same mistakes again, losing time and peace of mind. It also does no favors to auditing and compliance teams if they have to study piecemeal reports that fail to focus on all metrics of importance.
Here, we’ll go through important metrics that a security incident report should cover to benefit SOCs in both real-time and posterity. You can also download a report template given at the end of this blog.
The Art of Summarizing
A security incident report should start with a brief but complete summary. When viewed post closure, this summary will give all salient details necessary for readers to form a rough understanding of the incident. The summary should also ideally contain metrics across which incidents can be filtered, compared, and linked.
Some examples of fields that should be included in the summary are:
Incident ID: Unique incident identifiers are helpful for categorization and filtering.
Incident Title/Header: A one-line description of the incident.
Incident Type: The incident category (phishing, malware etc.) is useful for filtering and response process assignments.
Incident Owner: Each incident should be assigned to a security analyst of manager. This helps assign accountability and measure best-performing analysts over time for particular incident types.
Timeline Information: Metrics such as incident creation date, closure date, and time to resolution are measurement cornerstones upon which overall SOC efficiency rests.
Reason for Closure: With standardized keywords (false positive, duplicate incident etc.), this field can be a helpful filtering aid.
Evidence Information: High-level metrics of important pieces of evidence give readers insight into the investigation procedure followed and set standards for response procedures when similar incidents occur in the future.
Playbook Used: If you’re using a security orchestration and automation solution – or indeed if you’re using manual playbooks for incident response – then it makes sense to include the playbook that was used to triage and resolve the incident. This helps new analysts know which playbooks to align with similar incidents in the future.
These are just a few metrics to record in the security incident summary. For a more complete list, download the template available at the end of this blog.
To learn more about Demisto's reporting, dashboards, and other incident management features, download the Demisto for Incident Management datasheet.
Once the appetizer of the summary has been dispensed with, it’s time to enter the real meat and bones of the incident. The investigation timeline is essentially a step-by-step account of tasks undertaken to resolve the incident, the results of those tasks, and how the incident metrics changed because of those tasks.
An illustrative list of things to record for each investigation event is given below:
See You Later, Indicator
This section forms the most important linkage with other incidents in a SOC’s environment. A list of all indicators (URLs, IPs, hashes etc.) that were associated with the incident, along with their reputation, source, type, and timestamps will enable analysts to study repeating patterns of indicators across incidents. If certain indicators are persistent in the SOC environment, these post-mortem reports will enable analysts to identify them and initiate separate remediation measures.
A sample screenshot is given below:
Listing The Evidence
As the report winds down, it’s crucial to list down the main pieces of evidence that led analysts towards their final decision. Apart from its obvious use in auditing and compliance, this section also serves as a breadcrumb trail that guides analysts when they refer to the incident report in the future. Clarifying important pieces of evidence for one incident will help analysts run similar actions on related incidents occurring later.
Let’s Go Freehand
While it’s imperative for security incident reports to follow a standard, each incident will still have unique features that make it stand apart – a fingerprint-like identity impossible to fit into any other category. To legislate for these features, incident reports should contain a ‘Collaboration Notes’ section.
Some aspects this section should cover are:
Specific actions taken by the analysts and the underlying reasons for these actions.
Chats and messages between analysts to highlight how they arrived at a certain decision.
Thought processes behind identifying key pieces of evidence.
Product integrations used and the underlying reasons for using them.
Learnings for similar incidents in the future.
We hope these security incident report guidelines help you standardize measurement and recording in your SOC. These are just guidelines, though; feel free to chop, change, and add to these suggestions to create a reporting standard that fits your SOC like a glove.
You can find a template of this report below (with illustrative examples) to help get you started.