Flere bedrifter bruker sikkerhetsloggene sine til å oppdage skadelige hendelser. Mange av dem samler for mye loggdata—ofte milliarder av hendelser. De skryter om størrelsen på deres logg lagringsstasjon arrays. Måles de i terabyte eller petabyte?

et fjell med data gir dem ikke så mye nyttig informasjon som de ønsker. Noen ganger er mindre mer. Hvis du får så mange varsler at du ikke kan tilstrekkelig svare på dem alle, må noe endres. Et sentralisert loggstyringssystem kan hjelpe. Denne raske introduksjonen til logging og ekspertanbefalinger hjelper nye systemadministratorer med å forstå hva de bør gjøre for å få mest mulig ut av sikkerhetslogger.

Grunnleggende om sikkerhetshendelseslogging

En av de beste veiledningene for sikkerhetslogging er National Instituted Of Standards & Technology (NIST) Special Publication 800-92, Guide To Computer Security Log Management. Selv om det er litt datert, skrevet i 2006, dekker det fortsatt grunnleggende om sikkerhetsloggadministrasjon godt.

det plasserer sikkerhetslogggeneratorer i tre kategorier: operativsystem, applikasjon eller sikkerhetsspesifikk programvare(f. eks. brannmurer eller inntrengingsdeteksjonssystemer). De fleste datamaskiner har dusinvis av logger. Microsoft Windows-datamaskiner leveres med tre hoved -, binære hendelseslogger: system, program og sikkerhet. Dessverre kan navnene være misvisende, og bevis på sikkerhetshendelser lagres ofte i alle tre loggene.

Siden Windows Vista er disse tre hovedloggfilene brutt ned i nesten hundre forskjellige visninger for mer fokusert fordøyelse. Minst et dusin er tekst eller binære logger, selv uten noe annet program installert. Et Unix-stilsystem har vanligvis en sentralisert syslog-fil sammen med andre tekstbaserte loggfiler for alle de forskjellige applikasjonene og daemonene. Mange administratorer omdirigere de enkelte filene til hoved syslog filen for å sentralisere ting.

Smarttelefoner og andre databehandlingsenheter har vanligvis også loggfiler. De fleste ligner syslog, men de kan ikke lett sees eller nås. De fleste krever at enheten settes inn i en spesiell feilsøkingsloggingsmodus eller laster ned tilleggsprogramvare for å vise eller konfigurere loggfilene. Ett unntak er iPhone krasj logger, som er synkronisert av iTunes til verten PC på hver tilkobling.

sikkerhetsloggfiler på mobile enheter er mye vanskeligere å få tilgang til og mye mindre nyttige når du gjør det. Du kan kanskje få grunnleggende informasjon om en sikkerhetshendelse, men med langt mindre detalj enn du kan få fra den gjennomsnittlige personlige datamaskinen. Mange administratorer installerer et tredjepartsprogram for å samle inn grundigere sikkerhetsloggdata fra en mobil enhet.

Windows aktiverer de fleste loggfiler som standard, selv om du kanskje må definere hvilket nivå av logging du vil ha. Slå på mest mulig detalj bør bare gjøres under et bestemt behov eller mens du prøver å spore en aktiv, kjent sikkerhetshendelse. Ellers kan antall hendelsesmeldinger raskt overvelde et system. Mange systemer har blitt krasjet fordi velmenende systemadministratorer slått på den mest detaljerte logging for å hjelpe med å diagnostisere noe og deretter glemte å slå den av.Unix-lignende Systemer har vanligvis syslog aktivert som standard, og du kan konfigurere detaljnivået. Mange andre program-og sikkerhetsloggfiler er deaktivert som standard, men du kan aktivere hver enkelt med en enkelt kommandolinje.

hver nettverksenhet og sikkerhetsprogram og enhet vil generere sine egne logger. Til sammen vil en systemadministrator ha hundrevis av loggfiler å velge mellom. Et typisk sluttbrukersystem kan generere tusenvis til titusenvis av hendelser per dag. En server kan enkelt generere hundretusener til millioner av hendelser om dagen.

Tips: Med mindre du vet om en pågående sikkerhetshendelse, vil standard logginnstillingene gi mer enn nok informasjon for de fleste sikkerhetsbehov. Start med standardinnstillingene og legg til loggfiler og detaljer bare etter behov. Hvis du slår på detaljert logging, gjør du en påminnelse om å slå av ekstra detaljer senere, slik at du ikke glemmer det.

Sentralisert sikkerhetshendelseslogging

hver administrator ønsker å samle de vanligste standard loggfilene for hver datamaskin til en sentralisert plassering. Verdien i å samle alle dataene til en sentralisert database for varsling og analyse kan ganske enkelt ikke undervurderes. Spørsmålet er: Hvordan samler du alle dataene og hvor mye?

de fleste systemer har muligheten til å sende sine hovedloggfiler til et sentralisert sted. Du vil nesten alltid få langt mer verdi og allsidighet ved å bruke en tredjepartsagent som er bygget nøyaktig for å samle inn og sende hendelseslogginformasjon. Mange administratorer bruker gratis verktøy for å gjøre det, men de fleste kommersielle alternativene er bedre.

