The Security Incident Report is provided to MDR subscribed clients when your Security Analyst has identified a threat(s) which in turn becomes a "Security Incident". The report includes information about the threat(s) and how to best mitigate or mimize the risk.
Security Incidents reports are made available to you following our Incident Management process and are associated with tickets within the Help Center.
Security Incident reports are always provided to you in PDF format.
Page One - Severity, Victims, Summary and Mitigations
The first page outlines the severity of the identified security incident and provides an overview of the affected victims with essential summary fields describing the threat and recommendations on how to mitigate the risk.
NOTE: Details of the threat are described in the Incident Details starting on page 2.
The graphic above shows the various fields included in the Security Incident Report. Below is a detailed description of each field:
1. Severity
All Security Incidents are categorized with a severity that describes the severity of the reported threat.
| Severity | Description |
| Critical |
Security incidents with severe impact that threaten to have a significant adverse impact on the affected systems. These issues have a high probability of spreading or propagating, pose a threat to confidential or otherwise sensitive data or system. Critical security incidents require immediate attention for remediation or mitigation. |
| High | Security incidents where if exploited, these threats could lead to compromise of the system and/or loss of information. Should be investigated in a timely fashion. |
| Medium | Minor security incidents with low risk of spreading or propagation. Should be tracked and followed-up but generally medium threat severity incidents require no immediate action. |
| Low | Observed security related event that could be an indicator of threat or interesting from other perspectives but no direct security incident or threat. |
The (MDR) Security Analyst will make an informed decision in assigning the threat severity taking into consideration the specific situation and past experience.
The assigned severity level will provide you an easy means to quickly assess how important a threat is, and the level of priority which should be assigned in addressing it.
This will allow you to re-prioritize your actions so that you can start mitigating any threats quickly.
Hopefully you will not experience any Critical security incidents!
2. Title
A “one-liner” that describes the content of the reported Security Incident. This is the field used when listing tickets and in notifications.
When using the Help Center, this field is also known as the Subject.
3. First Observation
Start and stop. Time of the first evidence of the threat and when it ended ~ (to). Normally the timestamp on the first alert or date on the first log record found through threat hunting. If the threat is active when sending first report, it is marked as Ongoing.
the First Observation is NOT the time used for SLA measurement. There will be reports where the First Observation is a significant period of time prior (hours, days or weeks) to notification. This may be due to the fact that threat hunting might have revealed the true start of an attack to have occurred earlier.
There are multiple timestamps in in relation to a new Security Incident ticket: First Observation (this), Determine time (reports started in SOC reporting tool) and created (ticket created and made available in the Help Center).
4. Victims
The Host name(s) and/or IP address(es) affected by the threat with Username (if present) and Endpoint ID (if present).
If Isolation Initiated? is Yes, the MDR SOC has isolated and contained the threat using the client EDR solution.
If all victims are without Endpoint ID, the columns Endpoint ID and Isolation Initiated? is hidden in the report.
A victim will have one or more values of IP Address, Host name, Username or Endpoint ID.
5. Recommendations
A set of actionable mitigation step(s) that can be performed by the client to mitigate the threat and bring it to closure.
The Recommendations might not be the only way to mitigate the threat. Rather, they provide a suggested approach from the SOC. Ultimately, the choice of the most appropriate mitigation approach rests with the client. When performing mitigation, it is also necessary to understand risks associated with mitigation actions, as there could be impacts on availability and in some cases even data loss could occur. These kinds of impacts may either be known side-effects of mitigation or there may be potential risks associated with errors which could occur during mitigation.
6. MITRE ATT&CK
To make it easier to understand the threat and perform additional mitigations actions, we will categorize a threat according to a tactic in the MITRE ATT&CK IT and OT framework.
A threat can be categorized in multiple MITRE tactics. We will only reflect the most severe tactic.
For more details about MITRE ATT&CK tactics:
- IT: Enterprise Matrix
- OT: ICS Matrix
Reflecting the MITRE tactics, gives the client the possibility to use MITRE techniques to do additional threat hunting and mitigation.
7. Incident Summary field 1 + 2
Summary of the relevant threat in this report.
8. Device
Always RTENGINE.
9. Attack Origin
How was the attack initiated? Did a user visit a web page, get an email, insert a USB, etc.
10. Labels
Predefined tags the SOC can add to a ticket with explanation. These might reflect a malware family, a general description, functionality, etc. A report could have zero, one or multiple labels.
11. APT (Advanced Persistent Threat)
The threat is an APT. If the Security Analyst conclude that the threat is an APT, the APT symbol is enabled in the report.
12. Leakage
Leakage of sensitive client data detected. The Leakage symbol is enabled if the Security Analyst verifies sensitive data leakage during investigations and threat hunting.
13. MDR ticket #
Reference to the Help Center ticket number.
Page 2- Detailed threat information
The second page presents Incident Details with Attack Stages, a graphical presentation of the threat (attack) with IOCs, and the start of the detailed Incident Description.
14. Incident Details
Graphical representation of the threat (attack) that the SOC is reporting. The graphical representation varies from threat to threat, hence the sample is just one out of many.
15. Attack Stages
The Attack Stages are linked to the stages in the graphical representation. The section will list the values (IOCs) used in the attack and will indicate how the SOC has seen the IOC, either as
- DE – Detected: As an accept log record or alert or
- B – Blocked: As an blocked log record or alert or
- N – No Log Data: No traces in logs or alerts in scope. However, a later stage could not have happened unless this stage happened.
16. Incident Description
This is the most important part of the Security Incident Report. In this section, the SOC describes the relevant threat and describes why this poses a risk. The description includes steps and findings done through the analysis process where the SOC has used enrichment data and performed Threat Hunting and correlation. The SOC will add evidence data to support the findings.
In general a report will contain:
- Description
- Why the threat poses a risk
- Analysis
- Evidence in form of either a log or PCAP (evidence) exempt.
The Incident Description can be short or extensive depending on the what's needed to accurately describe the reported threat and associated risk. In this sample, the Incident Description spans over 3 pages, but in other cases it could require only 1.
The purpose is to clearly describe the threat that poses risk to the client.
Page 3 onwards - Threat details continued
A Security Incident Report can be on 1 page or multiple depending on the amount of information which needs to be provided in order for the client to understand the threat and risk.
16. Incident Description
As above.
Final Page - Alerts that have contributed to the Security Incident Report.
17. Alert Data
A detailed list showing sources and alerts triggered which contributed to the identification of threat that is reported in this Security Incident Report.
The sample shown here is for 1 alert. If multiple alerts have contributed, there will be multiple sections on this page.
Security Incident Report Version updates
If a threat changes, emerges or new relevant info is available, a new version of the report will be created. When the client receives an updated report (i.e. new version), there will be revision marks on changes and all new text in the Incident Description will be appended to the existing description.
Changes in the report are tracked and highlighted to make it easier and faster to read up on the new version.
Only NTT Security Holdings can update the Security Incident Report.
Field changes are updated and indicated in Remarks. This makes it easy to see what has changed in the other fields than the Incident Description field. If there are only changes in the Incident Description field, the Remarks section just states The reported threat is still observed.
Incident Description updates are appended at end of the text giving a clear demarcation on the newly added text. This means that you will only need to read the new text which has been added, making it easier to understand what has been changed or added since the previous version of the report.
Comments added to the Security Incident ticket will not be added to the Security Incident Report. It will nevertheless contain valuable information in order to truly understand what has occurred.
Comments
0 comments
Article is closed for comments.