Last year I finally came around and decided to read “The Phoenix Project”. This book is an amazing eye-opener explaining the current state of IT and operations, in a very fun and entertaining way. The highlight for me was when the security team was introduced like this:
“Information security is always flashing their badges at people and making urgent demands regardless to the consequences to the rest of the organization which is why we don't invite them to many meetings. The best way to make sure something doesn't get done is to have them in the room. They are always coming up with a million reasons why anything we do will create a security hole that alien spacehackers will exploit to pillage our entire organization and steal all our code, intellectual property, credit card numbers, and pictures of our loved ones.
These are potentially valid risks, but I often can't connect the dots between their shrill hysterical self-righteous demands and actually improving the defensibility of our environment.”
I honestly laughed out loud when I read this part, probably because it resonated so much with me. It hurts a little to admit it, but I recognize the past me in that quote. Coming up with unrealistic security threats just because you think it’s expected from someone in your role and using fearmongering to make others buy into your arguments.
It is also a good description of how security teams were perceived as showstoppers for years, and why the term “The department of No” started being used frequently as a reference to security. Since this book was written, many security teams have realized they should move away from the practice of being gatekeepers and consistently saying no.
Many have instead shifted their approach completely, and are now trying to become the “Department of Yes”. Security should no longer be a hindrance to productivity, but give recommendations on controls and measures to reduce risk to an acceptable level. This is, in my opinion, a step in the right direction. Transitioning from gatekeepers to trusted advisors will remove some of the layers of the isolation between security and the rest of the organization. However, this transition comes with risks on it’s own. A mindset that prioritizes always saying "yes" can lead to the acceptance of risks that might otherwise be rejected. While individual cases may seem justifiable, these accepted risks will stack up over time and eventually lead to a weakened security posture.
Rami Mcarthy has written an excellent piece on the importance of a well-considered, strategically deployed “No”. I strongly encourage everyone to read it.
The Modern Security Team
A modern security team should aim to be so seamlessly integrated into the organization that it becomes a natural extension of each development and operations team, rather than an external force imposing rules or a gatekeeper that simply approves or rejects solutions. To be able to create valuable synergies with the rest of the organization, security must be the opposite of what the Phoenix Project quote describes- collaborative, solution-oriented and an enabler of democratized security efforts.
Breaking Down Silos
In our experience, a disconnect often occurs between security and the tech organization. Security engineers must understand not just security best practices, but also how their organization operates. Without this knowledge, security recommendations risk being impractical or unrealistic, which leads to them being ignored and you losing credibility. Close collaboration is the key to understand each other better. Security must embed themselves within development and platform teams. In my opinion this means:
- Being hands-on with code, infrastructure, and deployment pipelines.
- Collaborating on technical solutions rather than just reviewing and approving them.
- Understanding the practical implications of security recommendations by working directly with the teams that implement them.
So not only do we have to be part of the early stages of development (we keep hearing about the shift-left initiatives, which is important) but we have to be part of all stages of the development lifecycle.
Democratizing Security
In some organizations I’ve worked with, security teams have treated their work as something exclusive and secretive, often leaving other teams in the dark. While certain aspects of security must remain confidential, this closed-off mindset does more harm than good.
Make your security tools available across the organization. This is a necessity in order to make each team responsible for the security of their environments. Provide training and thorough on-boarding. And then, to further enhance synergies and democratization, let each team take part in configuring these security tools according to their needs. Let them become security engineers. To achieve this, understanding your organizations ways-of-working is very important. If you can align the configuration of your security tools and its supporting processes with the ones of your developers, you enable them to take part improving your security capabilities.
To some of you this may sound like a fairytale, but I’ve seen it done in multiple organizations. Let me provide you with an example:
In an organization where the standard practice is to define all Infrastructure as Code, e.g. using Terraform, security tools should be configured in the same way. By configuring the tool with Terraform and deploying it through a pipeline, each team can participate in the configuration. This allows other teams to configure the solution that affects them, where they may propose additional detection capabilities, change the conditions of a guardrail or similar. Changes are then proposed through pull requests to the version control system, where the security team can be the approvers.
We also have to make sure that real security threats are flagged in real time and dispatched to the right teams via their preferred channels. We have to be prepared to back our claims with data and evidence. And then, when needed, we must be ready to offer specific, concise and actionable recommendations that takes our architecture and processes into consideration.
Conclusion
The security team described in The Phoenix Project is exaggerated yet painfully familiar. We must move away from the practice of being the gatekeepers and start the journey to become contributors, through hands-on engineering of our own solutions. Getting our hands dirty is the best way to understand our organization and the technology in use, and it’s the only way we can truly make practical and actionable guidance on how to solve security issues. By breaking down silos, embedding security expertise into development teams, and democratizing security tools, we move away from outdated models of control and toward a culture where security is a shared responsibility.
Modern security teams should collaborate closely with developers and operations to build efficient and secure systems, without having to flash their badge.