Security Maturity: Teams & Their Technologies
TL;DR / Summary at the end of the post. The information shared in this series is derived from my experience building the DevSecOps program at Thermo Fisher Scientific (a global Fortune 100 laboratory sciences company).
Full Disclosure up-front: I am employed as a Code Scanning Architect at GitHub at the time of publishing this blog post.
Security Maturity in the age of DevSecOps
In much the same way as software development has evolved over the last two decades, the definition of Security Maturity has evolved with the advent of DevSecOps. Security has become part of the design and build process, and the maturity required to integrate seamlessly into that process has changed significantly from the days of “put a firewall in front of it and call it done”.
In the current era of DevSecOps, Security Maturity - in terms of both Teams & their Technologies - can be measured across four stages based on the direction they’re heading in (forward or backward), and the outcomes they produce. I think of these four stages as follows:
Immature (teams / technologies)
The immature focus on quantitative measurements 📈 whether that be the number of attacks blocked, the volume of findings produced, or the amount of work required to implement a technology in a DevSecOps process. The numbers are all that matter.
Immature technologies are focused on their solution (and how many findings they produce), regardless of how it might impact the broader process they are integrating with. Likewise, immature teams focus on themselves to the detriment of the other teams - all while forgetting about the DevOps principles of communication, coordination, and collaboration.
Adolescent (teams / technologies)
Adolescents understand the value of qualitative outcomes, but lack clarity on how to go about achieving these outcomes at scale - sometimes falling back into bad habits by focusing solely on quantitative measurements.
Technologies in this category are making strides in the right direction, but often lack sensible defaults, and can be a challenge to configure properly. As for adolescent teams, they often have the right mix of talent - but tend to lack focus, investment, and/or leadership to make progress toward the outcomes they envision.
How to support this content: If you find this post useful, enjoyable, or influential (and have the coin to spare) - you can support the content I create via Patreon.️ Thank you to those who already support this blog! 😊 And now, back to that content you were enjoying! 🎉
Mature (teams / technologies)
The mature comprehend how to efficiently produce qualitative outcomes, and have the right capabilities - people, process, and technologies - to realize such outcomes.
Mature technologies have sensible defaults, understand the process(es) and ecosystem(s) they should integrate with, and produce data that is both easy to comprehend and broadly consumable.
Likewise, mature teams tend to have a diversity and depth of talent that keep pace with ongoing innovations and changes within the broader industries of software engineering and information security. They accomplish this through focused objectives, strategic leadership, and ongoing investments that treat security as a feature of their product(s).
Geriatric (team / technologies)
You will find the geriatrics wherever engagement, experimentation, innovation, and/or learning has stopped. They’ve reached a state of regression by failing to keep pace with the ongoing changes in software development and information security.
In terms of technologies, you can easily identify the geriatrics as those acquired by hedge funds or conglomerates - after which their founder(s) and other key engineering talent quietly departs within a few years. These companies generally innovate only so much as is minimally necessary for marketing hype, but do little to address evolution in the software development process - let alone invest in the engineering required to continue making an impact at scale.
As for geriatric teams - these are the teams where the business, key leadership, and/or senior talent have stopped engaging beyond minimally necessary. When questioned why something is done a certain way, these are the teams that respond with some version of “because it has always been done that way”. They might have the right aptitude to do the job, but their attitude and engagement burnt out years ago.
TL;DR / Summary
When it comes to security maturity in the age of DevSecOps, teams and their technologies go through four stages of growth and regression.
Those that are immature focus inward, and heavily rely on quantitative measurements to show value; Adolescents have a vision for what qualitative outcomes might look like, but sometimes fall back on immature practices; those that are mature comprehend how to efficiently produce qualitative outcomes, and have the right capabilities to do so; and finally the geriatrics have stopped engaging, experimenting, innovating, and/or learning new things - thus failing to keep up with an evolving landscape.
In the upcoming series of posts on each of these stages I will be discussing further indicators for each level of maturity in both teams and the technologies they use. I will likewise share methods for growing your DevSecOps maturity in order to keep pace with ongoing changes in the world of Software Development, and will be sharing elements of my experience growing a mature DevSecOps program in a Fortune 100 company.
As always, thanks again for stopping by to read my pseudo-random musing 😊 While I work on the next blog post about Immature Teams and their Technologies, you can git checkout other (usually off-topic) content I’m reading over at Instapaper, or read my recent off-topic post collecting my thoughts about the global pandemic.
Until next time, remember to git commit && stay classy!
Cheers,
Keith // securingdev
If you found this post useful or interesting, I invite you to support my content through Patreon 😊 and thanks once again to those who already support this content!😊