Overview The post-incident activity (a.k.a Post Mortem ) is a crucial step in the incident lifecycle process - it provides in-depth understanding from an OPSEC perspective, allowing a more adequate and focused response plan, but despite its importance, it is often conducted improperly, leading to loss of evidence integrity and inconclusive investigations. So, what aspects should not be overlooked?

1. July, 2021
Key Investigation Aspects
for Information Security
Creative Commons

2. The post-incident activity (a.k.a Post Mortem) is a crucial step in the incident lifecycle
process - it provides in-depth understanding from an OPSEC perspective, allowing a more
adequate and focused response plan, but despite its importance, it is often conducted improperly,
leading to loss of evidence integrity and inconclusive investigations.
So, what aspects should not be overlooked?
“Those who don't know history are doomed to repeat it.” ― Edmund Burke
Overview

3. Ok, you implemented the
required controls, your
team were ready. But the
evidences were not
admissible in court.
Understanding the problem
I. Lack of Controls
After an incident take
place, you regrettably
might discover that you
don’t have enough audit
trails to pursue an
investigation.
II. Lack of Preparation
Deal with tough decisions
in the heat of an
information security
incident might not only be
difficult but
counterproductive as well.
III. Lack of Preservation

4. After an incident take place, you regrettably might discover that you don’t have enough audit trails to pursue an investigation.
It is always important to consider:
● If you don’t detect, you can’t respond. Make sure the security architecture has enough layers, offering sensors and audit logs - if you use a solution
such as a SIEM, you can increase the correlation and alerting efficiency by configuring the data sources based on those layers. Keep an eye on
access and behaviour. Identify company’s “Crown Jewels” for better (risk based) results.
● Not only logs are necessary, but it should follow the proper standard. A logging standard procedure is the very first step in order to define what to
log, the required pattern and its retention period (i.e. timezone, auth data and etc). The criteria should follow infosec and regulatory features (i.e.
GDPR / LGPD). Make sure logs are stored properly, preventing tampering or unauthorized access (non repudiation principle).
● Over time, a control is just effective if you are able to measure (CE). While you can support governance using a variety of threat/risk modeling
frameworks (FAIR is one of them), you need to understand that the solution must be designed considering the “technology, process and people”
tripod. Rather than searching around for frameworks, first understand what problem you want to solve, your context and then check what the
industry can offer (i.e. COSO framework for enterprise internal controls, CIS for cyber defense guidelines and etc). We are fortunate to have a
lot of options up our sleeve, but focus on the problem, not the framework.
Understanding the problem
I. Lack of Controls

5. Deal with tough decisions in the heat of an information security incident might not only be difficult but counterproductive as
well. Some notes to keep in mind:
● The clock starts ticking. Time is key, so operational efficiency is mandatory. Make sure you have the incident playbooks/runbooks ready (and
tested - always aim to reduce the response time). Governance routines like a Business Continuity Plan / Disaster Recovery Plan is always a good
way to go on your security roadmap.
● Consider having a CSIRT and a CERT, nonetheless, you must educate the personnel on a wider security culture program and awareness
campaigns. They should understand and perceive, at least, basic infosec aspects; how to identify certain threats and how to report them.
● ITOps staff among other strategic business units must receive a resourceful training on how to deal with certain incidents, specifically, how to deal
with evidence (collect, maintain - we will see more on our next slide “Preservation”). These guidelines must be clear and remarkably available.
Understanding the problem
II. Lack of Preparation

6. Ok, you implemented the required controls, your team were ready. But the evidences were not admissible in court. What was
missing?
● Cybersecurity Forensics lesson #1: Preserve the evidence. Train the necessary personnel on how to collect evidence without data loss or risk of
tampering. Use chain of custody documentation and remember to keep it updated.
● Safeguard/Protect physical and logical evidence - e.g. a very common mistake is shutting down a compromised computer and losing useful volatile
data stored in RAM; there is less intrusive ways to gather evidence and this must be done professionally, with the use of forensic tools (i.e.
sleuthkit/Autopsy, FTK, Volatility, Encase, etc). For some documents, images and screenshots you might benefit using a notarial act as written
evidence. In addition, the evidence and investigation assets must be stored at a secure and restricted location.
● Create a timeline and document every step of the way. Date and Time, Locations, Assets (by unique ID), People involved. Also, make sure to keep
track of the important decisions that led your investigation. Always use probability in favor on your decision making - It is important so you can
rethink your steps or help people understand the rationale that was used.
Understanding the problem
III. Lack of Preservation

7. An investigation must be confidential - Always keep track to whom the information was
disclosed - If there is an NDA in place, if the people are aware of the sensitivity of the topic.
You must control the communication channels as this might affect the outcome of the
ongoing investigation.
This also applies for discussing about the investigation in public or using insecure devices to
access case information, which might lead to a security breach.
Keep in mind

