ISO 27002:2022, Kontrol 8.8 – Håndtering af tekniske sårbarheder

Ejerskab af kontrol 8.8

Kontrol 8.8 omhandler teknisk og administrativ styring af software, systemer og ikt-aktiver. Nogle af retningslinjerne involverer implementering af en meget detaljeret tilgang til softwareadministration, asset management og netværkssikkerhedsrevision.

Som sådan bør ejerskabet af Kontrol 8.8 ligge hos den person, der har det overordnede ansvar for at vedligeholde organisationens IKT-infrastruktur, såsom IT-chefen eller tilsvarende organisatorisk.

Vejledning – Identifikation af sårbarheder

Inden implementering og sårbarhedskontroller er det vigtigt at få en komplet og opdateret liste over fysiske og digitale aktiver (se kontrol 5.9 og 5.14), som ejes og drives af organisationen.

Oplysninger om softwareaktiver bør omfatte:

• Leverandørnavn
• Ansøgningens navn
• Versionsnumre i drift
• Hvor softwaren er implementeret på tværs af godset

Når organisationer forsøger at lokalisere tekniske sårbarheder, bør de:

1. Skitsér tydeligt, hvem (inden for organisationen) er ansvarlig for sårbarhedshåndtering fra et teknisk perspektiv i overensstemmelse med dens forskellige funktioner, herunder (men ikke begrænset til):
• Asset management
• Risikovurdering
• Overvågning
• Opdatering
2. Hvem er ansvarlig for softwaren i organisationen
3. Vedligehold en fortegnelse over applikationer og ressourcer, der vil blive brugt til at identificere tekniske sårbarheder.
   

4. Bed leverandører og leverandører om at afsløre sårbarheder ved levering af nye systemer og hardware (se kontrol 5.20), og specificer som sådan i alle relevante kontrakter og serviceaftaler.
5. Gør brug af sårbarhedsscanningsværktøjer, herunder patchingfaciliteter.
6. Udfør regelmæssige, dokumenterede penetrationstests – enten internt eller via en certificeret tredjepart.
7. Vær opmærksom på brugen af ​​tredjeparts kodebiblioteker og/eller kildekode til underliggende programmatiske sårbarheder (se kontrol 8.28).

Vejledning – Offentlige aktiviteter

Ud over interne systemer bør organisationer udvikle politikker og procedurer, der opdager sårbarheder på tværs af alle deres produkter og tjenester, og modtage sårbarhedsvurderinger i forbindelse med leveringen af ​​de nævnte produkter og tjenester.

ISO råder organisationer til at gøre en offentlig indsats for at spore eventuelle sårbarheder og tilskynde tredjeparter til at engagere sig i sårbarhedshåndteringsindsats ved brug af dusørprogrammer (hvor udnyttelser søges efter og rapporteres til organisationen for en belønning).

Organisationer bør gøre sig tilgængelige for offentligheden gennem fora, offentlige e-mail-adresser og forskningsaktiviteter, så den bredere offentligheds kollektive viden kan bruges til at beskytte produkter og tjenester ved kilden.

Hvor der er truffet afhjælpende foranstaltninger, der påvirker brugere eller kunder, bør organisationer overveje at frigive relevant information til de berørte personer eller organisationer og samarbejde med specialiserede sikkerhedsorganisationer for at formidle information om sårbarheder og angrebsvektorer.

Derudover bør organisationer overveje at tilbyde en automatisk opdateringsprocedure, som kunderne er i stand til at til- eller fravælge, baseret på deres forretningsbehov.

Vejledning – Evaluering af sårbarheder

Tilstrækkelig rapportering er nøglen til at sikre hurtig og effektiv afhjælpning, når sårbarheder opdages.

Når de vurderer sårbarheder, bør organisationer:

1. Analyser omhyggeligt eventuelle rapporter og beslut, hvilke handlinger der skal tages, herunder (men ikke begrænset til) ændring, opdatering eller fjernelse af berørte systemer og/eller hardware.
2. Aftal en beslutning, der tager hensyn til andre ISO-kontroller (især dem, der er relateret til ISO 27002:2022) og anerkender risikoniveauet.

Vejledning – modvirkning af softwaresårbarheder

Softwaresårbarheder bekæmpes bedst med en proaktiv tilgang til softwareopdateringer og patchhåndtering.

Inden eventuelle ændringer implementeres, bør organisationer sikre, at eksisterende softwareversioner bevares, at alle ændringer er fuldt testet og anvendt på en udpeget kopi af softwaren.

