Security Maturity: Immature Teams
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.
Recapping Security Maturity in relation to DevSecOps
As stated in the first post in this series - in the age of DevSecOps, security has become part of the design and build process; the maturity required to integrate seamlessly into the development process has changed significantly from the days of “put a firewall in front of it and call it done”.
As it stands today, Security Maturity - in terms of both teams and their technologies - can be measured across four stages based on the direction they’re heading (forward ➡️ or backward ⬅️), and the outcomes they produce. I think of these four stages in terms of breadth and depth as follows:
Immature Teams
To put it bluntly: immature teams are self-centered. They prioritize reducing the amount of work they need to perform at the business’ and their colleague’s expense, and they fail to recognize that they’re part of a larger team of security and software engineering professionals. This was very-much the way I first ran my team when I started at Thermo Fisher Scientific; learn from my mistakes.
Communication
With immature teams, communication only happens after they’re ready to tell leadership what they’ve done - or when they need some other team to start working on something. Immature teams aren’t asking questions, building relationships, or attempting to understand other’s problems.
This leads to immature teams performing work that often negatively impacts others around them. Sometimes that means buying technologies other teams aren’t ready to integrate with, or building solutions that require other teams to implement certain functionality - often without consulting the other team about their priorities.
To say this leads to significant friction between teams would be an understatement.
Coordination
Coordination only exists between immature teams and other parts of the organization when they’re imposing a new solution on another team, or when forcing an integration between something the immature team has built and a technology that another team is already using. Again, there is little consideration when it comes to building relationships and understanding other’s problems.
When immature teams fail to coordinate with the rest of the security and software development organization, they become disruptive - and eventually, ignored. If an immature team starts throwing a fit about how other teams aren’t working with them, you can safely assume it’s due to a lack of empathy and communication - which in turn means little (or no) coordination takes place.
Collaboration
Collaboration can’t happen without communication and coordination, so it is very rarely seen from immature teams. If anything, acts of collaboration should be viewed as a sign of maturity taking root. Collaboration requires people to act in the interest of themselves and others for mutual benefit, and when it starts happening good things follow.
That being said, sometimes collaboration happens because it is imposed from leadership - or is performed selfishly up until a point where the immature team no longer benefits from ongoing collaboration. This is an unfortunate regression that happens when there’s a lack of empathy for the priorities and experiences of others.
If this type of regression happens enough times, other teams will stop collaborating - effectively ostracizing the immature team and keeping them from achieving their goals. This is usually when re-organization and/or leadership changes take place in order to rekindle organizational relationships.
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! 🎉
Success
For immature teams, success is measured by quantitative outcomes: the amount of applications scanned; the volume of security findings their tools uncovered; the quantity of tickets opened; the amount of attacks they blocked by the application firewall. Don’t get me wrong - metrics are important, but they’re not the point.
Metrics should be measured alongside qualitative outcomes: the amount of applications scanned on pull request; the volume of remotely exploitable security findings their tools uncovered; the quantity of tickets the developers closed before releasing to production; the amount of attacks blocked that would be exploitable without the application firewall. These measurements speak to the most important goal of any security organization:
To discover - and make informed decisions about - risks to the business.
Growing Up
What immature security teams need in order to “grow up” is perspective. I was very fortunate to have a great leader and friend to guide me - Bryan challenged me to grow out of the immature ways I first started implementing the DevSecOps program at Thermo Fisher, and helped me understand that information security is a team sport.
Unfortunately, not everyone has that mentor and/or friend they can lean on to help give them perspective. As such, I cannot think of a faster way to gain the perspective immature teams need than through three must-read books for DevSecOps practitioners:
- The DevOps Handbook (part six is about Security!)
- Agile Application Security
- The Unicorn Project
Read these books cover-to-cover, and take notes! I found that reading the first two books became easier when I applied the Pomodoro Technique to set-aside focused time for reading and reflection. Physical hourglass timekeepers are great for this, because you can’t pause an hourglass.
TL;DR / Summary
The challenge with immature teams is that they are self-centered; they fail to recognize they’re part of a larger team of security and software engineering professionals working toward the same goals and outcomes. Part of the reason they face challenges when implementing their work is through a failure of communication.
Don’t get me wrong, such teams do communicate - but that only happens after they’re ready to share with leadership what they’ve accomplished, or when they need some other team to start working on something. Likewise, coordination often exists between immature teams and other parts of the organization when they’re imposing on another team.
And frankly, collaboration can’t happen without communication and coordination. Unfortunately, with immature teams collaboration usually ends when they’ve got what they needed - even if their collaborators have not. Once immature teams have successfully hit the metrics they were targeting (more vulnerability findings; more apps scanned; more tickets opened), they punch-out.
More than anything, immature teams would benefit greatly by gaining some perspective. They can do this through asking questions, building relationships, and attempting to understand other’s problems. Short of role model leaders and mentors, the fastest way I can think of to gain this perspective is through three must-read books for DevSecOps practitioners:
If immature teams and their leaders leverage the Pomodoro Technique to set-aside focused time for reading these books cover-to-cover, and then reflect on what they’ve read, they’ll grow by leaps and bounds.
As always, thanks again for stopping by to read my pseudo-random musing 😊 While I work on the next blog post on Immature Technologies, you can git checkout other (usually off-topic) content I’m reading over at Instapaper.
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!😊