The reason I find this security challenge interesting is that it brings together two distinct threat and concern types; one of voice communication services and one of IP networks. Those implementing or maintaining a VoIP network are commonly from one of these two backgrounds, and therefore may initially see only half of a security objective.

Stock IP threats

These are the concerns that are picked up by the regular IP networking person and probably the threats that they think about daily. For example;

• Remote Code Execution
• Denial of Service
• Traffic interception

Because the Voice platform is now on an IP connected and integrated network, all of these now also exist in your voice infrastructure. In fact, all of these concerns existed before, however inward connections were far more limited than on your nice new VoIP system and attacks were less likely.

Voice specific threats

Those who maintain large non-IP voice networks have similar problems keeping them awake at night. Commonly these concerns fall into one of the following categories:

• Service theft (toll fraud)
• Evesdroping (wiretapping)
• Service Disruption / Outage (read Denial of Service)

The most common VoIP signalling protocol I see in use  SiP, and it is pretty simple to understand from an observers point of view. This means that it IP based security threat monitoring tools could be converted to the voice world, IDS/IPS on VoIP networks could offer discovery and mitigation of both traditional IP network threats along with the voice specific. I recommend that those maintaining a VoIP infrastructure take a look at a modern IDS system to determine  if it can help them discover and protect against many of the threats that concern them.

Snort obvoiusly has a bucket of rules specific to voice networks put together by the Sourcefire VRT, and there are also additional offerings from the Bleeding Threats.

Over the last few weeks, I have seen a couple of posts to the Snort forums asking for help to get Snort 3.x up and running. It is good to see that others are interested in testing the engine, and unfortunate that there is such a steep learning curve to get to grips with the new way that Snort, and the Snort Security Platform now work. I have a hunch that after a little effort in learning the new methods it will all soon seem like second nature to all of us.

I thought I would share the steps I went through to get Snort 3 running on a test VMware virtual machine in the hope they can help out others.

My base OS is Ubuntu jeos, a stripped down build of Ubuntu designed and optimised for running in a VMware instance, the below instructions should work for pretty much any Debian based OS and let me know if they don’t!

The Jeos installation leaves me with a minimal Ubuntu system, comparable to Debian “base” , so to build anything on top of this we need to install some extra packages.

Before we try to install and configure the Snort Security Platform along with the Snort 3 analitical engine, lets make sure that we are able to get snort 2.8.2.1 (the latest stable 2.x release at the time of writing) working on our device. This extra task will save us a LOT of time later.

Building and installing Snort 2.8

Firstly I want to access this device via ssh, so a ssh daemon is required along with some other basic tools

sudo apt-get install ssh wget

We need all the key components to allow us to compile code, the build-essential meta-package will install all of these for me.

sudo apt-get install build-essential

To build Snort from source, we need to install some key libraries and development headers that it requires. libpcap is the promiscuous packet capture library, it is used by Snort, wireshark, tcpdump etc to capture network traffic.

sudo apt-get install libpcap0.8 libpcap0.8-dev

Snort supports PCRE for matching data within packets and data streams, therefore we need to install the required libraries and header files.

sudo apt-get install libpcre3 libpcre3-dev

Once Snort’s dependancies are installed, lets get the snort 2.x source and install it.

