Když se to stane: reakce na incident
Co dělat, když se v síti stane něco, co se stát nemělo: fáze reakce a příprava (log server, kontakty, mapa sítě, zálohy konfigurace), role a eskalace, odkud přijde první signál a jak ho odtriagovat, kontejnment karanténou a jeho cena, vyšetřování z časové osy a toků včetně skutečného blast radiusu, náprava příčiny místo příznaku, bezpečná obnova s N-1 testem a post-mortem bez viníků.
Lekce 1: Než se to stane
Fáze reakce na incident
Než začneš: tenhle kurz staví na pojmech ze začátečnických kurzů (adresy a maska, brána, VLANy, porty, DNS, firewall) – když ti některý nebude jasný, mrkni napřed do nich. Navazuje také na kurzy Monitoring, logy a detekce, Zero Trust a mikrosegmentace a Když síť nefunguje. Incident je situace, kdy se v síti stalo něco, co se stát nemělo: zařízení se chová jinak, než má, někdo se dostal tam, kam neměl, data odešla ven. Reakce na incident není hrdinský výkon jednoho člověka o půlnoci – je to postup, který se dá napsat na jednu stránku a projít podle ní. Právě proto se dělí na fáze: příprava (než se to stane), detekce (zjistíš, že se něco děje), kontejnment (zastavíš šíření), náprava (odstraníš příčinu), obnova (vrátíš provoz) a ponaučení (změníš síť tak, aby se to neopakovalo). Fáze nejsou byrokracie. Jsou tam proto, že v krizi má člověk sklon dělat věci ve špatném pořadí: mazat, restartovat a „uklízet" dřív, než ví, co se vlastně stalo. Když pořadí dodržíš, každý krok má svůj smysl a nezničíš si podklady pro ten další. A ještě jedna věc, kterou lidé podceňují: fáze se překrývají a vracejí. Při vyšetřování často zjistíš, že se to šíří dál, a vracíš se ke kontejnmentu. To je normální – důležité je vědět, ve které fázi zrovna jsi a co je jejím cílem.
Krok za krokem
- Příprava je fáze, která proběhne dřív, než se cokoli stane: sběr logů, mapa sítě, kontakty. Bez ní ostatní fáze nefungují.
- Detekce: něco se děje a ty se to dozvíš – z alertu sondy, z logu, nebo od uživatele. Teprve tady incident začíná existovat.
- Kontejnment zastaví šíření. Teprve po něm přijde náprava (odstranění příčiny) a obnova (návrat do provozu).
- Poslední fáze je ponaučení: co v síti změnit, ať se totéž neopakuje. Fáze se přitom klidně vracejí – to je normální.
Co si připravit předem
Kvalita reakce na incident se nerozhoduje ve chvíli, kdy incident nastane, ale měsíce předtím. Čtyři věci ti v krizi ušetří nejvíc času a je rozumné mít je hotové. Za prvé log server: jedno místo, kam zařízení posílají své události. Bez něj nemáš časovou osu a vyšetřování se scvrkne na dohady – a co nebylo zapsané, se zpětně nedoplní. Za druhé kontakty: kdo se volá v noci, kdo mluví s vedením, kdo s poskytovatelem připojení, kdo s dodavatelem aplikace. Hledat telefonní číslo ve chvíli, kdy stojí výroba, je zbytečná ztráta. Za třetí mapa sítě: co kde je, co je kritické a co s čím mluví. V simulátoru je jejím obrazem kontrola topologie a přehled spojení – když je znáš z klidu, poznáš v krizi, co je odchylka. A za čtvrté zálohy konfigurace zařízení: firewallová pravidla, VLANy, směrování. Když se ukáže, že někdo nastavení změnil, chceš mít s čím porovnat a co vrátit. Společný jmenovatel: všechny čtyři věci jdou pořídit v klidu, levně a bez adrenalinu – a ani jednu z nich si v krizi nedoplníš. Test připravenosti je jednoduchý: představ si, že tvůj hlavní server je od včerejška napadený, a zeptej se, čím bys začal. Když odpověď zní „nevím, kde se podívat", víš, co doplnit.
Krok za krokem
- Log server je první věc. Zařízení mu posílají události, takže máš z čeho postavit časovou osu incidentu.
- Mapa sítě: co kde je, co je kritické a co s čím normálně mluví. Kontrola topologie a přehled spojení ji drží aktuální.
- Zálohy konfigurace ti dají odpověď na otázku „změnil to někdo?" a hlavně něco, co se dá vrátit zpátky.
- Kontakty, mapa, logy, zálohy – vše se pořídí v klidu. V krizi si už ani jedno z toho nedoplníš.
Kdo co dělá
V malé firmě se často říká „incident vyřeší ajťák". Jenže i jeden člověk potřebuje vědět, které role zrovna zastává, protože se navzájem ruší. Role jsou tři a dají se popsat velmi stručně. Ten, kdo rozhoduje, říká, co se smí udělat: jestli se server odpojí, jestli se přeruší výroba, jestli se volá policie. Je to rozhodnutí o dopadu na byznys, ne technické – proto ho nemá dělat ten, kdo je zrovna po lokty v logu. Ten, kdo vyšetřuje, sbírá důkazy a skládá časovou osu; potřebuje klid a hlavně nesmí zároveň uklízet. Ten, kdo komunikuje, drží informované vedení, uživatele a případně zákazníky – a odstiňuje vyšetřujícího od dotazů „už to bude?". Když jsi na incident sám, střídej role vědomě a po částech, ne všechny naráz. K rolím patří eskalace: předem daná hranice, po jejímž překročení voláš dál. Například: incident trvá přes hodinu, týká se osobních údajů, zasahuje víc než jeden segment, nebo si nejsi jistý rozsahem. Eskalace není přiznání neschopnosti, ale běžný pracovní krok – a předem stanovená hranice tě zbaví trapného zvažování uprostřed noci. Zapamatuj si jednoduché pravidlo: kdo vyšetřuje, nerozhoduje; kdo rozhoduje, nemluví za všechny; a mluvit ven má vždycky jeden člověk.
Krok za krokem
- Kdo rozhoduje: smí se server odpojit? Přeruší se provoz? Je to rozhodnutí o dopadu na firmu, ne technický detail.
- Kdo vyšetřuje, sbírá důkazy a skládá časovou osu. Potřebuje klid – a nesmí u toho zároveň uklízet.
- Kdo komunikuje, drží informované vedení a uživatele a odstíní vyšetřujícího od dotazů „už to bude?".
- Eskalace je předem daná hranice: delší než hodinu, osobní údaje, víc segmentů, neznámý rozsah. Pak voláš dál.
Lekce 2: Detekce: první signál
Odkud přijde první zpráva
Incidenty málokdy začínají tak, jak si je lidé představují – tedy velkým červeným nápisem na obrazovce. Začínají čtyřmi mnohem obyčejnějšími způsoby a stojí za to znát je všechny, protože každý má jinou rychlost a jinou spolehlivost. Za prvé uživatel: „něco mi tu bliká", „přišel divný e-mail", „počítač je pomalý". Je to nejčastější zdroj a zároveň nejméně přesný – ale nepodceňuj ho, protože uživatel často zaznamená věci, které žádný nástroj nevidí. Za druhé sonda IDS/IPS: pozná známý vzor útoku a vystaví alert. Je rychlá a konkrétní, ale vidí jen to, co jí prochází pod nosem a co má v signaturách. Za třetí monitoring a logy: server, který přestal odpovídat, prudký nárůst provozu, opakované neúspěšné přihlášení. To je pomalejší signál, zato ukazuje souvislosti. A za čtvrté nástraha (honeypot): zařízení, které nemá žádný legitimní důvod, aby s ním kdokoli mluvil. Když se u něj objeví spojení, není to skoro nikdy planý poplach – proto je nástraha nejčistší signál, jaký v síti můžeš mít. Praktický závěr zní: nespoléhej na jediný zdroj. Sonda mlčí u toho, co nemá v signaturách, uživatel si nevšimne tichého odesílání dat a monitoring uvidí až následek. Teprve dohromady tvoří síť, do které se incident chytí – a čím dřív se chytí, tím menší je škoda.
Krok za krokem
- Nejčastěji se první ozve uživatel: „přišel divný e-mail", „počítač je pomalý". Nepřesné, ale často to vidí dřív než nástroje.
- Sonda IDS/IPS pozná známý vzor útoku a vystaví alert. Rychlá a konkrétní – ale vidí jen to, co má v signaturách.
- Monitoring a logy ukážou server, který přestal odpovídat, nebo opakovaná neúspěšná přihlášení. Pomalejší, zato v souvislostech.
- Nástraha nemá legitimní důvod k provozu, takže spojení u ní je nejčistší signál. Spoléhat na jediný zdroj se nevyplácí.
Poplach vs. incident
Mezi „přišel alert" a „máme incident" je velký kus cesty a jmenuje se triage. Je to rychlé roztřídění: co je planý poplach, co je drobnost, kterou vyřídíš mimochodem, a co je skutečný incident, u kterého se spustí celý postup. Bez triage se stane jedna ze dvou špatných věcí. Buď se z každého alertu udělá poplach, tým se vyčerpá a za měsíc už si alertů nikdo nevšímá – to je únava z alertů, kterou znáš z kurzu Monitoring, logy a detekce. Nebo se naopak neudělá poplach z ničeho a skutečný průnik zapadne mezi stovkami řádků. Triage stojí na třech otázkách, které si klidně napiš na papír. Je to skutečné? Existuje potvrzení z druhého zdroje, nebo je to jediný osamocený řádek? Jak daleko to sahá? Jedno zařízení, jeden segment, nebo se to už objevuje na víc místech? Co je v sázce? Testovací počítač, nebo databáze s osobními údaji? Teprve odpovědi rozhodnou, jestli se spustí postup, a hlavně jak rychle. Užitečná zkratka: závažnost není totéž co hlasitost. Alert označený jako kritický může být šum a řádek s úrovní „informace" může být první krok průniku. Proto se v triage díváš na co se stalo a čeho se to týká, ne na to, jakou barvu má nástroj v hlášce.
Krok za krokem
- Alert přišel. Tím ale incident ještě nevzniká – mezi hlášením a incidentem je triage, rychlé roztřídění.
- První otázka: je to skutečné? Potvrdí to druhý zdroj, nebo je to jeden osamocený řádek bez opory?
- Druhá a třetí otázka: jak daleko to sahá (jedno zařízení, nebo víc míst) a co je v sázce (testovací PC, nebo databáze).
- Závažnost není totéž co hlasitost: kritický alert bývá šum, řádek „informace" může být první krok průniku.
Ověř, než spustíš poplach
Než vyhlásíš incident, ověř si, že se opravdu děje to, co si myslíš. Zní to jako zbytečné zdržení, ale je to naopak nejlevnější krok celého postupu: planý poplach stojí čas celé firmy, a hlavně otupí ochotu reagovat příště. Ověření má tři jednoduché kroky a všechny zvládneš v simulátoru. Za prvé druhý zdroj: potvrzuje alert i log na jiném zařízení? Sonda hlásí podezřelé spojení – vidíš ho i v přehledu spojení, tedy v tom, kdo s kým mluví? Když ano, je to reálný provoz, ne jen ojedinělá shoda vzoru. Za druhé čas: kdy se to objevilo poprvé a děje se to pořád? Jednorázová událost z minulého týdne je něco úplně jiného než spojení, které vzniká každou minutu. Za třetí kontext: nemá to prosté vysvětlení? Nová aplikace, plánovaná aktualizace, nový kolega, testovací provoz. Velmi mnoho „útoků" se rozpustí ve chvíli, kdy zjistíš, že v pátek začala fungovat nová záloha. Pozor ale na opačnou chybu, která je zákeřnější: ověřování nesmí být důvod nic nedělat. Když máš vážné podezření a k tomu potvrzení z druhého zdroje, kontejnment neodkládej kvůli tomu, že chceš mít stoprocentní jistotu. Rozumné pravidlo zní: ověřuj minuty, ne hodiny. Krátká kontrola tě ochrání před planým poplachem, dlouhá analýza už jen dává útočníkovi čas.
Krok za krokem
- Sonda hlásí podezřelé spojení. Zatím je to hypotéza, ne zjištění – planý poplach stojí čas celé firmy.
- Druhý zdroj: potvrzuje totéž log a přehled spojení? Když ano, je to reálný provoz, ne ojedinělá shoda vzoru.
- Čas a kontext: děje se to pořád, nebo to bylo jednou? A nemá to prosté vysvětlení – nová záloha, aktualizace, test?
- Ověřování ale nesmí být důvod nic nedělat. Krátká kontrola chrání před planým poplachem, dlouhá dává čas útočníkovi.
Lekce 3: Kontejnment: zastav šíření
Izolace zařízení a její cena
Kontejnment má jediný cíl: zastavit šíření. Není to oprava ani úklid, je to zarážka. Nejpřímější nástroj, který na to v síti máš, je karanténa – v simulátoru ji najdeš pod pravým tlačítkem myši jako Izolovat. Zařízení zůstane fyzicky na místě, ale síť ho odřízne: nemluví se sousedy, nemluví ven a nikdo nemluví s ním. Z pohledu incidentu je to velmi silný krok, protože okamžitě zmenší blast radius – tedy to, kam až se dá z napadeného zařízení dostat (pojem znáš z kurzu Switching a VLANy). Má to ale svou cenu a je poctivé ji pojmenovat hned. Za prvé uživatel přestane pracovat: když izoluješ počítač účetní, účetní nedělá. Když izoluješ server, stojí všechno, co na něm závisí. Za druhé izolace je vidět: útočník, který na zařízení sedí, okamžitě pozná, že jsi ho odhalil, a může zareagovat – zahladit stopy nebo přeskočit jinam, pokud už jinde je. A za třetí, což se přehlíží nejčastěji: izolace není důkaz. Odříznuté zařízení dál obsahuje to, co ho napadlo, a jakmile ho vrátíš do sítě bez nápravy, začne znovu. Karanténa je proto výborný první krok, ne poslední. Zastaví hodiny a dá ti prostor zjistit, co se stalo – a přesně o to v kontejnmentu jde: koupit si čas, aniž bys zničil podklady pro vyšetřování.
Krok za krokem
- Napadené PC se odsud dostane dál – na server i ven. To, kam až dosáhne, je jeho blast radius.
- Karanténa: pravé tlačítko → Izolovat. Zařízení zůstane na místě, ale síť ho odřízne od okolí i od internetu.
- Zbytek sítě jede dál a blast radius se zmenšil. Cena je ale reálná: izolovaný uživatel nebo server nepracuje.
- Pozor: izolace není náprava. Zařízení dál obsahuje to, co ho napadlo – bez opravy začne po návratu do sítě znovu.
Kdy izolovat a kdy sledovat
Karanténa je silný nástroj, ale ne vždycky správný. Existuje totiž druhá možnost, která se v prvním okamžiku zdá divná: nechat to běžet a dívat se. Rozhodnutí mezi „izolovat hned" a „ještě chvíli sledovat" je jedno z mála skutečně těžkých rozhodnutí celého incidentu, a proto se vyplatí znát, čím se řídí. Izoluj hned, když hrozí, že se to během minut rozšíří (šifrující malware, který postupuje po sdílených discích), když jsou v sázce citlivá data, když už vidíš aktivní odesílání ven, nebo když prostě nemáš kapacitu situaci sledovat a zároveň jí rozumět. Rychlé zastavení je skoro vždycky lepší než pomalé rozhodování. Chvíli sleduj tehdy, když ti pozorování reálně přinese to, co jinak nezískáš: kam všude útočník sáhl, kdo je jeho druhý cíl, kudy se dostal dovnitř. To dává smysl u pomalého, tichého průniku, kde jedno izolované zařízení stejně není celý příběh – a hlavně jen tehdy, když máš čím sledovat a někdo se tomu opravdu věnuje. Sledování bez monitoringu není strategie, je to jen nečinnost s lepším názvem. Rozdíl mezi oběma volbami se dá shrnout jednou větou: izolace ti zachrání síť, pozorování ti zachrání znalost. Když nemáš na výběr, ber záchranu sítě. A když se rozhodneš sledovat, dej tomu pevný časový strop a předem řekni, co se musí objevit, abys okamžitě izoloval.
Krok za krokem
- Když se to šíří v minutách nebo jsou v sázce citlivá data, izoluj hned. Rychlé zastavení bije pomalé rozhodování.
- Vidíš aktivní odesílání ven? Pak už se nečeká na dokonalé pochopení – data odcházejí právě teď.
- U tichého průniku může mít sledování smysl: ukáže, kam všude útočník sáhl. Ale jen když máš monitoring a někoho, kdo se dívá.
- Izolace zachrání síť, pozorování zachrání znalost. Když nemáš na výběr, ber síť – a sledování dej pevný časový strop.
Co izolace nevyřeší
Nejčastější chyba po úspěšném kontejnmentu je úleva. Zařízení je izolované, alerty utichly, tak je hotovo – a přesně tady incidenty ožívají podruhé. Izolace totiž řeší šíření, ale nechává nedotčené tři věci. Za prvé příčinu: pořád nevíš, jak se to tam dostalo. Když to byl e-mail s přílohou, nic ti nebrání otevřít stejnou přílohu na jiném počítači zítra. Když to byla zranitelná služba vystavená ven, sedí venku pořád. Za druhé ostatní zařízení: útočník málokdy končí na prvním stroji. Než ho izoluješ, mohl už dávno být jinde – proto po kontejnmentu následuje kontrola, jestli se stejný vzor neobjevuje i jinde, typicky v přehledu spojení a v logu. A za třetí trvalý přístup: přidaný účet, změněné pravidlo na firewallu, přesměrovaný DNS záznam – tyhle úpravy útočník stihl udělat v době, kdy měl zařízení pod kontrolou, ještě před izolací. Karanténa jednoho počítače je neodstraní a fungují dál. Praktický důsledek: po izolaci si nedávej pauzu, ale rovnou pokračuj do vyšetřování – právě proto, že karanténa zastavila hodiny a ty teď máš prostor. A ještě jedna nepříjemná zkušenost, kterou je lepší si přečíst tady než zažít: napadené zařízení se nevrací do sítě jen proto, že už nic nedělá. Vrací se až po nápravě – vyčištěné nebo přeinstalované, se změněnými hesly a s ověřením, že po návratu nezačne znovu. O tom je celá lekce Náprava a obnova.
Krok za krokem
- Zařízení je izolované a alerty utichly. Tady se lidem uleví – a přesně tady incidenty ožívají podruhé.
- Příčina zůstala nedotčená: vystavená zranitelná služba sedí venku dál, stejná příloha se dá otevřít zítra jinde.
- Útočník málokdy končí na prvním stroji. Zkontroluj, jestli se stejný vzor neobjevuje i jinde – v přehledu spojení a v logu.
- A zůstává trvalý přístup: přidaný účet, změněné pravidlo, přesměrovaný záznam. Po izolaci pokračuj rovnou do vyšetřování.
Lekce 4: Vyšetřování
Časová osa z logů
Vyšetřování incidentu vypadá v praxi mnohem méně dramaticky, než se čeká: skládáš časovou osu. Bereš jednotlivé záznamy ze syslogu, ze sondy a z alertů, řadíš je podle času a hledáš, kde příběh začíná. Osa má tři body, které chceš najít vždycky. První výskyt: nejstarší záznam, který k incidentu patří. Skoro vždy je dřív, než sis myslel – alert přišel v úterý, ale první podivné spojení je z pátku. Bod obratu: okamžik, kdy se z podezřelého chování stalo něco škodlivého (odeslání dat, změna nastavení, další zařízení). A poslední aktivita: nejnovější záznam, ze kterého poznáš, jestli je incident ještě živý. Při skládání osy pomáhá jedno pravidlo: drž se času, ne dojmu. Když má každý řádek přesný čas, přestává být důležité, co si kdo pamatuje. Právě proto se v kurzu Monitoring, logy a detekce tak trvá na jednom log serveru – bez společné osy se časy z různých zařízení srovnávají mizerně. Počítej i s tím, že v ose budou díry. Zařízení, které logy neposílalo, chvíle, kdy byl syslog zahlcený, události, které se ztratily cestou. Díru poznamenej a nedělej, že tam nic nebylo – nezaznamenané neznamená, že se nestalo. Časová osa je nejcennější výstup celého vyšetřování: z ní se odvozuje rozsah, náprava i to, co se pak napíše do post-mortemu.
Krok za krokem
- Hledej první výskyt: nejstarší záznam, který k incidentu patří. Bývá dřív, než sis myslel – alert je až následek.
- Bod obratu je okamžik, kdy se z podezřelého chování stalo škodlivé: odeslání dat, změna nastavení, další zařízení.
- Poslední aktivita ti řekne, jestli je incident ještě živý. Drž se přitom času, ne dojmu – čas na řádku nelže.
- V ose budou díry – zařízení bez logů, ztracené události. Zapiš je: nezaznamenané neznamená, že se nestalo.
Kudy se to šířilo
Časová osa říká kdy. Druhá polovina vyšetřování odpovídá na kudy – a k tomu slouží pohled na provoz jako na toky: kdo s kým mluvil, jak dlouho a kolik toho přeneslo. V simulátoru to najdeš v přehledu spojení, který jednotlivá spojení agreguje, takže místo tisíce řádků vidíš dvojice „tenhle mluví s tímhle". Pro vyšetřování to je ideální nástroj, protože průnik se skoro vždycky projeví jako nová dvojice, která tam dřív nebyla: pracovní počítač mluví s databází, na kterou nikdy nesahal; server v DMZ se ozývá dovnitř do LAN; jedna stanice mluví ven na adresu, na kterou nikdo jiný nechodí. Když k tomu přiložíš svou představu o tom, co je normální, máš odpověď na otázku, kam až se to dostalo. To druhé, co z toků odvodíš, je blast radius: skutečný, ne teoretický. Teoretický blast radius sis mohl spočítat předem – „z DMZ se dá na databázi". Skutečný uvidíš v tocích: útočník se opravdu na databázi podíval, nebo jen zkoušel a narazil na pravidlo? Rozdíl mezi „mohl by" a „opravdu byl" je pro rozsah incidentu zásadní, protože rozhoduje, kterých systémů se týká náprava a co se musí hlásit dál. Praktický postup je jednoduchý: vyjdi od napadeného zařízení a jdi po spojích dál – s kým mluvilo, a s kým mluvili oni. Když se ti seznam přestane rozrůstat, znáš hranici incidentu.
Krok za krokem
- Přehled spojení agreguje provoz do dvojic „kdo s kým mluví". Tohle je normální tok, který tam patří vždycky.
- Průnik se projeví jako nová dvojice: počítač mluví se serverem, na který nikdy nesahal. To je stopa, po které jdeš dál.
- Druhá typická stopa: jedna stanice mluví ven na adresu, na kterou nikdo jiný nechodí. Odesílá se něco právě teď?
- Z toků odvodíš skutečný blast radius: kam se útočník opravdu dostal, ne kam by teoreticky mohl. To určí rozsah nápravy.
Co si zapsat
Při incidentu se pracuje rychle a v hlavě zůstane jen zlomek. Proto se od začátku zapisuje – a překvapivě to není administrativa navíc, ale nejlevnější způsob, jak si ušetřit práci později. Zapisují se dvě různé věci. Za prvé zjištění: co jsi viděl, kde a v kolik hodin. „14:02 – v přehledu spojení nové spojení z PC na server, dřív tam nebylo." Za druhé své vlastní kroky: co jsi udělal a kdy. „14:09 – PC izolováno." Druhá část se podceňuje a pak chybí nejvíc, protože bez ní se za dva dny nedá odlišit, co způsobil útočník a co ty sám při úklidu. Kolem důkazů existuje pojem chain of custody – řetězec, ve kterém je u každého záznamu jasné, kdo ho pořídil, kdy a co se s ním od té doby dělo. Přesná pravidla jsou věcí právníků a forenzních specialistů; tobě stačí rozumět principu a chovat se podle něj: záznamy se kopírují, neupravují, ukládají se mimo napadené zařízení a poznamená se, kdo je vzal. Když se z incidentu později stane právní věc nebo pojistná událost, tohle rozhoduje o tom, jestli tvoje podklady k něčemu jsou. A jedna vysloveně praktická rada: nezačínej úklidem. Restart, přeinstalace nebo smazání podezřelého souboru jsou nevratné kroky, které často zničí právě to, co bys za hodinu potřeboval. Nejdřív zaznamenej, potom uklízej. Základ ti simulátor připraví sám: v panelu Syslog je tlačítko sestavit zprávu – vygeneruje časovou osu událostí, izolovaná zařízení a pozorovaná spojení, a ty doplníš vlastní kroky.
Krok za krokem
- Zapisuj zjištění: co jsi viděl, kde a v kolik. „14:02 – nové spojení z PC na server, dřív tam nebylo."
- A hlavně své vlastní kroky: „14:09 – PC izolováno." Bez toho za dva dny nerozlišíš útočníka od vlastního úklidu.
- Důkazy se kopírují, neupravují, a ukládají mimo napadené zařízení. Poznamená se, kdo je vzal a kdy.
- Nezačínej úklidem. Restart, přeinstalace a mazání jsou nevratné a často zničí právě to, co budeš za hodinu potřebovat.
Lekce 5: Náprava a obnova
Odstranit příčinu, ne příznak
Náprava je fáze, ve které se odstraňuje to, co incident umožnilo. Zní to samozřejmě, jenže v praxi se místo příčiny běžně odstraní příznak – protože příznak je vidět a příčina ne. Typické příklady poznáš snadno: server se zasekl, tak se restartoval; podivné spojení se zablokovalo pravidlem na firewallu; napadený počítač se přeinstaloval. Ve všech třech případech přestalo být vidět to, co vadilo. Ale otázka „jak se to tam dostalo?" zůstala nezodpovězená, a dokud zůstane, incident se vrátí – klidně na jiném zařízení a s jiným příznakem. Rozlišit obojí pomáhá jednoduchá otázka, kterou si polož u každého kroku nápravy: kdyby útočník zkusil totéž znovu, prošel by? Když ano, opravoval jsi příznak. Příčiny v síti bývají nudné a opakují se: vystavená služba, která venku být neměla; chybějící aktualizace; sdílené nebo výchozí heslo; příliš široké pravidlo, které povolí víc, než mělo; chybějící segmentace, díky které se z jednoho stroje dalo všude. Náprava je pak stejně nudná: zavřít, doplnit, zúžit, oddělit. Do nápravy patří i zrušení trvalého přístupu, o kterém byla řeč u kontejnmentu: přidané účty, změněná pravidla, přesměrované záznamy. A pozor na jednu past: neopravuj naslepo dřív, než víš, co se stalo. Vypnout půl sítě „pro jistotu" je také zásah – nevratný pro vyšetřování a bolestivý pro provoz.
Krok za krokem
- Server se zasekl, tak se restartoval; podivné spojení se zablokovalo. Vidět to není – ale to je příznak, ne příčina.
- Otázka „jak se to tam dostalo?" zůstala. Vystavená služba, chybějící aktualizace nebo široké pravidlo tam jsou dál.
- Náprava je stejně nudná jako příčina: zavřít, doplnit, zúžit, oddělit – a zrušit trvalý přístup, který si útočník zřídil.
- U každého kroku se ptej: kdyby útočník zkusil totéž znovu, prošel by? Když ano, opravoval jsi příznak.
Vrátit do provozu bezpečně
Obnova je návrat do normálu – a je to fáze, ve které se dělá poslední velká chyba incidentu: vrátí se všechno naráz a bez kontroly. Rozumný postup má čtyři kroky. Za prvé vracej po částech a v pořadí podle důležitosti. Když zapneš vše najednou a něco se pokazí, nevíš co – když vracíš po jednom, víš to okamžitě. Za druhé dívej se přitom: po každém návratu zkontroluj logy, alerty a přehled spojení. Právě tady se pozná, jestli byla náprava úplná: když se stará dvojice „kdo s kým mluví" objeví znovu, nebylo hotovo. Za třetí ověř, že síť je zase odolná. Během incidentu jsi možná něco odpojil, zablokoval nebo přepnul na náhradní trasu – a snadno se stane, že síť sice jede, ale už jen po jedné cestě. Na tohle je v simulátoru N-1 test: postupně vyřazuje jednotlivé prvky a ukazuje, co po jejich výpadku přestane fungovat. Když po incidentu N-1 test ukáže nové jediné body selhání, obnova ještě neskončila. Ke stejnému účelu slouží kontrola topologie, která najde zapomenuté odpojené kabely nebo osiřelá zařízení. A za čtvrté zkontroluj, že to opravdu funguje uživatelům, ne jen tobě na diagramu. Zavolej člověku, který incident nahlásil, a nech ho vyzkoušet to, co nešlo. Věta „u nás to jede" je nejslabší možný důkaz obnovy.
Krok za krokem
- Vracej po částech a podle důležitosti. Když zapneš vše naráz a něco se pokazí, nevíš co – po jednom to poznáš hned.
- Po každém návratu koukni do logů a přehledu spojení. Když se stará podezřelá dvojice objeví znovu, náprava nebyla úplná.
- Spusť N-1 test a kontrolu topologie: síť sice jede, ale nezůstala po zásahu jen jedna cesta a odpojené kabely?
- Nakonec to nech vyzkoušet uživateli, který incident nahlásil. „U nás to jede" je nejslabší možný důkaz obnovy.
Kdy je incident uzavřený
Incidenty mají zvláštní vlastnost: často nikdy formálně neskončí. Provoz jede, nikdo si nestěžuje, tak se na to prostě přestane myslet – a za měsíc si nikdo nepamatuje, co se vlastně vyřešilo a co ne. Proto se uzavření incidentu vyslovuje nahlas a má svoje podmínky. Jsou čtyři a nejde ani jednu přeskočit. Za prvé příčina je odstraněná, ne jen zakrytá – umíš odpovědět na otázku, jak se to dovnitř dostalo, a ta cesta je zavřená. Za druhé rozsah je známý: víš, kterých zařízení a dat se to týkalo, a u těch, kde sis jistý nejsi, jsi to zapsal. Za třetí provoz běží normálně a ověřil to někdo jiný než ty. A za čtvrté je co předat dál: existuje zápis s časovou osou, se seznamem tvých kroků a s tím, co zbývá dodělat. Když některá podmínka neplatí, incident není uzavřený – je jen tichý, což není totéž. Zvláštní kategorie je incident, u kterého se nepodařilo zjistit všechno. To je běžné a není to ostuda; důležité je uzavřít ho poctivě: napsat, co víš, co nevíš a jaké riziko z toho plyne. Pak se rozhodne, jestli se pokračuje ve vyšetřování, nebo se přijme zbytkové riziko a posílí monitoring. Uzavření incidentu má nakonec ještě jednu funkci, pro tým velmi důležitou: je to okamžik, kdy se přestává hasit a začíná se přemýšlet – tedy vstup do poslední fáze, ponaučení.
Krok za krokem
- První podmínka: příčina je odstraněná, ne jen zakrytá. Umíš říct, jak se to dovnitř dostalo, a ta cesta je zavřená.
- Druhá: rozsah je známý – víš, kterých zařízení a dat se to týkalo. Tam, kde si jistý nejsi, to máš zapsané.
- Třetí: provoz běží normálně a ověřil to někdo jiný než ty. Čtvrtá: existuje zápis, který se dá předat dál.
- Když se nepodařilo zjistit všechno, uzavři to poctivě: co víš, co nevíš a jaké zbytkové riziko z toho plyne.
Lekce 6: Ponaučení
Post-mortem bez viníků
Poslední fáze je ta, která se vynechává nejčastěji, a přitom jako jediná zlepšuje příští incident. Post-mortem je krátké setkání po uzavření, na kterém se projde, co se stalo a co s tím dál. Klíčové slovo je bez viníků: nehledá se, kdo to zavinil, ale co to umožnilo. Není to laskavost k lidem, je to praktické opatření. Když se hledá viník, lidé přestanou hlásit chyby a příště se o incidentu dozvíš mnohem později, tedy dráž. Když se hledají příčiny, mluví se otevřeně a najdeš i věci, které by ti jinak nikdo neřekl. Post-mortem má krátkou osnovu, kterou zvládneš na půl stránky. Co se stalo – časová osa v pár bodech. Jak jsme to zjistili – a hlavně, jestli to šlo zjistit dřív; tohle je nejcennější otázka celého setkání. Co jsme udělali – kroky včetně těch, které nezabraly. Co změníme – konkrétní opatření, každé s jedním jménem a jedním termínem. Bez posledního bodu je post-mortem jen povídání. Dvě věci, které nemají v post-mortemu co dělat: obecné závěry typu „musíme být opatrnější" (to není opatření, to je přání) a seznam všeho, co by šlo teoreticky zlepšit. Lepší jsou tři změny, které se opravdu udělají, než třicet bodů, které nikdo neotevře. Kurz Když síť nefunguje k tomu dodává jedno: i incident, který dopadl dobře, stojí za půlhodinu rozboru.
Krok za krokem
- Co se stalo: časová osa v pár bodech, poskládaná z logů. Ne román – stačí body, ze kterých je vidět sled událostí.
- Jak jsme to zjistili – a hlavně, šlo to zjistit dřív? To je nejcennější otázka celého setkání.
- Co jsme udělali, včetně kroků, které nezabraly. Právě ty se učí nejhůř a jinde než tady se o nich nemluví.
- Co změníme: konkrétní opatření, každé s jedním jménem a jedním termínem. Bez toho je post-mortem jen povídání.
Co změnit v síti
Opatření z post-mortemu se skoro vždycky dají zařadit do tří skupin – a je užitečné je znát dopředu, protože ti napoví, kde hledat. První je segmentace. Otázka zní: kdyby se totéž stalo znovu, dostal by se útočník stejně daleko? Když ano, chybí hranice. Rozdělení do VLAN, oddělení serverů od uživatelských počítačů, zvláštní segment pro věci, se kterými nikdo běžně nepracuje – to všechno zmenšuje blast radius a je to nejúčinnější změna, kterou po incidentu můžeš udělat. Druhá je pravidla. Projdi ta, která incident umožnil, a hledej příliš široká povolení: „odkudkoli", „na jakýkoli port", pravidla bez popisu, pravidla, o kterých nikdo neví, proč tam jsou. Ke každému si polož otázku, kterou znáš z kurzu Zabezpečení sítě: kdo přesně to potřebuje a proč. Třetí je monitoring. Tady se ptáš jinak: šlo to zjistit dřív? Odpovědí bývá doplnit logování tam, kde chybělo, poslat na log server i zařízení, které se zapomnělo, nebo postavit nástrahu – zařízení bez legitimního provozu, u kterého je každé spojení skutečný signál. Ať vybereš cokoli, drž se jednoho pravidla: málo změn, ale dotažených. Po incidentu je chuť překopat celou síť, jenže rozdělaná segmentace je horší než žádná. Vyber tři věci, u každé napiš, kdo a do kdy – a příště začínáš z lepší pozice.
Krok za krokem
- Otázka číslo jedna: dostal by se útočník znovu stejně daleko? Když ano, chybí v síti hranice.
- Segmentace: VLANy, oddělení serverů od uživatelů, zvláštní segment pro to, s čím nikdo běžně nepracuje.
- Pravidla: projdi ta široká – „odkudkoli", „jakýkoli port", bez popisu. U každého se ptej, kdo to přesně potřebuje.
- Monitoring: doplň logování tam, kde chybělo, nebo postav nástrahu. A drž se pravidla: málo změn, ale dotažených.
Kontrolní seznam připravenosti
Na závěr kurzu si shrňme celou reakci do seznamu, který se dá projít za pár minut a který ti řekne, jak jsi na tom dnes, ne až za tři měsíce. Sbíráš logy na jedno místo? Ověř, že tam posílají i firewall, sonda a servery – a že to opravdu dorazí; syslog jede přes UDP 514 a cestou se ztrácí tiše. Poznáš, co je normální? Otevři přehled spojení a projdi dvojice „kdo s kým mluví". Když je vidíš poprvé až při incidentu, nemáš s čím srovnávat. Víš, kdo rozhoduje a koho voláš? Kontakty a hranice eskalace mají být na papíře, ne v hlavě jednoho člověka. Umíš zařízení izolovat? Zkus si karanténu nanečisto a všimni si, co všechno tím zastavíš – ať to nezjišťuješ poprvé v krizi. Máš zálohy konfigurace a víš, jak se vracejí? Záloha, kterou jsi nikdy nezkoušel obnovit, je jen naděje. Přežije síť výpadek jednoho prvku? Spusť N-1 test a kontrolu topologie; jediné body selhání se hledají v klidu. A poslední, nepříjemná otázka: kdy jsi to naposledy zkoušel? Postup, který nikdo nikdy neprošel, není postup, ale dokument. Půlhodinové cvičení nanečisto – „server je napadený, co teď?" – najde chybějící kontakt i chybějící logy spolehlivěji než jakýkoli audit. Reakce na incident se totiž netrénuje při incidentu.
Krok za krokem
- Sbíráš logy na jedno místo? A dorazí tam i od firewallu a sondy? Syslog jede přes UDP 514 a ztrácí se tiše.
- Poznáš, co je normální? Projdi dvojice v přehledu spojení. Když je vidíš poprvé při incidentu, nemáš s čím srovnávat.
- Umíš zařízení izolovat? Zkus karanténu nanečisto a všimni si, co všechno tím zastavíš – ne až v krizi.
- A poslední otázka: kdy jsi to naposledy zkoušel? Reakce na incident se netrénuje při incidentu, ale v klidu.