There is a decades old principle in managing any project called the “Triple Constraint” or sometimes “The Iron Triangle.”
It states that any project involves trade-offs between three constraints:
- Time: project schedule
- Cost: available resources in terms of people and budget)
- Scope: volume and comprehensiveness of features, functions, operational performance
Sometimes “Quality” is added as an outcome of the trade-offs of these constraints, meaning sacrificing too much across them will result in lower quality output.
This same model is sometimes applied to product management (Figure 1).
Figure 1: The Triple Constraint (sometimes called “The Iron Triangle”)
And if you are product manager, then you know the drill: Typically at least one of the constraints is fixed and can’t be varied.
That means you need to adjust the other two factors in your plan and product roadmap.
So, for example, say that an aggressive launch deadline for your product is set in stone. You may need to explore raising the project budget (cost) or reducing the feature-set (scope) — or do some of both — to hit the deadline.
Those are the classic product management trade-offs involved in bringing any product to market or maintaining and enhancing one after release.
When the Triple Constraint concept was invented, however, the person who devised it probably had no idea that it would have such a massive impact on one of today’s critical areas: product security.
The Security Challenge for Product Management
Expending time and resources on improving product security is often a tough sell. After all, time spent on security matters is less time available for enhancing features and functionality that really sells a product.
The exception of course is when a particular type of security function, like encrypting application data or strong user authentication, is needed for the product to meet a basic customer requirement, a particular certification or so on.
Then, that particular aspect of security is taken as a given, is planned as part of the product functional scope, and baked into the product development process just like any other feature.
But compliance with a single minimal requirement doesn’t mean the product is secure overall.
And that’s where the constraints of product management can force security trade-offs.
The Open Source Accelerator
Time-to-market pressures are leading companies to use commonly available open source components for many of their baseline product functioning.
It’s smart strategy. Why reinvent the wheel? Just grab a pre-built component, integrate it, and then spend your time and resources building out new features and functions that truly differentiate your offering. You bring a more differentiated product to market faster.
But how do you ensure these components are not affected by a vulnerability today, or in a few weeks or months from now?
There are strong arguments that open source software is actually more secure in general than proprietary software, because the crowd effect of the open source community brings constant scrutiny by many eyeballs on security issues.
But still the fact remains that your product is composed of a large number of components that you did not build and may not be comprehensively maintaining or enhancing on your own.
And the continuing flood of new vulnerabilities means that a component affected by no vulnerabilities on release might be hit by one or more in a week.
So how do you ensure such a component — and your product — is secure today and stays secure tomorrow?
The Security Trade-Off
Maintaining product security once a product is released and in production can take a backseat to managing the stream of enhancements, bug fixes, updates and new versions in the pipeline.
There are hundreds of new vulnerabilities reported every week, such as the Common Vulnerabilities & Exposures reported by the National Institute of Standards and Technology.
Given all the other demands, there just isn’t enough time to manually sift through these vulnerabilities, analyze their impact on your product, figure out the right mitigation, and execute the fix.
The bottom line is that security will often take a backseat. Product feature enhancements, product performance, bug fixes and other areas will take priority when time and budget restraints force trade-offs.
So the Triple Constraint means that many hundreds of products with less than adequate security are deployed in production in today’s massively heightened cybersecurity threat environment.
That puts customers at risk and exposes product makers to liability if they sell nonsecure products.
In Part 2 of these postings, we’ll explore best practices for a product security process that cuts the security trade-off. We’ll examine and give examples of four steps in an effective process that helps product managers bring more secure products to market and keep them secure throughout the product lifecycle.
About Timesys
Timesys has extensive experience with embedded system development and lifecycle management. Timesys has been instrumental in working with global leader semiconductor manufacturers with smart, quick and quality solutions for highly complex systems with accelerated product innovation and multiple product variants.