wget http://snort.org/dl/current/snort-2.8.2.1.tar.gz
tar -zxf ./snort-2.8.2.1.tar.gz
cd snort-2.8.2.1
./configure
make
sudo make install
sudo mkdir /etc/snort
sudo cp etc/* /etc/snort

We should now be in a position where Snort 2.8.x is ready to be configured for use, lets check its availability with a snort -V to check.

snort -V

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.2.1 (Build 16)
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2008 Sourcefire Inc., et al.
           Using PCRE version: 7.4 2007-09-21

Before we can test Snort in any way, we need a few more things, some rules, and some test data. How you access the Snort rulebase is dependant on whether or not you are a Snort rule subscriber, and what level of subscription you have. for this simple test we dont need the latest and greatest rules from the Sourcefire VRT (Vulnerablity Researh Team) like if we were running a real sensor, but we need a modern set of rules that will work with a 2.8 engine.

Go and register an account on snort.org, and download the “registered user release”, or use whatever ruleset you have handy for a 2.8 engine. Put the rule files into /etc/snort/rules/

<get hold of rule tarball>
tar -zxf snortrules-snapshot-CURRENT.tar.gz
sudo cp -r rules/ /etc/snort/

We now need to set the “RULE_PATH” variable in /etc/snort/snort.conf to point to /etc/snort/rules. I use vi to acomplish this.

sudo vi /etc/snort/snort.conf

After editing, the line should look like this

grep "var RULE_PATH" /etc/snort/snort.conf
var RULE_PATH /etc/snort/rules

Lets not give snort a test

snort -c /etc/snort/snort.conf -A fast -l /tmp -T

This command tells snort to start up in IDS mode reading /etc/snort/snort.conf. The output mode is “Fast”, logging will be to the /tmp directory, and to simply test the config and exit.

You should see an output a little like this:

        --== Initialization Complete ==--

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.2.1 (Build 16)
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2008 Sourcefire Inc., et al.
           Using PCRE version: 7.4 2007-09-21

           Rules Engine: SF_SNORT_DETECTION_ENGINE  Version 1.8  <Build 14>
           Preprocessor Object: SF_DCERPC  Version 1.1  <Build 4>
           Preprocessor Object: SF_FTPTELNET  Version 1.1  <Build 10>
           Preprocessor Object: SF_SMTP  Version 1.1  <Build 7>
           Preprocessor Object: SF_Dynamic_Example_Preprocessor  Version 1.0  <Build 1>
           Preprocessor Object: SF_SSH  Version 1.1  <Build 1>
           Preprocessor Object: SF_DNS  Version 1.1  <Build 2>
           Preprocessor Object: SF_SSLPP  Version 1.0  <Build 1>

Snort successfully loaded all rules and checked all rule chains!
Snort exiting

The below pcap is one I commonly use for testing an installation, it contains some obvious attacks from about 2001. I host it here to make it easy for me to find.

cd /tmp
wget rm-rf.co.uk/downloads/Honeynet-RFP-iis.tgz
tar -zxvf ./Honeynet-RFP-iis.tgz

Now we have Snort configured (using the term losely), and a pcap to test snort with, lets give it a run.

snort -c /etc/snort/snort.conf -A fast -l /tmp -r ./Honeynet-RFP-iis.pcap

If successful you should have a file in /tmp/Alert that contains lots of alarms, and /tmp/snort.log.<timestamp> that contains the pcaps of the detected events.

If you do, lets move on to building and installing snortsp.

Building Snortsp 3.0Beta

The Snort security platform has other requirements for building on top of the above that were needed for Snort 2.x

Libnet and libdumbnet provide low level packet creation and modification libraries. Note that libdumbnet is the Debian name equivalent of libdnet in other distributions. The curses libraries handle screen and terminal manipulation, Libreadline provides history and tab completion for terminal commands to improve the user interaction expience with a shell. Lua is the new scripting language used in the Snort Security Platform, flex and bison are more modern replacements to lex and yacc. A UUID (universally unique identifier) generator is also now required for SnortSP.

sudo apt-get install libnet1 libnet1-dev \
    libdumbnet-dev libdumbnet1 \
    libncurses5 libncurses5-dev \
    libreadline5 libreadline5-dev \
    liblua5.1-0 liblua5.1-0-dev \
    flex bison \
    uuid uuid-dev

Now download and compile SnortSP.

Note: At the time of writing snort 3.0.0b2 is the most current release. Don’t use old betas, go grab the latest from snort.org.

cd ~
wget http://www.snort.org/dl/prerelease/3.0.0-b2/snortsp-3.0.0b2.tar.gz
tar -zxf ./snortsp-3.0.0b2.tar.gz
cd snortsp-3.0.0b2
./configure
make
sudo make install
sudo ldconfig
sudo mkdir /etc/snortsp
sudo cp etc/* /etc/snortsp/

Now SnortSP should be installed, not that this is just the security platform and not the snort engine itself. Snort, the analytical engine, needs to be built separately. Before we compile it first check that snortsp works

snortsp -V
SnortSP Version 3.0.0b2

cd src/analysis/snort/

./configure --with-platform-includes=/usr/local/include/snortsp/ \
    --with-platform-libraries=/usr/local/lib/snortsp/
make
sudo make install

The snort engine should now be ready for configuration and use under SnortSP. The challenge we have now it to get it doing what we want.

Start up snortsp to check the platform it is ready for use, (ssp.shutdown() is the command to shutdown the snortsp shell)

sudo snortsp -L /etc/snortsp/snort.lua
[+] Loaded pcap DAQ
[+] Loaded file DAQ
[+] Loaded afpacket DAQ
[*] DAQ Modules Loaded...
[*] Loading decoder modules
[+] Loaded ethernet
[+] Loaded null
[+] Loaded arp
[+] Loaded ip
[+] Loaded tcp
[+] Loaded udp
[+] Loaded icmp
[+] Loaded icmp6
[+] Loaded gre
[+] Loaded mpls
[+] Loaded 8021q
[+] Loaded ipv6
[+] Loaded ppp
[+] Loaded pppoe
[+] Loaded gtp
[+] Loaded raw
[*] Decoder initialized...
[*] Flow manager initialized...
[*] Data source subsystem loaded
[*] Engine manager initialized
Control thread running - 3083479952 (22010)
[*] Loading command interface
[!] Loading SnortSP command metatable
[!] Loading data source command metatable
[!] Loading engine command metatable
[!] Loading output command metatable
[!] Loading analyzer command metatable
Executing /etc/snortsp/snort.lua
   ,,_     -*> SnortSP! <*-
  o"  )~   Version 3.0.0b2 (Build 9) [BETA]
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 2008 Sourcefire Inc.
snort> ssp.shutdown()

Because snortsp is a radically new method of handling data sources and detection engines (such as the Snort analytic), some tools have been provided within the snortsp tarball for porting your old method of starting up snort and having it run within the snortsp. This tool is called sspiffy.sh. This tool was a key element to me getting my first instance of snort inside the snortsp running the packets contained within my pcap through detection, however it wasn’t the simple walk in the park it was supposed to be.

I suggest you take a look at the documentation for this tool and see how you get on, however expect the lua file that it creates to not be perfect, but close. Also make sure that it has write access to your snort.conf. With this in mind, i decided to share my sightly modified lua file, based on the output of sspiffy.sh. It works for me along with this snort.conf. Feel free to hack about with it to make it do what you want.

My snort.lua file (save it to /etc/snort)

My snort3 beta snort.conf file (save it to /etc/snort)

cd /tmp/
wget http://rm-rf.co.uk/downloads/snort3_beta_pcap.lua
sudo cp snort3_beta_pcap.lua /etc/snort/

sudo mv /etc/snort/snort.conf /etc/snort/snort.conf.2.8
wget http://rm-rf.co.uk/downloads/snort3_beta.conf
sudo cp /tmp/snort3_beta.conf /etc/snort/snort.conf

Now lets fire up snortsp using the lua file above, and see how she goes. If successful you should see output like this.

Anyway, I need to spend some more time playing with the tool and less writing all of this. Let me know if I have got something wrong, or if these instructions don’t work for you.

Happy Snortin’

-Leon

Help !!!!!!!!
Snort doesn’t work !
It dies with a “Not Using PCAP_FRAMES” error message”.
Quick, quick help me now!

I’m ranting about this here so hopefully when people google the “Not using PCAP_FRAMES” message before blindly posting to the forums or mail lists for help (I know, I can dream), maybe this post will appear in their search results solving their non-issue.

What is an error message?

Lets look a real error messages first, unlike the above.

--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /this/rules/file/does/not/exist
ERROR: Unable to open rules file: /this/rules/file/does/not/exist or /this/rules/file/does/not//this/rules/file/does/not/exist
Fatal Error, Quitting..

The error condition above is clearly identified, other messages not prefixed with “ERROR” are supporting messages to help a user understand what the system is doing. This rule holds true with most software and not Snort alone.

What is a PCAP_FRAME?

PCAP_FRAMES is an environment variable that is used to pass a configuration setting to a custom pcap library, specifically the code by Phil Woods (Nice job by the way Phil). If you have not built snort against Phil’s libpcap that supports pcap ring buffers in shared memory, PCAP_FRAMES means absolutely NOTHING to you, zip, nout, fsck all, nada.

If you are unsure if you have built Snort against Phil’s libpcap or a stock distribution, then trust me you’re using a stock libpcap.

For those who are interested, PCAP_FRAMES defines a size (in frames) of a pcap ring-buffer in shared memory.

Are you sure? It looks like Snort stops with this as an error.

Yes I’m sure, and I find your lack of faith disturbing. Lets look at the code in snort.c to check.

1163     if( getenv(”PCAP_FRAMES”) )
1164     {
1165         LogMessage(”Using PCAP_FRAMES = %s\n”, getenv(”PCAP_FRAMES”) );
1166     }
1167     else
1168     {
1169         LogMessage(”Not Using PCAP_FRAMES\n” );
1170     }

If the environment variable PCAP_FRAMES is set, it shows the value to user during Snort initialization. If the environment variable is not set, it tell the user that PCAP_FRAMES are not being used.

For example, ill start up snort as a sniffer on my Mac with a stock libpcap.

[09:12:32]lward@drax~$ sudo snort -vdei en0 > /dev/null
Password:
Running in packet dump mode
-snip verbose startup output-

,,_     -*> Snort! <*-
o"  )~   Version 2.8.0.2 (Build 75)
''''    By Martin Roesch & The Snort Team:
http://www.snort.org/team.html
(C) Copyright 1998-2007 Sourcefire Inc., et al.
Using PCRE version: 7.6 2008-01-28
Not Using PCAP_FRAMES
^C*** Caught Int-Signal
==============================================================
Packet Wire Totals:

-SNIP-

Here Snort has started up and was sniffing without error (until I hit CRTL+C), now lets set PCAP_FRAMES to some garbage because it will have no effect on Snorts behavior or my stock libpcap.

bash-3.2# export PCAP_FRAMES="Foo Bar This setting has no impact on my libpcap instance"
bash-3.2# snort -dvei en0 > /dev/null

Running in packet dump mode

--== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
Initializing Network Interface en0
OpenPcap() device en0 network lookup:
en0: no IPv4 address assigned
Decoding Ethernet on interface en0
--== Initialization Complete ==--
 ,,_     -*> Snort! <*-
o"  )~   Version 2.8.0.2 (Build 75)
 ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2007 Sourcefire Inc., et al.
Using PCRE version: 7.6 2008-01-28
Using PCAP_FRAMES = Foo Bar This setting has no impact on my libpcap instance
 ^C*** Caught Int-Signal
 ===================================

So in summary, this verbose message has no meaning to most users of Snort. If you are running Snort as an IDS but not in daemon mode, don’t expect to see anything on STDOUT until you stop the processes (hit CRTL+C to send a SIGINT).

As always, happy Snortin’
-Leon

Firstly let’s don’t not forget that I[DP]S is all about access controls, which controls are implemented are your choice.

a) Tactical threat suppression
b) Business link risk mitigation
c) Security event detection
d) Network audit controls

Tactical threat suppression (Provides a preventative access control)
This is normally seen as the deployment of IPS at key access gateways of a protected network, the policy deployed is set to prevent specific malicious traffic flows from gaining entry. This design meets the “virtual patch” ideas to protect assets from key threats that concern the security team. Think “sploit de jour”.

Security event detection (Provides a detective access control)
Deployment of an IDS to detect network events that could impact the traditional security goals of the network (think network security 101 goals here (C, I & A)).
This is probably the most commonly planned IDS deployment from the out-set, it defines a system that is inspects network data flow, and when a security event occurs a team of analysts is there do their “job”. Following analysis, some form of incident response policy would be followed that should lead to the event being resolved. The main requirement for this type operation is a tuned IDS system to detect events that matter to the organization where something can be done in response to them.

Business link risk mitigation (Provides a preventative access control)
The use of an IPS can decrease the risk associated with a network link, therefore allowing the organization to potentially conduct business with higher risk 3rd party networks. The IPS policy acts as a traffic scrubber to prevent potentially harmful flows from entering the network from less-trusted parties.

Network event recording (Provides an audit control)
Deployment of an IDS that monitors the network for potential security events and supporting information. This is sometimes seen as a failed “Security Event Detection” deployment, where an IDS just logs event data but isn’t inspected by an analyst in anything close to real-time. A report may be run once in a while, but the data is stored for future reference should it be needed.
I see this is as a very valid deployment goal, and those who want “all rules enabled” generally fit into this category.

Problems can appear when designs attempt mix requirements between these achievable goals, for example:

Security event detection + Network event recording:

This combination leads to access and audit controls being enabled in the same policy. Those who are interested in audit requirements commonly want “all rules enabled” and therefore create an un-tunable policy that cannot hope to provide accurate security event detection (read bucket loads of F+).

The methods used to analyze, store, and work with event data may vary across the deployment goals. For example, if a user wants to place a device outside of a firewall to provide audit records, keeping event data in a live event analysis system may be overkill. Maybe a better solution would be an event feed to a SAN in a flat-file system. This would remove the burden to keep event data in an analysis database for real-time access.

Splitting an IDS/IPS deployment into logical chunks, each with specific requirements makes makes a far more manageable and valuable deployment as these goals can be segmented and managed on their own. When I get time I will put more effort into explaining my ideas around this, but in the short term I wanted to throw some ideas out there.

The idea behind this is quite simple, make an assumption that the network is “secure” as it is and operating fine today, then work out how much IPS noise it generates under this normal operation. In the future only alarm on events that have not been previously discovered during the “normal” period.  This type of difference analysis commonly requires a reporting tool that analyses the output from network sensors, but the way that the question was phrased got me thinking about this as a tuning process.

So lets summarize the steps involved to achieve this as a tuning goal.

• Sensor must be deployed into the target network
• Sensor must be run for a period of time to generate an alert “base line”
• The Alerts must be investigated to check that they are all “acceptable” and normal for a network of this type (make sure you don’t accept an already p0wned network)
• All alerts that were raised then need to be suppressed based on the assumption that they have no interest to the analyst now or in the future.
• Sensor must be restarted with a new “suppressed” configuration.

It turns out that this is a simple thing to achieve, and after thinking about it for a while also raises two very interesting points:

• The bulk trade off between F+ and F- . Is there an acceptable ratio, and what is it?
• IDS for forensic use vs IDS for enhancing current security

I will approach both of the above points in another blog entry when I get some time.

Anyway, here is a dirty bit of perl that achieves what the above. It parses Snort’s fast alert output, and creates a suppression entry for each gid:sid that has generated an alarm. The suppression decision is made either on the event source IP, destination IP, or both IPs depending on what type of event is discovered.

For example, it is more common that policy-violations will need to be suppressed on the IP address that was the source of the event, and therefore the source of the “non policy violating policy-violation” that you don’t want to know about in the future (there is logic there, you just need to look for it).

Execution of the script is simple, and instructions are included in the source.

Download snort_alert_autosuppress.pl here.

People commonly expect Snort to provide many systems that are well out of scope of it’s design, including :

• Event analysis UI’s
• Real-time e-mail alerts
• Graphical configuration tools
• The kitchen sink
• Reporting functions

The list goes on …

There are many external tools that provide all of these functions, please remember Snort is a high performance network intrusion detection/prevention engine and not a complete IPS solution alone. Many commercial offerings use Snort as the detection engine but bundle their own management and reporting framework around it, including <blatent plug> Sourcefire </blatant plug>.

Swatch is the most commonly used light-weight method of performing an active response when Snort raises an event, this included sending email. When I teach Snort classes I find that students quickly get to grip with how to use swatch, but still need a hand getting a formatted email out of the system.

To make this a more simple task, i threw together this simple script to provide nice email alerts with impact and advice on how to react to the event.

Let me know if you find it useful.

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

Living things have a natural habitat, an environment where they thrive because it provides all that’s needed for their survival. The evolution, and more importantly extinction of species has shown us that once the habitat of a creature changes substantially, it must either adapt to its new surroundings or it can quickly become extinct.

The natural habitat of a network security device, such as a firewall or an intrusion prevention system is the modern enterprise network. From the outside this habitat looks to be volatile and hazardous where only the strongest technologies survive.

When an organisation is seeks to adopt a new security technology, they commonly go through a process of product selection based on a key criteria, for example.

Does the product meet business goals assigned to the project
Cost of ownership & return on investment
How well does the product integrate with the operating environment
How will it perform its function on our network rather than someone else’s

Integration questions and tests are particularly important as no two enterprise networks resemble each other, however one point that commonly gets overlooked is that the modern network rarely resembles itself a few months further along the line. How well security technologies deal with this rapid rate of change can be linked to how successful their deployment will be a few months along the line.  Will the new device adapt as the environment changes? Alternatively, will it continue in a pointless attempt to enforce extinct policies that has no relevance to the state of the organisation as it is now.

When introduced to a new network, an Intrusion Prevention System needs to be configured for the environment, this is so the device can better understand the habitat it operates in and is therefore better equipped to detect or prevent intrusions. In the world of IPS this is known as the black art of tuning. A tuning process can be broken down into a couple of logical steps.
Deploying vulnerability based network attack detection or prevention capabilities for assets that require protection.
Mapping the organisations acceptable usage policy into the devices configuration.

Both of these steps provide their own challenges, for the initial configuration of a system and also it’s adaption as the network it protects evolves. Lets take a look at each one in turn and discuss methods that can employed to improve the accuracy of detection, speed of response, and adaption to the network as it and associated business goals change.

Vulnerability based attack detection and prevention.

IPS is commonly considered the current generation of network intrusion detection systems, the new kid on the block that has the ability to prevent the exploitation of network vulnerabilities or violations of acceptable use as well as alert to the presence of an attack. Deciding on what vulnerabilities the device needs to detect or protect from exploitation has traditionally been based on user input. It is assumed that the security or network team within an organization is aware of the assets and services offered by the network, and therefore in a position to decide what vulnerabilities the IPS should mitigate. Unfortunately I commonly find this assumption to be flawed.

Many organizations I speak to incorrectly believe that they have a unique problem. Not knowing what assets and services are operating on the network, and therefore not knowing what needs to be protected for which vulnerabilities. This is clearly not a unique issue as I run into it all the time, and the impact of this problem turns out to be high. Missed attacks or false alarms.

Here at Sourcefire we designed a technology back in 2003 that provides information to make this task much easier, we call it RNA - Real-time Network Awareness. RNA provides a map of what the protected network looks like right now, based on how assets and services behave or are accessed. This real-time network map provides good answers to key questions before and after security events occur.

Before an event.
What devices are currently on the protected network?
What services do these devices offer?
What vulnerabilities may exist on these systems?
What detection or prevention capabilities do I need to employ to best protect this network?

After an event.
Was the attack relevant to the device or service?
E.g. Would the target have been vulnerable to the attack. Was it an Apache attack against an IIS Webserver.
Following the attack, did the network or asset change in any way?  2E.g. Did a new service start, or a new client application communicate to the internet for the first time.

Having this real-time map of assets on the network allows us to quickly adapt to changes in the environment. For example, take the current running IPS policy, maybe one that is designed to protect public facing assets from known attacks and overlay it onto a map of what the network is right now. Are there any gaps in the defenses? Has a new service been deployed on the network without the security team being made aware of it?
Has the version of Apache been updated on our production systems? Therefore mitigating the risk of some attacks being successful.

This real-time, constantly adapting map of the network is the key component of enabling the IPS to evolve as its habitat changes. It prevents it from becoming a dinosaur and churning out useless extinct log data.

Monitoring and Enforcing an Acceptable Use

Detecting violations of the organizations acceptable usage policy at a network level is a commonly desired function of Intrusion Prevention. Although we instinctively think of Firewalls, IPS and other network access control devices preventing communications between specific computers and protocols, these communications most likely occur at the request of a user. A laptop for example is not intrinsically a malicious device as its functions are controlled by a user, so if an acceptable usage policy is violated through an instant messaging chat session, do we blame the device or the user?

Tracking down the sources of AUP violations can traditionally be tricky in dynamic environments, and as it happens these are the most common source of AUP violations. Large DHCP ranges are commonly associated with call centres or groups of office staff who will gladly whittle their work day away by abusing network resources. In these environments it can be hard to find something static to associate with an event to allow investigation. The IP address of the source has since changed, knowledge of the original MAC address has been lost due to the network topology, a user was “hot-desking”, the only static in this habitat is the person that violated policy.  This is why it is important to associate these types of events with the user of the system at the time of the violation.

This unique combination of user and network awareness providing an up-to-date map of who is accessing what on the network is invaluable when it comes to actually enhancing the security. Network information has its most value at the time of discovery, constant discovery means providing constant value.

Sipping my Heineken, obviously served the continental way (thats with a quantity of head that instinctively makes you check for a measurement line), I was trying to catch up on email when I came to notice another overlooked parallel between IPS deployment design and the real world. Ditching the over-spilling inbox, I felt compelled to write about it.

A common challenge I encounter when working with organizations to help design intrusion monitoring and prevention strategies, is one of balancing unrealistic objectives with all too realistic budgets. I guess that there’s no shock there as its a far from a new problem, however I find that for me it becomes less frustrating once I manage to get a few important concepts across to the client.

Before I meet with those who are in possession of the organizational and technical information required to help deploy an IPS, it’s common for one of my “sales-guys” to say in an upbeat way “Don’t worry Leon, this design won’t take you long, they emailed me a network diagram! I have already half-specced the solution myself!”, The look in their eyes as they rub their hands together is one of elation as they count and re-count how much their design will cost.

I find that there is commonly an all-or-nothing approach unique to network security, this forces people to rarely see a middle ground of achievability. This is probably best manifested when I see the infamous network diagram, now modified to include an IPS appliance on every network link on the page. I don’t want to poke fun solely at my sales-guys for the occasional over optimistic deployment idea, I see similar designs from other network security venders all the time.

I have never been shown a network diagram that allows me to immediately design a decent IPS deployment. People think of a network IPS as its name suggests, a network device, however the function it provides operates at network, service, application and organizational levels. The normal network map that I initially get shown is one of routers, switches, firewall’s etc, it never presents me with worthwhile information about business objectives, how data is designed to move around the ether. Where do critical business services exist and barriers of trust drawn?

The all-or-nothing approach to device placement commonly results in a great number inline devices between every link that you can find, it costs a bucket load of cash and probably wont actually meet a goal of substantially improving security.

So, you may wondering what the parallel is that I felt compelled to write about, so lets jump a little closer to the point. When you plan an IPS deployment, don’t start off with the unobtainable “all-or-nothing” approach. Start with a plan that reflects network data flow as of now, and then try to meet achievable objectives that have been formally defined. This process also indirectly addresses the below common objections I hear against IDS and IPS as a technology.

“To do this right, I need to place down way to many devices. Too much cost in purchasing, and management effort”

“I cant put IPS everywhere so what’s the point of monitoring at all”.

The bar that I am sitting in has somewhere in the region of sixty people, they are all going about their business, chatting away and enjoying many creatively poured glasses of Heineken. It is impossible for me to monitor what everyone is discussing, especially without interruption, but is it impossible for me, a single monitoring point, to overhear something valuable?

I wasn’t purposely trying to eavesdrop,  but I couldn’t help but overhear an interesting conversation coming from the table next to me. The details of what was said is irrelevant for my point, but now that I have heard it I feel that I’m in a much better situation that I was before. I can use this newly found knowledge to be more intelligent about things. This is just the same as using the intelligence provided from a single network security monitoring device, we just need to make sure that we understand the scope of what it provides.

In the UK we are famously big users of Closed Circuit Television (CCTV), it provides an immensely valuable resource of audit data and crime detection. It is impossible to monitor the whole country with CCTV as the cost of cameras and the required of management effort grows beyond a line of what is worth-while. This line of what can be achieved and managed is also visible at an organizational level, It is unlikely that your whole office is monitored with CCTV, but there may well be a camera or two above important doors.

In just the same way that I can over hear a conversation or a well placed CCTV camera can record an interesting event, strategic placement and planning of a network monitoring device can provide data about specific assets that concern the user. A network IPS is essentially an access control device, and assuming you select a good one, extremely flexible. Operation of these devices fall into one of two camps, Detective controls, like a CCTV camera and preventative controls, like an automatic door. As you can imagine, the most valuable deployments provide a mix of these two controls at relevant locations.

Remember that if you decide to operate the network without audit and detective controls in place, you will never discover anything. With a good design that can actually deliver achievable, protection and monitoring in specific areas, this gives you one hell of a better chance to protect your organization than leaving your head stuck in the sand monitoring nothing.