Analys av loggdata

Hitta dator när DHCP används

När man använder DHCP kommer en dator eller någon annan enhet på nätverket att byta IP-adress ibland. Man måste därför logga bytet av IP-adress från en DHCP-logg och ha det i åtanke om man söker efter en viss dator med en IP-adress. Alternativt kan man använda datornamnet vid sökning eller DNS-namnet som ofta uppdateras vid bytet av IP-adress om allt fungerar.

Har man gott om IP-adresser och inte byter datorer allt för frekvent, kan man förlänga lånetiden för en IP-adress (till sex veckor eller mer) och då kanske datorn aldrig byter IP-adress. Man behöver ändå logga bytet från en DHCP-logg för att få spårbarhet om det skulle hända.

Hitta dator när NAT används

När man använder NAT (Network Address Translation) och har lokala IP-adresser översätts dessa till publika IP-adresser som fungerar på internet vid en router, brandvägg eller liknande, även portarna översätts för att minimera antalet publika IP-adresser som används.

Svårigheten här blir att veta vilken dator som har orsakat en incident ute på internet. Rapporten från någon på internet anger bara brandväggens utsidas IP-adress (174.71.70.89), port (51414) och tidpunkt. Från brandväggsloggen måste man fånga händelsen då översättningen mellan lokal och publik IP-adress görs.

När detta är gjort har man den lokala IP-adressen och kan börja leta efter datorn och ha DHCP i åtanke, eftersom datorn kan ju nu ha bytt IP-adress till någon annan IP-adress.

Felsökning DHCP-problem

Enheten får ingen IP-adress. Lediga IP-adresser är slut:

Scope, 192.168.16.0, is 100 percent full with only 0 IP addresses remaining. Exemplet är taget från loggboken i Microsoft Windows.

Här kan det vara bra att skapa ett larm, så att man får vetskap om problemet direkt.

Felsökning kommunikation

Fel IP-adress används. En dator nekas att kommunicera med vetenskapliga tidskrifter. Sökning i loggsystemet hittar en IP-adress som nekas. Sökning historiskt visar att när det fungerade användes en annan lokal IP-adress från DHCP som kopplades till en specifik brandväggskonfiguration med en publik IP-adress som accepteras hos tidskriftsservern. Lösningen blir att reservera datorns IP-adress i överensstämmelse med brandväggskonfigurationen.

Är det några som kör QUIC?

QUIC är ett protokoll baserat på UDP och fungerar med HTTP för att öka prestandan. I stället för TCP/80 och TCP/443 används UDP/80 och UDP/443.

Man söker efter händelser där destinationsporten är UDP/80 eller UDP/443 och får då fram alla loggposter där QUIC används.

SSH-portar/tunnlar

SSH är ett protokoll som krypteras och stödjer tunnlar över TCP/22. Andra program kan använda tunneln som skapats. Detta gör att SSH kan liknas vid VPN.

Det är av största vikt att veta vilka tunnlar som passerar in genom en brandvägg, eftersom trafiken inne i tunnlarna kan undvika regler som är uppsatta i brandväggen.

Sökning efter TCP och port 22 gör att man kan se om det har skapats några möjliga tunnlar och vilka IP-adresser som deltar i kommunikationen.

Felsökning

Användarna upplever att det går långsamt att surfa på jobbet jämfört med hemma. Man söker i loggsystemet för att hitta något som kan orsaka att det går långsammare för en testanvändare.

Under tiden testanvändaren surfar så blir flera uppkopplingar nekade i brandväggen på specifikt UDP port 80 och 443. Man testar att öppna för UDP 80 och 443 i brandväggen och då går det lite snabbare att surfa.

Hur upptäcker man DNS-tunnlar?

Det kan vara extremt svårt att upptäcka DNS-tunnlar. Granska och analysera DNS-händelser från egna interna DNS-servrar. Utvärdera onormala mönster, till exempel storleken på DNS-förfrågningar och svar, frekvensen av förfrågningar, eller onormala kombinationer av DNS-typer som används. Detta kan hjälpa till att identifiera misstänkt aktivitet som kan vara relaterad till DNS-tunnlar.

Pentest och se vad som syns i loggarna

