PSIRT: hvad et product security incident response team gør

Hvad er et PSIRT?

Et Product Security Incident Response Team (PSIRT) er den funktion, der håndterer sikkerhedssårbarheder i de produkter, en virksomhed fremstiller og sælger. FIRST definerer det som en enhed, der fokuserer på "the identification, assessment and disposition of the risks associated with security vulnerabilities within the products", herunder tilbud, løsninger, komponenter og tjenester.

I praksis gør et PSIRT følgende:

• driver den kanal, som forskere, kunder og partnere rapporterer sårbarheder igennem;
• holder øje med sårbarheder i de tredjeparts- og open source-komponenter, der er i dets produkter;
• triagerer hver rapport: Er den reel, hvilke produkter og versioner rammer den, og hvor alvorlig er den;
• får det engineering-team, der ejer koden, til at rette fejlen efter en tidsplan, der passer til risikoen;
• offentliggør advisories og koordinerer offentliggørelsen med rapportører og downstream-leverandører;
• rapporterer metrikker til ledelsen og uddanner dem, der bygger produkterne.

Det meste af arbejdet sker efter release. FIRST bemærker, at de fleste produktsårbarheder rapporteres som kvalitetsfejl, der er sluppet igennem, når et produkt er på markedet, selvom et PSIRT også tilfører værdi tidligere, i designgennemgange og trusselsmodellering.

Hvor et PSIRT hører hjemme i organisationen

Forskellen fra andre sikkerhedsteams er fokusset på produkter. Et enterprise-CSIRT beskytter virksomhedens egne systemer og netværk; et PSIRT beskytter de kunder, der kører virksomhedens produkter. De to deler kompetencer og ofte rapporteringslinje, og de mødes, når en hændelse i virksomhedens egen infrastruktur, for eksempel et kompromitteret build-system, når et produkt. Den fulde sammenligning finder du i PSIRT vs CSIRT.

FIRST beskriver tre driftsmodeller:

• Distribueret: Et lille kerne-PSIRT fastlægger politik og koordinerer, og sikkerhedsrepræsentanter i hvert produktteam står for triage og rettelser. Det skalerer på tværs af en stor, varieret portefølje, men de, der udfører arbejdet, rapporterer ikke til PSIRT'et.
• Centraliseret: Et større PSIRT med egen programledelse og egne medarbejdere til triage og afhjælpning, som rapporterer til en topleder for produktsikkerhed. Det passer til mindre virksomheder eller en ensartet portefølje og koster mere, når porteføljen vokser.
• Hybrid: en blanding af de to, valgt ud fra virksomhedens størrelse, portefølje og udviklingsstrategi.

Uanset modellen lægger FIRST vægt på uafhængighed: PSIRT'et bør rapportere til en leder, der bekræfter dets myndighed, så det kan indtage en objektiv holdning til sårbarheder i virksomhedens egne produkter.

FIRST PSIRT Services Framework

PSIRT Services Framework, udgivet gratis af FIRST og nu i version 1.1, er den reference, de fleste PSIRT'er bygger deres servicekatalog på. Det beskriver det operationelle fundament (mandat, interessenter, budget, politikker) og derefter seks serviceområder:

Serviceområde	Hvad det dækker
1. Styring af interessentøkosystemet	Interne interessenter, rapportørmiljøet, downstream-leverandører og kunder, hændelseskommunikation, anerkendelse af rapportører, interessentmetrikker
2. Opdagelse af sårbarheder	Modtagelse af sårbarhedsrapporter, opdagelse af urapporterede sårbarheder, overvågning af produktkomponenter for sårbarheder, identifikation af nye sårbarheder, opdagelsesmetrikker
3. Triage og analyse af sårbarheder	Kvalificering af rapporter, samarbejde med etablerede rapportører, reproduktion af sårbarheder
4. Afhjælpning	Plan for release af rettelser, afhjælpning, hændelseshåndtering, release-metrikker
5. Offentliggørelse af sårbarheder	Underretning, koordinering, offentliggørelse via advisories, offentliggørelsesmetrikker
6. Træning og uddannelse	Træning af PSIRT, udviklings- og valideringsteams og andre interessenter; feedbackmekanismer

