For ikke lenge siden la Splunk til en annen lisensieringsmodell - infrastrukturbasert lisensiering (). De teller antall CPU-kjerner under Splunk-servere. Veldig lik Elastic Stack-lisensiering, de teller antall Elasticsearch-noder. SIEM-systemer er tradisjonelt dyre og vanligvis er det et valg mellom å betale mye og å betale mye. Men hvis du bruker litt oppfinnsomhet, kan du sette sammen en lignende struktur.
Det ser skummelt ut, men noen ganger fungerer denne arkitekturen i produksjon. Kompleksitet dreper sikkerhet, og dreper generelt alt. Faktisk, for slike tilfeller (jeg snakker om å redusere eierkostnadene) er det en hel klasse med systemer - Central Log Management (CLM). Om det , vurderer dem undervurdert. Her er deres anbefalinger:
- Bruk CLM-funksjoner og -verktøy når det er budsjett- og bemanningsbegrensninger, sikkerhetsovervåkingskrav og spesifikke brukskrav.
- Implementer CLM for å forbedre logginnsamlings- og analysefunksjonene når en SIEM-løsning viser seg å være for dyr eller kompleks.
- Invester i CLM-verktøy med effektiv lagring, raskt søk og fleksibel visualisering for å forbedre etterforskning/analyse av sikkerhetshendelser og støtte trusseljakt.
- Sørg for at gjeldende faktorer og hensyn tas i betraktning før implementering av en CLM-løsning.
I denne artikkelen vil vi snakke om forskjellene i tilnærminger til lisensiering, vi vil forstå CLM og snakke om et spesifikt system i denne klassen - . Detaljer under kuttet.
I begynnelsen av denne artikkelen snakket jeg om den nye tilnærmingen til Splunk-lisensiering. Typer lisensiering kan sammenlignes med leiebilpriser. La oss forestille oss at modellen, når det gjelder antall CPUer, er en økonomisk bil med ubegrenset kjørelengde og bensin. Du kan gå hvor som helst uten avstandsbegrensninger, men du kan ikke gå veldig fort og følgelig tilbakelegge mange kilometer om dagen. Datalisensiering ligner på en sportsbil med modell med daglig kjørelengde. Du kan kjøre hensynsløst over lange avstander, men du må betale mer for å overskride den daglige kjørelengden.
For å dra nytte av belastningsbasert lisensiering, må du ha lavest mulig forhold mellom CPU-kjerner og GB med data lastet. I praksis betyr dette noe sånt som:
- Det minste mulige antallet spørringer til de innlastede dataene.
- Det minste antallet mulige brukere av løsningen.
- Så enkle og normaliserte data som mulig (slik at det ikke er behov for å kaste bort CPU-sykluser på etterfølgende databehandling og analyse).
Det mest problematiske her er de normaliserte dataene. Hvis du vil at en SIEM skal være en aggregator av alle loggene i en organisasjon, krever det en enorm innsats i parsing og etterbehandling. Ikke glem at du også må tenke på en arkitektur som ikke faller fra hverandre under belastning, dvs. ekstra servere og derfor ekstra prosessorer vil være nødvendig.
Datavolumlisensiering er basert på mengden data som sendes inn i maw-en til SIEM. Ytterligere datakilder straffes med rubelen (eller annen valuta), og dette får deg til å tenke på hva du egentlig ikke ønsket å samle inn. For å overliste denne lisensieringsmodellen kan du bite på dataene før de injiseres i SIEM-systemet. Et eksempel på slik normalisering før injeksjon er Elastic Stack og noen andre kommersielle SIEM-er.
Som et resultat har vi at lisensiering etter infrastruktur er effektiv når du bare trenger å samle inn visse data med minimal forhåndsbehandling, og lisensiering etter volum vil ikke tillate deg å samle inn alt i det hele tatt. Jakten på en mellomløsning fører til følgende kriterier:
- Forenkle dataaggregering og normalisering.
- Filtrering av støyende og minst viktige data.
- Tilbyr analysemuligheter.
- Send filtrerte og normaliserte data til SIEM
Som et resultat vil ikke mål-SIEM-systemer trenge å kaste bort ekstra CPU-kraft på prosessering og kan dra nytte av å identifisere bare de viktigste hendelsene uten å redusere synligheten til hva som skjer.
Ideelt sett bør en slik mellomvareløsning også gi sanntidsdeteksjons- og responsfunksjoner som kan brukes til å redusere virkningen av potensielt farlige aktiviteter og samle hele strømmen av hendelser til et nyttig og enkelt kvantum av data mot SIEM. Vel, da kan SIEM brukes til å lage ytterligere aggregeringer, korrelasjoner og varslingsprosesser.
Den samme mystiske mellomløsningen er ingen ringere enn CLM, som jeg nevnte i begynnelsen av artikkelen. Slik ser Gartner det:
Nå kan du prøve å finne ut hvordan InTrust overholder Gartners anbefalinger:
- Effektiv lagring for volumer og typer data som må lagres.
- Høy søkehastighet.
- Visualiseringsevner er ikke det grunnleggende CLM krever, men trusseljakt er som et BI-system for sikkerhet og dataanalyse.
- Dataanriking for å berike rådata med nyttige kontekstuelle data (som geolokalisering og andre).
Quest InTrust bruker sitt eget lagringssystem med opptil 40:1 datakomprimering og høyhastighets deduplisering, noe som reduserer lagringskostnader for CLM- og SIEM-systemer.
IT Security Search-konsoll med google-lignende søk
En spesialisert nettbasert IT-sikkerhetssøk (ITSS)-modul kan koble til hendelsesdata i InTrust-depotet og gir et enkelt grensesnitt for å søke etter trusler. Grensesnittet er forenklet til det punktet at det fungerer som Google for hendelsesloggdata. ITSS bruker tidslinjer for søkeresultater, kan slå sammen og gruppere hendelsesfelt, og hjelper effektivt med trusseljakt.
InTrust beriker Windows-hendelser med sikkerhetsidentifikatorer, filnavn og sikkerhetspåloggingsidentifikatorer. InTrust normaliserer også hendelser til et enkelt W6-skjema (Hvem, Hva, Hvor, Når, Hvem og Hvor Fra) slik at data fra forskjellige kilder (innfødte Windows-hendelser, Linux-logger eller syslog) kan sees i ett enkelt format og på ett enkelt format. søkekonsoll.
InTrust støtter sanntids varslings-, deteksjons- og responsfunksjoner som kan brukes som et EDR-lignende system for å minimere skader forårsaket av mistenkelig aktivitet. Innebygde sikkerhetsregler oppdager, men er ikke begrenset til, følgende trusler:
- Spraying av passord.
- Kerberoasting.
- Mistenkelig PowerShell-aktivitet, for eksempel utførelse av Mimikatz.
- Mistenkelige prosesser, for eksempel LokerGoga løsepengevare.
- Kryptering ved hjelp av CA4FS-logger.
- Logg inn med en privilegert konto på arbeidsstasjoner.
- Passord gjette angrep.
- Mistenkelig bruk av lokale brukergrupper.
Nå skal jeg vise deg noen skjermbilder av InTrust selv, slik at du kan få et inntrykk av dens evner.
Forhåndsdefinerte filtre for å søke etter potensielle sårbarheter
Et eksempel på et sett med filtre for innsamling av rådata
Et eksempel på bruk av regulære uttrykk for å skape en reaksjon på en hendelse
Eksempel med en PowerShell-sårbarhetssøkeregel
Innebygd kunnskapsbase med beskrivelser av sårbarheter
InTrust er et kraftig verktøy som kan brukes som en frittstående løsning eller som en del av et SIEM-system, som jeg beskrev ovenfor. Sannsynligvis er den største fordelen med denne løsningen at du kan begynne å bruke den umiddelbart etter installasjon, fordi InTrust har et stort bibliotek med regler for å oppdage trusler og svare på dem (for eksempel blokkering av en bruker).
I artikkelen snakket jeg ikke om boksede integrasjoner. Men umiddelbart etter installasjonen kan du konfigurere sending av hendelser til Splunk, IBM QRadar, Microfocus Arcsight eller via en webhook til et hvilket som helst annet system. Nedenfor er et eksempel på et Kibana-grensesnitt med hendelser fra InTrust. Det er allerede integrasjon med Elastic Stack, og hvis du bruker gratisversjonen av Elastic, kan InTrust brukes som et verktøy for å identifisere trusler, utføre proaktive varsler og sende varsler.
Jeg håper artikkelen ga en minimal idé om dette produktet. Vi er klare til å gi deg InTrust for testing eller gjennomføre et pilotprosjekt. Søknaden kan legges igjen på på nettstedet vårt.
Les våre andre artikler om informasjonssikkerhet:
(populær artikkel)
Kilde: www.habr.com