du vil ha et sentralisert loggstyringssystem for å samle inn, lagre og analysere alle dataene. Det er hundrevis av alternativer og leverandører å velge mellom. Du har programvare-bare og apparatet alternativer, med sistnevnte lettere å gi bedre ytelse i de fleste tilfeller. Velg et alternativ som lar deg effektivt og sikkert samle hendelsesdata fra de fleste kildene dine. Du vil ikke sende hendelsesloggdata over ledningen i klartekst. Hendelsesloggen programvare må samle data, normalisere det (konvertere den til et felles format), varsle om avvikende hendelser, og lar deg kjøre spørringer.

før du velger en løsning, prøv før du kjøper. Du vil være i stand til å skrive inn noen spørring og få et svar i en rimelig tid. Hvis du venter 10 til 15 sekunder på et svar, bruker du hendelseslogganalyse mindre og den begynner å miste verdien.

de fleste bedrifter samler alle data fra de viktigste standard loggfilene, og det kan lett være overveldende, både fra nettverksutnyttelsesgjennomstrømning og lagringsperspektiv. Jeg mener dette bokstavelig, ikke figurativt. De fleste erfarne administratorer har en historie om hvordan aggregering av hendelsesloggene knuste nettverksytelsen til de optimaliserte hendelseslogging.

Uansett hva du gjør, ikke bare samle inn informasjon fra servere. I dag starter de fleste kompromisser fra sluttbrukerarbeidsstasjoner. Hvis du ikke samler loggfilene fra klientdatamaskiner, vil du mangle de fleste verdifulle dataene.

Tips: Generer så mange detaljer som du trenger på det lokale systemet, men filtrer og send bare de mest verdifulle og kritiske hendelsene til det sentraliserte loggstyringssystemet. Send det som trengs for å generere varsler for alle dine viktigste sikkerhetshendelser, men la resten være på det lokale systemet. Du kan alltid hente den ekstra detalj når det trengs. Ved hjelp av denne metoden kan du få dataene du trenger for å få varsler og starte rettsmedisinske undersøkelser, men uten å overvelde nettverks-og lagringsenhetene dine. Det er alltid sjansen for at en dårlig fyr kan slette de lokale hendelsesloggdataene før du kan hente den, men i praksis har jeg nesten aldri sett det skje.

Å Få nyttig logginformasjon

den vanskeligste delen av ethvert hendelseslogg styringssystem er å få nok informasjon til å kunne oppdage alle nødvendige sikkerhetshendelser, mens ikke overveldende systemet med for mye støy. Selv i de mest effektive styringssystemene vil de fleste innsamlede hendelsesloggdataene være støy. Det er bare måten hendelseslogg ledelse fungerer.

Tips: Kontroller at dato og klokkeslett er riktig innstilt på alle systemene dine. Når du prøver å korrelere hendelser, må du ha nøyaktig tid.

hvor hendelsesloggen styringssystemer viser sin virkelige verdi er i hvor godt de filtrerer unødvendig støy og varsling på nyttige handlings hendelser. Kritiske hendelser bør alltid føre til en umiddelbar varsling og en responsiv undersøkelse. En hendelsesoppføring bør defineres som handlekraftig når hendelsesoppføringen indikerer sterk sannsynlighet for skadelig aktivitet, overdreven (vedvarende) systemaktivitet, uventet (vedvarende) fall i systemaktivitet eller virksomhetskritiske ytelsesproblemer eller feil i programmer.et godt administrasjonssystem for hendelseslogger kommer med forhåndsdefinerte vanlige varsler (f.eks. overdreven konto lockout) og tillater administratorer å lage sine egne hendelser (avvik fra forventede grunnlinjer som overskrider en viss terskel). Det kan ta flere korrelerte hendelser fra flere systemer for å generere et varsel. Avhengig av hendelsens sjeldenhet, er en enkelt hendelse (f. eks. pålogging til en falsk «felle» – konto) nok til å generere et varsel. Et godt system kommer med hendelsene de fleste administratorer vil varsle på og med nok filtre for å slough bort søppel.

Tips: start med å definere alle hendelser relatert til bedriftens nyeste og mest sannsynlige fremtidige vellykkede angrep, og finn deretter ut hvilke hendelsesmeldinger og varsler du må definere for å oppdage og stoppe disse angrepene. Du har mange, mange sikkerhetshendelser å bekymre seg for, men de viktigste å overvåke og varsle på de som mest sannsynlig vil bli brukt i fremtiden mot din bedrift.

God hendelseslogging handler om å trekke ut nødvendige kritiske hendelser og varsler fra en ellers overveldende mengde informasjon. Problemet for de fleste admins er ikke å få nok informasjon, men i å få virkelig nyttig informasjon ut av en overveldende tsunami av hendelser. En god hendelseslogg styringssystem hjelper deg å gjøre det.