Livscyklussen for sårbarhedsstyring hos softwareleverandører

Hvad er livscyklussen for sårbarhedsstyring?

Livscyklussen for sårbarhedsstyring er den gentagelige proces, en produktleverandør følger for at håndtere en sårbarhed i software, den leverer: modtage eller finde den, verificere den, finde ud af, hvad der er berørt, rette den, udgive rettelsen og informere kunderne. Hos en leverandør drives den som regel af et product security incident response team (PSIRT), mens engineering-teams laver rettelserne.

Denne side handler om leverandørsiden. It-sårbarhedsstyring, altså scanning og patching af de servere og laptops, en organisation kører, deler ordforrådet, men ikke de svære dele. En leverandør skal stå til ansvar for hver understøttet release, kunderne har i hænderne, og skal offentliggøre, hvad den fandt.

Livscyklussens stadier

1. Modtag eller opdag. Sårbarheder kommer fra eksterne forskere via dit disclosure-program, fra kunder, fra koordinatorer som nationale CSIRT'er og fra din egen overvågning: en ny CVE i en open source-afhængighed, et scannerfund eller en intern test. Log hver enkelt med et sporings-id, og bekræft modtagelsen over for eksterne rapportører.
2. Verificér og triagér. Genskab problemet, eller bekræft afhængighedsmatchet, afgør, om det er en sårbarhed i dit produkt, og vurdér, hvor alvorlig og hvor hastende den er. Luk det, der ikke er relevant, med en begrundelse, du kan vise senere. Prioriteringssignaler som EPSS og CISA KEV-kataloget hjælper med at rangere resten.
3. Vurdér berørte produkter og versioner. Find hvert produkt, hver release og hver understøttet branch, der indeholder den sårbare kode eller komponent, og hver kundeinstallation, der kører en af dem. Dette trin afgør omfanget af rettelsen og advisoryen.
4. Afhjælp. Det ansvarlige team udvikler og tester en rettelse: en opgraderet afhængighed, en kodeændring eller en afhjælpende foranstaltning som en konfigurationsændring, når en rettelse endnu ikke er mulig.
5. Udgiv rettelsen. Lever opdaterede versioner for hver berørt understøttet branch via en kanal, kunderne kan stole på.
6. Informér og offentliggør. Udgiv en advisory, der siger, hvad der er berørt, hvor alvorligt det er, og hvad man skal gøre, tildel eller henvis til et CVE-id, og kreditér rapportøren. Maskinlæsbare formater som CSAF og VEX lader kunderne behandle advisories automatisk.
7. Overvåg og lær. Hold øje med udnyttelse og nye oplysninger, opdatér advisoryen, og før den grundlæggende årsag tilbage til udviklingen, så den samme type fejl ikke leveres igen.

ISO/IEC 30111 og ISO/IEC 29147

To internationale standarder beskriver denne livscyklus for leverandører. De deler den ved organisationens grænse:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Titel	Vulnerability handling processes	Vulnerability disclosure
Dækker	Det, der sker internt: verificering, undersøgelse, prioritering og afhjælpning	Grænsefladerne: at modtage rapporter og offentliggøre advisories
Centralt indhold	Politik og organisation, PSIRT'ets ansvar, håndteringsfaser, hensyn til forsyningskæden	Interessenters roller, håndtering af rapporter, indhold i advisories, koordinering, disclosure-politik
Målgruppe	Leverandører, der håndterer rapporterede sårbarheder	Leverandører, der modtager rapporter og offentliggør sårbarheder

Standarderne er lavet til at blive brugt sammen. ISO/IEC 30111 nævner seks håndteringsfaser: forberedelse, modtagelse, verificering, udvikling af afhjælpning, release og efter release. Den kræver også overvågning af processen, fortrolighed om sårbarhedsoplysninger og opmærksomhed på forsyningskæden, fordi mange sårbarheder ligger i komponenter, du ikke selv har skrevet. Begge standarder er aktuelle udgaver, bekræftet ved deres seneste ISO-gennemgang, og er markeret til revision.

