Patch Management Policy: En praktisk vejledning
Forsvar din organisation mod et hav af sårbarheder
This post is also available in:
English
Patching – denne meget nødvendige, men undertiden forsømte praksis med at løse sikkerhedsproblemer relateret til sårbarheder – kan være en byrde for organisationer i alle størrelser. Du ved sandsynligvis allerede, at en regelmæssig og veldefineret patch management rutine proaktivt sikrer, at dine systemer fungerer, som de skal. Det kan dog virke som en overvældende opgave på grund af antallet af systemer, der kræver dine medarbejders konstante opmærksomhed. Dette bringer os til emnet med patch management politik.
Bliv ved med at læse for at forstå, hvad en god patch management-politik indebærer, og hvordan du kan oprette dine egne patchprocesser og procedurer.
Hvad er Patch Management Policy?
En Patch Management Policy består af et sæt trin og procedurer, der sigter mod at håndtere og afbøde sårbarheder i dit miljø gennem en regelmæssig og veldokumenteret programrettelsesproces. Kort sagt indeholder en patch management policy retningslinjer og krav til korrekt håndtering af sårbarheder og involverer forskellige faser, såsom test, udrulning og dokumentation af sikkerhedsopdateringer, der anvendes til din organisations endpoints.
En sårbarhed vises, når en frigivet softwarekode er defekt, hvilket betyder, at ondsindede aktører kan udnytte den. En udnyttelseskode også følge, når en sårbarhed afsløres. Ofte offentliggøres og sælges udnyttelsessæt på undergrunds markeder eller offentliggøres som POC’er af sikkerhedsforskere, der forsøger at demonstrere, hvordan sikkerhedsfejl kan udnyttes.
En udnyttelse på zero days udnyttelse kan forekomme, når proof-of-concept-koden afsløres, inden en sårbarhed bliver rettet, hvilket betyder, at zero-days fejl opstår, efter at en sikkerhedsmæssig sårbarhed er opdaget, før sælgeren får muligheden for at løse det.
At offentliggøre POC-kode til zero-days udnyttelse har altid været problematisk, da det efterlader netværk sårbare, hvilket potentielt kan føre til en vellykket udnyttelse. Ifølge en nylig rapport har omkring to ud af hver tredje udnyttede sårbarhed, har en tilknytning til en offentliggørelse af en exploit code. Samtidig, når en exploit code offentligt afsløres, er chancerne syv gange større for at vi ser en udnyttelse, sammenlignet med at den ikke offentliggøres.
Jeg har også behandlet emnerne om opdagelse af sårbarhed og udnyttelser i min tidligere artikel med titlen Hvad er Vulnerability Management, så klik ind på den, hvis du er interesseret i at lære mere.
Komponenterne i en Patch Management-politik
Anbefalingerne nedenfor repræsenterer en patch management-framework, der involverer risikoidentifikations- og reduktionsteknikker, design og opsætning af en mekanisme, der opretholder patch standarden i en organisation.
En vellykket politik til patch Management skal føres på basis af flere forskellige faser. Nedenfor vil jeg liste seks faser, men afhængigt af størrelsen på en organisation og dens eksisterende processer kan det nøjagtige antal og rækkefølgen af trinene variere. Alligevel bør den grundlæggende procedure forblive den samme.
Her er de vigtigste trin, som enhver effektiv patch management-politik skal omfatte:
1. Aktivbeholdning
At have en aktivbeholdning på plads giver dig mulighed for at spore dine hardware- og softwareaktiver, der skal patches. På denne måde opdager du al installeret software på dine enheder samt identificerer alle de maskiner, der ejes af din organisation. Derfor vil du være sikker på, at alle potentielle sikkerhedshuller er lukket.
Desuden skal aktivopgørelse og sporing ledsages af kategorisering og rapportering, så du har detaljeret information om din hardware og software tilgængelig efter en scanning og dermed får fuld synlighed i dit miljø.
2. Tildel Patch Management-roller i dit team
Nøglen til patch effektivitet er at sætte de rigtige personer i ansvar, som vil være i stand til korrekt at håndtere patch management-relaterede aspekter. Alle i teamet skal have klart definerede roller og ansvar – alle involverede parter skal vide nøjagtigt, hvem der ansvarlig for hvilken proces. Derudover er det vigtigste aspekt, som du skal huske på, er aldrig at lade dine brugere tage sig af patchen selv.
3. Vælg den rigtige patch management software
Når du beslutter dig for, hvilken patch management software der passer til din organisation, er et vigtigt aspekt, du skal huske på, automatisering.
Ponemon Institute fandt ud af, at 56% af sikkerhedsprofessionelle bruger mere tid på manuelle processer end at reagere på sårbarheder, hvilket fører til et enormt efterslæb på respons. På samme tid bruger organisationer 18.000 timer på at administrere sårbarhedsrespons processer til en pris på 1,1 millioner dollars. Således vil automatisk patch management-software spare en betydelig mængde tid og penge og give dine sysadmins mulighed for at flytte deres fokus fra besværlige, manuelle opgaver til andre aktiviteter.
For eksempel vil HeimdalTM Securitys X-Ploit Resilience (tilgængelig som en enkeltstående løsning eller integreret i både Thor Foresight Enterprise og Thor Premium Enterprise) gøre det muligt for dine sysadmins at oprette politikker og automatisk installere patches til dine endpoints i henhold til en veldefineret tidsplan.
Etableringen af denne proces holder dine endpoints opdaterede uden administratorens involvering. Politikker kan oprettes ved at definere den type patches, du vil anvende – det glæder både OS og tredjeparts-patches.
Hvis du vælger manuel implementering af programrettelser, viser X-Ploit Resilience-dashboardet en liste med opdateringer, der allerede er installeret, de opdateringer, der er under installation, de opdateringer, der er tilgængelige for installation, samt det samlede antal af opdateringer (installeret, afventende og tilgængelig) pr. endpoint.
4. Test dine patches
Først skal du oprette et testmiljø, der er en replika af miljøet omkring de eksisterende systemer, der inkluderer servere, der dækker alle dine missions-kritiske programmer.
Hvis du har egenudviklet software, har du allerede servere, der understøtter testprocessen. Hvis du har en lille organisation, der ikke tillader testfasen at finde sted, skal du i dette tilfælde distribuere patches til de mindst kritiske servere, der let kunne gendannes i tilfælde af systemfejl. Dette betyder, at du på forhånd skal fastslå, hvilke servere og endpoints der er mindst kritiske, og derefter teste dine patches på dem. Hvis der ikke er nogen problemer, kan du fortsætte med at rulle dine patches ud til hele dit miljø.
Bare husk at selvom leverandører, der frigiver patches, tester dem, matcher de muligvis ikke dit miljø, så du skal også dække dette aspekt på din side.
5. Opret en patch plan
Ved at udvikle og implementere en patch plan for patchhåndtering vil du være sikker på, at al din software er opdateret og sikret mod fremtidige risici, samt at være i stand til at overvåge og beslutte, hvornår opdateringerne installeres. På denne måde vil dit it-personale være i stand til at holde dine systemer opdateret og sikre, og derved sikre at patches anvendes regelmæssigt.
6. Dokumenter din patching process
Det er meget vigtigt at holde et resumé og et overblik over din patches status. Takket være disse rapporter vil du have et komplet billede af patch status for hver bruger og se, om nogen af dine endpoints mangler et specifikt program.
Desuden er rapporter afgørende for, at du bliver fuldt compliant og i stand til at demonstrere detaljeret, præcis hvad der finder sted i dit miljø.
Hvorfor automatisering er afgørende
Patch management er ikke en simpel opgave, men med de rette ressourcer og værktøjer kan det blive lettere. Som en best practice for patch management skal du tage højde for, at automatisering er nøglen, når det kommer til patch management.
Ved at bruge software til patch management og fjerne de manuelle patches fra dine IT-teams aktivitet spilder dit personale ikke mere tid på langsomlige processer. Desuden kan en automatisk patch management-løsning forbedre kvaliteten af deres arbejde endnu mere, da den søger regelmæssigt efter manglende opdateringer og kontrollerer dem, der allerede er i drift. Det vil eliminere den indsats og byrde, der er forbundet med at udføre sådanne aktiviteter alene, og åbne ressourcer, der kan bruges til projekter af større betydning.
Ifølge Ponemon Institute-undersøgelsen oplevede 76% af virksomhederne et cyberangreb, der involverede et zero-days angreb. I din politik til patch Management vil det også være meget vigtigt at angive, hvordan man behandler patch i tilfælde af zero-days sårbarheder. Under sådanne omstændigheder vil timing tydeligvis ikke være på din side – du vil have en begrænset tidsramme til at handle. Igen vil en automatiseret patch management software hjælpe dig med hurtigt at installere patches, når de frigives.
Heimdal® Patch & Asset Management Software
- Schedule updates at your convenience;
- See any software assets in inventory;
- Global deployment and LAN P2P;
- And much more than we can fit in here...
For at opsummere
Da vulnerability-discovery-to-exploitation tiden bliver kortere, lægger dette en belastning på it-ledere til hurtigt at patche systemer og holde trit med de seneste opdateringer. Men ved at definere en ordentlig patch management policy spare du tid, penge og reducerer sikkerhedsproblemer. Hvad mere er, da automatiske patch management-systemer installerer patches med jævne mellemrum, fjerner man, de manuelle komponenter i patch management. Det vil også sikre, at softwarefejlene opfanges, så snart de opstår, og at de hurtigt kan rettes.
Det er klart, at patch management ikke løser alle sårbarhedsrelaterede problemer, men det vil fungere som en grundlæggende beskyttelsesmekanisme i dit samlede Vulnerability Management program.
Har du allerede en patch management-politik på plads? Hvordan håndterer du patching i din organisation? Gå til kommentarsektionen, og del dine tanker om patch management-politikker med os!