Hot mot threat intelligence – bästa praxis

Många människor säger att hotinformation (TI) smakar gott, men få förstår hur man lagar den. Det finns ännu färre som vet vilka processer som ska aktiveras för att TI ska fungera och ge vinst. Dessutom är antalet personer som vet hur man väljer en leverantör av hotinformation, var man ska kontrollera en indikator för falska positiva och om det är värt att blockera en domän som en kollega har skickat via WhatsApp försumbart.

Vi hade två kommersiella APT-prenumerationer, tio informationsutbyten, ett dussin fria flöden och en omfattande lista över TOR-utgångsnoder. Vi använde också ett par kraftfulla reverseringsverktyg, avancerade Powershell-skript, en Loki-scanner och en betald VirusTotal-prenumeration. Inte för att ett säkerhetsincidenthanteringssystem inte skulle fungera utan allt detta, men om du vill fånga komplexa attacker måste du gå hela vägen.

Det som bekymrade mig särskilt var möjligheten att automatisera kontrollen av indikatorer för kompromettering (IOCs). Det finns ingenting som är så omoraliskt som att artificiell intelligens ersätter en människa i en aktivitet som kräver tanke. Men jag insåg att mitt företag skulle ställas inför den utmaningen förr eller senare, eftersom antalet våra kunder ökade.

Under flera års kontinuerlig TI-verksamhet har jag trampat på en mängd hinder och jag vill ge några tips som kan hjälpa nybörjare att undvika vanliga misstag.

Tips 1. Sätt inte för stora förhoppningar till att fånga saker med hjälp av hash-värden: de flesta malwares är polymorfa idag

Hotinformationsdata kommer i olika format och manifestationer. Den kan innehålla IP-adresser för botnätverks kommandocentraler, e-postadresser som är inblandade i phishing-kampanjer och artiklar om undvikningstekniker som APT-grupper är på väg att börja använda. För att lösa detta problem föreslog David Bianco att använda det som kallas Pyramid of Pain. Det beskriver en korrelation mellan olika indikatorer som du använder för att upptäcka en angripare och den mängd “smärta” som du kommer att orsaka angriparen om du identifierar en specifik IOC.

Till exempel, om du känner till MD5-hashes värdet för den skadliga filen, kan den enkelt och exakt upptäckas. Men det kommer inte att orsaka så mycket smärta för angriparen, eftersom tillägg av bara 1 bit information till den filen kommer att helt ändra dess hash.

Tips 2. Försök att använda indikatorer som angriparen kommer att ha tekniska svårigheter eller dyra att ändra

I förväg kan man fråga sig hur man kan ta reda på om en fil med ett visst hash-värde finns i vårt företagsnätverk. Jag säger följande: det finns olika sätt. Ett av de enklaste sätten är att använda en lösning som underhåller en databas med MD5-hashes för alla exekverbara filer inom företaget.

Låt oss gå tillbaka till Pyramid of Pain. I motsats till upptäckt med hjälp av ett hash-värde är det mer produktivt att identifiera angriparens TTP (taktik, teknik och procedur). Det är svårare att göra och kräver mer ansträngning, men du kommer att orsaka mer smärta för motståndaren.

Till exempel, om du vet att APT-gruppen som riktar sig mot din ekonomiska sektor skickar phishing-e-post med *.HTA-filer ombord, då skapar du en upptäcktsregel som letar efter sådana e-postbilagor kommer att slå angriparen under bältet. De kommer att behöva ändra spam-taktiken och kanske till och med köpa 0-dag eller 1-dag-exploater som inte är billiga.

Tips 3. Sätt inte för stora förhoppningar till upptäcktsregler som skapats av någon annan, eftersom du måste kontrollera dessa regler för falska positiva och finjustera dem

När du börjar skapa upptäcktsregler finns det alltid en frestelse att använda färdiga regler. Sigma är ett exempel på en fri repository. Det är ett SIEM-oberoende format för upptäcktsmetoder som tillåter dig att översätta regler från Sigma-språk till ElasticSearch samt Splunk eller ArcSight-regler. Repositoryn innehåller hundratals regler. Det verkar som en bra sak, men djävulen, som alltid, är i detaljerna.

Låt oss titta på en av mimikatz-upptäcktsreglerna. Denna regel upptäcker processer som försökt läsa minnet av lsass.exe-processen. Mimikatz gör detta när den försöker hämta NTLM-hashes, och regeln kommer att identifiera skadlig kod.

Men det är kritiskt för oss – experter som inte bara upptäcker utan också svarar på incidenter – att se till att det faktiskt är en skadlig aktör. Tyvärr finns det många legitima processer som läser lsass.exe-minne (t.ex. vissa antivirusverktyg). Därför kommer en regel som den i en verklig situation att orsaka fler falska positiva än fördelar.

Jag är inte villig att anklaga någon i detta avseende – alla lösningar genererar falska positiva; det är normalt. Men hotinformationspecialister måste förstå att dubbelkontroll och finjustering av regler från både öppna och stängda källor fortfarande är nödvändigt.

Tips 4. Kontrollera domännamn och IP-adresser för skadligt beteende inte bara på proxyservern och brandväggen utan också i DNS-servrarloggarna – och se till att fokusera både på lyckade och misslyckade upplösningar

