PSIRT: wat een product security incident response team doet

Wat is een PSIRT?

Een Product Security Incident Response Team (PSIRT) is de functie die beveiligingskwetsbaarheden afhandelt in de producten die een bedrijf maakt en verkoopt. FIRST definieert het als een entiteit die zich richt op het identificeren, beoordelen en afhandelen van de risico's van beveiligingskwetsbaarheden in de producten, waaronder aanbod, oplossingen, componenten en diensten.

In de praktijk doet een PSIRT het volgende:

• het beheert het kanaal waarlangs onderzoekers, klanten en partners kwetsbaarheden melden;
• het let op kwetsbaarheden in de componenten van derden en de open-sourcecomponenten in zijn producten;
• het trieert elke melding: klopt die, welke producten en versies zijn getroffen, hoe ernstig is het;
• het zorgt dat het verantwoordelijke engineeringteam het oplost, volgens een planning die bij het risico past;
• het publiceert advisories en coördineert de openbaarmaking met melders en downstream-leveranciers;
• het rapporteert metrics aan de leiding en traint de mensen die de producten bouwen.

Het meeste werk gebeurt na de release. FIRST merkt op dat de meeste productkwetsbaarheden als quality escapes worden gemeld zodra een product op de markt is, al voegt een PSIRT ook eerder waarde toe, bij ontwerpreviews en threat modeling.

Waar een PSIRT in de organisatie zit

Het verschil met andere beveiligingsteams is de focus op producten. Een enterprise-CSIRT beschermt de eigen systemen en netwerken van het bedrijf; een PSIRT beschermt de klanten die de producten van het bedrijf gebruiken. De twee delen vaardigheden en vaak een rapportagelijn, en ze komen elkaar tegen wanneer een incident in de eigen infrastructuur van het bedrijf, zoals een gecompromitteerd buildsysteem, een product bereikt. De volledige vergelijking staat in PSIRT vs CSIRT.

FIRST beschrijft drie operationele modellen:

• Gedistribueerd: een klein kern-PSIRT bepaalt het beleid en coördineert, en beveiligingsvertegenwoordigers in elk productteam doen de triage en de fixes. Dit schaalt over een grote, gevarieerde portfolio, maar de mensen die het werk doen, rapporteren niet aan het PSIRT.
• Gecentraliseerd: een groter PSIRT met eigen programmamanagement, triage- en herstelmedewerkers, dat rapporteert aan een senior executive voor productbeveiliging. Dit past bij kleinere bedrijven of een uniforme portfolio en kost meer naarmate de portfolio groeit.
• Hybride: een mix van beide, gekozen op basis van bedrijfsomvang, portfolio en ontwikkelstrategie.

Welk model het ook is, FIRST benadrukt onafhankelijkheid: het PSIRT moet rapporteren aan een executive die zijn gezag bevestigt, zodat het objectief stelling kan nemen over kwetsbaarheden in de eigen producten van het bedrijf.

Het FIRST PSIRT Services Framework

Het PSIRT Services Framework, gratis gepubliceerd door FIRST en inmiddels op versie 1.1, is de referentie waarop de meeste PSIRT's hun dienstencatalogus baseren. Het legt de operationele basis vast (mandaat, stakeholders, budget, beleid) en beschrijft daarna zes dienstengebieden:

Dienstengebied	Wat het omvat
1. Beheer van het stakeholderecosysteem	Interne stakeholders, de gemeenschap van melders, downstream-leveranciers en klanten, incidentcommunicatie, erkenning van melders, metrics over stakeholders
2. Ontdekken van kwetsbaarheden	Intake van kwetsbaarheidsmeldingen, vinden van niet-gemelde kwetsbaarheden, productcomponenten monitoren op kwetsbaarheden, nieuwe kwetsbaarheden identificeren, metrics over ontdekking
3. Triage en analyse van kwetsbaarheden	Meldingen kwalificeren, samenwerken met vaste melders, kwetsbaarheden reproduceren
4. Herstel	Releasebeheerplan voor oplossingen, herstel, incidentafhandeling, metrics over releases
5. Openbaarmaking van kwetsbaarheden	Melding, coördinatie, openbaarmaking via advisories, metrics over openbaarmaking
6. Training en opleiding	Training van het PSIRT, ontwikkel- en validatieteams en andere stakeholders; feedbackmechanismen

