FireStarter: Centralize or Decentralize the Security Organization?

By Mike Rothman

The pendulum swings back and forth. And back and forth. And back and forth again. In the early days of security, there was a network security team and they dealt with authentication tokens and the firewall. Then there was an endpoint security team, who dealt with AV. Then the messaging security team, who dealt with spam. The database security team, the application security team, and so on and so forth.

At some point in the evolution of these disparate teams, someone internally made a power play to consolidate all the security functions into one group with a senior security person driving things. Maybe that person was the “security manager,” or perhaps the CISO. And maybe it wasn’t even a power play, but simply an acknowledgement that having security dispersed throughout the organization wasn’t efficient and was creating unnecessary exposures.

But the pendulum inevitably swings back (regardless of where you are) and the central team was dispersed into operations teams. Or the security specialists were pulled back into a security group. Regardless, it seems that the org chart is always changing, regardless of the sense of doing such.

Let’s take a step back and figure out whether it makes sense to have a central security team with operational resources or not. Philosophically, I believe there does need to be a central security function, but not necessarily a big team. This group needs to:

  • Manage the program: Someone has to be responsible and accountable for the security program. So this is really about setting strategy and getting the wheels in motion to execute on the strategy.
  • Persuade the troops: Security is not something folks do without a little push (or a big one). So the central function needs to persuade the other operating IT units and line of business groups that following security policies is a good thing.
  • Report on progress: Ultimately someone has to generate reports for the auditors, and this group is usually it. They also tend to present to the board and other senior execs about the effectiveness and efficiency of the security program.

So the real question is how many resources does this central security function need? Do they need to have firewall jockeys, IDS tuners, SOC console watchers, and database security folks? I can see both sides of the argument.

The ops teams don’t care about security (for the most part), so if you put the security folks in the operational groups, ultimately they’ll be marginalized. Or so the argument goes for those favoring the central security function. You also lose a lot of integration and defense-in-depth coordination when you have ops folks scattered throughout the organization. In this model the central security function needs to coordinate all the activities in the ops groups to ensure (and enforce) policy compliance.

On the other hand, we all want security just baked in, meaning security is just there – like a utility. Of course, we’re nowhere close to that, but how can we ever get there unless we have security folks living right next to their operational cohorts … and eventually the separate security folks just go away, as our core infrastructure takes on security characteristics, as opposed to having to bolt security on.

So what are you folks seeing out there? I know there are folks strongly on both sides of the discussion, so let’s hash it out and figure out what is the latest, greatest, and best model for security organizations nowadays.

No Related Posts

Here’s how I see it.  If you have a large and monolithic security function, the rest of IT tends to think that security is someone elses’s job, and then they begin to act that way.  This results in a need for a lot of oversight.  Large companies can sustain this, but the vast majority of companies cannot.  So, you need to craft a structure that makes everyone feel that security is part of their job and, IMO, the best way to do that is to make it part of their job by decentralization.

By ds

I think this is a great LHF topic too. In my experience org hem lines tend to map to maturity of the program. When a business disruption e.g. incident or compliance issue, hits a decentralized org Manage/Persuade/Report requires central leadership to provide one voice (and one throat). As operational processes mature they can be embedded into IT proper for integration and cost savings. I think it’s fair to separate security processes into “service” and “operations” buckets.
At the risk of over simplifying with yet another 2x2 chart:
y- maturity H,L
x- ops, svc
Where high maturity ops can be decentralized.
I think the key is strong leadership in security services MPR to keep close to the evidence and not be marginalized on policy island.

By Jared Pfost

You need a central function, which is strong enough to keep a common approach and framework in place, and also drive general security projects with limited business cases.
Nonetheless you need also strong local functionality to get the frameworks implemented. But without good support from the central function, local functions will go their own ways and the message will different depending on the departments.

By Oliver

I think centralized model will work best for all, specifically for bigger co’s…

By Ramki B Ramakrishnan

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.