Threat Level: green Handler on Duty: Tom Webb

SANS ISC: InfoSec Handlers Diary Blog - Watching the watchers InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Watching the watchers

Published: 2014-04-03
Last Updated: 2014-04-03 09:18:29 UTC
by Bojan Zdrnja (Version: 1)
14 comment(s)
A lot of companies today have various IDS and IPS devices implemented in their internal network (especially if you must be compliant with PCI DSS, for example). So these devices get implemented to monitor various traffic at various interfaces/perimeters in a company, but the question I got asked is how can we be sure that the IDS/IPS is doing its job?
 
Obviously, some simple monitoring should be in place – this typically consists of pinging the device or collecting various counters such as memory, CPU usage and similar. This is normally enough to make sure that the device is up and operational. But the question is – how do we make sure that the IDS/IPS is actually detecting malicious traffic or network attacks?
 
An obvious answer to this question is to try to send something malicious and to see if the IDS/IPS correctly identified the attack. So the following options (or all of them) can be implemented:
  • We can automatically download eicar.com and see if the IDS/IPS detected the malicious file.
  • We can perform an automatic scan with nmap or execute any NSE nmap script. Typically, a normal scan (a SYN scan) should trigger the IDS/IPS. This is also a good test to see if the IDS/IPS is detecting network behavior.
  • We can send an exploit over the network. While thinking what to send I browsed through pytbull, which is an IDS/IPS testing framework (more at http://pytbull.sourceforge.net/). Pytbull comes with a bunch of attacks that can be used to test your IDS/IPS installations. At the end I decided that it was too complex, so it was much easier just to take some shellcode, prepend NOP sled to it (yea, so it looks real) and use scapy to send it.
The above "attacks" can now be scheduled – for every schedule, the IDS/IPS device should detect (and/or block) such attacks. To confirm that everything is working ok, it should also generate an appropriate log file which can be then automatically verified with a SIEM; if an attack was executed and there was no detection we know something went wrong with either the IDS/IPS device or the network between the probe and the device – no matter what our standard monitoring is saying.
 
So, what mechanisms do you use to verify your IDS/IPS is working OK? Let us know!

--
Bojan
@bojanz

Keywords: ids ips test
14 comment(s)
Diary Archives