A product security incident response team (PSIRT) identifies, evaluates and coordinates responses to the security vulnerabilities and incidents in the products an organization develops and/or manufactures. A traditional cybersecurity incident response team (CSIRT) protects the organization’s infrastructure, and the PSIRT maintains the products themselves. Although the core focus of each team is different, there are many similarities in establishing and running these capabilities and teams. This piece explains how to create a best-practice PSIRT tailored to your organization.
Create a PSIRT Charter: Get Executive Buy-In
Establishing a PSIRT is similar to setting up a traditional CSIRT. First, and very importantly, senior leadership must support this and have the support codified in a PSIRT charter.
This charter should detail:
- PSIRT scope and services to be provided (e.g., which products are supported)
- Roles and responsibilities, including operating model
- Stakeholders, such as business units, customer groups and the legal team
In addition, an operating budget must be established with adequate resources provided to address the charter scope.
How to Choose a PSIRT Model
There are three standard operating models for PSIRTs, each of which has its own pros and cons. The one you choose will depend on the capabilities and resources of your specific organization and environment (see Figure 1).
Best Practices for Setting up a PSIR
The time commitment required for setting up a PSIRT depends very much on:
- The complexity of the organization’s product line: This can be mitigated by a distributed model that draws on existing resources, but it still requires a small team to establish the policies and procedures for all teams to follow.
- The current maturity of vulnerability management capabilities within the organization: If the CSIRT (or equivalent) has a documented set of processes for vulnerability and patch management, the PSIRT can use these and tailor them to product security. If these capabilities do not exist, it will take time to establish the processes and to define, collect, analyze and refine the metrics to know if the PSIRT is operating effectively. For example, the team must establish criteria for rating product vulnerabilities to determine if they are critical, high, medium or low impact. This will have a significant impact on the product teams, and there most likely will be some iterations before the criteria are finalized.
- The educational needs of stakeholders: Organizations should focus their educational efforts in three areas:
- Internal PSIRT: This is essential. The internal PSIRT team must understand the product team development lifecycle to provide updates and fixes in an appropriate way that fits seamlessly into the existing processes. The PSIRT team can also work with the product team to make improvements to the development lifecycle as necessary, but this should be done as a collaboration.
- The product team: This team must be educated on the criteria and criticality of vulnerabilities and how these will impact product development. Depending on the model selected, the product team will either develop the security fixes themselves or test and implement the fixes provided by the PSIRT.
- External stakeholders: This group includes customers, third parties, the general public, etc., and must be educated on how and where to report vulnerabilities. An effective way to do this is to have a link for reporting on the organization website. All responses to external reports should be coordinated or even provided by the organization’s legal team.
Download: Create Incident Response Metrics Worth Reporting
The PSIRT should also establish multiple ways to identify security issues. These should include:
- Establishing reporting capabilities for external parties to submit potential security vulnerabilities to the PSIRT.
- Joining an information sharing group, such as an Information Security and Analysis Center for the organization’s industry.
- Monitoring public sources, the news and information from threat intelligence agencies.
The Forum of Incident Response and Security Teams (FIRST) provides extensive guidance and a services framework for establishing a PSIRT
Establish PSIRT Maturity in Phases
Many tools are available to support PSIRT operations. However, it is important for organizations to take the time to first establish policies, procedures and operations as a way to guide tool selection.
For example, the PSIRT will want tools to do vulnerability scanning and perform patch management or insert fixes into the existing development process. Prior to scanning, though, the organization must have a comprehensive asset management capability. This applies to product security, just as it does with computer security. The product team must maintain and provide to the PSIRT a detailed security bill of materials and asset list.
Many open source tools are available for PSIRT teams to obtain vulnerability information on products (e.g., Cisco’s PSIRT OpenVuln API). PSIRT teams can grow in maturity by automating and orchestrating vulnerability discovery and reporting. This can be implemented with a multitude of security orchestration, automation and response (SOAR) tools.
Overall, PSIRTs should create a business requirements document to select tools based on existing IT requirements, security requirements and desired functionality.
Stand Up a Strong PSIRT
A basic PSIRT capability can be stood up with relative speed if the organization already has documented asset management, vulnerability management and patch management capabilities in place. The policies and procedures used in those disciplines can be used and tailored for the product line(s). To ensure success:
- Choose the right PSIRT model for your environment: Selecting a distributed, centralized or hybrid model determines how the PSIRT will operate within the existing organizational structure.
- Spend time on communication and training: The PSIRT will only be successful if communication and education of internal and external stakeholders is performed early and continuously.
- Take a phased approach: Beware of trying to do too much at once. Design for automation and orchestration as a goal, but it is more important to get the charter, policies and procedures correct than it is to jump into tooling. FIRST also provides helpful resources.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.