The Importance of Security Based on Outcomes
I don’t know about you, but I’m rapidly closing in on twenty years in this industry. I’m blessed enough to have held a variety of jobs in the general security field, and worked through a long string of challenging roles that gave me perspective. Over that span of time, I’ve always tried to apply security like anything else – starting with the end in mind.
What I’ve learned in the last decade of being on the consulting/provider side of the table is that starting with the end in mind isn’t universally applicable. I guess I’ve just been lucky – working with progressive security leaders who understand that starting something by using the words “let’s just go” is part of the “famous last words of a CISO.” I like to think that I’ve helped a handful of security leaders make good decisions by slowing them down, providing an opportunity and sounding board, and bringing practical examples and use-cases of “doing it better.” But let’s get down to the issue at hand.
Outcomes are important. Knowing what you want to achieve before you set off on your journey is crucial. I know this sounds like common sense when you’re, say, taking a family trip or getting in the car at the airport – but what about how you run your security program? How do you define your outcomes in a way that not only makes sense to business executives but to program managers and technical experts as well? The simple answer is that you have to start abstract and work your way into the concrete, or start concrete and work backwards into the abstract – it’s really your choice depending on how your mind works and how you think. But omitting the step is a virtual guarantee of certain doom.
The problem with defining outcomes is reaching the right level of specificity – so that it can be achieved and measured to completion. That’s right – you have to be able to measure your relative distance (closer, further) in relation to the effort and resources you put into the task. That’s a roundabout way of saying you have to figure out whether the millions you’re spending on the thing you’re trying to do is working. If you set your outcomes too loose (poorly defined) there is a significant potential that there will be lack of clarity and your technical and program management teams will work towards different ends, while your leadership’s expectations will be something different. Good luck reconciling those.
Setting the right outcomes is an art and a science. Experience will teach you the art, while peers and frameworks will give you the science. You have to marry those two together in just the right proportions to get what you want.
For example, let’s say you want to improve a software security program. You’ve done “software security” for a while, but a recent audit finding or a hack/breach or something else demonstrated that you’re not doing as well as you’d like. “We must do something” is your directive, and suddenly you have budget and ability to execute. But “do something” isn’t measurable, and it definitely doesn’t help you succeed. So what do you do, so that you don’t end up with a pile of new tools, new hires and an army of consultants with no realoutcome? Let’s figure this out.
Step one, really, is to figure out what’s broken. Was it a failure in resourcing, tooling, a process breakdown, a lack of education/awareness or something else? If you don’t know that answer, or haven’t taken the time to investigate you’re going to have a bad time. So first figure out what your deficiency is – and it’s OK to write down more than one thing. It very simply could be due to lack of resources, causing sub-optimal use of available tools and process challenges. The result is that your application development processes may not incorporate a proper review cycle which can result in applications being released with security flaws that can leave your business open to risk of cyber attack. That happens a lot more than we’d like to think. Identify the problem you’re going to solve, and define what ‘solved’ looks like.
Now create the three levels of outcome. First, at the executive level you’ll want to talk risk reduction. What is the level of risk now, and how much will you reduce it by? Next, translate that into the program management level. The solution may be to deploy additional processes and more integrated tools with additional levels of awareness and targeted training. You can accomplish these tasks at the program management level. Finally, the last level involves the technical details. What does the implementation look like? What are the requirements for process development, tools purchase and integration, and who needs to get trained and become more aware?
Now, you can start to take metrics on all these activities and abstract them back up to the leadership level. Now you can report progress, and now you can demonstrate that an incremental spend can have an exponential effect on risk (maybe) reduction. But when you first set the outcomes, you at least know what you’re trying to achieve. Otherwise, you’re in the “do something” death-spiral, which leads downward.
So, if you’re starting to get pulled into an initiative, or it’s time to revisit a part of your security program on which you can’t quite quantify the returns, start with outcomes. Even if you realize you’re doing poorly, at least now you’llhave empirical data. And remember, knowing is half the battle.