This is Part 1 of our blog series about building a Product Security Incident Response Team from the ground up. Watch this webinar to dive deeper into this topic.
——
The Colonial Pipeline cyber security breach in 2021 marked a watershed moment in IT security. Though this attack shut down the largest oil pipeline in
the U.S. and resulted in a $4.4 million ransom payment, it most likely made headlines simply because it represents in shocking clarity the most disturbing cyber security trend of recent years: Attacks on operational technology (OT) have now gone mainstream.
Other recent attacks underscore this conclusion, including the Oldsmar water purification plant breach and an attack against JBS SA, the world’s largest meat processor, that led to an $11M ransom payment. Every industry, from hospitals and medical devices to automotive and industrial machinery, has seen a rise in attacks targeting non-traditional endpoints. No longer content to hack email or web servers, attackers are going after “real-world” devices that control production lines, vehicles, medical devices, and more. And these attacks could have particularly devastating and immediate real-world consequences.
The primary challenge facing leaders in device manufacturing companies today is that the expansion in operational technology, intelligent devices, and IoT has been absolutely essential from a business standpoint, but could be devastating from a cybersecurity perspective, if not managed properly.
For any company looking to stay relevant, there’s no question of not adapting to the times and integrating today’s wide range of connected devices and processes.
But as business leaders have started to realize, all this connectivity has also broadened their attack surface, creating the need for an integrated, cohesive security approach.
Any vulnerability in a connected product or device can potentially be exploited to make it perform unpredictably, opening up a nearly infinite range of potential repercussions when it comes to safety—along with massive monetary losses and damage to your reputation. Many companies—particularly small- and medium-sized businesses—never recover from a cyber attack.
It’s up to you to ensure that your company can grow and adapt, harnessing the best of today’s technology and connectivity while creating a hardened, resilient security posture that ensures you won’t be the next company to show up in the headlines.
In this article, we’ll look at the product security incident response team (PSIRT), which brings stakeholders together to establish a unified, hardened posture that intelligently anticipates risks and ensures resilience if the worst does happen.
Today, if you’re manufacturing software-driven devices, regardless of your industry, you need a PSIRT. To help you get up and running efficiently, we’ll explore popular models for setting up a PSIRT, then look at three crucial elements you need in place to drive its success.
The Need for a PSIRT
In most cases, following a cyber attack, businesses fail because they lack a coordinated, unified response to threats and breaches. Instead, there are ad hoc processes that fail to come together at critical times, leaving major aspects of security to fall through the cracks.
But a growing number of companies—across industries including automotive, medical, energy, manufacturing, and many more—are being proactive and facing the growing risk by creating an integrated PSIRT.
Establishing a PSIRT recognizes a key reality for most larger companies today: Many components are shared across products. Coupled with the growing demand for standards and regulatory compliance, this fact means that security can no longer be a siloed activity, separated by department.
The most recent PSIRT Services Framework, created by the FIRST community, provides several models for creating a PSIRT within your business, with the goal of ensuring seamless product security that’s tightly integrated with the rest of the company’s operations. This framework suggests three primary models: distributed, centralized, and hybrid. The main difference between the three models has to do with where the PSIRT is drawn from and the hierarchy of who they report to.
Distributed PSIRT
Representatives of teams across your organization (engineering, support, management) serve together within the PSIRT and report to team leaders.
- Pros: Best for organizations with a wide range of products, can easily scale the PSIRT as needed, costs distributed across the organization
- Cons: Less control over individual departments, so staff lack accountability to the PSIRT
Centralized PSIRT
A larger team of PSIRT staff are distributed among multiple departments across the organization (engineering, support, management) and report to security executives.
- Pros: Best for organizations with a few, homogeneous products; collects experts and creates tighter accountability
- Cons: Does not scale as well as distributed model, cannot adapt easily to expanding product range, makes the PSIRT a new cost center
Hybrid PSIRT
Considered the “best of both worlds,” this PSIRT has the flexibility to fit multiple organization types and sizes, along with varied product ranges. This will generally make use of a smaller team, as in the distributed model, but likely retains accountability to senior executives to create a focused, “the buck stops here” approach.
The hybrid approach will look different for every organization.
- Pros: Adapts readily to the size and scale of your organization
- Cons: May lack clear coordination and hierarchy unless care is taken during planning phases
Key Components of Your PSIRT
Regardless of the model you choose, there are a few essential common elements that drive the success of your PSIRT. Every single PSIRT relies on the right combination of people, processes, and technology, which we will explore in the following sections.
People
One of the first steps in setting up a PSIRT is creating a staffing plan, which identifies the skill sets needed and competencies expected when selecting individuals for the team. If existing staff don’t possess the necessary skills and competencies, the staffing plan should also determine whether these will be met through outsourcing, vendor support services, or up-skilling existing team members with appropriate, role-based training. According to FIRST, all team members should have at least “a solid understanding of basic security concepts and knowledge of the products that are being supported.”
At the very least, you’ll want to create the following roles within your PSIRT:
- PSIRT manager: A central head or managing executive to whom the rest of the team reports, the manager’s primary responsibility is to oversee the operations of the PSIRT initiative. This includes the creation of policies, processes, procedures, and guidelines for the team’s operations. The PSIRT manager also represents the PSIRT within the organization and ensures ongoing buy-in from management—critical for making the PSIRT a priority in the budget—and internal stakeholders.
- PSIRT analysts: These are the people who handle the analysis and remediation of security vulnerabilities. Analysts have to continually monitor a variety of sources for vulnerabilities, attack techniques, and potential threats that may pose a risk to the company’s products; they also work with product teams to pinpoint and remediate vulnerabilities. See the Process section below for details.
- Security points of contact: There should be points of contact designated in each of the organization’s product or business lines who take responsibility for addressing all security issues in their domain, including risk quantification, analysis, and remediation across all affected product versions.
- Legal point of contact: The role of the legal POC is to ensure that there is no violation of IP or liability issues due to incidents, SLAs with customers, etc., along with any other regulatory concerns arising from PSIRT operations.
- Communications contact: This team member must be skilled in crisis communications for on-message and ongoing incident response. This can be a high-pressure role—for instance, handling media inquiries during the investigation of a breach for which answers are not yet readily available, along with rebuilding the brand and reputation following the incident.
In Part 2 of this blog, we will cover the processes and technology needed to build a PSIRT.
