The preamble: Why you struggle to build a cybersecurity program

I have a reputation for being picky. I'm often the bearer of bad news. It's not so much something I enjoy doing as it is something I'm wired to do. How does that impact the struggle mentioned above? Well, the reality is, a lot of organizations push through that struggle, get results, and think they're doing pretty well for themselves. They usually are the organizations that have high staff turnover, unhealthy conflicts, a bureaucratic and toxic culture, and an unsustainable approach to a lot of things, not only to security.

This is not some kind of workers right type of article, where I try to tell companies what their workers need. For that, let your workers tell you what they want. Instead, this is a security-specific opinion based on real world experience, aiming to showcase the typical struggles that even the most seasoned and experienced engineers and leaders face in the world of cybersecurity.

Organizations that fail to get the basics right will keep repeating their own history and keep wasting money and human effort for nothing. Burnout is very common in those environments, and skilled employees often leave for greener pastures.

Why is the struggle so painful and real? Let's discuss.

You don't know where to start

You're often thrown into the line of fire with little to no training. "Swim, come on, it's easy!", you might hear a senior leader say. You may often swim and maybe sometimes sink, but that doesn't make the approach fundamentally sound.

Well, just like an application's SDLC, a prerequisite for your program is requirements elicitation. Why do you even need that SIEM? That should be a question you are able to answer with ease. What's the road that leads to that? It obviously isn't just about requirements, as those can be vast, vague, and nebulous. For example, a requirement can be that our organization needs to be PCI DSS compliant. Fair enough, what does that mean and what do we do about it? Well, we follow the methodology. What methodology is that? Let's be patient here, I'm getting to it.

You don't understand the dependencies

Assets beget risks beget more assets to protect those previously identified assets from risks. Sounds messy, doesn't it? It does if you're starting with the wrong things, or not focusing enough on fundamentals (again). Step 0 in your program building, at least in a practical sense, should be getting your asset strategy right. "But Roland, what about risks and that shiny new tool I heard about and ChatGPT?"... Well, if you don't have solid asset management, your risks will always be inaccurately perceived. That shiny new tool? It needs solid risk management to determine if it's useful. If you spend money on it without that, you're the real tool (sorry). As for ChatGPT, it's one of those tools! You need to evaluate whether and when you need it.

I hope you can sense where I'm getting at. You need to follow the fundamental steps and create a program built on solid foundations. What does that look like? Let's take a look at the diagram below, it's a start.

Your ultimate goal is to minimize risks, but that doesn't mean it's your starting point. You start by identifying and evaluating your assets to know what risks apply to them. Then you inform yourself on how much risk is acceptable based on the organizational strategy and best practices. You then create metrics to track your program's performance, and set goals to achieve.

Honestly, all of this should even be preceded by organizational values and culture. This is a prerequisite to determine a lot of these matters. You should be aware of the approach and create a strategy that matches it.

You don't know what each individual element should look like

Even if you understand the methodology and want to follow a step-by-step approach to solid fundamentals, sometimes you don't know what to do about a specific element in the process. For example, let's take risk assessment. A lot of people don't understand what it is or where to start with it. Luckily, I have an article about this topic. For other topics, and in general, there's no easy way. You have to do the work and conquer the concept. My advice? Understand more that what to do and get to why you're doing it.

Let's look at the diagram below:

The lesson here is: everything should come from a requirement. If you don't know what the requirement is and you're applying the measure anyway, go back to the drawing board. Whether you answer the requirement with a technological measure, a policy, or anything else for that matter, is called control design. That's our destination.

The golden toolbox

Here's what your program should be built on, I call it "the golden toolbox":

• An asset management strategy, hopefully heavy on automation
• A risk management approach, hopefully with costs in mind
• A solid knowledge of your requirements and everything relevant in your ecosystem
• A battle tested incident response and recovery plan
• A wealth of reasonable policies that take psychological acceptability into account
• The right technology to help you achieve your controls

Just like a golden image pipeline, this toolbox is the prepackaged standard to aim for. If you're missing any of the fundamentals, you will struggle, hence the article's title. While asset management is the hammer, you don't screw things together with one of those. You need the risk management screwdriver. While the shiny tool can be the best drill out there, sometimes what you need is an adequate wrench. Again, requirements.

Let me help you build better

Thank you for reading this long. I'm always amazed when people make it this far, even after many years of this writing experiment. I hope you learned something useful, and that you feel like the time you spend reading my article was time you spent well. Do suggest some more topics if you feel like it, hit that "Message" button and let me know what's on your mind. I'm also in the process of creating something cool, something that will help you build better, that's why this article is a "preamble". Preamble to what you might say? Well, you'll just have to wait and see. For now, enjoy the rest of your week.

Good luck, and keep on keeping on.