When you purchase a car nowadays, you want not only the best you can afford, but also a bit of personalisation. You choose your colour, what type of sound system, electric seats, sun roof, and if you are lucky enough to live somewhere sunny, maybe choose a convertible model.

It’s the same with anything you buy today, the product can be personalised to suit your individual needs and requirements; If you go to McDonalds and say “I want extra cheese in my big Mac” you get it; in Starbucks ask for “extra cream in that coffee” and you get it; on your iphone if you want to change the background, you can. In short every person, and business have different requirements, so how can a standard solution fit them all?

LogLogic provides a quality engine at the core of its solution suite. It has a deserved reputation as being THE enterprise log management solution. If you need the Ferrari of Log Management solutions – LogLogic is it.

On top of that we have solutions that solve different business needs; Security Event Manager, Database Security Manager, and Compliance Manager. The unique thing is that we provide access to all that lovely log information via our Web Services API.

It means that if you want a blue and white dashboard, with a pink monkey running across your screen alerting you to issues, with a loud neigh, on your network, databases, or applications you can have it. You can create anything you want via the API, and it’s free! The great thing is that the business will never even have to see raw logs, or hear about Log Management; they’ll just see that pink monkey racing across the screen!

So you want to try this out? Well all you have to do is download our evaluation Vmware image, and our sample API dashboard from the LogLogic developers portal, http://www.loglogic.com/Virtual-Appliance, and http://open.loglogic.com/forum/sample-loglogic-api-realtime-dashboard , and away you go.

Personalising Log Management to specifically solve business issues……now there’s a shock!

Som jag skrev tidigare så har Joel Snyder (tillsammans med LogLogic) skrivit en checklista att använda vid upphandlingar av Security Information Management system och loghanteringssystem.

Här tänkte jag sammanfatta och översätta hans slutsatser runt första punkten på checklistan, Datainsamling och Arkivering.

Men en slutsats jag drar, och säkert flera med mig, är att första punkten alltid måste vara utred behoven och förväntningarna, att börja i den tekniska ändan kommer alltid att sluta i tårar!

Datainsamling

Majoriteten av alla loggmeddelanden kommer typiskt via SYSLOG – en standard för överföring av loggmeddelanden via nätverk. Om era logghanteringsbehov bara kräver SYSLOG så bör valfritt logghanteringssystem fungera utmärkt.

Problem uppstår typiskt när man skall lägga till Windows Event Log data – något som inte alla logghanteringssystem stödjer, och att lägga till stöd för detta kan bli krångligt. Om behovet finns så bör detta utredas innan beslut fattas.

Se till att identifiera de källor som ni förväntas samla data ifrån och kontrollera ifall logghanteringssystemen i fråga hanterar dessa eller ifall ni måste handskriva egna importverktyg.

Sedan varierar metoderna och verktygen man använder för att läsa in de loggtyper som logghanteringssystemet inte hanterar från början. Ju fler handskrivna loggradsimporter man blir tvungen att skriva själv, desto viktigare är det hur pass kraftfulla och lättanvända dessa verktyg är.

Arkivering

Vissa logghanteringssystem hanterar arkivering medan andra ser sig som en steg i kedjan, där någon annan är ansvarig för arkivering. Vilket som är rätt eller fel kommer att utgå ifrån era krav.

Gör beräkningar på hur mycket data som kommer att genereras och under hur lång tid det kommer lagras för att kunna bedöma vilka lagringsbehov ni kommer att ha.

Mer information finns här

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.

Utred behov och förväntningar

Som jag skrev tidigare så har Joel Snyder (tillsammans med LogLogic) skrivit en checklista att använda vid upphandlingar av Security Information Management system och loghanteringssystem.

Här tänkte jag sammanfatta och översätta hans slutsatser runt första punkten på checklistan, Datainsamling och Arkivering.

Hans lista hade som första punkt “Datainsamling och arkivering”, men en slutsats jag drar, och säkert flera med mig, är att första punkten alltid måste vara utred behoven och förväntningarna, att börja i den tekniska ändan kommer alltid att sluta i tårar!

