Detta är en artikel om CIS-kontrollerna, version 7 . I den här artikeln kommer du att läsa om hantering av loggar. Kanske skulle vi kunna betrakta detta som ett av de viktigaste åtgärdsområden som kan införas men samtidigt ett av det mest omfattande och kluriga områden som finns.
Välkommen till en artikel om Underhåll, hantering och analys av loggar. Nu börjar vi.
Nyckelinsikter
- Logga inte allt, det är inte en lösning
- Börja med att logga utifrån användningsfall, vad är det ni vill upptäcka?
- Etablera rutiner för hur ni inhämtar och analyserar loggar
- Centraliserad loggning är eftersträvansvärt men allting ska inte alltid loggas centralt.
Innehållsförteckning
- Inledning]
- Åtgärdsområdets målsättning
- Införande
- Steg 1 - Avgör mognad
- Steg 2 - Påbörja införande
- Steg 3 - Mäta effektivtet
- Sammanfattning
Inledning
Spåra, spårbar, spårbarhet… loggning?
Det finns en elefant i rummet och den heter spårbarhet, eller var det loggning? Loggning och spårbarhet, är det samma mynt, olika sidor eller helt olika mynt? Därom tvista de lärde… men jag tycker inte det finns särskilt mycket att jiddra om.
Spårbarhet är förmågan att spåra, att följa ett händelseförlopp. I sammanhang av informations- och it-säkerhet innebär spårbarhet förmågan att spåra händelser (åtkomstförsök, lyckade eller misslyckade, förändringar - ta bort, ändra, utöka) hos information, data, processer, funktioner, system.
Loggning är ett samlingsbegrepp för sådana åtgärder vi kan införa för att skapa spårbar information, system, data osv. Det finns digital såväl som analog loggning. Vi kan logga på systemnivå eller applikationsnivå. Det finns många olika typer av loggning, format och lagringsmöjligheter.
Jag skulle vilja påstå att loggning är en grundläggande åtgärd utan vilken få organisationer och företag kommer att nå en lämplig nivå av säkerhet.
Åtgärdsområdets målsättning
Syftet med detta åtgärdsområde är flerfaldigt. Du kan använda loggning för att upptäcka drift- och systemfel, intrångsförsök, handhavande fel osv. Det finns många möjliga användningsområden och det är också genom dessa möjligheter vi stöter på utmaningar.
Målsättningen med att etablera spårbarhet är att vi ska ge oss själva möjligheten att upptäcka, i tid, händelser som kan komma att negativt påverka vår verksamhet. I den bästa av världar ska spårbarhet även över tid leda till att vi kan förutspå händelser, och agera för att minimera eventuell skada innan den blir ett faktum.
Införande
Innan ni börjar är det, likt tidigare åtgärdsområden, dags att uppskatta er mognad avseende loggning.
Steg 1 - Avgör mognad
Ingen förmåga
Loggning? Jo, men visst… det är påslaget, eller?
Partiell förmåga
Inför upphandling eller nyutveckling ställer vi krav på/utreder förutsättningarna för spårbarhet i applikationen/systemet. Vi har ingen systematisk insamling, men har planer på detta. Det har diskuterats om ett införande av SIEM för säkerhetsövervakning men där är vi inte ännu.
God förmåga
Vi har ett SIEM, samlar in loggar från system, applikationer och operativsystem. Vi har förmåga att identifiera tokiga användargenererade aktiviteter som individuellt är legitima, men sammantaget innebär fulhet. Det finns givetvis förbättringspotential… som det alltid gör.
Denna mognadstrappa är inte avsedd att ge en uttömmande bedömning och klassificering av er mognad. Målsättning är att ni ska få en känsla för hur ni “ligger till” gällande samtliga CIS-åtgärdsområden. Inom vissa områden kanske helt saknar förmåga vilket kan vara anledning att fokusera på just detta område. Det är också precis vad denna mognadstrappa ska hjälpa er besvara. För varje område gör ni en snabb bedömning om mognad och avgör om ni ska fortsätta med införande av åtgärder inom området.
Steg 2 - Påbörja införande
Utifrån er mognad kan det finnas vissa delar av arbetet med loggning som kan vara mer eller mindre relevant och lämpligt. Eftersom jag både professionellt och personligen har ett mer attack- och angriparecentriskt fokus på mitt arbete med cybersäkerhet är det naturligt för mig att dels rekommendera det och dels börja där.
Ni kanske väljer att fokusera på aspekter inom tillgänglighet, eller som konsekvens av lagstiftning eller andra typer av föreskrifter och regleringar. Oavsett är det viktigt att ni väljer ett område och fokuserar på detta. Det finns viss risk för att arbetet blir alldeles för omfattande, eller att man gör nybörjarmisstag som att säga “vi loggar allt” och prioriterar alla händelser.
Nej. Nej, det gör ni inte.
Prioritet 1
NTP-server
En tämligen viktig egenskap hos loggar är tidsstämplar. Se till att ni har en NTP-server mot vilka ni ALLTID synkroniserar tid. Varje gång ni pillar i ett system, se till att den synkroniserar tid mot er interna NTP.
Prioritet n+1
Så här gör vi (ni):
- Identifiera drivkrafterna bakom införandet, varför fokuserar ni på loggning överhuvudtaget?
- Beskriv användningsfall som förklarar vad mer exakt det är ni avser upptäcka genom loggningen.
- Decentraliserat eller centraliserad hantering av loggar?
- Dokumentera rutiner för inhämtning i händelse av potentiell incident eller annan utredning.
Vilka är drivkrafterna bakom införandet?
Det första steget i införande av loggning är att beskriva er ambition. Varför vill ni ha loggning och vad är det ni avser upptäcka/identifiera med loggningen? Vilka är era drivkrafter bakom införandet?
Vilka användningsfall?
Vad är det ni egentligen vill upptäcka? Användningsfallen syftar till att i text beskriva vilka händelser ni avser upptäcka. Handlar det om att identifiera försök till intrång? Handlar det om att identifiera när användare läser ut stora mängder information? Användningsfallen syftar till at beskriva dessa användningsfall. De är inte specifika i exakt vilka fält som behöver finnas i en logg, de är mer abstrakta än så. De är en inriktning på loggningen.
Decentraliserad eller centraliserad logghantering
Givetvis vore det bäst ni inför en central logghantering, så är det. Men verkligheten kanske inte alltid tillåter detta och då kan ni behöva fatta er med en decentraliserad loggning. Vilka händelser genreras var och hur kommer ni åt dessa när de behövs?
Samtidigt är det inte alltid lämpligt att samla in all typ av logg centralt. Det kanske genererar alldeles för mycket data och istället blir ett slags “on-demand” inhämtning lämpligt. Tänk så här: var 10:e sekund görs en snapshop av vilka processer som exekverar på en datorklient och vilka nätverks anslutningar varje process har “i gång”. Detta är GULD ur ett forensiskt/incident-utredningsperspektiv. Samtidigt skulle det generera stora mängder data om allting hela tiden sparkas över till en central loggningsserver, särskilt om du har många användare (tänk 10,000+).
Dokumentera rutiner
Jag tycker att rutiner är underskattade. De behöver inte vara omfattande. Men se till att dokumentera hur ni gör för att logga in, hämta och behandla loggar från ett antal system när så behövs. Beskriv hur kollegan ska göra om du inte kan eller är tillgänglig. Rutiner ska finnas när du behöver göra ett jobb ofta, men inte tillräckligt ofta för att komma ihåg detaljerna för varje tillfälle.
Fokusområde - Säkerhetsloggning (inspiration)
Utan loggar är ni blinda. Är ni blinda blir det också svårt att upptäcka, stoppa och förebygga angrepp. Det finns vissa grundläggande källor som ni rimligen bör fokusera på först, exempelvis DNS-uppslag (Domain Name System) i kombination med datornamn/hostnamn samt vilken användare.
Detta ger er möjlighet att upptäcka en rad spännande aktiviteter. Kommunikation mot C2-servrar, kommunikation mot kända och okända domäner. Saknar du DNS-loggar kommer du missa många hemskheter på ditt nätverk och framförallt tappar du förmågan att reagera på suspekt kommunikation. Kort och gott, genom DNS-logg kommer du att se mycket.
Steg 3 - Mäta effektivitet
Och så det här med mätning. Jag har sagt det förr, och säger det igen. Det är inte enkelt att mäta effektivitet när syftet är att mäta något som är värt att veta. Här kommer några förslag på mätningar som kan vara relevanta att göra när ni mäter loggning:
- Hur lång tid (minuter, timmar, dagar) tar det från det att ni identifierat en konstig händelse till dess att ni bekräftat att händelsen ska uppgraderas till incident eller avfärdas?
- Utifrån dokumenterade användningsfall, hur många incidenter uppstår per användningsfall?
- Utifrån incidenter per användningsfall, hur många av dessa resulterade i begränsade skadeeffekter?
Sammanfattning
Logg-hantering är ett omfattande område som sträcker sig från den yttersta perimetern bort till legitima användargenererade händelser i ett system djupt inne i organisationens hjärta. Identifiera drivkraften bakom viljan att införa loggning/spårbarhet, dokumentera användningsfall och arbeta utifrån dessa användningsfall. Tro inte att loggning är en på/av-brytare och att logga allt är en bra lösning.