Truslerintelligens bedste praksis-tips

Mange mennesker siger, at truslerintelligens (TI) smager godt, men få forstår, hvordan man laver det. Der er endnu færre, der ved, hvilke processer man skal engagere for, at TI skal fungere og give profit. Desuden kender kun en ubetydelig del af mennesker til, hvordan man vælger en feed-udbyder, hvor man skal kontrollere en falsk positiv indikator, og om det er værd at blokere en domæne, som din kollega har sendt dig over WhatsApp.

Vi havde to kommercielle APT-abonnementer, ti informationsudvekslinger, omkring et dusin gratis feeds og en omfattende liste over TOR-udgangsnoder. Vi brugte også et par kraftfulde reverseringsværktøjer, avancerede Powershell-scripts, en Loki-scanner og et betalt VirusTotal-abonnement. Ikke fordi et sikkerhedsincidentresponscenter ikke kan fungere uden disse, men hvis du vil fange komplekse angreb, må du gå hele vejen.

Det, der især bekymrede mig, var muligheden for at automatisere kontrollen af indikatorer for kompromittering (IOCs). Der er intet så umoralsk som, at kunstig intelligens erstatter en menneskelig aktivitet, der kræver tanke. Jeg indså dog, at mit selskab ville møde denne udfordring før eller siden, da antallet af vores kunder voksede.

I løbet af flere års permanent TI-aktivitet har jeg trådt på en masse rake og vil gerne give nogle tips, der kan hjælpe nye med at undgå almindelige fejl.

Tip 1. Sæt ikke for store forhåbninger til at fange noget ved hashes: de fleste malware er polymorfe i disse dage

Truslerintelligensdata kommer i forskellige formater og manifestationer. Det kan inkludere IP-adresser på botnet Command og Control-center, e-mail-adresser, der er involveret i phishing-kampagner, og artikler om undvigelsesmetoder, som APT-grupper er ved at udnytte. For at få orden i denne rod kan David Bianco foreslå at bruge, hvad der kaldes Pyramiden af smerte. Den beskriver en korrelation mellem forskellige indikatorer, som du bruger til at opdage en angriber, og mængden af “smerte”, du vil påføre angriberen, hvis du identificerer en bestemt IOC.

For eksempel, hvis du kender MD5-hashes af den skadelige fil, kan den let og nøjagtigt opdages. Det vil dog ikke påføre angriberen megen smerte, fordi tilføjelse af blot 1 bit information til filen vil ændre dens hash fuldstændigt.

Tip 2. Prøv at bruge indikatorer, som angriberen vil finde teknisk kompliceret eller dyrt at ændre

Forudsigende spørgsmålet om, hvordan man kan finde ud af, om en fil med en given hash findes i vores virksomhedsnetværk, vil jeg sige følgende: Der er forskellige måder. En af de letteste metoder er at bruge en løsning, der opretholder en database over MD5-hashes af alle eksekverbare filer i virksomheden.

Lad os vende tilbage til Pyramiden af smerte. I modsætning til opdaging ved en hashværdi er det mere produktivt at identificere angriberens TTP (taktik, teknik og procedurer). Dette er sværere at gøre og kræver mere indsats, men du vil påføre modparten mere smerte.

For eksempel, hvis du ved, at APT-gruppen, der målretter din sektor af økonomien, sender phishing-e-mails med *.HTA-filer ombord, vil oprettelse af en opdagelsesregel, der søger efter sådanne e-mail-vedhæftninger, ramme angriberen nedenfor bæltestrengen. De vil være nødt til at ændre spammetaktikken og måske endda bruge penge på at købe 0-dages eller 1-dages eksploitationsmuligheder, som ikke er billige.

Tip 3. Sæt ikke for store forhåbninger til opdagelsesregler, der er oprettet af andre, fordi du selv må kontrollere disse regler for falske positiver og finjustere dem

Når du begynder at oprette opdagelsesregler, er der altid en fristelse til at bruge allerede eksisterende regler. Sigma er et eksempel på en gratis repository. Det er et SIEM-uafhængigt format for opdagelsesmetoder, der tillader dig at oversætte regler fra Sigma-sprog til ElasticSearch samt Splunk eller ArcSight-regler. Repositoryt indeholder hundredvis af regler. Det ser ud som en god ting, men djævlen, som altid, er i detaljen.

Lad os se på en af mimikatz-opdagelsesreglerne. Denne regel opdager processer, der har forsøgt at læse lsass.exe-processens hukommelse. Mimikatz gør dette, når den forsøger at få NTLM-hashes, og reglen vil identificere malware.

Det er dog kritisk for os – eksperter, der ikke kun opdager, men også responderer på incidenter – at sikre, at det faktisk er en maliciøs aktør. Desværre er der mange legitime processer, der læser lsass.exe-hukommelse (f.eks. visse antivirusværktøjer). Derfor vil en regel som denne i en reel verden medføre mere falske positiver end fordele.

Jeg er ikke villig til at anklage nogen i denne forbindelse – alle løsninger genererer falske positiver; det er normalt. Truslerintelligensspecialister må dog forstå, at dobbeltkontrol og finjustering af regler, der er erhvervet fra både åbne og lukkede kilder, stadig er nødvendigt.

Tip 4. Kontroller domænenavne og IP-adresser for skadelig adfærd ikke kun på proxyserveren og brandvæggen, men også i DNS-serverlogfiler – og sikrer, at du fokuserer både på succesfulde og fejlende opslag

Skadelige domænenavne og IP-adresser er de optimale indikatorer set fra detektionskompleksitet og mængden af smerte, du påfører angriberen. Det kan dog kun lade sig gøre at håndtere dem på overfladen. Du bør i hvert fald spørge dig selv, hvor du skal hente domæneloggen.

