Building products securely is not a security problem, it’s a product management problem
How bad product management practices lead to global insecurity and what we can do to address it
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!
As product leaders, we are responsible for shipping software that solves customer problems and enables our companies to grow. Achieving this is not easy: the competition is stiff, the time is limited, and the pressure to execute is enormous. Moreover, although those of us lucky to see our startups grow will get to proudly present frameworks and develop methodologies for achieving success, the truth is that building products is anything but straightforward.
Having worked across many different industries - retail, wholesale, e-commerce, financial technology, and now - cybersecurity, I have learned that building products is both an art and a science. Throughout my career, I was fortunate to make some good product decisions, fight some bad habits, and make my share of mistakes. I have also observed some patterns that tend to repeat again and again; this piece is about one of them.
In this article, I am discussing how immature product management practices in the tech industry lead to poor design decisions, and ultimately undermine our security.
Building products securely is not a security problem, it’s a product management problem
In the past several months, I have had conversations with many people in the industry concerned with the fact that we need to build products secure from the ground up. This isn’t a coincidence: the recently unveiled by the White House National Cybersecurity Strategy states in clear terms:
“We must begin to shift liability onto those entities that fail to take reasonable precautions to secure their software while recognizing that even the most advanced software security programs cannot prevent all vulnerabilities. Companies that make software must have the freedom to innovate, but they must also be held liable when they fail to live up to the duty of care they owe consumers, businesses, or critical infrastructure providers. Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not on the end-users that often bear the consequences of insecure software nor on the open-source developer of a component that is integrated into a commercial product. Doing so will drive the market to produce safer products and services while preserving innovation and the ability of startups and other small- and medium-sized businesses to compete against market leaders”.
This means that companies building software must start thinking about security the moment they are beginning to explore the feasibility of an idea, and not after the code has been shipped or is ready to hit the production environment. Shifting security left means several things, one of which is that building products securely is no longer a security problem; it is a product management problem.
Customer discovery and cybersecurity
One of the most critical responsibilities of the product manager is continuous customer discovery. It is by talking to customers, observing market trends, analyzing user feedback, conducting interviews with prospects who chose not to adopt the product, and the likes that product managers can understand what it is that different types of customers value. Continuous discovery shapes everything, from decisions about the features the company needs to build, to pricing the product and picking a market segment to go after.
Identifying companies that do not prioritize proper customer discovery is easy: all one needs to do is open the pricing page and look at what features are listed as “enterprise-only”. Products built by immature teams typically have three of them: single sign-on (SSO), the ability to access audit logs, and role-based access controls (RBAC). Security capabilities are sold as enterprise-grade features, and some vendors have gone as far as restricting the ability for non-enterprise users to enable multi-factor authentication to access their software.
Gating security as an enterprise feature has serious consequences as the so-called SSO tax and audit logs tax make it hard for small companies to afford what they should be provided with by default - the ability to secure their data.
To solve this problem,
Product teams should go beyond the obvious and spend time learning what unique problems different types of customers have, and what their willingness to pay for solutions looks like.
Armed with that understanding, PMs should be able to design pricing tiers that enable companies to generate revenue and upsell their customers without restricting access to SSO and audit logs.
Treating security as a non-functional requirement during planning
One of the core responsibilities of the product manager is ensuring that the development team always works on the highest-value items, a task typically accomplished by maintaining a well-defined planning process.
When the product team is scoping a new feature, product designers and engineering leaders are usually an active part of the planning process. The people who are, unfortunately, not at the planning table are security professionals. In most organizations, security requirements are still not seen as “functional”, and instead treated as something that can be layered on later. Security practitioners aren’t currently being invited to be a part of the planning process, even though they most certainly should be.
Security can no longer be seen as an afterthought. To make it happen,
PMs need to start including representatives of the security team when planning new features and capabilities. Security has to be planned and built in from day one, not “sprinkled” on top to check the box when the feature is ready to be released.
PMs should learn the basics of security, the way they did with user experience, data analytics, and software engineering. While no one expects them to become deep domain experts, they should understand the vocabulary and be able to communicate with product security team members.
Cutting security requirements as non-essential during the product launch
To win in today’s competitive market, tech companies need to maintain high development velocity, shipping software faster and more often. Naturally, high velocity means many trade-offs, and the need to constantly adjust the scope of features and products. Since PMs are ultimately responsible for managing new product launches and ensuring that the company meets its goals, it is a part of their job to maintain the team’s focus and cut non-essential functionality.
Cybersecurity product requirements are routinely deemed as non-critical and pushed to the bottom of the backlog. This isn’t a result of some kind of malicious disregard for security, but rather a second or third-order consequence of the need to get to market quicker. The way security gets deprioritized looks as follows:
An early-stage startup needs to validate the idea and get a minimum viable product to the market. Since there are no valuable assets and no customer data, the team rightfully asserts that this is not the right time to worry about security - they need to validate the problem, the solution, and the market first.
After the startup has validated the problem, and acquired some users, it needs to get a fully-functional product to the market to not lose momentum. It makes sense to not over-invest in security, and focus on building the product instead.
Assuming that everything goes well, what follows is the time to scale and do the land grab, capturing as much market share as possible. At the growth stage, there are simply not enough resources to think about security; everyone on the team needs to be heads down shipping new capabilities, expanding the product offerings, and getting the sales numbers to go up.
We can keep going, but the main idea is clear: at every step of the way when product managers work on launching new software, they have to be ruthless about prioritization and cut scope to move quickly. Unfortunately, cybersecurity requirements are one of the first to go - not to be dismissed entirely, but to get implemented only partially, with the idea that the rest will probably happen “in the coming sprints”.
It would be naive and unrealistic to believe that we can somehow slow down the speed of innovation (which is also why the letter asking to “slow the pace of AI development” is nothing but a well-intentioned PR stunt). It doesn’t help that penalties for building insecure products are meaningless: it makes perfect business sense to launch a new product quickly and with little regard for security, and generate a lot of revenue. Then, when the cyber incident inevitably happens, the company can simply pay a small percentage of the profits as a fine and move on to building the next product.
While PMs cannot solve the problem without a broader discussion on the industry level, we can make it better.
Product managers must evolve and start seeing security as a part of their work, no matter what industry they’re in. This means taking the time to learn about best practices in shipping secure products, common mistakes software teams make, and design patterns that are prone to cause cyber incidents.
PMs must look for ways to prioritize security from day one with the understanding that there will never be “the right time” to start working on hardening the product. The best time for security is yesterday; the second best is now.
Closing thoughts
The role of the security team is to act as an enabler, helping product teams by sharing the best practices, offering recommendations, and suggesting specific fixes. Then, it is the responsibility of the product managers to ensure that security requirements are being prioritized during the development process.
As a technology industry, we have allowed privacy, security, and compliance to be perceived as features that can be gated behind additional paywalls to drive revenue. This approach cannot be allowed to stand: capabilities that make the product secure are foundational to what the product is; they are not features for upsell and cross-sell.
To a reasonable person today, it is hard to imagine the world in which they had to pay extra to have railings on their balcony, lifejackets on the cruise, or a seat belt in their car. It is tempting to restrict single sign-on (SSO), audit logs, and other safety capabilities to those who can pay extra, but we must not allow this behavior to continue. We know that public pressure can force vendors to improve: just recently Microsoft expanded its suite of free security tools following the criticism that it was charging clients to protect themselves against Microsoft's own mistakes.
There is nothing that stops companies from evolving their product management practices and shipping more secure products. It is worth keeping in mind that building products securely is not a security problem, it’s a product management problem.
While I largely agree with this I think there is some subtly that should be discussed here.
There are security 'features' such as SSO and logging, etc. that I totally agree with you on (and have some opinions on as discussed here - https://www.nudgesecurity.com/post/why-the-sso-tax-needs-to-go).
When you get past those features my opinions start to diverge. There is no product manager in the world that writes requirements and then specifies 'and must be reliable.' These are implicit. There is a strong analogy to the requirement of 'and must be secure.' Just as you wouldn't fault product management for quality issues in a feature release, you should not expect a product manager to specify 'and must validate input' or similar security basics.
So yes, product management should embrace the new reality of the market demand for security 'features' but past that there is still a responsibility for development to also embrace the new reality of secure development as well.