Når man direkte adresserer sårbarheder, efter at de er blevet identificeret, bør organisationer:

1. Søg at løse alle sårbarheder på en rettidig og effektiv måde.
2. Hvor det er muligt, følg de organisatoriske procedurer for forandringsledelse (se kontrol 8.32) og hændelsesrespons (se kontrol 5.26).
3. Anvend kun opdateringer og patches, der stammer fra pålidelige og/eller certificerede kilder, især i vasen med tredjepartsleverandørers software og udstyr.
• Når det drejer sig om leverandørsoftware, bør organisationer foretage en vurdering baseret på de tilgængelige oplysninger om, hvorvidt det er nødvendigt at anvende automatiske opdateringer (eller dele heraf) til erhvervet software og hardware.
4. Test eventuelle opdateringer, der er nødvendige før installation, for at undgå uforudsete hændelser i et driftsmiljø.
5. Søg at adressere højrisiko og forretningskritiske systemer som en prioritet.
6. Sørg for, at eventuelle afhjælpende handlinger er effektive og autentiske.

I tilfælde af, at en opdatering ikke er tilgængelig, eller problemer, der forhindrer en opdatering i at blive installeret (såsom omkostningsproblemer), bør organisationer overveje andre foranstaltninger, såsom:

1. Spørg sælgeren til råds om en løsning eller "klistergips"-løsning, mens udbedringsindsatsen øges.
2. Deaktivering eller stop af netværkstjenester, der er berørt af sårbarheden.
3. Implementering af netværkssikkerhedskontrol ved kritiske gateway-punkter, herunder trafikregler og filtre.
4. Forøgelse af det overordnede overvågningsniveau i overensstemmelse med den tilknyttede risiko.
5. Sørg for, at alle berørte parter er opmærksomme på sårbarheden, herunder leverandører og kunder.
6. Forsinke opdateringen for bedre at kunne evaluere de tilknyttede risici, især hvor driftsomkostninger kan være et problem.

Understøttende kontroller

• 5.14
• 5.20
• 5.9
• 8.20
• 8.22
• 8.28

Supplerende vejledning om kontrol 8.8

• Organisationer bør føre en revisionslog over alle relevante sårbarhedshåndteringsaktiviteter for at hjælpe med afhjælpende bestræbelser og forbedre procedurerne i tilfælde af en sikkerhedshændelse.
• Hele sårbarhedshåndteringsprocessen bør periodisk gennemgås og evalueres for at forbedre ydeevnen og identificere flere sårbarheder ved kilden.
• Hvis organisationen brugte software, der er hostet af en cloud-tjenesteudbyder, bør organisationen sikre, at tjenesteudbyderens holdning til sårbarhedshåndtering er i overensstemmelse med dens egen og bør udgøre en central del af enhver bindende serviceaftale mellem de to parter, herunder eventuelle rapporteringsprocedurer. (se kontrol 5.32).

Ændringer og forskelle fra ISO 27002:2013

ISO 27002:2022-8.8 erstatter to kontroller fra ISO 27002:2013:

• 12.6.1 – Håndtering af tekniske sårbarheder
• 18.2.3 – Teknisk overensstemmelsesgennemgang

27002:2022-8.8 repræsenterer en fundamentalt anderledes tilgang til sårbarhedshåndtering, end den er indeholdt i 27002:2013.

27002:2013-12.6.1 beskæftiger sig i vid udstrækning med implementering af afhjælpende foranstaltninger, når en sårbarhed er blevet identificeret, hvorimod 18.2.3 er begrænset til tekniske værktøjer (for det meste penetrationstest).

27002:2022-8.8 indeholder helt nye afsnit om emner som en organisations offentlige aktiviteter, hvordan sårbarheder identificeres i første omgang og den rolle, cloud-udbydere spiller for at sikre, at sårbarheder holdes på et minimum.

Samlet set lægger ISO større vægt på den rolle, som sårbarhedsstyring spiller i andre områder af 27002:2022 (især ændringsstyring), og går ind for en holistisk tilgang, der trækker i talrige andre kontroller og informationssikkerhedsprocedurer.

Hvordan ISMS.online hjælper

Vores platform er intuitiv og nem at bruge. Det er ikke kun for meget tekniske mennesker; det er for alle i din organisation. Vi opfordrer dig til at involvere medarbejdere på alle niveauer af din virksomhed i processen med at opbygge dit ISMS, fordi det hjælper dig med at opbygge et virkeligt bæredygtigt system.

Kontakt i dag for book en demo.