For ikke længe siden tilføjede Splunk endnu en licensmodel - infrastrukturbaseret licensering (). De tæller antallet af CPU-kerner under Splunk-servere. Meget lig Elastic Stack-licensering, tæller de antallet af Elasticsearch-noder. SIEM-systemer er traditionelt dyre og normalt er der et valg mellem at betale meget og betale meget. Men hvis du bruger noget opfindsomhed, kan du samle en lignende struktur.
Det ser uhyggeligt ud, men nogle gange fungerer denne arkitektur i produktionen. Kompleksitet dræber sikkerhed og dræber generelt alt. Faktisk er der for sådanne tilfælde (jeg taler om at reducere omkostningerne ved ejerskab) en hel klasse af systemer - Central Log Management (CLM). Om det i betragtning af dem undervurderede. Her er deres anbefalinger:
- Brug CLM-funktioner og -værktøjer, når der er budget- og personalebegrænsninger, sikkerhedsovervågningskrav og specifikke brugskrav.
- Implementer CLM for at forbedre logindsamlings- og analysefunktionerne, når en SIEM-løsning viser sig at være for dyr eller kompleks.
- Invester i CLM-værktøjer med effektiv lagring, hurtig søgning og fleksibel visualisering for at forbedre undersøgelse/analyse af sikkerhedshændelser og understøtte trusselsjagt.
- Sørg for, at relevante faktorer og overvejelser tages i betragtning, før en CLM-løsning implementeres.
I denne artikel vil vi tale om forskellene i tilgange til licensering, vi vil forstå CLM og tale om et specifikt system i denne klasse - . Detaljer under snittet.
I begyndelsen af denne artikel talte jeg om den nye tilgang til Splunk-licensering. Typer af licenser kan sammenlignes med biludlejningspriser. Lad os forestille os, at modellen, hvad angår antallet af CPU'er, er en økonomisk bil med ubegrænset kilometertal og benzin. Du kan gå overalt uden afstandsbegrænsninger, men du kan ikke køre særlig hurtigt og derfor tilbagelægge mange kilometer om dagen. Datalicens ligner en sportsvogn med en model med dagligt kilometertal. Du kan køre hensynsløst over lange afstande, men du skal betale mere for at overskride den daglige kilometergrænse.
For at drage fordel af belastningsbaseret licensering skal du have det lavest mulige forhold mellem CPU-kerner og GB indlæst data. I praksis betyder det noget som:
- Det mindst mulige antal forespørgsler til de indlæste data.
- Det mindste antal mulige brugere af løsningen.
- Så enkle og normaliserede data som muligt (så der ikke er behov for at spilde CPU-cyklusser på efterfølgende databehandling og analyse).
Det mest problematiske her er de normaliserede data. Hvis du ønsker, at en SIEM skal være en aggregator af alle logfilerne i en organisation, kræver det en enorm indsats i parsing og efterbehandling. Glem ikke, at du også skal tænke på en arkitektur, der ikke falder fra hinanden under belastning, dvs. yderligere servere og derfor vil der være behov for yderligere processorer.
Datavolumenlicensering er baseret på mængden af data, der sendes ind i SIEM'ens maw. Yderligere datakilder kan straffes med rublen (eller anden valuta), og det får dig til at tænke over, hvad du egentlig ikke ønskede at indsamle. For at overliste denne licensmodel kan du bide dataene, før de injiceres i SIEM-systemet. Et eksempel på en sådan normalisering før injektion er Elastic Stack og nogle andre kommercielle SIEM'er.
Som et resultat heraf har vi, at licensering efter infrastruktur er effektiv, når du kun skal indsamle visse data med minimal forbehandling, og licensering efter volumen vil ikke tillade dig at indsamle alt overhovedet. Søgningen efter en mellemløsning fører til følgende kriterier:
- Forenkle dataaggregering og normalisering.
- Filtrering af støjende og mindst vigtige data.
- Giver analysemuligheder.
- Send filtrerede og normaliserede data til SIEM
Som følge heraf behøver mål-SIEM-systemer ikke at spilde yderligere CPU-kraft på behandling og kan drage fordel af kun at identificere de vigtigste hændelser uden at reducere overblikket over, hvad der sker.
Ideelt set bør en sådan middleware-løsning også give realtidsdetektions- og responsfunktioner, der kan bruges til at reducere virkningen af potentielt farlige aktiviteter og samle hele strømmen af hændelser til et nyttigt og simpelt datakvantum mod SIEM. Nå, så kan SIEM bruges til at skabe yderligere aggregeringer, korrelationer og advarselsprocesser.
Den samme mystiske mellemløsning er ingen ringere end CLM, som jeg nævnte i begyndelsen af artiklen. Sådan ser Gartner det:
Nu kan du prøve at finde ud af, hvordan InTrust overholder Gartners anbefalinger:
- Effektiv lagring af de mængder og typer af data, der skal lagres.
- Høj søgehastighed.
- Visualiseringsmuligheder er ikke, hvad grundlæggende CLM kræver, men trusselsjagt er som et BI-system til sikkerhed og dataanalyse.
- Databerigelse for at berige rådata med nyttige kontekstuelle data (som geolocation og andre).
Quest InTrust bruger sit eget lagringssystem med op til 40:1 datakomprimering og højhastigheds deduplikering, hvilket reducerer lageroverhead for CLM- og SIEM-systemer.
IT Security Search-konsol med google-lignende søgning
Et specialiseret webbaseret IT-sikkerhedssøgning (ITSS)-modul kan oprette forbindelse til hændelsesdata i InTrust-lageret og giver en enkel grænseflade til at søge efter trusler. Grænsefladen er forenklet til det punkt, at den fungerer som Google for hændelseslogdata. ITSS bruger tidslinjer til forespørgselsresultater, kan flette og gruppere begivenhedsfelter og hjælper effektivt med trusselsjagt.
InTrust beriger Windows-begivenheder med sikkerheds-id'er, filnavne og sikkerhedslogin-id'er. InTrust normaliserer også hændelser til et simpelt W6-skema (Hvem, hvad, hvor, hvornår, hvem og hvorfra), så data fra forskellige kilder (native Windows-hændelser, Linux-logfiler eller syslog) kan ses i et enkelt format og på et enkelt søgekonsol.
InTrust understøtter varslings-, detektions- og responsfunktioner i realtid, der kan bruges som et EDR-lignende system for at minimere skader forårsaget af mistænkelig aktivitet. Indbyggede sikkerhedsregler registrerer, men er ikke begrænset til at detektere følgende trusler:
- Adgangskode-sprøjtning.
- Kerberoasting.
- Mistænkelig PowerShell-aktivitet, såsom udførelse af Mimikatz.
- Mistænkelige processer, for eksempel LokerGoga ransomware.
- Kryptering ved hjælp af CA4FS-logfiler.
- Login med en privilegeret konto på arbejdsstationer.
- Gættet adgangskodeangreb.
- Mistænkelig brug af lokale brugergrupper.
Nu vil jeg vise dig et par skærmbilleder af InTrust selv, så du kan få et indtryk af dens muligheder.
Foruddefinerede filtre til at søge efter potentielle sårbarheder
Et eksempel på et sæt filtre til indsamling af rådata
Et eksempel på brug af regulære udtryk til at skabe en reaktion på en begivenhed
Eksempel med en PowerShell sårbarhedssøgningsregel
Indbygget vidensbase med beskrivelser af sårbarheder
InTrust er et kraftfuldt værktøj, der kan bruges som en selvstændig løsning eller som en del af et SIEM-system, som jeg har beskrevet ovenfor. Den største fordel ved denne løsning er nok, at du kan begynde at bruge den umiddelbart efter installationen, pga InTrust har et stort bibliotek af regler til at opdage trusler og reagere på dem (for eksempel blokering af en bruger).
I artiklen talte jeg ikke om boxed integrationer. Men umiddelbart efter installationen kan du konfigurere afsendelse af hændelser til Splunk, IBM QRadar, Microfocus Arcsight eller via en webhook til et hvilket som helst andet system. Nedenfor er et eksempel på en Kibana-grænseflade med begivenheder fra InTrust. Der er allerede integration med Elastic Stack, og hvis du bruger den gratis version af Elastic, kan InTrust bruges som et værktøj til at identificere trusler, udføre proaktive alarmer og sende notifikationer.
Jeg håber, at artiklen gav en minimal idé om dette produkt. Vi er klar til at give dig InTrust til at teste eller gennemføre et pilotprojekt. Ansøgningen kan efterlades på på vores hjemmeside.
Læs vores andre artikler om informationssikkerhed:
(populær artikel)
Kilde: www.habr.com