För att bli riktigt duktig på att detektera intrång, behöver man veta hur ett intrång ser ut. Ett sätt att göra detta kan vara att beställa ett pentest, där svagheter testas för att se om man saknar något skydd. Man kan då parallellt och senare söka i loggsystemet och försöka hitta händelser som kommer från pentestet och lära sig hur de ser ut, för att bli bättre på att detektera liknande försök i framtiden.

Red Team övningar och se vad som syns i loggarna

Ytterligare ett sätt att få erfarenhet av hur ett intrång sker är att beställa Red Team övningar. Detta Red Team tar då och försöker ta sig in på nätverket så långt det går och lämnar en rapport över vad de hittade för brister och hur de gick tillväga.

Man kan då parallellt och senare söka i loggsystemet för att lära sig hitta spår efter detta Red team.

När man har blivit duktig på att hitta intrång, så kan man bilda ett Blue Team som försöker hitta intrånget och stoppa det, innan Red Team har kommit in så långt i nätverket.

Pentest och se vad som syns i loggarna

För att bli riktigt duktig på att detektera intrång, behöver man veta hur ett intrång ser ut. Ett sätt att göra detta kan vara att beställa ett pentest, där svagheter testas för att se om man saknar något skydd. Man kan då parallellt och senare söka i loggsystemet och försöka hitta händelser som kommer från pentestet och lära sig hur de ser ut, för att bli bättre på att detektera liknande försök i framtiden.

Red Team övningar och se vad som syns i loggarna

Ytterligare ett sätt att få erfarenhet av hur ett intrång sker är att beställa Red Team övningar. Detta Red Team tar då och försöker ta sig in på nätverket så långt det går och lämnar en rapport över vad de hittade för brister och hur de gick tillväga.

Man kan då parallellt och senare söka i loggsystemet för att lära sig hitta spår efter detta Red team.

När man har blivit duktig på att hitta intrång, så kan man bilda ett Blue Team som försöker hitta intrånget och stoppa det, innan Red Team har kommit in så långt i nätverket.

Backuper (Se när de går fel och när de inte körs alls)

Man aktiverar loggning av alla backuper i alla applikationer, system och skickar dessa till loggsystemet. Man skapar ett larm i loggsystemet som kontrollerar om någon backup går fel och ett meddelande går då ut till backupansvariga.

Man bestämmer även att avsaknad av backuphändelse under den tid som händelsen förväntas komma, ska larmsättas.

Vill man inte ha ett separat övervaknings- och larmsystem för alla larmflöden, kan man säkerställa att larmflödet fungerar genom att skicka meddelanden till backupansvariga varje dag, oavsett om det har gått bra, dåligt eller inte alls. Kommer det inget meddelande så fungerar inte larmflödet. Det är ett enkelt sätt att kontrollera larmflödet och kan fungera för vissa organisationer efter att ha utvärderats.

Långsamma applikationssökningar mot databaser (Index kanske saknas)

Det är fler än en gång det inträffar att en applikation upplevs som långsam. Ett sätt att kontrollera om det är databasen som är långsam, är att aktivera prestandaloggning där varje sökning/fråga loggas med statistik över hur lång tid det tog. Här kan man se hela frågan och villkoret.

Man letar i logghändelserna efter en fråga som tar lång tid att utföra. Om man hittar en sådan fråga, kontrollerar man villkoret och ser vilka fält/kolumner som villkoret använder. Dessa behöver vara indexerade för att inte databasen ska behöva leta igenom hela tabellen efter ett svar. Tyvärr förekommer det mer än en gång att det saknas index. Lösningen blir att skapa index.

Digitala recept kommer inte fram till apoteket

I det här exemplet skickas recept ut från journalsystemet i ett speciellt format till en mapp på en annan server. En meddelandetjänst hämtar därefter recepten från den mappen och skickar dem till apoteket på ett säkert och krypterat sätt.

Nu har patienter som ska hämta ut recepten på apoteket klagat på att de inte har kommit fram. Apoteket meddelar sjukhuset att recept inte kommer fram och en felsökning påbörjas i loggsystemet.

