StealthWatch: analys och incidentutredning. Del 3

Cisco StealthWatch är en analytisk lösning inom cybersäkerhet som erbjuder omfattande hotövervakning i distribuerade nätverk. StealthWatch baseras på insamling av NetFlow och IPFIX från routrar, switchar och andra nätverksenheter. Resultatet är att nätverket blir en känslig sensor, vilket gör att administratören kan se in på ställen som traditionella nätverksskydd, som Next Generation Firewall, inte kan nå.

I tidigare artiklar har jag redan skrivit om StealthWatch: första introduktionen och möjligheterna, samt utveckling och konfigurering. Nu föreslår jag att vi går vidare och diskuterar hur man bör hantera larm och utreda säkerhetsincidenter som lösningen genererar. Det kommer att ges 6 exempel som jag hoppas ger en bra förståelse för produktens nyttighet.

Först bör det sägas att StealthWatch har en viss uppdelning av larm i algoritmer och feeds. Första är olika slags larm (meddelanden) som när de aktiveras, kan upptäcka misstänkta saker i nätverket. Andra är säkerhetsincidenter. I denna artikel kommer 4 exempel på algoritmlarm och 2 exempel på feeds att diskuteras.

1. Analys av de mest omfattande interaktionerna inom nätverket

Det första steget i konfigurationen av StealthWatch är att definiera värdar och nätverk i grupper. I webbgränssnittet fliken Configure > Host Group Management skall nätverk, värdar och servrar delas in i lämpliga grupper. Man kan även skapa egna grupper. För övrigt är analysen av interaktioner mellan värdar i Cisco StealthWatch ganska bekväm, eftersom man inte bara kan spara sökfilter baserat på flöden, utan även själva resultaten.

För att börja bör man gå till fliken i webbgränssnittet Analyze > Flow Search. Sedan måste följande parametrar ställas in:

• Search Type — Top Conversations (de mest populära interaktionerna)
• Time Range — 24 hours (tidsintervall, annan kan användas)
• Search Name — Top Conversations Inside-Inside (valfritt förståeligt namn)
• Subject — Host Groups → Inside Hosts (källa — grupp av interna noder)
• Connection (kan ange portar, applikationer)
• Peer — Host Groups → Inside Hosts (mål — grupp av interna noder)
• Under Advanced Options kan man dessutom ange samlare från vilken data ses, utskriftsordning (efter bytes, flöden och så vidare). Jag lämnar det som standard.

Efter att ha tryckt på knappen Sök presenteras en lista med interaktioner som redan sorterat efter mängden överförda data.

I mitt exempel, värden 10.150.1.201 (servern) inom bara en ström överförde 1,5 GB trafik till värden 10.150.1.200 (klienten) via protokollet mysql. Knappen Hantera kolumner möjliggör att lägga till fler kolumner i den utdata som visas.

Därefter kan administratören skapa en anpassad regel som triggas kontinuerligt för denna typ av interaktioner och notifierar via SNMP, e-post eller Syslog.

2. Analys av de långsammaste klient-serverinteraktionerna inom nätverket med avseende på fördröjningar

Taggar SRT (Server Response Time), RTT (Round Trip Time) kan användas för att utreda serverfördröjningar och allmänna fördröjningar i nätverket. Detta verktyg är särskilt praktiskt när man snabbt vill hitta orsaken till användarnas klagomål på långsamt fungerande applikationer.

Anmärkning: praktiskt taget alla Netflow-exportörer kan inte skicka SRT, RTT-taggar, så för att se dessa data på FlowSensor måste man ofta konfigurera att skicka en kopia av trafiken från nätverksapparater. FlowSensor å sin sida tillhandahåller utökad IPFIX till FlowCollector.

Denna analys är mer praktisk att genomföra i java-applikationen StealthWatch, som installeras på administratörens dator.

Högerklicka på Inuti värdar och gå till fliken Flödestabell.

Klicka på Filter och ställ in nödvändiga parametrar. Som exempel:

• Datum/Tid — För de senaste 3 dagarna
• Prestanda — Genomsnittlig Round Trip Time >=50ms

Efter att ha visat data bör man lägga till de RTT, SRT-fält som intresserar oss. För detta, klicka på kolumnen i bildskärmen och välj med höger musknapp Hantera kolumner. Fortsätt genom att klicka på RTT, SRT-parametrarna.

Efter att ha behandlat förfrågan sorterades jag efter genomsnittlig RTT och såg de långsammaste interaktionerna.

För att få en mer detaljerad information, klicka med höger musknapp på flödet och välj Snabb vy för Flöde.

