V prvej časti tejto série sme sa venovali najmä štandardným bezpečnostným opatreniam ako sú heslá, firewally, záplaty softvéru a vzdelávanie. Taktiež sme sa venovali endpoint riešeniam, ktoré často predstavujú jednu z prvých línii obrany voči pokročilejším útokom v organizácii, keďže ide o riešenia nainštalované priamo na počítači užívateľa. Čo však môžeme urobiť v prípade, že endpoint riešenie na koncovom zariadení zlyhá? Práve tu nastupuje súbor opatrení a nástrojov, ktoré môžeme zhrnúť do širokého pojmu správy prístupu k dátam a infraštruktúre.
Správa prístupu k dátam a infraštruktúre
Pre ilustráciu tohto pojmu budeme pokračovať v modelovej situácii z predchádzajúceho článku. Máme teda užívateľa, ktorý podľahol spear phishingu a kliknutím si nainštaloval malware, ktorý nebol zachytený endpoint riešením. Predpokladajme, že jeho počítač je v moci útočníka, ktorý dokáže zaznamenávať stisky kláves, dostane sa k jeho súkromným šifrovacím kľúčom, dokáže mu podvrhnúť falošné webové stránky, čiže prakticky má plnú kontrolu nad zariadením užívateľa bez jeho vedomia.
V štandardnom scenári útokov na organizácie sme sa dostali do bodu, kedy môže útočník použiť prístupové údaje užívateľa a pristupovať ku dátam a infraštruktúre, ku ktorej ma tento užívateľ prístup a to vrátane cloudu. Taktiež má pod kontrolou zariadenie, v tomto prípade notebook, umiestnený v sieti organizácie.
Častokrát záchranu nepredstavuje ani použitie firewallu na segmentáciu siete, či multifaktorovej autentizácie ako prvé opatrenia aspoň čiastočne spadajúce pod správu prístupu. Je tak vhodné siahnuť po nástrojoch typu PIM/PAM (Privileged Identity Management / Privileged Access Management). Obe kategórie sú si veľmi podobné a dá sa zjednodušene povedať, že vykonávajú rovnakú funkciu len trochu iným spôsobom.
Ide o nástroje, ktoré stoja medzi užívateľom (identitou) a dátami alebo infraštruktúrou (nezávisle na tom, či sa jedná o cloud), ku ktorej chceme kontrolovať prístup. V našom modelovom príklade to znamená, že identita, ktorú môže útočník zneužiť má prístup len k vybraným serverom alebo dátam. Narážame na klasický princíp najnižších privilégii, kedy užívateľ má prístup len k tomu, k čomu ho musí mať. Ideovo ho potrebujeme aplikovať všade, či sa jedná o dáta, servery alebo ich cloudové varianty (cloud je konieckoncov len počítač niekoho iného).
Základný prínos PIM/PAM nástrojov, ktoré sú používané na implementáciu tohto princípu, vidíme triviálne vo väčších infraštruktúrach, kde by bolo organizačne a časovo náročné udržiavať stále na každom serveri a všade aktuálne SSH kľúče, prihlasovacie údaje, meniť prístupy a podobne. PIM/PAM umožňuje centralizovanú správu prístupov a to v rôznych technických módoch – či už ako endpoint riešenie alebo sieťová gateway, či rôzne hybridy. Vhodným doplnkom sú nástroje na správu identít, pomocou ktorých je spravovaný životný cyklus jednotlivých užívateľov, resp. ich identít, vrátane ich prístupových údajov.
Vrátime sa ale naspäť. Predstavme si, že užívateľ pracuje v organizácii, ktorá používa tieto nástroje a ich doteraz spomenuté funkcionality. Užívateľ má pravidelne menené heslo, generované nové SSH kľúče, jednotlivé prístupy sú stále revidované. Nič z toho však nie je platné, keďže útočník je pevne usadený v počítači, kde všetko vidí a ku všetkému má prístup rovnaký ako napadnutý užívateľ. Sľubujem, že už v tomto článku nebudem ďalej posilňovať útočníka, ale modelová situácia je v tejto podobe stále celkom reálna a častá. Okrem toho, že daná situácia je reálna, veľký problém nastáva vtedy, ak dôjde k úspešnému napadnutiu užívateľa, ktorý je napríklad správcom siete alebo team leaderom, resp. má prístup k veľkej časti infraštruktúry. Čo sa s tým dá robiť?
V takýchto situáciach prídu vhod funkcionality nástrojov označované ako UBA (User Behavior Analysis), teda nástroje na analýzu správania užívateľov. Takéto nástroje môžu byť dostupné ako samostatné riešenia založené na softvérových agentoch, ktoré sa čiastočne môžu prekrývať s funkcionalitami endpoint riešení, ale nie sú nutne zamerané proti malwaru alebo útočníkom. Vstupujú práve až do neskorších fáz útoku, kedy dochádza k zneužitiu danej identity, čo je z pohľadu UBA vnímané ako neobvyklé správanie daného užívateľa.
Kvalitatívne totiž dochádza k niečomu podobnému ako je štandardný prípad použitia pre niektoré z týchto nástrojov a to je insider threat, čo už je úmyselná škodlivá činnosť vychádzajúca od samotného užívateľa. Medzi bežné funkcionality UBA patrí napríklad sledovanie prístupu v čase, kontrola otváraných dokumentov, sledovanie navštívených webových stránok, využívanie tlačiarní alebo kontrola práce s externými médiami.
Okrem samostatných UBA riešení však nájdeme niektoré techniky analýzy správania užívateľov aj v pokročilých PIM/PAM riešeniach. Môže sa jednať napríklad o analýzu časov prístupu, charakteristiku otvorených okien na cieľovom serveri (pri grafických pripojeniach), filtrovanie použitých príkazov alebo analýzu rôznych behaviorálnych biometrík, napríklad rytmu písania na klávesnici. Výsledkom je detekcia neobvyklého správania daného užívateľa, čo v našom prípade ukazuje na zneužitie útočníkom.
Nesmieme zabudnúť ani na podporu auditu, ktorá sa dosahuje hlavne záznamom jednotlivých užívateľských činností, a to či už v textovej forme logov alebo vo forme kontinuálnych grafických záznamov pri grafických pripojeniach ako je RDP, Citrix, VNC a podobne, prípadne kombináciou textovej a grafickej formy.
Ak si vyššie napisané aplikujeme na našu modelovú situáciu, po zlyhaní prostriedkov preventívnej kontroly prístupu sme pomocou UBA funkcionalít detekovali, že niečo nie je v poriadku so správaním daného užívateľa. Prístup sme ihneď zakázali, prístupové údaje zmenili a na základe auditných záznamov sme zistili, že útočník nestihol spraviť nič zlé. Zistili sme, ako sa podarilo útočníkovi vydávať za užívateľa, ktorého sme následne poučili a niečo podobné sa už znova nezopakuje. Vďaka správne nastaveným procesom, vzdelaným ľuďom a kvalitným nástrojom sme z toho tentokrát vyviazli prakticky bez strát.
Čo sa ale môže stať, ak útočník „nepôjde“ po užívateľoch ale zameria sa napríklad na našu webovú stránku alebo iné súčasti našej infraštruktúry? O tom si povieme v ďalšej časti seriálu.
Dávid Kosť, Lead SOC Analyst, Axenta a.s.
