Why should we have clear objective(s) in Incident Analysis?

Incident Analysis (IA) stands as the cornerstone of understanding and preventing accidents, security breaches, and unexpected events that often disrupt the functioning of organisations. The efficacy of any IA largely depends on the clarity provided by well-defined objective(s). Thus in today’s article, we shall delve into the importance of establishing them.

While the significance of objective-driven analysis may seem apparent, a deeper exploration reveals a profound impact that extends beyond what most would practise. It’s paramount that we’ve to understand why defining an objective is so important to appreciate the benefit of doing so.

Imagine this — you’re in a dense forest with only a compass, will you be able to navigate your way out of the forest?

Similar to the mentioned scenario whereby the compass serves as a guide to help you get out of the forest, having clear objective(s) serves as a guide to investigators to identify the root cause of the incident.

However, the bigger question is not whether we make an objective, but rather, do we have good objectives that lead to good analysis eventually? Referring back to the scenario about having only a compass in a dense forest, we may know how to use the compass but do we know what to do with it with efficiency?

Defining good/clear objective(s) is like a way of equipping yourself with the tool(s) to interpret what happens in front of you. As a practitioner in the field of IA, we need to have commanding knowledge of both the situations and the tools to be effective.

Generally we follow these processes when an incident happens:

Imagine if we aren’t careful in defining good objective(s), what would happen if someone asks you to prove a negative? For example you may be trying to determine if a system has not been compromised (a negative). It’s a very difficult, if not, impossible task.

It’s very unlikely you have access to all the information you need to prove that point since most systems do not have full audit trails of every transaction that has happened and waiting for your review. Besides, log files have limited space, get overwritten, have limited retention time, etc. Unless it’s a superb life-critical system, most systems will not spend that kind of money to maintain a system with full audit trails and hence, it’s impossible to prove a negative objective.

More example of negative objectives are as follow:

• Is my system compromised?
• Is my system free from malware?
• Is my system safe from hackers?

It’s often crucial what objective(s) is/are defined, though this may seem unimportant at first. It is critical to the success of the investigation!

Going back to the “Is my system compromised?” objective, it’s most likely that either some evidence of the past events of the system never existed or is lost over the time. Thus, you can never 100% prove if your system has/ hasn’t been compromised.

Instead, you can redefine it to a better objective such as “Do we have any indicator of compromise?”. This would have better directed the investigation to deep-dive into the indicators of compromise and state, which are more reasonable. It also provides reasonable confidence in answering that question and high confidence on the analysis that has been performed on the supporting factual evidence which uncovers no evidence of malware.

Citing another example which is commonly found in our practice of work — when there’s a malware infection incident happening, we often define the objective of incident analysis as “whether there’s malware present in all our computers?”. This may seem simple but it’s not easy to answer at all! A lot of effort may be spent in looking for the malware in each computer, but still, there’s no guarantee that no spots are missed.

Instead, we should redefine the objective as:

“Is there any past or active transaction that happened in our system with malware hash d84728asdklhahk2309420498r2039570e?”

In this case, we can then easily place the necessary steps with a much higher confidence level with a much simpler analysis steps to check for matches.

It’s natural human behaviour to take things as surface initially, but we hope this article provides some insights on why we should actually take some time (at the start of analysis) to redefine better objective(s) that can lead to a much better outcome.

While it is unconventional, the practice of conducting IA with well-defined objective(s) can be a valuable and thought-provoking exercise; it encourages investigators to embrace complexity, certainty, and pave ways for anticipated discoveries and holistic insights. By adopting this approach, organisations can foster adaptability, creativity, and open-mindedness amongst their analysis teams, enhancing their capacity to address incidents that defy straightforward categorisation.

Ultimately, the importance of setting clear objective(s) in IA cannot be overstated. It serves as a guiding light, leading investigators towards uncovering the root causes of incidents, promoting a culture of learning and improvement, and enhancing overall organisational resilience.

By knowing and acknowledging the significance of well-defined objective(s), organisations can unlock the full potential of IA as a tool. (̀ ͜ʖ ́❛)✊

🧙🏼‍♀Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.