Ping is the all-time favorite of "monitoring" in IT. Looking at network traffic on the job, I have seen servers being pinged by various "monitoring" tools all across the enterprise no less than every second or so. I usually refer to this as "theft prevention", because the "monitoring" application will - if at all - only turn "red" if someone grabs your box and walks away with it. It ain't no secret that true monitoring requires that you monitor the key functionaliy, and not the existence, of a device.

While this concept is increasingly in use for operational (service availability) monitoring, it seems to me this hasn't quite caught on yet for the monitoring of security filters. Experience tells that security filters which you think are in place but aren't, or are not working anymore, make for nasty surprises. Here's a few hints on how to avoid them:

Case #1: Proxy Anti-Virus
If you have a proxy server that is supposed to do AV filtering, a simple script that pulls an EICAR test file through the proxy can go great lengths in detecting whether the AV is still working. It won't tell you if the patterns are up to date, but it WILL tell you if, for example, the AV process has crashed and the solution is in "fail open" state.

Case #2: Proxy URL Filtering
If there is something in place that supposedly should keep your users from going to www.morelength.porn, then having a script that tries exactly this access can tell you if your URL filter is working as desired.

Case #3: Proxy Content Filtering
If your proxy is configured to prevent downloads of, say, files with .scr extension, trying to grab such a file through the proxy makes a good test, too. Not that I advocate blocking by extension only, read my earlier post on "Decoding Malware" to see how current malware avoids extension and content filters. But if having such a block is part of your defense strategy, testing that it still works should also be part of it.

Case #4: EMail Content Filtering
Pretty much the same as #3, but due to the load of spam and virii on the email side, content and extension based blocking still makes a lot of sense here. If you can get away with it, even better are white lists that only allow a pre-defined set of attachment types. In any case, testing that these filters still work as advertised is highly recommended. You can set up an external server to send "known blocked" email types against your mail gateway. You can even address such test emails to the operations or abuse team mailbox, and if they ever get one of the test mails complete with attachment delivered, they know right away something is broken  (test mails which have been filtered correctly can be moved into a folder automatically, so they dont clutter the inbox)

Case #5: EMail Anti-Spam and Anti-Virus
Trying to send inbound EICARs and GTUBEs via email, following the same approach as above, will tell you if your spam filter and AV are doing their job as desired.

If you have some neat feat to share on how you test the working condition of your security filters, please let us know and I'll update this diary later today with the best tips we receive.