CIS Controls version 7 - Åtgärd 3 - Kontinuerlig hantering av sårbarheter - (3/20)

Friday, October 26, 2018

FörsvarVägledningCIS Version 7.0

Christoffer Strömblad

Entusiastisk Jedi inom Cybersäkerhet

Nyckelinsikter:

  • Dokumentera hur ni avser hantera information som kräver aktiva åtgärder avseende exempelvis uppdateringar eller konfigurationsändringar. Vem behöver göra vad, vem ska informeras, vem är ansvarig? Osv.
  • Identifiera brister genom kontinuerlig sårbarhetsscanning, icke-autentiserad såväl som autentiserad
  • Prioritera brister utifrån riskbedömning om hur bristerna påverkar verksamheten
  • Inför verktyg för automatisk uppdatering av operativsystem, och även för tredjepartsprodukter

Vid införande av sårbarhetsscanningsverktyg finns det tendenser till att fokusera på verktygen. Notera att dessa verktyg endast är identifierande, de gör ingenting åt identifierade brister. Det är därför viktigt att först ha en plan för hur ni vill hantera uppdateringar eller annan information som kräver någon form av aktiv åtgärd. Det är föga meningsfullt att samla på sig massa information om brister om de aldrig åtgärdas.

Likt föregående inlägg har jag skapat en uppdaterad CSF-profil som du kan använda för att strukturera och få en slags plan på införandet. 

NIST CSF Profil - Grundläggande åtgärder - CIS Controls version 7 - Åtgärder 1 till 3 Ladda ner

Åtgärdsområdets målsättning

Inom ramen för det här åtgärdsområdet ska du kontinuerligt inhämta, bedöma och agera på information som avser eventuella sårbarheter i företagets olika operativsystem, plattformar, system, applikationer osv. Målsättningen är att minimera den tid en angripare har möjlighet att utnyttja identifierade brister.

Åtgärder inom det här området avser exempelvis automatiska sårbarhetsscanningar (icke-autentiserad så väl som autentiserad), verktyg för patch-hantering och riskprioritering.

Införande

Likt tidigare inlägg fortsätter jag använda strukturen om en logisk följd av steg som är rimliga utifrån ett införandeperspektiv.

Strukturen är enligt nedan:

  1. Avgöra organisationens mognad avseende åtgärdsområdet
  2. Påbörja införande av de “enklare” åtgärderna. Gå till steg 4 för att initiera mätning av införandet och åtgärdernas effekter
  3. När ni är tillbaka från steg 4, fortsätt införandet med de mer avancerade åtgärderna.
  4. Mäta effekter av åtgärderna

Steg 1 - Avgör mognad

Ni bör rimligen börja med att avgöra mognad för åtgärdsområdet innan ni påbörjar eller fortsätter ett pågående införande. Målsättningen med mognadstrappan är dels att bidra till en överblick på de olika förmågorna (åtgärdsområdena) och dels ge förutsättningarna att kunna prioritera vilka åtgärder som ska införas. 

Det kan också användas som ett rapporteringsverktyg uppåt i kedjan för att kunna ge en hint om organisationens cybersäkerhet och förmåga att värja sig mot hot och hantera risker.

Mognadsnivå Kriteria
Ingen förmåga Vi gör i princip ingenting inom åtgärdsområdet, det kan bara bli bättre.
Partiell förmåga Vi har påbörjat och delvis infört åtgärden automatisk sårbarhetsscanning men har ännu ingen strukturerad process för att hantera resultaten från dessa scanningar.
God förmåga Vi har förmåga att genomföra icke-autentiserad och autentiserad sårbarhetsscanning, utför den från ett externt så väl som ett internt perspektiv. Vidare har vi en systematisk process för att hantera resultaten och gör kontinuerligt riskbedömningar för att prioritera vilka system som ska uppdateras först och i vilken ordning.