Eén dienst verdient aparte aandacht omdat die een groot deel van het werk is gaan uitmaken: het monitoren op kwetsbaarheden in productcomponenten. De eerste functie daarvan is een inventaris van productcomponenten, een lijst van de leveranciers, producten en versies in elk product, die volgens FIRST essentieel is om snel de getroffen producten voor overgeërfde kwetsbaarheden te identificeren. In moderne software is die inventaris een software bill of materials (SBOM).

Het PSIRT-proces in één oogopslag

Twee ISO/IEC-normen beschrijven het proces. ISO/IEC 30111:2019 behandelt hoe een leverancier intern met kwetsbaarheden omgaat. ISO/IEC 29147:2018 behandelt hoe hij meldingen van buitenaf ontvangt en informatie over herstel publiceert. 30111 is bedoeld om samen met 29147 te worden gebruikt, en de fasen daarin geven een nuttig overzicht:

1. Voorbereiding. Beleid, rollen, een gepubliceerde manier om kwetsbaarheden te melden, een scoringsmethode en een inventaris van wat wordt geleverd.
2. Ontvangst. Neem meldingen in ontvangst van onderzoekers, klanten, partners en uw eigen tests, en uit advisories voor componenten die u gebruikt. Bevestig de ontvangst aan de melder.
3. Verificatie. Bevestig de kwetsbaarheid, reproduceer die, geef een score en bepaal elk getroffen product en elke getroffen versie. Leg ook vast welke producten niet zijn getroffen, en waarom.
4. Ontwikkeling van herstel. Het verantwoordelijke team bouwt en test een fix of mitigatie. Het PSIRT volgt die aan de hand van de afgesproken tijdlijn.
5. Release. Lever de fix en publiceer de advisory, afgestemd met de melder en met downstream-leveranciers die uw product inbouwen.
6. Na de release. Let op problemen met de fix, beantwoord klanten en koppel hoofdoorzaken terug naar de ontwikkeling.

Elke fase, met wat u moet vastleggen en wie de eigenaar is, komt aan bod in de levenscyclus van kwetsbaarheidsbeheer. Zie prioritering van kwetsbaarheden om te bepalen welke bevindingen eerst komen, met signalen over misbruik uit EPSS en de CISA KEV-catalogus. Een kwetsbaarheid die wordt misbruikt voordat er een fix is, is een zero-day, en het PSIRT behandelt die als een incident. Hoe u van advisory naar een gerepareerde, geleverde build komt, staat in CVE-remediatie.

Openbaarmaking en advisories

Openbaarmaking is het deel van het PSIRT dat klanten zien. De gangbare praktijk is gecoördineerde openbaarmaking van kwetsbaarheden: de melder meldt vertrouwelijk, de leverancier repareert, en beide publiceren op een afgesproken datum, met vermelding van de melder. Het begint met een gepubliceerd beleid voor openbaarmaking van kwetsbaarheden dat aangeeft hoe u meldt, wat melders kunnen verwachten en hoe lang producten worden ondersteund. Zie gecoördineerde openbaarmaking van kwetsbaarheden.

Een goede advisory vertelt een klant, zonder telefoontje:

• welke producten en versies zijn getroffen, en welke niet;
• het CVE-ID en een ernstscore;
• de gerepareerde versie, of een mitigatie als er nog geen fix is;
• wie het heeft gevonden.

Grote klanten willen advisories steeds vaker in een machineleesbare vorm die ze automatisch met hun eigen inventaris kunnen vergelijken. CSAF is de OASIS-standaard voor advisories, en met VEX geeft u aan dat een product niet is getroffen door een kwetsbaarheid in een van zijn componenten, wat beide partijen een ticket bespaart.

PSIRT-metrics en volwassenheid

Het kader neemt metrics op in elk dienstengebied. Gangbare metrics:

• tijd tot de bevestiging van een melding, tot de triage en tot het uitbrengen van een fix, per ernst;
• open kwetsbaarheden per product, ernst en ouderdom;
• aandeel fixes dat binnen de gepubliceerde hersteldoelen is geleverd;
• kwetsbaarheden die intern zijn gevonden tegenover van buitenaf gemelde;
• gepubliceerde advisories en correcties op advisories.

