PSIRT: vad ett Product Security Incident Response Team gör

Vad är ett PSIRT?

Ett Product Security Incident Response Team (PSIRT) är funktionen som hanterar säkerhetssårbarheter i de produkter som ett företag tillverkar och säljer. FIRST definierar det som en enhet som fokuserar på ”the identification, assessment and disposition of the risks associated with security vulnerabilities within the products”, inklusive erbjudanden, lösningar, komponenter och tjänster.

I praktiken gör ett PSIRT följande:

• driver kanalen där forskare, kunder och partner rapporterar sårbarheter;
• bevakar sårbarheter i tredjeparts- och open source-komponenterna i sina produkter;
• triagerar varje rapport: är den verklig, vilka produkter och versioner påverkas, hur allvarlig är den;
• får det ansvariga utvecklingsteamet att åtgärda den, enligt en tidsplan som motsvarar risken;
• publicerar säkerhetsmeddelanden och samordnar offentliggörandet med rapportörer och nedströmsleverantörer;
• rapporterar mätvärden till ledningen och utbildar dem som bygger produkterna.

Det mesta av arbetet sker efter release. FIRST konstaterar att de flesta produktsårbarheter rapporteras som kvalitetsmissar när en produkt väl finns på marknaden, även om ett PSIRT också tillför värde tidigare, i designgranskningar och hotmodellering.

Var ett PSIRT hör hemma i organisationen

Skillnaden mot andra säkerhetsteam är fokuset på produkter. Ett CSIRT på företagsnivå skyddar företagets egna system och nätverk; ett PSIRT skyddar kunderna som kör företagets produkter. De två delar kompetens och ofta rapporteringsväg, och de möts när en incident i företagets egen infrastruktur, till exempel ett komprometterat byggsystem, når en produkt. Hela jämförelsen finns i PSIRT vs CSIRT.

FIRST beskriver tre driftsmodeller:

• Distribuerad: ett litet centralt PSIRT sätter policy och samordnar, och säkerhetsrepresentanter i varje produktteam sköter triage och åtgärder. Modellen skalar över en stor och varierad portfölj, men de som gör arbetet rapporterar inte till PSIRT.
• Centraliserad: ett större PSIRT med egen programledning och egen personal för triage och åtgärder, som rapporterar till en högre chef för produktsäkerhet. Modellen passar mindre företag eller en enhetlig portfölj och kostar mer när portföljen växer.
• Hybrid: en blandning av de två, vald utifrån företagets storlek, portfölj och utvecklingsstrategi.

Oavsett modell betonar FIRST oberoende: PSIRT bör rapportera till en chef som bekräftar dess befogenheter, så att det kan ta objektiv ställning till sårbarheter i företagets egna produkter.

FIRST PSIRT Services Framework

PSIRT Services Framework, som FIRST publicerar gratis och som nu är i version 1.1, är referensen som de flesta PSIRT bygger sin tjänstekatalog på. Det anger operativa grunder (mandat, intressenter, budget, policyer) och därefter sex tjänsteområden:

Tjänsteområde	Vad det omfattar
1. Hantering av intressenter	Interna intressenter, rapportörsgemenskapen, nedströmsleverantörer och kunder, incidentkommunikation, erkännande av rapportörer, mätvärden för intressenter
2. Upptäckt av sårbarheter	Mottagning av sårbarhetsrapporter, upptäckt av orapporterade sårbarheter, bevakning av produktkomponenter för sårbarheter, identifiering av nya sårbarheter, mätvärden för upptäckt
3. Triage och analys av sårbarheter	Kvalificering av rapporter, samarbete med etablerade rapportörer, återskapande av sårbarheter
4. Åtgärd	Plan för hantering av åtgärdsreleaser, åtgärd, incidenthantering, mätvärden för releaser
5. Offentliggörande av sårbarheter	Avisering, samordning, offentliggörande genom säkerhetsmeddelanden, mätvärden för offentliggörande
6. Utbildning	Utbildning av PSIRT, utvecklings- och valideringsteam och andra intressenter; mekanismer för återkoppling

