Efficiency/Effectiveness tradeoffs for a security program
Like everything, you have to pick 2 out of 3 defining features
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.
Headway is growing fast, and I’m looking for a Senior Security Engineer to join our founding security team. We are building a new mental health care system that everyone can access where security is paramount to user trust because our users entrust us with sensitive information. You will work closely with me to help shape both the engineering and security culture at a revolutionary company. Please apply and/or reach out to me if you’re interested.
I’ve been talking a lot about the benefits of security engineering and more recently, about how to make operational security work for your organization if security engineering isn’t viable. What I’ve been missing is something a lot of executives like — a framework to evaluate various options and goals of a security organization. More specifically, they can answer questions like the following:
Should I push harder for a security engineering organization? Is that what I need?
If an engineering-focused security team isn’t viable, how should I communicate the tradeoffs to other executives and the board?
If I want both operational and engineering-based security, how should I properly resource between the two, and what should be the expected outcome?
Although sometimes these seem like basic and somewhat vague/vacuous questions, they are important as ways to discuss security in terms understandable to the board and other executives. Historically, failure to communicate this properly has caused changes in security leadership or even resets of security programs.
As many of you know, I have strong beliefs about how security programs should be built in order to address a rapidly changing and complex threat landscape. However, I’m a pragmatist, and sometimes, you have to work with what you have, and the solution is contextual. Also, many times, your organization can’t wait around to solve a problem perfectly because as every day passes, the amount of debt compounds.
Three features of a security program (pick 2)
I’ve stated before that I perceive security programs to be platforms at companies, meaning they provide a service and/or product for the rest of the organization. Like most platforms and systems, there will be tradeoffs, so security “platforms” can typically have 2 out of these 3 features:
Low cost: This is obvious. Ideally, we want to minimize the amount of money we spend to achieve the most results on any platform. These costs include all types of resources, e.g. tools, headcount, operational costs, etc.
High quality: The security program provides high-quality services or tools that effectively reduce risk and provide value to the organization.
Low friction (high velocity): The security program creates minimum friction in an organization and allows them to operate at high velocity.
A good security program achieves two of these goals/features and tries to achieve as much of the third as possible. For example, many regulated companies want high-quality security programs that minimize friction to encourage innovation. However, the costs are high as they need to invest heavily in tools, operations, and headcount. The idea is that they want to try to minimize cost because one can imagine a way to have a high-quality, low-friction security program is to buy every conceivable tool, staff them with a team, and then have a team of security engineers triage. Unfortunately, this isn’t realistic because resources aren’t infinite, and the goal of most organizations is to grow efficiently.
I believe it’s impossible for a security organization to have all three, so an efficient and effective security organization tends to have two and tries its best to achieve as much of a third one as possible. Not surprisingly, most security organizations struggle to even have one of these features. Specifically, operational security programs struggle to be low cost, tend to be high friction, and lack the context to be high quality.
What two features should your organization pick?
Of course, the answer is that it depends. Let’s look at the 3 combinations and see what organizations might fit this.
Low cost and high quality
This is a hard combination to achieve because it involves finding cost-effective talent and tools. Some companies have tried to do this for traditional services, such as pentesting by using offshore resources. Although this strategy will lower the cost for the security organization, it will create more cost for the organization as a whole (and possibly increase cost) because the security team will not have the resources to fix the issues. As a result, they will either need to create strict guidelines to prevent issues and/or ask others to fix issues, both leading to increased friction.
This strategy is commonly seen in operationally focused security organizations that tend to be around for sales enablement and compliance. Executive teams usually see this security team as a checkbox they need to fulfill at the lowest cost. At the same time, security leaders want to focus on achieving high-quality results to demonstrate their value. These companies either don’t value security and/or are in an industry where security is not a high priority, e.g. they don’t have too much sensitive data or their customers deem them to be low-risk vendors.
High quality and low friction
An organization can achieve this duo if cost isn’t a primary factor. They can hire high-quality services and contractors to augment security. Similarly, they can hire top-tier but expensive security talent that excels in both engineering and operational work. They can also afford the best-of-breed tools. As a result of better staff and tools, security should be able to reduce friction in resolving security issues across the organization.
This approach works well in companies that have a large budget for security, either because they care about security or are forced to care about security, i.e. they are in a regulated industry. This also works well at early-stage startups in a space where customer trust is paramount, and it’s necessary for them to move fast. I’ve primarily seen this in fintech and healthtech. Companies in the data space also tend to have similar scrutiny.
Low cost and low friction
The easiest way to have this combination is to have a small security team that addresses/handles only the most severe risk and ensures that the company does just enough to achieve compliance. These teams will also be laser-focused on solving problems in the development phase where problems are easier and cheaper to fix, and likely only severe problems will be addressed in production. This isn’t ideal as the security debt and risk of a company will compound, but this is the only way to keep costs low without increasing friction.
This tends to exist in startups where security isn’t a priority. They are either considered low-risk vendors and/or don’t handle any sensitive information. As a result, they might need compliance audits like SOC2 to get customers, but likely they don’t need much security support beyond that. As a startup, they also need to move fast. These teams are primarily compliance and operational security professionals.
Takeaway
There are several levers an organization can pull to have some form of effective and efficient security team. The definition of “effective” and “efficient” will differ across organizations based on how much they value and prioritize security. I described three main features above that an organization can achieve. The best security leaders know how to achieve two without sacrificing the third too much. Unfortunately, most security teams tend to have one or sometimes none. This framework is important for executives to understand security organizational strategy and how to evaluate it.