The Idea Of The Security Team Is Dead

If you've ever wondered by most security teams are viewed as the team that "says no" and considered to be a roadblock, look no further than the simple org chart.

A separate security is the preferred setup for most enterprises but it's rarely done with a full understand of the end results. It's a great example of the unintended consequences of form following function.

This is the reason why security is bolted on to a solution just before it hits production. This organizational structure is designed from the ground up to prevent security-by-design.

Security needs to be built into the very fabric of every IT solution. The DevOps movement has done wonders to start to breakdown the barriers between development and operations. This shift in IT delivery is leading to faster innovation and a better focus on business value.

The good news is that by changing the way security expertise is developed and deployed within the enterprise, you can see similar improvements to the security posture of the organizations.

The bad news is that this isn't a technology problem but a cultural one and it's extremely difficult to quickly implement cultural shifts within any organization.

Teams That Says "No"

No matter how good a security team is, when they are separated from the rest of the organization, there is a tendency for the team to be excluded for them to exclude themselves.

This situations gets even worse when security is mandated as part of a project management gating system. To double down on the problem, security teams--like most IT teams--are chronically understaffed, underfunded, and overworked.

This is a not a recipe for success.

There Is No Such Thing As Security Ops

A key role played by the security team is that of security operations. Another symptom of traditional thinking, security operations tends to be a duplication of a lot of efforts with little pay off day-to-day.

When a bug occurs in production, the response is very straight forward;

  1. Bug is reported
  2. Analyze the impact and prioritize the issue
  3. Apply any needed mitigation (note to users, disable feature, etc.)
  4. Resolve the issue with a new deployment

If you step back and map out the process for rolling out a new patch or system to the infrastructure, you'll get the exact same process.

Applying a security lens to the same question and you'll get;

  1. Bug is reported
  2. Analyze the impact and prioritize the issue
  3. Contain the issue
  4. Apply any needed mitigation (new IPS policy, updated A/V profiles, etc.)
  5. Resolve the issue with a new deployment

If only one step is different across three processes, why are there 3 separate processes run by 3 separate teams? It doesn't make sense.

DevOps proponents have realized part of this and push for the reunification of the two identical processes. If security wasn't an isolated team, the logical step would be to unify all three processes under the simple umbrella of Ops.

Form Follows Function

We've established that there is no need of a separate process for security within standard responses to issues. If form follows function, that means that there is also no need for a dedicated security ops team.

Modern security practices are starting to integrate security practitioners within the development squads and teams.

Security needs to follow Peter Merholz's example--he is concerned with integrating user experience talent into the development flow--security practitioners should be working direct with development squads.

Each practitioners should work with one or two squads. Helping the squads understand the security requirements of the solution, the challenges facing the codebase & solution, and helping the developers truly understand the risk facing the solution.

In turn the security practitioner gains valuable insight in the business requirements, business processes, and ahas a more complete understanding of how the business drives value.

Distributed & Centralized

This doesn't mean that the dedicated security practitioners work alone and in isolation from their peers.

Despite their day-to-day responsibilities with the development squads, practitioners should meet regularly and collaborate with their peers. This ensures the consistent application of ideas and policy along with ensuring that understanding of security and risk is well distributed throughout the enterprise.

Remember we're talking about security operations, there is still a very real need for a centralized trust & assurance team. This is the team that would audit development squads and various solutions against the corporate standard and any regulations or compliance requirements.

No Silver Bullet

The idea of unified operations is compelling but it's certainly not a cure-all. The key takeaway is that security can no longer work in isolation, dictating policy and requirements from up on high.

To get solutions that are secure-by-design takes a distribution of security expertise throughout the organization.

Developers cannot build good solutions in a vacuum. Security expertise needs to be distributed throughout the organization and also nurtured throughout the organization.

The idea of a centralized security operations team is dead. Distributed operations provide more flexibility, help amplify security knowledge, and result in a clearer understanding of the risk facing the business.

Distributing your security team is a win-win.