En tjänst är värd att lyfta fram eftersom den har blivit en stor del av arbetet: bevakning av sårbarheter i produktkomponenter. Dess första funktion är en inventering av produktkomponenter, en lista över de leverantörer, produkter och versioner som ingår i varje produkt, som FIRST kallar ”essential to quickly identify affected products for inherited vulnerabilities”. I modern programvara är den inventeringen en software bill of materials (SBOM).

PSIRT-processen i korthet

Två ISO/IEC-standarder beskriver processen. ISO/IEC 30111:2019 täcker hur en leverantör hanterar sårbarheter internt. ISO/IEC 29147:2018 täcker hur den tar emot rapporter utifrån och publicerar information om åtgärder. 30111 är tänkt att användas tillsammans med 29147, och faserna den beskriver ger en användbar översikt:

1. Förberedelse. Policy, roller, ett publicerat sätt att rapportera sårbarheter, en poängsättningsmetod och en inventering av det som levereras.
2. Mottagning. Ta emot rapporter från forskare, kunder, partner och dina egna tester, och från säkerhetsmeddelanden för komponenter du använder. Bekräfta mottagandet till rapportören.
3. Verifiering. Bekräfta sårbarheten, återskapa den, poängsätt den och fastställ alla berörda produkter och versioner. Registrera också produkter som inte påverkas, och varför.
4. Utveckling av åtgärd. Det ansvariga teamet bygger och testar en rättning eller en mitigering. PSIRT följer upp den mot den överenskomna tidsplanen.
5. Release. Leverera rättningen och publicera säkerhetsmeddelandet, samordnat med rapportören och med nedströmsleverantörer som bygger in din produkt.
6. Efter release. Håll utkik efter problem med rättningen, svara kunderna och för tillbaka grundorsakerna till utvecklingen.

Varje steg, med vad som ska registreras och vem som äger det, tas upp i livscykeln för sårbarhetshantering. För att avgöra vilka fynd som kommer först, se prioritering av sårbarheter, med utnyttjandesignaler från EPSS och CISA KEV-katalogen. En sårbarhet som utnyttjas innan en rättning finns är en zero-day, och PSIRT hanterar den som en incident. Vägen från säkerhetsmeddelande till ett åtgärdat, levererat bygge tas upp i CVE-åtgärder.

Offentliggörande och säkerhetsmeddelanden

Offentliggörandet är den del av PSIRT som kunderna ser. Den vanliga metoden är samordnat offentliggörande av sårbarheter: rapportören rapporterar privat, leverantören åtgärdar, och båda publicerar på ett överenskommet datum, där rapportören får erkännande. Det börjar med en offentlig policy för offentliggörande av sårbarheter som anger hur du rapporterar, vad rapportörer kan förvänta sig och hur länge produkter stöds. Se samordnat offentliggörande av sårbarheter.

Ett bra säkerhetsmeddelande talar om för en kund, utan ett telefonsamtal:

• vilka produkter och versioner som påverkas, och vilka som inte gör det;
• CVE-id och en allvarlighetspoäng;
• den åtgärdade versionen, eller en mitigering om det ännu inte finns någon rättning;
• vem som hittade den.

Stora kunder vill allt oftare ha säkerhetsmeddelanden i ett maskinläsbart format som de automatiskt kan matcha mot sin egen tillgångsinventering. CSAF är OASIS standardformat för säkerhetsmeddelanden, och VEX är sättet att ange att en produkt inte påverkas av en sårbarhet i en av dess komponenter, vilket sparar ett ärende på båda sidor.

Mätvärden och mognad för PSIRT

Ramverket lägger mätvärden i varje tjänsteområde. Vanliga mätvärden:

