How to Close the Security Divide with the Right Team Structure

Written by Darya Winters | Nov 14, 2018 11:18:44 AM

Organizations today are taking great strides when it comes to innovation, but unfortunately security and governance continue to lag behind. One recent study revealed that, although the DevOps ratio is now 10:1, the DevSec ratio is still 100:1. We need to understand what’s causing this gap and what actions we can take to bridge it.

Earlier this year, Sonatype put together an article looking at what enterprises can do to bridge the gap between software developers, IT operations, and security. We’ve summarized their thoughts here, but we encourage you to read the full article if you would like to learn more.

Understanding the Gaps in Dev(Sec)Ops

It’s important to reinforce that day-to-day security measures like checking for third-party vulnerabilities and responding to incidents aren’t the cause for concern. Instead, where voids tend to appear is with things such as hacker mindsets (proactively searching for new possible attack vectors) and in performing tasks like in-depth risk analyses and threat models, all of which play key roles in enabling enterprises to create robust, holistic security architectures.

Two Models for Addressing the Problem

1. Fully Shared Responsibilities

This framework calls for each development team to integrate at least one T-shaped individual (someone capable of many things and an expert in one) who specializes in security. This person needs to be able to translate security threats into actionable items that their team can implement and communicate concerns in ways business owners and leaders will understand.

Keep in mind that the security-focused person shouldn’t be allocated all of the security work otherwise the silo will simply be transformed from a macro one (where there’s a distinct security team) to a micro one (where there is an isolated team member). Over time, the job of doing security analyses should be spread throughout the team so that the T-shaped person can stay on top of best practices, find new tools and methods, facilitate workshops, and ultimately lead security strategy.

Pros

Cons

Reduce incidents more quickly and prevent them down the road by increasing the ownership security has in the development of new products, services, and solutions.
Increase the Dev-to-Ops-to-Sec ratio. Not only will this embed security within your development processes, but it will also allow more people to bring their diverse experiences to the decision-making table.
Signal to your employees and end users alike that security is a top priority for your organization.

The cost associated with finding and recruiting the right people can be high, and the transition itself can take time.
High-performing, autonomous teams tend to thrive on stability and will be extra sensitive to personnel changes.
Teams may feel the lack of centralized contact for security, which is why channels of communication always need to be open between team members and security-focused persons within the enterprise.

The Final Word

A fully shared responsibilities model is often ideal for companies with cross-functional, autonomous teams that each work on products or services with very different risk profiles. Spotify is one of the largest and highest-profile companies to have adopted this approach.

2. Security as an Enabling Team

In this model, a central security team supports multiple product development teams, getting involved from day one of a project to make sure they can provide security-specific feedback at each stage of the process. An important caveat here is that the security team shouldn’t actually perform analyses or implementations. They should simply promote best practices and provide guidance on which other teams can act.

Switching to the security-as-an-enabling team model can sometimes be an easier transition for enterprises because it doesn’t require the same degree of structural change that a fully shared responsibilities model does. Ultimately, the biggest challenge with this approach tends to be making the shift without confusion or regression.

Pros

Cons

The timeframe to enablement is shorter.
Enterprises don’t need to hire too many new team members, avoiding hassles associated with recruitment and team disruption.

Effective communication is critical to the success of this approach.
For product development teams already working at maximum capacity, introducing new responsibilities can be challenging.
This shift might not resonate as much with employees and customers, and it is easier to backslide into a model where the security team is solely responsible for analyzing, implementing, and guiding.

The Final Word

This approach works well for companies that have a smaller number of teams to begin with, especially if those teams (or members of them) have a pre-existing interest in security. Enterprises that have taken this approach include Sportradar.

Evolve Teams to Suit Changing Security Needs

Remember that team design shouldn’t be static. The best fit for you today might get in the way of better, faster developments tomorrow, which is why you need to be prepared to adapt as your organization grows.

About iTMethods

iTMethods helps companies accelerate software delivery capabilities through their Cloud-native DevOps SaaS Platform. The Enterprise SaaS offering features a toolchain catalog comprised of best-of-breed DevOps tools including CloudBees Jenkins, Github, Atlassian, Sonatype, and many more. These tools are deployed to each customer’s specific requirements, including security, scalability, and 24/7 customer support.

Learn more at itmethods.com

Read more from iTMethods:

View full post