Understanding and Selecting SIEM/LM: Business Justification
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
