Few things make me happier than getting to publicly disagree with one of my coworkers.
Earlier today Mike suggested that security is too reactive and tactical to succeed. Then we hear the usual platitudes about treating security as a risk management function, better metrics, blah blah blah. Not that there is anything wrong with all that, but it needs to be discussed in context of the fundamental nature of security.
Which is an ongoing state of disruptive innovation.
Security is reactive by nature – the moment it isn’t is the moment you really lose. The question is how to best provide yourself with the most time to plan your reactions, and what kind of infrastructure you can put in place to reduce the cost and complexity of any course corrections.
Business innovation tends to result from three primary drivers:
- Competitive response. A competitor does something; you need to respond to stay in the game.
- Competitive advantage. You do something to gain an edge, and force others to respond.
- Efficiency/effectiveness. You streamline and improve your processes to reduce overhead.
But security only shares one of those drivers. Security innovation is dominated by externalities:
- Business innovation. The business does something new, so you need to respond.
- Attacker innovation.
- Internal efficiency/effectiveness. “Doing security better”.
Two of the three forces on a business are internal, with only competitive response driven by an outside actor. Security flips that. We can’t ever fully predict what the business or attackers will do down the road, so we need to scramble to react. That’s why we can never seem to skate ahead of the puck. You can’t skate ahead of a quantum field state that will eventually collapse into a single wave function – there are too many options to choose one.
The trick, as Chris Hoff and I have been talking about at RSA for about 6 years now, is to take a strategic approach to prediction. This is why even a risk-based security approach is, in reality, just another tactical piece. The strategic piece is building a methodology to inform your working assumptions for what the future holds, and building your program to respond quickly once a direction is set.
It isn’t magic, and some of you do this intuitively. You stay up to date on the latest research, both in and out of security. You track both new attack and general technology trends. You engage heavily with the business to understand their strategic direction before they make the tactical technology choices you later have to secure.
A lot of this looks almost identical to Mike’s recommendations, but the reason organization after another fails in their risk-based, metrics-driven, incident response programs is they to and run them in a bubble, and assume situations are static on at least an annual basis.
If you build your program assuming everything will change underneath you, you will be in much better shape. And I absolutely believe this is a realistic and pragmatic goal that others have achieved.