Having only security operations is ok
You just have to understand the limitations, and security problems won't be fixed as quickly.
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
Traditionally, cybersecurity has been an operations-focused discipline because it was part of IT. However, with the rise of the cloud, much of the infrastructure responsibilities have shifted from IT to engineering, but in many companies, including many tech ones, security is still focused on operations rather than engineering. In fact, even companies with dedicated DevOps teams don’t even have a dedicated engineering team for security. Although I believe that every tech company should have an engineering team focused on security, it’s not necessary or even possible — hiring engineers, especially ones that specialize in security, is difficult and tricky.
What’s an operations-focused security team?
Most “traditional” security teams are operations-focused, and that’s how the industry started. What does that mean? These teams are focused on auditing systems and uncovering risks. Although there are tools that help with this, scaling an organization like this requires adding more employees. This is in contrast to most engineering-focused organizations where you can scale engineering processes through building platforms.
It’s no surprise that security organizations started this way because most of the compliance work is a form of auditing. For example, SOC2 is a type of security audit that started as a form of financial control that morphed into a security requirement. As a result, many companies have molded their security responsibilities around key compliance requirements.
In an operations-focused security team, much of the focus is on monitoring and creating processes to uncover and resolve risks. As a leader of these types of teams, the goal is to regularly make these processes efficient. Moreover, another goal is to create more teams, and the justification for new team creation is that the team will lead to more risk reduction. However, this usually works well in strong macroeconomic conditions. The budgets of operationally focused teams generally are constrained during downturns because they don’t contribute to the top or bottom lines of the company — it’s hard to do more with less with these types of teams.
Why is it not necessary to have an engineering-focused security team?
You must be thinking “Ok, Frank’s whole blog is talking about how security engineering teams help organizations. Why is he suddenly saying it’s ok not to have one?” That’s a good question. The goal of this newsletter is to discuss practicality rather than ideal end states. As I alluded to above, it’s hard to build a security engineering team and staff it. The question for the executive team is whether it’s worth the cost and resource investment to build something like this. Of course, it’s better to have one, but it’s not necessary. For instance, it’s nice to have a high-quality engineering team like Google or Meta, but many companies build good products without it. The same logic applies here.
The operations-focused security team can take an organization pretty far. They can deal with compliance and uncover security issues. However, in this setup, there needs to be a tight feedback loop between the engineering leaders and security because security will be incapable of rectifying the issues they uncover. Security and engineering need to share context to understand the priority of fixing an issue among other product/platform priorities they have. (Note: This is the main case for having security engineering. The context is notoriously hard to share.) In other words, security has to rely on engineering to solve the security issue, and engineering needs to balance this risk with other business risks it’s currently holding. That’s ok, but it just increases the responsibility of your core engineering teams.
What are some benefits?
To be clear, despite my advocacy for security engineering, I do believe at a steady/end state, there should be a security operations team. The question is the size and whether a security organization is primarily engineering-focused or operations-focused. This is common for engineering organizations too. At scale, many engineering teams have an operations counterpart.
Back to the benefits of having a security team that doesn’t have an engineering counterpart, i.e. security engineering. There’s already a talent shortage in cybersecurity, and if you combine that with the software engineering talent shortage, you’re going to end up investing significant time and effort for unclear results. Honestly, most companies probably don’t need security engineering if they have a cooperative engineering team with people that care about security.
Overall, operations teams are relatively easier to hire, build, and manage. There are clearer career paths and more opportunities for your employees. Most security products are built for this type of team, so the programs to build around those tools and teams are much more straightforward.
Building a security engineering team to complement a security operations team is a risk, and it could be a costly one. A security operations team covers most of your goals, has clearer responsibilities, and reduces organizational complexity.
What are some limitations?
With a security operations team, an organization needs to rely on the engineering team to rectify most security issues. As described above, this requires a tight feedback loop between security and engineering and places the responsibility of remediation priority on engineering leadership. This is a risk because it requires engineering leadership to understand and manage product and security priorities from an engineering perspective. That might contribute to a substantial increase in cognitive load for the engineering organization, which comes with its own risks.
This will impact the company in a few ways (compared to companies that have dedicated security engineering teams):
Teams might need to context switch more often as they will be required to deal with security-related issues that they might have little knowledge of. This reduces the productivity of an engineer, who is forced to context-switch into security.
Increased demand for engineering resources. Although security doesn’t have to worry about hiring engineers, this increases the burden of hiring in engineering.
Potential increased friction between security and engineering. Security wants to make progress, but engineering is slow to understand the context. The organizations regularly speak past each other.
If there isn’t an increased capacity to handle security issues, product and/or security improvements will be delayed.
Takeaway
None of these issues are deal breakers, of course. However, it’s important to understand the limitations of having an operations-focused security organization because it affects overall organizational strategy. For example, having only a security operations team might work if the company is not in a highly regulated space and can easily hire engineers, and it has had trouble attracting engineering leaders with security knowledge. Whatever it may be, not understanding the limitations creates gaps and friction that not only could lead to worse security posture but can also negatively affect business/product outcomes.