Writing a Report on a Security Incident

Reports must be written in a certain standard; the reader can guess whether the information they want is in the report or not without reading the report and can quickly reach a result they are looking for in just a piece of information.

For example, if a breach were to happen, the administrator should be able to go to the relevant section of the report, such as the root cause and be able to determine it in minutes.

So what elements are important in a report?

1. Intelligibility: If a report were to be sent to the CEO of a company, it should not contain technical details regarding MITRE techniques or tools used by the APT group; therefore, a section of "executive summary" must be created without mentioning technical jargon while keeping the events in a summarized manner.
2. Timeline: The report should be written in accordance with the timeline of events. It should include what the SOC team did step by step with timestamps included. The reader should be able to visualize the timeline of events in order of occurrence and should not have any doubts about what happened in between those events.
3. Repeatability: Technical details in the report should be written in a way that can be repeated or reproduced. Let's say you found malware in a certain section of the server. You should align steps on how to replicate these findings, so should this event reoccur in the future, the reader must know how to come to the same conclusions.
4. Focus on a single subject: The subject of your content should be fixed; do not go off-topic or add in unrelated information to the event.

What styling should I use?

• Write the report in the past tense; remember that the event is in the past.
• Utilize short and concise sentences; remember, this is a report, not a novel. The reader must be able to quickly pick up on the content, so keep your sentences short.
• Focus on what you do; do not include things that were not done, only write things that were done during the event.

Ex: Memory analysis could not be performed due to the server being restarted.

• Be careful with abbreviations: IOC, IDS, IPS, AV, EDR, etc. Some may sound familiar to you, others not so much. The reader may not know all the abbreviations for tools and frameworks; be sure to include the full wording at least once initially, and then you may utilize abbreviations throughout the report.
• Consistency If you are using "host", keep utilizing "host", If you are using "endpoint" keep utilizing "endpoint". Avoid using different synonyms, as this may confuse the reader.
• Date & Time: Keep the same time & date format throughout your report for consistency.
• Font "Comic Sans" should be avoided; to keep consistency, you can mix up different font titles but the same font paragraphs.
• Bullet points & lists: utilize these to avoid paragraphs.

What report structure should I use?

1. Table of Contents: This section should specify the content of the report, the titles, and the page numbers of the pages specified. If any section of the report is to be reached directly, this is the purpose of this section.
2. Incident Background: This section will explain how the incident was detected, who detected it first, what was detected first, and what actions were taken. It needs to be 2–3 paragraphs, short enough to fulfil an explanation.
3. Findings This is the section where the findings we detected during the investigation will be explained.
4. Recommendations: Short- and long-term recommendations will be shared regarding the incident in this section. Patching vulnerabilities would be a short-term solution, while perhaps an EDR would be a long-term recommendation.
5. Timeline: This is the section in which the event is sorted by time. There is no need to include details of the events; just focus on the important parts. The aim is to provide insight into how the event evolved; remember to utilize timestamps.
6. Appendices This is often used for long listings; if the list needs to be more than one page and affects readability, it can be included in this section.

Ex : Port Scanning List , IP List that was attacked.

In summary, effective report writing hinges on clarity, consistency, and focus. A well-structured report should be easily navigable, allowing readers to quickly find key information like the incident timeline and findings. Use concise language, consistent terminology, and avoid unnecessary technical jargon, particularly when addressing non-technical audiences. By following these guidelines, your report will not only inform but also facilitate decision-making and future action.