God eftermiddag, i tidigare artiklar har vi bekantat oss med ELK Stacks arbete. Låt oss nu diskutera de möjligheter som kan realiseras av en informationssäkerhetsspecialist för att använda dessa system. Vilka stockar kan och bör läggas in i elasticsearch. Låt oss fundera på vilken statistik som kan erhållas genom att sätta upp dashboards och om det finns någon vinst i detta. Hur kan du implementera automatisering av informationssäkerhetsprocesser med hjälp av ELK-stacken. Låt oss rita upp systemets arkitektur. Totalt sett är implementeringen av all funktionalitet en mycket stor och svår uppgift, så lösningen fick ett separat namn - TS Total Sight.
För närvarande blir lösningar som konsoliderar och analyserar informationssäkerhetsincidenter på ett logiskt ställe snabbt i popularitet, som ett resultat av att specialisten får statistik och en handlingsgräns för att förbättra tillståndet för informationssäkerhet i organisationen. Vi satte oss denna uppgift genom att använda ELK-stacken, och som ett resultat delade vi upp huvudfunktionaliteten i 4 sektioner:
- Statistik och visualisering;
- Upptäckt av informationssäkerhetsincidenter;
- Incidentprioritering;
- Automatisering av informationssäkerhetsprocesser.
Därefter kommer vi att titta närmare på var och en individuellt.
Upptäckt av informationssäkerhetsincidenter
Huvuduppgiften med att använda elasticsearch i vårt fall är att endast samla in informationssäkerhetsincidenter. Du kan samla in informationssäkerhetsincidenter från alla säkerhetsmetoder om de stöder åtminstone vissa lägen för att skicka loggar, standarden är syslog eller scp att spara till en fil.
Du kan ge standardexempel på säkerhetsverktyg med mera, varifrån du ska konfigurera vidarebefordran av loggar:
- Alla NGFW-verktyg (Check Point, Fortinet);
- Eventuella sårbarhetsskannrar (PT Scanner, OpenVas);
- Web Application Firewall (PT AF);
- nätflödesanalysatorer (Flowmon, Cisco StealthWatch);
- AD-server.
När du har konfigurerat sändningen av loggar och konfigurationsfiler i Logstash kan du korrelera och jämföra med incidenter som kommer från olika säkerhetsverktyg. För att göra detta är det bekvämt att använda index där vi kommer att lagra alla incidenter relaterade till en specifik enhet. Med andra ord, ett index är alla incidenter på en enhet. Denna distribution kan implementeras på 2 sätt.
första utföringsformen Detta är för att konfigurera Logstash-konfigurationen. För att göra detta måste du duplicera loggen för vissa fält till en separat enhet med en annan typ. Och använd sedan den här typen i framtiden. I exemplet klonas loggar från IPS-bladet på Check Point-brandväggen.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
För att spara sådana händelser i ett separat index beroende på loggfälten, till exempel, såsom Destination IP-attacksignaturer. Du kan använda en liknande konstruktion:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
Och på så sätt kan du spara alla incidenter i ett index, till exempel efter IP-adress eller efter domännamn på maskinen. I det här fallet sparar vi det i indexet "smartdefense-%{dst}", efter IP-adressen för signaturdestinationen.
Olika produkter kommer dock att ha olika loggfält, vilket leder till kaos och onödig minnesförbrukning. Och här måste du antingen noggrant ersätta fälten i Logstash-konfigurationsinställningarna med fördesignade, som kommer att vara desamma för alla typer av incidenter, vilket också är en svår uppgift.
Andra implementeringsalternativet - det här är att skriva ett skript eller en process som kommer åt den elastiska databasen i realtid, drar ut nödvändiga incidenter och sparar dem i ett nytt index, detta är en svår uppgift, men det låter dig arbeta med loggar som du vill, och korrelerar direkt med incidenter från annan säkerhetsutrustning. Detta alternativ låter dig konfigurera arbete med loggar för att vara mest användbart för ditt fall med maximal flexibilitet, men här uppstår problemet med att hitta en specialist som kan implementera detta.
Och naturligtvis den viktigaste frågan, och vad kan korreleras och upptäckas??
Det kan finnas flera alternativ här, och det beror på vilka säkerhetsverktyg som används i din infrastruktur, ett par exempel:
- Det mest uppenbara och, ur min synvinkel, det mest intressanta alternativet för dem som har en NGFW-lösning och en sårbarhetsskanner. Detta är en jämförelse av IPS-loggar och resultat av sårbarhetsskanning. Om en attack upptäcktes (inte blockerad) av IPS-systemet, och denna sårbarhet inte är stängd på slutmaskinen baserat på skanningsresultaten, är det nödvändigt att blåsa av i visselpipan, eftersom det är stor sannolikhet att sårbarheten har utnyttjats .
- Många inloggningsförsök från en dator till olika platser kan symbolisera skadlig aktivitet.
- Användare laddar ner virusfiler på grund av att de besöker ett stort antal potentiellt farliga webbplatser.
Statistik och visualisering
Det mest uppenbara och förståeliga som ELK Stack behövs för är lagring och visualisering av stockar, det visades hur du kan skapa loggar från olika enheter med Logstash. Efter att loggarna går till Elasticsearch kan du sätta upp instrumentpaneler, som också nämndes , med den information och statistik du behöver genom visualisering.
Exempel:
- Dashboard för händelseförebyggande hot med de mest kritiska händelserna. Här kan du spegla vilka IPS-signaturer som upptäckts och var de kommer ifrån geografiskt.
- Dashboard om användningen av de mest kritiska applikationerna för vilka information kan läcka.
- Skanna resultat från valfri säkerhetsskanner.
- Active Directory-loggar efter användare.
- Instrumentpanel för VPN-anslutning.
I det här fallet, om du konfigurerar instrumentpanelerna för att uppdatera med några sekunders mellanrum, kan du få ett ganska bekvämt system för att övervaka händelser i realtid, som sedan kan användas för att svara på informationssäkerhetsincidenter så snabbt som möjligt om du placerar instrumentpanelerna på en separat skärm.
Incidentprioritering
Under förhållanden med stor infrastruktur kan antalet incidenter gå ur skala och specialister kommer inte att hinna ta itu med alla incidenter i tid. I det här fallet är det först och främst nödvändigt att bara lyfta fram de incidenter som utgör ett stort hot. Därför måste systemet prioritera incidenter utifrån deras svårighetsgrad i förhållande till din infrastruktur. Det är tillrådligt att ställa in en e-post- eller telegramvarning för dessa händelser. Prioritering kan implementeras med hjälp av standardverktyg från Kibana genom att ställa in visualisering. Men med aviseringar är det svårare; som standard ingår denna funktionalitet inte i den grundläggande versionen av Elasticsearch, bara i den betalda versionen. Köp därför antingen en betalversion eller, återigen, skriv en process själv som kommer att meddela specialister i realtid via e-post eller telegram.
Automatisering av informationssäkerhetsprocesser
Och en av de mest intressanta delarna är automatiseringen av åtgärder för informationssäkerhetsincidenter. Tidigare har vi implementerat denna funktionalitet för Splunk, du kan läsa lite mer i denna . Huvudtanken är att IPS-policyn aldrig testas eller optimeras, även om den i vissa fall är en kritisk del av informationssäkerhetsprocesser. Till exempel, ett år efter implementeringen av NGFW och frånvaron av åtgärder för att optimera IPS, kommer du att samla ett stort antal signaturer med åtgärden Detect, som inte kommer att blockeras, vilket avsevärt minskar tillståndet för informationssäkerhet i organisationen. Nedan följer några exempel på vad som kan automatiseras:
- Överföring av IPS-signatur från Detect till Prevent. Om Prevent inte fungerar för kritiska signaturer är detta ur funktion och en allvarlig lucka i skyddssystemet. Vi ändrar handlingen i policyn till sådana signaturer. Denna funktionalitet kan implementeras om NGFW-enheten har REST API-funktionalitet. Detta är bara möjligt om du har programmeringskunskaper; du behöver extrahera nödvändig information från Elastcisearch och göra API-förfrågningar till NGFW-hanteringsservern.
- Om flera signaturer upptäcktes eller blockerades i nätverkstrafik från en IP-adress, är det vettigt att blockera denna IP-adress ett tag i brandväggspolicyn. Implementeringen består också av att använda REST API.
- Kör en värdskanning med en sårbarhetsskanner, om denna värd har ett stort antal IPS-signaturer eller andra säkerhetsverktyg; om det är OpenVas kan du skriva ett skript som kommer att ansluta via ssh till säkerhetsskannern och köra skanningen.
TS Total Sight
Sammantaget är implementeringen av all funktionalitet en mycket stor och svår uppgift. Utan att ha programmeringskunskaper kan du konfigurera minimifunktionaliteten, som kan vara tillräcklig för användning i produktionen. Men om du är intresserad av all funktionalitet kan du uppmärksamma TS Total Sight. Du kan hitta mer information på vår . Som ett resultat kommer hela driftschemat och arkitekturen att se ut så här:
Slutsats
Vi tittade på vad som kan implementeras med ELK Stack. I efterföljande artiklar kommer vi separat att överväga funktionaliteten hos TS Total Sight mer i detalj!
Så håll utkik (, , , ), .
Källa: will.com