8. What about some
theory
Forensic science attributes evidence
generation on the crime event the process
of
● Identification
● Classification (or individualization)
● Association
● Reconstruction
(K, Inman; N, Rudin)
You can follow these principles to structure
your investigation and your report.

9. What about some
theory
Cause of Action
Materiality
Admissibility
Relevance
Reliability
Evidence
Evidence information can be used for
reconstruction and causality

10. Know your case
Regarding the Incident
● Given an OPSEC standpoint, was this a targeted
incident? Was it isolated or a chain of events?
Discover the pattern and the objective.
● Use your Threat Intel team as a valuable resource
(if you don’t have any Threat Intel Platform, I can
recommend you check MISP project. It is an open
source TIP).
● Manage expectation. It is easy to lose track of the
purpose of the investigation. It might be time
consuming and might end inconclusive.
● Attention to the forensic/investigation report.
The information must be clear - remember, this
can be used as your testimonial and might be
presented as legal evidence.

11. Know your case
Ishikawa diagram (a.k.a fishbone) can
help you understand, document and
present, in a visual way, the causal
event chain that culminated in the
incident.
TECHNOLOGY
PEOPLE
ENVINRONMENT
PROCESS
Event 1.1
Event 1.2
Event 2.2
Event 2.1
Event 3.1
Event 4.1
Event 3.2
Event 4.2
Event 3.3
Event 4.3
3
1
2
4

12. You can have a more technical approach
using MITRE | ATT&CK framework,
depending on your objective and public.
It certainly would allow you to deep dive
and have a more robust and security
oriented perspective about the incident.
Privilege Escalation
Credential Access
Discovery
Collection
Resource Development
Persistence
Defense Evasion
Lateral Movement
Initial Access
Execution
Reconnaissance
C&C
Exfiltration
Impact
Know your case

13. Know your case
Regarding the Subject (criminal authorship)
● If the incident also check as a cybercrime activity, you can benefit by
using profiling techniques, such as motivation (financial, political,
emotional, personal, among others), language analysis (vices, typos)
and any other detail that might give you a hypothesis to work with
(pro-tip: Take a look at the “Hackers Profiling Project - HPP”, and if
you want to go even further on this road, check Ryan and Deci’s
taxonomy of human motivation).
● Know your enemy. Gather information might help you understand
the case, the subject motivations, possible connections and so on. You
can even use social engineering techniques to obtain them - carefully.
● With the collected information, you can create a “dictionary” - a list
with all the relevant terms and words that might help you
individualize the subject / search your environment for connections;
furtherly using the dictionary on your data devices (DLP, web
gateway, email gateway, file server and etc) - Once more, careful to
not let evidence or clues in cache or logs showing to unauthorized
people your query attempts/results.

14. Know your case
Regarding the Subject (criminal authorship)
● You can benefit by using OSINT framework, tools and
resources to enrich your data or find more relevant
information regarding the subject. Always be careful so
you don’t make noise and be discovered first - if the
subject can trace you back or discover that there is an
ongoing investigation, the tendency is that the subject
become more self-aware and might delete evidence / stop
acting.

15. Know your case
Taxonomy Motivations (Dittrich and Himma,
2005, as cited by Akhgar et al.,2015).

16. Know your case
Some tips for your report
● Include complete names (and, if possible, unique
IDs) of the people involved and their role on the
investigation
● Time and date and the used timezone
● Objectives or “tasking” - When, how and by whom
were you tasked. What is your goal by proceeding
in this investigation. You can also delimit your
scope here
● Hypothesis formulation - the evidences and
interviews will later bring assumptions/questions;
here is a tip: you can describe what was the effect
(incident) and possible motivations for the
materialization of that effect (not only what, but
how)

17. Know your case
Some tips for your report
● Timeline (graph) followed by the historic - which is
the list and description of actions taken (text)
● Results obtained (as clear as possible, usually
based on the incident reconstruction)
● Conclusion (usually match with the investigation
objective)
● List of attachments, followed by date of collection
and source (usually, I also register the MD5 hash
of the evidences listed here in order to attest its
integrity

18. Some tips for your report
● Don’t get lost - It’s important to be consistent in
your analysis and the report is a way to show it.
Know your case
Don’t lose track of
your objective
Use the objective
to explore your
hypothesis
Use the hypothesis
to define the
required actions,
creating your
historic
Document the
results of the
actions taken used
on the historic
Write the
conclusion based
on the results

19. While the level of detail of the investigation and report might vary accordingly to the
potential loss based on risk (financial, operational, strategical, reputational and so on), it is
important to emphasize that you should consider and invest your effort not just on this phase, but
considering the whole picture - in this case, the incident lifecycle.
More importantly, the infosec role is not only conducting the analysis and delivering the
forensic report, but leading the required initiatives for risk remediation, constantly working on a
better security posture towards the organization.
The most important part begin with the report.
Conclusion

20. Thanks
Rodrigo Sozza
Infosec | Cybersecurity | Forensics