Security isn't thin
  ITS LARGE

    LOUD AND

      FAT

<---Mark "Fat Bloke" Osborne

 
 
 

I-AM-DOH

Together we can erradicate IDS false positives

For about 100 years (i.e. since 2000) I have been banging on at conferences and security forums that IDS often don't work, not because the concept is bad but because the

  • IDS themselves are badly coded
  • IDS rules are badly designed
  • IDS are usually installed by a Muppet from a general re-seller who would not understand the dynamics of a hack if you tied him down and rammed all volumes of hacking-exposed up his bot-bot
  • IDS systems are forced to operate in isolation from environment it operated in, to re-inforce the nonsensicle , marketing proposition that it is a plug-and-play technology
  • IDS was sold to people looking for an easy panacea to momentous security problems - obviously it isn't, it is just a monitoring technique

At the time, I believed that techniques like anomalous detection held the key to the future of IDS but in the short term, education plus care deployment and tuning based on a server weighted methodology (here) and a careful deployment strategy (here) could radically improve the detection rate and effectiveness.

I put in practice what I preached and enjoyed many happy engagements (engagements = job in consultant speak ) making IDS work - It was fun and the people who contacted me found the work useful. During this time, I discovered that before tuning most customers were getting stats of about 1/20 i.e. 1 "interesting" alert out of say 20. And generally this was because:

  1. The IDS only packet grepped and were seeing attacks that weren't there.
  2. The IDS was reporting a problem on a server running a product neither of which really existed.
  3. The IDS was reporting a problem on a server that really did exist but didn't run that product.
  4. The IDS was reporting a problem on a server that really did exist and did run that product - but that product didn't have that problem.
  5. The IDS was reporting a problem you'd already been told about
In 2002 I published an article on my website (HERE) , with an invitation to others to collaborate, showing a design for an IDS Alert filter which would use the concept of priority escalation and combined various open source products ("lets leverage the knowledge resource of the open source community" - Y'all can tell I'm a consultant ) to reduce the number of false positives using the following techniques:

  1. Os-identification
  2. Service identification
  3. Port-scanning
  4. Vulnerability scanning
  5. On-line cve and bug interpretation.
  6. Server importance weighting
  7. Attacker frequency

In early 2003, nobody had volunteered to collaborate (although some chaps from London 2600 did share some info) so in-between versions of WIDZ and whilst I was resting ( consultant speak for having a huge falling out with several dumb-ass Scottish accountant types, then running away to find a new job with a big bag over one shoulder with swag written on it ), I wrote I-am-doh as a proof of concept (i.e. I don't programme worth a damn) to demonstrate how the above techniques can be used.

  • It leverages nessus and the nessus database for vulnerability identification.
  • It leverages Nmap for port and OS identification - and now service identification.
  • It used to (and may do again) use AMAP and VMAP for Service and version identification.
  • it uses bug track to gain online vulnerability info.

The concept of product re-useably is continued, all gui's are based on existing products like gnome-terminal, which provides the ability to scroll and to open browser windows on to bug track or nessus.org. These features would have taken ages to code !!!.

I wasn't going to release the code ever because you'd all been so bloody unco-operative but in view of the comments from the G**TNER last week about IDS being dead I thought I'd better release early

BOTTOM-LINE - I-AM-DOH filters greater than 75% of the false-positives.

Give it ago, the code is as flaky as hell but it proves a point.

I-am-doh [I DS-Attack Monitor-Desktop-DOH also because I think Homer Simpson is a role model

download iamdohv1.tgz

 

I-AM-DOH Screen Shots

Here is the basic I-AM-DOH desktop. One screen shows a rolling log-display of all alerts on the alert file(this could be made to read it from a syslog). The other terminal has a rolling log-display of all alerts that I-AM-DOH has processed and considered more worthy of attention.

This shows the screens in more detail.

This screen shows why I used a basic gnome-terminal instead of a simple HTTP display. Not only can I browse up and down.


But I can open the CVE or BID information from the alert in a browser window.


Here it shows a session enquiry of a vulnerability on white hats.

Now onto I-am-doh, here we see an alert fireing. It pops up a window, again i could have made this a bit of html. But I decided to go for gmessage. This message times out after 30 seconds and retrys for 3 attempts but that is configurable.

The menu offers u a number of choices. These include:

  • do nothing - leave don't resend message
  • exclude this address-snortrule
  • run nessus
  • run a script to send a message to the ABUSE@ISP
  • list all events associated with this address

And here we see the last of those options - list all events associated with this address




[Back 2 LFB]