Het bijbehorende PSIRT Maturity Document van FIRST deelt de diensten in drie niveaus in:

• Niveau 1, basis: sponsorschap van de directie, stakeholders, budget en beleid; een manier om meldingen te ontvangen; een triageworkflow; gedocumenteerde fixes; advisories die CVE en CVSS gebruiken en de melder vermelden.
• Niveau 2, gemiddeld: een charter en organisatiemodel, basismetrics, een productregister met een overzicht van afhankelijkheden, een formeel herstelplan, een systeem om stakeholders te informeren, en training voor het team.
• Niveau 3, gevorderd: rechtstreeks contact met de gemeenschap van melders, productcomponenten monitoren op kwetsbaarheden, metrics over ontdekking en releases, geavanceerde incidentafhandeling en playbooks voor coördinatie in de sector.

De beweging tussen de niveaus gaat van reactief naar proactief.

Een PSIRT opbouwen: begin klein

1. Regel een schriftelijk mandaat van een executive, met de bevoegdheid om productteams te vragen zaken op te lossen.
2. Publiceer hoe u een kwetsbaarheid meldt: een beveiligingscontactadres, een webformulier of een security.txt-bestand, en een kort beleid voor openbaarmaking.
3. Definieer triage en scoring: wie beslist of een melding geldig is, hoe de ernst wordt gescoord, en de hersteldoelen per ernst.
4. Weet wat u levert. Per productversie de componenten en versies erin. Zonder dit wordt elke nieuwe CVE in een populaire bibliotheek dagenlang rondvragen bij engineeringteams.
5. Wijs per product een eigenaar aan die bevindingen ontvangt en fixes inplant.
6. Schrijf een sjabloon voor advisories en publiceer de eerste, zelfs voor een klein probleem.
7. Meet vanaf het begin een paar tijdlijnen, zodat u verbetering kunt laten zien.

De pagina voor PSIRT-teams bekijkt de rol vanuit de leidinggevende voor productbeveiliging, en industriële leveranciers kunnen deze stappen koppelen aan IEC 62443-4-1, waarvan de eisen voor de levenscyclus van veilige ontwikkeling ook defectbeheer en patchbeheer omvatten.

Regelgeving die een PSIRT verwacht

Een PSIRT was vroeger een kenmerk van een volwassen leverancier. Diverse kaders vragen nu om wat het oplevert. NIS2 artikel 21, lid 2, onder e) noemt de afhandeling en openbaarmaking van kwetsbaarheden bij de maatregelen die essentiële en belangrijke entiteiten moeten nemen. In de VS vereist section 524B dat fabrikanten van medische hulpmiddelen een plan indienen om kwetsbaarheden na de marktintroductie te monitoren, te identificeren en aan te pakken, inclusief gecoördineerde openbaarmaking van kwetsbaarheden, samen met een SBOM. En de EU Cyber Resilience Act verplicht fabrikanten om actief misbruikte kwetsbaarheden en ernstige incidenten aan de autoriteiten te melden, te beginnen met een vroegtijdige waarschuwing binnen 24 uur; zie wat is de CRA.

De tools die een PSIRT nodig heeft

Behoefte	Waarom
Intake van meldingen en dossierbeheer	Elke melding krijgt een eigenaar, een status en een tijdlijn
Inventaris van wat wordt geleverd	Een nauwkeurige SBOM per productversie, inclusief transitieve afhankelijkheden
Continue monitoring	Nieuwe CVE's gematcht met de componenten in elke uitgebrachte versie, niet alleen de volgende
Triage en routering	Bevindingen gaan naar het team dat verantwoordelijk is voor de fix, met de context om te handelen
Verklaringen over wel of niet getroffen	VEX legt vast welke producten een kwetsbaarheid raakt en waarom de andere niet zijn getroffen
Publiceren van advisories	Voor mensen leesbare advisories, en machineleesbare CSAF voor grote klanten

