PSIRT: hva et team for produktsikkerhetshendelser gjør

Hva er et PSIRT?

Et Product Security Incident Response Team (PSIRT) er funksjonen som håndterer sikkerhetssårbarheter i produktene et selskap lager og selger. FIRST definerer det som en enhet som konsentrerer seg om å identifisere, vurdere og disponere risikoene knyttet til sikkerhetssårbarheter i produktene, inkludert tilbud, løsninger, komponenter og tjenester.

I praksis gjør et PSIRT følgende:

• driver kanalen der forskere, kunder og partnere rapporterer sårbarheter;
• følger med på sårbarheter i tredjepartskomponentene og komponentene med åpen kildekode i produktene;
• prioriterer hver rapport: Er den reell, hvilke produkter og versjoner berører den, hvor alvorlig er den;
• får det ansvarlige utviklingsteamet til å rette den, etter en tidsplan som står i forhold til risikoen;
• publiserer advisories og koordinerer offentliggjøring med finnere og nedstrømsleverandører;
• rapporterer metrikker til ledelsen og lærer opp dem som bygger produktene.

Det meste av arbeidet skjer etter utgivelse. FIRST påpeker at de fleste produktsårbarheter rapporteres som kvalitetsfeil som har sluppet gjennom etter at et produkt er på markedet, selv om et PSIRT også tilfører verdi tidligere, i designgjennomganger og trusselmodellering.

Hvor et PSIRT hører hjemme i organisasjonen

Forskjellen fra andre sikkerhetsteam er fokuset på produkter. Et CSIRT i en virksomhet beskytter selskapets egne systemer og nettverk; et PSIRT beskytter kundene som kjører selskapets produkter. De to deler kompetanse og ofte rapporteringslinje, og de møtes når en hendelse i selskapets egen infrastruktur, for eksempel et kompromittert byggesystem, når et produkt. Den fulle sammenligningen finner du i PSIRT vs. CSIRT.

FIRST beskriver tre driftsmodeller:

• Distribuert: Et lite kjerne-PSIRT setter policy og koordinerer, og sikkerhetsrepresentanter i hvert produktteam står for prioritering og retting. Modellen skalerer over en stor og variert portefølje, men de som gjør arbeidet, rapporterer ikke til PSIRT-et.
• Sentralisert: Et større PSIRT med egne ansatte for programledelse, prioritering og retting, som rapporterer til en toppleder for produktsikkerhet. Modellen passer mindre selskaper eller en ensartet portefølje og koster mer etter hvert som porteføljen vokser.
• Hybrid: En blanding av de to, valgt ut fra selskapets størrelse, portefølje og utviklingsstrategi.

Uansett modell legger FIRST vekt på uavhengighet: PSIRT-et bør rapportere til en toppleder som bekrefter myndigheten, slik at det kan ta et objektivt standpunkt til sårbarheter i selskapets egne produkter.

FIRST PSIRT Services Framework

PSIRT Services Framework, gitt ut gratis av FIRST og nå i versjon 1.1, er referansen de fleste PSIRT-er bygger tjenestekatalogen sin på. Det legger et operativt grunnlag (mandat, interessenter, budsjett, policyer) og beskriver deretter seks tjenesteområder:

Tjenesteområde	Hva det dekker
1. Forvaltning av interessentøkosystemet	Interne interessenter, finnermiljøet, nedstrømsleverandører og kunder, hendelseskommunikasjon, anerkjennelse av finnere, interessentmetrikker
2. Oppdagelse av sårbarheter	Mottak av sårbarhetsrapporter, oppdagelse av urapporterte sårbarheter, overvåking av produktkomponenter for sårbarheter, identifisering av nye sårbarheter, oppdagelsesmetrikker
3. Prioritering og analyse av sårbarheter	Kvalifisering av rapporter, samarbeid med etablerte finnere, reproduksjon av sårbarheter
4. Retting	Plan for utgivelse av rettinger, retting, hendelseshåndtering, utgivelsesmetrikker
5. Offentliggjøring av sårbarheter	Varsling, koordinering, offentliggjøring gjennom advisories, metrikker for offentliggjøring
6. Opplæring og utdanning	Opplæring av PSIRT-et, utviklings- og valideringsteam og andre interessenter; tilbakemeldingsmekanismer

