Cybersikkerhet

Truslerintelligens beste praksis-tips

mm
Legg til Unite.AI blant dine foretrukne kilder på Google

Mange mennesker sier at truslerintelligens (TI) smaker godt, men få forstår hvordan man skal lage det. Det er enda færre som vet hvilke prosesser man skal engasjere for at TI skal fungere og gi avkastning. Dessuten er det en forsvinnende liten del av mennesker som vet hvordan man skal velge en leverandør av truslerintelligens, hvor man skal sjekke en indikator for feilpositiver, og om det er verdifullt å blokkere en domene som din kollega har sendt deg over WhatsApp.

Vi hadde to kommersielle APT-abonnementer, ti informasjonsutvekslinger, omtrent et dusin gratis feeds, og en omfattende liste over TOR-utgangsnoder. Vi brukte også et par kraftige reverseringsverktøy, master Powershell-skript, en Loki-scanner og et betalt VirusTotal-abonnement. Ikke at et sikkerhetsincident-svarssenter ikke kan fungere uten alle disse, men hvis du er opptatt av å fange komplekse angrep, må du gå hele veien.

Hva jeg var spesielt bekymret for, var muligheten for å automatisere sjekking av indikatorer for kompromittering (IOCs). Det finnes ingen ting som er mer umoralsk enn kunstig intelligens som erstatter en menneske i en aktivitet som krever tenkning. Imidlertid innser jeg at mitt selskap ville møte denne utfordringen tidlig eller senere, ettersom antallet våre kunder økte.

I løpet av flere års kontinuerlig TI-aktivitet, har jeg trådt på en rekke hinder, og jeg ønsker å gi noen tips som kan hjelpe nye mennesker å unngå vanlige feil.

Tip 1. Ikke set for store forhåpninger til å fange noe ved hjelp av hasjer: de fleste malware er polymorfe i dag

Truslerintelligensdata kommer i forskjellige formater og manifestasjoner. Den kan inkludere IP-adresser til botnet-kommandosentraler, e-postadresser involvert i phishing-kampanjer, og artikler om unngåingsteknikker som APT-grupper er i ferd med å starte å bruke. For å kort fortelle, disse kan være forskjellige ting.

For å sortere ut denne hele messen, foreslo David Bianco å bruke det som kalles Pyramiden av smerte. Den beskriver en korrelasjon mellom forskjellige indikatorer som du bruker for å oppdage en angriper og mengden “smerte” du vil påføre angriperen hvis du identifiserer en bestemt IOC.

For eksempel, hvis du kjenner MD5-hashen til den skadelige filen, kan den lett og nøyaktig oppdages. Imidlertid vil den ikke påføre mye smerte til angriperen, fordi tilføyelse av bare 1 bit informasjon til den filen vil fullstendig endre dens hash.

Tip 2. Prøv å bruke indikatorer som angriperen vil finne teknisk komplisert eller dyrt å endre

I forventning av spørsmålet om hvordan man skal finne ut om en fil med en gitt hash eksisterer i vårt bedriftsnettverk, vil jeg si følgende: det finnes forskjellige måter. En av de enkleste metodene er å bruke en løsning som opprettholder en database over MD5-hasher for alle eksekverbare filer innen bedriften.

La oss gå tilbake til Pyramiden av smerte. I motsetning til oppdaging ved hjelp av en hash-verdi, er det mer produktivt å identifisere angriperens TTP (taktikker, teknikker og prosedyrer). Dette er hardest å gjøre og krever mer innsats, men du vil påføre mer smerte til motparten.

For eksempel, hvis du vet at APT-crewet som målretter din sektor av økonomien sender phishing-e-poster med *.HTA-filer ombord, vil opprettelse av en oppdagingregel som søker etter slike e-postvedlegg være et hardt slag mot angriperen. De vil måtte endre spammetaktikken og kanskje til og med bruke penger på å kjøpe 0-dagers eller 1-dagers eksploateringer som ikke er billige.

