Frankly Speaking - The end of the security specialist
The rise of the generalist security engineer
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.
Happy Chinese New Year (for those who celebrate)! I was recently on the Absolute AppSec podcast where I talked about organizational security and discussed the potential security implications of AI/ML. If you get a chance, check it out!
LET’S BE FRANK
I’ve been writing a lot about the rise of security engineering and the need for more software engineers in security. The reason for this is that there’s a lot to unpack. A recent topic that has come up is the idea of specialists. Traditionally, security has hired specialized analysts, sometimes to an extreme. For example, there are analysts that specialize in specific tools, like Splunk and Zscaler. There are other analysts that specialize in specific functions, like SOC, pentests, bug bounty, etc. It’s pretty obvious that this is extremely restricting and inefficient. It is also bad for the security industry as it discourages innovation. Specifically, bad legacy products are kept afloat because it’s easier to find analysts for them given how long they have been around. Also, a security leader isn’t incentivized to try new tools because it’s hard to find the right people to configure and maintain those tools. However, this way of operating has to change and is changing. It’s becoming too inefficient and more importantly, makes it more difficult to stay ahead of attackers.
Organizational change in security
To start, with the trend of more security engineers, organizational change is almost certain and a necessity. The reason for this is that security engineering should be viewed a profit and business center rather than a cost center.
In my organizations, security is in its own organization. It might sometimes sit under the COO, CIO, CFO, or even legal. This doesn’t make sense if the security organization also includes security engineering. Many organizations are strangely stuck on having security as one unit. However, there’s no real reason for this. If anything, it’s ok to move the security engineering function out of broader security. However, regardless of how other parts of security are organization, it’s important for security engineering to sit under engineering. The reason is obvious: engineering functions should follow similar OKRs and business objectives. It makes organizational management around benefits, compensation, people management, etc. much easier.
More importantly, this makes organizational design easier. This type of organizational shift happened when DevOps moved from IT into engineering and created the infrastructure/production engineering groups in most companies. I’m seeing this trend happen more often with security, and I believe it will work out well for many companies. However, much of it depends on what type of security person/team is hired first. If security compliance and operations is hired first, then security starts as a separate organzation or sometimes is in IT. However, if a security engineer is the first hire, then security starts under engineering, many times under infrastructure or production engineering. In the end, having security engineering under the engineering organization is the right move. Honestly, where the other parts of security sit is less important.
The generalist security engineer
Like I said earlier, traditional organizations have hired specialist security analysts in the past. However, the hiring strategy for security engineering is different, especially with security engineering as an engineering function. There will be a tendency for traditional security leaders to hire specialists. Although it’s fine to advertise or hire for a specific function, such as product security or application security, it’s important to hire strong security generalists. The reason for this is that the priorities will shift and unlike traditional security functions, there isn’t always a tool to maintain, such as Splunk or Zscaler or Proofpoint. In general, this security engineer will spend time on projects and shift around to provide resources to high priority items, just like a normal software engineer.
To be clear, what I mean by security engineer here is a software engineer that does security. By hiring a software engineer that does “general” security, it is much easier to hire and use this engineer. A hiring manager doesn’t have to create different interview loops and train different members of the team for these loops. Similarly, it standardizes how recruiters find these engineers, and it is much easier to hire a talented generalist than a specialist especially in a market where security engineers are extraordinarily difficult to hire. Moreover, it’ll be easier to hire an engineer who has a broad knowledge set and can learn to solve different problems. By moving away from security analysts, an organization is cultivating a problem solver rather than a specific type of operator or analyst. This is more aligned toward an engineering mentality — a builder that solves problems.
From my experience, like most engineering functions, security engineering generally has more problems than resources unless it’s one of the larger tech companies. This also means priorities do shift, and an organization needs to be dynamic in moving around resources. However, the problem with specialists is that it’s hard to reallocate them. Unless a company knows that they have a persistent, highly strategic security problem that requires a specialist, they shouldn’t hire one. This is similar to other engineering functions.
Another strategy is to have a strong software engineer work closely with an experienced security engineer to learn security. Security skills can easily be acquired with some experience and practice. However, it is important to have experienced security engineers on the team with depth of knowledge to help provide guidance, especially with complicated security scenarios.
There are numerous ways to design an efficient security engineering organization. However, they should start with focusing on hiring strong security engineer generalists to help build and solve problems.
Conclusion
Having a security engineering organization, especially in a tech company, is extremely important. Staffing this organization is an ongoing challenge. However, although it’s vital to recognize function gaps, hiring a specialist isn’t the right way to go. An organization should hire generalist security engineers like they hire generalist software engineers that can solve various problems. It might help to hire specialists for long-term highly strategic projects, but that person is usually needed only in well-resourced and mature security engineering organziations.
Security organizations are going to experience shifts in the next few years. We will see many engineering organizations develop dedicated security functions, and they will have to figure out the appropriate leaders and engineers to staff that function.