Én tjeneste fortjener å trekkes frem fordi den har blitt en stor del av arbeidet: overvåking av sårbarheter i produktkomponenter. Dens første funksjon er et inventar over produktkomponenter, en liste over leverandørene, produktene og versjonene som inngår i hvert produkt, og FIRST kaller dette avgjørende for raskt å kunne identifisere berørte produkter ved nedarvede sårbarheter. I moderne programvare er det inventaret en SBOM (software bill of materials).

PSIRT-prosessen i korte trekk

To ISO/IEC-standarder beskriver prosessen. ISO/IEC 30111:2019 dekker hvordan en leverandør håndterer sårbarheter internt. ISO/IEC 29147:2018 dekker hvordan den mottar rapporter utenfra og publiserer informasjon om retting. 30111 er ment å brukes sammen med 29147, og fasene den beskriver, gir en nyttig oversikt:

1. Forberedelse. Policy, roller, en publisert måte å rapportere sårbarheter på, en metode for poengsetting og et inventar over det som leveres.
2. Mottak. Ta imot rapporter fra forskere, kunder, partnere og din egen testing, og fra advisories for komponenter du bruker. Bekreft mottaket overfor finneren.
3. Verifisering. Bekreft sårbarheten, reproduser den, gi den en poengscore og fastslå hvert berørte produkt og hver berørte versjon. Registrer også produkter som ikke er berørt, og hvorfor.
4. Utvikling av retting. Det ansvarlige teamet bygger og tester en retting eller et tiltak. PSIRT-et følger den opp mot den avtalte tidsplanen.
5. Utgivelse. Lever rettingen og publiser advisoryen, koordinert med finneren og med nedstrømsleverandører som bygger produktet ditt inn i sine.
6. Etter utgivelse. Følg med på problemer med rettingen, svar kunder og før rotårsaker tilbake til utviklingen.

Hvert stadium, med hva som skal registreres og hvem som eier det, dekkes i livssyklusen for sårbarhetshåndtering. Hvordan du avgjør hvilke funn som kommer først, ser du i prioritering av sårbarheter, med signaler om utnyttelse fra EPSS og CISA KEV-katalogen. En sårbarhet som utnyttes før det finnes en retting, er en zero-day-sårbarhet, og PSIRT-et håndterer den som en hendelse. Veien fra advisory til et rettet, levert bygg dekkes i CVE-utbedring.

Offentliggjøring og advisories

Offentliggjøring er den delen av PSIRT-arbeidet kundene ser. Vanlig praksis er koordinert offentliggjøring av sårbarheter: Finneren rapporterer privat, leverandøren retter, og begge publiserer på en avtalt dato, med finneren kreditert. Det begynner med en offentlig policy for offentliggjøring av sårbarheter som sier hvordan du rapporterer, hva finnere kan forvente og hvor lenge produkter støttes. Se koordinert offentliggjøring av sårbarheter.

En god advisory forteller en kunde, uten en telefonsamtale:

• hvilke produkter og versjoner som er berørt, og hvilke som ikke er det;
• CVE-ID-en og en alvorlighetsscore;
• den rettede versjonen, eller et tiltak hvis det ikke finnes en retting ennå;
• hvem som fant den.

Store kunder vil i økende grad ha advisories i et maskinlesbart format som de automatisk kan matche mot sitt eget aktivainventar. CSAF er OASIS-standardformatet for advisories, og VEX er måten å si at et produkt ikke er berørt av en sårbarhet i en av komponentene på, noe som sparer begge sider for en sak.

PSIRT-metrikker og modenhet

