![The Power of Dojos and ChatOps in Security Knowledge Share [CALMS for DevSecOps: Part 5] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F91793c9f-b4ae-4c9e-a36e-2c09893911b9%2Faid_field_img__233d7ed850fcfd7b636d98aa024f3946.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_BHtzFuj7x8fHcssjFHrhmmifkwhC){kind=small}
Welcome to the fifth and final part of this blog series about DevSecOps through the CALMS lenses. We’re finishing this time with:
SHARING
To recap, DevSecOps has two main drivers: security is a constraint in most organizations and has been an afterthought in the DevOps world. DevOps seeks to optimize the flow of value outcomes from idea to realization through the removal of bottlenecks and amplifying feedback.
In the automation post in the series, I outlined how we can address the constraint with automation practices, but I also have intimated there is a cultural approach to addressing this problem also, and it’s all centred around effective sharing of knowledge. A pattern I have advised on and seen working effectively now on several occasions in my clients is for one or two members from the ‘ivory tower’ of security to embed and co-locate themselves in a product team for a temporary period—around three months works well.
The 80:20 rule appears to apply here; 20% of the knowledge is needed in 80% of the situations, so the required amount of knowledge rubs off quickly when a small group of humans are working closely together. The security experts can then move onto more product teams—the knowledge they will have gained during this process will accelerate the knowledge sharing in the new teams they visit.
This does require getting security on board with the DevOps vision the product teams are working towards and needs some open-minded people willing to change their day-to-day working practices. Leadership has to rubber-stamp it and we have to make the trade off between ‘we can’t find time to save time’ and ‘if you make yourself break the cadence now, you’ll reap the reward of increased capacity injection later’ work.
These agile, DevOps, DevSecOps advocates, call them what you will, can also be encouraged to do other things to help share the knowledge. For example, they could start a DevSecOps community of interest/practice or guild where they invite people (anyone that’s interested) to participate in workshops, meetups, online spaces or even hackathons and share their insights that way.
Whilst all this knowledge sharing is going on conversationally, other things can happen too to make the knowledge widely available through self-service and to accelerate learning. Most organizations we work with use some sort of wiki, whether it’s Confluence or Teams or something else. A common fail though on these sort of platforms is that they become sprawling and difficult to navigate. They do need some housekeeping too.
Most of the agile and DevOps world now operates in Jira (there are other backlog management tools available but this is by far the most popular and ubiquitous in our experience). And everyone knows how to use a group chat tool (you have WhatsApp, yes?). Slack is by far the most popular in technology teams but Office365 is available almost everywhere and comes with Teams. Both of these have the capability to integrate with tools in the DevOps toolchain and group chat + tools = ChatOps. This is one of my favorite quick wins for DevOps evolutions—and I am always asked for quick wins. Fast and easy to get set up and to use, it’s a collaboration platform that builds trust through visibility and can improve recovery times and system stability.
So, for example, instead of going into a war room and getting people on a conference line when an incident happens, if you’re using ChatOps, you’ll open a channel and everyone will pile in there. Your team may query Dynatrace for some fault diagnosis, or Jenkins for information on the latest changes or you could push a new change to fix it through Puppet—all sharing the same pane of glass. When you’re done, the retro is complete and an experiment set to make sure the incident doesn’t happen again, you can save the chat record back to a Jira ticket.
Or another example, a team’s reached the end of their sprint and are ready to release. Some of them are in an office in Kent, the garden of England as we like to call it, and some of their teammates are in Bangalore. By setting up a chat channel they can monitor all the code commits real time, check the continuous integration server is passing the tests (including the security ones!) and watch it go into production—and even stay and monitor it there if they want. Again, the chat record can be saved back to the product backlog.
And my final recommendation for DevSecOps sharing is the dojo. Popularized by Target, dojos put one or two new(ish) product teams into a new environment with SMEs (like security) on hand in the same place for a few weeks and set and pursue an aggressive goal while practicing new ways of working. I particularly enjoyed Capital One’s talk from DevOps Enterprise Summit London in 2018, where John, the Product Owner, sets the tone for psychological safety, with the statement ‘things are going to get messy’ which brings us full circle to the first post in this series, about the cultural elements of DevSecOps.
I hope you’ve enjoyed this blog series on DevSecOps and CALMS. Please leave your comments below.
Machine Identity Security Architecture
Related posts