Denna information visar att värden 10.201.3.59 från gruppen Försäljning och Marknadsföring via protokollet NFS ansluter till DNS-servern under en minut och 23 sekunder och har en fruktansvärd fördröjning. I fliken Gränssnitt kan man ta reda på vilken Netflow-exportör datainformationen erhölls från. I fliken Tabell visas mer detaljerad information om interaktionen.

Därefter måste vi ta reda på vilka enheter som skickar trafik till FlowSensor och problemet ligger sannolikt där.

Dessutom är StealthWatch unikt i det att det utför deduplicering data (sammanfogar samma flöden). Därför kan man samla in praktiskt taget från alla Netflow-enheter utan att oroa sig för att det kommer att finnas många duplicerade data. Tvärtom, i detta schema hjälper det att förstå var just de största fördröjningarna uppträder.

3. Revision av kryptografiska protokoll för HTTPS

ETA (Encrypted Traffic Analytics) — en teknik utvecklad av Cisco som möjliggör detektering av skadliga anslutningar i krypterad trafik utan att dekryptera den. Dessutom gör denna teknik det möjligt att "dekompilera" HTTPS efter TLS-versioner och de kryptografiska protokoll som används vid anslutningar. Denna funktionalitet är särskilt användbar när man behöver upptäcka nätverksnoder som använder svaga kryptostandarder.

Anmärkning: man bör först installera nätverksappen på StealthWatch — ETA Kryptografisk Revision.

Vi går till fliken Dashboards → ETA Kryptografisk Revision och välja den grupp av värdar som ska analyseras. För en översikt väljer vi Inuti värdar.

Man kan observera att TLS-versionen och den motsvarande kryptostandarden visas. Enligt det vanliga mönstret i kolumnen Åtgärder går vi till Visa Flöden och sökningen startar i en ny flik.

Från utskriften framgår det att värden 198.19.20.136 under 12 timmar använde HTTPS med TLS 1.2, där krypteringsalgoritmen och säkra protokoll och hash-funktionen SHA-384. På så sätt tillåter ETA att hitta svaga algoritmer i nätverket.

4. Analys av anomalier i nätverket

Cisco StealthWatch kan känna igen trafikavvikelser i nätverket genom att använda tre verktyg: Kärnhändelser (säkerhetshändelser), Relationshändelser (interaktionshändelser mellan segment, nätverksnoder) och beteendeanalys.

Beteendeanalys gör det möjligt att över tid bygga en beteendemodell för en viss värd eller grupp av värdar. Ju mer trafik som passerar genom StealthWatch, desto mer exakta kommer triggarna att vara tack vare denna analys. I början triggar systemet ofta felaktigt, så reglerna bör "justeras" manuellt. Jag rekommenderar att man under de första veckorna ignorerar sådana händelser, eftersom systemet kommer att anpassa sig själv eller lägga till dem i undantag.

Nedan ges ett exempel på en förinställd regel Anomali, där det anges att händelsen kommer att inträffa utan larm om värden i gruppen Inre Värdar interagerar med gruppen Inre Värdar och under 24 timmar överstiger trafiken 10 megabyte..

Som exempel tar vi larmet Data Hoarding, vilket betyder att någon värd för källan/målet har laddat ner/överfört en onormalt stor mängd data från en grupp värdar eller en värd. Vi trycker på händelsen och dyker ner i tabellen där de utlösande värdarna anges. Här väljer vi den värd vi är intresserade av i kolumnen Data Hoarding.

En händelse visas som säger att 162k “poäng” har upptäckts, medan policyn tillåter 100k “poäng” — dessa är interna metrik för StealthWatch. I kolumnen Åtgärder klicka på Visa Flöden.

Vi kan se att denna värd interagerade på natten med värden 10.201.3.47 från avdelningen Försäljning & Marknadsföring via protokollet HTTPS och laddade ner 1.4 GB. Detta exempel kanske inte är helt lyckat, men detektering av interaktioner på flera hundra gigabyte sker på samma sätt. Därför kan vidare undersökning av anomalier leda till intressanta resultat.

Anmärkning: i SMC:s webgränssnitt visas data under flikarna Dashboards endast för den senaste veckan och under fliken Monitor för de senaste 2 veckorna. För att analysera äldre händelser och för att generera rapporter krävs arbete med java-konsolen på administratörens dator.

5. Identifiering av interna nätverksskanningar

Nu ska vi gå igenom några exempel på incidenter inom informationssäkerhet. Denna funktionalitet är mer intressant för säkerhetsteam.

