It’s time to resume our series on Understanding and Selecting a SIEM/Log Management solution. We have already discussed what problems this technology solves, with Use Cases 1 & Use Cases 2, but that doesn’t get a project funded. Next we need to focus on making the business case for the project and examine how to justify the investment in bean counter lingo.

End User Motivations and Business Justification

Securosis has done a lot of work on the motivation for security investments. Unfortunately our research shows budgets are allocated to visceral security issues people can see and feel, rather than being based on critical consideration of risks to the organization. In other words, it’s much harder to get the CEO to sign off on a six-figure investment when you can’t directly demonstrate a corresponding drop in profit or an asset loss. Complicating matters in many cases, such as the theft of a credit card, it’s someone else who suffers the loss. Thus compliance and/or regulation is really the only way to justify investments to address the quiet threats.

The good news relative to SIEM and Log Management is the technology is really about improving efficiency by enhancing the ability to deal with the mushrooming amount of data generated by network and security devices. Or being able to detect an attack designed to elude a firewall or IPS (but not both). Or even making reporting and documentation (for compliance purposes) more efficient. You can build a model to show improved efficiency, so of all security technologies – you’d figure SIEM/Log Management would be pretty straight forward to justify.

Of course, putting together a compelling business justification does not always result in a funded project. Remember when money gets tight (and when is money not tight?) sometimes it’s easier to flog employees to work harder, as opposed to throwing high dollar technology at the problem. Yes, the concept of automation is good, but quantifying the real benefits can be challenging.

Going Back to the Well

Our efforts are also hamstrung by a decade of mis-matched expectations relative to security spending. Our finance teams have seen it all, and in lots of cases haven’t seen the tangible value of the security technology. So they are justifiably skeptical relative to yet another ROI model showing a two week payback on a multi-million dollar investment. Yes, that’s a bit facetious, but only a bit.

When justifying any investment, we need to ensure not to attempt to measure what can’t be accurately measured, which inevitably causes the model to collapse under its own cumbersome processes and assumptions. We also need to move beyond purely qualitative reasoning, which produces hard to defend results. Remember that security is an investment that produces neither revenue nor fully quantifiable results, thus trying to model it is asking for failure.

Ultimately having both bought and sold security technology for many years, we’ve come to the conclusion that end user motivations can be broken down pretty simply into two buckets: Save Money or Make Money. Any business justification needs to very clearly show the bean counters how the investment will either add to the top line or help improve the bottom line. And that argument is far more powerful than eliminating some shadowy threat that may or may not happen.

Although depending on the industry, implementing log management (in some form) is not optional. There are regulations (namely PCI) that specifically call out the need to aggregate, parse and analyze log files. So the point of justification becomes what kind of infrastructure is needed, at what level of investment – since solutions range from free to millions of dollars. To understand where our economic levers are as we build the justification model, we need to get back to the use cases (Part 1, Part 2), and show how these can justify the SIEM/Log Management investments. We’ll start with the two use cases, which are pretty straight forward to justify because there are hard costs involved.

Compliance Automation

The reality is most SIEM/Log Management projects come from the compliance budget. Thus _compliance automation is a “must do” business justification because regulatory or compliance requirements must be met. These are not options. For example, if your board of directors mandates new Sarbanes-Oxley controls, you are going to implement them. If your business accepts credit cards on Internet transactions, you are going to comply with PCI data security standard.

But how to you justify a tool to make the compliance process more efficient? Get our your stop watch and start tracking the time it takes you to prepare for these audits. Odds are you know how long it took to get ready for your last audit, the auditor is going to continue looking over your shoulder – asking for more documentation on policies, processes, controls and changes.

The business case is based on the fact that the amount of time it takes to prepare for the audit is going to continue going up and you need automation to keep those costs under control. Whether the audit preparation budget gets allocated for people or tools shouldn’t matter. So you pay for SIEM/Log Management with the compliance budget, but the value accrues to both the security function and streamlines operations. Sounds like a win/win to us.

Operational Efficiency

Our next use case is about improving efficiency and this is relatively straightforward to justify. If you look back at the past few years, the perimeter defenses of your organization have expanded significantly. This perimeter sprawl is due to purpose-built devices being implemented to address specific attack vectors. Think email gateway, web filter, SSL VPN, application aware firewall, web application firewall, etc. All of which have a legitimate place in a strong perimeter. Specifically each device requires management to set policies, monitor activity, and act on potential attacks. The system itself requires time to learn, time to manage, and time to update. which requires people and additional people aren’t really in the spending plan nowadays.

Operational efficiency means less time managing while accomplishing the security checklist items you are supposedly responsible for. There is clearly a cost to having analysts gather data from numerous security consoles and having to do analysis and correlation in their own heads. Automating much of this analysis clearly increases the efficiency of the folks you already have.

Thus you can justify this use case by talking about the number of staff you won’t have to hire via the intelligent use of automation. Lots of folks get scared by this justification tactic, since they figure talking about efficiency means they’ll be expected to cut headcount. That’s short sighted because most security teams are woefully understaffed, which means the only hope is to automate activities and improve efficiency. Using hard time and cost metrics for these tasks, you can directly generate a number for activities that you won’t have to do, thus saving money.

React Faster

Finally, the react faster use case focuses on improving security by accelerating detection of attacks. So how do we quantify the benefits of this kind of use case? Let’s look at the economic impact of improved security:

• Reduce downtime (increase availability) – Here we’d need to model the cost of downtime by some measure. Perhaps it’s lost orders. Or unhappy customers. Or failure to ship merchandise. There are lots of ways to quantify downtime, odds are your operations folks have a method they’ve used to get management tools.
• Brand impact of breach – You can also work to estimate the negative effect on the organization’s brand of a high profile breach. Right, that’s about as scientific as throwing a dart.
• Cost of disclosure and clean-up – Less squishy is the cost of notifying customers of a problem and cleaning up the mess caused by a successful attack. There are standard numbers of the cost to clean up based upon customer records compromised, so that’s pretty easy to quantify.

Clearly this is the hardest situation to build a compelling cost justification. Securosis has done a lot of research into this kind of squishy business justification (and tried to make it a bit less squishy). We recommend you take a look at our Business Justification for Data Security white paper to get a feel for how to structure a process to quantify risks and losses when hard numbers are not available. Sure, we think ROI is the flying Unicorn of statistics, but we do provide qualitative and quantitative approaches to produce estimates of tangible cost reduction.

To be clear, many organizations don’t even bother trying to come up with a dollar figure for improved security, rather using this as qualitative additional value for an investment – as opposed to the main economic driver.

Packaging Your Business Case

The level of justification and packaging you need to get the project approved will be dependent on your specific environment. Some organizations need terribly formal documents, with spreadsheet models and ROI calculations. Others will take a quick slide deck with the highlights and the inklings of the depth of analysis. Obviously do the least you need to get the green light for the project. The more time you spend concocting ROI models, the less time you have for fighting the bad guys.