• tid för att bekräfta en rapport, triagera den och släppa en rättning, per allvarlighetsgrad;
• öppna sårbarheter per produkt, allvarlighetsgrad och ålder;
• andel rättningar som levererats inom de åtgärdsmål du har publicerat;
• sårbarheter som hittats internt jämfört med sådana som rapporterats utifrån;
• publicerade säkerhetsmeddelanden och korrigeringar av dem.

FIRST:s kompletterande PSIRT Maturity Document delar in tjänsterna i tre nivåer:

• Nivå 1, grundläggande: stöd från ledningen, intressenter, budget och policyer; ett sätt att ta emot rapporter; ett arbetsflöde för triage; dokumenterade rättningar; säkerhetsmeddelanden som använder CVE och CVSS och ger rapportören erkännande.
• Nivå 2, medelnivå: en stadga och en organisationsmodell, grundläggande mätvärden, ett produktregister med kartläggning av beroenden, en formell åtgärdsplan, ett system för att avisera intressenter och utbildning för teamet.
• Nivå 3, avancerad: direkt samarbete med rapportörsgemenskapen, bevakning av produktkomponenter för sårbarheter, mätvärden för upptäckt och release, avancerad incidenthantering och handlingsplaner för samordning inom branschen.

Rörelsen mellan nivåerna går från reaktivt till proaktivt.

Så bygger du ett PSIRT: börja i liten skala

1. Skaffa ett skriftligt mandat från en chef, med befogenhet att be produktteam åtgärda saker.
2. Publicera hur en sårbarhet ska rapporteras: en kontaktadress för säkerhetsfrågor, ett webbformulär eller en security.txt-fil, och en kort policy för offentliggörande.
3. Definiera triage och poängsättning: vem som avgör om en rapport är giltig, hur allvarlighetsgrad poängsätts och åtgärdsmålen per allvarlighetsgrad.
4. Vet vad du levererar. För varje produktversion: komponenterna och versionerna i den. Utan detta blir varje ny CVE i ett populärt bibliotek dagar av frågor till utvecklingsteamen.
5. Utse en ägare per produkt som tar emot fynd och planerar in rättningar.
6. Skriv en mall för säkerhetsmeddelanden och publicera det första, även för ett litet problem.
7. Mät några ledtider från början, så att du kan visa förbättringar.

Sidan om PSIRT-team ser på rollen ur produktsäkerhetsansvarigas perspektiv, och industriella leverantörer kan koppla de här stegen till IEC 62443-4-1, vars krav på en säker utvecklingslivscykel omfattar defekthantering och patchhantering.

Regelverk som förutsätter ett PSIRT

Ett PSIRT brukade vara ett tecken på en mogen leverantör. Flera ramverk kräver nu det som ett PSIRT levererar. NIS2 artikel 21.2 e listar hantering och offentliggörande av sårbarheter bland de åtgärder som väsentliga och viktiga entiteter måste vidta. I USA kräver avsnitt 524B att tillverkare av medicintekniska produkter lämnar in en plan för att övervaka, identifiera och åtgärda sårbarheter efter lansering, inklusive samordnat offentliggörande av sårbarheter, tillsammans med en SBOM. Och EU:s Cyber Resilience Act kräver att tillverkare rapporterar aktivt utnyttjade sårbarheter och allvarliga incidenter till myndigheter, med början i en tidig varning inom 24 timmar; se vad är CRA.

Verktygen ett PSIRT behöver

Behov	Varför
Mottagning av rapporter och ärendespårning	Varje rapport får en ägare, en status och en tidsplan
Inventering av det som levereras	En korrekt SBOM per produktversion, inklusive transitiva beroenden
Löpande bevakning	Nya CVE:er matchas mot komponenterna i varje släppt version, inte bara nästa
Triage och routning	Fynd går till teamet som äger åtgärden, med sammanhanget som krävs för att agera
Uttalanden om påverkade och opåverkade produkter	VEX registrerar vilka produkter en sårbarhet påverkar och varför de andra inte påverkas
Publicering av säkerhetsmeddelanden	Säkerhetsmeddelanden för människor, och maskinläsbar CSAF för stora kunder

