Kan man skapa Windows-loggar som är förståeliga för en lekman?

Transkript

1 Kan man skapa Windows-loggar som är förståeliga för en lekman? Vilka är vi på Secorum AB Secorum är ett företag som jobbar med logghantering ur ett helhetsperspektiv. Vad innebär då detta? Det finns många produkter på marknaden som hanterar loggar. Vi har lärt oss att det finns en övertro på att produkterna kommer att lösa dina loggproblem. Så är tyvärr inte fallet. Produkterna har det gemensamma att skit in ger skit ut. Kombinationen av rätt information och en bra logghanteringsprodukt är det vi eftersträvar. Vad som är en bra logghanteringsprodukt kan dock variera mellan olika kunder. Det är med andra ord dina krav som styr val av produkt och du kommer inte undan att anpassa dina loggars informationsinnehåll när du centraliserar din analys. Vi kommer in i tekniken ganska sent. Innan installation och insamling vill vi helst få kunden att förstå värdet av att ta fram sina analysbehov. Dessa tillsammans med krav på din spårbarhet öppnar dörren till ett lyckat projekt. Analysbehov, logghanteringskrav och krav på informationsinnehållet i dina loggar leder till en kravmassa som kravställer på rätt produkt och rätt information i dina loggar. Att jobba med logghantering Att jobba med logghantering innebär att omvandla data till information. Data måste som regel bearbetas på något sätt för att ge rätt informationsvärde. Det bästa är att skapa rätt data från början, då har den skapade mängden loggdata redan rätt informationsinnehåll. Detta kräver att du vet vilken information du behöver. Att ha kommit så långt i sin kravställning är ovanligt, men det är till den nivån vi strävar. En bra bild på processen för att bygga upp en logghanteringsfunktion, oavsett produkt, är den som visas i Bild 1. Notera att processen är gammal och beprövad, den så kallade informationsmodellen som ligger till grund för Secorums informationsprocess är sedan länge framtagen och använd av både militär och polis. Till skillnad från militära och polisiära organisationer så äger organisationen de källor som genererar den data vi så småningom ska analysera. Det finns dock en övertro att logghanteringsprodukter klarar av att rätta till en låg informationsnivå i loggarna. Oavsett logghanteringsprodukternas pris och förmåga så kommer dess output aldrig att bli bättre än informationsnivån de förses med. Det är den resan vi ska ta med dig på i denna föreläsning. Loggar du inget om objektet, t.ex. transaktionsloggar, vet du inget om objektet.

2 Modell för logghantering Systemvärld Syftet med spårbarheten inom organisationen Återkoppling Styr behovet av analys Nuvarande Loggenerering Insamling bearbetning Analys Spridning Data Data/Information Information Bild1. Secorums logghanteringsmodell Den viktigaste delen i Secorums logghanteringsmodell är att identifiera syftet med organisationens spårbarhetsbehov. Har vi detta klart för oss så kommer vi att få styrning i samtliga steg i kedjan. Initialt styrs spårbarhetsbehoven av dina analysbehov, men ganska snart klär vi på kravlistan med andra krav som t.ex. arkivering, realtidsanalys, korreleringsbehov och så vidare. Återkopplingen sker i huvudsak från analytikerna, men kommer även från dem som rapporter och loggutdrag sprids till. Återkopplingen är motorn i den iterativa process som möjliggör att i etapper bygga upp din logghantering. Vi behöver inte ha kravet att ta fram något perfekt i den första iterationen. Att sätta dessa krav för lågt innebär som regel ett misslyckande då det visat sig vara svårt att förändra källsystemens loggning efter det att de tagits in i en central logghanteringslösning. Målet är att loggutdrag och rapporter är förståeliga för en lekman och att vi en gång för alla kommer bort från kravet att en logg måste tolkas av en tekniker för att förstås. I syfte att exemplifiera vad vi menar så kan delar av din loggpolicy bygga på följande krav: Det ska vara möjligt att binda den enskilde till sina operationer även om fler har skrivrättigheter i samma objekt. Loggutdragen ska vara förståeliga för en lekman Ur ovan text härleder vi t.ex. följande krav: Autenticeringen som binder den logiska användaridentiteten i loggen till dess fysiska användare ska vara tillräckligt stark Det ska vara möjligt att utesluta alla andra som inte utfört en viss operation Det ska vara möjligt att logga förändrade värden inne i ett objekt

