Dobré odpoledne, v předchozích článcích jsme se seznámili s prací ELK Stack. Nyní si proberme možnosti, které může specialista na informační bezpečnost realizovat při používání těchto systémů. Jaké protokoly mohou a měly by být zadány do elasticsearch. Zvažme, jaké statistiky lze získat nastavením dashboardů a zda je v tom nějaký zisk. Jak můžete implementovat automatizaci procesů informační bezpečnosti pomocí ELK stacku. Pojďme sestavit architekturu systému. Celkově je implementace veškeré funkcionality velmi rozsáhlý a obtížný úkol, takže řešení dostalo samostatný název – TS Total Sight.
V současné době rychle získávají na popularitě řešení, která konsolidují a analyzují incidenty informační bezpečnosti na jednom logickém místě, v důsledku čehož specialista dostává statistiky a hranice akce ke zlepšení stavu informační bezpečnosti v organizaci. Tento úkol jsme si stanovili pomocí ELK stacku a v důsledku toho jsme hlavní funkcionalitu rozdělili do 4 sekcí:
- Statistiky a vizualizace;
- Detekce incidentů informační bezpečnosti;
- Upřednostňování incidentů;
- Automatizace procesů informační bezpečnosti.
Dále se na každý podíváme blíže.
Detekce incidentů informační bezpečnosti
Hlavním úkolem použití elasticsearch je v našem případě shromažďovat pouze incidenty informační bezpečnosti. Incidenty zabezpečení informací můžete sbírat z jakýchkoli bezpečnostních prostředků, pokud podporují alespoň některé režimy zasílání logů, standardem je ukládání syslog nebo scp do souboru.
Můžete uvést standardní příklady bezpečnostních nástrojů a další, odkud byste měli nakonfigurovat předávání protokolů:
- Jakékoli nástroje NGFW (Check Point, Fortinet);
- Jakékoli skenery zranitelnosti (PT Scanner, OpenVas);
- Web Application Firewall (PT AF);
- netflow analyzátory (Flowmon, Cisco StealthWatch);
- AD server.
Jakmile nakonfigurujete odesílání protokolů a konfiguračních souborů v Logstash, můžete korelovat a porovnávat s incidenty pocházejícími z různých bezpečnostních nástrojů. K tomu je vhodné použít indexy, do kterých budeme ukládat všechny incidenty související s konkrétním zařízením. Jinými slovy, jeden index jsou všechny incidenty na jednom zařízení. Tato distribuce může být implementována 2 způsoby.
první provedení Toto slouží ke konfiguraci konfigurace Logstash. Chcete-li to provést, musíte duplikovat protokol pro určitá pole do samostatné jednotky s jiným typem. A pak tento typ použít v budoucnu. V příkladu jsou protokoly klonovány z IPS blade firewallu Check Point.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Chcete-li uložit takové události do samostatného indexu v závislosti na polích protokolu, například jako signatury útoku na cílovou IP. Můžete použít podobnou konstrukci:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
A tímto způsobem můžete uložit všechny incidenty do indexu, například podle IP adresy nebo názvu domény stroje. V tomto případě jej uložíme do indexu "smartdefense-%{dst}", podle IP adresy cíle podpisu.
Různé produkty však budou mít různá pole protokolu, což povede k chaosu a zbytečné spotřebě paměti. A zde buď budete muset pečlivě nahradit pole v nastavení konfigurace Logstash za předem navržená, která budou stejná pro všechny typy incidentů, což je také obtížný úkol.
Druhá možnost implementace - jedná se o psaní skriptu nebo procesu, který v reálném čase přistoupí k elastické databázi, vytáhne potřebné incidenty a uloží je do nového indexu, je to obtížný úkol, ale umožňuje vám pracovat s protokoly, jak chcete, a přímo korelovat s incidenty z jiných bezpečnostních zařízení. Tato možnost umožňuje konfigurovat práci s logy tak, aby byla pro váš případ co nejužitečnější s maximální flexibilitou, zde však nastává problém s hledáním specialisty, který to dokáže implementovat.
A samozřejmě nejdůležitější otázka, a co lze korelovat a zjistit??
Zde může být několik možností a záleží na tom, jaké bezpečnostní nástroje se používají ve vaší infrastruktuře, několik příkladů:
- Nejviditelnější a z mého pohledu nejzajímavější možnost pro ty, kteří mají řešení NGFW a skener zranitelnosti. Toto je porovnání protokolů IPS a výsledků skenování zranitelnosti. Pokud byl systémem IPS detekován (neblokován) útok a tato zranitelnost není na základě výsledků skenování na koncovém stroji uzavřena, je nutné odpískat, protože je vysoká pravděpodobnost, že byla zranitelnost zneužita .
- Mnoho pokusů o přihlášení z jednoho počítače na různá místa může symbolizovat škodlivou aktivitu.
- Uživatel stahuje virové soubory kvůli návštěvě velkého množství potenciálně nebezpečných stránek.
Statistiky a vizualizace
Nejviditelnější a nejsrozumitelnější věcí, pro kterou je ELK Stack potřeba, je ukládání a vizualizace protokolů, bylo ukázáno, jak můžete vytvářet protokoly z různých zařízení pomocí Logstash. Poté, co protokoly přejdou do Elasticsearch, můžete nastavit dashboardy, které byly také zmíněny , s informacemi a statistikami, které potřebujete prostřednictvím vizualizace.
Příklady:
- Dashboard pro události prevence hrozeb s nejkritičtějšími událostmi. Zde můžete odrážet, které signatury IPS byly detekovány a odkud geograficky pocházejí.
- Dashboard o používání nejkritičtějších aplikací, u kterých mohou unikat informace.
- Výsledky skenování z jakéhokoli bezpečnostního skeneru.
- Protokoly služby Active Directory podle uživatele.
- Panel připojení VPN.
V tomto případě, pokud nakonfigurujete dashboardy tak, aby se aktualizovaly každých pár sekund, můžete získat poměrně pohodlný systém pro monitorování událostí v reálném čase, který pak lze použít pro nejrychlejší reakci na incidenty zabezpečení informací, pokud panely umístíte na samostatné obrazovka.
Upřednostňování incidentů
V podmínkách velké infrastruktury může počet incidentů jít mimo rozsah a specialisté nebudou mít čas řešit všechny incidenty včas. V tomto případě je nutné především upozornit pouze na ty incidenty, které představují velkou hrozbu. Systém proto musí upřednostňovat incidenty na základě jejich závažnosti ve vztahu k vaší infrastruktuře. Na tyto události je vhodné nastavit upozornění e-mailem nebo telegramem. Stanovení priorit lze implementovat pomocí standardních nástrojů Kibana nastavením vizualizace. S notifikacemi je to ale složitější, ve výchozím nastavení tato funkce není součástí základní verze Elasticsearch, pouze placená verze. Proto si buď kupte placenou verzi, nebo si opět sepište proces, který specialisty v reálném čase upozorní e-mailem nebo telegramem.
Automatizace procesů informační bezpečnosti
A jednou z nejzajímavějších částí je automatizace akcí pro incidenty informační bezpečnosti. Dříve jsme tuto funkcionalitu implementovali pro Splunk, v tomto si můžete přečíst trochu více . Hlavní myšlenkou je, že politika IPS není nikdy testována ani optimalizována, i když v některých případech je kritickou součástí procesů informační bezpečnosti. Například rok po implementaci NGFW a absenci akcí pro optimalizaci IPS se vám akcí Detect nashromáždí velké množství podpisů, které nebudou blokovány, což značně snižuje stav informační bezpečnosti v organizaci. Níže uvádíme několik příkladů toho, co lze automatizovat:
- Přenos IPS podpisu z Detect to Prevent. Pokud Prevent nefunguje pro kritické signatury, pak je to mimo provoz a vážná mezera v systému ochrany. Na takové podpisy změníme akci v politice. Tuto funkci lze implementovat, pokud má zařízení NGFW funkci REST API. To je možné pouze v případě, že máte programátorské dovednosti; potřebujete extrahovat potřebné informace z Elastcisearch a odesílat požadavky API na řídicí server NGFW.
- Pokud bylo zjištěno nebo zablokováno více podpisů v síťovém provozu z jedné IP adresy, pak má smysl tuto IP adresu na chvíli zablokovat v zásadách brány firewall. Implementace také spočívá v použití REST API.
- Spusťte skenování hostitele pomocí skeneru zranitelnosti, pokud má tento hostitel velký počet podpisů IPS nebo jiných bezpečnostních nástrojů; pokud je to OpenVas, můžete napsat skript, který se připojí přes ssh k bezpečnostnímu skeneru a spustí skenování.
TS Total Sight
Celkově je implementace všech funkcí velmi rozsáhlý a obtížný úkol. Bez znalosti programování můžete nakonfigurovat minimální funkčnost, která může být dostatečná pro použití v produkci. Pokud vás ale zajímají všechny funkce, můžete věnovat pozornost TS Total Sight. Více podrobností najdete na našem . V důsledku toho bude celé operační schéma a architektura vypadat takto:
Závěr
Podívali jsme se na to, co lze implementovat pomocí ELK Stack. V následujících článcích se budeme samostatně podrobněji zabývat funkčností TS Total Sight!
Takže zůstaňte naladěni (, , , ), .
Zdroj: www.habr.com