Skadliga domännamn och IP-adresser är de optimala indikatorerna ur detektionsenkelhetens och den mängd smärta som du orsakar angriparen. Men de verkar enkla att hantera bara vid första anblicken. Minst, bör du fråga dig var du ska hämta domänloggen.

Om du begränsar ditt arbete till att kontrollera proxyserverloggarna bara, kan du missa skadlig kod som försöker fråga nätverket direkt eller begär en icke-existerande domännamn som genereras med DGA, för att inte tala om DNS-tunneling – ingen av dessa kommer att listas i loggarna för en företagsproxyserver. Kriminella kan också använda VPN-tjänster där ute med avancerade funktioner eller skapa anpassade tunnlar.

Tips 5. Övervaka eller blockera – bestäm vilket du ska välja först efter att ha funnit ut vad för slags indikator du har upptäckt och erkänt de möjliga konsekvenserna av blockering

Varje IT-säkerhetsexpert har ställts inför ett icke-trivialt dilemma: att blockera ett hot eller övervaka dess beteende och starta en utredning när det utlöser larm. Vissa instruktioner uppmuntrar tydligt till blockering, men ibland är det ett misstag att göra det.

Om indikatorn för kompromettering är ett domännamn som används av en APT-grupp, blockera det inte – börja övervaka det istället. De nuvarande taktikerna för att distribuera riktade attacker förutsätter närvaron av en ytterligare hemlig anslutningskanal, till exempel cellspårningsappar som bara kan upptäckas genom en djupgående analys. Automatisk blockering kommer att förhindra att du upptäcker den kanalen i det här scenariot; dessutom kommer motståndarna att snabbt inse att du har märkt deras förehavanden.

Å andra sidan, om IOC är ett domän som används av kryptoransomware, bör det blockeras omedelbart. Men glöm inte att övervaka alla misslyckade försök att fråga de blockerade domänerna – konfigurationen av den skadliga koden kan innehålla flera kommandocentral-URL:er. Vissa av dem kan inte finnas i flödena och kommer därför inte att blockeras. Till slut kommer infektionen att nå ut till dem för att hämta krypteringsnyckeln som kommer att användas omedelbart för att kryptera värden. Det enda tillförlitliga sättet att säkerställa att du har blockerat alla C&C är att omvända exemplet.

Tips 6. Kontrollera alla nya indikatorer för relevans innan du övervakar eller blockerar dem

Tänk på att hotdata genereras av människor som är benägna att göra fel, eller av maskin inlärningsalgoritmer som inte är felfria heller. Jag har sett olika leverantörer av betalda rapporter om APT-gruppers aktivitet som oavsiktligt lägger till legitima prover till listan över skadliga MD5-hashes. Med tanke på att även betalda hotrapporter innehåller lågkvalitativa IOCs, bör de som erhålls via öppen källinformation definitivt granskas för relevans. TI-analytiker kontrollerar inte alltid sina indikatorer för falska positiva, vilket innebär att kunden måste göra kontrollarbetet för dem.

Till exempel, om du har fått en IP-adress som används av en ny iteration av TrickBot, innan du använder den i dina upptäcktsystem, bör du säkerställa att den inte är en del av en värdtjänst eller en som kommer från din IP. Annars kommer du att ha svårt att hantera många falska positiva när användare som besöker en webbplats som finns på den värdtjänsten går till helt ofarliga webbsidor.

Tips 7. Automatisera alla hotdataarbetsflöden till max. Börja med att fullständigt automatisera kontrollen av falska positiva via en varningslista medan du instruerar SIEM att övervaka IOCs som inte utlöser falska positiva

För att undvika ett stort antal falska positiva relaterade till intelligens och erhållna från öppna källor, kan du köra en preliminär sökning efter dessa indikatorer i varningslistor. För att skapa dessa listor kan du använda de 1000 webbplatserna med mest trafik, adresser till interna undernät samt domäner som används av stora tjänsteleverantörer som Google (GOOGL ), Amazon (AMZN ) AWS, MS Azure och andra. Det är också en bra idé att implementera en lösning som dynamiskt ändrar varningslistor som består av de översta domänerna/IP-adresserna som företagets anställda har åtkomst till under den senaste veckan eller månaden.

Att skapa dessa varningslistor kan vara problematiskt för ett medelstort SOC, så det är meningsfullt att överväga att anta så kallade hotinformationsplattformar.

Tips 8. Sök igenom hela företaget efter värdsindikatorer, inte bara de värdsystem som är anslutna till SIEM

Som regel är inte alla värdsystem i ett företag anslutna till SIEM. Därför är det omöjligt att kontrollera dem för en skadlig fil med ett specifikt namn eller sökväg med hjälp av standardfunktionen i SIEM. Du kan ta hand om detta problem på följande sätt:

1. Använd IOC-scanner som Loki. Du kan använda SCCM för att starta det på alla företagsvärdsystem och sedan vidarebefordra resultaten till en delad nätverksmapp.
2. Använd sårbarhetsscanner. Vissa av dem har efterlevnadslägen som tillåter dig att kontrollera nätverket för en specifik fil i en specifik sökväg.
3. Skriv ett Powershell-skript och kör det via WinRM.

Som nämnts ovan är detta inte tänkt att vara en omfattande kunskapsbas om hur man gör hotinformation rätt. Men enligt vår erfarenhet kommer att följa dessa enkla regler att tillåta nybörjare att undvika kritiska misstag när de hanterar olika indikatorer för kompromettering.