TS Total Sight. Ett verktyg för insamling av händelser, incidentanalys och automatisering av hotrespons.

God dag, i tidigare artiklar har vi bekantat oss med hur ELK Stack fungerar. Nu ska vi diskutera möjligheter som en säkerhetsspecialist kan realisera med dessa system. Vilka loggar bör och kan samlas in i Elasticsearch? Vi kommer att titta på vilken statistik som kan erhållas genom att konfigurera dashboards och om det finns någon vinning med detta. Hur kan vi implementera automatisering av säkerhetsprocesser med hjälp av ELK-stacken? Vi kommer att sammanställa systemets arkitektur. Sammanfattningsvis är implementeringen av all funktionalitet en mycket stor och svår uppgift, därför har vi givit den ett eget namn – TS Total Sight.

För närvarande ökar populariteten för lösningar som konsoliderar och analyserar säkerhetsincidenter på ett och samma logiska ställe. Som ett resultat får specialisten statistik och en handlingsplan för att förbättra säkerhetsläget i organisationen. Det är en sådan uppgift vi har ställt oss i användningen av ELK-stacken, och vi har därför delat upp huvudsaklig funktionalitet i fyra avsnitt:

1. Statistik och visualisering;
2. Upptäckte säkerhetsincidenter;
3. Prioritering av incidenter;
4. Automatisering av säkerhetsprocesser.

Nedan kommer vi att titta närmare på varje del.

Upptäckte säkerhetsincidenter

Huvuduppgiften med att använda Elasticsearch i vårt fall är att endast samla in säkerhetsincidenter. Säkerhetsincidenter kan samlas in från alla skyddsmedel, förutsatt att de stödjer någon form av loggöverföring; standard är syslog eller att spara till fil via SCP.

Vi kan ge några standardexempel på skyddsmedel och annat varifrån loggöverföring bör konfigureras:

1. Alla typer av NGFW (Check Point, Fortinet);
2. Alla typer av sårbarhetsscanners (PT Scanner, OpenVas);
3. Web Application Firewall (PT AF);
4. Netflow-analysatorer (Flowmon, Cisco StealthWatch);
5. AD-server.

När vi har konfigurerat loggöverföring och konfigurationsfiler i Logstash kan vi korrelera och jämföra incidenter som kommer från olika säkerhetsverktyg. För detta är det praktiskt att använda index där vi lagrar alla incidenter relaterade till en specifik enhet. Med andra ord, ett index – det är alla incidenter knutna till en enhet. Detta distributionssystem kan realiseras på två sätt.

Första alternativet Det här är inställningen av Logstash-konfigurationen. För detta behöver du duplicera loggar efter specifika fält till en separat enhet med en annan typ. Och senare använda denna typ. I exemplet klonas loggarna av IPS-bladet från Check Point-brandväggen.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

För att spara sådana händelser i en separat index beroende på loggfält, till exempel sådana som Destination IP för attacksignaturer. Du kan använda en liknande konstruktion:

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

Och på så sätt kan man spara alla incidenter i index, till exempel efter IP-adress eller domännamn på maskinen. I detta fall sparar vi i indexet «smartdefense-%{dst}», efter IP-adressen av betydelsen av signaturen.

Men olika produkter har olika fält för loggar, vilket kommer att leda till oreda och onödig minnesanvändning. Här måste du noggrant i Logstash-konfigurationens inställningar byta fält till förutbestämda, som kommer att vara lika för alla typer av incidenter, vilket också är en komplex uppgift.

Ett andra genomförandealternativ är att skriva ett skript eller en process som i realtid hämtar relevanta incidenter från Elastic-databasen och sparar dem i en ny index, det är en tung uppgift, men möjliggör arbete med loggar på det sätt man önskar, och korrelera direkt med incidenter från andra säkerhetsverktyg. Detta alternativ gör det möjligt att konfigurera loggarna så användbart som möjligt för ditt fall med maximal flexibilitet, men här uppstår problemet med att hitta en sådan specialist som kan genomföra detta.

Och självklart, den viktigaste frågan, vad kan man egentligen korrelera och upptäcka?

Här finns det flera alternativ, och det beror på vilka säkerhetsverktyg som används i din infrastruktur, här är några exempel:

1. Det mest uppenbara och enligt min mening mest intressanta alternativet för dem som har en NGFW-lösning och en sårbarhetsscanner. Detta är en jämförelse av loggarna från IPS och resultaten från sårbarhetsskanningen. Om en attack har upptäckts (inte blockerad) av IPS-systemet, och denna sårbarhet inte är åtgärdad på den slutliga enheten baserat på resultaten från scanningen — är det viktigt att slå larm, eftersom det finns en stor sannolikhet att sårbarheten har utnyttjats.
2. Många inloggningsförsök från en maskin till olika platser kan indikera skadlig aktivitet.
3. Nedladdning av virusfiler av användaren efter att ha besökt ett stort antal potentiellt farliga webbplatser.

