dette er del fire av serien” Jakt Med Splunk: Det Grunnleggende”.
Bruk av metadata og tstats for å raskt etablere situasjonsforståelse
så du vil jakte, ikke sant??? Vel, min unge padwa, hold på. Som En Splunk Jedi en gang fortalte meg, må du først gå sakte for å gå fort. Hva mener jeg med det? Vi vil, hvis du jag i trussel jakt og begynne anhengsling SPL ukritisk, risikerer du å skape hull i etterforskningen. Hvilke hull kan det være? Som en klok mann sa en Gang, Kjenn ditt nettverk. Egentlig—i dette tilfellet-vet nettverket og vertene. For å effektivt jakte, er det viktig å forstå dataene du har og ikke har for vertene dine. Uten denne kunnskapen, risikerer du å gjøre forutsetninger som fører til dårlige beslutninger mens trussel jakt.
I Dag skal jeg dele med deg min metodikk rundt innledende informasjonsinnhenting og hvordan jeg bruker metadata og tstats-kommandoene for å forstå dataene som er tilgjengelige for meg når jeg starter trusseljakt.
La oss begynne med å se på metadata. Metadata-kommandoen er en genererende kommando, som betyr at den er den første kommandoen i et søk. For de som ikke er helt oppdatert På Splunk, er det visse felt som er skrevet på indekstid. Disse feltene er _time, kilde (hvor hendelsen oppsto, kan være en filbane eller en protokoll / portverdi), sourcetype (type maskindata) og vert (vertsnavn eller IP som genererte en hendelse). Disse metadatafeltene (se hva jeg gjorde der?) kan søkes og returneres med verdier som inkluderer første gang, siste gang og teller for en bestemt verdi.
Her er et par eksempler.
sjefen min har gitt meg i oppgave å starte jakt basert på noen indikatorer nylig samlet. Min første tanke er å se at jeg har datasett tilgjengelig for meg som gjelder tiden jeg jakter på. Dette er et raskt søk som jeg kunne kjøre for å nummerere sourcetypes I Splunk de siste syv dagene.
Som du kan se, har jeg de siste syv dagene 5.162 FireEye-hendelser. Å gjøre en liten epoch time conversion, bestemmer jeg at dataene først slo min indekser På Mai 12 2017 på 2:31:00 GMT og siste gang det ble sett På min indekser Var Mai 20 2017 22:01:12 GMT. Basert på tidsområdet for søket mitt – Det var Fra 13. Mai 22: 00 GMT Til 20. Mai 22: 38: 15 GMT—jeg har høy tillit til at Mine FireEye-data er ganske nåværende, men hvis undersøkelsen min går tilbake før 12.Mai, har Jeg Ikke FireEye-data å jobbe med, noe som kan påvirke hvordan jeg nærmer meg denne aktiviteten eller redusere tilliten til å bestemme når noe først ble sett i nettverket mitt.
nå som jeg vet hvilke typer data jeg har I Splunk, la oss se hvilke verter som sender data gjennom – har jeg nåværende data for alle mine verter? Kanskje jeg vil isolere på verter som skriver til en bestemt indeks. I dette tilfellet vil jeg se alle vertene som har data i os-indeksen fordi jeg vet at data i den indeksen vil være av betydning for meg i jakten.
metadatakommandoen har ikke mange alternativer til det, men du kan begrense søket til bestemte indekser, søkekolleger eller servergrupper og til og med sourcetypes (som jeg gjorde over). Når du har et resultatsett, kan du bøye SPL musklene på resultatene for å få mer informasjon ut det. Kanskje du vil forbedre situasjonsforståelsen før jakt og sjekke om det er spesifikke verter som ikke har sendt data til Splunk de siste 24 timene.
i dette søket brukte jeg metadata-kommandoen for å få en liste over verter. Ved hjelp av kommandoene eval, search and fieldformat kunne jeg filtrere ned til verter som ikke hadde logget i mer enn 24 timer, endre tidsverdiene til noe mer brukervennlig å se enn det jeg viste i det første eksemplet, og deretter sortere og utdata i en tabellvisning som raskt kan forbrukes.
et par siste tanker om metadata. Det krever get_metadata evne til å være assosiert med en rolle brukeren har før den kan brukes. (Morsomt faktum: visste du at under hetten kjører du faktisk metadatakommandoen når du klikker På Datasammendragsknappen på søkets hjemmeside?)
og nå for noe helt annet… (Nei, egentlig ikke).
En annen kraftig, men mindre kjent kommando I Splunk er tstats. Tstats-kommandoen—i tillegg til å kunne hoppe høye bygninger i en enkelt bundet—ok, kanskje ikke) – kan produsere søkeresultater med blendende hastighet. Mye som metadata, er tstats en genererende kommando og fungerer på indekserte felt (vert, kilde, sourcetype og _time) samt datamodeller. Jeg elsker datamodeller så mye som den neste fyren, men det er ikke nok plass til å snakke om dem i dette innlegget, så la oss lagre dem for en annen gang.
i mellomtiden vil jeg forbedre min allerede etablerte situasjonsforståelse og svare på et grunnleggende spørsmål når jeg starter en jakt—hvilken informasjon har jeg tilgang til og har jeg noen blinde flekker? Kanskje jeg raskt vil få en visning i DNS-hendelsene mine.
jeg kan raskt generere totalt antall hendelser de siste syv dagene der sourcetype er stream: dns og dataene ligger i hovedindeksen. I dette søket blir data brutt ut av _time og host i 1-timers intervaller. Som metadata—når jeg utfører mitt innledende søk-kan JEG bruke SPL til å formatere dataene som jeg passer, i dette tilfellet ved hjelp av xyseries-kommandoen og deretter bruke Et Områdediagram til det for å generere en graf over hendelser som kommer fra verten der jeg samler DNS. Det er viktig å merke seg at bruk av tstats på denne måten ikke er optimal for mer enn en håndfull verter. Hvis du er ute etter en tabellutgang og teller—ingen bekymringer-dette kan være svært effektivt. Å prøve å graf for mange verter kan bli veldig opptatt, noe som gjør det vanskelig for en analytiker å raskt konsumere.
med den milde advarselen, la oss bygge et søk for raskt å identifisere verter som logger mer eller mindre data enn det som normalt forventes. Plassere grenser på data—selv når det kommer fra et stort antall verter—kan enkelt gjøres.
for dette søket ser jeg på verter som logger på indeksen ‘os’, og jeg vil se tilbake de siste syv dagene i carving tiden i 3-timers intervaller for å finne median antall hendelser etter vert. Median er bare ett statistisk alternativ jeg kan bruke; persentil og gjennomsnitt er også tilgjengelig, så bruk det du føler er riktig. Jeg så tilbake de siste 3 timene for samme informasjon. For å bestemme prosentdifferansen mellom medianen og den nåværende tellingen, delte vi for å få en prosentverdi og filtrert for resultater + / -5%. Sortering og omdøping av felt gjør det enkelt å konsumere siden jeg nå har mine uteliggere, samt å produsere en graf som viser medianen og dagens hendelsesvolumer kartlagt sammen med prosentforskjellen.