Hvis du begrænser dit arbejde til at kontrollere proxyserverlogfiler alene, kan du misse skadelig kode, der forsøger at spørge netværket direkte eller anmoder om en ikke-eksisterende domæne, der er genereret med DGA, for ikke at nævne DNS-tunneling – ingen af disse vil være listet i logfilerne for en virksomhedsproxyserver. Kriminelle kan også bruge VPN-tjenester derude med avancerede funktioner eller oprette brugerdefinerede tunneller.

Tip 5. Overvåg eller blokér – beslut, hvilken af dem du skal vælge, først efter at have fundet ud af, hvilken type indikator du har opdaget, og anerkendte de mulige konsekvenser af blokering

Hver IT-sikkerhedsekspert har stået over for en ikke-trivial dilemma: skal man blokere en trussel eller overvåge dens adfærd og starte en undersøgelse, når den udløser alarm? Nogle instruktioner opfordrer ubestemt til at vælge blokering, men nogle gange er det en fejl.

Hvis indikatoren for kompromittering er et domænenavn, der bruges af en APT-gruppe, bør du ikke blokere det – i stedet skal du overvåge det. De nuværende taktikker for at udrulle målrettede angreb forudsætter tilstedeværelsen af en yderligere hemmelig forbindelseskanal, f.eks. mobilsporing, som kun kan opdages gennem en dybdegående analyse. Automatisk blokering vil forhindre dig i at finde denne kanal i denne situation; desuden vil modparten hurtigt opdage, at du har bemærket deres manipulationer.

På den anden side, hvis IOC er et domæne, der bruges af crypto-ransomware, skal det blokere med det samme. Men glem ikke at overvåge alle fejlende forsøg på at spørge de blokerede domæner – konfigurationen af den skadelige encoder kan inkludere flere Command og Control-server-URL’er. Nogle af dem kan ikke være i feeds og derfor ikke blive blokeret. Før eller siden vil infektionen nå ud til dem for at få fat i krypteringsnøglen, der straks vil blive brugt til at kryptere værten. Den eneste pålidelige måde at sikre, at du har blokeret alle C&Cs, er at omvende eksemplet.

Tip 6. Kontroller alle nye indikatorer for relevans, før du overvåger eller blokerer dem

Husk, at trusselsdata genereres af mennesker, der er tilbøjelige til fejl, eller af maskin læringsalgoritmer, der ikke er fejlfrie. Jeg har oplevet, at forskellige udbydere af betalte rapporter om APT-gruppers aktivitet utilsigtet tilføjede legitime eksempler til listerne over skadelige MD5-hashes. Givet, at selv betalte trusselsrapporter indeholder lavkvalitets-IOCs, skal de, der er erhvervet via åben kilde-intelligence, nøje vurderes for relevans. TI-analytikere kontrollerer ikke altid deres indikatorer for falske positiver, hvilket betyder, at kunden selv må gøre kontrollen.

For eksempel, hvis du har fået en IP-adresse, der bruges af en ny iteration af TrickBot, skal du, før du bruger den i dine detektionssystemer, sikre, at den ikke er en del af en webhostingtjeneste eller en, der kommer fra din egen IP. Ellers vil du have svært ved at håndtere mange falske positiver, hver gang brugere, der besøger en side, der befinder sig på den hostingplatform, går til helt uskyldige websteder.

Tip 7. Automatiser alle trusselsdata-arbejdsprocesser til det maksimale. Start med at fuldstændigt automatisere kontrollen af falske positiver via en advarselsside, mens du instruerer SIEM til at overvåge IOCs, der ikke udløser falske positiver

For at undgå en stor mængde falske positiver i forbindelse med intelligence og åbne kilder kan du køre en forhåndssøgning efter disse indikatorer i advarselssider. For at oprette disse advarselssider kan du bruge de 1000 mest besøgte websteder, interne undernetadresser samt domæner, der bruges af store tjenesteudbydere som Google (GOOGL ), Amazon (AMZN ) AWS, MS Azure osv. Det er også en god idé at implementere en løsning, der dynamisk ændrer advarselssider, der består af de øverste domæner/IP-adresser, som virksomhedens medarbejdere har adgang til i løbet af den seneste uge eller måned.

Oprettelse af disse advarselssider kan være problematisk for en mediumstørrelse SOC, så det giver mening at overveje at antage såkaldte truslerintelligens-platforme.

Tip 8. Scann hele virksomheden for værtsindikatorer, ikke kun de værter, der er tilsluttet SIEM

Som regel er ikke alle værter i en virksomhed tilsluttet SIEM. Derfor er det umuligt at kontrollere dem for en skadelig fil med en bestemt navn eller sti ved kun at bruge standard SIEM-funktionaliteten. Du kan tage dig af dette problem på følgende måde:

1. Brug IOC-scannere som Loki. Du kan bruge SCCM til at lancere det på alle virksomhedsværter og derefter sende resultaterne til en fælles netværksmappe.
2. Brug sårbarhedsscannere. Nogle af dem har overholdelsesmodi, der tillader dig at kontrollere netværket for en bestemt fil i en bestemt sti.
3. Skriv et Powershell-script og køre det via WinRM.

Som nævnt ovenfor er denne artikel ikke ment som en omfattende videnbase om, hvordan man gør truslerintelligens rigtigt. Dommere ud fra vores erfaring vil følge disse simple regler dog tillade nye at undgå kritiske fejl, mens de håndterer forskellige indikatorer for kompromittering.