Any security monitoring system comes with a certain amount of good old-fashioned alerting: that is, identification of deviations from an expected state, and bringing them to the attention of a response unit. Picking up a deviation is easy; interpreting it in the context of a whole running system, on various layers, and with business activity is something else entirely.

The more intelligent analytics today can work with clever algorithms and heuristics to define more complex deviations based on historical activity -- for example, a "learning" monitoring system can record network or user activity and alert on events that exceed thresholds from that baseline, such as being able to tell the difference between human-speed clicking through Web pages and automated probes.

But there’s just no substitute for an admin with intimate knowledge of the system who can look at something and immediately say, "That doesn’t look right." Or who can say, "Oh yeah, we meant to do that, don’t worry about it."

Once, we got a database activity monitoring product set up, and happily started watching the transactions it captured. But I saw a username that wasn’t like any other that we’d ever created -- it was the name of a well-known fictional character, and it was accessing some very sensitive records. I went tearing down the hall in a panic to the DBA lounge, asking them if they’d ever heard of this user who looked like an intruder. It turned out to be a legacy database account with admin rights that they couldn’t get rid of. The database admins had that historical knowledge and day-to-day context that I didn’t have.

A DBA, a developer, a network admin, and a security person can all look at the same events and interpret them in their own contexts. They can also get different information out of those same entries. They’ll know who normally adds firewall permissions in response to personal visits from the CIO and for what purposes, such as one-day access to a test server to demo an application for a hotel conference room full of VIPs (and, of course, nobody remembered that they needed the access until after the danishes had been passed out). This is the sort of thing that you just can’t program, no matter how many brainiacs you have working on your SIEM.

The end result is that your monitoring simply can’t work without a sufficient supply of carbon-based life forms.

Tuning, day-to-day monitoring, and response all have to be done by these very expensive components -- and remember that good, security-minded technical talent is hard to come by. This is what trips up some organizations: They think that putting in an automated log management and intrusion detection system will replace people, and it won’t. It can make the staff’s life easier, sure, but it can’t do all the work. In fact, in complex environments it can’t even do half the work.

If you think about it, no one person in your organization can know simultaneously what’s going on in the accounting system, on the legal team, in lines of business, in procurement, on the network, in development and testing, and on the Exchange server (although I once worked for a brilliant COO who came damn close to being able to do it). If a person can’t know all the context to interpret events, then neither can a SIEM.

A SIEM installation requires a heavy investment up front to get it started, but it also requires an ongoing investment in humans to keep it running. This is what can put security monitoring and intrusion detection beyond the reach of under-funded enterprises. Prevention products tend to be less expensive than detection products in terms of the number of knowledgeable people needed to make them work effectively. A prevention product may plausibly be marketed as "set and forget," but you can never, ever "set and forget" monitoring. Your environment is too dynamic and complex for that -- and so are the threats that you’re trying to detect.

When you get a bid for a security monitoring system, go ahead and double the number in your mind to add the people requirements. That way you'll have a better chance of success in your project.

Wendy Nather is Research Director of the Enterprise Security Practice at the independent analyst firm 451 Research. You can find her on Twitter as @451wendy.