Application Security

Get Cross-Functional: Learn to Let Go and Embrace DevSecOps

In many organizations, building and securing apps has typically been a siloed affair. The product owner, the network engineer, the developer and the security engineer all come from different teams. And all too often, these teams become fiefdoms that believe their focus is the company’s primary objective. 

<p><span><span style="font-family: &quot;trebuchet ms&quot;, geneva;"><strong><span>In many organizations, building and securing apps has typically been a siloed affair. The product owner, the network engineer, the developer and the security engineer all come from different teams. And all too often, these teams become fiefdoms that believe their focus is the company’s primary objective. </span></strong></span></span></p>

In many organizations, building and securing apps has typically been a siloed affair. The product owner, the network engineer, the developer and the security engineer all come from different teams. And all too often, these teams become fiefdoms that believe their focus is the company’s primary objective. 

Today with Agile and DevOps moving faster and faster, this methodology has become a risk in itself. Since the security team often lacks up-front knowledge of the project, the threat model assessment is done after the fact. Controls amount to a wrapper around any new application or service because the security team steps in late as the security czar without really understanding why the business is developing the app in the first place. Then the business can’t release the new application on time because the threat model assessment can take weeks or months to accomplish. 

If this is happening in your organization today, we would say that you, as a security person, have become a form of friction. Your approach to security amounts to swooping in and potentially delaying a project by months. As a result, other teams may delay or even avoid reaching out. And that means risk. 

As development orgs have transformed with DevOps, security orgs may think they can keep up simply by pulling policies in. But as the business begins to move this fast, they realize quickly that in order to really get to that ideal, frictionless state, the entire process of security has to be incorporated intrinsically into every step of development. Sure, the app still needs a threat model assessment, but it must be done in a way that meets all the goals and objectives of the business. 

This is the cultural and organizational transformation that must happen as part of moving to DevSecOps. It isn’t just about creating policy in a frictionless way. It’s the whole security construct—plan, do, check, act—fully incorporated into a collaborative way of working. It’s about bringing the entire security mindset into that larger, cross-functional pod. 

In this model, those siloes dissolve. There’s a core business outcome, and that’s the primary objective. Everybody is aligned to it, and your role is part of achieving it.

As this model gains traction across industries, we’re seeing teams evolve too, in a way that makes much more sense for the agile world of frequent builds and releases. New roles are emerging as companies explore and optimize team structures and develop best practices. A typical team might have a product owner, team lead, cloud architect, site reliability engineer (SRE), DevOps system administrator, DevOps evangelist, automation specialist, experience assurance professional, a release manager—and in the mix of all this is, of course, your humble security engineer. 

Before, most of these roles were part of different teams with different interests. Now they’re one team with one objective, and they work to facilitate that. 

Advertisement. Scroll to continue reading.

Importantly, it’s not just about security causing friction, but also the product owner and the rest of the team understanding the security requirements. It’s about going as fast as possible, but doing so with the understanding that there are security bars that have to be met. 

Building that understanding on the business side means you won’t find out about a project at the last minute, and be forced to put on your security cop badge. If done right and integrated throughout the process, security ends up being not a source of friction, but a function that protects the business, at the speed of business. 

So what about all of those fiefdoms and their leaders? In the world of cross-functional teams, security leaders will provide oversight and direction. They’ll set policy and represent that to the broader organization. They’ll plan and deliver resources against that plan. Same for all of the other departments. 

But at the same time, they’re also going to have to let go just a little too, because their direct reports will be working in cross-functional teams. Leaders have to compromise to the extent that they may not be running their team members’ day-to-day, but they are still running the discipline at a high level. 

In the same way, the product owner is getting the best of all of these talented people without having to understand every discipline, allowing her to focus on being a product owner and building the best possible product. 

Ultimately, as security pros, we need to see that security isn’t the outcome—business is the outcome. So let’s figure out how to infuse security within that outcome. There’s a lot of fear and resistance to change, but getting cross-functional is actually an opportunity to be seen as a contributing part of the business and its success, rather than as a security cop. 

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version