Få produkter täcker varje rad; PSIRT-verktyg i jämförelse visar vilket verktyg som gör vad. Det är inventeringen som de flesta PSIRT har svårast med. En skanner som läser lockfiler i efterhand listar utvecklingsberoenden som aldrig levereras och missar paket som bygget laddade ner utanför pakethanteraren, så svaret på frågan ”är vi berörda?” börjar med tvivel.

CRACI hämtar den inventeringen från själva bygget. Det kör GitHub Actions-byggen på sina egna runners och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, paket som återställs från CI-cachar och beroenden som ingen lockfile listar. Varje SBOM har en fullständighetsstatus och exporteras som CycloneDX eller SPDX. Bevakade SBOM:er omvärderas löpande när nya sårbarheter publiceras, bygghistoriken visar vilka tidigare byggen som innehöll ett sårbart beroende, och inventarievyn visar vilka programvaruversioner som är driftsatta i vilka produkter. Säkerhetsteam triagerar fynd och skickar dem till teamen som äger åtgärden, och CRACI har stöd för VEX. Se sårbarhetsuppföljning och CRACI för PSIRT-team.

PSIRT: vanliga frågor

Vad står PSIRT för?

PSIRT står för Product Security Incident Response Team. FIRST definierar det som en enhet inom en organisation som fokuserar på att identifiera, bedöma och hantera riskerna med säkerhetssårbarheter i de produkter, erbjudanden, lösningar, komponenter och tjänster som organisationen tar fram eller säljer.

Vad är skillnaden mellan ett PSIRT och ett CSIRT?

Ett PSIRT hanterar sårbarheter i de produkter som ett företag levererar till kunder. Ett CSIRT på företagsnivå hanterar säkerhetsincidenter i företagets egna system och nätverk. De två arbetar tillsammans, till exempel när ett intrång i bygginfrastrukturen påverkar en produkt. Se PSIRT vs CSIRT.

Vad är FIRST PSIRT Services Framework?

En kostnadsfri guide från FIRST, Forum of Incident Response and Security Teams, som listar de tjänster ett PSIRT kan erbjuda. Version 1.1 grupperar dem i sex tjänsteområden: hantering av intressenter, upptäckt av sårbarheter, triage och analys av sårbarheter, åtgärd, offentliggörande av sårbarheter samt utbildning. Ett kompletterande mognadsdokument delar in tjänsterna i tre nivåer.

Vilka standarder beskriver PSIRT-processen?

ISO/IEC 30111:2019 täcker hur en leverantör hanterar sårbarhetsrapporter internt, från förberedelse och mottagning via verifiering, utveckling av åtgärd och release till tiden efter release. ISO/IEC 29147:2018 täcker gränssnittet mot omvärlden: att ta emot rapporter och publicera information om åtgärder. 30111 är avsedd att användas tillsammans med 29147. IEC 62443-4-1 ställer krav på en säker utvecklingslivscykel, inklusive defekt- och patchhantering, för produkter inom industriell automation.

Behöver ett litet företag ett PSIRT?

Det behöver funktionen, inte nödvändigtvis en avdelning. FIRST:s mognadsdokument börjar med stöd från ledningen, namngivna intressenter, en budget, några policyer, ett publicerat sätt att rapportera sårbarheter, ett arbetsflöde för triage, dokumenterade rättningar och säkerhetsmeddelanden som ger rapportören erkännande. En eller två personer med ett skriftligt mandat kan sköta det.

Vilka verktyg behöver ett PSIRT?

Som minimum: ett sätt att ta emot rapporter, ett ärendesystem, en metod för att poängsätta sårbarheter, en inventering av vilka komponenter som levereras i vilka produktversioner, bevakning av de komponenterna för nya sårbarheter, ett sätt att registrera om varje produkt påverkas (ofta som VEX) och ett sätt att publicera säkerhetsmeddelanden, allt oftare i CSAF.