Vilka behov har organisationen? Behöver ni ett SIM/logghanteringssystem för att uppfylla ett lagkrav eller ett compliancekrav så är det förhållandevis enkelt att bestämma behoven, annars kan det bli svårare. Men även med lagkrav i ryggen kan det finns behov utöver de lagstadgade? Å andra sidan, som jag skriver senare, försök inte beta av alla krav i hela organisationen samtidigt…

En typisk organisation kommer ha fler målsystem än anställda; arbetsstationer, fysiska servrar, virtuella server, nätverkskomponenter, passersystem, Intrusion Prevention Systems, brandväggar etc. Behoven kommer ge vilka av dessa system som behöver samlas in! Alltså; utred behoven innan ni börjar med tekniken.

Utred också förväntningarna ifrån verksamheten – förväntar sig någon att få rapport X så måste man antingen samla in den information som behövs för rapport X, eller informera berörda parter att rapport X inte kommer gå att generera. Felaktigt ställda förväntningar hos organisationen kan få en fantastiskt lyckad installation att upplevas som fullständigt misslyckad hos organisationen. “Vi levererade vad vi hade förutsatt oss att göra, men det var inte alls vad organisationen hade förväntat sig…”

Utan en tydlig uppfattning för vilka kraven är och vilka förväntningarna är, så tror jag att det är näst intill omöjligt att lyckas med ett projekt. Om man inte vet var man är eller vart man är på väg så är det omöjligt att veta om man är på rätt väg! Man kan inte tydligt nog poängtera detta, alldeles för många projekt har gått under på grund av detta!

Min personliga känsla är att man bör försöka göra installationer i omgångar – försök inte lösa allt på en gång! Börja med en uppsättning behov och förväntningar kopplade till dessa behov. Leverera en lösning som håller för dessa behov och krav. Gå i mål med detta och fortsätt sedan därifrån och utred nästa uppsättning behov och förväntningar. Oddsen är att ni har lärt er väldigt mycket på vägen som gör att ni tänker om till senare iterationer – försök vara agila!

Åh andra sidan – utan en känsla för de övergripande kraven så är det lätta att feldimensionera implementationen. Det gäller att produkten man väljer räcker hela vägen…

Wade Baker, Verizon Business RISK team, säger att i de fall där de undersöker cyberbrott så finner dom att trots att
informationen fanns i loggarna i 75% av fallen så upptäcktes inte problemet förrens en utomstående part  (kund, leverantör etc) kontaktade företaget.

Vidare säger Alan Paller, director of research at the SANS Institute, att ett bra SIEM verktyg är en bra start men “But they’re only going to catch the known attacks. Beyond that, tools take a back seat to a smart, well-educated team of people.”

Som sagt, har du kollat dina loggar idag ?

http://washingtontechnology.com/articles/2010/01/15/cyber-attacks-increase-google.aspx

Varje Security Event Management- / logghanteringsinstallation är olika, men det finns flera grundläggande kriterier att använda när man genomför sin upphandling. Säkerhetsgurun Joel Snyder går igenom de sex viktigaste kriterierna att betänka under upphandlingen – han inkluderar även en vältäckande produktlista av SIM system och logghanteringssystem.

Men en slutsats jag drar när jag läser utredningen är att första punkten alltid måste vara utred behoven och förväntningarna, att börja i den tekniska änden kommer alltid att sluta i tårar!

Jag tänker sammanfatta och översätta de punkter som nämns i dokumentet, men den verkliga checklistan borde, enligt mig, se ut som följer;

1. Utred behov och förväntningar
2. Datainsamling och arkivering
3. Normalisering
4. Korrelation och analys
5. Alarm och hantering
6. Rapportering
7. Utredningsarbete

Undersökningen är sponsrad av LogLogic.

[Edit] Tyvärr så verkar artikeln lagts bakom en registeringsportal, om du vill läsa den så kan du göra det genom att registrera här; IT Decision Checklist: SIMs and Log Management.

Jag tror att man kan säga att logghantering börjar gå från spjutspets till vardagsmat när det dyker upp loglogic appliance på eBay

annons på eBay

LogLogic 4.9 News Release

Och LogLogic har även fått ett patent på lagring av rådata,

LogLogic Patent News Release

Splunk 4 har nu kommit i en gratisversion (4.0.5), mer information om hur man kör Splunk gratis finns på

http://blogs.splunk.com/johnathon/?p=18

Mer information om Splunk finns på deras hemsida splunk.com