fler företag använder sina säkerhetsloggar för att upptäcka skadliga incidenter. Många av dem samlar in för mycket loggdata—ofta miljarder händelser. De skryter om storleken på sina logglagringsenheter. Mäts de i terabyte eller petabyte?
ett berg av data ger dem inte så mycket användbar information som de skulle vilja. Ibland är mindre mer. Om du får så många varningar att du inte kan svara tillräckligt på dem alla, måste något förändras. Ett centraliserat logghanteringssystem kan hjälpa till. Denna snabba introduktion till loggning och expertrekommendationer hjälper nya systemadministratörer att förstå vad de ska göra för att få ut det mesta av säkerhetsloggar.
grunderna för säkerhetshändelseloggning
en av de bästa guiderna för säkerhetsloggning är den nationella inrättade standarderna & Technology (NIST) Specialpublikation 800-92, Guide till Datasäkerhetslogghantering. Även om det är lite daterat, skrivet 2006, täcker det fortfarande grunderna för säkerhetslogghantering väl.
det placerar säkerhetslogggeneratorer i tre kategorier: operativsystem, applikation eller säkerhetsspecifik programvara (t.ex. brandväggar eller intrångsdetekteringssystem). De flesta datorer har dussintals loggar. Microsoft Windows-datorer levereras med tre huvudsakliga, binära händelseloggar: system, applikation och säkerhet. Tyvärr kan namnen vara vilseledande, och bevis på säkerhetshändelser lagras ofta i alla tre loggarna.
sedan Windows Vista är de tre huvudloggfilerna uppdelade i nästan hundra olika vyer för mer fokuserad matsmältning. Minst ett dussin är text-eller binära loggar, även utan någon annan applikation installerad. Ett Unix-system har vanligtvis en centraliserad syslog-fil tillsammans med andra textbaserade loggfiler för alla olika applikationer och demoner. Många administratörer omdirigerar de enskilda filerna till den huvudsakliga syslog-filen för att centralisera saker.
Smartphones och andra datorenheter har vanligtvis också loggfiler. De flesta liknar syslog, men de kan inte enkelt ses eller nås. De flesta kräver att enheten sätts i ett speciellt felsökningsloggningsläge eller ladda ner ytterligare programvara för att visa eller konfigurera loggfilerna. Ett undantag är iPhone-kraschloggar, som synkroniseras av iTunes till värddatorn vid varje anslutning.
Säkerhetsloggfiler på mobila enheter är mycket svårare att komma åt och mycket mindre användbara när du gör det. Du kanske kan få grundläggande information om en säkerhetshändelse, men med mycket mindre detaljer än du kan få från den genomsnittliga persondatorn. Många administratörer installerar ett program från tredje part för att samla in mer noggranna säkerhetsloggdata från en mobil enhet.
Windows aktiverar de flesta loggfiler som standard, även om du kanske behöver definiera vilken nivå av loggning du vill ha. Att aktivera så mycket detaljer som möjligt bör endast göras under ett specifikt behov eller när du försöker spåra en aktiv, känd säkerhetshändelse. Annars kan antalet händelsemeddelanden snabbt överväldiga ett system. Många system har kraschat eftersom välmenande systemadministratörer aktiverade den mest detaljerade loggningen för att hjälpa till med att diagnostisera något och sedan glömde att stänga av det.
Unix-system har vanligtvis syslog aktiverat som standard, och du kan konfigurera detaljnivån. Många andra program-och säkerhetsloggfiler är inaktiverade som standard, men du kan aktivera var och en individuellt med en enda kommandorad.
varje nätverksenhet och säkerhetsapplikation och enhet genererar sina egna loggar. Sammantaget kommer en systemadministratör att ha hundratals loggfiler att välja mellan. Ett typiskt slutanvändarsystem kan generera tusentals till tiotusentals händelser per dag. En server kan enkelt generera hundratusentals till miljontals händelser om dagen.
tips: Om du inte känner till en pågående säkerhetshändelse kommer standardlogginställningarna att ge mer än tillräckligt med information för de flesta säkerhetsbehov. Börja med standardinställningarna och Lägg till loggfiler och detaljer endast efter behov. Om du aktiverar detaljerad loggning, gör en påminnelse om att stänga av den extra detaljerna senare så att du inte glömmer.
centraliserad säkerhetshändelseloggning
varje administratör vill samla de vanligaste standardloggfilerna på varje dator till en central plats. Värdet i att aggregera alla data till en centraliserad databas för varning och analys kan helt enkelt inte underskattas. Frågan är: hur samlar du alla dessa data och hur mycket?
de flesta system har möjlighet att skicka sina huvudloggfiler till en central plats. Du får nästan alltid mycket mer värde och mångsidighet genom att använda en tredjepartsagent som är byggd exakt för att samla in och skicka händelseloggsinformation. Många administratörer använder gratis verktyg för att göra det, men de flesta kommersiella alternativen är bättre.
du vill ha ett centraliserat logghanteringssystem för att samla in, lagra och analysera all data. Det finns hundratals alternativ och leverantörer att välja bland. Du har endast programvara och apparatalternativ, med det senare lättare att ge bättre prestanda i de flesta fall. Välj ett alternativ som låter dig effektivt och säkert samla in händelsedata från de flesta av dina källor. Du vill inte skicka händelseloggdata över tråden i klartext. Händelselogghanteringsprogramvaran måste aggregera data, normalisera den (konvertera den till ett gemensamt format), varna om avvikande händelser och låta dig köra frågor.
innan du väljer någon lösning, försök innan du köper. Du vill kunna skriva in alla frågor och få svar på en rimlig tid. Om du väntar 10 till 15 sekunder för ett svar, kommer du att använda händelseloggen analys mindre och det börjar förlora sitt värde.
de flesta företag samlar in all data från de viktigaste standardloggfilerna, och det kan lätt vara överväldigande, från både nätverksutnyttjande genomströmning och lagring synpunkter. Jag menar detta bokstavligen, inte bildligt. De flesta erfarna administratörer har en historia om hur aggregering av deras händelseloggar krossade nätverkets prestanda tills de optimerade sin händelseloggning.
vad du än gör, samla inte bara in information från servrar. Idag börjar de flesta kompromisser från slutanvändarens arbetsstationer. Om du inte samlar in loggfilerna från klientdatorer kommer du att sakna de flesta värdefulla data.
tips: Generera så mycket detaljer som du behöver på det lokala systemet, men filtrera och skicka bara de mest värdefulla och kritiska händelserna till ditt centraliserade logghanteringssystem. Skicka vad som behövs för att generera varningar för alla dina viktigaste säkerhetshändelser men lämna resten på det lokala systemet. Du kan alltid hämta den extra detaljerna när det behövs. Med den här metoden kan du få de data du behöver för att få varningar och starta rättsmedicinska undersökningar, men utan att överväldiga dina nätverks-och lagringsenheter. Det finns alltid chansen att en dålig kille kan ta bort den lokala händelseloggen innan du kan hämta den, men i praktiken har jag nästan aldrig sett det hända.
få användbar logginformation
den svåraste delen av något händelselogghanteringssystem är att få tillräckligt med information för att kunna upptäcka alla nödvändiga säkerhetshändelser, samtidigt som du inte överväldigar ditt system med för mycket ljud. Även i de mest effektiva hanteringssystemen kommer de flesta insamlade händelseloggsdata att vara buller. Det är precis som händelselogghantering fungerar.
Tips: Kontrollera att datum och tid är korrekt inställda på alla dina system. När du försöker korrelera händelser måste du ha exakt tid.
där händelseloggshanteringssystem visar sitt verkliga värde är hur väl de filtrerar det onödiga bruset och varnar om användbara händelser som kan åtgärdas. Kritiska händelser bör alltid leda till en omedelbar varning och en lyhörd utredning. En händelsepost bör definieras som åtgärdbar när händelseposten indikerar stor sannolikhet för skadlig aktivitet, överdriven (ihållande) systemaktivitet, oväntat (ihållande) nedgång i systemaktivitet eller verksamhetskritiska problem med applikationsprestanda eller fel.
ett bra händelseloggshanteringssystem levereras med fördefinierade vanliga varningar (t.ex. överdrivna kontoutdrag) och tillåter administratörer att skapa egna händelser (avvikelser från förväntade baslinjer som överstiger ett visst tröskelvärde). Det kan ta flera korrelerade händelser från flera system för att generera en varning. Beroende på händelsens sällsynthet är en enda händelse (t.ex. inloggning till ett falskt ”trap” – konto) tillräckligt för att generera en varning. Ett bra system kommer med de händelser som de flesta administratörer vill varna på och med tillräckligt med filter för att slänga bort skräpet.
tips: Börja med att definiera alla händelser relaterade till ditt företags senaste och mest troliga framtida framgångsrika attacker och ta reda på vilka händelsemeddelanden och varningar du behöver definiera för att upptäcka och stoppa dessa attacker. Du har många, många säkerhetshändelser att oroa dig för, men de viktigaste att övervaka och varna för de som sannolikt kommer att användas i framtiden mot ditt företag.
bra händelseloggning handlar om att dra ut nödvändiga kritiska händelser och varningar från en annars överväldigande mängd information. Problemet för de flesta administratörer får inte tillräckligt med information, utan att få den verkligt användbara informationen ur en överväldigande tsunami av händelser. Ett bra händelselogghanteringssystem hjälper dig att göra det.
