Risk management is a team sport

Why trying to manage security risks by yourself is a mistake

‘Team of people playing with a ball that has risk printed on it’ / DALL-E

Far too many times I hear stories or comments from people dedicated to information security that nobody else cares about security, that they have a hard time getting other teams to respond to security issues, or cannot find a way to partner with other teams and security tickets just pile in an ever growing backlog.

I, myself, have found saying the same thing before. Frustrations mount, negativity builds up, and despair ensues. But what helped me get out of this mindset was to think of how can we do things differently. Whenever I hear people say that we have been dealing with the same security problems for decade with no end in sight, I always follow up with: ‘Well, we have also have been trying to solve them the same way making little to no progress’. Sounds like the definition of insanity, no?

My take is that the reasons for why security risk management fails in most organizations are:

• Identification of risks done in silos

  • Risk identification done on systems security teams don’t understand

• Vulnerabilities often conflicted as risks

  • Too much effort spent on calculating impact and probability but zero effort spent on communicating anything meaningful

• A lot of inertia in the beginning ending in tickets yielding perfunctory responses

  • Only caring about security risks

Risk identification from silos

One pattern that I see quite often is that security teams believe that the responsibility of identify risks only belongs to them. This creates the scenario where security teams attempt to identify risks on systems that they have no idea about and do not involve the owners of the systems to truly provide deeper context and understanding. The typical result is security teams screaming into a void and complain how they can’t get anyone to fix the issues they’ve discovered. The pain is only increased by the fact that more often than not, the owners of those systems never get to hear from security except for when ‘bad’ things are discovered and there is a demand for some type of work to be done.

Instead, allow the system owners to perform their own risk reviews. Encourage that all risks are evaluated and identified, not just security risks. Their knowledge of their systems will surface more risks than if a security team attempts to do this on their own. You’d be surprised at the results! Create a process or a habit to have the teams do this periodically, then build the backend system (people+process) to manage these risks and get commitments for how progress will be made against them. Not everything needs a $ impact associated to them, allow the system owners to have a bigger say when it comes to impact and probability.

Vulnerabilities often conflicted as risks

Confusing vulnerabilities for risks can create the scenario where too much work is asked for other teams to take action on but the impact of that work isn’t fully understood. When execution hours are finite trade-offs are a must. When vulnerabilities are treated as risks makes it very difficult for those who are making those trade-off decisions understand the priority of the work. Especially when the security team spends more time and effort calculating probability and impact using terminology that is not shared across the board. The impact message ends up not landing the right meaning and causing frustrations for all parties. Every hour spent working on non-business growing tasks is a debt against credibility and if not balanced carefully, that balance will turn to zero.

Vulnerabilities are just that. They can be used to influence risks identified, but do not bother stakeholder teams with a bunch of vulnerabilities and try to sell them as risks.

Good inertia at first that ends up in lackluster fashion

Sometimes teams begin with good inertia at identifying risks by involving their stakeholder teams but then finish the work in the most lackluster way which is creating a ticket per risk on that stakeholder team’s backlog or during ‘collaboration’ of identifying risks, only caring about security risks. This combined with the eternal backlog of vulnerabilities means that the teams with tickets assigned to them will never finish the work, if they ever get to it. But, can you blame them? Sometimes we forget to realize that these teams have a backlog of their own and while risk management is important to every organization, security work has a similar cost as working on tech debt does.

What happens when only security tickets are seemed as more important than any others is that those stakeholders will no longer want to work with their security counterparts. Why? Because we’re just throwing problems at them rather than figuring out a proper workflow for how to address the issues. For example, proper vulnerability analysis and negotiating proper SLAs for remediation of those vulnerabilities that truly matter.

Another example here can be identifying systemic problems and enabling the teams by building the guard rails or golden paths to make sure these issues do not surface again.

Conclusion

With everything, when you share a problem with a diverse set of mindsets, you get a more complete solution. When you try to tackle a problem alone, particular in an area that you do not understand, it’ll only result in a mound of frustrations. I truly believe that people want to do the right thing, but if doing the right thing is always more difficult to do than the easy thing, we’re setting ourselves up for failure. Every execution minute has a cost, security has to be willing to work on establishing a prioritization framework that recognizes that cost and realizes that it’s a broad thing to solve rather than just focusing on what’s top of mind for security.

However, risk management is a very hard problem to work on and like anything else, needs to be iterated over and over. Perfection is an impossible task so my advice is to always seek for what’s best at a point in time.