Mappen där recept hamnar i, har granskning/audit aktiverad och loggen skickas till loggsystemet. Meddelandetjänstens logg skickas också till loggsystemet.

I loggsystemet korreleras loggarna och man kan följa flödet kronologiskt och ser när recept hamnar i mappen, när de hämtas och plockas bort av meddelandetjänsten och när de skickas till apoteket. Där ser man nu att recepten hela tiden läggs till i mappen, men att meddelandetjänsten inte hämtar och tar bort dem och skickar till apoteket. Mappen innehåller nu ganska många recept. Lösningen blir att starta om meddelandetjänsten. Direkt ser man då att recepten minskar i mappen.

Man bestämmer att här vill man agera förebyggande och inte vänta på att patienter klagar, så man skapar ett larm som triggas när ett recept inte har tagits bort efter 10 minuter och meddelande skickas då till ansvarig funktion för meddelandetjänsten.

Backuper (Se när de går fel och när de inte körs alls)

Man aktiverar loggning av alla backuper i alla applikationer, system och skickar dessa till loggsystemet. Man skapar ett larm i loggsystemet som kontrollerar om någon backup går fel och ett meddelande går då ut till backupansvariga.

Man bestämmer även att avsaknad av backuphändelse under den tid som händelsen förväntas komma, ska larmsättas.

Vill man inte ha ett separat övervaknings- och larmsystem för alla larmflöden, kan man säkerställa att larmflödet fungerar genom att skicka meddelanden till backupansvariga varje dag, oavsett om det har gått bra, dåligt eller inte alls. Kommer det inget meddelande så fungerar inte larmflödet. Det är ett enkelt sätt att kontrollera larmflödet och kan fungera för vissa organisationer efter att ha utvärderats.

Långsamma applikationssökningar mot databaser (Index kanske saknas)

Det är fler än en gång det inträffar att en applikation upplevs som långsam. Ett sätt att kontrollera om det är databasen som är långsam, är att aktivera prestandaloggning där varje sökning/fråga loggas med statistik över hur lång tid det tog. Här kan man se hela frågan och villkoret.

Man letar i logghändelserna efter en fråga som tar lång tid att utföra. Om man hittar en sådan fråga, kontrollerar man villkoret och ser vilka fält/kolumner som villkoret använder. Dessa behöver vara indexerade för att inte databasen ska behöva leta igenom hela tabellen efter ett svar. Tyvärr förekommer det mer än en gång att det saknas index. Lösningen blir att skapa index.

Digitala recept kommer inte fram till apoteket

I det här exemplet skickas recept ut från journalsystemet i ett speciellt format till en mapp på en annan server. En meddelandetjänst hämtar därefter recepten från den mappen och skickar dem till apoteket på ett säkert och krypterat sätt.

Nu har patienter som ska hämta ut recepten på apoteket klagat på att de inte har kommit fram. Apoteket meddelar sjukhuset att recept inte kommer fram och en felsökning påbörjas i loggsystemet.

Mappen där recept hamnar i, har granskning/audit aktiverad och loggen skickas till loggsystemet. Meddelandetjänstens logg skickas också till loggsystemet.

I loggsystemet korreleras loggarna och man kan följa flödet kronologiskt och ser när recept hamnar i mappen, när de hämtas och plockas bort av meddelandetjänsten och när de skickas till apoteket. Där ser man nu att recepten hela tiden läggs till i mappen, men att meddelandetjänsten inte hämtar och tar bort dem och skickar till apoteket. Mappen innehåller nu ganska många recept. Lösningen blir att starta om meddelandetjänsten. Direkt ser man då att recepten minskar i mappen.

Man bestämmer att här vill man agera förebyggande och inte vänta på att patienter klagar, så man skapar ett larm som triggas när ett recept inte har tagits bort efter 10 minuter och meddelande skickas då till ansvarig funktion för meddelandetjänsten.

Anomalier

Det är viktig att hålla koll på nätverksflöden, dvs hur trafiken flödar i datanätverket. En bra sak med loggsystem är att de ofta kan fastställa vad som är normala nätverksflöden. Man kan sätta upp larm som aktiveras om något avviker från det normala med en viss procent eller värde.

