Do we still need dedicated security teams?
Dating back for decades now, most major companies and enterprises have had “security” teams. Sometimes called “IT Security” or “infrastructure security” or something along those lines. This group was responsible for everything from security policies to risk reviews to approving firewall changes. Sometimes they’d own things like IDS/IPS, anti-virus, and often strictly security tools like a SIEM, a WAF, or a database activity monitor.
But this was really only true in enterprise organizations. Startups often don’t have “security” teams. SMBs often don’t have “security” teams. And with the rise of DevOps and DevSecOps, the team responsible for security is often broken into completely separate organizations reporting to completely different managers. And yet many times there is still a “security team” existing alongside DevSec and OpSec teams. The lines get very blurry.
The different types of security teams
Along with having a dedicated “security team”, many enterprises have multiple teams, or multiple groups within one team performing specialized functions. Increasingly, they all have one role: review-and-advise.
Application Security is usually handled by an independent team, but does it need to be? Building static code reviews into the build or QA process is increasingly common. And especially at enterprises, pen-testing is done by external consultants. In these organizations, AppSec becomes a review-and-advise team.
Infrastructure Security is being chipped away by cloud vendors who increasingly manage the infrastructure for you, leaving the InfraSec team to review firewall policies and maybe administer a Palo Alto in AWS. But does this team actually manage the infrastructure? Does this team actually perform the patching? Of course not. All they do is review and advise. Do you have a “vulnerability management” person? Why? Why is that a role instead of a responsibility? As companies outsource more of the infrastructure, InfraSec teams become more of a review-and-advise team.
GRC (governance, risk, and compliance) seem to be the one old-school security team that is increasing in relevance. Built as a review-and-advise team from the very early days, this team is mostly responsible for calculating risk and collecting sign-offs, working as a go-between for auditors and technical teams, and handling asset management. This is a good team, much like Internal Audit and Human Resources.
But what about my particular specialty, SIEM administration and engineering? Plenty of companies still run their own SIEMs… but for how long? MDR (Managed Detection and Response) platforms are becoming increasingly popular. Enterprises have found it to be almost impossible to hire, train, and retain highly skilled SOC analysts and SIEM engineers, and vendors have a solution: outsource it. If you have a SOC, great! Keep it! If you don’t or you’re looking to build one… read on.
The part where Mark knocks down a straw man for the CISO
But, you might say, I’m the exception to the rule! And you might be right. I’ve worked with a number of organizations where the security team(s) do great work and are well-respected. That’s not the norm. If this describes you (and really think, what do your security engineers actually complain about… if it’s constant complaining that other teams aren’t following security’s advice, your security team is likely useless) then you’re doing a great job and should continue. Congratulations, you have a great security team!
But if you’re like most enterprises I’ve worked with who keep throwing money and headcount at a security organization that accomplishes nothing more than checking boxes for compliance, you need to rethink your strategy. Either give the security team actual teeth (see my 2017 idea that Security Should Break Your Company aka Zero Trust Networking) or put the employees on teams that do have teeth. Basically, if you sign off on more risks than you actually mitigate, you should rethink how your security organization is structured.
So do we still need dedicated security teams? Yes… but…
Yes, you still need someone at your org who understands the security landscape particular to your environment, and who knows the people/teams/politics. You need someone who is ultimately responsible for the security of the company.
But does that have to be a dedicated team? Increasingly, no. More and more I’m seeing enterprises with a security presence distributed across multiple teams, with a small GRC team performing the review-and-advise functions that are still required. It’s just not making financial sense to keep a fully-staffed security engineering team around. This is especially the case in companies that have strong cloud adoption.
(As an aside: another good point in favor of moving to the cloud: the cost of your security engineering goes DRAMATICALLY down. And the more cloud adoption you have, the more your vendor handles the infrastructure and in turn, the infrastructure security.)
The bottom line is
Don’t fire your security team, they’re valuable assets! But put them where they can make the most impact. And I guarantee that’s not sitting in a corner writing strongly worded yet toothless emails about policy violations and patching schedules. If you have a security engineer who has an interest in application security, put them in a development team. If you have security engineers who are good at infrastructure security, put them in your operations or cloud teams. If you have security engineers who are especially talented at describing and quantifying risk, put them in your GRC team.
Dedicated security teams are a relic of the past, and no one listens to them anyway because the business will always be more important than security, no matter what anyone says. If the business isn’t more important than security for you, it will be for your competitors. My advice? Dissolve your security team and distribute the staff to teams where they can actually make a difference to your organization rather than just slowing the velocity of your profit centers. Use this opportunity to expand the definition of “security”.
(For the bonus round, set up a cross-functional weekly or monthly stand-up where all the members of your now-defunct security team meet to discuss business-wide security issues. This keeps them as a “dotted-line” team and allows them to be on a more effective team while still maintaining the “dedicated security team” communication pathways.)
If you can’t let security break your company, break your security team.