Tip 3. Ikke set for store forhåpninger til oppdagingregler som er skapt av andre, fordi du må sjekke disse reglene for feilpositiver og finjustere dem

Når du kommer i gang med å opprette oppdagingregler, er det alltid en fristelse til å bruke ferdige regler. Sigma er et eksempel på en gratis repository. Det er et SIEM-uavhengig format for oppdagingmetoder som tillater deg å oversette regler fra Sigma-språk til ElasticSearch samt Splunk eller ArcSight-regler. Repositoryt inkluderer hundrevis av regler. Det ser ut som en flott ting, men djevelen, som alltid, er i detaljene.

La oss se på en av mimikatz-oppdagingreglene. Denne regelen oppdager prosesser som har forsøkt å lese minnet til lsass.exe-prosessen. Mimikatz gjør dette når den prøver å få NTLM-hasher, og regelen vil identifisere malwaret.

Imidlertid er det kritisk for oss – eksperter som ikke bare oppdager, men også responderer på hendelser – å sikre at det faktisk er en skadelig aktør. Dessverre finnes det tallrike legitime prosesser som leser lsass.exe-minne (f.eks. noen antivirusverktøy). Derfor vil en regel som denne i en virkelig verden føre til mer feilpositiver enn fordeler.

Jeg er ikke villig til å anklage noen i denne sammenhengen – alle løsninger genererer feilpositiver; det er normalt. Likevel må truslerintelligens-eksperter forstå at dobbeltsjekking og finjustering av regler fra både åpne og lukkede kilder er likevel nødvendig.

Tip 4. Sjekk domenenavn og IP-adresser for skadelig atferd ikke bare på proxyserveren og brannmuren, men også i DNS-serverloggene – og sikre deg på å fokusere både på vellykkede og mislykkede oppløsninger

Skadelige domenenavn og IP-adresser er de optimale indikatorer fra detektionsenkelhetens og mengden smerte du påfører angriperen. Imidlertid ser de ut til å være enkle å håndtere bare på overflaten. Du bør i det minste spørre deg selv hvor du skal hente domeneloggen.

Hvis du begrenser arbeidet ditt til å sjekke proxyserverloggene bare, kan du gå glipp av skadelig kode som prøver å spørre nettverket direkte eller ber om en ikke-eksisterende domenenavn generert med DGA, for å ikke nevne DNS-tunneling – ingen av disse vil være listet i loggene til en bedriftsproxyserver. Kriminelle kan også bruke VPN-tjenester der ute med avanserte funksjoner eller opprette tilpassede tunneler.

Tip 5. Overvåk eller blokkér – bestem hvilken en du skal velge bare etter å ha funnet ut hva slags indikator du har oppdaget og erkjent mulige konsekvenser av blokkering

Hvert IT-sikkerhetsekspert har møtt en ikke-trivial dilemma: å blokkere en trussel eller overvåke dens atferd og starte en undersøkelse når den utløser varsler. Noen instruksjoner oppmuntrer ubestemt til å velge blokkering, men noen ganger er det en feil.

Hvis indikatoren for kompromittering er et domenenavn brukt av en APT-gruppe, ikke blokkér det – start overvåkingen i stedet. Taktikken for å deployere målrettede angrep forutsetter nåværende tilstedeværelse av en ekstra hemmelig tilkoblingskanal, som for eksempel mobilsporing, som bare kan oppdages gjennom en grundig analyse. Automatisk blokkering vil forhindre deg i å finne denne kanalen i denne scenariot; dessuten vil motpartene raskt innse at du har lagt merke til deres triks.

På den andre siden, hvis IOC er et domenenavn brukt av crypto-ransomware, bør det blokkeres umiddelbart. Men glem ikke å overvåke alle mislykkede forsøk på å spørre de blokkerte domenene – konfigurasjonen av den skadelige encoderen kan inkludere flere Command og Control-server-URL-er. Noen av dem kan ikke være i feedene og derfor ikke blokkeres. Snart eller senere vil infeksjonen nå ut til dem for å hente krypteringsnøkkelen som umiddelbart vil bli brukt til å kryptere verten. Den eneste pålitelige måten å sikre at du har blokkert alle C&Cs er å reversere eksemplaret.