Én service er værd at fremhæve, fordi den er blevet en stor del af arbejdet: overvågning for sårbarheder i produktkomponenter. Dens første funktion er et inventar over produktkomponenter, en liste over de leverandører, produkter og versioner, der indgår i hvert produkt, som FIRST kalder "essential to quickly identify affected products for inherited vulnerabilities". I moderne software er det inventar en software bill of materials (SBOM).

PSIRT-processen i overblik

To ISO/IEC-standarder beskriver processen. ISO/IEC 30111:2019 dækker, hvordan en leverandør håndterer sårbarheder internt. ISO/IEC 29147:2018 dækker, hvordan den modtager rapporter udefra og offentliggør oplysninger om afhjælpning. 30111 er beregnet til at blive brugt sammen med 29147, og de faser, den beskriver, giver et nyttigt overblik:

1. Forberedelse. Politik, roller, en offentliggjort måde at rapportere sårbarheder på, en scoringsmetode og et inventar over det, der leveres.
2. Modtagelse. Modtag rapporter fra forskere, kunder, partnere og din egen test samt fra advisories for komponenter, du bruger. Bekræft modtagelsen over for rapportøren.
3. Verifikation. Bekræft sårbarheden, reproducér den, scor den, og fastslå hvert ramt produkt og hver ramt version. Registrér også de produkter, der ikke er ramt, og hvorfor.
4. Udvikling af afhjælpning. Det team, der ejer koden, bygger og tester en rettelse eller en afhjælpende foranstaltning. PSIRT'et følger den i forhold til den aftalte tidsplan.
5. Release. Lever rettelsen, og offentliggør advisoryen i koordinering med rapportøren og med downstream-leverandører, der indlejrer dit produkt.
6. Efter release. Hold øje med problemer med rettelsen, svar kunderne, og før grundårsager tilbage til udviklingen.

Hvert trin, med hvad der skal registreres, og hvem der ejer det, er beskrevet i livscyklussen for sårbarhedsstyring. Om, hvilke fund der skal komme først, kan du læse i prioritering af sårbarheder, med signaler om udnyttelse fra EPSS og CISA KEV-kataloget. En sårbarhed, der udnyttes, før en rettelse findes, er en zero-day, og PSIRT'et håndterer den som en hændelse. Vejen fra advisory til et rettet, leveret build er beskrevet i CVE-afhjælpning.

Offentliggørelse og advisories

Offentliggørelse er den del af et PSIRT, kunderne ser. Den almindelige praksis er koordineret offentliggørelse af sårbarheder: Rapportøren rapporterer privat, leverandøren retter, og begge offentliggør på en aftalt dato, med anerkendelse af rapportøren. Det starter med en offentlig politik for offentliggørelse af sårbarheder, der siger, hvordan man rapporterer, hvad rapportører kan forvente, og hvor længe produkter understøttes. Se koordineret offentliggørelse af sårbarheder.

En god advisory fortæller en kunde, uden en telefonsamtale:

• hvilke produkter og versioner der er ramt, og hvilke der ikke er;
• CVE-ID og en alvorlighedsscore;
• den rettede version eller en afhjælpende foranstaltning, hvis der endnu ikke er en rettelse;
• hvem der fandt den.

Store kunder vil i stigende grad have advisories i en maskinlæsbar form, de automatisk kan matche mod deres eget aktivinventar. CSAF er OASIS-standardformatet for advisories, og VEX er måden at angive, at et produkt ikke er ramt af en sårbarhed i en af sine komponenter, hvilket sparer begge parter en sag.

PSIRT-metrikker og modenhed

Rammeværket lægger metrikker ind i hvert serviceområde. Almindelige metrikker:

