Frankly Speaking - The rise of the technical security leader
Why tech companies should hire one
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.
As part of starting my new role at Headway, I’m offering 50% off a yearly subscription until 3/31!
In my last newsletter, I discussed why security is broken, and I attributed it to an outdated security organizational structure and CISO persona. I’ve been seeing more tech companies hire a security engineer as the first security hire (as evidenced by my current role). I’m likely biased, but this feels like the right move. We need to establish a foundational security strategy where security is integrated into the engineering process rather than an afterthought. I was particularly inspired by this LinkedIn post by Deepak Jeevankumar.
I’ve known Deepak for close to a decade at this point and worked with him at Dell Tech Capital investing in the next-gen of cybersecurity companies. He has a good intuition for finding the next major cybersecurity trend as evidenced by his early investments in cloud security. The reasons described in his post for and against a technical security leader, i.e. security engineering executive position, are interesting. Specifically, he associates security engineering with business enablement and traditional CISO roles with risk management. This further convinces me that the risk-focused, operational CISO role will fundamentally change and potentially diminish.
Many companies will be forced to innovate to maintain or increase market share. It’s clear that even large tech companies, such as Meta, Google, Amazon, etc., believe they need to be aggressive with growth or risk losing market share. However, in order to maintain a reasonable pace of tech innovation, the traditional CISO will become a blocker rather than an enabler whereas the security engineering leader can solve problems and develop solutions while being comfortable balancing business and security risks. This is why the rise of security engineering will become an inevitability for growth companies regardless of stage and size.
To make this concrete, let’s take a few examples of issues that an innovative organization will face.
API security and the ownership problem
One that has been on the top of my mind has been API security. It’s been a hot topic because more companies are moving toward Kubernetes and microservices, which has led to a rise in APIs and endpoints.
In a traditional organization, there is a dispute on ownership. Is this an infrastructure security problem because attackers might attack the API from the outside, or is this an application security problem because the API represents an entry point into the application? The reason for this dispute lies around the solution. If it’s an infrastructure security problem, we need to address it using a WAF to filter traffic, but if it’s an application security problem, then we need to address it from the inside out by scanning the APIs with a tool to detect any issues.
Unfortunately, the issue is a mixture of both. As a traditional security organization, do you need to form an API security program? Having two teams own an issue seems problematic. However, the security engineering team will believe this is a monitoring issue. Specifically, we need to have observability for application security, which becomes a mixture of DevOps and application security. A cool startup in the space is called Metlo, which is trying to be a developer-focused API security platform similar to what Datadog did for observability. We are also seeing more rule-driven approaches, such as Semgrep by r2c, that allow security engineers who have the technical context to write more targeted rules that reduce false positives and hone in on the real issues. As organizations adopt security engineering at a rapid pace, these types of tools will be more prevalent.
API security is a prime example of a change in infrastructure and application development where traditional risk-focused security organizations will struggle, i.e. they will recognize the risk but don’t have the context or problem-solving abilities to mitigate it. As they struggle, they will have trouble measuring and understanding the risk, so their default response is to slow down development.
The difficulty of understanding cloud security
I’m sure many people resonate with the tweet. My answer to Anton’s question is that there’s been a lack of technical security leadership at companies. In particular, the goal of CSPM tools is to find problems, but in most situations, the security team doesn’t implement the solutions — it’s the infrastructure/DevOps team fixing these problems. As a result, it’s difficult to prevent misconfigurations in the future because the implementing team doesn’t have the intuition or context. This is a similar problem to having separate infrastructure and DevOps teams early on at a company. The infrastructure team implements something, but the DevOps team is tasked with maintaining it. However, the infrastructure team is not incentivized to make decisions that make it easier to maintain because they never have to experience the maintenance step. DevOps will constantly be playing catchup, and the issues will continue to spiral out of control.
Similarly with security, without a security engineering team building and implementing but instead just detecting and instructing, it’s difficult to create a strong security design because security never fully understands or controls the initial design to ensure the appropriate steps are followed. I can bet that the companies that have strong cloud security postures have strong security engineering teams.
Takeaway
The above two examples are a few of the many reasons why having a risk-focused traditional security organization with a CISO is not enough. As companies are forced to innovate and take more risks, having this type of security organization will slow down engineering teams. This relates to the types of leaders companies should hire. Mature companies hire experienced leaders that take a few calculated risks whereas startups hire decisive leaders that are able to make decisions quickly and iterate. For security, as companies (even mature ones) need to innovate, there is a need for a security engineering team that can help enable businesses through fast iteration processes and make quick business-security risk tradeoff decisions.
I find myself very interested in this discussion, I lean towards security not needing a CXO position at all, and instead companies should probably be creating a risk CXO position and the seniormost security person is an engineer, but reporting to them. Anyone who spends the time communicating to, and building relationships with the MBAs in the C-Suite, is going to have to spend a lot of time massaging risk into numbers, and is essentially more of an actuarial professional and community builder. Doing that and understanding the technical solutions to problems as things change is a high bar. A CISO is a role of communication, while a VP of security engineering (even an EVP, but not CSuite) can spend his time leading down, and learning new technologies. Anytime you put someone into a physical c-suite, they are going to have a lot less integration with the team they are leading. I think we as a community have gotten very wrapped around titles but here I think the CXO is hurting us more than helping.