This is the second in a multi-part series on information security anti-patterns.
Too often in our technical due diligence and workshop engagements we encounter development teams who jokingly refer to their CISO as "Dr. No" or the entire Information Security department as the “Department of No.”
While certainly no company wants a security breach and the ensuing fallout of bad media coverage and loss of business which can follow, it also doesn’t mean the InfoSec team should hold the entire development team hostage awaiting to be graced by approvals or input – and then in many cases, just told “no” and have to start from scratch.
Definition
Gatekeeper anti-pattern occurs when all security decisions must go through the CISO or a ticketing/queuing process for approval.
Why the Gatekeeper approach is a bad idea
Security must enable business, not hinder it. Years ago, I attended a training for private “bodyguard” executive protection folks as I was considering going that route in my physical security career. It was conducted by a former head of the Secret Service who had been in charge of Presidential Security for the United States of America.
He shared that he was often approached by security professionals and asked how to create the perfect security plan. He said it was simple, put the President inside of a concrete bunker hundreds of feet below the ground in an undisclosed location for four years. Only problem? No reelection and the President couldn’t do their job.
Security can't operate in a sanitary vacuum. It must bend and flex with business needs and enable business success.
If your security team is not a part of the solution, then they are a part of the problem.
Common denominators of Gatekeeper Anti-Pattern
- CISO does not have a coding or development background.
- Security sits in a building or location behind a locked door separated from development teams.
- Development teams are required to submit a ticket for security to review exceptions.
- Security is not held accountable with development teams for deployment objectives.
- Security is a centralized function, and not distributed.
- CTO, CEO, and others have been convinced by fear rather than reason that the CISO knows what he or she is doing.
- CISO is not held to revenue objectives as part of his or her compensation package.
- CISO’s first response is “no” when asked to think about something differently.
The irony of course is that while the security team thinks that they are providing the best in class security by saying no all the time, teams find creative workarounds to get things done without security involvement and the overall security of the organization is weakened. Individuals might get caught not following security processes, but they have decided the risk of the pain of getting caught is less than the pain of trying to work with the security team.
Correct pattern:
Fixing the anti-pattern requires building a culture wherein the delivery teams OWN security and have the training and principles to help ensure they create a secure product and solution. Security can NEVER be centralized and be successful - it MUST be distributed and owned by the teams doing real work with great support from a centralized team.
CISOs and their InfoSec teams should:
- Be embedded within delivery teams – or at least have representation with a security-minded engineer on the team who has direct access to the InfoSec team as part of a guild or interest group.
- Security must be held accountable to delivery dates and desired outcomes of usability for products just like every other member of a delivery team.
- CISOs should have their compensation package tied to company revenue and meeting OKR objectives along with the rest of the engineering leaders.
- Become the team of “we can do that” – and drive for an acceptable outcome that factors risk AND business needs in real time, not in a sequence with a potential dead end.
Security is always going to be strongest when it is a distributed feature of a product instead of a “must do” bolt on to a product. When security is part of the culture, it becomes a natural extension of what everyone does. The only way this works is when the benefits to building a secure product outweigh the pain of having to work through a security process for an isolated and removed team of paranoid practitioners.
Summary
When the Information Security department is an enabler of business success, it becomes a shared responsibility of all team members and teams work together to build secure products.
If your security is the “department of No” you are likely not really all that secure. A measurement of lack of previous breaches is not a predictor of future success as the target is always moving and your company may not yet be on the radar of those who delight in doing you harm.
We conduct security high-level organizational assessments as part of our due diligence process. Contact us, we can help.