• tid til at bekræfte en rapport, til at triagere den og til at udgive en rettelse, efter alvorlighed;
• åbne sårbarheder efter produkt, alvorlighed og alder;
• andel af rettelser leveret inden for de afhjælpningsmål, du har offentliggjort;
• sårbarheder fundet internt sammenlignet med rapporteret udefra;
• offentliggjorte advisories og rettelser til advisories.

FIRST's ledsagedokument PSIRT Maturity Document ordner tjenesterne i tre niveauer:

• Niveau 1, grundlæggende: ledelsesopbakning, interessenter, budget og politikker; en måde at modtage rapporter på; et triage-workflow; dokumenterede rettelser; advisories, der bruger CVE og CVSS og anerkender rapportøren.
• Niveau 2, mellem: et kommissorium og en organisationsmodel, basismetrikker, et produktregister med kortlægning af afhængigheder, en formel afhjælpningsplan, et system til at underrette interessenter og træning af teamet.
• Niveau 3, avanceret: direkte samarbejde med rapportørmiljøet, overvågning af produktkomponenter for sårbarheder, opdagelses- og release-metrikker, avanceret hændelseshåndtering og playbooks for koordinering i branchen.

Bevægelsen mellem niveauerne går fra reaktiv til proaktiv.

Sådan bygger du et PSIRT: start i det små

1. Få et skriftligt mandat fra en leder, med myndighed til at bede produktteams om at rette ting.
2. Offentliggør, hvordan man rapporterer en sårbarhed: en kontaktadresse for sikkerhed, en webformular eller en security.txt-fil og en kort politik for offentliggørelse.
3. Definér triage og scoring: hvem der afgør, om en rapport er gyldig, hvordan alvorlighed scores, og afhjælpningsmålene pr. alvorlighed.
4. Vid, hvad du leverer. For hver produktversion: komponenterne og versionerne i den. Uden det bliver hver ny CVE i et populært bibliotek til dages forespørgsler hos engineering-teams.
5. Udpeg en ejer pr. produkt, som modtager fund og planlægger rettelser.
6. Skriv en skabelon til advisories, og offentliggør den første, selv for et lille problem.
7. Mål nogle få tidslinjer fra starten, så du kan vise forbedring.

Siden om PSIRT-teams ser på rollen fra produktsikkerhedslederens side, og industrielle leverandører kan koble disse trin til IEC 62443-4-1, hvis krav til den sikre udviklingslivscyklus omfatter fejlhåndtering og patchhåndtering.

Regler, der forventer et PSIRT

Et PSIRT plejede at være et tegn på en moden leverandør. Flere rammeværker kræver nu dets resultater. NIS2 artikel 21, stk. 2, litra e, nævner "vulnerability handling and disclosure" blandt de foranstaltninger, væsentlige og vigtige enheder skal træffe. I USA kræver section 524B, at producenter af medicinsk udstyr indsender en plan for at overvåge, identificere og håndtere sårbarheder efter markedsføring, herunder koordineret offentliggørelse af sårbarheder, sammen med en SBOM. Og EU's Cyber Resilience Act kræver, at producenter rapporterer aktivt udnyttede sårbarheder og alvorlige hændelser til myndighederne, begyndende med en tidlig varsling inden for 24 timer; se hvad er CRA.

De værktøjer, et PSIRT har brug for

Behov	Hvorfor
Modtagelse af rapporter og sagsstyring	Hver rapport får en ejer, en status og en tidslinje
Inventar over det, der leveres	En præcis SBOM pr. produktversion, inklusive transitive afhængigheder
Løbende overvågning	Nye CVE'er matches mod komponenterne i alle udgivne versioner, ikke kun den næste
Triage og videresendelse	Fund går til det team, der ejer rettelsen, med den kontekst, der skal til for at handle
Erklæringer om ramt og ikke ramt	VEX registrerer, hvilke produkter en sårbarhed rammer, og hvorfor de andre ikke er ramt
Offentliggørelse af advisories	Advisories, mennesker kan læse, og maskinlæsbar CSAF til store kunder

