The Three Phases to DevOps in Security (The Real Magic) - PART IV Change Technology
This is part four 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….
By now, the change in culture should be starting to manifest itself. You should have a team that is on a path to functioning, collaborating and looking for ways to save time and effort. They know who their customer is, what they want to do, where they are frustrated and have surfaced these issues. They communicate and look to collaborate regularly outside of their inner circle. They test ideas publicly, are eager to learn more about how they can do better and contribute back to the company and look to help solve problems, even if they aren’t their own. They know the priorities are helping pull in the same direction.
I now use the techniques to focus the teams on solving problems. These examples highlight common problems and pain points that I find particularly rewarding and illustrative to the teams who go through them.
1. Automate the tracking of work: Kanban boards are beautiful to see, but Stickies too often lose their “stick”, particularly when someone rubs up against them. Physical boards are also particularly problematic when your teams are geographically distributed. Look for tools such as Jira that can create a digital version of your Kanban board, but make sure that what you use and how you use it maintains the objectives of making the work visible and gives you a view into capacity. Don’t let the technology drive you – drive the technology.
2. Build testing for quality: I task the teams to look at how they achieve quality now – usually things like manual code reviews by security, and ad-hoc scans. I ask them how consistent it is (and even ask them to measure it). Clearly humans cannot be consistent in scans but can detect complex things that systems may not. I ask them the value of consistency in simple findings versus the value of inconsistently identifying complex findings. We weigh the options. We then (almost always) agree that it’s better to start with consistency in simple findings. We examine the model (process) for testing that is in place, we refine that model and then we look to build automation to make it consistent and faster. We continuously look for new ways to increase the capability to discover more complex findings. We also acknowledge that the manual process is needed, and how to achieve this without affecting quality of results and speed of delivery. Usually this means we have heavy reliance on automated tools for immediate releases, and reliance on quarterly manual reviews by humans to look for more complex problems.
3. Move documentation into code: Certain documentation suffers from being out-of-date as soon it is written – particularly configuration standards. The process for defining and negotiating a configuration standard comes out of people and process skills we discuss previously. Now think of how you can leverage those same skills to devise a way to think differently about documentation? If the code used to build systems is traceable, approvals are traceable, won’t it be more accurate than a document? Same can apply to asset inventories, network access controls and user role definitions. This process shows value in the customers (what do they want), devising and testing ideas to address it (automation?), learning and updating the ideas and implementing changes that improve the process by lessening the pain. Use the opportunity to walk through designing process first, and then layering technology on top of it. Keep focused on the objective (outcome), and ideas that span the range of process and technology. The collaboration with operational teams will be appreciated and the efficiencies (and accuracy) gained will be seen by all.
4. Add data: Create measures, metrics and analysis that can tell you how you are performing and improving. Leverage existing tools, add tools and build analysis that can inform you about how well you are achieving the goals of becoming DevOps, as well as how well you are achieving the objectives of the organization. I like to measure 'quality' – defects per project put into production; time to correct defects; % of critical vulnerabilities corrected in time periods; number and percentage of systems not patched in 30/60/90 day periods. I will look for metrics that will inform where work needs to be done. The metric is not the outcome, but rather an indicator of success or failure of an approach.
5. Create testing environments: Since this is an IT organization, give your teams somewhere to learn. Since cost is often a factor, use old retired equipment to test. Leverage virtualization and cloud to be testbeds for new concepts. Give the team the opportunity to learn in a safe environment so that when they work in production environments, they have raised their skills and confidence.
These technological techniques are core to Virtual Clarity’s methodology. Reach out to Virtual Clarity to see how we can act as that facilitator and send you on your journey…