It depends…

Kristen and Tania describe what a PSIRT team is, Dell’s PSIRT team’s workflow, common challenges, and how PSIRT teams can work earlier in the SDLC with development teams to develop more secure applications.

Kristen Pascale, Principal Techn. Program Manager, Dell EMC linkedin
Tania Ward, Consultant Program Manager, Dell linkedin
abstract slides video

The #1 job of a product security incident response team (PSIRT) is to minimize incidents by managing vulnerabilities. They handle the initial receipt, triage, and internal coordination of vulnerablity reports, for example, from an external security researcher. This can be quite challenging, as Dell’s PSIRT team handles thousands of diverse products.

Vulnerability Report: Receive the report from a third-party researcher or other source and ensure it contains sufficient info. Route to the appropriate engineering team.Investigation: Impact Assessment: The relevant engineering team is responsible for determing if the issue is exploitable and its impact/riskRemediation Planning: A timeline for the fix is set and what needs to be done is decided.Tracking Remedy: Ensuring the vuln is fixed and documentation is created that will be used in the disclosure.Disclosure: Details of the issue, the fix, and the upgrade path for how customers should secure themselves is distributed to affected parties.

The speakers emphasize that disclosure is the most important part, as it gives customers what they need in order to secure their environment. And when customers reach out asking if they’re affected by a newly publicized issue, like Heartbleed, they want answers fast!


There are several fundamental challenges here:

  • The effectiveness of the PSIRT team’s response largely depends on several factors outside of their control. For example, they rely on engineers to do appropriate triaging of an issue to determine its impact and how it should be fixed.

  • If products don’t have an accurate, up-to-date bill of materials (BOM), then it can be a big endeavor to determine if they are effected by a newly disclosed vulnerability.

Another problem they run into is that they’re unable to deliver a timely fix because the upgrade path given by the affected provider or community isn’t compatible with their product - they’ve added features and functionality since they initially embedded the third-party component in the product and haven’t updated it in a long time. Now when they try to update it, things break. Similarly:

  • The component may be embedded in a way that the product requires a major architectural change to update it.

  • The supplier of the component is no longer supporting it. “This has happened a lot.”

This is where the shit hits the iceberg and the clock starts ticking.


Kristen and Tania make a few recommendations:

  • When you’re designing an application, ask yourself, “Have I architected this in a way where I’ll be able to effectively update it in the future?”

  • Consider having a central, managed location hosting third-party code that all projects pull from. This can be invaluable for tracking products’ BOMs and thus easily updating and diagnosing when they’re affected by vulnerabilities in the future.

    • If having an org-wide repository for third-party code is infeasible due to your org’s size, consider having one at a business unit or project level.

  • Have an owner, both org-wide as well as for each product, for the third-party components used. They are responsible for ensuring ownership and management of these dependencies from the start to sunset of the application.

  • Keep track of each product’s BOM using automated tooling. Keep up to date with vulnerabilities in that are released for each dependency as well as their current development state: have they not received a patch in several years? Are they being end-of-lifed?

  • Third party components are a part of your system - consider how they change the threat model / attack surface of the apps they’re included in.

  • The PSIRT and development teams need to work together so that everyone understands the downstream effects and total cost of ownership of the third-party dependencies being used.

See BoMs Away - Why Everyone Should Have a BoM for more details about automatically creating BOMs.

My Thoughts: Your Mileage May Vary
This recommendation of controlling what third-party dependencies developers can use woud be a tough sell in many companies I’ve spoken with, where speed and time to market/iterate are king. Security teams at these companies are responsible for supporting devs in building things securely, but can rarely be blockers or make changes that cause too much friction.