loggproffs

av Tomas Carlsson

Införandet av logghantering är väl i princip som vilket annat teknikprojekt som helst? Man tittar lite på vilka loggkällor man har och sedan väljer man lämplig hårdvarulösning för att lagra loggarna på och så vips är det klart ?

I denna artikel tänker jag gå igenom hur jag tycker att man skall agera vid införandet av strukturerad logghantering och belysa några fallgropar som finns.

Jag vill bestämt hävda att teknik och produktval är något som kommer mot slutet av ett införande av logghantering. Om man tittar på teknik och framförallt produkter för tidigt så finns det en stor risk för att man låter de tekniska möjligheterna styra de verkliga behoven och omständigheterna.

Inledning
Att samla in loggar och lagra dessa utan att ha en tydlig ägare av loggarna, ett definierat syfte till att lagra loggarna och processer för hur loggarna skall hanteras, är helt meningslöst. Det enda det kommer att leda till är att datahallen är full av utrustning som drar massor av el och genererar växthusgaser som enligt WWF kommer att döda alla isbjörnar.

Så en första fas är att identifiera vilka behov, intressenter och ägare av loggar som finns. Det kan finnas krav både från externa parter (PCI, SOX etc) och från interna parter. Det viktiga är att man vet vilket syfte lagringen av loggar har. När man vet varför man vill lagra sina loggar så är nästa steg att fundera på vilka loggar som faktiskt finns att tillgå.

Syftet vs. befintliga loggar
Ett misstag som är lätt att göra är att titta på vilka loggar som genereras idag och sedan bygga logghanteringen runt detta. Vänd istället på detta och titta på vilka loggar man behöver för att uppnå sitt syfte med logghantering. En stor del av projektet kommer att handla om vilka loggar som finns, om och hur de kan anpassas för att uppnå syftet.

Exempel: Om behovet är att kunna ta fram rapporter på vilken användare som har surfat till vilken site på Internet, så måste alla användare autentiseras vid åtkomst av Internet så att användarnamn finns med i loggarna. Om autentisering inte är påslaget så måste (i detta exempel) först infrastrukturen anpassas så att målet med logghanteringen kan uppnås.

Juridiska aspekter
En annan punkt som måste adresseras tidigt är de juridiska aspekterna, loggar brukar alltid på något sätt relatera till människor och deras förehavanden. Det brukar alltid uppkomma konflikter mellan spårbarhet och integritet. Det man minst anar, t.ex. en IP adress, kan vara en personuppgift som måste hanteras enligt gällande föreskrifter. Ett tydligt syfte med att samla in loggar är ett måste för att kunna förankra logghanteringen hos jurister, myndigheter, fackföreningar med flera intressenter.

Användning
Det leder osökt in på ett annat mycket viktigt område, hur skall loggarna användas? Vem skall ha åtkomst till loggarna? Vilka behovs finns av att extrahera loggar ur logghanteringssystemet? Kan det finnas olika typer av loggar som olika intressenter skall ha åtkomst till?

Exempel: På företaget så är det personalavdelningen som utreder anklagelser om sexuella trakasserier, för att göra detta så måste handläggaren ha tillgång till loggar från diverse system. Vad händer om handläggaren själv kan söka i alla loggar eller får en fil med alla loggar när den som utreds är ekonomichefen? Kan man se vad ekonomichefen har gjort i koncernekonomisystemen? Blir handläggaren då en insider på börsen?

Exempel: En myndighet har anställda som åker runt i riket och genomför gryningsräder. På hotellet eller flygplatsen så kopplar dom upp sig och läser mail osv. Kan man då med ledning av IP adresserna i loggarna se vilken stad de är i? Och med ledning av det gissa sig till var nästa gryningsräd kommer att ske. I vilka loggar syns IP adressen, VPN loggarna, proxyloggarna? Kan registratorn maskera IP adresserna maskinellt, eller är det tuschpenna som gäller?

Innan man har allt detta klart för sig, dokumenterat och förankrat hos alla intressenter, så skall man nog inte gå vidare med införandet av logghantering utan i stället fokusera på att göra förarbetet. Risken är överhängande att projektet kommer att misslyckas, försenas, fördyras eller leverera något som ingen kan använda.

Klassificering
Det finns i princip alltid ett behov att kunna dela upp loggarna i klasserna lagringstid och åtkomst, sedan kan det finnas ytterligare klasser som kan behövas.

Som i exemplen ovan så kommer det uppstå frågor om hur man i systemet kan klassificera olika typer av loggar så att det går att söka effektivt. Kan man blanda loggar från hemliga och öppna system, hur söker man då effektivt? Här finns en stor fallgrop i form av att de flesta metoder för klassificering som finns idag baserar sig på tekniska faktorer så som fabrikat eller IP adress. Oftast är det ganska ointressant och väldigt resurskrävande att klassificera på det sättet.

Drömscenariot vore att logghanteringssystemet kunde göra klassificeringen baserat på de loggar som kommer in till systemet. Bäst av allt vore om klassificeringen kunde ske baserat på innehållet istället för trubbiga metoder så som avsändande system eller typ av logg.

Exempel: Vårt ekonomisystem består av ett antal Unix och Windows servrar, lite nätverksutrustning, ett SAN och en firewall. Vi vill då att logghanteringssystemet kan klassificera loggar så att det går att få en samlad bild vad som händer med ekonomisystemet. I många fall när man måste använda fabrikat/typ (windows, unix, firewall) eller IP adress i klassificeringen så kan man inte söka eller göra rapporter på ett effektivt sätt.

