This is Part 2 of our blog series about building a Product Security Incident Response Team from the ground up. Continuing from where we left off in Part 1, in this post we will cover the enabling processes and technologies of a PSIRT. Watch this webinar to dive deeper into this topic.
——
Processes
To ensure that operations run smoothly when a security event arises, the team must define key policies and procedures ahead of time. Many of these activities must be established during the “peacetime” prior to an incident, so that positive practices will already be in place if and when a threat occurs.
When an attack does occur or a vulnerability is discovered, which has become an unfortunate inevitability, it’s critical that automation, contextualization, and mitigation/ remediation processes are already in place. Considering these prior to an event will save time and help PSIRT teams to secure an organizations assets in a moment’s notice.
Maintaining a Central Repository
As part of the peacetime routine, the PSIRT should create and maintain a central repository of all products and software. Without contextualized insight of the full supply chain, a given product or asset may comprise dozens of components from a number of different suppliers, with each supplier developing the underlying software on various platforms and hardware architectures. Hence, listing all software components, versions, and configurations is no small task.
The PSIRT needs to upload the resulting software inventory or SBOM (software bill of materials) to the central repository and keep it up-to-date with every new product version or update. You can then manage this data using a dedicated asset management tool (see the Technology section below), ensuring the team has continuous real-time access to security data for all your latest product versions, as well as their distribution to customers.
Identifying and Involving Stakeholders
The PSIRT must also identify the various stakeholders with whom the team may need to interact when a security event arises. These can include parties inside a company, such as leadership and development teams, as well as outside entities, including component providers, developers, and customers.
The team needs to establish processes and mechanisms to facilitate the sharing of information with each of these stakeholders (e.g., a vulnerability disclosure framework). This will include creating incident response (IR) playbooks defining procedures both for attack conditions and peacetime training.
Actively Monitoring Threats
The third type of PSIRT process revolves around the collection of threat intelligence, including data on product vulnerabilities, vulnerable third-party components (e.g., TCP/IP stacks), and architectural weaknesses. Your PSIRT should spread a wide net, actively checking channels such as exploit databases, news outlets, technical blogs, and social media for relevant news, as well as subscribing to relevant vendor advisories and security mailing lists for open-source projects.
The team should also maintain a vulnerability disclosure program and advertise contact points to facilitate submissions by interested parties. Your threat monitoring process needs to include deliberately establishing and engaging with an active ecosystem of partners, peers, and researchers (or “finders”) with relevant security expertise to share threat intelligence.
A PSIRT should also invest in actively hunting for new attack techniques and potential threats. During peacetime, this can mean creating guidelines, including recommendations or best practices that are passed along to product security and development teams, or even holding workshops on relevant topics. This will help establish and facilitate routine product security assessments within the framework of the entire secure software development lifecycle (SDLC).
Organizations that foster secure development lifecycle practices—and invest in building them—will require fewer resources to remediate security flaws by catching them earlier in the development process.
Screening, Analyzing, and Remediating Incidents
Last but by no means least, the PSIRT must define a process for responding to cybersecurity incidents. While the aim of establishing a PSIRT is that these incidents will ideally be less threatening and have fewer repercussions for the organization as a whole, it is obviously still essential to have these processes in place.
The process of incident analysis will vary depending on the organization: Companies that receive a high volume of vulnerability reports may need to screen and validate each report before creating a ticket or case. The identified risk(s) can then be prioritized and communicated to the relevant team. Defining the exact policies and mechanisms for this process ahead of time ensures maximum efficiency when it’s crunch time.
The PSIRT needs to have predefined processes and mechanisms in place for risk analysis and remediation, including root cause analysis across all affected products and versions, as well as delivery of a patch or other remedy to all relevant stakeholders. The incident post-mortem process should also address the need for ongoing education and awareness among the product development, engineering, and management teams.
Technology
Once the right people and processes are in place for your PSIRT, you can begin to identify and evaluate technologies that can support them. But beware, this stage demands caution.
While a rise in awareness across multiple industries is a great starting point, this has resulted in a number of vendors providing individual tools that promise to solve one piece of the technology puzzle. Yet you need to be very careful about adopting a piecemeal approach to security. Not all the components you select may integrate with one another, and you may find that you’re paying too much for overlapping security tools.
Instead, look for a single platform that incorporates the comprehensive, security-first needs of your PSIRT, throughout the entire product lifecycle. This is really the best way to protect your customers—and your business.
Technologies you need to support your PSIRT team and save time includes:
- Asset management. Creating, analyzing, and maintaining an up-to-date inventory of all products released to market and their detailed bill of materials (SBOM), along with versioning, licenses, OS configurations, and more, is not as simple as you might think. Supply chain complexity means you also need to be aware of third-party and open-source components. You can’t track and fix risks you can’t see.
- Threat intelligence and contextualization. Software threat management is a constantly shifting tide pool of new and evolving weaknesses, CVEs, zero-days, exploits, and attack techniques. Don’t get sucked in- they don’t mean much if there is no context.
A modern PSIRT platform will provide continuous monitoring and aggregation of vulnerability and threat feeds such as the NVD, VulnDB, Exploit Database, and Metasploit. - Impact-based incident response. As so many companies have discovered, threat intelligence is worse than useless without a deep understanding of which threats are most relevant to your business, resulting in a flood of alerts that can distract your team from its core mission—or, worse, go ignored and unresolved. An automated PSIRT platform can provide relevancy checks across all your assets. This gives you the context you need to focus on threats that truly impact your products and improve your team’s focus, reducing the time and effort needed for forensic analysis and incident resolution.
- Digital twinning. With digital twinning, you can scan and pinpoint potential vulnerabilities and other issues using an exact blueprint copy of your system and all its components, including the OS, encryption, control flows, and API calls. This lets you reproduce attacks and test overall resilience with zero risk to your organization and your customers.
- Workflow automation. Any PSIRT platform must integrate into the way your company works. By creating and routing tickets for new security incidents, as well as tracking each issue to its resolution, you ensure that nothing falls through the cracks. Tickets should be meaningful—including a full impact assessment on components and devices—with clear guidance to resolve threats and policy violations.
- Reporting. By providing data and metrics around PSIRT performance, such as time to resolution (TTR), your team can demonstrate ROI from day one, proving its value in reducing the number and impact of security incidents. This business outcome data in turn helps stakeholders understand the essential role of the PSIRT and provide for an ongoing allocation of budget and other resources.
Shifting Gears: Toward the PSIRT Future
Establishing a PSIRT can help your organization shift gears from being in reactive mode to leveraging a well-oiled, proactive security posture. Once you have the right people, processes, and resources in place, your PSIRT will ideally function not as an isolated module within your organization, but instead operate in lockstep with the product, engineering, and support teams, driving best practices across all departments.
Naturally, all three elements—people, processes, and resources—are essential to success. However, when it comes to resources, there are many possible pitfalls. With an integrated PSIRT platform, you can ensure that you avoid any problems you could encounter trying to adopt a variety of products from multiple vendors.
Across a range of industries, including automotive, medical, and industrial, Cybellum’s platform empowers device manufacturers and their suppliers to identify and remediate security risks at scale, throughout the entire product life cycle.
Cybellum will help you leverage industry-leading tools and processes to quickly resolve product security incidents. Get your PSIRT program up to speed fast with best practices and insights from Cybellum’s PSIRT experts.
