För några veckor sedan introducerade jag dig till NIST Cyber Security Framework (CSF) och för några dagar sedan MITRE ATT&CK. När jag skrev om CSF läste du om profiler och hur dessa kan användas. Denna artikel är en mer konkret demonstration av dessa profiler.

Betrakta den här artikeln som någon slags uppföljnings del i artikelserien om CSF.

Innan vi börjar

Ett nödvändigt komplement till den här artikeln är basprofilen jag skapat, du kan ladda ner filen (PDF) här:

I basprofilen beskriver jag två skyddsförmågor som jag anser bör vara grundläggande för ett effektivt skydd mot diverse cyberangrepp. Nej, det handlar inte om att dokumentera dina mest skyddsvärda tillgångar, genomföra riskanalyser eller klassificera din information. Istället har jag valt att fokusera på förmågor som kan härledas till hur cyberangrepp genomförs idag.

Detta är en första version av basprofilen och jag ser framför mig att den utökas och förändras allt eftersom. Initialt kanske det inte ser så mycket ut men genom dessa förmågor och de specifika åtgärder jag rekommenderar anser jag att ni ges goda förutsättningarna att skapa ett bra skydd mot flera typer av cyberangrepp.

Basprofilen

I den här första versionen av basprofilen finns det två förmågor. Jag har medvetet endast inkluderat två eftersom jag tycker det är viktigt att visa hur vi stegvis kan bygga upp en profil. Det behöver inte alltid vara en big-bang, allt på en och samma gång. Förmågorna jag beskriver är:

  1. Förmåga att skydda integriteten på ditt nätverk
  2. Förmåga att hantera rättigheter och åtkomstkontroll.

Förmåga 1 – Integritet på nätverket

Förmåga (1) handlar om att vi ska ha “koll” på vårt nätverk. Inga “okända” kommunikationsflöden ska förekomma. Tänk så här. En användare surfar genom en webbläsare; port 53, 80 och 443 kommer att förekomma från processerna som tillhör webbläsarna på klienterna. Det är ett flöde ni sannolikt kommer vilja tillåta. Kanske direkt mot Internet eller genom någon form av proxylösning. OBS: Det handlar alltså inte endast om kommunikation över port 53, 80 och 443. Det handlar om kommunikation från webbläsaren över dessa portar.

Väldigt många cyberangrepp använder skadlig kod för att genomföras. De flesta skadliga programvaror kommer i två delar, en så kallad downloader (stage1) och en payload (stage2). Syftet med stage1 är dels vara minimal ur programsynpunkt (få funktioner, liten storlek, enkel) och dels att ladda ner stage2. Men eftersom vi infört åtgärder om vilka kommunikationsflöden vi förväntar oss kommer stage1 att misslyckas. En process försöker initiera kommunikation mot en adress på internet. Det spelar ingen roll om det är en tidigare helt okänd skadlig programvara eller ej eftersom kommunikationsflödet inte är godkänt. Stoppar vi möjligheten till flödet oskadliggör vi samtidigt trojanen eftersom den inte lyckas ladda ner sin stage2 (payload).

Att skydda integriteten på nätverket innebär således att vi skyddar nätverket från att “innehålla” något som vi inte känner till. Denna förmåga har således i huvudsak till syfte av att skydda organisationen från skadlig kod och genom det väldigt många cyberangrepp. Det är inte nödvändigt att blockera den skadliga koden från att exekvera, det räcker med att blockera stage1 från att lyckas ladda ner stage1.

Förmåga 2 – Hantera rättigheter och åtkomstkontroll

När man nämner rättigheter och åtkomstkontroll tänker de flesta direkt på användare och deras behörigheter. Vad många glömmer är att även klientdatorer, servrar, applikationer och tjänster också är entiteter med rättigheter.

I den här förmågan beskriver jag åtgärder som avser två separata webbläsare för att implementera principen om separation of duties. Genom två webbläsare får du möjlighet att separera intern och extern kommunikation. Ni kan ha en webbläsare för extern kommunikation mot Internet och en webbläsare för intern kommunikation.

Det finns många fördelar med det här och nackdelarna är inte så påtagliga som många skulle kunna tro. Först och främst blir det mycket svårt för en angripare att lyckas med phishing genom länk. Tycker användaren på länken kan standardläget vara att öppna länken i den interna webbläsaren och det resulterar i… ingenting. Koppla samman detta med insamling av loggar för just den här typen av aktivitet så får ni möjlighet att identifiera potentiella phishing-försök. (Många kommer vara “false-positives” för användare som glömt att en länk öppnas i interna webbläsaren. Men i de fall ni fångar ett phishing-försök kommer ni glädjas åt att det inte lyckats!)

Förbättringsåtgärder i profilen

Det finns flera områden i profilen som kan förbättras och utökas. Exempelvis skulle vi kunna beskriva en slags täckningsgrad inom varje förmåga. Så här tänker jag. Att vi kontrollerar vilka applikationer som får kommunicera på en klient är givetvis inte full täckning på icke godkända kommunikationsflöden. Vi skulle även kunna kontrollera flöden från servrar, andra nätverkstjänster eller kanske t.o.m ner per användare.

Vi kan självklart utöka med fler specifika åtgärder och fler metrics. Det viktigaste är att vi får en utgångspunkt och allteftersom identifierar sådant vi kan förbättra och tydliggöra. Kanske nya typer av angrepp kräver nya förmågor eller åtgärder.

Sammanfattning

Profiler är en viktig del av CSF och kan visa, som jag försökt göra nu, grundläggande förmågor vi önskar att vår organisation ska ha. Profilen jag beskriver i den här artikeln består av två förmågor och specifika åtgärder som gör att vi erhåller förmågan (åtminstone delvis).

I nästa steg av artikelserien tänker jag mig att vi kanske fokuserar lite mer på mätbarheten av införande av förmågor eller åtgärder. Jag är inte helt säker på vad som är ett naturligt nästa steg. Berätta vad ni tycker skulle kunna vara lämpligt.