Andre rammeværker følger samme form. FIRST PSIRT Services Framework grupperer arbejdet i opdagelse af sårbarheder, triage og analyse, afhjælpning og offentliggørelse, og IEC 62443-4-1 omfatter håndtering af sikkerhedsopdateringer og defekter i sin livscyklus for sikker udvikling af industrielle produkter.

Roller

• PSIRT eller produktsikkerhedsteam: ejer processen, modtager rapporter, triagerer, koordinerer rettelser og offentliggør advisories. Se CRACI til PSIRT-teams, og hvordan et PSIRT adskiller sig fra et CSIRT.
• Produkt- og engineering-teams: ejer koden, udvikler og tester rettelserne og leverer releases.
• Release management: beslutter, hvilke understøttede branches der får en rettelse, og hvornår.
• Kundesupport og kommunikation: håndterer kundernes spørgsmål og advisoryens målgruppe.
• Juridisk afdeling: rådgiver om offentliggørelse, kontrakter og underretninger til myndigheder.
• Eksterne parter: rapportører, koordinatorer som CERT/CC eller et nationalt CSIRT, upstream-maintainers af berørte komponenter og kunder, der skal installere rettelsen.

Frister og SLA'er

Der findes ikke én påkrævet tidsplan. De fleste leverandører sætter interne mål efter alvorlighed og offentliggør de eksterne i deres disclosure-politik. En typisk struktur:

• Bekræft en ekstern rapport inden for få arbejdsdage.
• Triagér inden for få dage, så rapportøren og det ansvarlige team ved, hvor sagen står.
• Afhjælp efter en frist bestemt af alvorlighed og udnyttelse, kortest for kritiske fund og alt, der vides at blive udnyttet.
• Offentliggør, når rettelsen er tilgængelig, eller ved en aftalt frist, hvis rettelsen trækker ud.

Pres udefra sætter den ydre grænse. Forskere sætter ofte en frist for offentliggørelse (Google Project Zero giver leverandører 90 dage), og lovgivningen tilføjer sine egne: EU's Cyber Resilience Act kræver, at producenter afhjælper sårbarheder "uden forsinkelse", og fastsætter rapporteringsfrister for aktivt udnyttede sårbarheder (se hvad CRA kræver). Når en sårbarhed allerede bliver udnyttet, som ved en zero-day, kører hvert stadie med den korteste frist.

Hvor livscyklussen bryder sammen

De fleste forsinkelser ligger ikke i at skrive rettelsen. De kommer af ikke at vide, hvad du har leveret.

• Du ved ikke, hvilke releases der indeholder en komponent. En ny CVE lander i et bibliotek. Hvilke af sidste års releases indeholder det, og hvilke kunder kører dem? Uden en registrering pr. release bygger teams gamle tags igen eller gennemsøger repositories manuelt, og listen over berørte versioner i advisoryen er et gæt.
• Transitive afhængigheder. Mange sårbare pakker har du ikke selv valgt. De ankommer som transitive afhængigheder flere lag nede, så en søgning i dine manifester overser dem.
• Støj fra udviklingsafhængigheder. Scannere, der læser lockfiles, rapporterer testframeworks og build-værktøjer, der aldrig bliver leveret. Hver af dem koster triagetid og begraver de fund, der betyder noget.
• Komponenter uden for pakkehåndteringen. Binærfiler downloadet af build-scripts, base-images og leverandørkomponenter optræder slet ikke i en lockfile.
• Uklart ejerskab. Et fund, intet team ejer, bliver liggende. Triage er først færdig, når rettelsen har en ejer.
• Rettelser, der ikke holder. En sårbar version kommer tilbage gennem en anden afhængighed eller en gammel branch, fordi intet forhindrer den i at komme ind i det næste build.

Målepunkter

