PSIRT
PSIRT vs CSIRT: produktsårbarheder og hændelser i din egen IT
Et CSIRT reagerer, når dine egne systemer bliver angrebet. Et PSIRT reagerer, når de produkter, du sælger, har en sårbarhed, som dine kunder er eksponeret for. Begge er incident response-teams, begge følger rammeværker fra FIRST, og under en reel hændelse har de ofte brug for hinanden.
Opdateret
Hvad er et CSIRT?
Et CSIRT (Computer Security Incident Response Team) er det team, der håndterer sikkerhedshændelser for en defineret gruppe af personer eller organisationer, kaldet dets målgruppe. FIRST's CSIRT Services Framework definerer det som en organisatorisk enhed, som kan være virtuel, eller en kapacitet, der leverer tjenester til denne målgruppe "for preventing, detecting, handling, and responding to computer security incidents".
Det er målgruppen, der afgør, hvilken slags CSIRT der er tale om:
- Enterprise-CSIRT: én virksomheds egne netværk, systemer, konti og data.
- Sektor-CSIRT: en gruppe organisationer i én branche, for eksempel finans eller energi.
- Nationalt CSIRT: et helt land, ofte med en rolle i grænseoverskridende koordinering.
- Leverandørteam: en virksomheds kunder, for problemer i dens produkter. Det er PSIRT'et.
CSIRT Services Framework (version 2.1) samler CSIRT-tjenester i fem områder: håndtering af informationssikkerhedsbegivenheder, håndtering af informationssikkerhedshændelser, sårbarhedsstyring, situationsbevidsthed og vidensoverførsel.
Hvad er et PSIRT?
Et PSIRT (Product Security Incident Response Team) er, med FIRST's ord, den enhed i en organisation, der fokuserer på "the identification, assessment and disposition of the risks associated with security vulnerabilities within the products", som organisationen fremstiller eller sælger. Det modtager sårbarhedsrapporter, finder ud af, hvilke produkter og versioner der er ramt, får bygget og leveret en rettelse og informerer kunderne gennem advisories.
Dets rammeværk, PSIRT Services Framework (version 1.1), har 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.
Den vigtigste forskel
Forskellen er, hvis systemer der er i fare. Et CSIRT beskytter organisationen: Hændelsen er i dit miljø, og du inddæmmer den. Et PSIRT beskytter dine kunder: Sårbarheden er i dit produkt, som kører i deres miljøer, og du kan ikke patche det for dem. Du leverer en rettelse og beder dem installere den.
FIRST siger det ligeud: "the focus on products is the key differentiator" mellem et PSIRT og andre incident response-teams i samme organisation, og et enterprise-CSIRT fokuserer generelt på de systemer og netværk, der udgør organisationens egen infrastruktur.
PSIRT og CSIRT sammenlignet
| Enterprise-CSIRT | PSIRT | |
|---|---|---|
| Omfang | Hændelser i organisationens egne netværk, systemer og data | Sårbarheder i de produkter, organisationen leverer |
| Målgruppe | Medarbejdere og interne systemer | Produkternes kunder og brugere |
| Typisk input | Alarmer, logs, brugerrapporter, threat intelligence | Rapporter fra forskere, advisories for tredjepartskomponenter, intern test, koordinatorer |
| Typisk output | Inddæmmede hændelser, gendannede systemer, evalueringer efter hændelser | Rettede releases, sikkerhedsadvisories, CVE-poster, underretninger til kunder |
| Uret starter | Når en hændelse opdages | Når en sårbarhed rapporteres eller offentliggøres |
| Typisk ejer | CISO'en eller IT-sikkerhed | Produktsikkerhed eller engineering |
| FIRST-rammeværk | CSIRT Services Framework 2.1 | PSIRT Services Framework 1.1 |
| Standarder | ISO/IEC 27035 (hændelsesstyring) | ISO/IEC 29147 (offentliggørelse af sårbarheder), ISO/IEC 30111 (håndtering af sårbarheder) |
Begge rammeværker understreger, at teamene ikke arbejder isoleret. PSIRT-rammeværket beskriver CSIRT'er, også de nationale, som interessenter, et PSIRT bør opbygge relationer til, fordi det ofte er gennem dem, en leverandør tidligt hører om en sårbarhed.
CERT vs CSIRT
Det første team af denne slags var CERT Coordination Center, som ifølge SEI opstod som reaktion på Morris-ormen i 1988, med finansiering fra DARPA, på Carnegie Mellons Software Engineering Institute. CERT er et mærke, der er registreret i USA af Carnegie Mellon University, og SEI giver amerikanske teams tilladelse til at bruge det i deres navne. Det licenserer ikke længere mærket uden for USA.
"CERT" og "CSIRT" beskriver altså den samme slags team. CSIRT er det neutrale begreb, som bruges af FIRST og i EU-retten; mange teams, især nationale, har stadig CERT i navnet.
Nationale CSIRT'er og koordinatorer
Nogle få organisationer er vigtige for et produktteam, fordi de står mellem dem, der finder sårbarheder, leverandører og brugere:
- CERT/CC har koordineret offentliggørelsen af softwaresårbarheder siden 1988 og udgiver en guide til koordineret offentliggørelse af sårbarheder for organisationer, der bygger deres egen proces.
- CISA koordinerer offentliggørelse mellem rapportører, producenter og brugere i USA og kan offentliggøre allerede 45 dage efter det første forsøg på at kontakte en leverandør, der ikke svarer, uanset om der findes en rettelse.
- Nationale CSIRT'er i EU. NIS2 kræver, at hver medlemsstat udpeger eller opretter et eller flere CSIRT'er, og de samarbejder i CSIRTs Network sammen med CERT-EU. ENISA, EU's cybersikkerhedsagentur, varetager sekretariatet.
Nationale CSIRT'er har også en formel rolle i rapportering af sårbarheder. Efter NIS2 artikel 12 udpeger hver medlemsstat ét CSIRT som koordinator for koordineret offentliggørelse af sårbarheder: en betroet mellemmand mellem den, der rapporterer en sårbarhed, og producenten. Koordinatoren kan identificere de berørte leverandører, hjælpe rapportøren og forhandle tidsplaner for offentliggørelse. Cyber Resilience Act bygger på samme rolle: Producenter underretter samtidig det CSIRT, der er udpeget som koordinator, og ENISA om aktivt udnyttede sårbarheder i deres produkter.
Sådan arbejder et PSIRT og et CSIRT sammen
Tag en sårbar open source-komponent, der bliver udnyttet, og som bruges både i dit produkt og i dine interne systemer. Begge teams modtager den samme advisory, og hvert team har sin egen opgave:
- CSIRT: finder komponenten på interne servere og bærbare, tjekker logs for udnyttelse, patcher eller isolerer og kører et hændelsesforløb, hvis noget er kompromitteret.
- PSIRT: finder ud af, hvilke produkter, versioner og builds der indeholder komponenten, vurderer, om produktet er ramt, leverer en rettet release og offentliggør en advisory, med en VEX-erklæring for de versioner, der ikke er ramt.
- Begge: deler indikatorer og tidslinjer. Finder CSIRT'et ud af, at angrebet nåede build-systemet, skal PSIRT'et tjekke, om en leveret release er blevet manipuleret, og så bliver en intern hændelse til en produkthændelse. Et forsyningskædeangreb krydser som regel denne grænse.
Det er det andet trin, der bremser PSIRT'et. Et CSIRT kan scanne sit eget miljø. Et PSIRT skal stå til ansvar for software, der allerede er i kundernes hænder, og det betyder, at det skal vide, hvad der indgik i hver release, det har leveret. Siderne om livscyklussen for sårbarhedsstyring og koordineret offentliggørelse af sårbarheder dækker resten af PSIRT'ets vej til en rettelse.
CSIRT vs SOC
Et Security Operations Center (SOC) holder øje: Det overvåger alarmer og logs døgnet rundt, filtrerer støj fra og eskalerer det, der ser reelt ud. Et CSIRT reagerer: Det overtager den bekræftede hændelse, inddæmmer den, undersøger den, koordinerer med jura og kommunikation og leder gendannelsen. I mindre organisationer er SOC'et og CSIRT'et ofte de samme personer, og SEI påpeger, at det betyder mindre, om et team kaldes et CSIRT, et SOC eller noget andet, end hvilke funktioner det udfører.
Ingen af dem erstatter et PSIRT. Et SOC overvåger dit miljø; det kan ikke se en sårbarhed i en enhed, en kunde kører.
Har du brug for begge?
Hvis du laver software eller enheder og også driver din egen IT, har du brug for begge funktioner. Du behøver ikke to afdelinger. Små leverandører starter ofte med én sikkerhedsansvarlig, der står for incident response i virksomheden, og en skriftlig PSIRT-proces for produkterne, med engineering på vagt til rettelser. Det, der skal være adskilt, er processen: En intern hændelse og en produktsårbarhed har forskellige ejere, forskellige frister og forskellige personer, der skal informeres.
Hvor CRACI passer ind
CRACI understøtter PSIRT-siden: at vide, hvad der er i den software, du leverer. Det kører dine GitHub Actions-builds på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder og pakker gendannet fra caches, og eksporterer SBOM'er som CycloneDX eller SPDX.
Overvågede SBOM'er genvurderes løbende, og build-historikken viser, hvilke tidligere builds der indeholdt en sårbar afhængighed. Inventaroversigten viser, hvilke versioner der er udrullet til hvilke produkter, og sikkerhedsteams triagerer fund og sender dem til de teams, der ejer rettelsen. Se sårbarhedssporing og CRACI til PSIRT-teams.
PSIRT vs CSIRT: ofte stillede spørgsmål
Hvad er et CSIRT?
Et Computer Security Incident Response Team. FIRST definerer det som en organisatorisk enhed, som kan være virtuel, eller en kapacitet, der leverer tjenester og support til en defineret målgruppe for at forebygge, opdage, håndtere og reagere på computersikkerhedshændelser. Målgruppen kan være én virksomhed, en sektor eller et helt land.
Hvad er forskellen på et PSIRT og et CSIRT?
Et PSIRT håndterer sårbarheder i de produkter, en virksomhed sælger, og som dens kunder er eksponeret for. Et enterprise-CSIRT håndterer sikkerhedshændelser i virksomhedens egne systemer og netværk. FIRST kalder fokusset på produkter den vigtigste forskel mellem de to.
Er et CERT det samme som et CSIRT?
Funktionelt, ja. CERT er et mærke, der er registreret i USA af Carnegie Mellon University, hvis CERT Coordination Center var det første team af sin slags, oprettet i 1988 efter Morris-ormen. CSIRT er det generiske begreb. Mange nationale teams bruger CERT i deres navn, og EU bruger CSIRT i sin lovgivning.
Hvad er forskellen på et SOC og et CSIRT?
Et SOC overvåger og opdager døgnet rundt: Det holder øje med alarmer og logs og eskalerer det, der ser reelt ud. Et CSIRT ejer reaktionen på bekræftede hændelser: inddæmning, undersøgelse, koordinering og gendannelse. I mange organisationer overlapper de to eller deler personer, og SEI bemærker, at det vigtige er, hvilke funktioner et team udfører, ikke hvad det hedder.
Har vi brug for både et PSIRT og et CSIRT?
Hvis du sælger software eller enheder og også driver din egen IT, har du brug for begge funktioner, men ikke nødvendigvis to afdelinger. I en lille virksomhed dækker de samme få personer ofte begge dele, med separate processer: én for hændelser i dit miljø og én for sårbarheder i det, du leverer.
Hvad gør et nationalt CSIRT?
Det håndterer hændelser for en national målgruppe, deler advarsler og koordinerer på tværs af grænser. Under NIS2 udpeger hver EU-medlemsstat mindst ét CSIRT, og et af dem fungerer som koordinator for koordineret offentliggørelse af sårbarheder: en betroet mellemmand mellem den, der rapporterer en sårbarhed, og producenten.
Vid, hvilke builds der indeholder en sårbar komponent
Når en advisory udsendes, skal dit PSIRT vide, hvor komponenten leveres. Book en demo, og se det ud fra en registrering af, hvad hvert build hentede.
Book en demo