PSIRT
PSIRT vs. CSIRT: produktsårbarheter og hendelser i din egen IT
Et CSIRT rykker ut når dine egne systemer blir angrepet. Et PSIRT rykker ut når produktene du selger, har en sårbarhet som kundene dine er eksponert for. Begge er team for hendelseshåndtering, begge følger rammeverk fra FIRST, og i en reell hendelse trenger de ofte hverandre.
Oppdatert
Hva er et CSIRT?
Et CSIRT (Computer Security Incident Response Team) er teamet som håndterer sikkerhetshendelser for en definert gruppe mennesker eller organisasjoner, kalt målgruppen. FIRSTs CSIRT Services Framework definerer det som en organisatorisk enhet, som kan være virtuell, eller en kapasitet som leverer tjenester til målgruppen for å forebygge, oppdage, håndtere og respondere på datasikkerhetshendelser.
Målgruppen avgjør hva slags CSIRT det er:
- CSIRT i en virksomhet: ett selskaps egne nettverk, systemer, kontoer og data.
- Sektor-CSIRT: en gruppe organisasjoner i én bransje, for eksempel finans eller energi.
- Nasjonalt CSIRT: et helt land, ofte med en rolle i grenseoverskridende koordinering.
- Leverandørteam: et selskaps kunder, for problemer i produktene. Dette er PSIRT-et.
CSIRT Services Framework (versjon 2.1) deler CSIRT-tjenester inn i fem områder: håndtering av informasjonssikkerhetsbegivenheter, håndtering av informasjonssikkerhetshendelser, sårbarhetshåndtering, situasjonsforståelse og kunnskapsoverføring.
Hva er et PSIRT?
Et PSIRT (Product Security Incident Response Team) er, slik FIRST beskriver det, enheten i en organisasjon som konsentrerer seg om å identifisere, vurdere og disponere risikoene knyttet til sikkerhetssårbarheter i produktene organisasjonen lager eller selger. Det tar imot sårbarhetsrapporter, finner ut hvilke produkter og versjoner som er berørt, får en retting bygget og levert, og informerer kundene gjennom advisories.
Rammeverket, PSIRT Services Framework (versjon 1.1), har 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.
Den viktigste forskjellen
Forskjellen ligger i hvem sine systemer som er i fare. Et CSIRT beskytter organisasjonen: Hendelsen er i ditt miljø, og du begrenser den. Et PSIRT beskytter kundene dine: Sårbarheten er i produktet ditt, som kjører i deres miljøer, og du kan ikke patche det for dem. Du leverer en retting og ber dem installere den.
FIRST sier det rett ut: Fokuset på produkter er det som først og fremst skiller et PSIRT fra andre team for hendelseshåndtering i samme organisasjon, og et CSIRT i en virksomhet er som regel rettet mot systemene og nettverkene som utgjør organisasjonens egen infrastruktur.
PSIRT og CSIRT sammenlignet
| CSIRT i en virksomhet | PSIRT | |
|---|---|---|
| Omfang | Hendelser i organisasjonens egne nettverk, systemer og data | Sårbarheter i produktene organisasjonen leverer |
| Målgruppe | Ansatte og interne systemer | Kunder og brukere av produktene |
| Typisk inndata | Varsler, logger, brukerrapporter, trusselinformasjon | Rapporter fra forskere, advisories for tredjepartskomponenter, intern testing, koordinatorer |
| Typisk resultat | Begrensede hendelser, gjenopprettede systemer, gjennomganger etter hendelser | Rettede utgivelser, sikkerhetsadvisories, CVE-oppføringer, kundevarsler |
| Klokken starter | Når en hendelse oppdages | Når en sårbarhet rapporteres eller publiseres |
| Typisk eier | CISO-en eller IT-sikkerhet | Produktsikkerhet eller utvikling |
| FIRST-rammeverk | CSIRT Services Framework 2.1 | PSIRT Services Framework 1.1 |
| Standarder | ISO/IEC 27035 (hendelseshåndtering) | ISO/IEC 29147 (offentliggjøring av sårbarheter), ISO/IEC 30111 (håndtering av sårbarheter) |
Begge rammeverkene understreker at teamene ikke arbeider isolert. PSIRT-rammeverket beskriver CSIRT-er, også de nasjonale, som interessenter et PSIRT bør bygge relasjoner til, fordi det ofte er gjennom dem en leverandør får tidlig kjennskap til en sårbarhet.
CERT vs. CSIRT
Det første teamet av denne typen var CERT Coordination Center, som ifølge SEI vokste frem av responsen på Morris-ormen i 1988, med finansiering fra DARPA, ved Carnegie Mellons Software Engineering Institute. CERT er et merke registrert i USA av Carnegie Mellon University, og SEI gir amerikanske team tillatelse til å bruke det i navnet sitt. Det lisensierer ikke lenger merket utenfor USA.
CERT og CSIRT beskriver altså samme type team. CSIRT er det nøytrale begrepet, brukt av FIRST og i EU-retten; mange team, særlig nasjonale, har fortsatt CERT i navnet.
Nasjonale CSIRT-er og koordinatorer
Noen få organisasjoner er viktige for et produktteam fordi de står mellom finnere, leverandører og brukere:
- CERT/CC har koordinert offentliggjøring av programvaresårbarheter siden 1988, og publiserer en guide til koordinert offentliggjøring av sårbarheter for organisasjoner som bygger sin egen prosess.
- CISA koordinerer offentliggjøring mellom dem som rapporterer, produsenter og brukere i USA, og kan publisere så tidlig som 45 dager etter det første forsøket på å kontakte en leverandør som ikke svarer, enten det finnes en retting eller ikke.
- Nasjonale CSIRT-er i EU. NIS2 krever at hver medlemsstat utpeker eller oppretter ett eller flere CSIRT-er, og de samarbeider i CSIRTs Network sammen med CERT-EU. ENISA, EUs cybersikkerhetsbyrå, står for sekretariatet.
Nasjonale CSIRT-er har også en formell rolle i rapportering av sårbarheter. Etter NIS2 artikkel 12 utpeker hver medlemsstat ett CSIRT som koordinator for koordinert offentliggjøring av sårbarheter: en betrodd mellommann mellom den som rapporterer en sårbarhet, og produsenten, som kan identifisere de berørte leverandørene, hjelpe den som rapporterer, og forhandle frem tidsfrister for offentliggjøring. Cyber Resilience Act bygger på den samme rollen: Produsenter varsler om aktivt utnyttede sårbarheter i produktene sine til CSIRT-et som er utpekt som koordinator, og til ENISA samtidig.
Slik samarbeider et PSIRT og et CSIRT
Ta en sårbar komponent med åpen kildekode som blir utnyttet, og som brukes både i produktet ditt og i de interne systemene dine. Begge teamene får samme advisory, og hvert av dem har sin egen jobb:
- CSIRT: finner komponenten på interne servere og bærbare maskiner, sjekker logger for utnyttelse, patcher eller isolerer, og håndterer en hendelse hvis noe ble kompromittert.
- PSIRT: finner ut hvilke produkter, versjoner og bygg som inneholder komponenten, vurderer om produktet er berørt, leverer en rettet utgivelse og publiserer en advisory, med en VEX-erklæring for versjonene som ikke er berørt.
- Begge: deler indikatorer og tidslinjer. Hvis CSIRT-et finner ut at angrepet nådde byggesystemet, må PSIRT-et sjekke om noen levert utgivelse er manipulert, og da blir en intern hendelse til en produkthendelse. Et leverandørkjedeangrep krysser vanligvis denne linjen.
Det er det andre steget som bremser PSIRT-et. Et CSIRT kan skanne sitt eget miljø. Et PSIRT må svare for programvare som allerede er i kundenes hender, og det betyr å vite hva som gikk inn i hver utgivelse det har levert. Sidene om livssyklusen for sårbarhetshåndtering og koordinert offentliggjøring av sårbarheter dekker resten av PSIRT-ets vei frem til en retting.
CSIRT vs. SOC
Et Security Operations Center (SOC) overvåker: Det følger med på varsler og logger døgnet rundt, filtrerer bort støy og eskalerer det som ser reelt ut. Et CSIRT responderer: Det tar den bekreftede hendelsen, begrenser den, etterforsker, koordinerer med juridisk avdeling og kommunikasjon og leder gjenopprettingen. I mindre organisasjoner er SOC-et og CSIRT-et ofte de samme menneskene, og SEI påpeker at det betyr mindre om et team kalles CSIRT, SOC eller noe annet, enn hvilke funksjoner det utfører.
Ingen av dem erstatter et PSIRT. Et SOC overvåker miljøet ditt; det kan ikke se en sårbarhet i en enhet en kunde kjører.
Trenger du begge?
Hvis du lager programvare eller enheter og også driver din egen IT, trenger du begge funksjonene. Du trenger ikke to avdelinger. Små leverandører begynner ofte med én sikkerhetsansvarlig som leder hendelseshåndteringen for selskapet, og en skriftlig PSIRT-prosess for produktene, med utviklere på vakt for rettinger. Det som må holdes atskilt, er prosessen: En intern hendelse og en produktsårbarhet har ulike eiere, ulike frister og ulike personer som må informeres.
Hvor CRACI passer inn
CRACI støtter PSIRT-siden: å vite hva som er i programvaren du leverer. Det kjører GitHub Actions-byggene dine på egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter og pakker gjenopprettet fra cacher, og eksporterer SBOM-er som CycloneDX eller SPDX.
Overvåkede SBOM-er vurderes kontinuerlig på nytt, og byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar avhengighet. Inventarvisningen viser hvilke versjoner som er rullet ut til hvilke produkter, og sikkerhetsteam prioriterer funn og sender dem til teamene som eier rettingen. Se sporing av sårbarheter og CRACI for PSIRT-er.
PSIRT vs. CSIRT: ofte stilte spørsmål
Hva er et CSIRT?
Et Computer Security Incident Response Team. FIRST definerer det som en organisatorisk enhet, som kan være virtuell, eller en kapasitet som leverer tjenester og støtte til en definert målgruppe for å forebygge, oppdage, håndtere og respondere på datasikkerhetshendelser. Målgruppen kan være ett selskap, en sektor eller et helt land.
Hva er forskjellen på et PSIRT og et CSIRT?
Et PSIRT håndterer sårbarheter i produktene et selskap selger, som kundene er eksponert for. Et CSIRT i en virksomhet håndterer sikkerhetshendelser i selskapets egne systemer og nettverk. FIRST kaller fokuset på produkter det som først og fremst skiller de to.
Er et CERT det samme som et CSIRT?
Funksjonelt sett, ja. CERT er et merke registrert i USA av Carnegie Mellon University, der CERT Coordination Center var det første teamet av denne typen, opprettet i 1988 etter Morris-ormen. CSIRT er fellesbegrepet. Mange nasjonale team bruker CERT i navnet, og EU bruker CSIRT i lovgivningen.
Hva er forskjellen på et SOC og et CSIRT?
Et SOC overvåker og oppdager døgnet rundt: Det følger med på varsler og logger og eskalerer det som ser reelt ut. Et CSIRT eier responsen på bekreftede hendelser: begrensning, etterforskning, koordinering og gjenoppretting. I mange organisasjoner overlapper de to eller deler folk, og SEI påpeker at det viktige er hvilke funksjoner et team utfører, ikke hva det kalles.
Trenger vi både et PSIRT og et CSIRT?
Hvis du selger programvare eller enheter og også driver din egen IT, trenger du begge funksjonene, men ikke nødvendigvis to avdelinger. I et lite selskap dekker ofte de samme få personene begge deler, med atskilte prosesser: én for hendelser i miljøet ditt og én for sårbarheter i det du leverer.
Hva gjør et nasjonalt CSIRT?
Det håndterer hendelser for en nasjonal målgruppe, deler varsler og koordinerer over landegrensene. Etter NIS2 utpeker hver EU-medlemsstat minst ett CSIRT, og ett av dem fungerer som koordinator for koordinert offentliggjøring av sårbarheter: en betrodd mellommann mellom den som rapporterer en sårbarhet, og produsenten.
Vit hvilke bygg som inneholder en sårbar komponent
Når en advisory kommer, må PSIRT-et ditt vite hvor komponenten leveres. Book en demo og se det ut fra en registrering av hva hvert bygg hentet.
Book en demo