Om ni gillar idéen av en mognadstrappa per åtgärdsområde kan jag se till att varje framtida (och existerande) inlägg får detta också. Jag sammanställer sedan dessa i ett separat inlägg/dokument som kan laddas ner för att göra en snabb kartläggning.

Steg 2 - Påbörja införande

Beroende på var ni befinner er i mognadstrappan har ni lite olika vägar att gå. Att utföra sårbarhetsscanning är endast en identifierande åtgärd, det kräver trots allt att ni också agerar på informationen. Så även om det kan kännas naturligt att direkt gå ut och börja leta verktyg för automatisk sårbarhetsscanning skulle jag istället rekommendera följande.

  1. Dokumentera en process för hur ni avser hantera uppdateringar eller annan typ av information som kräver någon form av aktiv åtgärd. När ni identifierar en sårbarhet, eller information som på annat sätt behöver ageras på, hur gör ni? Vet ni vem som äger vad och hur ansvarsfördelningen ser ut för eventuella delsystem? När ni vet detta, eller åtminstone har en känsla för detta är det rimligt att gå vidare.
  2. Skaffa verktyg för sårbarhetsscanning och detta kan vara knepigt. Främst för att säkerställa att det inte blir en silo-produkt, som försöker göra allting själv. Det viktiga (bland mycket annat), anser jag, är att verktyget ska vara tämligen öppet genom exempelvis trevliga API:er osv.

Detta är en bra början. När ni lyckats genomföra de här två, ändå relativt stora, aktiviteterna är det dags att börja mäta effekterna av detta. Så fortsätt ner till steg 4 innan du går till steg 3.

Steg 3 - Fortsatt införande

I detta steg är tanken att ni fortsätter införandet av övriga åtgärder som finns inom ramen för detta åtgärdsområde. 

  1. Inför autentiserad sårbarhetsscanning så att en scanner har möjlighet att logga in på målsystem. Detta innebär exempelvis att verktyget måste få möjlighet att logga in på servrar för att inventera installerade programvaror, patchar eller annan relevant information.
  2. Installera verktyg för automatisk uppdatering av programvaror dels för operativsystem och dels tredjepartsprodukter. 
  3. Inför en process för att göra riskbedömningar avseende identifierade sårbarheter som metod för att kunna prioritera vilka system och andra applikationer som behöver uppdateras först och i vilken ordning.

Steg 4 - Mäta effektivitet

Dags att mäta, här kommer några förslag på mätningar ni kan göra för att få känsla för hur pass väl era rutiner och verktyg fungerar.

  1. Från det datum då en patch finns tillgänglig för en sårbarhet hur lång tid tar det för er organisation att bedöma risken för sårbarheten?
  2. Från det datum då en patch finns tillgänglig hur lång tid tar det innan den är applicerad, testad och inflyttad till produktionsmiljö?
  3. Hur många identifierade kritiska sårbarheter är äldre än 30 dagar?
  4. Hur många identifierade sårbarheter, som bedömts enkla att exploatera, kan kopplas till er externa miljö? (E.g. publika hemsidor, applikationer eller andra typer av system, brandväggar, routrar osv.)
  5. Hur många sårbarheter påverkar, av verksamheten bedöma, kritiska system eller applikationer?

Sammanfattning

Åtgärdsområdet avser kontinuerlig sårbarhetsscanning. Det viktigaste i sammanhang av det här är att ha en plan på hur ni faktiskt avser hantera informationen som identifieras genom de här verktygen.

Lycka till, hör av er om något är oklart. Och vill ni diskutera lite mer praktisk erfarenhet av sådana här verktyg… hör av er!

FörsvarVägledningCIS Version 7.0

Christoffer Strömblad

Entusiastisk Jedi inom Cybersäkerhet

Har du läst dom här?

Cyberperspektivet på en Säkerhetsskyddsanalys

CIS Controls version 7 - Åtgärd 2 - Inventering och hantering av mjukvara - (2/20)