Detta är en artikel i en serie om CIS Controls version 7 och denna artikel handlar om förmågan kunna hantera konfigurationer för nätverksenheter, och då framförallt säkra konfigurationer av dessa olika typer av enheter. I grund och botten handlar det om att många nätverksenheter (e.g. brandväggar, routrar, switchar) överlämnas till kunden i ett tillstånd som många gånger inte är helt förenligt med säkerhet.
Nyckelinsikter
- Säker konfiguration börjar med kunskap och förståelse för de enheter ni har och deras möjligheter, och eventuella osäkra standard konfigurationer. Välj en enhet, sök upp erfarenhet/dokumentation kring enheten, gör något vettigt och exportera konfigurationen.
- Börja, gör det enkelt och eftersträva inte perfektion från början.
- Någonstans i framtiden kan ni eftersträva att dokumentera varje enskilt nätverksflöde med syfte, ansvarig och under hur lång tid flödet förväntas existera.
Inledning
Nätverksenheter behöver först och främst fungera för de flesta till vilka de levereras utan att de samtidigt ska behöva göra något aktivt för att få dem att fungera. Det talas om ett secure by default, men detta är sällan den verklighet vi lever i eller får levererad till oss. Det är en bunt nätverkstjänster som absolut inte behöver vara startade och även om de är startade är de osäkra från början, eller… det kunde vara bättre. Och eftersom nätverksenheter många gånger utgör första lagret av skydd är det också dessa enheter som får stå emot diverse angrepp som gissningsattacker osv.
Observera följande. Jag skriver i nästkommande stycke om exakt vilka kontroller som CIS-åtgärden förespråkar. Det är sällan jag håller med om dessa och också sällan jag skriver om exakt samma åtgärder. Jag håller mig vanligtvis inom samma ramar som åtgärden övergripande etablerat, men … jag avviker ganska kraftigt från de specifika kontrollerna. Främst därför att jag tycker de ibland är lite väl trivialiserande. De känns ibland något verklighetsfrånvarande och detta försöker jag balansera upp. Försöker är ordet…
Om CIS-åtgärden
Konfiguration av nätverksenheter, och då framförallt en säker konfiguration… detta är vad åtgärden i stort handlar om. Du ska för varje “viktig” nätverksenhet ha gjort en genomlysning av dess konfiguration och då med perspektivet på hur en given inställning påverkar säkerheten för enheten. Tjänster som inte används ska stängas av, förändringar ska noteras, utvärderas och hanteras. Ni ska ha en process för att hantera konfiguration av dessa enheter och kunna följa förändringar över tid och framförallt notera avvikelser och snabbt hantera förändringar som får en negativ påverkan på säkerheten i enheten. CIS-åtgärden består av totalt 7 kontroller:
- Upprätthåll en standardiserad och dokumenterad säkerhetskonfiguration för samtliga godkända nätverksenheter.
- Dokumentera nätverkstrafikflöden som ska tillåtas med motiv kring syfte, ansvarig och förväntad livslängd på flödet.
- Använd automatiserade verktyg för att verifiera konfigurationer.
- Installera de senaste uppdateringarna för enheterna.
- Systemadministration av enheter ska föregås av flerfaktors-autentisering.
- Använd dedicerade klienter för administration av nätverksenheter.
- Administrera nätverksinfrastruktur från ett dedicerat nätverkssegment.
Åtgärdens målsättning
Upprätta, inför och hantera aktivt konfiguration för enheter i nätverksinfrastrukturen genom att använda en rigorös och omfattande konfigurationshantering och förändringshantering med målsättningen om att förhindra angripare från att utnyttja sårbara tjänster eller inställningar.
Införandet
Steg 1 - Avgör mognad
Likt tidigare artiklar i den här serien försöker jag ge dig ett övergripande och grovt verktyg för att mäta er nuvarande mognad för just den här åtgärden. Tanken är att när jag avhandlat samtliga kontroller kommer jag att sammanfoga denna “mognads”-mätning för att ge er ett snabbt sätt att kalibrera er nuvarande position avseende CIS-åtgärderna och kanske en fingervisning på vad ni eventuellt skulle behöva fokusera på.
| Mognadsnivå | Kriteria |
|---|---|
| Ingen förmåga | Vi konfigurerar enheter så gott vi kan och det är mycket upp till ansvarig tekniker att sköta detta. Centralt konfigurationsrepo? Vad som händer om vi behöver byta ut enheten? … Vi löser det om det nu skulle hända… |
| Grundläggande förmåga | Det finns en ambition att bli bättre. Ansible, Chef, Puppet eller SaltStack… vi har funderat. Idag ett GIT-repo för de viktigaste systemen. Har provat att återställa några system. Vi försöker följa härdningsriktlinjer och annat som publiceras för de enheter vi använder oss utav. |
| God förmåga | De system som kan, är konfigurationsinventerade och testas regelbundet. Automatisering och annan magi, vi gör det. Vi skulle troligen kunna bygga om stora delar av vår nätverksinfrastruktur på några timmar om så skulle krävas. Vi har upprättat egna härdningsmallar för de flesta enheter vi äger. Säkerhet sitter i väggarna. |
Steg 2 - Påbörja införande
Som det nästan alltid gör handlar det om att börja och inte vara rädd för att det inte blev perfekt från start. Det är inte rocket-science direkt. Några dimensioner finns givetvis att beakta. Det är relativt enkelt att exportera en konfiguration från enhet, spara den någonstans och testa att importera samma konfiguration på en ny enhet och se att det fungerar. Men att sedan ta steget mot en fullständig systematisk konfigurationshantering kan vara lite knivigare. Men, så här skulle jag rekommendera att ni börjar:
- Någonstans behöver ni ha en redundant yta att spara saker. Åtkomsten till ytan behöver vara kontrollerad. Hur ni väljer att implementera det här spelar ingen roll. Ett krypterat GIT-repo, en NFS-share… ni avgör vad som är lämpligt och vad ni har möjlighet att använda.
- Välj ut en viktig enhet (ex. router). Genomför en analys av konfiguration, vad kan härdas, vad kan göras bättre? Vad säger officiella härdningsriktlinjer? Genomför, exportera konfiguration.
- Skapa en återkommande bokning i kalendern för ansvariga, genomför export och import (testa att de fungerar på en ny enhet).
- Upprepa 2-3 för samtliga “viktiga” enheter.
Detta är några relativt enkla första steg. Efter dessa kan ni satsa på automatisk export och överföring till ett centralt “repo”. Import och test bör ni kontinuerligt för att säkerställa att allting fungerar.
När ni börjar känna er mogna att manuellt hantera konfigurationer och härdningar skulle ni kunna börja kolla på verktyg för att automatisera problembilden och söka er mot tekniska lösningar.
Steg 3 - Mäta effektivitet
Med risk för att upprepa mig själv så är det svårt att mäta nyttan av att härda nätverksenheter, men samtidigt jag har några förslag/idéer.
- Skapa en baseline. Scanna av er yttre perimeter, dokumentera vad ni har tillgängligt eller “erbjuder” omvärlden.
- Genomför Steg 2.
- Skapa ny baseline, jämför med tidigare och notera skillnaden.
- Notera om det dyker upp någon CVE på någon av de tjänster som ni tog bort eller konfigurerade enligt åtgärden.
Ni skulle också kunna göra lite mer tråkiga mätningar som att se hur många enheter i er nätverksinfrastruktur som är aktivt härdade och inventerade i konfigurationshanteringen. Detta blir kvantitativa mätningar som kanske tappar mycket av bakgrunden, men givetvis har även dessa typer av kvantitativa värden sin plats i mätningarna av effektivitet.
Sammanfattning
Säkra konfigurationer för nätverksenheter börjar med att ni tar en enhet och börjar härda. Exakt hur och vart ni hittar den informationen beror givetvis på enheten, men det är första steget. Med denna åtgärd är målsättningen att ni får koll på nätverksinfrastrukturen och de enheter som ingår i denna. Ni ska upptäcka avvikelser från standardiserade konfigurationer och kontinuerligt genomlysa infrastrukturen för sådana avvikelser.
Men… jag tycker att ni först och främst ska försöka härda enheterna ni har. Spara ner konfigurationerna på ett lämpligt ställe och konstatera nu dessa konfigurationer som standard. Börja därefter sakta men säkert att införa en process för hur ni inför nya enheter och härdar dessa innan de tas i produktion.
Verkligheten säger också att det kommer dyka upp enheter ni inte har kontroll på eller plötsligt dyker upp på nätverket, och för detta finns det inga direkta genvägar. Se till att kontinuerligt inventera nätverket efter nya enheter som eventuellt är kopplade till den yttre perimetern.