Your organization’s computer security incident response team (CSIRT) plays a crucial role in coordinating the incident response process for security events that affect the company’s infrastructure, data or users. But to whom do you turn in case of incidents or vulnerabilities related to the products you build?

A product security incident response team (PSIRT) identifies, evaluates and coordinates responses to the security vulnerabilities in the products you manufacture. Whereas the CSIRT protects the infrastructure on which the organizations rely, the PSIRT maintains the products manufactured by those organizations to generate revenue. Although the core focus of each team is different, there are many similarities.

No ‘SIRT’ Is an Island

Like CSIRTs, a PSIRT is not an island in your company; it does not operate independently of other parts of the organization. Obviously, the way it is embedded within the organization depends on the maturity, size and objective of the team — and, of course, the resources available. The most common embedding models are very similar to typical CSIRT structures.

On the one hand, there is a distributed model wherein you involve members of existing departments, such as subject matter experts from the engineering and IT teams. On the other hand, in the centralized model, the PSIRT has its own staffing.

The distributed model works very well for scaling the team, and you can make use of the existing knowledge of experts experienced in your organization. It can be a challenge, though, to maintain oversight, and there may sometimes be a clash of responsibilities or duties. The centralized model works well for clear, nonredundant structuring, but scaling, especially in environments with a large set of products, can become very difficult.

The best of both worlds, then, is the hybrid model, in which a small team is in control, but productive relationships are built with experts across departments.

Assemble the Team

When building a PSIRT, you should first develop a charter describing how the team will operate and what services it will provide. The charter should include the roles and responsibilities, operating model and products that are in scope (similar to a constituency description). Additional guidance on setting up a services framework for a PSIRT is provided by the Forum for Incident Response Teams (FIRST).

Obviously, you need staffing and a dedicated budget to sustain long-term operations. The funding model can include “selling” services to other internal teams: Your PSIRT can deliver vulnerability assessment or code testing that you might otherwise outsource to an external partner.

Besides the budget, you also need adequate tooling to conduct your work. Especially for teams starting with a distributed model, care must be taken that team members make use of the PSIRT tooling and not rely solely on their departments’ kits. Failing to do so can introduce the risk that not all team members have access to the same knowledge.

Educate Stakeholders

Identify your stakeholders, build a relationship with them and make sure there’s support. Consider their needs and requirements when defining the charter or policies, and tailor your communication to them; not every stakeholder will expect the same types of messaging.

Document your policies, processes and procedures, and organize workshops within the organization to make them known. Deploying the team requirements without getting all the other affected teams on board would be a big mistake. It is critical to educate everyone in the organization on product security and their roles within that objective.

This will include internal stakeholders such as those in engineering, legal, communication, sales and customer support. Reach out to external stakeholders as well, including your national or sectorial CSIRT. Get involved in an information sharing and analysis center (ISAC) and build communication channels with consumer organizations and regulatory bodies.

A critical element of engagement is in the Secure Development Lifecycle (SDL). Ensure that your PSIRT participates in the SDL activities and governance process for a full picture of each version of each product before they go live.

Once you’ve identified all your stakeholders, define the metrics you will use for reporting. These metrics will most likely depend on the priorities of those to whom you report.

How to Discover Vulnerabilities

There are a few methods available to discover vulnerabilities, but there’s one that requires special attention: reports from external researchers, bug bounties or concerned users.

Enable External Reporting

External researchers and vigilant users that report vulnerabilities are also essential to your product security processes.

External reports are valuable for multiple reasons. For starters, the reporters have often looked at your product differently than your engineering department. Products get used in an unusual fashion or are broken down into different pieces, or a feature is used — or abused, as the case may be — in a way for which it was not designed.

Additionally, the reports are a good starting place for community building and can kick-start a search for other similar cases.

Engage With Other Teams

The CSIRTs, PSIRTs and partners collaborating in an ISAC make up another great source of external reports. To facilitate a swift exchange with these teams, you can set up automated intelligence sharing — for example, via the Industry Consortium for Advancement of Security on the Internet Common Vulnerability Reporting Framework (ICASI CVRF).

Monitor Public Sources

There are many public sources that can contain direct or indirect information on vulnerabilities in your products. Public sources include GitHub or Exploit Database, but even Twitter and various discussion and support boards can have valuable insights.

Monitoring all these sources can be challenging, but there are tools available to streamline the task. You can use marketing tools that track conversations about your products. You can use the Analysis Information Leak (AIL) framework, or tools that scan Twitter posts for keywords, such as TweetSniff.

Consider also scanning security conference programs or academic papers for new emerging trends or attack methodologies that might affect your products.

Learn the PSIRT Basics

The basic operating model also shares similarities with CSIRTs:

• Reproduce the vulnerabilities in a secure environment.
• Depending on the priority and impact, you might have to inform management.
• Restrict access to the reproduction or proof-of-concept exploit codes during analysis, and store them on a separate network.

After analyzing vulnerabilities, it’s time to mitigate and remediate:

• Define mitigation measures based on the analysis.
• Build a remediation plan based on supported versions of the product, such as patching or workarounds.
• Submit the suggested remediation to the QA and engineering teams for validation.
• If the issue was reported by a third party, you should inform them of the steps taken before going public. This type of transparency will increase the level of trust a reporter has in your organization and can help streamline future reporting.
• The remediation should also include a risk analysis and determination of how to most easily achieve delivery. Parts of the risk analysis can be disclosed to your customers.
• Strategize your client-facing actions. Tap the sales team, customer support, comms and possibly the legal team.
• The disclosed information should include clear actions for your customers and methods by which they can verify themselves that a remediation was successful. The EU Agency for Network and Information Security (ENISA)’s “Writing Security Advisories” guidelines can assist you in this process.

Never waste a good vulnerability. Reuse the incident information as training and educational material for the engineering teams to prevent similar incidents in the future. A PSIRT’s operations should feed into recursive security checks and practices to continuously scale product security with organizational growth and an ever-evolving threat environment.