Product Security Framework
Product Security is a superset of application security, infrastructure security, and security operations around a particular product or system.
I was inspired to write this after reading lcamtuf’s fantastic blog post about common mistakes and success strategies in product security. Michal mentioned that there really isn’t a good framework for building a great product security organization. So, I thought I would write down what I’ve learned over my career of building and iterating on these strategies.
The first thing you may notice about this framework is that it’s not divided into the typical 7 steps you see in a program based on the security development life-cycle. This is because most engineering organizations don’t use the waterfall model anymore. Engineering is more iterative and thus, your product security strategies need to be as well. Almost all of the pieces of your product security program need to happen over several steps of the product life-cycle.
Team Organization
Your product security team needs to work closely with your engineering organization and the rest of your security team to be successful. Placing your team near these organizations is crucial. You want your product security team to go through the same on-boarding as your engineers so they can become familiar with the culture and process of your engineering organization and identify areas of improvement. You also want your product security team to have good relationships with the rest of the security team so that they can collaborate and ask for assistance.
Engineering Relationships
Creating and maintaining good relationships with the engineering organization helps prevent “shadow engineering” or applications and systems that bypass engineering guidelines and never get security review.
Depending on the size of the engineering and product security teams, your strategies may differ here. Have regular meetings with all engineering leaders to discover and discuss new projects, systems, or features being developed. For high-risk systems, try to embed someone from product security into that team’s development life-cycle, sit in on their scrum meetings, assist in design and code reviews, and help them write sensitive code and security libraries.
Security Relationships
Infrastructure teams and security operations need to be close partners of product security. Often in modern engineering organizations, infrastructure is constantly changing and is software-defined. When evaluating the architecture or deployment of a product or system, having assistance from infrastructure teams will make sure that continuous monitoring and testing has context of the applications on top of the infrastructure.
Product security will never be able to prevent or fix all software vulnerabilities, so you need your security operations center to help detect and monitor incidents as they occur. This means getting your incident response team familiar with the applications and letting them make recommendations for what events are logged and what data is logged with those events. Product security needs to work with incident response to make sure alerts are accurate and don’t create false positives that harm relationships with the engineering organization.
Team Size
As your organization grows, product security needs to grow. If you want to achieve 100% coverage of your engineering organization, I’ve found the ideal ratio is somewhere around one product security engineer to every twenty engineers. Of course, your risk appetite may allow for less coverage. For instance, you may not need to have full coverage over internal-facing tools or code that does not go into production, like test cases.
Product and Infrastructure Asset Management
You must have a catalog of applications or microservices and related assets (domains, databases, infrastructure, and more). Don’t forget to document all paths into and around the web application like admin panels, support panels, and any development access to data or code.
Ensure each application, microservice, infrastructure, datastore, etc. has an owner and an associated risk level based on organizations risk governance framework. You may also want to document access paths and controls around each asset, including links to documentation, tickets, and ongoing security projects and enhancements.
Architecture and Design Review
Catching security risks and flaws early saves time and effort (and money). Insert security review into your engineering organizations design process. If they write design documents, require someone from security sign off on those documents. If they have architecture/design meetings, require someone from security be present at those meetings. It’s also important to have buy-in here from engineering leaders here, to avoid engineers from skipping this step without consequences.
Don’t forget to identify and document the soft access paths in the design review as well. If engineering and SRE have access to production data, that needs to be documented and secured. If support has a back-end interface with less authorization requirements, that needs to documented and secured. If code in QA or development environments have access to production data, that needs to be documented and secured.
Manual Code Review
Your product security team cannot review every line of code, especially as it’s being written. The most important part of code review during the development process is prioritizing. Don’t read every commit. Use clues from file names and committers to know what to review. Even better if you can have engineers signal to your team what’s sensitive and needs review. Write guidelines for the engineering organization, tell them to flag authentication and authorization code, new endpoints and APIs, and anything they feel is sensitive.
Vulnerability Discovery
Build robust security testing into your engineering organization’s continuous integration and continuous deployment process. Whether you buy tools off-the-shelf or write your own analysis tools or use open source projects, you need to come up with a baseline of reasonable testing that all code goes through. Your baseline should include the types of attacks and techniques your attackers would use against your products. I recommend a mix of open source, commercial, and internal tools that span posture management, monitoring, static analysis, dynamic analysis, and instrumentation.
It’s important to prevent harm (broken builds and false positives) and delays (longer builds) to the engineering organization. Product security’s most important job is to maintain trust and respect with the engineering organization. It’s security’s responsibility to review and raise security issues, it’s not engineering’s responsibility to review the output of complex and potentially legacy security tools and make risk decisions.
Continuous Integration and Continuous Deployment
While usually an unlikely threat, it’s your product security team’s job to ensure that after code is written, it stays secure the entire way from an engineer’s endpoint to a production server. That is to say code is not manipulated in any way that may allow an adversary access to production data. Version control, build hosts, integration testing, and deployment pipelines are all in scope. This is how your product security team ensures that your organization is not a weak point in the software supply chain.
Start with the basics, include all your standard host security controls on these machines and collect the right telemetry to detect malicious behavior. Also make sure that build systems are regularly refreshed. Then focus on code integrity, design a way where you can prove that code on production matches version control. This is typically done with code signing or hashing and maintaining a provable chain of custody. Also, techniques like content addressable storage, immutable logs, and revoking root access from engineers are valuable here.
Secrets Management
Make sure secrets are properly stored and encrypted. Have strong access control around secrets (engineers do not need access to production secrets). Secrets must be regularly expired and rotated. Have robust audit logs so that access can be investigated in the future.
Third Party Libraries and Software Supply Chain
Third-party libraries have several interesting risks. Obviously, vulnerabilities can be introduced into libraries that can affect the security of first-party code, though this is rare. Licenses in third-party libraries can create legal risk. Malicious libraries may end up in your product via typo-squatting, private dependencies, and many other ways. Legitimate libraries can also be compromised and backdoored. Finally, legitimate libraries may take actions that violate data governance policy for your organization. This is how your product security team ensure that your organization is not a victim of a compromised software supply chain.
Your product security team may be responsible for all these risks. The best way to tackle them is to start with a catalog of your third-party libraries. Assess the risk for each of these outcomes with each library and monitor and assess the riskiest libraries. You can use common static analysis tools to uncover common backdoors in malicious dependencies. And you can utilize an internal dependency manager to ensure that only approved, genuine dependencies are used in development and in production.
Security Assessment
No matter how good your automatic testing is, it’s always good to take a step back and review an entire system manually. While this is most commonly referred to as a penetration test, I call this an out-of-band assessment since penetration test can refer to so many things. Your assessment can be done internally or by a third-party, but you have to consider scoping your organization or product like an attacker would. Understand the kinds of attackers that would be interested in your product and use their techniques and methods to test your product. If your customer support staff has back-end access and your attackers are known to use phishing attacks against support staff, then they should be in scope.
Vulnerability Management
More often than not, your team is going to discover more vulnerabilities that can be patched while engineering can still hit product milestones. It’s important for your product security team to advise the organization how to balance vulnerabilities against features, and not only advocates to fix vulnerabilities. If a complete fix for a vulnerability will take too much time, consider mitigating controls instead to reduce the risk.
Ultimately, it’s security’s job to help the organization balance the risk so the company doesn’t go under due to breach and still has enough resources to do the things that make them money. Your team needs to prioritize accurately and effectively to maximize the effort put forward in fixing security vulnerabilities.
Training and Documentation
Engineers should go through some sort of product security training once a year and when they join the organization. This training should cover everything engineers need to know about working with security, including when to submit design reviews, code reviews, and new third-party libraries for review. It should include secure engineering guidelines, advice from infrastructure security, and recommendations on what needs to be logged and how. Any common security libraries or anti-patterns should be documented for engineers to refer to without having to ask product security.
Security Champions
As your organizations grows, you’ll reach a point where product security can’t be part of every design review and code review or will be more effective working on strategic projects. At this point, you’ll need to delegate some security advisory tasks to engineers. Having engineers perform product-level threat models, architecture reviews, and code reviews can all be part of your security champions program. A strong security champions program will help give these engineers the resources and training they need to give advice to their engineering peers and make decisions like when to request additional security review.
Reading Group
In addition to or instead of a security champions program, a reading group can help cultivate a culture of security by having security representatives in all parts of the organization. I’ve found the best way to captivate your team of security evangelists is to teach them new things. Hold a reading group where you introduce new and relevant topics and research and where your security champions can report in on things happening in other parts of the organization.
Metrics
It’s probably obvious at this point that I am not a fan of quantitative metrics. I think they are misleading and easily manipulated in security. I much prefer qualitative metrics that can be backed up with logic and reason. That said, your program needs some quantitative way to track itself. Here are my favorite metrics:
Vulnerability Lifetime in Production — The measurement of this metric doesn’t start when a vulnerability is discovered, it starts when a vulnerability is introduced into production, at the time of deployment. This metric measures the effectiveness of your product security program. Ideally, you will have no vulnerabilities in production, but that’s impossible, so aim to have this metric trend downward as you build and iterate on your product security program.
Number of “Shadow Engineering” Projects Surfaced Per Quarter — I like this metric because it doesn’t matter how many shadow engineering projects exist or how many were missed, which may be impossible to determine. This metric is designed to let you describe how well your product security team is at working with the engineering organization. An increasing trend represents improved trust between product security and engineering. A decreasing trend is generally bad, but could also represent engineering following security guidelines with additional information.
This article is part of a series of security frameworks. See the other ones here:
