Saturday, November 13, 2010

Quick introduction to Network Security Monitoring

Network Security Monitoring  is the area of Information Security I love, Unix systems apart, and I always wanted to write about this methodology since I started this blog :)

Many of the concepts I am going to talk about are better explained in the awesome book from Richard Bejtlich entitled The Tao of Network Security Monitoring: Beyond Intrusion Detection.  You can find more information about his book in his website.

The idea behind NSM is that Network Monitoring is not just a matter of deploying an IDS or IPS in the network. When an alert is generated, the only information we have is a rule and a small packet capture with the bytes that generated the alert.

The questions here are: Do we have enough information to confirm whether this was an attack or not? Was it successful? Can we easily track the activities performed by the attacker in our network?  The short answer, is we do not know! We do not have enough details to perform an investigation.

NSM is a methodology that tries to solve this problem by offering the data that an analyst needs to perform the investigation. I will not explain all the details, because it is too long for a blog post, but I will try to briefly explain the main concepts.

Full content data

It is easy to understand that, in an ideal scenario, a full packet capture of the traffic generated by the attacker should be enough, because it contains all the details of the activities performed by the attacker in our network.

With this data, we can confirm if an attack was successful and if the attacker went deeper in our network. Furthermore, we can obtain the tool-kits that were downloaded to the compromised server. The attacker can try to fool a forensic analyst that is analysing the compromised computer, but it is not possible in network comunications.

Session data
Unfortunately, full content data does not escalate.  An analyst cannot easily perform an investigation with huge amounts of data and it is even worse when the task is in real time. Session data helps to solve this problem because it is just a summary of the traffic that passed through our sensors.

An analyst can quickly track the attacker by applying filters to the session data and then going to the full content data when it is needed. At this point, the available data consists of all the communications at the transport layer, without the content of the packets. This includes: IP addresses, protocols, ports, flags. etc..

Statistical analysis and external indicators of a compromise
Having a good base of our network and equipment helps to detect unexpected changes that may be caused by an incident or an intrusion. It could be: high network traffic, servers under high load, etc.

Sometimes, this statistical analysis can be complemented by other indicators like: servers or routers crashing, people complaining that an application is not working. etc.. Perhaps intelligence and information gathering can be also added here: third party companies/institutions complaining about attacks from our network, a post in Internet saying the we were compromised, possible active threats. etc.

Intrusion Detection Systems
In practice, an human cannot spot an attack in real time just by looking at the generated data. We need a tool that automates all this process and the analyst will only validate the alerts with the available data, as already explained. In case an incident is ongoing, the analyst will escalate the alert to the CIRT (Computer Incident Response Team).

It is important to notice that we are using an IDS (Intrusion Detection System) and not an IPS (Intrusion Prevention System). Our goal is to gather enough information to understand the attacks and act accordingly. The IPS will block a possible attack but we will miss the full picture of the incident.

No comments:

Post a Comment