Cutting Through the Fog of Security Data

Our manager has a momentary mental lapse as she tries to get a handle on the data her security tools produce.

The past few weeks — nay, months — have been filled with people, process and project issues. I wondered if I would ever get any real work done. Real work to me is security work, not “adminisdribble.”

One of the worst aspects of adminisdribble is that it buries me in paperwork. And the paperwork is following me into the security realm. The agency used to get by without much documentation; as long as we had log files to reference when a situation arose, we were OK.

Nowadays, though, it seems as if everything needs to be documented, with audit logs pulled together for management, auditors and attorneys. It’s getting in the way of our real security work, so we have to get on top of it.

I have a vision in my mind: to be able to show anyone who needs it the security profile of the agency at any given moment. It would take all the data that we’re generating from routers, intrusion-detection systems, firewalls and a multi¿tude of other security tools and organize it for easy, at-a-glance digestion.

We certainly have no dearth of data. This past summer, we bought half a dozen new and beefy servers. One we designated as the security server, for housing the security software and log files. Only three people have access to it. We also purchased security software and appliances that let us monitor and document activity on the network.

We have router and firewall logs, intrusion-detection logs, network-monitoring data, Web server logs, and server event and performance-monitoring logs. We can even garner log files from every computer in the agency. We can document everything that happens on the network — what goes out and comes in, and who accesses what and when.

It’s all a bit overwhelming. Who’s going to monitor all this stuff and correlate the data?

Networking specialists understand the concept of setting a baseline: becoming familiar with what normal activity and thresholds are, so that when abnormal activity pops up or normal thresholds are exceeded, you can spot it. That’s the sort of thing we have to set up with all our new security toys so that we will receive alerts when real anomalies or malicious patterns are detected. It would be an acceptable practice to just eyeball the log files, looking for anything out of the ordinary. Unfortunately, we don’t have enough eyeballs to do that adequately. And my staff is overworked as it is, leading to fatigue, distraction and competition with higher priorities.

As I was struggling with this issue, a faint light began to shine inside my tired head. Haven’t I seen this movie before?

Yes, of course — it was all coming back to me. (Honestly, I think I have “sometimers” disease; sometimes my mind is sharp as a tack, and other times it’s as dull as a board!) As my mind cleared, it suddenly became obvious to me that the problem we were facing is fairly common and already well defined.

The sorts of tools we need do exist. They gather up gigabytes of network computing data, parse it into a common format and correlate events from a variety of systems. They identify threats, potential and otherwise, and sometimes even present the data in a graphical format as well as a report format. These sorts of tools used to be called SIMS — security information management systems. Now, as they move into the third and fourth generation, they have fancier names. See? I really do know something about them. If only I could remember the details ...

Shedding Some Light

In fact, we had dealt with this problem at the last company I worked at before joining the public sector. I just couldn’t seem to remember how we solved it.

I called my colleague Mark, who was still working in security at my previous employer. He could fully illuminate the dim corners of my mind that I was having trouble peering into — and he’s a friend, so he wouldn’t laugh too much about my deteriorating mental processes. In fact, he gushed about how much he missed me. Finally, I asked my question: “Hey, Mark, what did we end up using for event correlation? Didn’t we have the guys from ArcSight in to do a demo?”

Yes, he said, we had reviewed ArcSight’s Enterprise Security Management product, but although it was impressive in functionality, we were quoted a price of $150,000. That was too rich for our blood at the time. We then determined that the second-best tool available for our needs was Cisco Systems’ Security Monitoring, Analysis and Response System (MARS). According to Mark, the price had been right. And, he reminded me, Snort is still the best thing going in intrusion detection, and the log files feed right into MARS.

I jumped on e-mail and requested a quote for MARS from the state’s preferred vendor. Then I went to Cisco’s site to read up. I needed to know which log files or syslogs are compatible with the system. Of course, all the Cisco stuff is compatible — NetFlow and syslog data from Cisco routers, firewalls, switches, concentrators, intrusion detection and so on. It can pull data from almost any SNMP- and syslog-enabled device as well as from a host of vulnerability and antivirus systems, host operating systems, Web servers, Web proxy devices and database servers.

A tool like this could be just what I need to solve my data correlation problem, and it might solve my paperwork problem as well. I might be able to produce the sort of monthly security profile report I’ve dreamed about. Now that I feel as though my brain functions have been restored, I need to find out more and make this happen.

What Do You Think? This week’s journal is written by a real security manager, “C.J. Kelly,” whose name and employer have been disguised for obvious reasons. Contact her at, or join the discussions in our security blogs: To find a complete archive of our Security Manager’s Journals, go online to


Copyright © 2006 IDG Communications, Inc.

Download: EMM vendor comparison chart 2019
Shop Tech Products at Amazon