Det finns flera förinstallerade typer av skanning för StealthWatch:

• Port Scan — källan skannar många portar på destinationens nod.
• Addr tcp scan — källan skannar hela nätverket på en och samma TCP-port, samtidigt som den ändrar destinationens IP-adress. Under tiden får källan TCP Reset-paket eller får inga svar alls.
• Addr udp scan — källan skannar hela nätverket på en och samma UDP-port, medan den ändrar destinationens IP-adress. Källan får ICMP Port Unreachable-paket eller får inga svar alls.
• Ping Scan — källan skickar ICMP-förfrågningar till hela nätverket för att söka efter svar.
• Stealth Scan tcp/udp — källan använde samma port för att ansluta till många portar på destinationens nod samtidigt.

För en mer praktisk identifiering av alla interna skannrar finns det en nätverksapp för StealthWatch — Visibility Assessment. Genom att gå till fliken Dashboards → Visibility Assessment → Internal Network Scanners kommer du att se säkerhetsincidenter relaterade till skanning under de senaste 2 veckorna.

Genom att trycka på knappen Details, kommer att visa början av scanningen av varje nätverk, trafiktrenden och motsvarande larm.

Därefter kan man "dyka in" i värden från fliken i föregående skärmbild och se säkerhetshändelser, samt aktivitet för den senaste veckan för denna värd.

Som ett exempel kommer vi att analysera händelsen Portskanning från värden 10.201.3.149 till 10.201.0.72, genom att klicka på Actions > Associated Flows. En sökning efter flöden startas och relevant information visas.

Som vi ser har denna värd från en av sina portar 51508/TCP skannat målvärden för 22, 28, 42, 41, 36, 40 (TCP). Vissa fält visar ingen information, antingen för att inte alla Netflow-fält stöds av Netflow-exportören.

6. Analys av nedladdade skadliga program med hjälp av CTA

CTA (Cognitive Threat Analytics) — molnanalys från Cisco som integreras perfekt med Cisco StealthWatch och möjliggör att komplettera signaturanalys med signatureslös analys. Detta möjliggör detektering av trojaner, nätmaskar, zero-day-malware och andra skadliga program samt deras spridning inom nätverket. Teknologin EDA som nämnts tidigare möjliggör också analys av sådana skadliga kommunikationer även i krypterad trafik.

Bokstavligen på den första fliken i webbgränssnittet finns en specialwidget Cognitive Threat Analytics. En kort sammanfattning visar på upptäckta hot på användarvärdar: trojaner, bedrägliga program, påträngande reklamprogram. Ordet “Encrypted” indikerar just EDA:s funktion. Genom att klicka på värden får man all information, inklusive säkerhetshändelser och loggar för CTA.

Genom att hålla muspekaren över varje steg i CTA visas detaljerad information om interaktionerna. För fullständig analys bör man klicka på View Incident Details, och du hamnar i en separat konsol. Cognitive Threat Analytics.

I det övre högra hörnet låter filtret dig visa händelser efter kritikalitetsnivå. När man pekar på en specifik anomal kan loggar med motsvarande tidslinje visas längst ner på skärmen. På så sätt förstås det tydligt av säkerhetsavdelningens specialist vilken infekterad värd som, efter vilka åtgärder, började utföra vilka handlingar.

Nederst visas ytterligare ett exempel — en banktrojan som infekterade värden 198.19.30.36. Denna värd började interagera med skadliga domäner, och loggarna visar information om flödena av dessa interaktioner.

Ett av de bästa lösningarna som kan finnas är att sätta en host i karantän med hjälp av den inbyggda integrationen med Cisco ISE för vidare behandling och analys.

Slutsats

Cisco StealthWatch-lösningen är en av ledarna bland nätverksövervakningsprodukter, både vad gäller nätverksanalys och informationssäkerhet. Den gör det möjligt att upptäcka illegitima interaktioner inom nätverket, applikationsfördröjningar, de mest aktiva användarna, anomalier, skadlig programvara och APT. Dessutom kan den identifiera skanningar, penetrationstestare och utföra kryptorevision av HTTPS-trafik. Ytterligare användningsområden kan du hitta på länken.

Om du vill kontrollera om allt fungerar smidigt och effektivt i ditt nätverk, skicka en förfrågan.
Inom en snar framtid planerar vi ytterligare tekniska publikationer om olika säkerhetsprodukter. Om du är intresserad av detta ämne, följ våra uppdateringar i våra kanaler (Telegram, Facebook, VK, TS Solution Blog)!

Källa: habr.com