Rammeverket legger inn metrikker i hvert tjenesteområde. Vanlige metrikker er:

• tid til å bekrefte en rapport, prioritere den og gi ut en retting, etter alvorlighetsgrad;
• åpne sårbarheter etter produkt, alvorlighetsgrad og alder;
• andelen rettinger levert innenfor rettingsmålene du har publisert;
• sårbarheter funnet internt kontra rapportert utenfra;
• publiserte advisories og rettelser av advisories.

FIRSTs tilhørende PSIRT Maturity Document ordner tjenestene i tre nivåer:

• Nivå 1, grunnleggende: sponsor i toppledelsen, interessenter, budsjett og policyer; en måte å motta rapporter på; en arbeidsflyt for prioritering; dokumenterte rettinger; advisories som bruker CVE og CVSS og krediterer finneren.
• Nivå 2, middels: et mandat og en organisasjonsmodell, grunnleggende metrikker, et produktregister med kartlegging av avhengigheter, en formell plan for rettinger, et system for å varsle interessenter og opplæring av teamet.
• Nivå 3, avansert: direkte kontakt med finnermiljøet, overvåking av sårbarheter i produktkomponenter, metrikker for oppdagelse og utgivelse, avansert hendelseshåndtering og playbooks for koordinering i bransjen.

Bevegelsen mellom nivåene går fra reaktiv til proaktiv.

Slik bygger du et PSIRT: Start i det små

1. Få et skriftlig mandat fra en toppleder, med myndighet til å be produktteam om å rette ting.
2. Publiser hvordan man rapporterer en sårbarhet: en kontaktadresse for sikkerhet, et nettskjema eller en security.txt-fil, og en kort policy for offentliggjøring.
3. Definer prioritering og poengsetting: hvem som avgjør om en rapport er gyldig, hvordan alvorlighetsgrad settes, og rettingsmålene per alvorlighetsgrad.
4. Vit hva du leverer. For hver produktversjon: komponentene og versjonene i den. Uten dette blir hver nye CVE i et populært bibliotek til dager med spørsmål til utviklingsteamene.
5. Utpek en eier per produkt som mottar funn og planlegger rettinger.
6. Skriv en mal for advisories og publiser den første, selv for et lite problem.
7. Mål noen få tidslinjer fra starten, så du kan vise forbedring.

Siden for PSIRT-team ser på rollen fra produktsikkerhetslederens side, og industrielle leverandører kan koble disse stegene til IEC 62443-4-1, der kravene til sikker utviklingslivssyklus omfatter feilhåndtering og patchhåndtering.

Regelverk som forventer et PSIRT

Et PSIRT var tidligere et kjennetegn på en moden leverandør. Flere rammeverk ber nå om det et PSIRT produserer. NIS2 artikkel 21(2)(e) regner håndtering og offentliggjøring av sårbarheter blant tiltakene vesentlige og viktige enheter må gjennomføre. I USA krever section 524B at produsenter av medisinsk utstyr leverer en plan for å overvåke, identifisere og håndtere sårbarheter etter markedsføring, inkludert koordinert offentliggjøring av sårbarheter, sammen med en SBOM. Og EUs Cyber Resilience Act krever at produsenter rapporterer aktivt utnyttede sårbarheter og alvorlige hendelser til myndighetene, med et tidlig varsel innen 24 timer som første steg; se hva er CRA.

Verktøyene et PSIRT trenger

Behov	Hvorfor
Mottak av rapporter og saksoppfølging	Hver rapport får en eier, en status og en tidslinje
Inventar over det som leveres	En nøyaktig SBOM per produktversjon, inkludert transitive avhengigheter
Kontinuerlig overvåking	Nye CVE-er matches mot komponentene i hver utgitte versjon, ikke bare den neste
Prioritering og ruting	Funn går til teamet som eier rettingen, med konteksten som trengs for å handle
Erklæringer om berørt og ikke berørt	VEX registrerer hvilke produkter en sårbarhet berører, og hvorfor de andre ikke er berørt
Publisering av advisories	Lesbare advisories, og maskinlesbar CSAF for store kunder

