Incident analysis methodologies

In the past I researched for analysis methodologies in order to ascertain if the incidents flagged up by the security systems were true positives however  I could not find much about it. I was looking for a set of processes or steps that I could repeat over time and that lead me to a conclusion about the alerts I had in front of me. Some days ago I finished reading the book,

The applied network security monitoring – collecction, detection and analysis by Chris Sanders and Jason Smith

in which the author describes how based on his past experiences he have not came across many analysts who follow a set of steps and rules to investigage incidents. Instead it seems the process varies from analyst to analyst however for my surprise the author explained 2 anlysis methodologies that can perfectly used to determine the most likely cause of an incident.

There are 2 very well known analysis methodologies used in other fields out of security. The first field is associated with the police investigations and the analysis method is known as relational investigation. The second field is the medicine field in which it is used the differential diagnosis method.

The relational investigation is based upon defining linear relationships between the entities involved in an incident. This type of investigations relies on the relationships between clues and individuals associated with the crime scene. A network of computers is not unlike a network of people and everything is connected making possible to analyse the relationsips and actions happening among them to get a full picture of what it is occuring during an incident. The process described by the relational investigation is the following


The best way to see this method is with an example. Let’s consider the following scenario,

We have received an alert coming from the IDS sensor alerting on potentially bad traffic being transmitted between and external IP address ( and a local IP address ( It seems that the traffic which has been flag up is http traffic and it happened while the local IP address was navigating the internet. Together with the alert we were provided with a packet capture file.

What are the steps to be taken if the we use a relational investigation approach?

STEP1: Investigate the primary subjects, perform preliminary investigation of complaint. To accomplish this first step we have to collect friendly and threat intelligence related to both hosts. An example of this sort of information could be for the internal host information such as OS of the machine, process, services and port running and web browser type and version. An example of tactical threat intelligence for the hostile external IP could be to determine if this IP has communicated with other internal IP an check external reputational IP list to ascertain if this IP is known to be malicious.

In our particular scenario we gathered the information related to the internal machine and we detected a Windows Vista machine, also a port opened that is not within the baseline for that particular machine and an outdated Windows explorer browser. On the other side analysing the hostile IP we found an internet record with that IP blacklisted.It seems to be known as an IP hosting a webserver serving malicious executable files.

STEP2: Investigate primary relationship,investigate current interaction. In this stage with study the communication between our external IP ( and our local IP ( To do this we download around 10 minutes before and after of packet data to understand the nature of the communication. Inspecting this communication in detail it seems the user was redirected from a third party website and the user landed in a page showing false antivirus scan results and asking the user to download and execute the malicious executable to update the antivirus. The exe file was carved from the pcap file and analyzed by Cuckoo sandbox to perform automated malware analysis. The analysis triggered malicious behaviour for that executable file and classified as a Trojan. It seems this trojan is connecting to a remote IP address in Internet which we are calling (R.R.R.R). The connection is through the previous port detected and out of the normal baseline for that endpoint. At this point we have exausted the investigation of the primary subjects and the relationship between them and we can confirm this is a real incident.

STEP3: Investigate secondary subjects and relationships, investigate relationships between primary and secondary subjects. Now it has been indentified a third subject which is the external IP our trojan is communicating to. It is important here to collect hostile information from the IP to understand the subject and the potential relationsips with it. Doing a publick search through different OSINT sites in internet we found that this IP  (R.R.R.R) is part of a set of IP that are involved in different versions of this trojan and therefore blacklisted. Also we dig down into the IP address relationship with  the rest of our network and we found multiple IP addresses inside our network which also are connecting with that blacklisted IP address (R.R.R.R)

STEP4: Investigate additional degrees of subject’s relation. At this point we investigate these other endpoints in the network and we  detect exactly the same behaviour and therefore we can conclude that there are other IP’s compromise in our network.

In this last scenario and through relationship analysis we were able to understand and ascertain if the compromise ocurred or not but also extend the investigation beyond the initial alert through the relationship of the different entities. This a methodology that can help any analyst to get from A to Z withouth getting lost or overloaded with information during the process.

The next methodology is the Differential Diagnosis currently used in the medicine field.


A doctor will typically look at a set of symptoms a patient presents and he will create different hypothesis of what could be wrong. Through the differential process he will rule out or shorten the list of candidates to determine what is the most likely cause of discomfort for the patient. The differential method is based upon a process of elimination. It consists of five
distinct steps, although in some cases only two will be necessary.

Let’s see the method through a quick example,

STEP1: Identify and list the symptoms. The following symptoms were detected through the IDS an firewall alerts.

  • A web server in the DMZ is receiving massive amounts of inbound traffic
  • The inbound traffic is unreadable and potentially encrypted or obfuscated
  • The inbound traffic is coming to multiple destination ports on the internal host
  • The inbound traffic is UDP based

5 minutes after the initial symptoms were triggered by the IDS the firewall and data leak prevention solution alerted of attemps to get classifiedd information exfiltrated from a segment in the internal network.

STEP2: Consider and evaluate the most common diagnosis first. In this scenario the most common diagnosis would be a DDOS attack. Analysing the current traffic volume with what is considered the normal traffic for that server we found out that we are receiving 40% more of traffic that in the baseline for this server. For the sake of this example we are going to continue the analysis as we also have the DLP solution flagging up alerts.

STEP3: List all possible diagnoses for the given symptoms.Let’s list what are the potential candidates, there may be but we will only list some of them.

  • Denial of Service
  • Normal Communication
  • Misdirected Attacks
  • Misconfigured external infrastructure
  • SPAM mail relay

STEP4: Prioritize the List of Candidate Conditions by their Severity. The order of priority will vary with the organization’s risk profile. On generic terms let’s define the next order,

  1. Denial of Service
  2. SPAM mail relay
  3. Misconfigured external infrastructure
  4. Misdirected attack
  5. Normal communication

STEP5: Eliminate the Candidate Conditions, Starting with the Most Severe. The fact here is that we are under a DDOS attack and therefore we can not rule out our first hypothesis. Doing additional research we rule out 2 and we suspect that it isn’t either 3 and 4. We keep researching and looking at the time of the incident, during the night we can consider is not normal communication either.

Making a diagnosis: could it be that a DDOS attack has been directed against us to distract security personnel and exfiltrate sensitive information? based on the evidences it is the most likely hypothesis having ruled out most of them.

These 2 analysis techniques should definitively be in the analyst arsenal to detect and investigate incidents and of course, all packets are innocent until proven guilty.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s