Last year [2006], I completed a recommendation process for a large client centering on technology solutions to manage compliance information and efficiencies in operational information. When presented to management, this became more of a soup-to-nuts presentation on security information management.

Several client-specific slides have been removed, but there is quite a bit of material left to share.

Things I needed to remove include descriptions of:

• Client business requirements.
• Client IT architectural bias.
• Specifics of issues and leanings of the vendor architectures. Many didn’t have enough log management ability and didn’t benefit from the outgrowth of a log management lineage into managing security events in addition. Several appealed only to a more threat or alert centric console than a true SIM.

There is quite a bit of drift in understanding about what Security Information Management [SIM] architectures have evolved to solve. All of the products available are all very different and many are really built with infrastructural expectations in mind, though you will not hear their sales people tell you so. Like many competent and hard working professionals in my field, I had to separate the wheat from the chaff and glean, to the best of my ability, the best choice from the many available options. This is no simple task as there is a lot of sales material that will promise anything, but from the presentation of the architecture and real-world benchmarking, a clear image may present itself.

Two of the large commercial research firms authored materials were also gathered to assist in this mater, though one of them was shockingly inaccurate, unfamiliar with the history and utility of the tools in practice, and offered some very poor advice in its conclusions. Unfortunately this is all too common in my experience with commercial research, so the wise buyer of capital investment level hardware and software would be best served to spend the time evaluating each architecture, dependencies, and challenges if they are able.

A SIM implementation has the ability to solve a variety of problems at once due to its evolution from a log management platform. A successfully deployed SIM solution can gather events and logs from a variety of sources (ideally this would be all technology platforms available in an enterprise) and digest it so that it may be easily understood. It should also collect and corroborate related information from distinctly separated platforms so that related information can be examined and understood.

When this happens, a large advantage in compliance, operational, risk, threat, and efficiency management my occur.

I took some time here to make sure that everyone understood, or at least had a healthy suspicion, about what the point of a SIM solution should be using a variety of quotes from qualified people I like. As you can see, this includes Paul Stamp, Bruce Schneier, and others.

I also found it a good idea, based on feedback, to define what a SIM tool is not. Basically I needed to do this and sell the right mindset due to rampant vendor interference at levels of management that had no interest in what the technical solution should be as long as it solved the entire problem. There were many platform-centric tools thrown about and I needed to field questions on them all. This slide was the backdrop to many of these discussions.

For some audiences, the presentation of “SIM 101” ended here.

I then started to get down to brass tacks and tackle some of the questions of a technical audience. One key point was that distinct teams will have the ability to have one location for all systems and security management data; a centralized troubleshooting resource. Another would be that different teams, groups, or business units could be defined so that they would have differing levels of insight to this data as was reasonable. The principal of least privilege would apply here.

Now that we understand what good things SIM can bring to an enterprise, it’s time to talk about the possible downside.

I was thinking that an ITIL-like accounting methodology would lend itself to this kind of investment, but ended up being inappropriate for my client at the time. Much of the risks to SIM adoption can be addressed by close vendor involvement in making robust testing and deployment plans.

I then began speaking about specific vendor solutions that were available at the time. In information security, there is always a new version, software release, feature or widget that is promised by vendors to solve all of your problems. It may be available right now or Real Soon Now. It is best to test what may be tested and treat the rest as suspect in this skeptics opinion. Especially given my experience with how things are sold in my industry.

Here are the slides for various vendor offerings. You will notice that there is a lot said about some and little said about others. This is for good reason and is purely a time saving measure on my part. I didn’t feel that speaking at length for an inferior, incompatible, or miscategorized product was a good use of my audiences’ time. There are many products that are very highly regarded that I did not speak about here. I did review all leading and recommended products during this process. If you would like more information about them, feel free to contact me. I’m more than willing to share.

Now that you have read all of this, what do you do with all of this information? How do you decide what to do? I’m glad you asked.

I threw some more materials to backdrop the discussion here while I outlined the three major options. Those are (Yes. This is a simplification, though it is a just one) an appliance platform, a software platform, or a managed platform.

The limitations of so-called appliance platforms and more flexible software-based architecture are well known. To effectively choose between the two, leadership should balance the risk of complexity of implementation with the features required by the business.

Appliance platforms are less complex than software ones by their nature of combining the systems and software into a bundled solution that only has one vendor to support it.

In theory anyway. Not always in practice.

The gotchas list for a successful SIM implementation are the same as that for a successful centralized log management implementation with a couple additions. SIM can also accept metadata from sources such as vulnerability scanners, IDS/IPS alerts, business compliance software, and many others.

The key point here is that the more information that is known about how much data will be moving on the network, be it events, raw logs, or other meta data. A successful implementation will need to keep up with (or have a plan for later collecting) the traffic of the enterprise when WAN links fail, when an emergency event takes place, or other such events occur.

It is also important to consider what the proper level of logging should be in each platform area when deploying such an architecture. This may be a good time to roll out (or audit an existing) configuration management strategy in series or in parallel to a SIM deployment.

Lastly is a word on staffing. Getting the right team together is critical for these sensitive deployments.

Quantifying events per second and overall volume for the system is key. Some vendors have software that can assist in these estimations, but capacity planning is a bit of a specialized art. It may be worth bringing in specialists, from the vendor being implemented or otherwise, to determine what the correct numbers are in the set of circumstances that you are building this architecture to support. This will be the most difficult area to measure and may be the most probable deal-killer. This is doubly true for appliance architecture which is not as expandable as software. For example, I mention that NetForensics (for example) has the ability to run in a distributed grid environment which drastically increases its scalability. The appliance platforms did not yet have this ability which could limit their ability to scale in large environments. An out-of-band network for all of this logging data would also be a good idea to consider.

Also worth quantifying before deployment is data retention. What data of what kind is kept where, for how long, and in what format. Getting legal council involved to make sure your retention goals are where they need to be to keep you legitimate is always a good idea.

A hidden challenge with keeping a Security Operations Center [SOC] running is that it should be an amazingly boring job when things are run well. Incidents should be few and far between, staff should be highly trained and qualified to meet the issues that arise, and are very likely working on highly visible projects.

This leads to a retention problem for these positions. Highly qualified and bored team members tend to go find something else to do. Highly visible success tends to yield promotion. In both cases, seats are left empty in the SOC.

Is there another option that takes this into account? Yes.

ISS, now IBM, offers a service that functions as an outsourced SIM without surrendering control of your systems like managed providers demand. At the time this was a unique service, though others have followed their lead now, I am sure.

Advantages of out-tasking, out-sourcing, or out-whatever-you-want-to-call-it-ing to unload the boring work from your security staff and leave them to the more interesting work seems well advised.

—

Well there it is. Hope you enjoyed it.