10 principles for doing security and building cybersecurity products have remained unchanged since 1995
Looking at Adi Shamir's 10 Commandments of Commercial Security and their relevance in 2024
Over the years, I have witnessed a lot of trends and patterns in cybersecurity. Some are optimistic which makes me feel hopeful about the future of security, while others are less so. Among all these patterns, there are two that stand out the most which I would call cardinal sins of cybersecurity:
Too often, people in cybersecurity assume that every challenge our industry is experiencing today is new and has never been faced by those in other fields. This belief makes us waste effort trying to reinvent the wheel instead of first turning to knowledge from industries that are more mature than ours, such as software engineering, quality assurance, information technology, psychology, and the like.
Too often, people in cybersecurity assume that every challenge we are experiencing today is new and hasn’t been dealt with before in our own industry. This belief makes us jump into a search for solutions before learning if the same problem was observed in the past, and taking notes on how it was tackled before by the previous generation of security practitioners, founders, and industry leaders.
I have discussed the former in many of my previous articles, such as “Bringing software engineering principles, systems, and processes to cybersecurity” and “How pentesting mirrors the evolution of quality assurance”. In this piece, I am going to cover the latter.
Thanks to Rami McCarthy for inspiring & encouraging me to write this post.
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
Over 3,500 copies of my best selling book “Cyber for Builders: The Essential Guide to Building a Cybersecurity Startup” have been distributed to the readers so far.
The book is intended first and foremost for builders - startup founders, security engineers, marketing and sales teams, product managers, VCs, angel investors, software developers, investor relations and analyst relations professionals, and others who are building the future of cybersecurity. If this sounds like you, you should get a copy. The book has been rated 4.9 out of 5 on Amazon based on 80+ reviews, and in 2024 it became a finalist of the SANS Cybersecurity Difference Makers Awards.
Adi Shamir and his 10 Commandments of Commercial Security
In 1995, at the Crypto '95 conference attended by over 300 participants which at the time was considered a good-sized cybersecurity event, Adi Shamir gave a talk titled "Cryptography - Myths and Realities”. It was during that talk that he presented the now famous 10 commandments of commercial security.
Adi Shamir is not well-known to the new generation of security founders and practitioners, but he should be. While working at MIT in 1977, Shamir, Rivest, and Adleman developed RSA, an encryption algorithm used to secure the internet (RSA is the acronym for their last names). Present-day RSA Conference (RSAC) carries a part of his name. Shamir, together with Ronald L. Rivest and Leonard M. Adleman was later recognized with a Turing Award, known as the Nobel Prize for computer scientists.
Today, nearly 30 years later, Shamir’s 10 commandments remain as valid as they were at that time.
10 Commandments of Commercial Security: a closer look
1. Don't aim for perfect security
“So, be realistic, and do the best you can within your limits. Roughly, you should double security expenditure to halve risk.” - Adi Shamir
The fact that perfect security doesn’t exist was known three decades ago. Security teams could always be doing more, but at a certain point returns on new investments start to get lower and lower. The most unhappy people in security are idealists since they always feel like the business doesn’t care enough. Pragmatists understand that it's not just about trying to win more money on security; every dollar must be allocated in such a way that it can produce the highest return for the company as a whole. Sometimes, when there is no security program at all, that may very well be security. Still, at other times, it makes more sense to invest in international expansion, marketing, research and development, or other areas that produce the highest returns.
Cybersecurity is a business support function, and therefore security teams must get used to scaling non-linearly, similar to other departments such as human resources or IT. What this also means is that definitively calculating return on security investments (ROI) is hard. Say, how much more secure will we get if we invest another one million dollars into our security program? 1%? 10%? 60%? It’s hard to measure, and it’s even harder to measure if the success was indeed achieved. At the same time, we can usually be more certain about the ROI of, say, investing a million dollars in sales. Security leaders should most definitely continue advocating for security needs, while also recognizing that they need to do the best they can with the resources they have.
The same principle applies to security startups. No matter how hard they try, they will never be able to stop all security breaches, eliminate all zero days, and detect all advanced persistent threats (APTs). Anyone who suggests otherwise will immediately lose credibility because this is simply not how security works. Instead of aiming for or promising perfect security, cybersecurity vendors should be realistic and focus on delivering what is possible and feasible.
2. Don't solve the wrong problem
“For example, note that US banks lose 10 billion dollars a year in check fraud but only 5 million in online fraud.” - Adi Shamir
Broadly speaking, there are three drivers of security needs:
Adversary activity. Every day bad actors are seeking new ways to achieve their goals, which includes looking for new vulnerabilities and new attack vectors.
Regulatory changes. The government and other regulatory bodies are constantly evaluating what security measures should be mandatory and which ones should be recommended as best practices, and developing new guidelines, standards, and requirements.
Technology changes. Technology is constantly evolving, and the adoption of new tech necessitates new ways to secure it.
Security teams are always monitoring what is happening, and deciding how they should be responding. There are always a myriad of new developments so keeping track of all that and not losing focus requires a lot of discipline. Security leaders and practitioners have to make sure that at all times, they focus on solving the most important problem for the business. Focusing on what matters requires first-principle thinking, identifying what causes the most impactful issues in a specific organization, and going after those. Doing this is not easy since all three drivers of security needs - adversary activity, regulatory changes, and technology changes - fuel the emergence of new startups, new approaches, and new ways to solve old problems. Startups, having raised capital from investors, work hard to educate buyers about the problem they are solving. If you listen to founders, it doesn’t take too long to notice that whatever it is their company is doing has to be CISOs’ number one priority. It is that one thing that causes over 90% of breaches (and if not - it will certainly do that tomorrow, so security leaders better be proactive).
In all this noise, security leaders must remain focused on the interests of the organizations they are hired to protect. Oftentimes this means pacing their excitement about new technology and going back to fundamentals. While some new AI-generated threat or a new nation-state APT may indeed become a problem tomorrow, today their main concern may still be, say, MFA enforcement and email security. The very same thing applies to startups. Founders often get excited about new technology and lose sight that some of the most “meaty” problems are those that have been around for a decade or two, are well understood, but still unsolved.
3. Don't sell security bottom-up
“(in terms of the personnel hierarchy).” - Adi Shamir
It is fascinating to realize that three decades ago, there was enough understanding of the market to suggest that bottom-up sales won’t work in cybersecurity. It is even more incredible that little has changed about this, and it’s not for the lack of trying.
For decades, we’ve been trying hard to find a way to get security practitioners to champion solutions they like, and in most cases, we were unsuccessful. There are some exceptions, each of which comes with a lot of footnotes. For example,
Auth0 was incredibly successful with product-led growth (PLG) but if we zoom in closer, we realize that they didn’t sell a security product to security teams. Instead, they sold a tool that abstracted away the complexity of implementing authentication. We have learned enough to know that for many reasons, with the exception of security engineers at cloud-native venture-backed startups, security practitioners don’t have enough power to get a vendor through the sales process. Software engineers, IT teams, and others also don’t see security as something they need to worry about, and therefore they don’t buy security tools.
Sourcefire was successful selling bottom-up but that was because it was built on top of Snort, an open source project which by then gained huge traction. It’s worth noting that while there are several open source projects which over time evolved into highly successful companies, they all happened organically when maintainers saw an opportunity to extend something that had a lot of community love and adoption. On the other hand, attempts to build a commercial security product by first designing an open source version and trying to use it as a “trojan horse” for the commercial product to my knowledge never produced incredible outcomes.
I have several articles about selling security bottom-up, and I usually discourage startup founders from trying to rely on product-led adoption as a primary vehicle for growth. For those interested in learning more, I recommend reading “Caveat emptor: product-led growth in cybersecurity can be a great idea, but it can also hurt or even kill security startups”.
4. Don't use cryptographic overkill
“Even bad crypto is usually the strong part of the system.” - Adi Shamir
“Even bad crypto is usually the strong part of the system” is, in my view, a good reminder that security teams should be looking to leverage what was already built by someone else so that they can focus on unsolved problems specific to their environment, instead of unnecessarily reinventing the wheel. While the original point was about cryptography, I think it applies to almost any other area where people may be tempted to do the so-called “undifferentiated heavy lifting”.
I have noticed that there is a strong tendency of many security people to focus on areas they are most passionate about at the expense of the areas that need the most attention. This is not unique to security - software engineers, for instance, like to do the same. The difference is that in areas such as software engineering, we have built solid systems and practices (such as product management) that seek to at all times align what the teams are working on with what’s the highest priority for the business. For a variety of reasons, security is still lacking this mindset, and in many companies, security practitioners are investing their time and effort into areas that aren’t most valuable to the organizations at their stage of maturity.
The same pattern of solving non-critical problems is repeated by cybersecurity startup founders. Many of them start companies that are essentially passion projects far removed from the real needs of the industry. Security purists, in particular, frequently spend years trying to get something to 99.9% where 80% would suffice. While there is certainly nothing wrong with going after problems someone is excited to solve, when these companies raise capital they often get stuck because customers are content with “good enough” solutions.
5. Don't make it complicated
“This yields more places to attack the system, and it encourages users to find ways to bypass security.” - Adi Shamir
Today, we often talk about the fact that security tool sprawl is dangerous because it expands a company's attack surface and makes it easier for bad actors to find and exploit vulnerabilities. It’s fascinating to think that we ended up with the problem of vendor sprawl despite having known about the potential risks since at least 1995!
The more complex the controls, the more time security teams will need to spend integrating them into a cohesive program, the more cumbersome they will be to maintain over the long term, and the harder it will be for security leaders to understand what areas have good coverage and which are lacking. Without any doubt, unnecessary complexity makes things harder for security teams, but the real danger is in how it impacts the workforce. The more complex the controls and the more impact they have on user experience, the more likely it is people will find ways to circumvent them. This makes complete sense because users will always seek the least friction way to do their jobs (even if that also means the most insecure).
In cybersecurity, we often repeat the mantra that security teams need to do more with less. Once in a while, I wonder - maybe we should just strive to do… less? Maybe, having fewer controls but focusing on the highest-impact items could lead to more robust security coverage. The best way to do things in security is to build systems secure by design; the second best is to layer security in such ways that make secure behavior the most frictionless behavior. When people have to go the extra mile to do things insecurely as opposed to doing things securely, that’s when we will know that we are doing things the right way.
The same principle - “Don’t make it complicated” - applies to the way vendors build and market security solutions:
Oftentimes the way founders pitch their company makes it impossible to understand what problem their tools are actually solving. They fall in love with technology and lose sight of what matters to their buyers.
It is exceedingly rare that security leaders and practitioners can make sense of the ways companies market their products. One can spend hours reading marketing materials and public-facing documentation and still have no idea what the solution (or the problem) is. Our marketing is unnecessarily complicated.
The way most security products are built disregards not only best practices around user experience but also the way builders of these tools interact with the software themselves. We are used to clunky tools with confusing interfaces that require hours of reading documentation, sitting through training sessions, and learning new terminology. The problem around user experience doesn’t just increase the total ownership of security tools, but it also makes it more likely that security practitioners will misconfigure them, fail to maintain security coverage or leverage what the vendor provides altogether. It’s not uncommon for people to deploy security tools and pay for their subscription only to then realize that some 50% of the coverage the product was meant to provide was disabled.
6. Don't make it expensive
Cybersecurity is expensive, and we as an industry have become used to it. Not only that, but we have come to believe that it has to be that way. Since the main driver for security purchasing is compliance, and large public companies tend to be the most heavily regulated, vendors primarily build products targeted toward large enterprises with deep pockets. One of the consequences of that is the fact that most security tools are simply unaffordable by organizations unable to allocate millions or even billions of dollars to security which leads to the cybersecurity poverty line.
Security leaders who are used to paying exorbitant amounts of money for new capabilities get incredibly suspicious whenever some vendor charges less than its competitors. I have heard several stories about how a great solution would lose against the competitor because CISO thought that the price they ask for is suspiciously low, and therefore their product must be worse in terms of coverage and reliability. Security leaders are much more likely to buy more expensive tools and negotiate some discount than to consider alternatives that are cheaper to begin with. This paradox isn’t unique to security - it is simply how we have learned to perceive the relationship between price and quality. These psychological hacks are also the reason why we think that it’s better to get something that’s “on sale” at 50% off with the final price of $100 after the discount, rather than something that was priced at $100 from the beginning.
It’s not only cybersecurity buyers and sellers who have normalized the fact that security is expensive, but also the tech industry at large. There is plenty of discontent among security practitioners about the so-called SSO tax and audit logs tax. Tech companies of all sizes have learned to make customers pay exorbitant amounts of money just to get access to basic security capabilities. It’s no different than if the car industry was allowed to charge an extra 50%-1000% for providing seat belts. And yet, since that is normalized, we are unlikely to see any changes. As I have previously explained, these problems stem from the low maturity of product management practices in the tech industry, and the fact that security needs are a very convenient shortcut for SaaS companies to rely on when pricing their products.
7. Don't use a single line of defense
“Have several layers so security can be maintained without expensive replacement of the primary line.” - Adi Shamir
“Don’t use a single line of defense” is one of the principles that we as an industry have been wholeheartedly embracing and completely ignoring at the same time.
On the positive side, gone are the days when companies would rely on a single security tool such as a firewall or an antivirus to protect them against everything that can go wrong. This is partly because we as an industry have matured so we understand that there are no silver bullets, and partly because the number of potential attack vectors has exploded. There is now a solid understanding reinforced by frameworks and compliance standards that a holistic security program needs to cover many areas - from network to endpoint, identity, cloud, and application security, to email security, API security, SaaS security, data security, and so on.
On the less positive side, in our desire to consolidate all security tools under a “single pane of glass”, we are confidently marching into the world where several large vendors are turning simultaneously into a single line of defense and a single point of failure. As I explained in one of my previous articles, “... any monolithic platform becomes less secure as it grows in size. People who had an opportunity to work with a large legacy platform, be it SAP, Salesforce, or Workday, know that the bigger the platform, the less efficient it becomes. Moreover,
Large platforms drown in technical debt.
Large platforms have poor support channels.
Large platforms become insanely hard to implement, especially in fields that require customization.
Large platforms are expensive because most customers are paying for a multitude of features they will never use.
Large platforms are expensive because the deeper they become embedded into the customer’s workflows and the more areas they cover, the harder it becomes to switch and the more power the platform vendor has over the buyer.
Last but not least, the larger the platform, the bigger its surface area, and the more vulnerabilities it ends up introducing. To top it off, bad actors find it easier to focus their efforts on poking holes in one single tool which unlocks all doors, thus leading to the situation when the biggest security products may also become the most insecure single failure points.”
As an industry, we have to be mindful of going too far in our attempt to reduce the number of vendors. This isn’t an easy problem to solve since on the one hand, we need to simplify our stacks, and on the other hand, we must avoid assembling security monsters. I have recently come to realize that consolidating tools doesn’t necessarily lead to simplification. Quite often the opposite is true. There are two dimensions we have to look at: technology and budgeting. From the procurement and budgeting standpoint, consolidating multiple capabilities with one vendor will indeed almost always lead to simplification. This makes sense since instead of dealing with, say, five vendors, negotiating five separate contracts with their own pricing, renewal cadence, and so on, CISOs can deal with one (one vendor, one contract, bundled price, one support team, etc.). The problem is that oftentimes, moving to a single vendor complicates the tech side. Many of the so-called platforms are essentially assemblies of tens of disjoint tools cobbled together into one solution. Some may have invested a lot of time and effort into integrating these individual tools, most of which are probably acquired and not built in-house, but others didn’t. Dealing with a Frankenstein of cobbled tools that all have their own data standards, API specifications, architectural differences, and so on, may be incredibly costly. This is to say that consolidating contracts may simplify procurement, but complicate the technical environment and increase the total cost of ownership.
8. Don't forget the “mystery attack”
“Be able to regenerate security even when you have no idea what's going wrong. For example, smart cards are attackable but are great for quick cheap recovery.” - Adi Shamir
Even though we have thousands of tools focused on detection across different asset classes such as users, networks, endpoints, applications, and data, we cannot hope that we will be able to prevent, detect, and remediate every single threat. Something will inevitably slip through, and that something may be completely unexpected, and hard or outright impossible to explain. Our focus should therefore be on resilience not just prevention, detection, and response.
Resilience means different things to different people. At the very fundamental level, it is about ensuring that the company will be able to withstand an attack and recover from it. Over the past decade, we have gotten somewhat better at disaster recovery and resilience. However, many of the ideas remain just that - ideas and many best practices are still largely ignored. For example, there has been a lot of talk about self-healing APIs, self-healing networks, and other self-healing systems that are able to withstand threats and unexpected changes, whether caused by bad actors or malfunctioning of the system but so far these are mostly just ideas.
Security vendors should build products that account for mysterious attacks, and provide customers with tools that make it easier to prevent, detect, and recover from them. This may include telemetry storage for retroactive threat hunting, going beyond static rules, implementing machine learning for anomaly detection, and so on.
9. Don't trust systems
In 2024, zero trust has most certainly become a buzzword in our industry. More and more companies are starting to embrace the idea that systems cannot be trusted, implementing microsegmentation, device trust, continuous validation, workload monitoring, secure access service edge (SASE) solutions, and other seemingly new approaches. However, reading what was captured as one of the core pillars of security back in 1995 - “Don’t trust systems” - makes it clear that zero trust is anything but new.
The idea that everyone and everything needs to be continuously validated has existed in cybersecurity for several decades, and it has taken us this long to start operationalizing it on the industry level. The word “start” is key here: while 61% of companies claim to have an ongoing zero trust initiative, it remains unclear what the depth of zero trust adoption actually is. This is because zero trust is first and foremost a way to architect systems, not a tool a company can buy to become “secure”. True zero trust requires a lot of intentionality, and necessitates fundamental rebuilding of the way companies grant, validate, and revoke access to their systems. Doing this well is hard, and I would not be surprised if a decade from now there will be a renewed push for yet another iteration of zero trust.
Another dimension of not trusting systems is ensuring that we don’t blindly trust third parties we rely on. This is undoubtedly a painful topic given that third-party risk has turned into a game of filling out questionnaires with ChatGPT, and the dream of investing in supply chain security remains just that, a dream. Security vendors in particular have to be careful about their third-party dependencies: since cybersecurity products get a lot of access and highly sensitive permissions, startups have the responsibility to make sure that they won’t turn into a “trojan horse” for attackers.
10. Don't trust people
Oftentimes it feels like if there is one thing the industry fully agrees on it would be the principle that suggests we should not trust people. However, when we take a closer look at this aspect, things start to unravel very quickly.
Security practitioners have been quite good at instituting a zero trust mindset when it comes to the employees at companies they are designed to protect. Quite often, however, this mindset ends with finance, sales, marketing, and customer support which are “known” to be some of the worst offenders in the context of security. When it comes to securing developers, and even more so company executives and board members, this is where things get complicated. It’s not unheard of for companies to create exceptions around MFA or to circumvent some other common sense controls because a CEO or a board member (ironically, people with a lot of access to highly sensitive documentation) just don’t want to deal with extra friction.
While we as an industry have learned to not trust employees at our companies, it is fascinating that we continue to trust people in other circumstances. For example,
While we don’t lack tools for continuous compliance monitoring, we are still for the most part relying on point-in-time evidence such as screenshots and written attestations. This “evidence” doesn’t prove that the company was compliant at all times, but rather that it is compliant when it is being audited.
Cyber insurance underwriting remains focused on high-level questions, even if they are becoming more and more granular. Instead of looking for ways to gather evidence that buyers are indeed doing what they claim to be doing, we continue asking things like “Do you have MFA enabled? Yes or no?”.
The whole area of third-party risk is built on self-attestation of compliance. While for the most part, the actual third-party risk is transferred via contracts and vendor agreements, we continue to play this game of requesting and responding to security questionnaires. Nowadays, with the advancements of AI and ChatGPT, the market is flooded with tools that on one side, help to fill out these questionnaires, and on the other side, allow buyers to “summarize” vendor responses.
The industry continues to rely on expert reviews and endorsements as a part of the purchasing process. Opinions of industry analysts, endorsements from CISO communities, customer testimonials, and other types of trust factors greatly influence the probability that a startup will get early traction.
We continue to rely on anecdotal evidence when evaluating the effectiveness of controls. The phenomenon that Daniel Geer, Kevin Soo Hoo, and Andrew Jaquith described as “oracles and soothsayers” continues to persist and there is little evidence it is going to change anytime soon.
As humans, we cannot live in a continuous state of zero trust. At the end of the day, we need to trust others, work with others, and build meaningful relationships with those around us. What matters is that we choose wisely whom to trust, and understand what incentives are at play in any given situation. We have made a lot of progress on this front with the emergence of private communities for security leaders and ISACs, to name a few, but there is more we can do.
Closing thoughts
It has been nearly 30 years since Adi Shamir gave his famous talk and unveiled the 10 commandments of commercial security. Thirty years is a very long time for our industry (it’s also about as long as the CISO role has been in existence), but a drop in the ocean for other mature knowledge areas such as law, medicine, or accounting.
The young generation of security practitioners has been led to believe that the problems our industry is facing today are somehow new. As this article was meant to highlight, they are not. Three decades ago, we had people warning us to not sell security bottom-up, to not waste time tackling problem areas that don’t meaningfully contribute to our security, and to not overcomplicate our infrastructure. Three decades ago, we had people warning us that systems and people cannot be trusted. Does this mean that the industry is where it was before? Certainly not. What it means is that we have to continue focusing on fundamentals. Security leaders, security practitioners, and security founders alike have to keep in mind what real priorities are and where most of the attacks originate. Ironically, that hasn’t changed much either (even though we undeniably made a lot of progress).
As we are looking to build the future of security, let’s all remember the 10 commandments left to us by Adi Shamir and the generation that came before us.
Great one but challenge is till here....
The challenge? Well, it’s like teaching a cat to bark. These principles make sense to anyone with half a brain left unscrambled by PowerPoints, but they demand a shift in thinking that most security leaders wouldn’t manage even if their hair was on fire. Strategic advantage? Sure, if you're willing to explain it slowly enough for the boardroom crowd that counts their pennies before their brains.