Když kyberútok zasáhne firemní server, první otázkou obvykle není jen to, zda se něco pokazilo. Týmy musí zjistit, co se stalo, kdy to začalo, které účty a systémy byly zapojeny, k jakým datům se někdo dostal a zda má útočník stále přístup.
Tyto odpovědi závisí na bezpečnostních logách. Log není automaticky užitečným důkazem jen proto, že existuje. Neúplný záznam, nesprávné časové razítko nebo log, který může upravovat stejný správce, jenž událost způsobil, může vyšetřovatelům zanechat spíše seznam podezření než obhajitelnou časovou osu.
Kvalitní protokolování podporuje reakci na incidenty, právní a regulatorní přezkum, provozní učení i rozhodování o obnově. Pomáhá také firmě rozlišit mezi napadeným produkčním systémem a bodem obnovy, kterému lze důvěřovat.
Začněte událostmi, které odhalí cestu útočníka
Správná sada událostí se liší podle operačního systému, aplikace a infrastruktury, cíl je však stejný: zaznamenávat kroky, které ukazují počáteční přístup, eskalaci oprávnění, laterální pohyb, zajištění perzistence, přístup k datům a pokusy o ukrytí nebo zničení důkazů.
Události autentizace a identity
Zaznamenávejte úspěšná i neúspěšná přihlášení na serverech, v adresářových službách, VPN, cloudových konzolích, nástrojích pro vzdálenou správu a důležitých aplikacích. Užitečné podrobnosti zahrnují použitý účet, metodu autentizace, zdrojovou adresu, cílový systém, výsledek a podle dostupnosti také důvod neúspěchu.
Neomezujte se přitom na lidské uživatele. Servisní účty, identity naplánovaných úloh, klíče API, strojové certifikáty a identity aplikací lze zneužít stejně účinně jako pojmenované účty. Uchovávat by se měly také změny hesel, události vícefaktorové autentizace, vydání tokenů, vytvoření a ukončení relací i uzamčení účtů.
Změny oprávnění a účtů
Změny oprávnění často označují okamžik, kdy se průnik stává výrazně nebezpečnějším. Logujte přidání do rolí administrátora, roota, doménového administrátora, vlastníka databáze a cloudového administrátora. Zaznamenávejte změny souborů sudoers, členství ve skupinách, delegovaných oprávnění, přístupových zásad a práv servisních účtů.
Vytváření, mazání, deaktivace a opětovná aktivace účtů by měly být viditelné včetně identity, která akci provedla. Totéž platí pro změny přihlašovacích údajů API, klíčů SSH, přístupových tokenů, certifikátů a nastavení resetování hesel. Útočník může vytvořit nový účet místo toho, aby dál používal účet využitý při počátečním přístupu.
Spouštění procesů a zajištění perzistence
Logy spouštění procesů mohou ukázat, jak útočník přešel od platného přihlášení ke škodlivé aktivitě. Pokud je to praktické, zachycujte název spustitelného souboru, celý příkazový řádek, nadřazený proces, uživatelskou nebo servisní identitu, ID procesu, čas spuštění a hostitele. Vytváření souborů, používání interpretů skriptů, naplánované úlohy, cron úlohy, služby, položky spouštěné při startu, klíče Registry Run a příkazy pro vzdálenou správu mohou odhalit mechanismy perzistence.
Podrobnosti příkazového řádku jsou důležité. Záznam „spustil se powershell.exe“ je méně užitečný než záznam, který ukazuje skript, parametry, nadřazený proces a kontaktovaný cíl. Protokolování je třeba vyvážit s ochranou soukromí a správou tajných údajů: příkazové řádky mohou obsahovat hesla, tokeny nebo osobní údaje, takže přístup k nim musí být vhodně řízen.
Aktivita konfigurace, firewallu, VPN a DNS
Změny konfigurace mohou vysvětlit, jak útočník pronikl dovnitř i proč přestaly fungovat běžné kontroly. Zaznamenávejte změny bezpečnostních nastavení operačního systému, ochrany koncových bodů, pravidel firewallu, nastavení vzdáleného přístupu, zásad adresářových služeb, směrování, nastavení proxy a síťových bezpečnostních skupin.
Logy firewallu by měly zobrazovat povolená a zamítnutá připojení, zdrojové a cílové adresy, porty, protokoly, rozhraní nebo zónu a pravidlo, které provoz zpracovalo. Logy VPN by měly obsahovat časy připojení a odpojení, přidělenou adresu, účet, informace o zařízení, výsledek autentizace a bránu. Tyto záznamy mohou propojit externí zdroj s aktivitou, která se později objeví na interním serveru.
Požadavky DNS jsou často přehlíženy. Mohou odhalit infrastrukturu velení a řízení, místa pro přípravu dat, nově registrované domény a pokusy o přístup ke cloudovým úložištím nebo službám pro přenos dat. Uchovávejte požadujícího hostitele, dotazované jméno, typ záznamu, odpověď, resolver a časové razítko. Samotné DNS neprokazuje napadení, ale může doplnit sekvenci, kterou jiné logy zachycují jen částečně.
Aktivita webu, databází a cloudových administrátorů
Logy webového přístupu by měly zachycovat čas požadavku, zdrojovou adresu, hostitele, metodu, cestu, stavový kód, velikost odpovědi, identifikátor uživatele nebo relace tam, kde je to vhodné, a user-agent. Reverzní proxy a webové aplikační firewally mohou přidat kontext o blokovaných požadavcích, shodách s pravidly a předávaných adresách klientů. Původní informace o zdroji pečlivě uchovávejte; hlavičky proxy nelze považovat za důvěryhodné, pokud není řetězec proxy pod kontrolou.
U databází zaznamenávejte přihlášení, neúspěšná přihlášení, změny oprávnění, změny schématu, administrativní příkazy, dotazy zahrnující citlivé tabulky, exporty, zálohy, obnovy a změny nastavení auditu. Úplné protokolování dotazů může být nákladné nebo může obsahovat citlivá data, proto by organizace měly určit, které databáze, akce a třídy dat vyžadují podrobné zachycení.
Cloudové řídicí roviny potřebují vlastní auditní stopu. Zaznamenávejte kroky administrátorů týkající se správy identit a přístupu, úložišť, virtuálních strojů, bezpečnostních skupin, klíčů, nastavení logování, snapshotů, síťových tras a zásad mazání či uchovávání. Log cloudové úlohy může ukázat, co se stalo uvnitř serveru, zatímco administrátorský log poskytovatele ukáže, kdo změnil okolní prostředí.
Zálohování je bezpečnostní událost
Zálohy by neměly být považovány za oddělenou oblast od protokolování incidentů. Zaznamenávejte začátky a konce zálohovacích úloh, zdrojové systémy, vybraná data, výsledek, identitu operátora nebo služby, cíl, změny uchovávání, požadavky na smazání, chyby šifrování nebo klíčů, požadavky na obnovu a výsledky obnovy.
Útočník, který nedokáže produkční data okamžitě zašifrovat nebo ukrást, se může pokusit smazat body obnovy, zkrátit dobu uchovávání, deaktivovat úlohy nebo napadnout přihlašovací údaje používané ke správě záloh. Tyto kroky se musí objevit v auditní stopě, kterou nekontroluje výhradně produkční administrátor.
Pole, která mění záznam logu v důkaz
Objem událostí není totéž co vyšetřovací hodnota. Každá důležitá událost by měla odpovědět na několik základních otázek: kdy se stala, odkud pocházela, na co cílila, kdo nebo co ji provedlo, jaká akce nastala a zda byla úspěšná?
- Synchronizované časové razítko: Používejte jednotný zdroj času a zaznamenávejte časové pásmo nebo posun vůči UTC. Pokud to platforma podporuje, uvádějte přesný čas události i čas sběru, pokud se liší.
- Zdroj a cíl: Podle potřeby zachycujte zdrojové a cílové IP adresy, porty, názvy hostitelů, rozhraní, zóny, URL, databázové objekty nebo cloudové zdroje. Pokud ovlivňuje přiřazení odpovědnosti, zaznamenejte také kontext NAT nebo proxy.
- Identita: Identifikujte lidského uživatele, servisní účet, proces, zařízení, certifikát, token nebo klienta API. Samotné zobrazované jméno nestačí, pokud jej nelze přiřadit k jedinečné identitě.
- Akce: Uveďte, o co se někdo pokusil: přihlášení, přiřazení role, spuštění procesu, přístup k souboru, změnu pravidla, export, smazání nebo obnovu.
- Výsledek: Rozlišujte úspěch, neúspěch, zamítnutí, částečné dokončení a chybu. Neúspěšné události mohou ukázat průzkum a opakované pokusy, úspěšné události zase rozsah získaného přístupu.
- Korelační identifikátory: Uchovávejte ID požadavků, relací, trasování, transakcí, procesů a úloh. Tyto identifikátory umožňují vyšetřovatelům propojit požadavek proxy s událostí aplikace, databázovým dotazem a následnou akcí.
- Podrobnosti objektu a změny: U změn konfigurace nebo přístupu zaznamenejte dotčený zdroj a pokud možno také předchozí a novou hodnotu.
Korelační ID jsou obzvlášť cenná v distribuovaných prostředích. Uživatel se může autentizovat prostřednictvím poskytovatele identity, přistoupit k VPN, připojit se k webové službě, spustit aplikačního workera a vyvolat databázový dotaz. Bez sdílených identifikátorů nebo spolehlivého mapování mezi systémy se časová osa stává ručním hádáním.
Organizace by měly dokumentovat zdroje času, očekávaný posun a formáty časových razítek. Pětiminutový rozdíl mezi firewallem a serverem může při krátkém útoku stačit k nesprávnému seřazení událostí. Sběrače logů by měly zachovat původní časové razítko, místo aby je tiše nahrazovaly časem přijetí události.
Definujte minimální sadu událostí a kontrolní seznam vyšetřování
Každá firma by měla mít písemný základ protokolování pro své servery a kritické systémy. Minimálně by měl pokrývat autentizaci, změny oprávnění a účtů, spouštění procesů, změny konfigurace, síťový přístup, DNS, webovou a databázovou aktivitu, cloudovou administraci a zálohování. Základ by měl určit vlastníka systému, očekávaný zdroj logů, metodu sběru, dobu uchovávání a osobu odpovědnou za kontrolu závažných událostí. Praktická reference pro vytvoření kontrolního seznamu bezpečnostních logů a událostí reakce na incident může týmům pomoci odhalit mezery ještě před vznikem incidentu.
Základ protokolování není jednorázová konfigurační úloha. Přezkoumejte jej po významné změně softwaru, migraci, zavedení nové cloudové služby, akvizici nebo incidentu. Ověřte, že události očekávané na papíře se skutečně generují, shromažďují, lze v nich vyhledávat a jsou uchovávány po požadovanou dobu.
Centralizujte sběr, aniž vytvoříte jediný bod selhání
Centralizovaný sběr urychluje vyšetřování, protože analytici mohou vyhledávat napříč servery, systémy identit, sítěmi a aplikacemi podle jediné časové osy. Snižuje také pravděpodobnost, že útočník, který napadne jeden server, vymaže všechny záznamy své aktivity.
Odesílejte logy do vyhrazené sběrné vrstvy nebo platformy SIEM. Používejte zabezpečený přenos, omezte, kdo může záznamy odesílat nebo upravovat, sledujte stav sběračů a upozorněte na zastavení odesílání z důležitého zdroje. Tiché selhání logování může být stejně závažné jako výstraha, která nikdy nebyla nakonfigurována.
Centralizace neznamená, že každý systém má neomezený přístup ke každému logu. Oddělte oprávnění pro příjem, vyhledávání, správu a mazání. Uchovávejte záznamy o přístupu k logům a jejich exportu, zejména pokud mohou být důkazy sdíleny s forenzním poskytovatelem, pojišťovnou, regulátorem nebo orgány činnými v trestním řízení.
Uchovávání a odolnost proti manipulaci
Doba uchovávání by měla zohledňovat dobu, po kterou může útočník zůstat neodhalen, právní povinnosti, smluvní požadavky a rychlost interního vyšetřování. Krátká doba může odstranit důkazy potřebné k pochopení počátečního přístupu. Nadměrné uchovávání bez řízení přístupu může zvýšit riziko pro soukromí a bezpečnost.
Vhodně používejte úložiště pouze pro připojování nebo neměnná úložiště, chraňte logovací službu oddělenými přihlašovacími údaji a zabraňte produkčním administrátorům měnit či mazat historické záznamy. Hašování, podepsané záznamy, úložiště WORM a nezávislé kopie mohou posílit odhalování manipulace. Konkrétní kontrola by měla odpovídat citlivosti prostředí, princip je však jednoduchý: osoba, která může napadnout produkci, by neměla mít možnost přepsat důkazy o tomto napadení.
Oddělte produkci od důkazů
Logy by neměly být zcela závislé na stavu systémů, které monitorují. Pokud útočník získá administrátorský přístup k serveru, místní logy může smazat, upravit nebo zašifrovat. Odesílejte kopie mimo hostitele a u kritických systémů udržujte pro infrastrukturu sběru a uchovávání samostatnou administrativní hranici.
Samotnou logovací platformu chraňte vícefaktorovou autentizací, omezenou administrací, segmentací sítě a nezávislým monitoringem. Zálohujte její konfiguraci a podle potřeby i data. Pokud je logovací platforma během incidentu nedostupná, organizace může přijít jak o přehled, tak o schopnost prokázat, co bylo shromážděno.
Jak agentury oddělují důkazy napříč klienty
Poskytovatelé řízených služeb, IT agentury a bezpečnostní týmy podporující několik firem potřebují další úroveň disciplíny. Důkazy musí být odděleny podle klienta, nikoli pouze označeny polem, které by analytik mohl omylem nesprávně filtrovat.
Používejte pro každého klienta samostatné tenanty, úložné oblasti nebo přístupové domény s oddělenými rolemi a oprávněními podle principu nejmenších privilegií. Identifikátory klientů by měly být součástí metadat událostí, neměly by však být jedinou kontrolou bránící přístupu mezi klienty. Izolaci tenantů je třeba testovat u vyhledávání, dashboardů, exportů, upozornění i zásad uchovávání.
Uchovávejte auditní stopu toho, který pracovník přistupoval k důkazům konkrétního klienta a kdy. Definujte, jak se důkazy během vyšetřování uchovávají, jak se předávají a kdy se mažou. Pokud používáte sdílený sběrač, zdokumentujte technické a procesní kontroly, které brání tomu, aby se logy jednoho klienta objevily ve vyšetřování jiného klienta.
Agentury by se také měly předem dohodnout, kdo může schválit sběr, izolaci, pozastavení účtů, obnovu a zveřejnění. Během útoku může nejasná odpovědnost zdržet zásah, zatímco důkazy dál mizí.
Pomocí logů rekonstruujte životní cyklus útoku
Užitečné vyšetřování je časová osa, nikoli sbírka alarmujících událostí. Začněte nejčasnějším věrohodným signálem a ověřujte každou fázi pomocí více zdrojů.
- Počáteční přístup: Hledejte neobvyklá úspěšná autentizace, opakovaná selhání následovaná úspěchem, vystavené služby, podezřelé relace VPN, webové požadavky zneužívající zranitelné cesty, nové nástroje pro vzdálený přístup a neočekávaná cloudová přihlášení. Porovnejte zdroj, zařízení, geografii, čas a metodu autentizace s běžnou aktivitou.
- Spuštění a eskalace oprávnění: Identifikujte první podezřelý proces, skript, příkaz nebo akci aplikace. Poté sledujte změny místních, adresářových nebo cloudových oprávnění. Zeptejte se, zda měl účet již nadměrná práva, nebo zda útočník vytvořil novou cestu k administraci.
- Laterální pohyb: Sledujte autentizační a síťové záznamy od prvního hostitele k dalším serverům, sdíleným souborům, databázím, hypervizorům a systémům pro správu. Hledejte stejný účet, zdrojovou adresu, nástroj nebo proces objevující se na více systémech.
- Perzistence: Vyhledávejte nové účty, naplánované úlohy, služby, položky spouštěné při startu, klíče SSH, tokeny API, upravené přístupové zásady a změněná nastavení vzdálené správy. Perzistence může být vytvořena několik dní před krádeží nebo zašifrováním dat.
- Přístup k datům a dopad: Korelujte webové požadavky, přístupy k databázím, čtení souborů, vytváření archivů, exporty, aktivitu cloudových úložišť a neobvyklá odchozí připojení. Zjistěte, k čemu bylo skutečně přistoupeno, nikoli jen co mohlo být dostupné.
- Obcházení obrany: Prověřte zastavené agenty, vymazané protokoly událostí, deaktivované auditní zásady, změněná pravidla firewallu, smazané snapshoty, upravené plány zálohování a selhání sběru logů. Tyto události mohou ukazovat záměr útočníka i limity dostupných důkazů.
Časová osa by měla odlišovat pozorovaná fakta od předpokladů. Zaznamenejte zdroj každého závěru, uchovejte relevantní nezpracované logy a uveďte mezery. Pokud byl server offline nebo bylo logování deaktivováno, řekněte to jasně. Obhajitelná zpráva o incidentu je užitečnější, když přizná nejistotu, než když uvádí nepodložený přesný čas.
Otázky při kontrole logů po incidentu
Pro udržení zaměření kontroly používejte praktické otázky:
- Jaká je nejčasnější událost, kterou nelze vysvětlit běžnou obchodní aktivitou?
- Který účet, služba, zařízení nebo vystavená aplikace byly zapojeny jako první?
- Byl první přístup úspěšný, nebo opakovaná selhání odhalila přípravu před průnikem?
- Která oprávnění se po počátečním přístupu změnila?
- Jaké procesy, skripty, nástroje nebo naplánované úlohy se na zasažených systémech objevily?
- Se kterými interními hostiteli účet nebo zdroj dále komunikoval?
- Byly čteny nebo exportovány citlivé soubory, databázové tabulky, poštovní schránky či objekty cloudového úložiště?
- Změnil útočník pravidla firewallu, nastavení DNS, logování, zásady identit nebo zálohování?
- Jsou časová razítka všech relevantních systémů dostatečně synchronizovaná pro podporu této posloupnosti?
- Které logy chybí, mají zpoždění, jsou uloženy lokálně nebo s nimi mohlo být manipulováno?
- Které účty, klíče, tokeny a relace je nutné před obnovou odvolat?
- Které systémy byly prověřeny dostatečně na to, aby bylo možné rozhodnout, že obnova je bezpečná?
Je nutné vyvážit omezení útoku a zachování důkazů. Odpojení napadeného serveru může zastavit další škody, jeho vypnutí nebo vymazání však může odstranit volatilní důkazy. Dodržujte schválený postup pro incidenty a přizvěte kvalifikovanou forenzní podporu, pokud mohou mít zjištěné skutečnosti právní, regulatorní nebo pojistné důsledky.
Obnova závisí na důvěryhodné historii
Logy mohou ukázat, kdy byly systémy napadeny, ale nedokážou je opravit. Obnova vyžaduje známou čistou kopii dat a stavu systému a také jistotu, že útočník nezměnil samotný proces obnovy.
Před obnovou určete nejčasnější podezřelý okamžik napadení a s body obnovy vytvořenými později zacházejte opatrně. Projděte logy zálohovacích úloh, aktivitu administrátorů, změny uchovávání a testy obnovy. Ověřte, že přihlašovací údaje k zálohám nebyly odhaleny, že jsou obnovovaná data úplná a že se obnovené systémy okamžitě znovu nepřipojí k infrastruktuře útočníka.
Čisté body obnovy by měly být uchovávány dostatečně dlouho, aby pokryly pravděpodobnou dobu přítomnosti útočníka a období vyšetřování. Neměnnost během doby uchovávání pomáhá zabránit útočníkovi v přepsání nebo smazání těchto bodů po získání přístupu do produkce. Šifrování chrání data při přístupu k úložišti, zatímco oddělení klíčů zajišťuje, že poskytovatel úložiště nemůže data zákazníka jednoduše sám dešifrovat.
Pro firmy chránící servery, které mají pod kontrolou, nabízí Safenix off-site zálohování šifrované klíčem, který Safenix nikdy nedrží, uložené v Německu a neměnné po celou dobu uchovávání. Služba je určena pro firemní servery pod kontrolou zákazníka, nikoli pro weby hostované na sdíleném hostingu.
Po incidentu by měla být obnova před přechodem do produkce otestována v izolovaném prostředí. Ověřte aplikace, účty, síťové cesty, naplánované úlohy, monitoring a bezpečnostní kontroly, poté změňte přihlašovací údaje a potvrďte, že původní vstupní cesta je uzavřena. Firmy, které zvažují, jak uchovávat čisté body obnovy a testovat obnovu, mohou prozkoumat možnosti off-site zálohování serverů Safenix.
Začleňte logování do plánování odolnosti
Bezpečnostní logy jsou nejcennější, když jsou navrženy ještě před krizí. Zdokumentujte základ událostí, synchronizujte hodiny, centralizujte sběr, omezte přístup, oddělte důkazy od produkce a testujte postupy uchovávání a obnovy.
Monitoring serverů může včas identifikovat neobvyklé chování, zatímco auditní logy poskytují podrobnosti potřebné k rekonstrukci rozhodnutí a kroků. Společně s čistými a chráněnými body obnovy dávají firmě dvě věci, které tým pro reakci na incident potřebuje nejvíce: spolehlivý přehled o tom, co se stalo, a bezpečnější způsob návratu k provozu.