Weinig producten dekken elke rij; PSIRT-tools vergeleken laat zien welke tool wat doet. De inventaris is waar de meeste PSIRT's moeite mee hebben. Een scanner die achteraf lockfiles leest, vermeldt ontwikkelafhankelijkheden die nooit worden geleverd en mist pakketten die de build buiten de pakketbeheerder om heeft gedownload, dus het antwoord op "zijn we getroffen?" begint met twijfel.

CRACI haalt die inventaris uit de build zelf. Het draait GitHub Actions-builds op zijn eigen runners en legt de pakketten vast die elke job werkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit CI-caches zijn teruggezet en afhankelijkheden die in geen enkele lockfile staan. Elke SBOM heeft een volledigheidsstatus en wordt geëxporteerd als CycloneDX of SPDX. Gemonitorde SBOM's worden continu opnieuw beoordeeld zodra er nieuwe kwetsbaarheden worden gepubliceerd, de buildgeschiedenis toont welke eerdere builds een kwetsbare afhankelijkheid bevatten, en de inventarisweergave toont welke softwareversies in welke producten zijn uitgerold. Securityteams triëren bevindingen en sturen ze naar de teams die verantwoordelijk zijn voor de fix, en CRACI ondersteunt VEX. Zie kwetsbaarheden volgen en CRACI voor PSIRT-teams.

PSIRT: veelgestelde vragen

Waar staat PSIRT voor?

PSIRT staat voor Product Security Incident Response Team. FIRST definieert het als een entiteit binnen een organisatie die zich richt op het identificeren, beoordelen en afhandelen van de risico's van beveiligingskwetsbaarheden in de producten, het aanbod, de oplossingen, componenten en diensten die de organisatie maakt of verkoopt.

Wat is het verschil tussen een PSIRT en een CSIRT?

Een PSIRT handelt kwetsbaarheden af in de producten die een bedrijf aan klanten levert. Een enterprise-CSIRT handelt beveiligingsincidenten af in de eigen systemen en netwerken van het bedrijf. De twee werken samen, bijvoorbeeld wanneer een inbreuk op de buildinfrastructuur een product raakt. Zie PSIRT vs CSIRT.

Wat is het FIRST PSIRT Services Framework?

Een gratis gids van FIRST, het Forum of Incident Response and Security Teams, die de diensten opsomt die een PSIRT kan leveren. Versie 1.1 groepeert ze in zes dienstengebieden: beheer van het stakeholderecosysteem, ontdekken van kwetsbaarheden, triage en analyse van kwetsbaarheden, herstel, openbaarmaking van kwetsbaarheden, en training en opleiding. Een bijbehorend volwassenheidsdocument deelt de diensten in drie niveaus in.

Welke normen beschrijven het PSIRT-proces?

ISO/IEC 30111:2019 behandelt hoe een leverancier kwetsbaarheidsmeldingen intern afhandelt, van voorbereiding en ontvangst via verificatie en ontwikkeling van herstel tot release en de fase na de release. ISO/IEC 29147:2018 behandelt het contact met de buitenwereld: meldingen ontvangen en informatie over herstel publiceren. 30111 is bedoeld om samen met 29147 te worden gebruikt. IEC 62443-4-1 stelt eisen aan de levenscyclus van veilige ontwikkeling, inclusief defect- en patchbeheer, voor producten voor industriële automatisering.

Heeft een klein bedrijf een PSIRT nodig?

Het heeft de functie nodig, niet per se een afdeling. Het volwassenheidsdocument van FIRST begint met sponsorschap van de directie, benoemde stakeholders, een budget, een paar beleidsdocumenten, een gepubliceerde manier om kwetsbaarheden te melden, een triageworkflow, gedocumenteerde fixes en advisories die de melder vermelden. Een of twee mensen met een schriftelijk mandaat kunnen dat doen.

Welke tools heeft een PSIRT nodig?

Minimaal: een manier om meldingen te ontvangen, een dossiersysteem, een scoringsmethode voor kwetsbaarheden, een inventaris van welke componenten in welke productversies worden geleverd, monitoring van die componenten op nieuwe kwetsbaarheden, een manier om vast te leggen of elk product is getroffen (vaak als VEX), en een manier om advisories te publiceren, steeds vaker in CSAF.