flere virksomheder bruger deres sikkerhedslogfiler til at registrere ondsindede hændelser. Mange af dem indsamler for meget logdata—ofte milliarder af begivenheder. De prale om størrelsen af deres log opbevaring drev arrays. Måles de i terabyte eller petabyte?

et bjerg af data giver dem ikke så mange nyttige oplysninger, som de gerne vil. Nogle gange er mindre mere. Hvis du får så mange advarsler, at du ikke kan reagere tilstrækkeligt på dem alle, skal der ændres noget. Et centraliseret logstyringssystem kan hjælpe. Denne hurtige introduktion til logning og ekspertanbefalinger hjælper nye systemadministratorer med at forstå, hvad de skal gøre for at få mest muligt ud af sikkerhedslogfiler.

grundlæggende om sikkerhedsbegivenhedslogning

en af de bedste guider til sikkerhedslogning er den nationale indført af standarder& teknologi (NIST) speciel publikation 800-92, Guide til styring af Computersikkerhedslog. Selvom det er lidt dateret, skrevet i 2006, dækker det stadig det grundlæggende i sikkerhedslogstyring godt.

det placerer sikkerhed log generatorer i tre kategorier: operativsystem, applikation eller sikkerhedsspecifikt program (f.eks. brandvægge eller systemer til detektering af indtrængen). De fleste computere har snesevis af logfiler. Microsoft-computere leveres med tre primære, binære hændelseslogfiler: system, applikation og sikkerhed. Desværre kan navnene være vildledende, og bevis for sikkerhedshændelser gemmes ofte på tværs af alle tre logfiler.

siden Vinduer Vista, er disse tre vigtigste logfiler opdelt i næsten hundrede forskellige visninger for mere fokuseret fordøjelse. Mindst et dusin er tekst eller binære logfiler, selv uden nogen anden applikation installeret. Et system med unik stil har normalt en centraliseret syslog-fil sammen med andre tekstbaserede logfiler til alle de forskellige applikationer og dæmoner. Mange administratorer omdirigerer de enkelte filer til den vigtigste syslog-fil for at centralisere tingene.

Smartphones og andre computerenheder har normalt også logfiler. De fleste ligner syslog, men de kan ikke let ses eller tilgås. De fleste kræver, at enheden sættes i en særlig fejlsøgningstilstand eller henter yderligere programmer for at se eller konfigurere logfilerne. En undtagelse er iPhone crash logs, som synkroniseres af iTunes til værten PC ved hver forbindelse.

Sikkerhedslogfiler på mobile enheder er meget sværere at få adgang til og meget mindre nyttige, når du gør det. Du kan muligvis få grundlæggende oplysninger om en sikkerhedsbegivenhed, men med langt mindre detaljer, end du kan få fra den gennemsnitlige personlige computer. Mange administratorer installerer et tredjepartsprogram for at indsamle mere grundige sikkerhedslogdata fra en mobilenhed.

vinduer aktiverer de fleste logfiler som standard, selvom du muligvis skal definere, hvilket niveau af logning du vil have. Aktivering af den mest mulige detalje bør kun ske under et specifikt behov eller under forsøg på at spore en aktiv, kendt sikkerhedsbegivenhed. Ellers kan antallet af begivenhedsmeddelelser hurtigt overvælde et system. Mange systemer er gået ned, fordi velmenende systemadministratorer tændte for den mest detaljerede logning for at hjælpe med at diagnosticere noget og derefter glemte at slukke for det.systemerne har normalt syslog aktiveret som standard, og du kan konfigurere detaljeniveauet. Mange andre applikations-og sikkerhedslogfiler er som standard deaktiveret, men du kan aktivere hver enkelt med en enkelt kommandolinje.

hver netværksenhed og sikkerhedsapplikation og enhed genererer sine egne logfiler. Alt i alt vil en systemadministrator have hundredvis af logfiler at vælge imellem. Et typisk slutbrugersystem kan generere tusinder til titusinder af begivenheder om dagen. En server kan nemt generere hundreder af tusinder til millioner af begivenheder om dagen.

Tip: Medmindre du kender til en igangværende sikkerhedsbegivenhed, standardlogindstillingerne giver mere end nok information til de fleste sikkerhedsbehov. Start med standardindstillingerne, og tilføj kun logfiler og detaljer efter behov. Hvis du aktiverer detaljeret logning, skal du lave en påmindelse om at slukke for den ekstra detalje senere, så du ikke glemmer det.

centraliseret sikkerhedsbegivenhedslogning

hver administrator ønsker at indsamle de mest almindelige standardlogfiler på hver computer til en centraliseret placering. Værdien i aggregering af alle data til en centraliseret database til alarmering og analyse kan simpelthen ikke undervurderes. Spørgsmålet er: Hvordan samler du alle disse data og hvor meget?

de fleste systemer har evnen til at sende deres vigtigste logfiler til en centraliseret placering. Du får næsten altid langt mere værdi og alsidighed ved at bruge en tredjepartsagent, der er bygget nøjagtigt til indsamling og afsendelse af hændelseslogoplysninger. Mange administratorer bruger gratis værktøjer til at gøre det, men de fleste af de kommercielle muligheder er bedre.