3 Det ska vara möjligt att förstå vad som hänt genom att läsa innehållet i relevanta loggposter utan krav på att vara en tekniker Dessa krav ska implementeras på loggarna som skapas av källsystemen. Secorum och NetIQ tillsammans Samarbetet mellan NetIQ och Secorum är ett bra exempel på hur två företag samarbetar i syfte att hitta en lösning som kan adderas till en ny eller existerande logghanteringsfunktion. Eller självständigt för den delen. I detta fall har vi låtit behoven styra och släppt produktkonflikter och andra problem genom att visa att två företags produkter kan samarbeta i syfte att uppnå ett gemensamt mål. Vi pratar om HP ArcSight och NetIQ med produkten Change Guardian (CG). CG fungerar idag som den gjorde innan vårt samarbete, men dess loggar som här ska användas för att ersätta Windows EventLog vad mindre bra. Under sommaren har Secorum kravställt på CG:s loggar och NetIQ har utvecklat sin produkt efter dessa. Resultatet är en produkt som loggar i Common Event Format (CEF-format), en industristandard som förstås av flertalet logghanteringsprodukter. Bland annat ArcSight. I vårt dagliga arbete stöter vi på Windows EventLogg och då främst dess säkerhetslogg. Den som vet något om Windows säkerhetslogg vet att det skapas mängder av loggposter för en enda operation. Dessutom måste loggningen i förväg konfigureras och eftersom man inte brukar ta hänsyn till de specifika servrarnas krav slutar det som regel med en gemensam policy som ser likadan ut på alla servrar. I den riktiga världen är detta detsamma som att anta att alla levande varelser har samma förutsättningar. Säg till en elefant, en apa och guldfisk att de ska klättra upp i ett träd och du får bara en som klarar av detta. Utan att vara allt för negativ är Windows EventLogg något av det svåraste att ge sig på som logganalytiker. Det är inte många loggkällor som genererar sådana mängder av data med så lågt informationsvärde. Processen att göra data till information är i detta fall både lång och svår. Att tillkalla en Windows expert för att tolka plattformens loggar är visserligen en lösning, men tänk om alla komponenter som genererar loggar skulle ha detta som krav. Den lösningen är dyr och den är då begränsad då nästan inget loggas av det som händer inuti objektet. I nedan presentation finner du en lösning som kompletterar eller helt ersätter Windows operativsystemsloggar. I denna demo har vi stängt av Windows EventLogg helt. Notera att vi inte kan göra detta om applikationen på servern skriver till EventLoggen. Denna demo visar hur vi kan ersätta operativsystemets loggning, inte applikationernas. Att applikationer skriver till EventLoggen är en annan sak att hantera, dessa är lika dålig som operativsystemets loggar och man bör kravställa på en helt annan logg även i dessa fall. Om detta talar vi om en annan gång. Kraven att hantera i denna demo är följande: 1. Skapa en loggpost per mänsklig operation på Windows servern 2. Skapa en loggpost som är förståelig för en lekman 3. CG skapar loggposter i CEF-format som läses in av ArcSight Logger och ESM

