Security Portfolios: A Different Approach To Leadership

Part seven of an ongoing series.

In a recent column, I introduced the idea of cybersecurity portfolios, and today I want to talk more about how to use them. Essentially, a “cyber portfolio” or a “controls portfolio” is a way to model the state of your security based on the investments you’re making. This is analogous to how your financial portfolio is a model of your financial investments.   

This new type of model is a different way to approach security leadership. So I’m going to start out with a picture, and then use it to think about some definitions.

Let’s look at Sounil Yu’s Cyber Defense Matrix (CDM). It’s a 5-by-5 matrix of security goals and asset types. The goals are from NIST CSF (identify, protect, detect, respond and recover) and the assets are from COBIT (apps, data, devices, networks, people). What makes this so powerful is how the arrangement allows you to compactly and usefully organize your thinking about defensive resource allocation.

It’s concrete. It’s a set of controls. It’s complete.  

You can use a portfolio view like this one to rapidly identify gaps. (Example above from Yu’s RSA talk.) For example, this matrix shows nothing in application detect/respond/recover; the response and recovery categories are generally weak. That is not atypical, which may make it okay, or it may not, but the business can now see that. Perhaps they are covered by processes and training?

You might create a view of your portfolio that shows where your process and training budgets are going. You can do this analysis using the CDM to help you see your portfolio.

It’s worth asking, why go from the CDM to portfolio views? The answer comes to us from George Box, a statistician, who said that all models are wrong, and some models are useful. There are things for which the CDM is great, and there are places where it's less useful (orchestration, departmental leadership).

So what makes for a good portfolio view? Fundamentally, one that drives business change or understanding. That change might be to allocated budget, it might be agreement to move forward on a project, it might even be that executives believe that a risk is reasonably well addressed. The understanding may be that discussions become more focused or grounded.

Which brings us to the question: what’s in a good portfolio view?

First, let me define controls inclusively and expansively. Controls are the things you do to manage risk; to reduce the likelihood or impact of incidents, or to reduce your uncertainty about either.   There’s a meta-level of things you do to assess, measure, or communicate about those risks or controls, and I’ll count those as controls, because from a management perspective, they are more like controls than anything else. Thus, a list of controls in your portfolio should be complete, or, if you’re dealing with a subset, clearly scoped.

Second, the portfolio of controls is everything that the business spends money on, either budgeted as dollars or time. It’s less consistent across different organizations where the budget will be. It’s likely to include the CSO’s entire budget, and some of IT/product development and/or operations.

Third, while I’ve talked about the assets, a financial portfolio can include debts. We can talk about technical debt – the shortcuts we take, knowing that we’ll have to come back and repay it, and we can talk about security debt. Richard Stiennon and Chris Young have come before me in applying the concept, but it hasn’t gotten much traction, perhaps because the asset to debt ratio in security often seems so small.

Which leads me to point four: We in security are hyper-focused on failures because it’s hard to measure what was really blocked. But in the minds of our peers, we’re expensive and cumbersome. We have lots of things in the asset column, and a focus on failures or a focus on risk can distract communication from how our controls help us, or how well they help us.

It can feel like a waste of time to talk about obvious things, but what is obvious from one perspective can be surprising from another. What’s obvious to security can be hard to understand for operations (and vice versa). This failure to communicate exacerbates the tension that naturally results from different prioritization of goals. (For example, both security and operations want to ensure that only authorized personnel or their code can make changes to the live site. Operations focuses on making sure they can make changes, security focuses on ensuring no one else can do so).

Grounding a conversation around a well-organized list of controls and their goals can help everyone be, literally, on the same page.

Related Content In This Series: