Why you struggle to turn risk assessments into control design (and what to do about it)

Back by unpopular demand to tell you about problems, are you happy? No? Too bad, I'm doing it anyway.

We often excel at controls, or at least at proposing them. That's what we do, we're security engineers, we know how to protect, even when we attack. What we absolutely fail at way too frequently is linking those controls to a justification, a "why" if you will. Why should we have this overcomplicated authentication scheme? Just because?

I get that you can explain the hell out of it technically, what threats it's supposed to defend against, and how it does that exactly, but that's not quite enough when dealing with an audience that doesn't speak the same language. In fact, the nature of the entrepreneurial world being what it is, this is often the audience you get when you're trying to decide on what controls to implement.

So, until we come up with a different way to run our organizations, we need to learn how to do things right. To do that, we need to describe the problem first. Let's do just that, shall we?

You don't have a solid enough risk register

This in itself has root causes, I discussed them already in this article. As a brief summary, most of the time we grossly misunderstand risk assessment and therefore fail to make it make sense and bring value.

How does this relate to control design? Well, that's the thing, it's a crucial even if complicated input for us to design controls. Why do we need that authentication process? To treat that access control risk. Why should we implement device encryption? Well, to protect our data in case of theft of course, a threat we managed to identify and quantify in our risk register hopefully. You get the idea.

The fact of the matter is, if you don't have a risk register with a list of identified risks and a list of risks that need treatment, you will struggle to come up with the necessary controls that your organization needs. I will even argue that risk treatment is all about controls, it can even BE controls, just under a different name.

If you suck at risk registers, you will fail at risk treatment controls.

You don't understand the layered approach

Consider this below diagram with me for a second:

This is what I like to call "the risk onion". To make it more official and corporate, let's call it the layered approach to risk treatment. Have you ever thought of policies as controls? You haven't? Well then you need to understand this layering a little bit better.

In fact, this is a grotesque and almost criminal oversimplification, and I recognize that fully. It's still a useful tool to explain the concept, so please bear with me for a second.

Failing to understand that controls come in all shapes and sizes means that you will fail at optimizing them for the risks at hand. Why is that? Because it's much cheaper to treat risks statically than dynamically. The English translation: Drafting a document is cheaper than creating technology. Sometimes, that's all you need, even if the dynamic control of shiny technology is a much stronger one.

You don't know the technology well enough

It's inevitable that you will need some dynamic and technologically advanced controls in your program. There's no escaping the technical treatment of some risks. As technology continuously evolves, we find ourselves lacking some skills in the security world. We need to know how things work outside of our bubble. This is partly why I sat for some certification exams that have absolutely nothing to do with security (AWS Data Analytics Specialty for example). I wanted to understand how things are done, what the cutting-edge technology is, and how I can interact with it in general. This, in turn, helped me know how to secure it.

If you don't know what the technical world is infatuated with these days, you're behind on your security duties. If you know how to describe a risk but can't give a technological recommendation to treat it, you will have failed at your mission to secure the organization.

What to do about it

I implicitly gave you 3 action points, and told you to take a hard look in the mirror so that you can do this security thing better. Those action points are:

• Learn how risk management works: Consult popular frameworks like COBIT and NIST CSF to learn how to have a solid risk register that you can refer to as a snapshot of the enemy to defend against.
• Learn the layered approach: Understand that different risks can be treated differently, and that the same risk can be treated variedly. Covering a potential risk with different controls and understanding the nuance that exists between different control types is absolutely crucial.
• Learn technologies outside of security: Understand what developers use, what data scientists use, what administrative assistants use, and so on. If I have to choose one thing you should learn, it would be Cloud Architecture. This will help you understand how modern workloads work and in fact will often mean that you will learn how to secure those technologies, because security is included in that knowledge due to the service-based model of those offerings.

This is a good place to start, I hope you find it useful and it helps you do better!

It means a lot that you decided to read this far

I'm often bemused by the fact that people read my articles. I can't get used to it no matter how hard I try. Thank you for reading and spending a few minutes of your time with me, I hope this was useful knowledge for you that made you feel like it was time well spent. If you have any questions or feedback, or if you just feel like saying hi, feel free to do so by sending me a message on LinkedIn. I'm here for the humbling thrill of internet attention, but I also am trying my best to bring value to this corner of the internet. Check out my Amazon author page if you'd like:

https://www.amazon.com/author/roland-gharfine

Until next time!

Good luck, and keep on keeping on.