Vulnerability Disclosure Programs (VDP) and PSIRT's
Cornerstones of being a responsible software supplier
We’ve spoken quite a bit about industry frameworks such as NIST’s Secure Software Development Framework (SSDF) in other blog entries, so it makes sense to cite it as an example here as well when discussing vulnerability disclosure and response for software suppliers.
As discussed, SSDF calls for organizations to implement sound practices to help aid secure software development. It lays out the practices across four groups, which are Preparing the Organization, Protecting Software, Producing Well-Secured Software and Responding to Vulnerabilities. One key theme across these four groups is the ability for organizations and suppliers to both disclose and respond to vulnerabilities that impact their consumers.
This is emphasized in areas such as having policies in place that address vulnerability disclosure and remediation activities. Having these policies and processes in place produces several key benefits for software suppliers, such as being able to inform researchers about their vulnerability management practices and report potential vulnerabilities they may discover to the supplier.
As anyone who has been in cybersecurity or software development long enough knows, it isn’t a matter of if vulnerabilities will emerge, but when. Therefore, it is key for organizations to have codified security response processes and mature capabilities when it comes to disclosing vulnerabilities to software consumers.
This traditionally has occurred through static notification measures such as websites, emails and PDF documentation. However, the industry is now moving towards automated machine-readable notification advisories.
This is most prominently showing up through avenues such as the Common Security Advisory Framework (CSAF) and the Vulnerability Exploitability eXchange (VEX), which is considered by many to be an accompanying document to SBOM’s that will show the actual exploitability of vulnerabilities associated with software and products from suppliers.
CSAF aims to allow stakeholders to automate the creation and consumption of security vulnerability information and is striving to support VEX, although at the time of this writing, that capability is still maturing. CSAF has been championed recently by organizations such as CISA in their article “Transforming the Vulnerability Management Landscape”.
Another notable example is CycloneDX, the industry leading SBOM format we have discussed, which also has something they refer to as a “Bill of Vulnerabilities” which allow the sharing of vulnerability data between systems and sources of vulnerability intelligence.
The emergence of methods and standards such as CSAF and VEX show a continued industry momentum to shift form the traditional static vulnerability advisory and notification processes to one of machine-readability and automation, which allows the process to be more efficient, less error prone and ultimately more scalable as well.
Having standardized a Vulnerability Disclosure Program (VDP) in place is a sign of maturity from software suppliers and builds trust with consumers while empowering them to be aware of ongoing vulnerabilities and incidents as well as take remedial action to address vulnerabilities associated with the products in their environment before they can be exploited by a malicious actor.
It is also becoming a requirement in some industries, such as the U.S. Federal sector, which as we discuss elsewhere, is requiring third-party software providers working with the Federal government to self-attest to aligning with SSDF practices, such as the existence of a VDP in their 22-18 memo issued by the Office of Management and Budget (OMB).
Having a VDP program in place that is both responsive to security researchers and communicates openly and effectively with consumers builds consumer trust and also helps mitigate risk to suppliers that may come in the form of financial ramifications such as regulatory consequences for poor practices or reputational harm.
While you may find yourself in the position of being a software supplier, the inevitable reality is that you are also likely a software consumer or utilize third parties to some extent when it comes to providing your software and products to your own downstream consumers.
This means you need to take steps to understand your own supply chain and the security measures that your suppliers take. This may come in the form of attestations and vetting software components you utilize from third parties in your software. If it is a proprietary supplier, you can utilize contractual measures to enforce a level of rigor that your organization or downstream consumers require.
If the components instead are provided using OSS, you need to implement OSS governance as recommended by groups such as NIST in their 800-161 and software supply chain guidance.
Failing to do so inevitably creates risk for your downstream consumers and potentially business challenges as savvy consumers will inevitably push back on insecure software passed on to them either through seeking to understand your secure software development practices or asking for artifacts such as SBOM’s that can expose risk and vulnerable components embedded in your products or applications.
Product Security Incident Response Team (PSIRT)
Another key recommendation, tied to both SSDF and industry best practice around being a product and software supplier is implementing a Product Security Incident Response Team (PSIRT).
A PSIRT is like a Cybersecurity Incident Response Team (CSIRT) however instead of being inward facing and focused on the organizations infrastructure and systems, a PSIRT is product-focused and concerns with vulnerabilities and threats to an organizations product. PSIRT makes an appearance is the NIST SSDF, in the Respond to Vulnerabilities (RV) group and is listed as an implementation example that allows organizations to handle responses to vulnerability reports and incidents and handle communication among the organization's stakeholders, which may be internal and external.
Whether you’re looking to stand up a new PSIRT team or assess the maturity of an existing one to identify gaps for improvement, one great resource to do so is the PSIRT Maturity Document from FIRST, the same organization that leads CVSS and EPSS.
FIRST’s PSIRT Maturity Document provides 3 maturity levels for PSIRT teams to benchmark against, going from Basic, Intermediate and Proactive levels of maturity. Let’s take a brief look at each maturity level to understand the associated capabilities per level.
Source: https://www.first.org/standards/frameworks/psirts/psirt_maturity_document
Before diving into the levels of a PSIRT, one of the most foundational steps is creating a PSIRT charter which captures the PSIRT’s Mission Statement, Stakeholders, Affiliation/Sponsoring Organization and Scope.
At the Basic level a PSIRT is likely just being established and trying to get to a baseline level of functionality. This requires things such as executive sponsorship, stakeholder identification, budget and baseline policies procedures. This means the PSIRT needs to have the support of the organizations leadership, have identified who the stakeholders are both internal and external, have a budget for initial staffing and establishment and create policies and processes to codify how the PSIRT will functional fundamentally.
Example policies and processes FIRST’s document provide include a Vulnerability Management, Information Handling and Remediation Service Level Agreements. Beyond that, the PSIRT needs some basic capabilities to meet its intent. This includes the ability to intake vulnerability reports, which involves publishing contact information and how to go about reporting vulnerabilities to the organizations PSIRT.
Receiving vulnerability reports is just the first step though, going beyond that, PSIRTs need the ability to triage and analyze vulnerability reports. This involves key steps such as qualification of vulnerability reports, meaning is this even a valid vulnerability? Should it be accepted or rejected? FIRST recommends PSIRTs capture key vulnerability information and adopt machine-readable formats to aid efficiency and scale. Resources they cite include the Common Vulnerability Reporting Framework (CVRF), CSAF, which we’ve previously discussed and the Common Vulnerability Enumeration (CVE) program, the last of which ultimately is supported by NIST’s National Vulnerability Database (NVD) and enables vulnerability communication to consumers, often through the support of vulnerability scanning tools which integrate and query the NVD for vulnerability data such as CVE’s.
Once the PSIRT has qualified a vulnerability as valid and accepted, they need to move on to Vulnerability Analysis, which involves understanding how the flaw and vulnerability works, how it can be exploited and what versions of their products, services are impacted by the vulnerability and what the ramifications of exploitation generically can be, since this will vary depending on the environment and mitigating controls that may or may not exist, which is often left to consumers to determine due to their inherent knowledge of their operating environment.
During analysis PSIRTs will often perform prioritization and scoring. FIRSTs documentation of course recommends the use of CVSS, which is logical given their relationship with CVSS, but as we have discussed elsewhere CVSS also has several strong critiques from academia and industry alike. Despite those criticisms, CVSS experiences broad adoption in the industry and if a PSIRT chose another scoring methodology, as FIRST notes, they will likely need to explain the decision to consumers who are often familiar with CVSS already.
Now that a vulnerability has been qualified, and analyzed the supplier needs to do the business of remediating the vulnerability. This may involve activities such as a code fix and product patch or guidance for consumers to mitigate the risk of a vulnerability, or theoretically choosing not to fix the vulnerability whatsoever, based on a cost benefit analysis by the PSIRT and their peers among the supplier firm.
Lastly, in the Basic level of maturity of the step of Vulnerability Disclosure, which involves notifying the consumers of the product or service of the vulnerability. This notification is ideally accompanied by guidance on how to remediate the vulnerability or mitigate it if a code fix or resolution doesn’t exist. FIRST also recommends crediting the security researcher or entity responsible for notifying the supplier of the vulnerability to begin with. It provides attribution to the reporting party and builds trust among the community.
Moving beyond the basic and foundational level of maturity, a PSIRT would then advance to Maturity Level 2 or Intermediate. This is where the PSIRT starts to provide more comprehensive services, engage with more stakeholders both internal and external to the organization and mature existing fundamental capabilities.
As FIRST mentioned, PSIRTs at the immediate level have a clear understanding of their stakeholders, establish processes and can optimize their analysis and response to vulnerabilities. Intermediate level PSIRTs are also able to utilize tooling to improve their vulnerability intake and processing capabilities. FIRST recommends that PSIRTs at the Intermediate level begin understanding the components that go into a released product, capturing this data in a Product Manifest or Bill of Materials, often called an SBOM if the product is software centric.
The possession of the BOM not only helps with software component visibility and vulnerability management for communication to consumers downstream but it also enables the organization to understand what third-parties they may need to engage with, such as OSS projects.
FIRST’s guidance points out that more mature PSIRTs have clear roles and responsibilities for understanding where each stakeholder fits into the vulnerability triage and analysis activities and has begun to build rapport with the security researchers who may be reporting vulnerabilities or flaws to the PSIRT. This rapport is built by having functional processes and tools such as ticketing systems in place to facilitate the vulnerability reporting process.
In addition to the use of CVSS and severity scoring PSIRT’s often mature to use the Common Weakness Enumeration (CWE) labeling for vulnerabilities. We’ve covered CWE elsewhere in the text, but it is a system managed by MITRE that allows for a community-developed list of software and hardware weakness types to allow for quick labeling and categorization of vulnerabilities.
Intermediate PSIRTs are also able to lean on previous vulnerability remediation activities to avoid starting from scratch each time and have codified processes to aid in vulnerability remediation activities and subsequently vulnerability disclosure as well. This means improving how the PSIRT works with various parties as part of disclosure and FIRST recommends the use of their Multi-Party Coordination and Disclosure Guidelines to facilitate a mature approach to vulnerability disclosure. (https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.0)
Part of this disclosure maturity will involve standardized avenues for disclosure, metric tracking and iterative process improvement as the disclosure activities go on. FIRST also points out that there may be cases where the PSIRT decides to provide customer notification prior to the actual public disclosure. This makes sense given once the information is public, it isn’t just defenders who are watching but also malicious actors who inevitably will look to exploit the vulnerability prior to consumers remediating the flaws.
Finally, the PSIRT ideally progresses to Maturity Level 3, also known as Advanced.
One quick look at the diagram above points out that the PSIRT has now built a robust portfolio of services and capabilities as well as advancing on foundational capabilities. This infers that the process of vulnerability reporting ingestion, analysis, and the subsequent delivery of security updates for the products the PSIRT is responsible for is understood across the organization and its stakeholders.
One of the biggest differentiators for Advanced PSIRTs from others is the shift from a reactive culture to a proactive one. This means actively looking out for vulnerabilities or flaws in products, over-communicating to stakeholders and being engaged and working cohesively with product engineering teams.
Much of the truth of being advanced means excellent execution of the fundamentals. This includes strong relationships with stakeholders to provide and receive feedback to optimize the function and performance of the PSIRT. This active improvement process is tied to tangible metrics and Key Productivity Indicators (KPI)’s. Examples include customer satisfaction and Service Level Objectives and Agreements (SLA/SLO)’s.
Keeping with the theme of DevSecOps, first mentions that another hallmark of advanced PSIRT’s is tight integration and relationships with the Development team to understand the product roadmap and upcoming features and releases. The PSIRT also will have optimized their tooling to handle vulnerability intake, analysis and reporting processes. The PSIRT also has actively influenced the software development lifecycle of the organizations products and services to ensure that vulnerability analysis and scanning is a standardized activity embedded into the development workflow and lifecycle.
Given that a PSIRT is constantly engaging with security researchers, often with the same one more than once, they begin to understand the proficiency and validity of the vulnerability reports from the research community and can prioritize reporting and escalations based on this knowledge. Advanced PSIRTs can embody the “shift-left” mantra of the industry by getting engineering teams to take feedback early in the product development lifecycle. This includes not just the identification of vulnerabilities but also prioritization and remediation activities.
It is also crucial that the PSIRT understands the ecosystem they operate in, not just downstream to consumers but upstream to their own providers. This awareness is accompanied by clear and actionable communication and expectations in each direction of the software supply chain.
Lastly, given PSIRT’s proficiency in dealing with vulnerabilities and product flaws, the PSIRT can begin to teach others. This could manifest in internal training and communication on product security and vulnerability management practices to not only optimize the PSIRT’s performance but also the performance of the development and product teams they support.
This improves not just the product and PSIRT’s operations but also ideally leads to more secure products for downstream consumers, which is the goal at the end of the day.
At the end of the day, being a software supplier comes with some fundamental levels of responsibility. This includes having a functional team dedicated to ingesting, analyzing and communicating information to downstream consumers as it relates to vulnerabilities or flaws in your products and offerings. The PSIRT is poised perfect to carry out this activity, but it requires executive support and investment from the organization.