The Three Phases to DevOps in Security (The Real Magic) - PART V Monitor for Drift
This is the final installment in a five-part series. If you’d like to understand more of the stories behind this work and how it can be applied to making your security organization more effective, collaborative and engaged, contact us….
As a leader, you are responsible to ensure the techniques do not slide into misuse and legacy patterns. There will be a tendency for that to happen. New team members will not come in necessarily with the same culture, and some of the techniques they use may not be the same. Watch for these signs and address them early:
- Attachment to a single solution coupled with an inflexibility and unwillingness to try and disprove it as worthy: This will typically manifest itself in beliefs that a solution is 'all solving', and the solution comes up regularly at random conversations. Address this by inserting yourself into the conversation and asking for ways to disprove it – but making it about the idea, not the person.
- Continued use of email for conversations: This is an old and hard habit to break, and you will find team members (and even yourself) falling into this trap. It is especially easy to slip into when your operations and people are geographically distributed. Address this by asking for a call between parties buried in a long email chain. Don’t be the one to lead the call, but instead make sure it happens. If the participants in the email chain are made the owners of the conversation, it makes the pattern something that rubs off on them.
- Believing in mandates based on external forces: This is when you find that “what-needs-to-get-done” is being driven by a compliance or regulatory requirement, auditor or other external entity instead of by the company and its priorities. You can identify this when people say “We have to do this or we will fail.” Start by asking “What is the real monetary impact if we don’t do it?” I ask the business owners of the affected area what they think the impact is, and the probabilities it would happen. This reminds the team that our customers are outside of security, and that the company can accept a risk. It is our job to inform them of the threat, and the probable impact, but not to say that something is mandated. When dealing with auditors and external entities offering 'advice', I either go through the same risk exercise so we can debate the importance of the finding or abstract the finding into an objective the auditor believes is being missed (given that most findings include an irrelevant detailed action to remediate the finding). I ask the teams within the company how the objective could be satisfied. Now the company gets to decide how to solve the gap in objectives that the auditor finds, or even decide if the risk is something they choose to accept.
- Continuously revised priorities: If this is a result of management decisions that reflect an indecisive management, as CSO, I shield them from this. I believe that the team should feel as much stability as reasonable – given that security itself is chaotic and unpredictable. If this is a result of internal actions, I pull the team together and have a conversation about how and why these shifts are happening. If the team believes they are appropriate, even if disruptive, then I let them continue. The key is that they have the opportunity to voice concern about any disruptive changes in focus and priorities.
You have now started the journey on a path to creating a DevOps culture. Keep your eyes on the goal – maintaining the culture so it creates the outcomes you want.
Want more information? See Daniel in London on March 22 at DevSecOps Days - more info here.