I dagsläget är man oftast tvungen att dela upp loggar mellan olika hårdvaror och lagringsytor för att möjligheten att ha olika lagringstider och olika åtkomstregler. Om då syfte eller användningsområde ändras så kan man behöva flytta enorma mängder loggar mellan olika system. I bästa fall så går det att flytta eller exportera loggarna så att den nya strukturen kan uppnås.

En annan del av förarbetet som måste göras är att ta ställning till om lagring av känslig data skall ske i sin helhet eller om man skall lagra endast delar av den. Det kan ju bli enklare att få acceptans för ett logghanteringssystem om känslig information inte lagras i sin helhet, t.ex. skall man lagra hela kontokortsnr, IP adresser, personnr eller skall delar blankas ut? Eller skall informationen lagras i sin helhet och döljas vid sökning?

Autenticitet
Detta leder osökt in på ett annat område som också är väldigt intressant, hur vet man att loggarna som finns lagrade i logghanteringssystemet inte har blivit manipulerade? De flesta som säljer logghanteringsprodukter kommer säga “JA!” när dom tillfrågas om deras produkter kan verifiera integriteten i loggarna som lagrats. Frågan är var, under loggens väg från att den blir skapad tills att den hamnar i logghanteringssystemet, som utgångspunkten för verifieringen fastställs.

Loggens väg kan grovt indelas i tre delar, genererande system, (nätverks-)transport och lagrande system. För att kunna fastställa loggens integritet redan i det genererande systemet så måste det finnas en komponent av logghanteringssystemet på det genererande systemet.

I de allra flesta produkter som finns tillgängliga på marknaden så utförs integritetskontrollen mot det ögonblick då loggen anlände till logghanteringssystemet. Rent tekniskt kan det vara så att loggen mellanlagras på logghanteringssystemet innan utgångsläget för integritetskontrollen fastställs.

Är det då viktigt att loggarnas integritet kan garanteras? Fråga 100 experter och få lika många svar. Det viktigaste är att det finns en tydlig dokumentation av exakt hur loggar hanteras under hela sin livscykel.

Implementering
Nu är det dags att starta med mer implementationsrelaterade frågor, och eftersom förarbetet är grundligt gjort så blir det enkelt att finna vilka loggkällor och typer av loggar som behövs för det fastställda syftet.

Under inventeringen som görs måste olika, mestadels, tekniska aspekter av loggarna fastställas,

- Finns loggarna?
- Vilket format har loggarna (ascii, binärt, codepage, 7/8 bit)?
- Med vilken frekvens genereras dom (realtid, dagligen, veckovis)?
- Hur är loggarna organiserade (syslog, nyckel/värde)?
- På vilket sätt överförs loggarna (nätverksström, filer)?
- Hur stora är loggarna, hur snabbt ökar volymen loggar?

Resultatet av inventeringen är underlag för implementationsplanen och de tekniska kraven på logghanteringssystemet.

Oftast så har någon loggkälla inte möjlighet att sända loggar i realtid över nätverket. Det innebär att logghanteringssystemet måste kunna hämta loggarna själv eller med hjälp av en hjälpprogramvara.

Det också viktigt att det går att anpassa logghanteringssystemet efter hur de egna loggarna ser ut, ibland kan det vara så att om man har ändrat något i en standardlogg t.ex. från en proxy så känns inte formatet alls igen. Det måste också vara enkelt att lägga till egna format.

Drift
Det är lätt att glömma en genomgång av hur logghanteringssystemet faktiskt skall driftas, en av de största utmaningarna är att upptäcka om en loggkälla slutar att skicka loggar eller plötsligt ändrar struktur.

Det är också nödvändigt att ta hänsyn till logghantering i den vanliga ändringsprocessen, det är lätt hänt att en uppgradering av en router eller proxy innehåller förändringar i hur loggarna ser ut eller på vilken detaljnivå loggning sker.

Systemkrav
De viktiga systemkraven på logghanteringssystemet som tidigare har listat är,

- Klassificering av loggar, ex. hemlig/publik, sökning/rensning baserat på klass.
- Stöd/anpassning för olika typer av loggar och olika metoder för att transportera dom.
- Utblankning av delar sökdata ex. kontokortsnr, personnr, ipadress i rapporter.

det viktigaste är dock att inte köpa ett system som låser in loggarna i ett proprietärt system, utvecklingen inom logghantering går mycket snabbt framåt.

Framtiden
Artikeln “How Rackspace Now Uses MapReduce and Hadoop to Query Terabytes of Data” är hisnande läsning om hur världens största ISP hanterar Terabytes av loggar per dag .

Logghantering är lite i sin linda vad det gäller kommersiella produkter, det skulle vara förvånande om det inte börjar dyka upp kommersiella produkter baserade på mapreduce/hadoop inom ett år eller så. Den som då har ett logghanteringssystem som inte kan exportera loggarna kommer troligen ha kastat pengarna i sjön.

Summering
Logghantering är som allt annat, gör man rätt så är det lätt. Om man fuskar med förarbetet och jobbar med utgångspunkt från vad tekniken kan idag så kommer det troligen att bli fel och isbjörnarna fortsätta att dö.

När väl logghanteringen är införd enligt konstens alla regler så möjliggörs all strukturerad behandling av loggarna. Loggar är nödvändig bas i händelsehantering (SIEM), drift, säkerhetsundersökningar med mera.

Detta inlägg postades Friday, 19 March, 2010 kl 14:53 i Tomas Carlsson. Du kan följa svar via RSS 2.0 flödet. Du kan lämna en kommentar, eller en trackback från din egen sida.