New multi-solutions make it difficult for IT managers to keep tabs on all the products

Opinion by Nick Barron

Why do vendors in a multi-solution world make it so difficult to monitor things? Just provide a read-only interface...

Why do vendors in a multi-solution world make it so difficult to monitor things? Just provide a read-only interface...

It used to be nice and simple in the old days. Your anti-virus was updated by hand (I still have some of those Dr Solomon's ‘no write enable tab' floppies), patch management was a case of scribbling the right version number on a disk or running a quick (home-grown) batch script. Firewalls, web filtering, intrusion detection and all that fun stuff were unknown outside research labs.

Fast-forward 20 years and the average security techie not only has to know about a wider range of technologies and threats, but also has a bewildering array of user interfaces to contend with when dealing with their ever-increasing menagerie of security products. The cost associated with rolling out and managing a modern security product will often significantly exceed the purchase price, so ease of management can be as crucial as a product's security features.

Unfortunately, a common interface is rarely practical. If you go for a single vendor solution you get quite close; maybe not one interface but a common look-and-feel. It's rare to find a single vendor that meets all your needs, so for a best-of-breed security solution you're stuck with learning several different views of the security world.

I'm a pragmatic sort of security techie, so I can live with that. What I do like to have is a simple way to find out how worried I should be, and how much coffee I need to put on when I get in. While controlling all your solutions from a single view may be impractical, it should be possible to keep tabs on the ‘go/nogo' status of your security world with whatever product you choose.

There's little effort involved in vendors providing simple functionality to check how things are going. The standard way to do this is SNMP, but anything will do as long as it can be easily processed. Plain old text files are fine, XML is an option if you need structure or are particularly fond of angle brackets.

My preferred solution for monitoring is the open source Nagios product ( This allows me to check very quickly if anything's broken (or on its way to breaking), and is flexible enough to add checks with short (and therefore cheap) custom scripts. It will email me about problems and send me a text message if things get really bad (but please don't mention this to my boss).

I recently looked at adding monitoring of our corporate anti-virus product to our Nagios system. The product has a good user interface, so I thought it would be simple enough to add. No such luck.

There's no simple command line interface, and although SNMP is supported, it only provides alerts for certain conditions. While it will helpfully fire off a warning when, for example, more than ten machines are out-of-date, it remains stoically silent when the figure drops back below the threshold. So even if I could pull the standard messages into Nagios it would be of little use, as they tend to be short-term panics rather than real problems. I'd much rather just have the raw data; products such as Nagios happily handle thresholds and generate alerts for me.

Still, I thought, no problem, it runs on an SQL database and I share an office with a pack of tame and easily bribed Oracle code monkeys (or “database developers” to the uninitiated). A few quick queries should get me all the information I need. Alas, the vendor didn't like this, saying any such solution would result in an unsupported installation.

While I am quite happy with vendors baulking at unauthorised modifications to their databases (my employer sells a complex database and we are equally unsympathetic), read-only access is a different kettle of fish.

So I'll end with an appeal to vendors. As well as the pretty and demo-friendly graphical interfaces, provide a simple command line script to pull out vital statistics, and a documented read-only interface to your database. A read-only SNMP interface would be nice, but is not essential (SNMP traps are OK, but more effort to handle).

Pretty as your dashboard screens are, I only really want to look at them when I absolutely have to. Please learn to play well with others.


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events