Building practitioner-focused cybersecurity: nine principles for founders and product leaders
Ahead of the RSA Conference, I am sharing principles for building the future of cybersecurity
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!
The need for practitioner-focused security products
In the past several decades, security has gone through an evolutionary loop. As a discipline, it started in communities of people who were tinkering with technology, trying to understand the fundamentals of how the code and other moving parts behave, and subverting it into doing what it wasn't designed to do. Then, came the period when security started being seen as a product problem - "what tool do I need to buy to become safe". With that shift, large vendors proclaimed that they will "keep anyone safe forever" as long as customers keep paying for their products. After a few decades of the promised safety, we have learned that it is not how security works. Fast forward to 2023, and we have solid proof that despite all the advertised magic and promises to keep everyone safe, it's not products, but security practitioners who defend people and organizations. While not everyone has realized that, those who should, did.
I have talked a lot about the trends I am seeing in the industry, including the move from promise-based to evidence-based security, the rise of security engineering, and the reasons why its people, not tools, shape the future of security. It is important to acknowledge that security vendors are very much needed. However, what we need are not magic widgets with a big red "activate shield" button in the middle of the screen, but professional tooling that security practitioners can use to do what they can do best.
In this piece, I am looking at principles we as an industry can adopt to build this practitioner-focused security.
Building practitioner-focused cybersecurity: nine principles for founders and product leaders
Accessibility
Cybersecurity products have an accessibility problem on multiple levels. Most security vendors make it impossible for practitioners to get started with the product and set it up in their home lab without having to attend multiple sales calls. Moreover, many companies require prospects to "qualify" for their tooling, and meet minimum spend requirements or another arbitrary threshold such as a minimum number of endpoints. To top it off, some providers force buyers to sign multi-year contracts, commit to certain consumption levels, and forecast demand multiple years ahead. Lastly, it is not uncommon for security vendors to sell training about using their complicated products, making it hard for those that do get access to the tool to make the most out of it.
Imposing these restrictions leads to several issues. First, it makes it hard for students, as well as aspiring and junior security practitioners to learn the tools they need to know to find a job in the industry. This perpetuates systemic barriers where those from non-traditional backgrounds and people who are not yet employed by large and well-known corporations cannot catch up with their more fortunate peers by putting in the hard work on their own time. Second, it makes professional security tooling inaccessible to small and medium-sized businesses - those that are most vulnerable to security attacks. Lastly, minimum order amounts create barriers to entry into service businesses: many security professionals could have been running small managed detection & response (MDR) providers on the side if not for the fact that vendors commonly force them into long-term contracts and minimum spending.
Security products of the next decade have to embrace accessibility. Security practitioners should be able to get started with the product without having to attend a series of mandatory demos, deploy it in their home lab, and do a proof of value (POV) on their own terms. Moreover, there should be no requirements about minimum spend, or a need for customers to sign multi-year contracts unless they choose to do so. We have examples of what accessibility looks like from many other industries such as developer tools, and there is no reason security should remain behind the rest of the tech space.
Transparency
For many years, security has been sold as a magic solution to little-understood problems. Up until today, we see many vendors claim to stop zero days, advanced persistent threats, nation states and even guarantee "zero false positives" - something that is not possible and not reasonable. The marketing game of cybersecurity providers has been simple: offer as little information as possible about how the product actually works, get the prospect into a demo, intimidate them and induce fear with stats about the size of the problem, and then sell them on a little understood "next-gen revolutionary security widget that stops 100% of everything bad".
This marketing approach is damaging to the future of security for several reasons. First, it forms an incorrect idea that security is a "feature" that can be purchased and simply "enabled", rather than a process and an approach to doing things people and organizations need to think about when they do their daily work. This oversimplification of security then creates a false sense of safety for customers who start believing that they are protected by some kind of magic tool. Second, this approach to security leads to wasted resources that could be used to actually strengthen one's security posture. None of this helps us build a more secure future.
The need for transparency goes beyond marketing. Some of the layers of product transparency include:
What problems does it solve and what problems does it not solve? (marketing & documentation)
How much does it cost? (pricing)
How are decisions made? (detection logic)
What does the data that powers decision-making look like? (telemetry)
How is the product built? (code)
Companies should listen to their customers to learn what kind of transparency they need and provide it while considering the business constraints.
Today, security products are built like black boxes; as security teams mature, this needs to change. Defense teams need the ability to know the exact set of malicious activities and behavior they are protected from. This requires access to detection rules, being able to test, and when needed - adjusting and customizing their logic to the unique organizational environment. The benefits of this transparency are plenty: defenders will develop a better understanding of their organization's detection coverage, and over time - expertise needed to tweak it to their needs; companies will be able to adopt a DevOps approach to security, leverage CI/CD pipelines, version control, detections as code, and other advances in the field; security teams will get more ownership over the outcomes and not be forced to rely on vendors alone.
Interoperability
Security is not a problem that can be solved with one tool, at least not today and likely not anytime soon. An average enterprise security team relies on a large number of products. Different reports quote anything between as few as 20 and as many as 80; something in the middle between these two numbers is probably the most common.
For the security team to build a holistic picture of the threat landscape, understand its environment, and detect and respond to malicious behavior, it needs the tools it uses to talk to one another. This, unfortunately, can be a challenge, as many cybersecurity vendors do not make their products interoperable and easy to integrate with others. When it is possible, one of the two scenarios is commonly true:
Integrating security tools to work together can be incredibly hard and time-consuming. This forces security teams to choose where to spend their limited time and overextended resources: on integrating products, or defending their organizations.
Artificially imposed restrictions and arbitrary limitations create vendor lock-in and make it hard to leverage tooling to its fullest potential. It is not uncommon for vendors to restrict the types of data that can be accessed and sent to another tool, the types of operations that can be accomplished via API, and the like.
Practitioner-focused security tooling needs to be built on the principle of interoperability. Users should be allowed to own and fully control their data, and freely decide what type of data is sent and where. Security providers should as much as possible use common taxonomies, standards, frameworks, and protocols to make integrating with other products easy. Moreover, users of security products should be given a generic way to integrate with providers that are not a part of the vendor's network of partners, instead of locking them into the ecosystem of "approved" and "preferred" options.
User experience
We live in a world that prioritizes user experience: from Apple with its suite of products, to apps like Uber and even B2B solutions, the importance of good design and seamless interactions is well understood. That is until we look at security where users have gotten used to complicated flows, confusing designs, and inconsistent patterns of interacting with the product.
While security providers tend to invest in building new features and capabilities, the experience of those that will be interacting with the solution - be it engineers, security analysts, or regular employees, is typically an afterthought. This is unfortunate because the power of any security tool can only be realized if the users do not dislike spending time navigating it.
Users today expect the same intuitive and seamless experience from their B2B enterprise tools as they do from their iPhones. First, for cybersecurity to become an integral part of our lives, it needs to not introduce a lot of friction. Second, as security vendors are focused on adoption in the enterprise, they will have little choice but to make their tools easier, friendlier, and more intuitive to navigate. The time when people could allocate hours to go over technical documentation and read 100 pages of user manuals is quickly coming to an end: the easier it is to try and implement a tool, the more likely it will be purchased, implemented, and used.
As we are looking to build practitioner-first security, we will need to start prioritizing the needs of those who are expected to use the product daily. Without the emphasis on design and user experience, it won't be possible to accomplish.
Extendability
In 2023, it is well understood (at least by mature security teams) that every organization's environment is unique, and the way certain behavior can be detected in one company can be vastly different from the way it can be done in another. In practical terms, this means that any security tool needs to be customized and fine-tuned to match the unique needs of every organization.
Unfortunately, many security vendors do not make it easy to extend the basic product functionality. A case in point is vendors focused on detection and response: while most have started allowing users to create their own detection logic, the telemetry they expose and the capabilities of the language may not be enough to craft useful, high-fidelity detections.
If a security team can describe something they want to detect or prevent, they should be able to write a detection logic and apply it unilaterally, without having to rely on vendor intervention. For mature security teams, this flexibility will make it possible to leverage the research they do and be proactive in designing defensive measures tailored to the threats the organizations face. No one should be forced to submit support tickets and wait until a vendor adds new detection logic when they know what needs to be done, how, and when.
Extendability is closely related to interoperability as security teams should be able to customize tooling to fit their needs, which often means leveraging API, architecture workflows, and complex integrations - all of which should not be an afterthought for vendors.
Focus on problems
Cybersecurity is a complex technical field that sees ever-growing demand, and therefore it attracts many entrepreneurial technologists looking to shape the future of the space. It takes deep domain expertise to build a security company, hence why most founders in the industry are either former practitioners or business leaders with many years of working in the field. In other words, it is hard to come up with a good cybersecurity idea that would end up succeeding at a university hackathon; not entirely impossible but highly unlikely.
As security is a technical field, it naturally attracts people who are creative technologists, those who like to tinker with new ideas and innovations looking for ways to apply them in the industry. This factor, which is undoubtedly one of the strongest sides of the industry, is also one of its most pronounced weaknesses. This is because the focus on technology at times leads to technology-first solutions - products that leverage the latest and coolest tech in search of a problem. Some of the recent examples include blockchain, smart contracts, AI, and the like. On their own, these technologies are neutral, what matters is how they are used. Unfortunately, many founders instead of focusing on the problem and asking "what tools are available for me to solve it?", look at new exciting tech and think "how can I find a problem to solve with it?". This backward thinking leads to startups infusing AI, blockchain, ChatGPT, NFT, virtual reality, and other promising tech where it doesn't really add anny value.
Practitioner-focused security tooling must focus on the problem first and treat technology as the means to do it, not the other way around. Adopting this approach will lead to less hype and more problem-solving - something that we as an industry badly need.
Testability
The concept of testability builds on the idea of transparency. Today, most security products are built as magic black boxes - vendors make statements such as "we detect all threats and stop all attacks"; customers are forced to take these promises. What is rather unfortunate is that even when we as an industry make progress and create ways to codify our knowledge and build a foundation of testability, companies take that and dilute both the intent and the real meaning of these advancements. Take MITRE ATT&CK framework - a guideline for classifying and describing cyber attacks and intrusions designed to make it easier for security teams to ensure that they have the coverage in place for different behaviors. Unfortunately, vendors don't shy away from proclaiming that their products "cover 100% of MITRE ATT&CK" and making other statements that miss the nuances and mislead unsuspecting users into thinking that they are fully protected when in reality, they are likely not.
Making security products testable means that the exact set of malicious activity and behavior a customer is protected from should be known and they should be able to test and prove this. Without being able to analyze not just what is being detected, but how it is done - what signals and what logic is used to trigger a detection - no tests can show a complete picture. Tests should be easily reproducible, and this means that security teams should be able to write unit, integration, and regression tests as code and run them at any time to validate their defenses.
Security products of the future will need to be testable at scale - not just manually, by having people click on different parts of the web app, but on-demand using automation and continuously as a part of CI/CD pipelines.
Scalability
As security relies on data and the volumes of data continue to go up, and as businesses set aggressive growth targets and look for ways to scale their operations, security mustn't lag behind. For organizations of all sizes and across all industries, the ability to scale security infrastructure, systems, and coverage to address increased workloads, growing demand, and business appetite for expansion is of utmost importance. Scaling security infrastructure is hard as it requires the ability to manage dozens of different tools, keep in sync and control the versioning and configuration of hundreds and thousands of security policies tailored to different needs and types of users, and much more.
In the past, security products were built for human scale - the idea was that an analyst or even a team of analysts can make a limited number of changes at the same time. As the scale of enterprises grew, security companies started building APIs on top of otherwise inflexible tooling, - an approach that enabled many to make things better but didn't solve the problem fully.
Today, we need products built for machine scale, where everything is designed API-first from day one. Practitioner-focused security tooling must be infinitely scaleable and able to handle increased customer demand, as well as unexpected changes to the business, be it a rapid increase of transactions, data, number of tenants, or any other metric which may impact the use and experience with the product.
Engineering-centricity
Transparency, interoperability, extendability, testability, and scalability are all by-products of the engineering mindset. Security teams are starting to understand that tools are just tools and that no product is going to truly secure an organization. The actual work for defending an enterprise is in the hands of practitioners who need to understand the risks their company is facing, what types of attackers target the business, what behaviors are they likely to show, how these can be detected, what response is appropriate in a particular situation, and so on.
Armed with this understanding, security professionals need to gain full visibility into their environment, into what they are detecting and how they are doing it, how that is being tested, and what happens when the gaps are uncovered. Embracing an engineering approach to security means integrating security in CI/CD pipelines, leveraging the advancements of DevOps, detections-as-code, infrastructure-as-code, and other approaches that have proven to work and scale in other areas of technology. As I have explained before, "When a team detects new vulnerabilities and malicious behaviors, they should have the tools to respond to them in a way that eliminates the need to manually apply the same response to the same vulnerability tomorrow. Historically, most of the security knowledge resided in the heads of experienced practitioners who have “been there, done that”. As the industry is maturing, we need to look for ways to codify this knowledge and make it shareable, testable, and accessible for use and improvement for organizations across the globe. Cybersecurity will always be an art as it deals with the creative, intelligent adversary. However, it needs to also become a science if we want to continue growing our knowledge base and make cyber defenses accessible to organizations who cannot afford to hire “the best of the best” in the field. Taking the science-based, engineering approach to security will enable security teams to build systems and processes to do their work consistently."
Closing thoughts
In the previous piece, I explained why building security products is hard and why skilled security practitioners are the only way to achieve an advantage over the adversary. Although it is tempting to believe that we can find a magic product that is going to “activate shields” over our heads, the reality is much less magical and much more sobering: the future of security relies on people. Adversaries are highly motivated people with often strong technical abilities; we need people on the defense side to be as strong, and we need many of them.
To be effective at their jobs, security practitioners need tools that act as components of IT infrastructure, that don’t overpromise, and that don’t impose unnecessary limitations. They need tools that can be understood, tested, and that can play well with others. In the past, only open source cybersecurity tooling would offer that level of openness; as we are looking to build the future of security, we must get commercial vendors that take a similar approach. Fortunately, we are slowly starting to see more and more focus on the needs of practitioners, and I am cautiously optimistic we are on the path that will lead us to better security.
A very old Panther blog echos your ideas: https://panther.com/blog/panther-database-as-service-modern-serverless-architecture/