Frankly Speaking 6/28/22 - Don't confuse compliance with 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.
I know it’s been a rough week for many people, including myself, so I want to thank everyone for taking the time to read and subscribe. As always, I welcome feedback and suggestions on content.
LET’S BE FRANK
I’ve written that compliance drives security value in the past, but I realize I didn’t capture many of the nuances in that post. I’m revisiting this and possibly revising some of my previous statements because I believe that security has been slow to keep up with recent tech trends. In fact, by talking with security leaders and observing security strategies, I am certain that this area will remain confusing for a while.
To be clear, compliance and security should be treated as two separate goals. However, of course, if compliance and security can be achieved in the same initiative, that’s an ideal situation. I will talk about a few cases where that’s happened, and it’s no surprise those tools have driven immense value.
In this newsletter, I’ll talk about the following:
Why compliance and security should be separate goals, especially with the cloud
Consequently, how we should think about these goals in an organization
How security companies should think about compliance and security as go-to-market strategies
Finally, I’ll talk about some products that achieve both goals
Compliance and Security: A Tale of Two Cities
It is common to conflate compliance and security. Many compliance requirements might seem like they provide security. For example, certain scanning tools might fulfill compliance requirements, but a company probably shouldn’t blindly follow the output of these tools. Is it good to keep your dependencies up to date? Probably. However, companies don’t have unlimited engineering resources. Updating a dependency requires testing the codebase to ensure functionality, which might be complex. Could this limited engineering time be better spent doing something else?
This is the crux of the fallacy — the belief that compliance leads to better security. Compliance is necessary for an organization to demonstrate they have a bare baseline of security, but saying it is necessary for security might actually be dangerous and counterproductive.
To better illustrate this, let’s consider our favorite noisy tools: static app sec testing tools (SAST). Most organizations have this, and the primary driver of having this is compliance. However, these tools tend to be noisy and output a lot of information. The age-long question is whether engineers should spend time rectifying all these problems. My answer is definitely not.
The reason is that most of these findings are not useful. Most don’t have exploits in the wild and are theoretical. Does fixing them help? Sure, if you have unlimited resources, it certainly doesn’t hurt, but if you don’t have unlimited resources, it does hurt. It substantially reduces an organization’s engineering velocity and ability to focus on the product that delivers value.
So, what do we do here? It’s important to decide how to deal with these outputs. Enter vulnerability management. Some people describe this as a program or maybe a policy. Really, it doesn’t matter. What matters is that it needs to be established in conjunction with the procurement of SAST and appsec tools in general. The specifics of each organization’s vulnerability management program/policy depend on their risk tolerance and resources. For example, most startups should probably only fix critical (and maybe high) vulnerabilities that are currently being exploited in the wild or have a mature exploit. Moreover, you might not even need to fix vulnerabilities if they are controls in place for that part of the codebase. Bigger companies with more resources could focus on vulnerabilities that affect larger parts of their codebase or have more complex fixes like using their WAF to block types of traffic that might be trying to exploit this vulnerability. The exact details are company-dependent.
In this example, SAST fulfills compliance, but vulnerability management is the security portion because it takes into account an organization’s specific environment, risks, and potential threats. The follow-up question here is who should own each part.
For those of you who don’t regularly read my posts, I believe that in a cloud-based company, this is a complicated question because most traditional advice says that both should be owned within security. Of course, this made sense when IT and security worked closely together, had similar skill sets and managed the infrastructure. However, now engineers are involved in infrastructure, which changes the game. They are the ones who are most intimately familiar with risks in both the infrastructure and the product. Specifically, for appsec, that’s why we are seeing more appsec teams are made up predominately of software engineers. In fact, in some organizations, application and product security do not report into security but instead platform engineering. There has not been convergence on the best organization construction, and I am, by no means, an expert on this.
This is a good segue into the next section, which talks about how companies should think about these goals.
Compliance and security in an organization: Oil and water, or salt and pepper?
Let’s be honest. Everyone views compliance as a tax. It’s something that every organization has to do because their customers ask and because it’s a good baseline posture. However, it cannot be the end state for security. It’s more of a starting point. Like taxes, the idea is to minimize to make it efficient because it doesn’t drive value. However, smart security leaders are able to use compliance to effectively achieve their security strategy, which is a win-win. It’s important to mention here that this doesn’t mean their security strategy is based on compliance, but rather they can effectively use elements of compliance to achieve their security strategy. This state is very different from what I describe as the worst state — doing a bunch of compliance tasks and calling it a security strategy.
Why is it so hard to combine security and compliance? It’s inherently hard to combine static goals with adaptive ones. Compliance has many requirements, and some of them might not make an organization more secure. However, it’s necessary to achieve certification and pass audits whereas security is more adaptive. It regularly changes in response to organizational changes and broader security risks. It’s easier to keep them separate, i.e. compliance defines baseline requirements for security, and security ensures that they are incorporated as part of a broader security strategy.
Another way to think about this is that compliance shows risks, and security decides how to take action on these risks, which could also include inaction. Effective security leaders and valuable products are able to combine these.
Specifically, startups can use these facts to their advantage. For example, new products can go to market quicker if they use compliance as a driver, especially a new compliance requirement. For example, many companies bought cloud security posture management (CSPM) tools earlier on because they needed to meet compliance requirements around cloud visibility. However, these tools, in my opinion, have failed to deliver value beyond compliance so far. They haven’t found a good way to provide actionable insights that align well with security strategies.
Using compliance is a good initial GTM strategy to generate value for a startup product, but it won’t expand and help it sustain the value. The reason is that there will be other products that come into this market. Since compliance is a tax, it becomes a race to the bottom for price. In order to generate additional security value, the product needs to solve problems related to a company’s security strategy.
The Ultimate Pairing: Compliance and Security
The best examples of combining compliance and security are the endpoint and SSO products. I’m specifically referring to Crowdstrike and Okta.
Crowdstrike went to market by providing a better alternative to anti-virus, which was a compliance requirement. It was obviously a huge market because every endpoint at every company needed it. However, it was always a pain and had a ton of false positives (yes, many people still talk about those dreaded Symantec scans and alerts). They drove additional value by providing a strong response tool, which is an important part of a company’s security strategy. It mitigated threats detected by their detection product and with great effectiveness.
Similarly, Okta solved the simplest compliance need, which was provide an authentication solution for 3rd party SaaS applications through a centralized portal. However, it greatly simplified authentication for an organization. As a result of Okta, IT and security only had to manage one identity for each employee. They also made it easy to connect the various applications with Okta.
In both these cases, some of the value came from combining or consolidating workflows. For Crowdstrike, a company no longer needed to worry about responding after receiving findings. For Okta, companies no longer need to worry about consolidating or managing various identities.
Final Thoughts
To summarize, it’s important to treat compliance and security as separate goals. Compliance tends to create initial value, but in order to continue capturing value, a product needs to solve security problems in an adaptive manner.
Here are some parting questions:
How do you find the value driver in a security product?
As a follow up, are there valuable products that could gain value if they were a strong compliance driver?
Is there a group of projects that have only compliance value but could be more valuable through consolidation? Similarly, are there other basic strategies to gain value?
What are the main drivers of security value capture and separately, value creation?