What is a Product Security Incident Response Team (PSIRT)?

The Computer Security Incident Response Team (CSIRT) is a longstanding fixture of information security departments. The CSIRT, a team of experts from different areas of an organization, responds to security incidents, such as data breaches. In recent years, makers of technology products have developed their own internal version of the CSIRT, known as Product Security Incident Response Team (PSIRT), which responds to vulnerabilities in the company’s own products. PSIRTs have come into existence as tech companies recognize how their products often play a role in their customers’ security incidents—and seek to avoid such incidents or minimize their impact.

y

What is a PSIRT?

A PSIRT is typically a group of employees, sometimes supplemented by contractors and consultants, who focus on identifying, assessing, and remediating security vulnerabilities in the company’s products. For example, the PSIRT at a maker of server software might discover that their firmware contains code that hackers can exploit to take over the server. To fix this vulnerability, the PSIRT will analyze the vulnerability, find a secure replacement for the code in question, and provide it to engineering teams.

In organizational terms, the PSIRT is usually situated inside the company’s secure engineering organization. This approach helps ensure that the PSIRT’s functions contribute to the company’s Secure Development Lifecycle (SDL). The PSIRT may also participate in gathering requirements and modeling risk, with the goal of building security into the product.

Why is a PSIRT important?

Business leaders and product managers consider PSIRTs to be important for a range of reasons. At a minimum, an effective PSIRT helps ensure greater product quality and fewer security patching updates. These outcomes not only keep costs down, they also help the brand by avoiding the appearance of being lax about a product’s security.

A more significant issue is the increasing awareness that individual technology products can be major sources of risk exposure for customers. The maker of an IoT device, for instance, would likely not want their device to be the cause of a customer’s data breach. An incident of this kind can be embarrassing and expensive to deal with, especially if the device maker is unprepared and left scrambling to find a solution after the breach has occurred. If the device maker has a PSIRT, it could either avoid the risk entirely or at least be ready to react to the problem immediately and effectively.

Components of a PSIRT

As its name states, a PSIRT is a team, so its most important components are people. PSIRT team members must be knowledgeable and experienced in different aspects of cybersecurity. Some might be experts in application security. Others might have experience with open-source security, and so forth. In a large company, the PSIRT might be a dedicated, full-time team. In a smaller organization, the PSIRT might comprise a small core team of full-time employees, augmented by people who work elsewhere in the organization, but who are available to help with incident response or vulnerability analysis as needed.

The PSIRT manager is a person of great importance in the success of the PSIRT. He or she must be, in addition to being a good manager, skilled in creating policies, processes, and procedures that enable the PSIRT to do its job. He or she needs to be a good communicator and adept at handling the potentially complicated organizational dynamics that surround product security.

Further to that point, the PSIRT team will have connections with other departments, such as Legal and Compliance. Manufacturers of avionics, for example, are subject to FAA regulations concerning disclosures of vulnerabilities in their products. The PSIRT will likely be a key player in this area of compliance. The PSIRT will also have a contact in the company’s communications group, e.g., with the public relations team regarding public disclosures of security problems or statements about security incidents at client firms.

How does a PSIRT work?

A well-run PSIRT will operate based on established policies and procedures. Like a CSIRT, a PSIRT will always try to reproduce vulnerabilities in a secure environment. Then, based on the perceived seriousness of the vulnerability and estimates of its impact on the product, the PSIRT may choose to inform management. If management decides to disclose the vulnerability, the PSIRT will collaborate with relevant stakeholders in the announcement process.

The team will then determine a way to mitigate the vulnerability and initiate a remediation process. This will involve creating a remediation plan in partnership with product management teams, who are responsible for the product in-market.

In some cases, the company learns about a vulnerability from a third party. When this occurs, the PSIRT needs to evaluate the vulnerability and make recommendations on how to respond. For example, if a device uses a certain version of the Linux Operating System, and a bug hunting team finds an exploit in that version of Linux, the PSIRT has to come up with a plan for handling the exploit and communicating about it with customers.

PSIRT vs CSIRT

While the CSIRT and PSIRT have similar structures and operating processes, their respective focuses are entirely different. The CSIRT’s job is to help keep the company secure, working to defend its networks, applications, and data from malicious actors. The PSIRT, in contrast, is all about keeping the company’s products secure.

Best practices for building an effective PSIRT

Best practices for building an effective PSIRT are emerging across technology companies. Some relate to staffing and organizational structure. It may be a best practice, for example, to avoid staffing the PSIRT as a standalone team, but rather build the team by distributing its members across different groups, such as quality assurance (QA), security operations, and software development.

A PSIRT needs budget and suitable tooling to do its job. It’s not a good idea to assume that the PSIRT will manage with whatever technology everyone else is using. A PSIRT needs the IT resources to create isolated test environments, for instance. It will need to procure specialized equipment in many cases.

Educating stakeholders is a best practice for PSIRTs as well. Not all employees and managers have an intuitive grasp of product security. The best outcomes result from people being knowledgeable and “bought in” to the PSIRT’s mission. Training workshops are a natural outgrowth of another best practice, which is the documentation of the PSIRT’s policies and processes.

Other relevant best practices include:

• Report to external groups—working with outside entities that track vulnerabilities that affect your product. This may mean dealing with people who like to break things and find hidden problems in a product. It may not be a lot of fun, but it’s a great way to find flaws that affect security.
• Automate intelligence sharing—automatically making other groups in the company aware of vulnerabilities as they get discovered. These stakeholders may have ideas on remediation and other helpful information to share.
• Pay attention to public sources of vulnerability and threat data—subscribing to Information Sharing and Analysis Centers (ISACs) as well as repositories like GitHub.

Conclusion

A PSIRT is an important element of a company’s SDL efforts. It helps keep products secure, which makes it possible to avoid serious security incidents arising from vulnerabilities. If there is an incident, a PSIRT enables a rapid, effective response. Getting a PSIRT to work means thinking through staffing and organizational challenges. No two companies will have the same PSIRT structure and organizational connections. Best practices recommend working across the organization, as well as with external entities. As these elements come together, the PSIRT emerges as a powerful factor in greater product security.