Få produkter dækker alle rækker; PSIRT-værktøjer sammenlignet viser, hvilket værktøj der gør hvad. Inventaret er det, de fleste PSIRT'er kæmper med. En scanner, der læser lockfiles bagefter, angiver udviklingsafhængigheder, der aldrig leveres, og overser pakker, buildet downloadede uden om pakkehåndteringen, så svaret på "er vi ramt?" begynder med tvivl.

CRACI tager det inventar fra selve buildet. Det kører GitHub Actions-builds på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra CI-caches og afhængigheder, som ingen lockfile angiver. Hver SBOM har en fuldstændighedsstatus og eksporteres som CycloneDX eller SPDX. Overvågede SBOM'er genvurderes løbende, efterhånden som nye sårbarheder offentliggøres, build-historikken viser, hvilke tidligere builds der indeholdt en sårbar afhængighed, og inventaroversigten viser, hvilke softwareversioner der er udrullet til hvilke produkter. Sikkerhedsteams triagerer fund og sender dem til de teams, der ejer rettelsen, og CRACI understøtter VEX. Se sårbarhedssporing og CRACI til PSIRT-teams.

PSIRT: ofte stillede spørgsmål

Hvad står PSIRT for?

PSIRT står for Product Security Incident Response Team. FIRST definerer det som en enhed i en organisation, der fokuserer på at identificere, vurdere og håndtere risiciene ved sikkerhedssårbarheder i de produkter, tilbud, løsninger, komponenter og tjenester, organisationen fremstiller eller sælger.

Hvad er forskellen på et PSIRT og et CSIRT?

Et PSIRT håndterer sårbarheder i de produkter, en virksomhed leverer til kunder. Et enterprise-CSIRT håndterer sikkerhedshændelser i virksomhedens egne systemer og netværk. De to arbejder sammen, for eksempel når et brud på build-infrastrukturen påvirker et produkt. Se PSIRT vs CSIRT.

Hvad er FIRST PSIRT Services Framework?

En gratis guide fra FIRST, Forum of Incident Response and Security Teams, der angiver de tjenester, et PSIRT kan levere. Version 1.1 samler dem i seks serviceområder: styring af interessentøkosystemet, opdagelse af sårbarheder, triage og analyse af sårbarheder, afhjælpning, offentliggørelse af sårbarheder samt træning og uddannelse. Et ledsagende modenhedsdokument ordner tjenesterne i tre niveauer.

Hvilke standarder beskriver PSIRT-processen?

ISO/IEC 30111:2019 dækker, hvordan en leverandør håndterer sårbarhedsrapporter internt, fra forberedelse og modtagelse over verifikation, udvikling af afhjælpning og release til efter release. ISO/IEC 29147:2018 dækker grænsefladen mod omverdenen: modtagelse af rapporter og offentliggørelse af oplysninger om afhjælpning. 30111 er beregnet til at blive brugt sammen med 29147. IEC 62443-4-1 fastsætter krav til den sikre udviklingslivscyklus, herunder fejl- og patchhåndtering, for industrielle automatiseringsprodukter.

Har en lille virksomhed brug for et PSIRT?

Den har brug for funktionen, ikke nødvendigvis en afdeling. FIRST's modenhedsdokument starter med ledelsesopbakning, navngivne interessenter, et budget, nogle få politikker, en offentliggjort måde at rapportere sårbarheder på, et triage-workflow, dokumenterede rettelser og advisories, der anerkender rapportøren. Én eller to personer med et skriftligt mandat kan drive det.

Hvilke værktøjer har et PSIRT brug for?

Som minimum: en måde at modtage rapporter på, et sagsstyringsværktøj, en metode til at score sårbarheder, et inventar over, hvilke komponenter der leveres i hvilke produktversioner, overvågning af de komponenter for nye sårbarheder, en måde at registrere, om hvert produkt er ramt (ofte som VEX), og en måde at offentliggøre advisories, i stigende grad i CSAF.