Tip 6. Sjekk alle nye indikatorer for relevans før du overvåker eller blokkérer dem

Hold i mente at trusseldata genereres av mennesker som er utsatt for feil, eller av maskin læringsalgoritmer som ikke er feilfrie heller. Jeg har vært vitne til at forskjellige leverandører av betalte rapporter om APT-gruppers aktivitet utilsiktet har lagt til legitime eksempler i listene over skadelige MD5-hasher. Gitt at selv betalte trusselrapporter inneholder lavkvalitets-IOCs, bør de som er hentet via åpen kilde-intelligens være verifisert for relevans. TI-analytikere sjekker ikke alltid indikatorer for feilpositiver, hvilket betyr at kunden må gjøre sjekkearbeidet for dem.

For eksempel, hvis du har funnet en IP-adresse brukt av en ny iterasjon av TrickBot, bør du før du bruker den i dine detektionssystemer, sikre deg på at den ikke er en del av en vertstjeneste eller en som kommer fra din egen IP. Ellers vil du ha en hard tid med å håndtere tallrike feilpositiver hver gang brukerne som besøker en nettside som bor på den vertstjenesten, går til fullstendig harmløse nettsider.

Tip 7. Automatiser alle trusseldata-arbeidsflyter til maksimum. Start med å fullstendig automatisere feilpositiv-sjekking via en advarseliste, samtidig som du instruerer SIEM til å overvåke IOCs som ikke utløser feilpositiver

For å unngå en stor mengde feilpositiver relatert til intelligens og hentet fra åpne kilder, kan du kjøre en forhåndssøkning etter disse indikatorene i advarselister. For å opprette disse listene, kan du bruke de øverste 1000 nettstedene etter trafikk, adresser til interne undernett, samt domener brukt av store tjenesteleverandører som Google (GOOGL ), Amazon (AMZN ) AWS, MS Azure og andre. Det er også en god idé å implementere en løsning som dynamisk endrer advarselister bestående av de øverste domener / IP-adresser som selskapets ansatte har aksessert i løpet av den siste uken eller måneden.

Opprettelse av disse advarselistene kan være problematisk for et medium-stort SOC, så det har mening å vurdere å adoptere såkalte truslerintelligens-plattformer.

Tip 8. Skann hele bedriften for vertindikatorer, ikke bare vertsene som er koblet til SIEM

Som regel er ikke alle vertsene i en bedrift koblet til SIEM. Derfor er det umulig å sjekke dem for en skadelig fil med en bestemt navn eller sti ved å bare bruke standard SIEM-funksjonalitet. Du kan håndtere dette problemet på følgende måter:

  1. Bruk IOC-scannere som Loki. Du kan bruke SCCM til å starte det på alle bedriftsverter og deretter sende resultater til en delt nettverksmappe.
  2. Bruk sårbarhets-scannere. Noen av dem har overholdelsesmoduser som tillater deg å sjekke nettverket for en bestemt fil i en bestemt sti.
  3. Skriv et Powershell-skript og kjør det via WinRM.

Som nevnt ovenfor, er denne artikkelen ikke ment å være en omfattende kunnskapsbase for hvordan man gjør truslerintelligens riktig. Basert på vår erfaring, likevel, vil å følge disse enkle reglene tillate nye mennesker å unngå kritiske feil mens de håndterer forskjellige indikatorer for kompromittering.

Alex er en cybersecurity-forsker med over 20 års erfaring i analyse av malware. Han har sterke ferdigheter i fjerning av malware, og han skriver for flere publikasjoner relatert til sikkerhet for å dele sin erfaring innen sikkerhet.