4 4. Möjliggör att i realtid kunna förändra loggningen på Windows server från dem som analyserar dess loggar, t.ex. personalen i en SOC 5. Möjliggör att skapa larm som triggas av valfria händelser De komponenter som samarbetar i denna demo utgörs av delarna i Bild 2. Change Guardian Clients ArcSight Clients Change Guardian Profile Editor Change Guardian Web Console ArcSight ESM Console ArcSight Logger Web Console Change Guardian Servers ArcSight Servers Event forwarding, Syslog TCP Event forwarding, Smart Connector Change Guardian Server ArcSight Logger ArcSight ESM Change Guardian Agents U s e r ac c t i o n s Microsoft Server Bild två visar komponenterna som ingår i denna demo. CG kräver att en agent installeras på varje Windows server för att den ska kunna följa vad som sker i serverns filsystem. I korthet är demon uppsatt av följande komponenter En Windows server som exemplifierar en organisations alla Windows servrar En Change Guardian (CG) server som kommunicerar med en agent installerad på Windows servern Logginsamling från CG till HP ArcSight för realtidsövervakning och analys CG klienter för managering av CG-agenten Logganalysklienter för övervakning och analys av insamlad loggdata. DEMO Denna text innehåller endast en liten del av det vi vill visa på vårt frukostseminarium den 11 november 2014 i NetIQ:s lokaler i Kista. Vill du se mer av detta är du välkommen till vårt seminarium.

5 Kom ihåg att det är CG, som via installation av en agent på Windows servern, som genererar de loggar vi ska samla in. Dessa skapas i CEF-format, vilket öppnar dörren för bland annat ArcSight att förstå dessa utan att behöva skriva nya parsers för detta. Flera andra logghanteringsprodukter, inklusive NetIQ:s egen produkt (Sentinel) som har samma förmåga. Användningsfall 1 En användare loggar in på en Windows server över RDP och ändrar textinnehållet i en fil från ett värde till ett annat. Ur ovan händelsekedja redovisas nedan två loggposter från CG i syfte att ge en hint om hur CG loggar detta. Exempelloggar från Change Guardian som analyseras i ArcSight CEF:0 NetIQ Change Guardian Series 4 Personal File was read 5 cat=cha suid=s suser=ingvar rt= sourcednsdomain=localdomain.local shost=windows82 src= sourceservicename=%system Process% msg=personal.txt File was read by 'localdomain\\ingvar' with outcome Success cnt=1 filepath=c:\\data\\personal\\personal.txt destinationdnsdomain=localdomain.local dhost=windows82 dst= cs1label=details cs1= CEF:0 NetIQ Change Guardian Series 4 Personal File was written 5 cat=cha suid=s suser=ingvar rt= sourcednsdomain=localdomain.local shost=windows82 src= sourceservicename=%system Process% msg=personal.txt File was written by 'localdomain\\ingvar' with outcome Success cnt=2 filepath=c:\\data\\personal\\personal.txt destinationdnsdomain=localdomain.local dhost=windows82 dst= cs1label=details cs1= A20D A1007&dt\= Användare: ingvar Händelse: File was read eller File was written GRÖNT: Objekt som händelsen avser (Personal.txt) BLÅTT: Länk till Before och After informationen som skrivs till Change Guardian KlientIP=

6 Destination IP= Nedan info ges om man följer länken i loggposten (den blå) till CG-servern, t.ex. från ArcSighs analysfunktion ESM. Här visas filens värde före och efter. Om filen är en binär (Word, Excell o.s.v.) kan man via hashsummans se, upptäcka, larma om filen har ändrats, men inte till vad. Det är valbart om du vill att objektets innehåll skrivs till loggen eller inte vid en uppdatering. Vid insamling och analys i ArcSight är det en fördel att ha den utanför då ArcSights insamlingsagenter trunkerar (klipper) efter ett visst antal Bytes, beroende på vilket fält som väljs. Normalt Bytes vid ett fält av typen String. CG gör sig bra för att spåra förändringar i register, konfigurationsfiler och i övrigt åtkomst till kataloger och filer som man vill skydda. Eftersom varje objekt man vill ska omfattas av loggning får sin hashsumma beräknad går detta att använda CG på samma sätt som Trip Wire, men med den ytterligare funktionen att CG är direkt tolkningsbar av ledande logghanteringsprodukter.