Snippet #3: The Workbench - Understanding Requirements (chapter 3)

Below is an extract from chapter 3 of my upcoming book, titled "Real life cybersecurity: How program building actually works". It draws an analogy between a crafting workbench, and the cultural context of an organization in the cybersecurity world. You can find the book at this link: https://a.co/d/eRudF4m and the full table of contents at this link: https://www.dhirubhai.net/posts/roland-gharfine-1a7057100_askroland-cybersecurity-linkedin-activity-7140185653924782080-IK8z

You can also read the book introduction here: https://www.dhirubhai.net/pulse/book-introduction-real-life-cybersecurity-how-program-gharfine-p6kde

It's currently only available for pre-order as a Kindle ebook version, with the release date set to January 14th 2024 (delayed from December 31st for logistical reasons), and the paperback version upcoming on January 31st 2024. Enjoy.

Every now and then, it’s useful to zoom out after zooming in for so long. Just like a skilled photographer occasionally retreats from looking straight down the camera’s sight to observe the surrounding elements, so does a skilled strategist take a step back and observe the effects of foundational decisions. We’ve made so many of those decisions in the 2 most recent chapters, that it can be surprisingly easy to forget the big picture while focusing on the intricacies of every little cog that makes our machine turn.

So having said that, why are requirements the workbench in our workshop? To answer this question, let’s talk about why workbenches are useful. A true craftsman will tell you that a sturdy and comfortable workbench can set the frame for the entire workflow, and help them masterfully manage all things from a predefined structure and space. It can also store your tools, serve as a support for creative structures using those tools that achieve complicated actions, and even provide a space for collaboration. Requirements are the supporting structure and the frame we need to really figure out why certain things need to be done a certain way. If we understand our requirements, which as we will discuss in this chapter, means to understand the organizational context, we can put our formula, the golden toolbox which this part of the book is named after, into real and tangible action.

Remember the football field analogy from earlier (the risk appetite section)? In that analogy, the requirements we are operating under are more like the relevant football federation that governs our league. For those of you who could be bothered to follow Football, you’ll know that there are leagues that are known for physicality, others for flair and finesse, and others for solid fundamentals and tactics. Some leagues value developing youth players, some others value instant and continuous success, some teams are built for continental championships, and some teams are built for domestic domination. I’m not here to pretentiously flash my football knowledge, but rather to point your attention to how truly fundamental the art of understanding requirements is. In this chapter, our job is to understand why requirements matter, what sets or affects our requirements, and how the requirements applicable to our context can affect everything else in said context. Let’s begin managing our football club (or looking at our workbench if you still prefer the main analogy), shall we? Note: Please do not under any circumstances manage like Ed Woodward (of Manchester United). It’s been a rough few years folks, and no amount of highlights from the Alex Ferguson years can drown my sorrow and football thirst. Send help if you read this message.

Why does the organizational context matter? Why does culture affect our cybersecurity program and how? The short answer is that they constitute our approach to everything, and in the interest of integration, we want our approach to cybersecurity to be consistent with that. The long answer will come in this chapter.

So, whether you care about my football obsession or not, the organizational context matters, I think we can agree that this is an uncontroversial statement that applies in the vast majority of cases. But what are the details around that? How exactly does the organizational context affect things, and what do we stand to gain by knowing this simple but fundamental fact? Again, we would like to draw useful lessons from the knowledge rather than just lay out the knowledge for the sake of feeling good about ourselves. Let’s talk about it, and learn together.