An alchemists view from the bar

Network Security Alchemy

Leon’s tips for Ips event classification and analysis

leave a comment »

… and more tuning ideas

So here I am, stuck in another hotel bar, this time at the dark-end of Cornwall, sipping (carefully I may add) at the local tipple (Skinners Press gang cider). I have been taking some time to sift through snort forum postings and following the discovery of the normal “what the hell do I do about this alarm” calls for help, I thought I would take time-out to compile a list of top-tips to  better deal with intrusion alarms.

We all know the situation, you are being alerted to new “stuff” happening on the network, you don’t recognize the alarm as obviously bad, or even obviously dismissible and are desperately trying to work out how much, or even if you should be concerned.

There are certain things you can do to enhance the process of dealing with and understanding new alarms you haven’t any experience in, and due to the shifting threat spectrum (/me slaps self around the face for extreme buzzword abuse, and to mitigate the effect of the cider) new alarms arrive all the time.

Without wanting to write a book on incident analysis, ill split this over a couple of blog postings as some of this advice is conceptual and some introduces methods of approaching the problem, and other tips are tool specific.

First, the bleeding obvious (if you don’t do this already, pick up your security hat and coat and head for the door).

Understand the alarm.

This is such an important point that I must state it even though it sounds obvious. What does the event message really represent? Be sure to read all documentation associated with the alarm. If your IDS is Snort, and used the VRT rules, you have luck on your side as Nigel does a good job of writing and keeping rule documentation current. It is essential that you understand what the writer of the rule wanted to bring to your attention. Your reaction should vary depending on what has occurred, and one hopes that they would have attached a realistic event message. If you consider a regular server-side attack, all of the following may be raised in separate alarms associated with a single flow.

Access, or discovery of a potentially vulnerable system on the protected network
Exploitation of a vulnerability
Discovery of a specific exploit
Malformed network packets
Successful attack response

One of the things that you should have in your favor (and unfortunately, or rather shockingly, this isn’t always the case with many commercial tools) is the ability to look at the detection “source”. This provides an undeniable method of knowing what was being searched for, and may yield more clues to the writers intent (if not already obvious).

Understand the source and target devices in the context of the alarm.
Is it an attack response coming from your network? or someone else’s? How this is evaluated is specific to the event.

Take a look at the packet(s) that raised the alarm for supporting evidence of suspicion.

Without access to the packet that triggered the event(s) you’re dead in the water here and you are flying blind. Was this alarm real or a “programming error” on behalf of the detection system. Take a look at the decoded packet, inspect it, check for the presence of supporting evidence that the alarm may be real. A NOOP sled or a shell call are trivial examples.

Understand the quality of the rule/signature that generated the event.
Check out how the rule was written, if your IDS doesn’t provide you with the detection source, you are dead in the water. Being able to justify WHY an event triggered a rule is imperative.

The slightly less than obvious … the “C” word.

Understand the alert in the context of the systems involved.
To qualify the potential impact of an “attack” against a target system we need to know what the target system is. In turns out that this can be a harder job than discovering the attack itself, evaluate the alarm against the Operating System, Services, and applications provided by the target.

Evaluate the event in the context of the organization.
What was the “application” being attacked. By application I refer the the purpose of the target system in the operation of the organization. IIS alone means nothing, what is being served over HTTP from this device, and how does it’s compromise effect the operation of the company.

Following the completion of this process TUNE! Can you automate this effort the next time this event is raised on …
This target
A group of targets
Your whole network


Written by leonward

May 2, 2008 at 6:01 pm

Posted in Security

Tagged with ,

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: