Flowchart for patch management (test, godkend, udrul i ringe)

Hvad er flowchart for patch management (test, godkend, udrul i ringe)?

Patch management er den stående cyklus, der forvandler en leverandørbulletin til en opdatering, der installeres, verificeres og dokumenteres på hvert eneste aktiv, den gælder for. Udløseren kommer udefra: en leverandør udgiver en rettelse, en sikkerhedsfeed bringer en bulletin, eller en scanning rapporterer en manglende opdatering, og uret starter, uanset om timingen passer. NIST's vejledning om planlægning af patch management i virksomheder rammer hele aktiviteten ind som forebyggende vedligehold for teknologi, hvilket er den ærlige beskrivelse af den — rutinearbejde med en deadline hæftet på. Diagrammet herunder følger én bulletin fra ende til anden: matchet mod aktivregistret, vurderet for eksponering og kritikalitet, sendt enten ad den akutte vej eller ind i den månedlige cyklus, testet mod den service, den berører, godkendt som en ændring, meldt ud, udrullet i ringe med en rollback-vej, derefter scannet igen, rapporteret og lukket.

Det her er patch-pipelinen, ikke det sårbarhedsprogram, der fodrer den, og ikke den ændringsproces, der godkender den. Sårbarhedsstyring ejer scanningsplanen, fundregistret, risikovurderingerne og udbedringsfristerne på tværs af enhver slags rettelse, hvoraf patching kun er én; når den beslutter, at en bestemt opdatering skal installeres, er dette diagram, hvad der sker derefter. Ændringsstyring ejer anmodningen, udvalget og kalenderen i almindelighed og optræder her som to trin snarere end som emnet. Software deployment dækker jeres egne build-artefakter, der bevæger sig fra en pipeline til produktion; patching flytter en andens binære fil ind på et system, I ikke selv har skrevet og ikke kan fejlsøge, hvilket er grunden til, at test og rollback vejer så tungt i dette diagram. Betragt det som et udgangspunkt, der skal tilpasses under jeres egne procedurer, lovkrav og en sikkerhedsvurdering, snarere end som en kontrol, I kan overtage uændret.

Fire beslutninger bærer processen. 'Akut patch eller rutinecyklus?' ligger i sikkerhedsbanen, fordi det er dem, der forstår eksponeringen, der bør sætte tempoet, og det er dét, der forhindrer, at rutinecyklussen bliver suspenderet, hver gang en bulletin larmer. 'Består patchen testen?' og 'Er pilotringen sund?' ligger begge hos applikationsejeren snarere end hos patch-administratoren, fordi det værktøj, der installerer en opdatering, ikke kan fortælle jer, om servicen stadig virker bagefter. 'Er risikoundtagelsen accepteret af ejeren?' er tegnet som en beslutning med en afvisningsgren med vilje: et system, der ikke kan patches, er en forretningsbeslutning med en ejer og en udløbsdato, ikke en sag, der stille ældes. Verifikationstrinnet til sidst lukker sløjfen, fordi en udrulningsrapport og en ren ny scanning er to forskellige påstande om den samme portefølje.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes (Sikkerhed / sårbarhedsteam, Patch-administrator, Ændringsansvarlig, Applikationsejer og Servicedesk / brugere) fordelt på seks faser: bulletin og omfang, vurdering og prioritering, testfase, godkendelse og planlægning, udrulning samt verifikation og rapportering
• Indtag, der starter med en bulletin frem for et scanningsresultat: sikkerhedsbanen matcher udgivelsen mod aktivregistret og besvarer "Berørte aktiver i porteføljen?", med en "Luk bulletinen som ikke relevant"-terminator, så et overvejet nej bliver registreret frem for antaget
• Kritikalitetsopdelingen ved beslutningen 'Akut patch eller rutinecyklus?', som sender en aktivt udnyttet fejl ad en fremskyndet vej og samler alt andet i den månedlige baseline, så den planlagte cyklus ikke suspenderes, hver gang en bulletin larmer
• En testsløjfe, intet værktøj kan genveje: patchen går til et testmiljø, applikationsejeren kører regressionstest og besvarer "Består patchen testen?", og en fejl lander på "Forventes leverandørens rettelse i tide?" frem for på et blindt nyt forsøg
• Godkendelse før udrulning: beslutningen 'Er ændringen godkendt til vinduet?' sender en tynd anmodning tilbage til at blive bearbejdet, ændringsansvarlig booker vedligeholdelsesvinduet, og servicedesk melder nedetiden ud, før noget installeres
• Ringudrulning med to udveje: "Er pilotringen sund?" sender en regression videre til "Udfør rollback-planen", "Bekræfter en ny scanning, at patchen er installeret?" jagter de aktiver, en udrulningsrapport overså, og et system, der ikke kan patches, ender i "Registrér en tidsbegrænset risikoundtagelse"

Hvornår du skal bruge skabelonen

• I skriver eller omskriver en procedure for patch management og har brug for ét billede af, hvem der vurderer, hvem der tester, hvem der godkender, og hvem der verificerer
• Patching bliver ved med at glide forbi sin deadline, og I har brug for at se, om den går i stå ved testen, ved ændringsudvalget eller ved vedligeholdelsesvinduet
• I konfigurerer patch-grupper, ringe og vedligeholdelsesvinduer i et administrationsværktøj og vil have processen aftalt, før værktøjet koder én for jer
• En dårlig opdatering lagde en service ned, og rollback'en blev improviseret, så rollback-udløseren og den person, der må kalde den, skal nu stå på diagrammet
• En auditor eller en kunde har spurgt, hvordan sikkerhedsopdateringer når jeres systemer, hvordan undtagelser godkendes, og hvordan I dokumenterer, at patches reelt landede

Sådan fungerer det

1. Omdøb banerne til jeres roller

   Erstat Sikkerhed / sårbarhedsteam, Patch-administrator, Ændringsansvarlig, Applikationsejer og Servicedesk / brugere med de roller, I reelt har. I et lille team er sikkerhedsanalytikeren og patch-administratoren ofte samme person, så læg de baner sammen frem for at tegne en overlevering, der aldrig sker. Hold applikationsejeren adskilt, for den bane er dér, testbeslutningerne bor.

2. Skriv jeres akutte udløser på triage-beslutningen

   Ved siden af 'Akut patch eller rutinecyklus?' skal I skrive, hvad der gør en patch akut, i vendinger en vagthavende ingeniør kan bruge: bevis for aktiv udnyttelse, et internetvendt aktiv, ingen brugbar workaround. En alvorlighedsscore beskriver fejlen, ikke jeres eksponering, så navngiv de andre input, I bruger — CISA's katalog over kendt udnyttede sårbarheder er et almindeligt et — og angiv, hvem der må træffe beslutningen uden for arbejdstid.

3. Sæt en udbedringsfrist pr. alvorlighedsbånd

   Skriv fristen for hvert bånd ved siden af vurderingstrinnet. Nogle er sat for jer: modtager I kortbetalinger, kræver PCI DSS, at kritiske sikkerhedspatches på systemer inden for scope installeres inden for én måned efter udgivelse, og alt andet inden for en tidsramme, I selv definerer og begrunder, og CIS Controls beder om automatiseret patching af operativsystemer og applikationer mindst månedligt. Vælg tal, I kan overholde i en dårlig måned.

4. Sig, hvad testmiljøet er, og hvad en bestået test betyder

   Angiv, hvad testmiljøet indeholder, hvor tæt det er på produktion, og hvad applikationsejeren reelt tjekker ved 'Består patchen testen?'. Navngiv de transaktioner, der stadig skal gennemføres, de grænseflader, der stadig skal autentificere, og de rapporter, der stadig skal køre. En patch, der installeres uden problemer og alligevel knækker et natligt job, har fejlet testen, og kun et navngivet tjek fanger det.

5. Definér ringene, modningstiden og vinduet

   Angiv, hvilke maskiner der sidder i pilotringen, og hvorfor de er repræsentative, hvor længe I venter, før I forfremmer til den næste ring, og hvilket vedligeholdelsesvindue hver ring bruger. Leverandører med en fast kadence gør det lettere at planlægge: Microsofts månedlige sikkerhedsopdateringer lander den anden tirsdag, med udenfor-serie-udgivelser, når noget ikke kan vente til den næste.

6. Aftal rollback-udløseren og undtagelsesreglen

   Beslut rollback-udløseren, før I får brug for den — hvilke symptomer, målt hvordan, og hvem der må kalde den uden at indkalde til møde — og skriv trinnene ved siden af 'Udfør rollback-planen'. Fastsæt derefter undtagelsesreglen: hvad en kompenserende kontrol skal opnå, hvem der må acceptere restrisikoen, den maksimale levetid for en undtagelse, og hvad der sker den dag, den udløber.

7. Prøv det af mod to reelle bulletiner

   Tag to nylige bulletiner, én rutinemæssig og én, I håndterede som akut, og følg begge gennem diagrammet. Hvert trin, nogen beskriver, men som ikke er tegnet, og hver boks, der i praksis bliver sprunget over, er et fund, det er værd at handle på, før I udgiver det. Læs derefter jeres undtagelsesregister op mod det: en aktiv undtagelse uden revisionsdato er dét hul, denne proces findes for at lukke.

Ofte stillede spørgsmål

Hvilke trin består en proces for patch management af?

En bulletin eller patch-udgivelse ankommer fra leverandøren eller en sikkerhedsfeed, og sikkerhedsteamet matcher den mod aktivregistret; en bulletin, der ikke rører noget i porteføljen, lukkes som ikke relevant frem for at blive ignoreret. Berørte aktiver vurderes for eksponering, udnyttelighed og kritikalitet, og patchen sendes enten ad den akutte vej eller ind i den månedlige baseline. Den udrulles til et testmiljø, og applikationsejeren kører regressionstest. En bestået test giver en ændringsanmodning med en rollback-plan; en fejlet test spørger, om leverandørens rettelse ventes i tide, og hvis ikke, overvejes i stedet en kompenserende kontrol og en tidsbegrænset undtagelse. Når ændringen er godkendt, bookes og meldes vinduet ud, patchen går til en pilotring og derefter til de resterende ringe. En ny scanning bekræfter, at den reelt landede, aktiver, der er gået glip af, jages, og cyklussen slutter med en compliance-rapport.

Hvad er forskellen på patch management og sårbarhedsstyring?

Sårbarhedsstyring er programmet: et aktivregister, en scanningsplan, fund der triageres og vurderes, udbedringsfrister efter alvorlighed, ejere tildelt og nøgletal rapporteret til ledelsen. Patch management er én af de måder, et fund bliver rettet på, og den største. Forskellen betyder noget i begge retninger. Ikke enhver sårbarhed har en patch, fordi konfigurationsændringer, deaktivering af en funktion, netværkssegmentering og versionsopgraderinger også lukker fund; og ikke enhver patch er drevet af en sårbarhed, fordi funktions- og stabilitetsrettelser kommer gennem den samme pipeline. I praksis deler de to et aktivregister og en risikovurdering og overleverer på ét enkelt punkt: sårbarhedsstyring beslutter, at denne opdatering skal installeres inden denne dato, og patch management er alt mellem den beslutning og en verificeret installation.

Hvor hurtigt bør sikkerhedspatches installeres?

Sæt frister efter alvorlighedsbånd og eksponering, og sæt tal, I kan overholde i en dårlig måned, frem for ambitiøse tal. Nogle er sat for jer. PCI DSS kræver, at kritiske sikkerhedspatches på systemer inden for scope installeres inden for én måned efter udgivelse, mens andre gældende patches installeres inden for en tidsramme, den ansvarlige enhed selv definerer og begrunder. CIS Controls beder om automatiseret patch management af operativsystemer og applikationer mindst månedligt. Amerikanske civile forbundsmyndigheder arbejder efter bindende CISA-direktiver med langt kortere, risikobaserede frister for sårbarheder i kataloget over kendt udnyttede sårbarheder; de direktiver forpligter ikke private organisationer, men kataloget er et nyttigt prioriteringsinput for alle. Uanset hvilke frister I vælger, bør I måle compliance ud fra en ny scanning frem for ud fra udrulningsværktøjets succesrapport.

Hvad gør I med systemer, der ikke kan patches?

Nogle systemer kan reelt ikke tage imod opdateringen: et apparat, leverandøren ikke længere supporterer, et instrument, hvis leverandør ikke har kvalificeret patchen, en applikation, hvis supportaftale forbyder ændringer, eller en maskine, hvis nedetid koster mere end den risiko, den bærer. Svaret er ikke at lade sagen stå åben. Indfør en kompenserende kontrol, der reducerer udnytteligheden af netop den svaghed — segmentering, fjernelse af den eksponerede service, strammere adgang, ekstra overvågning — og registrér en tidsbegrænset undtagelse, der navngiver kontrollen, restrisikoen, den person, der accepterede den, og datoen, den gennemgås. Vil ingen acceptere risikoen, flytter systemet over på en udskiftnings- eller udfasningsplan, hvilket er grunden til, at undtagelsesbeslutningen på dette diagram har en afvisningsgren. Undtagelser, der aldrig udløber, er dét, der får en portefølje til at ophobe permanent upatchede systemer.

Er patch management en ITIL-proces, og hvem godkender en udrulning?

Ikke under det navn. ITIL 4 beskriver 34 ledelsespraksisser frem for processer, og patch management er ikke én af dem; arbejdet ligger på tværs af change enablement, release management og deployment management, med information security management, der sætter risikoappetitten. Det er en navngivningspointe frem for en grund til at tegne noget om. Godkendelse til at installere på produktionssystemer kommer normalt gennem change enablement, hvilket er, hvad beslutningen 'Er ændringen godkendt til vinduet?' repræsenterer her. Den ordning, de fleste teams lander på, er en forhåndsgodkendt standardændringsmodel for rutinemæssig, testet patching, der følger en offentliggjort cyklus, en normal ændring for alt usædvanligt eller med stor konsekvens, og en akut ændringsvej for aktivt udnyttede fejl, hvor den akutte sag skrives op straks bagefter frem for at blive sprunget over.