du vil have et centraliseret logstyringssystem til at indsamle, gemme og analysere alle data. Der er hundredvis af muligheder og leverandører at vælge imellem. Du har kun programmel og apparatindstillinger, hvor sidstnævnte lettere giver bedre ydelse i de fleste tilfælde. Vælg en mulighed, der giver dig mulighed for effektivt og sikkert at indsamle begivenhedsdata fra de fleste af dine kilder. Du vil ikke sende hændelseslogdata over ledningen i klar tekst. Hændelseslogstyringsprogrammet skal samle dataene, normalisere dem (konvertere dem til et fælles format), advare om unormale begivenheder og give dig mulighed for at køre forespørgsler.

før du vælger en løsning, Prøv før du køber. Du vil være i stand til at indtaste enhver forespørgsel og få et svar inden for en rimelig tid. Hvis du venter 10 til 15 sekunder på et svar, bruger du hændelsesloganalyse mindre, og den begynder at miste sin værdi.

de fleste virksomheder indsamler alle data fra de vigtigste standard logfiler, og det kan nemt være overvældende, fra både Netværk Udnyttelse gennemløb og opbevaring synspunkter. Jeg mener dette bogstaveligt, ikke billedligt. De fleste erfarne administratorer har en historie om, hvordan aggregering af deres hændelseslogfiler knuste deres netværks ydeevne, indtil de optimerede deres hændelseslogning.

uanset hvad du gør, skal du ikke bare indsamle oplysninger fra servere. I dag starter de fleste kompromiser fra slutbrugerarbejdsstationer. Hvis du ikke indsamler logfilerne fra klientcomputere, mangler du de fleste af de værdifulde data.

Tip: Generer så mange detaljer som du har brug for på det lokale system, men filtrer og send kun de mest værdifulde og kritiske begivenheder til dit centraliserede logstyringssystem. Send hvad der er nødvendigt for at generere advarsler til alle dine vigtigste sikkerhedshændelser, men lad resten være på det lokale system. Du kan altid hente den tilføjede detalje, når det er nødvendigt. Ved hjælp af denne metode kan du få de data, du har brug for for at få advarsler og starte retsmedicinske undersøgelser, men uden at overvælde dit netværk og lagerenheder. Der er altid chancen for, at en dårlig fyr kan slette de lokale hændelseslogdata, før du kan hente dem, men i praksis har jeg næsten aldrig set det ske.

Hent nyttige logoplysninger

den sværeste del af ethvert hændelseslogstyringssystem er at få nok information til at kunne registrere alle nødvendige sikkerhedshændelser, mens du ikke overvælder dit system med for meget støj. Selv i de mest effektive styringssystemer vil de fleste indsamlede hændelseslogdata være støj. Det er bare den måde, hvorpå hændelseslogstyring fungerer.

Tip: Sørg for, at dato og klokkeslæt er indstillet korrekt på alle dine systemer. Når du prøver at korrelere begivenheder, skal du have nøjagtig tid.

hvor hændelseslogstyringssystemer viser, at deres reelle værdi er i, hvor godt de filtrerer den unødvendige støj og advarer om nyttige handlingsmæssige begivenheder. Kritiske begivenheder bør altid føre til en øjeblikkelig advarsel og en lydhør undersøgelse. En hændelsesjournal skal defineres som handlingsrettet, når hændelsesjournalen indikerer stor sandsynlighed for ondsindet aktivitet, overdreven (vedvarende) systemaktivitet, uventet (vedvarende) fald i systemaktivitet eller missionskritiske problemer med applikationens ydeevne eller fejl.

et godt hændelseslogstyringssystem leveres med foruddefinerede almindelige advarsler (f.eks. overdreven kontolokalisering) og giver administratorer mulighed for at oprette deres egne begivenheder (afvigelser fra forventede basislinjer, der overstiger en bestemt tærskel). Det kan tage flere korrelerede begivenheder fra flere systemer til at generere en advarsel. Afhængigt af begivenhedens sjældenhed er en enkelt begivenhed (f.eks. logon til en falsk “trap” – konto) nok til at generere en advarsel. Et godt system kommer med de begivenheder, de fleste administratorer ønsker at advare om og med nok filtre til at slough væk junk.

Tip: Start med at definere alle begivenheder relateret til din virksomheds seneste og mest sandsynlige fremtidige vellykkede angreb, og find derefter ud af, hvilke begivenhedsbeskeder og advarsler du skal definere for at opdage og stoppe disse angreb. Du har mange, mange sikkerhedshændelser at bekymre dig om, men dem, der er vigtigst at overvåge og advare om dem, der mest sandsynligt vil blive brugt i fremtiden mod din virksomhed.

god hændelseslogning handler om at trække de nødvendige kritiske begivenheder og advarsler ud af en ellers overvældende mængde information. Problemet for de fleste administratorer er ikke at få nok information, men at få de virkelig nyttige oplysninger ud af en overvældende tsunami af begivenheder. En god begivenhed log management system hjælper dig med at gøre det.