Frankly Speaking 10/5/22 - The rise of security engineering
Bringing engineering to operational security
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.
We have a lot of open engineering roles at dbt Labs, including on my team in security! If you or someone you know is interested, feel free to ask them to apply via the website or ping me, and I’m happy to talk to them about why dbt is an awesome place to work.
LET’S BE FRANK
This week’s newsletter will be based on a podcast that I did with the CEO of a former portfolio company, Appdome. If you’re interested in learning more about security engineering and DevSecOps, I encourage you to listen to the whole podcast. Otherwise, I’ll talk about it here and provide some additional commentary.
In the podcast, we discuss DevSecOps, but I prefer the term security engineering. For context, I’ve talked about this before in the previous blogs where I define what a security engineer is.
In the past, I have also described that the creation and rise of security engineering have resulted from the increased functional presence of security in engineering, which is the logical progression as IT has shifted into DevOps as a result of the migration to the cloud. However, I mostly talk about security engineering becoming a more critical function, but I haven’t provided much insight into why and how this might happen.
Components of a security organization
In my opinion, there are two major components of any security organization in the cloud world: security engineering and operational security.
Operational security includes teams that allow security to “operate” and function. This includes what people perceive as traditional security teams like incident response, vulnerability management, red teams, etc.
Security engineering includes product and platform security as well as teams that enable the operational security teams to be more efficient.
Another way to think about these components is that one group (security engineering) writes the code and the other group (operational security) audits the code. It is important to have this separation. Of course, there might be many subgroups.
It is important to have this distinction and not broadly group them together into just security for two reasons. First, these two components require different skill sets. Security engineering requires a software engineer interested in security whereas the operational security group requires traditional security personnel, e.g. analysts and operations engineers.
Second, it allows for more flexible security organization construction. Some organizations want to have everything under a singular security leader, but understanding these components can give the option of having a security leader for operational security and having an engineering leader manage the security engineering team. This allows for better allocation of resources and possibly a more efficient organization if done correctly.
How to use security engineering
Now that we see the purpose of these two components, how should an organization use this information?
To start, how much security engineering a company needs depends heavily on its product and consequently its industry. The security engineering team is primarily focused on building software to better secure the product and platform. Companies in the financial, data, healthcare, etc. spaces tend to need more security engineering as there are more security and regulatory concerns. Similarly, these companies might need more security engineering to support the larger operational security team.
Another key use for security engineering is to help run an efficient operational security team. That side of the organization tends not to have software engineers, so the security engineering team can help them build tools, automation, and processes to ensure the team can scale efficiently without substantially increasing headcount. Similarly, they have the context to ensure to make sure the correct tools are being used in the correct ways.
Finally, depending on the product, the security engineering team can provide substantial value by executing security product features on the roadmap for customers. Since the security engineering team has more context, these software engineers can execute these features faster because they likely have consumed similar products/features in the past, making them more product-minded engineers by default. This is many times more efficient than creating a non-security team and having the security engineers consult or embed on the team temporarily.
Conclusion
Building a security engineering team might seem like a hard task, but it has many benefits that generate substantial value for the company. They can help build product features and also can make operational security tasks more efficient.
For organizations that require large amounts of security to handle, building a security engineering organization can not only increase operational efficiency in security but also deliver substantial product value to the company. As executive teams start to emphasize security, they should seriously consider investing in a security engineering organization earlier rather than later.