V první části této série jsme se věnovali zejména standardním bezpečnostním opatřením jako jsou hesla, firewally, záplaty softwaru a vzdělávání. Také jsme se věnovali endpoint řešením, která často představují jednu z prvních linií obrany vůči pokročilejším útokům v organizaci, neboť jde o řešení nainstalovaná přímo na počítači uživatele. Co však můžeme udělat v případě, že endpoint řešení na koncovém zařízení selže? Právě zde nastupuje soubor opatření a nástrojů, které můžeme shrnout do širokého pojmu správy přístupu k datům a infrastruktuře.

Správa přístupu k datům a infrastruktuře

Pro ilustraci tohoto pojmu budeme pokračovat v modelové situaci z předchozího článku. Máme tedy uživatele, který podlehl spear phishingu a kliknutím si nainstaloval malware, který nebyl zachycen endpoint řešením. Předpokládejme, že jeho počítač je v moci útočníka, který dokáže zaznamenávat stisky kláves, dostane se k jeho soukromým šifrovacím klíčům, dokáže mu podvrhnout falešné webové stránky, čili prakticky má plnou kontrolu nad zařízením uživatele bez jeho vědomí.

Ve standardním scénáři útoků na organizace jsme se dostali do bodu, kdy může útočník použít přístupové údaje uživatele a přistupovat k datům a infrastruktuře, ke které měl tento uživatel přístup a to včetně cloudu. Také má pod kontrolou zařízení, v tomto případě notebook, umístěný v síti organizace.

Častokrát záchranu nepředstavuje ani použití firewallu na segmentaci sítě, či vícefaktorová autentizace jako první opatření alespoň částečně spadající pod správu přístupu. Je tak vhodné sáhnout po nástrojích typu PIM / PAM (Privileged Identity Management / Privileged Access Management). Obě kategorie jsou si velmi podobné a dá se zjednodušeně říci, že vykonávají stejnou funkci jen trochu jiným způsobem.

Jde o nástroje, které stojí mezi uživatelem (identitou) a daty nebo infrastrukturou (nezávisle na tom, zda se jedná o cloud), ke které chceme kontrolovat přístup. V našem modelovém příkladu to znamená, že identita, kterou může útočník zneužít, má přístup jen k vybraným serverům nebo datům. Narážíme na klasický princip nejnižších privilegií, kdy uživatel má přístup pouze k tomu, k čemu ho musí mít. Ideálně ho potřebujeme aplikovat všude, ať se jedná o data, servery nebo jejich cloudové varianty (cloud je koneckonců jen počítač někoho jiného).

Základní přínos PIM / PAM nástrojů, které jsou používány k provádění tohoto principu, vidíme ve větších infrastrukturách, kde by bylo organizačně a časově náročné udržovat stále na každém serveru a všude aktuální SSH klíče, přihlašovací údaje, měnit přístupy a podobně. PIM / PAM umožňuje centralizovanou správu přístupů a to v různých technických módech – ať už jako endpoint řešení nebo síťová gateway, či různé hybridy. Vhodným doplňkem jsou nástroje pro správu identit, pomocí kterých je spravován životní cyklus jednotlivých uživatelů, resp. jejich identit, včetně jejich přístupových údajů.

Vrátíme se ale zpět. Představme si, že uživatel pracuje v organizaci, která používá tyto nástroje a jejich dosud zmíněné funkcionality. Uživatel má pravidelně změněné heslo, generované nové SSH klíče, jednotlivé přístupy jsou stále revidovány. Nic z toho však není platné, protože útočník je pevně usazen v počítači, kde všechno vidí a ke všemu má přístup stejný jako napadený uživatel. Slibuji, že už v tomto článku nebudu dále posilovat útočníka, ale modelová situace je v této podobě stále docela reálná a častá. Kromě toho, že daná situace je reálná, velký problém nastává tehdy, když dojde k úspěšnému napadení uživatele, který je například správcem sítě nebo team leaderem, resp. má přístup k velké části infrastruktury. Co se s tím dá dělat?

V takových situacích přijdou vhod funkcionality nástrojů označované jako UBA (User Behavior Analysis), tedy nástroje pro analýzu chování uživatelů. Takové nástroje mohou být dostupné jako samostatné řešení založené na softwarových agentech, které se částečně mohou překrývat s funkcionalitami endpoint řešení, ale nejsou nutně zaměřeny proti malwaru nebo útočníkem. Vstupují právě až do pozdějších fází útoku, kdy dochází ke zneužití dané identity, což je z pohledu UBA vnímáno jako neobvyklé chování daného uživatele.

Kvalitativně totiž dochází k něčemu podobnému jako je standardní případ použití pro některé z těchto nástrojů a to je insider threat, což už je úmyslná škodlivá činnost vycházející od samotného uživatele. Mezi běžné funkcionality UBA patří například sledování přístupu v čase, kontrola otevíraných dokumentů, sledování navštívených webových stránek, využití tiskáren nebo kontrola práce s externími médii.

Kromě samostatných UBA řešení však najdeme některé techniky analýzy chování uživatelů i v pokročilých PIM / PAM řešeních. Může se jednat například o analýzu časů přístupu, charakteristiku otevřených oken na cílovém serveru (při grafických připojeních), filtrování použitých příkazů nebo analýzu různých behaviorálních biometrik, například rytmu psaní na klávesnici. Výsledkem je detekce neobvyklého chování daného uživatele, což v našem případě ukazuje na zneužití útočníkem.

Nesmíme zapomenout ani na podporu auditu, kterého se dosahuje hlavně záznamem jednotlivých uživatelských činností, a to ať už v textové formě logů nebo ve formě kontinuálních grafických záznamů při grafických připojeních jako je RDP, Citrix, VNC a podobně, případně kombinací textové a grafické formy.

Pokud si výše napsané aplikujeme na naši modelovou situaci, po selhání prostředků preventivní kontroly přístupu jsme pomocí UBA funkcionalit detekovali, že něco není v pořádku s chováním daného uživatele. Přístup jsme ihned zakázali, přístupové údaje změnily a na základě auditních záznamů jsme zjistili, že útočník nestihl udělat nic špatného. Zjistili jsme, jak se podařilo útočníkovi vydávat se za uživatele, kterého jsme následně poučili a něco podobného se už znovu nezopakuje. Díky správně nastaveným procesům, vzdělaným lidem a kvalitním nástrojům jsme z toho tentokrát vyvázli prakticky bez ztrát.

Co se ale může stát, pokud útočník „nepůjde“ po uživatelích ale zaměří se například na naši webovou stránku nebo jiné součásti naší infrastruktury? O tom si povíme v další části seriálu.

Dávid Kosť, Lead SOC Analyst, Axenta a.s.