It depends…

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.

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!

Challenges

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.”

Recommendations

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.