Få produkter dekker hver rad; PSIRT-verktøy sammenlignet viser hvilket verktøy som gjør hva. Inventaret er der de fleste PSIRT-er sliter. En skanner som leser lockfiler i etterkant, lister opp utviklingsavhengigheter som aldri leveres, og overser pakker bygget lastet ned utenom pakkebehandleren, så svaret på «er vi berørt?» begynner med tvil.

CRACI henter det inventaret fra selve bygget. CRACI kjører GitHub Actions-bygg på sine egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra CI-cacher og avhengigheter ingen lockfile viser. Hver SBOM har en fullstendighetsstatus og eksporteres som CycloneDX eller SPDX. Overvåkede SBOM-er vurderes kontinuerlig på nytt etter hvert som nye sårbarheter publiseres, byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar avhengighet, og inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter. Sikkerhetsteam prioriterer funn og sender dem til teamene som eier rettingen, og CRACI støtter VEX. Se sårbarhetssporing og CRACI for PSIRT-team.

PSIRT: ofte stilte spørsmål

Hva står PSIRT for?

PSIRT står for Product Security Incident Response Team. FIRST definerer det som en enhet i en organisasjon som konsentrerer seg om å identifisere, vurdere og disponere risikoene knyttet til sikkerhetssårbarheter i produktene, tilbudene, løsningene, komponentene og tjenestene organisasjonen produserer eller selger.

Hva er forskjellen på et PSIRT og et CSIRT?

Et PSIRT håndterer sårbarheter i produktene et selskap leverer til kunder. Et CSIRT i en virksomhet håndterer sikkerhetshendelser i selskapets egne systemer og nettverk. De to samarbeider, for eksempel når et brudd på byggeinfrastrukturen berører et produkt. Se PSIRT vs. CSIRT.

Hva er FIRST PSIRT Services Framework?

En gratis veiledning fra FIRST, Forum of Incident Response and Security Teams, som lister opp tjenestene et PSIRT kan levere. Versjon 1.1 grupperer dem i seks tjenesteområder: forvaltning av interessentøkosystemet, oppdagelse av sårbarheter, prioritering og analyse av sårbarheter, retting, offentliggjøring av sårbarheter samt opplæring og utdanning. Et tilhørende modenhetsdokument ordner tjenestene i tre nivåer.

Hvilke standarder beskriver PSIRT-prosessen?

ISO/IEC 30111:2019 dekker hvordan en leverandør håndterer sårbarhetsrapporter internt, fra forberedelse og mottak gjennom verifisering, utvikling av retting, utgivelse og fasen etter utgivelse. ISO/IEC 29147:2018 dekker grensesnittet mot omverdenen: mottak av rapporter og publisering av informasjon om retting. 30111 er ment å brukes sammen med 29147. IEC 62443-4-1 setter krav til sikker utviklingslivssyklus, inkludert feilhåndtering og patchhåndtering, for produkter til industriell automasjon.

Trenger et lite selskap et PSIRT?

Selskapet trenger funksjonen, ikke nødvendigvis en avdeling. FIRSTs modenhetsdokument begynner med en sponsor i toppledelsen, navngitte interessenter, et budsjett, noen få policyer, en publisert måte å rapportere sårbarheter på, en arbeidsflyt for prioritering, dokumenterte rettinger og advisories som krediterer finneren. Én eller to personer med et skriftlig mandat kan drive dette.

Hvilke verktøy trenger et PSIRT?

Som et minimum: en måte å motta rapporter på, et saksoppfølgingssystem, en metode for å gi sårbarheter poengscore, et inventar over hvilke komponenter som leveres i hvilke produktversjoner, overvåking av disse komponentene for nye sårbarheter, en måte å registrere om hvert produkt er berørt (ofte som VEX), og en måte å publisere advisories på, i økende grad i CSAF.