In part 1, I attempted to convince you that the most common approaches and tools for information security are basically flawed and will ultimately continue to fail, as they have for more than a decade.
Despite the unstoppable growth of the information security market, organizations continue to face the same basic challenges and problems. We’ve spent an awful lot of money, but haven’t made a lot of progress, as evidenced by this 2012 Ernst and Young report: “Many organizations are still having difficulty finding security breaches and properly logging them”
Compare that statement to the first bullet point from the summary of the same report dated 2003: “More than 34% of organizations rate themselves as less than adequate in their ability to determine whether their systems are currently under attack.”
Same problem, nearly a decade difference.
The current big data security strategies, built on backs of SIEM tools, are just more sophisticated methods of setting off a fire alarm. They’re pushing the boundaries of alarm technology by looking for people carrying matches, potential pyromaniacs, and other anomalous behavior, but they’re still fundamentally on the reactive side of the line. This isn’t a reasonable strategy in fire prevention, or in information security.
To illustrate the problem, as well as its age, this is a slide from 2003 (sorry marketing folks):
The age old analogy here compares building codes to fire departments; you get more net reduction in fire-related damage by spending effort on prevention through code compliance than fire response. At this point it’s appropriate to ask what processes, tools or structures play the role of building codes in information security. It’s tempting to look to security policies and other types of compliance as the corollary, but there’s something vitally important missing in that connection: evidence.
Evidence is an interesting term to use in this context because it differs from both data and information. I’ve had more than a few conversations extolling the virtues of information over data, sometimes falling into the term ‘actionable information’ to emphasize the point that information is data with meaning. But evidence is data that proves a point, and that forces us to ask “what’s the point?”
“As we have already seen from our findings in this year’s survey, it is vital that organizations align their information security strategy with their business strategy and objectives.” (E&Y 2012)
The point is to run a business, or deliver a service if you’re not profit driven. E & Y describes achieving this sort of alignment this as a “transformation,” and they’re not wrong. I’m not a big fan of maturity models because they tend to get used to avoid responsibility (“We’re not mature enough to do that”), but there is a model that applies here.
The process starts by taking some action, usually as a reaction to a problem. This might be installing AV, scanning for vulnerabilities, or configuring a firewall. As the action becomes more routine, the organization starts to ask how it’s performing.
Here we develop basic metrics (not always good metrics) to measure performance of that action. Once we’re comfortable measuring how the action is performing, we start to ask how it should be performing, which drives the development of objectives.
If you’re establishing objectives and measuring performance against them, you’re managing performance. If you get to a point of being able to guarantee some level of performance, you might actually establish a set of SLAs.
Now, which parts of this curve have anything to do with aligning information security strategy with the business objectives? The answer is all of them, which goes back to why a maturity model is problematic.
You can’t really select the actions to take without some purpose, which should go back to the objectives, but is often more directly problem-resolution driven. You can’t know whether you’re performing to objectives without measurement on the actions. You can’t establish SLAs without the other three (and maybe you don’t need to).
This kind of analysis is all well and good for a neatly contained blog, but how do you insert this kind of thinking into an existing organization full of complicated people with jobs, opinions, problems and bosses? The answer is both simple and complex.
Start with this kind of thinking.
First, go read the E & Y report on transforming your information security organization. Then go read a few others that disagree. Check out the Society of Information Risk Analysts for some deeply technical content. Then, when you’re engaged in a project, consistently ask three questions:
- What’s the objective of this project?
- How does this objective matter to the business?
- How do we know if we’re successful at achieving the objective?
The summary at the end here is that building more sophisticated alarms hasn’t worked, and won’t. Investing in more proactive measures is a better strategy, but in order to do that, you have to know what the objective you’re trying to achieve is, and that means you have to align with the overall objectives of the business. You can’t do that alone, but you alone can start.
Title image courtesy of ShutterStock