Här behöver man finjustera larmen så att de bara kommer när det verkligen är något man vill titta noggrannare på.

Har data skickats mellan dessa noder?

Vid ett intrång där man kan peka ut en viss dator som har blivit övertagen, vill man säkerställa om datorn har kontaktat andra datorer, servrar eller andra nätverksenheter.

Med hjälp av nätverksflöden och rätt konfiguration i nätverket är det möjligt att se vilka andra enheter i nätverket som datorn har kommunicerat med. Man kan då fortsätta att analysera dessa enheter för att avgöra om attacken har spridit sig.

Vilka protokoll används i nätverket?

En annan möjlighet är att få vetskap om vilka protokoll som används i nätverket, hur ofta och hur mycket data som skickas. Det kanske finns protokoll som man inte alls vill ha i nätverket. Man kan då i loggsystemet spåra vilka enheter som använder dessa protokoll.

Vilka länder kommer IP-adresserna ifrån

Man kan vara intresserade av att veta vilka länder som försöker att komma åt en av företagets webbtjänster. Alla loggsystem har möjligheter att koppla varje IP-adress till ett specifikt land. Man kan med hjälp av denna information skapa cirkeldiagram som visar hur stor andel kommer från olika länder och liknande.

Geografisk plats kombinerat med säkerhetsincidenter

Man misstänker att en dator fjärrstyrs från internet. Här vill man hitta eventuell IP-adress ute på internet och se varifrån den kommer. Är det en anställd som fjärrstyr datorn och har behörighet för detta, eller är det ett intrång.

Felsökning och korrelering, problem med vissa delar av nätet

Vid VPN-uppkoppling med flerfaktorautentisering via SMS, så får vissa användare inga SMS. Man felsöker i loggsystemet och korrelerar SMS-loggarnas mobilnummer med användarnas konton och varifrån de kopplar upp sig med VPN och man kan då se att det verkar vara i Sundsvallsområdet som man har problem med att få SMS. Det visar sig att mobiloperatören har problem i detta område.

Korrelering med länkande fält (Samma fält finns från båda loggkällorna)

Söka efter fält som betyder samma sak, innehåller jämförbara värden och finns i båda loggkällorna, blir enkelt eftersom de använder samma fält i loggsystemet och man får en bra sammanställning. Finns det ytterligare loggkällor med samma fält, så får man det på köpet.

Korrelering utan länkande fält (Bara tidpunkt)

Ibland kan det vara så att det inte går att korrelera fält från olika datakällor, eftersom informationen saknas. Kan man inte utöka någon av datakällorna med ett fält till, blir man tvungen att söka efter dessa datakällor och sortera efter tidpunkt. Man får ändå en kronologisk följd av händelser som ger en helhetsbild av förloppet.

Här är det mycket viktigt att klockorna är synkroniserade mot samma tidkälla och att tidzonen stämmer. Tester behöver utföras för att verifiera detta.

Loggkällan har slutat att skicka loggdata helt och hållet

När en loggkälla slutar att skicka data, så måste man ha ett sätt att indikera när detta sker och skapa larm som varnar om problemet. Ofta anger man en viss tid, till exempel har ingen data inkommit under 30 minuter. Problemet kan bero på:

- Tekniskt fel

- En antagonist har stängt av loggningen

Händelserna har slutat helt, produktionsstopp?

Loggkällan har slutat att skicka loggdata i den takt den brukar

När detta sker kan det indikera något problem med produktionssystemet, tekniskt fel, eller att helt enkelt användarna är lediga.

Detta problem kan vara svårare att sätta larm på, när man inte bara kan använda inaktivitet som mått. Det kan gå att specificera avvikelser från det normala i form av procent eller värden.

Vad hände vid tidpunkten runt incidenten?

Här gäller det att få så mycket information om incidenten som möjligt. Det kan vara så att den första informationen som fås är felaktig eller innehåller brister och då blir jobbet att hitta orsaken mycket svårare.

Ju mer man vet om incidenten, desto mer detaljerad sökning kan man göra i loggsystemet och sortera i kronologisk ordning.

Det kan vara så att all data inte loggas, så man får felsöka i själva källsystemet för att komma vidare.