V dnešní době přináší kyberprostor rozličné hrozby, které vznikají a vyvíjejí se každý den. Útočníci nacházejí nové cesty, kterými se mohou infiltrovat do kyberprostoru organizací a dosáhnout svého cíle. Tím může být např. získání citlivých údajů, přesvědčení obchodních partnerů k odeslání platby na účet útočníka, paralýza společnosti nebo prostý přeprodej získaného přístupu do infrastruktury společnosti na online tržištích. Analytici ze Security Operation Center (SOC) jsou pro firmy, případně jejich dodavatele SOC řešení, první linií obrany, která má za cíl správně rozpoznat nestandardní situace a reagovat na ně. Jak ale zajistit, že tým nestagnuje a je schopen dodat, co se od něj očekává v prostředí, kde se mění pravidla hry až nepřiměřeně rychle? Přesně o tom bude pojednávat tento článek. Většina poznatků je odpozorována z vlastní praxe vedení SOC týmů.
Security Operations SOAR SIEM SOC Cyber Threat Intelligence
Role SOCu
SOC je oddělení, které je zodpovědné za úspěšné rozpoznání hrozby a zvolení vhodné a efektivní reakce. Funguje zpravidla na principu přijímání výstrah na nestandardní chování v infrastruktuře, což může znamenat bezprostřední hrozbu právě probíhajícího kybernetického útoku. Tým musí celou událost řádně zanalyzovat a rozhodnout, zda se jedná o oprávněný nebo falešný poplach. Při skutečné hrozbě poté musí tým hrozbu zmitigovat – zajistit, že se nebude dále šířit prostředím. To může často provést sám nebo eventuálně za pomoci jiného týmu, který má daný systém pod správou. Je nutno uvést, že postupy se v IT a OT prostředí značně odlišují. Následně tým buď samostatně, nebo v kombinaci s ostatními přechází do fáze bližšího zkoumání hrozby, snaží se systémy zbavit kompromitace a zajistit jejich návrat do produkčního prostředí. V neposlední řadě se také snaží z daného incidentu ponaučit a navrhnout možná zlepšení detekcí a procesů. [1]
Další aktivitou, do které lze SOC velmi dobře zapojit, je implementace tzv. Threat Huntingu (hledání hrozeb v prostředí na základě logů), ovšem vytvoření efektivní detekce pomůže analytikům zachytit existenci hrozby zpravidla dříve. Ve větších organizacích bývá pro Threat Hunting alokován speciální tým.
Pouze z představení role SOC týmu je zřejmé, že se jedná o místo, kde nedostatečná informovanost a znalost nových hrozeb, může mít pro společnost fatální následky. Práce SOC analytika je mnohdy náročná a nedává jednotlivcům prostor pro to, aby sami hledali a vyhodnocovali, v jaké oblasti a jak zlepšit schopnost společnosti efektivně reagovat na nové techniky útoků.
Obr. 1: Cyklus Security Incident Response [1]
Kybernetická obrana je týmová hra
SOC rozhodně není jediným týmem, který je zapojen do přípravy na možný útok. Většinou je součástí většího oddělení kyberbezpečnostní obrany. V ideálním případě se v takovém oddělení nachází tým SIEM inženýrů, kteří shromažďují potřebné logy, vytvářejí a upravují pravidla pro detekce nových hrozeb.
Zde se dostává na řadu další člen týmu či ve větších organizacích specializovaný tým – Cyber Threat Intelligence (CTI). Ten má za úkol monitorovat, jaký je vývoj trendů v útocích, informovat o nich nejen management, ale především právě týmy, které jsou zodpovědné za vytváření detekčních pravidel. Vytvářejí reporty a sdílejí informace o nových typech útoků a trendech tak, jak potřebuje každý ze stakeholderů, který má svoji roli v přípravě na kyberbezpečnostní incident. [2]
Při této kooperaci je velmi doporučeno používat MITRE ATT&CK framework, který má za cíl umožnit snadno mapovat CTI analytikům techniky, taktiky a procedury útočníků, které jsou na vzestupu. Detekční inženýři dle toho mohou snadno zjistit, zda mají nebo nemají k dispozici logy, které jim umožní vytvořit efektivní detekce. [3]
Tým SOC analytiků a Incident responderů tento framework může použít k ověření pokrytí svých znalostí a zaměřit se na zlepšení svých schopností v sekcích, které jsou hojně využívané během útoků, ale tým o nich nemá až tak dobré povědomí a kupříkladu nemá k dispozici žádné procesy, jak na daný typ akce útočníka reagovat.
Bez čeho se dnes žádný SOC neobejde, je využívání různých databází již známých maligních hashů, IP adres a URL adres. Kontrola nalezených informací by měla být jednou ze základních akcí, které má tým uvedeny v procesech, jak reagovat na detekci hrozby. Existuje velké množství webových stránek, které lze použít pro základní OSINT (Open Source Intelligence). Jako příklady lze uvést VirusTotal, AbuseIPDB nebo Cisco Talos. Další možností je také postavení vlastní TIP (Threat Intelligence Platform), do níž lze připojit externí důvěryhodné zdroje a lze v ní dokumentovat indikátory kompromitace, které jste viděli ve svém prostředí.
Na základě takto sbíraných a velmi aktuálních dat je opět možné vytvořit vlastní detekce v monitorovacím systému. Jedním z open source řešení, které je hojně využívané napříč kyberbezpečnostní komunitou, je MISP. [4]
Také je nutno zmínit, že mnoho organizací nebo i státních agentur pravidelně sdílí informace o nejnovějších hrozbách prostřednictvím reportů. Velmi doporučuji vyhledání těch, které jsou relevantní pro vaši organizaci, a přihlásit SOC k jejich odběru.
Přehlednost a jednoduchost nástrojů
SOC pracuje zpravidla s vícero technologiemi od různých dodavatelů. To znamená, že analytici mají několik prostředí, které musejí aktivně monitorovat. Pro efektivní monitoring je nutné zajistit, že upozornění ze všech nástrojů, které SOC používá, jsou přenesena do centrálního managementu (Case Management). Ve většině případů SOC potřebuje přístup i do původních nástrojů, odpadá ovšem nutnost monitoringu několika různých dashboardů pouze za účelem sledování nových upozornění. S tím také souvisí vzájemná synchronizace statusů. Nejen pro přehled managementu, ale např. i z důvodu auditingu je potřeba se ujistit, že všechna varování, která jsou zanalyzovaná a zdokumentovaná v centrálním managementu, mají informace o výsledku vyhodnocení zapsané i v původním systému a varování jsou tam řádně uzavírána. V opačném případě se snadno můžete dostat do situace, že byť jsou všechny výstrahy řádně zanalyzovány a zavřeny v centrálním řešení, v původním nástroji se jejich množství hromadí a situace se stává nepřehlednou. To může být problémem v momentu, kdy např. dojde k výpadku hlavního monitoringu nebo pouze souvisejícího konektoru mezi systémy. Tuto akci lze ve většině případů zautomatizovat, a zabránit tak zdvojené práci analytiků.
Obr. 2: Možnost využití MITRE ATT&CK® [3]
se ujistit, že všechna varování, která jsou zanalyzovaná a zdokumentovaná v centrálním managementu, mají informace o výsledku vyhodnocení zapsané i v původním systému a varování jsou tam řádně uzavírána. V opačném případě se snadno můžete dostat do situace, že byť jsou všechny výstrahy řádně zanalyzovány a zavřeny v centrálním řešení, v původním nástroji se jejich množství hromadí a situace se stává nepřehlednou. To může být problémem v momentu, kdy např. dojde k výpadku hlavního monitoringu nebo pouze souvisejícího konektoru mezi systémy. Tuto akci lze ve většině případů zautomatizovat, a zabránit tak zdvojené práci analytiků.
Znalost prostředí
Dalším velmi důležitým faktorem je zajistit, že SOC zná prostředí organizace. Je nutné, aby tým měl přístup k informacím o tom, co má dané zařízení za účel, jestli je přístupné z internetu, jak kritické je pro danou společnost nebo kdo je za něj zodpovědný. K tomu zpravidla slouží centrální konfigurační databáze (CMDB), které jsou v ideálním případě součástí nástroje pro zaznamenávání incidentů v organizaci. I infrastruktury společností se mění velmi rychle a je nutné, aby SOC měl vždy k dispozici aktuální informace.
Speciálně zde nyní zmiňuji cloudová prostředí, jelikož ta mohou být často mimo zmíněné centrální konfigurační databáze. V prostředích, kde je pro uživatele relativně snadné si vytvořit virtuální systém v cloudu, musí být zajištěno, že SOC dovede získat potřebné informace co nejrychleji.
Automatizace a machine learning
V momentu, kdy má tým zajištěné všechny části z předchozích částí článku, přichází na řadu automatizace. Sami útočníci využívají mnohdy její různé varianty – od přichystaných skriptů až po využívání AI a LLM. Tým výzkumníků z Cornwell University již dokázal, že při využití týmu LLM agentů řízených HPTSA (Hierarchical Planning with Task-Specific Agents) je možné dokonce zneužít 0-day zranitelnosti. [5]
V práci SOCu je spousta aktivit, které jsou repetitivní a bývají součástí každé analýzy. Z toho důvodu je klíčové tyto akce identifikovat a hledat možnosti, jak je eventuálně částečně či zcela zautomatizovat. Většina SOC týmů často čelí problémům s nedostatečnou kapacitou personálu a implementace automatických analyzátorů nebo responderů může efektivitu týmu výrazně zvýšit.
Dobrým příkladem je automatická analýza phishingových e-mailů. Existuje spousta možností, jak si postavit interní jazykový model, který se bude zaměřovat na analýzu e-mailů reportovaných uživateli. Jedním z nich je kombinace extrakce jednotlivých indikátorů kompromitace z nahlášené zprávy, následná analýza v analyzátorech a samotná kontrola textu.
K vytvoření takového systému je pochopitelně potřeba dostatečné množství materiálu, na jehož základě svůj model vytrénujete. Dle své osobní zkušenosti doporučuji alespoň 80 000 e-mailů. Po takovémto množství jsme již byli schopni vytvořit model, který je užitečný pro každodenní použití v SOCu, jelikož analytik již získává odhad, s jakým materiálem pracuje a jaké byly výsledky všech analýz, které by dříve musel dělat manuálně.
Další potenciálně automatizovatelnou akcí je např. generování vhodných odpovědí uživatelům na základě daného vzoru. V momentu, kdy je automatický responder schopen díky rozhodnutí analytika odeslat zpětnou vazbu uživateli o malignosti či validitě e-mailu, ušetříte spoustu velmi hodnotného času na důležitější aktivity, kde je potřeba analytikův úsudek.
V neposlední řadě si můžeme zkusit zkombinovat témata z předchozích částí článku. Co kdyby centrální management dovedl na základě informací z původní výstrahy získat všechna potřebná data o podezřelém zařízení z CMDB, zároveň zanalyzoval indikátory kompromitace vůči internímu MISPu i externím zdrojům a analytik přišel k dané události v momentu, kdy má všechny tyto nutné informace již po ruce? Pokud všechny části řetězce fungují tak, jak je očekáváno, schopnost analytika správně reagovat se rapidně zvyšuje.
Obr. 3: Spolupráce v týmu kybernetické obrany z pohledu zefektivnění práce SOCu
Kontinuálnost vzdělávání je klíčem
Posledním článkem řetězce, který se musí adaptovat na rychlý vývoj, jsou samotní SOC analytici. Vědomosti, které mají, mohou sehrát klíčovou roli. Nejedná se pouze o informace z oblasti Threat Intelligence, ale o znalosti jednotlivých technik útočníků, systémů nebo o technické porozumění novým hrozbám. Důležitý je také samotný rozvoj a specializace jejich dovedností. To vše ovšem nelze vyřešit jedním tréninkem za rok.
Je důležité implementovat prostor pro kontinuální vzdělávání. Může se jednat pouze o několik hodin týdně či měsíčně, ale v celkovém měřítku se bude jednat o velkou změnu. Nelze totiž očekávat, nebo dokonce požadovat, že se SOC analytici budou vzdělávat ve svém volném čase.
Podnítit analytiky ke kontinuálnímu vzdělávání lze několika způsoby:
- CyberRanges – vzdělávací portály se zaměřením na kybernetickou bezpečnost se skórovacím systémem,
- prezentace analytiků na téma vybraných nových fenoménů nebo zajímavých znalostí na teamových mítinkách,
- týmové Capture the Flag události,
- zapojení analytiků do činnosti jiných týmů z oddělení kybernetické bezpečnosti a spolupráce na společných projektech.
V ideálním případě by se mělo jednat o kombinaci výše uvedených, což ale není možné ve všech případech. Nejdůležitější ovšem je tým aktivně podporovat a ocenit úspěšný seberozvoj.
Závěr
Úspěch SOCu v dynamicky se vyvíjejícím světě nezávisí pouze na jednom týmu. Jedná se zpravidla o optimalizaci, která musí fungovat ve spolupráci s ostatními týmy kybernetické obrany. Z pozice vedoucího týmu či manažera oddělení můžete sami implementovat některé změny, ovšem celkový úspěch mise celého oddělení závisí na vícero faktorech, které mnohdy přesahují hranice kyberbezpečnostního oddělení.
Za klíčové považuji zmapování aktuální situace a prioritizaci možných zlepšení na základě poměru množství vynaloženého a ušetřeného času, stejně tak jako evaluaci stavu informovanosti o aktuálních hrozbách.
Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.
Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.