By Adam Shostack, Emergent Chaos
Nearly a decade ago Bruce Schneier wrote “Security is a process, not a product.” His statement helped us advance as a profession, but with the benefit of hindsight, we can see he’s only half right. Security isn’t about technology.
Security is about outcomes, and our perceptions, beliefs and assurance about those outcomes.
Here’s a quick gut check: which would you rather tell the board or your customers? (1) “We had no security incidents last year, and aren’t sure why,” or (2) “Our customer database was pillaged 9 times, despite a cross-organizational investment in ISO 27001 which was aligned with our balanced scorecard and measured to be in the top quartile of all infosec programs?”
However people orient themselves around security, what they worry about is not “does the organization follow COBIT or ITIL?” but, “will they protect the information I’m giving them?”
Across the variety of orientations which exist within security, outcomes are what counts. Some examples:
- Compliance officers want to keep the CEO out of jail. All the process in the world is useful because when they’re not, they can talk about their plans for correcting that.
- Applied Researchers ask “did you pwn it?” They’re concerned with testing a hypothesis, which is “this system resists this type of attack”
- Law enforcement wants to catch the bad guy (or gal). Much of the friction between civil libertarians and law enforcement comes from a conflict about prioritization of goals.
We’ve focused on process because we have so little data on outcomes. People will talk about their training processes. But when you ask them, did that process work? no one wants to say.
For us to mature as a discipline and as part of the organizations we support, we must go from talking about what might happen to what does happen.
This essay orginally appeared on Emergent Chaos.