Statistik och visualisering

Det mest uppenbara och förståeliga syftet med ELK Stack är att lagra och visualisera loggar, i tidigare artiklar har det visats hur man kan samla loggar från olika enheter med hjälp av Logstash. Efter att loggarna har skickats till Elasticsearch kan du ställa in dashboards som också nämndes, i tidigare artiklar, med den information och statistik som du behöver genom visualisering.

Exempel:

1. Dashboard för Threat Prevention-händelser med de mest kritiska händelserna. Här kan du visa vilka IPS-signaturer som har upptäckts och var de geografiskt kommer ifrån.

   

2. Dashboard för användningen av de mest kritiska applikationerna där information kan läcka.

   

3. Resultat från skanningar med vilken säkerhetsskanner som helst.

   

4. Loggar från Active Directory för användare.

   

5. Dashboard för VPN-anslutningar.

I detta fall, om man konfigurerar dashboards att uppdateras var flera sekund, kan man få ett ganska praktiskt system för övervakning av händelser i realtid, vilket sedan kan användas för den snabbaste responsen på informationssäkerhetsincidenter, om man ställer in dashboards på en separat skärm.

Prioritering av incidenter

I stora infrastrukturer kan antalet incidenter skjuta i höjden, och specialister har inte tid att hantera dem alla i tid. I detta fall är det nödvändigt att först och främst prioritera endast de incidenter som utgör ett stort hot. Därför bör systemet prioritera incidenter baserat på deras farlighet i förhållande till din infrastruktur. Det är önskvärt att konfigurera aviseringar via e-post eller Telegram om dessa händelser. Prioriteringen kan genomföras med inbyggda verktyg i Kibana genom att ställa in visualiseringar. Men aviseringar är svårare; som standard ingår inte denna funktionalitet i grundversionen av Elasticsearch, endast i den betalda versionen. Så antingen köper du den betalda versionen, eller så måste du skriva en process som i realtid meddelar specialister via mail eller Telegram.

Automatisering av informationssäkerhetsprocesser

Och en av de mest intressanta delarna är automatisering av åtgärder vid incidenter inom informationssäkerhet. Tidigare har vi implementerat denna funktionalitet för Splunk; du kan läsa mer om det i denna artikeln. Huvudidén är att IPS-policyn aldrig kontrolleras och optimeras, även om den i vissa fall är en avgörande del av informationssäkerhetsprocesserna. Till exempel, ett år efter implementeringen av NGFW och avsaknaden av optimeringsåtgärder för IPS, kommer du att ha en stor mängd signaturer med åtgärden Detect, som inte kommer att blockeras, vilket sänker informationssäkerhetsstatusen i organisationen. Här är några exempel på vad som kan automatiseras:

1. Överföring av IPS-signatur från Detect till Prevent. Om kritiska signaturer inte fungerar med Prevent, så är det oacceptabelt och en allvarlig spricka i skyddssystemet. Vi ändrar åtgärden i policyn för dessa signaturer. Denna funktionalitet kan implementeras om NGFW-enheten har REST API-funktionalitet. Detta är möjligt endast om man har programmeringskunskaper; man måste hämta den nödvändiga informationen från Elasticsearch och göra API-anrop till NGFW:s styrserver.
2. Om många signaturer upptäckts eller blockerats i nätverkstrafiken från en IP-adress, är det värt att blockera den IP-adressen tillfälligt i brandväggspolicyn. Implementation består också av att använda REST API.
3. Starta hostgranskningen med en sårbarhetsskanner om det finns ett stort antal signaturer för IPS eller andra säkerhetsmedel på denna värd. Om det är OpenVas kan du skriva ett skript som ansluter till säkerhetsskannern via ssh och startar skanningen.

TS Total Sight

Att implementera all funktionalitet är en väldigt stor och komplex uppgift. Utan programmeringskunskaper kan du konfigurera minimal funktionalitet som kan vara tillräcklig för produktionsanvändning. Men om du är intresserad av all funktionalitet kan du titta på TS Total Sight. Du kan läsa mer om det på vår webbplats. Som ett resultat kommer hela arbetsstrukturen och arkitekturen att se ut på följande sätt:

Slutsats

Vi har diskuterat vad som kan implementeras med hjälp av ELK Stack. I kommande artiklar kommer vi att titta mer detaljerat på funktionaliteten hos TS Total Sight!

Så håll utkik efter uppdateringar (Telegram, Facebook, VK, TS Solution Blog), Yandex.Dzen.

Källa: habr.com