Målepunkt	Hvad det viser
Tid til bekræftelse	Om rapportører får svar, når din politik lover det
Tid til triage	Hvor længe et fund venter, før nogen ved, om det betyder noget
Tid til afhjælpning, efter alvorlighed	Hvor hurtigt rettelser leveres, målt fra modtagelse til en tilgængelig release
Tid til advisory	Hvor længe kunderne venter på information efter rettelsen
Andel inden for mål	Om interne SLA'er holder, især for kritiske og udnyttede fund
Backlog efter alder	Fund, der sidder fast, og hvor
Andel ikke berørt	Hvor meget triagearbejde der går til fund, der ikke er relevante

Mål hvert stadie for sig. En lang tid til afhjælpning viser sig ofte at være en lang tid til at finde de berørte releases.

Kør livscyklussen på en registrering af det, du har leveret

Hvert stadie efter triage afhænger af at vide, hvad der er i hver release. CRACI kører dine 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 kan eksporteres som CycloneDX eller SPDX.

CRACI genvurderer løbende overvågede SBOM'er og samler dem på tværs af builds og repositories, og leverandør-SBOM'er kan tilføjes, så indkøbte komponenter overvåges side om side med dine egne. Når en ny CVE dukker op, viser build-historikken, hvilke tidligere builds der indeholdt den sårbare afhængighed, direkte eller transitiv, så du ved, i hvilken periode du var berørt, og inventaroversigten viser, hvilke softwareversioner der er installeret på hvilke produkter. Sikkerhedsteams triagerer fund i CRACI og sender dem til de teams, der ejer rettelsen, CRACI understøtter VEX, og policy gates kan blokere builds, der indeholder en bestemt CVE, så en rettet sårbarhed bliver ude. Se sårbarhedssporing.

Livscyklussen for sårbarhedsstyring: ofte stillede spørgsmål

Hvad er stadierne i livscyklussen for sårbarhedsstyring?

For en produktleverandør: modtage eller opdage sårbarheden, verificere og triagere den, finde de berørte produkter og versioner, udvikle afhjælpningen, udgive rettelsen, offentliggøre advisoryen og derefter overvåge og lære. ISO/IEC 30111 kalder faserne forberedelse, modtagelse, verificering, udvikling af afhjælpning, release og efter release.

Hvad er ISO/IEC 30111?

ISO/IEC 30111:2019 er den internationale standard for processer til håndtering af sårbarheder. Den giver leverandører krav og anbefalinger til at behandle og afhjælpe rapporterede sårbarheder i deres produkter og tjenester, fra politik og PSIRT'ets rolle til håndteringsfaserne og hensyn til forsyningskæden.

Hvad er forskellen på ISO/IEC 30111 og ISO/IEC 29147?

ISO/IEC 29147 dækker den udadvendte del: at modtage rapporter og offentliggøre advisories. ISO/IEC 30111 dækker den interne håndtering imellem: verificering, undersøgelse, prioritering og rettelse. De to er beregnet til at blive brugt sammen. Se koordineret offentliggørelse af sårbarheder for 29147-siden.

Hvad er triage af sårbarheder?

Triage er det trin, hvor et sikkerhedsteam bekræfter, at en rapporteret eller opdaget sårbarhed er reel, vurderer, hvor alvorlig og hvor hastende den er for dit produkt, og sender den til det team, der ejer rettelsen. God triage lukker også de fund, der ikke er relevante, med en registreret begrundelse.

Hvordan adskiller sårbarhedsstyring af produkter sig fra it-sårbarhedsstyring?

It-sårbarhedsstyring patcher de systemer, en organisation kører. Sårbarhedsstyring af produkter håndterer fejl i software, organisationen bygger og leverer til andre, så den tilføjer trin, it-teams ikke har: at finde ud af, hvilke udgivne versioner der er berørt, at levere en rettelse til kunderne og at fortælle dem om det i en advisory.

Hvilke målepunkter bør en proces til håndtering af sårbarheder følge?

Tid til at bekræfte en rapport, tid til triage, tid til afhjælpning og tid til advisory, hver efter alvorlighed, plus andelen af fund, der opfylder dine interne mål, den åbne backlog efter alder, og hvor mange fund der blev lukket som ikke berørt.