Kybernetický incident málokdy začíná zprávou „byli jste napadeni“. Prvním signálem bývá obvykle podezřelé přihlášení do firemního účtu, neočekávané pravidlo pro přesměrování e-mailů, deaktivovaný agent EDR, nedostupný server nebo stížnost zaměstnance na neobvyklou výzvu k vícefaktorovému ověření.

V tomto okamžiku organizace ještě nezná rozsah útoku. Právě první rozhodnutí však určují, zda událost zůstane lokálním problémem, nebo se promění v několik týdnů trvající krizi s zastavením podnikání, ztrátou dat a poškozením reputace.

Času na tato rozhodnutí je stále méně. V nejrychlejších případech, které Unit 42 vyšetřila, trvalo útočníkům 72 minut, než se dostali od počátečního přístupu k potvrzenému odeslání dat. To je přibližně čtyřikrát rychlejší než před rokem. Nejde o průměrnou dobu u všech útoků, ale o nejrychlejší případy, avšak tento ukazatel dobře demonstruje, jak výrazně se zúžilo časové okno pro obránce. V našich vlastních vyšetřováních jsme se setkali s útoky na infrastrukturu AWS trvajícími méně než 10 minut. Útočník, jakmile získal klíč, okamžitě zahájil odesílání dat. Trvalo mu pouhých 6 minut, než začal odesílat data z úložiště společnosti.

Správná reakce v roce 2026 nebude spočívat v hrdinském zmatku službu konající směny. Jedná se o předem připravený a řízený proces, který umožňuje rychle omezit činnost útočníka, zachovat důkazy, zajistit provoz kritických operací a obnovit funkčnost systémů bez opětovného ohrožení.

Co se do roku 2026 změnilo

Útok se již neomezuje na jeden systém

Současný útočník může současně využívat lokální infrastrukturu, cloudový účet, firemní e-mail, SaaS aplikace i přístup dodavatele.

I po izolaci infikovaného notebooku mu mohou zůstat:

  • aktivní cloudová relace;
  • refresh token;
  • OAuth oprávnění;
  • klíč API;
  • kompromitovaný služební účet;
  • delegovaný administrativní přístup;
  • záložní kanál pro správu prostřednictvím legitimní cloudové služby.

Podle údajů Unit 42 bylo v 87 % zkoumaných incidentů k objasnění události nutné porovnat důkazy z minimálně dvou různých zdrojů, v nejsložitějších případech dokonce z deseti. To znamená, že vyšetřování již nelze omezovat na jeden počítač nebo jeden protokol událostí: je nutné současně analyzovat identifikační údaje, koncová zařízení, síť, cloud a SaaS. (Unit 42)

Model „najít škodlivý soubor, odstranit ho a přeinstalovat počítač“ již nezajišťuje plnohodnotnou ochranu.

Identity a zranitelnosti jsou stejně důležité

Současný incident nemá jediný univerzální vektor proniknutí.

Podle údajů Unit 42 bylo 65 % počátečních vniknutí v jejích vyšetřováních spojeno s technikami založenými na identitě: ukradenými přihlašovacími údaji, manipulací s MFA, únosem relací, vydáváním se za zaměstnance technické podpory nebo zneužitím legitimního vzdáleného přístupu. (Unit 42)

Zároveň zpráva Verizon DBIR 2026 uvádí zneužití softwarových zranitelností jako hlavní počáteční vektor ve svém vzorku: objevilo se v 31 % úniků a poprvé předstihlo odcizené přihlašovací údaje.

Praktický závěr: nelze volit mezi ochranou identit a řízením zranitelností. Vyspělý program reakce na incidenty musí pokrývat obě oblasti. Tým musí být schopen současně rušit tokeny a relace, analyzovat privilegovaný přístup, uzavírat zranitelné externí služby a zjistit, jakou konkrétní cestu útočník použil.

Dodavatelé se stali součástí útočné plochy

Podle údajů ze zprávy Verizon DBIR 2026 se třetí strany podílely na 48 % úniků dat – o 60 % častěji než v předchozím roce. Jako vstupní bod může sloužit dodavatel softwaru, MSP, integrátor, cloudová služba nebo subdodavatel s legitimním přístupem.

Organizace musí předem vědět:

  • kdo může poskytnout protokoly dodavatele;
  • jak rychle lze jeho přístup odebrat;
  • jak dlouho se uchovávají telemetrická data;
  • jaké činnosti jsou povoleny smlouvou;
  • kdo odpovídá za komunikaci;
  • jak uchovat důkazy v cizí infrastruktuře.

Pokud se tyto otázky objeví až během útoku, tým již ztrácí drahocenný čas.

Vydírání již nevyžaduje šifrování

Šifrování infrastruktury zůstává vážnou hrozbou, ale již není povinnou součástí vydírání. Útočníci mohou ukrást data a okamžitě přejít k vyhrožování zveřejněním nebo prodejem, aniž by vyvolávali masivní šifrovací události, na které jsou tradičně nastaveny ochranné prostředky.

Ransomware se vyskytoval téměř v polovině úniků dat, které zkoumala zpráva Verizon DBIR 2026. Absence zašifrovaných serverů však neznamená, že incident je bezvýznamný: neoprávněný přístup k e-mailům, systému CRM, úložišti souborů nebo cloudovému prostředí může vést ke srovnatelným finančním a reputačním důsledkům.

AI urychluje obě strany

AI pomáhá útočníkům rychleji analyzovat útočnou plochu, přizpůsobovat sociální inženýrství, hledat zranitelnosti a vytvářet škodlivý kód. Zpráva Verizon DBIR 2026 vyzdvihuje 15 útočných technik, které jsou již posilovány pomocí generativní AI.

Obránci zase využívají modely ke korelaci událostí, vytváření časových os, seskupování výstrah a přípravě dotazů pro vyhledávání hrozeb (threat hunting).

Automatizace však nenahrazuje proces ověřování. Rychlý mylný závěr v krizové situaci se může ukázat jako neméně nebezpečný než pomalá reakce.

Nový rámec: reakce začíná ještě před incidentem

V dubnu 2025 vydal NIST normu SP 800-61 Revision 3, která nahradila pokyny z roku 2012.

Hlavní změnou je, že reakce na incidenty již není považována za samostatný lineární proces, který se spouští po výstraze. Je začleněna do obecného modelu řízení kybernetických rizik NIST CSF 2.0 a souvisí se všemi šesti jeho funkcemi:

Govern, Identify, Protect, Detect, Respond a Recover.

Správa rolí, inventarizace aktiv, segmentace, zálohování, smlouvy s dodavateli a protokolování nejsou pouze podpůrná opatření, ale tvoří součást připravenosti na incident. (NIST Computer Security Resource Center)

Dne 11. června 2026 NIST rovněž zveřejnil IR 8374 Revision 1 – aktualizovaný profil řízení rizik spojených s ransomwarem na základě CSF 2.0. Dokument propojuje přípravu, ochranu, reakci a obnovu do jednotného cyklu řízení rizik. (NIST Computer Security Resource Center)

Hlavní závěr je jednoduchý:

Správná reakce začíná dlouho před prvním výstrahovým signálem.

Ještě před incidentem musí organizace definovat role a pravomoci, připravit komunikační kanál mimo síť, zajistit dostatečné uchovávání protokolů, zabezpečit záložní kopie a otestovat postupy obnovy. Rovněž jsou nezbytné samostatné postupy pro ransomware, kompromitaci firemní e-mailové komunikace, převzetí cloudových účtů, krádež dat a útoky prostřednictvím dodavatele.

Zvláštní význam mají nácviky. Plán, který existuje pouze na papíře a nikdy nebyl prověřen pod časovým tlakem, zůstává pouhou hypotézou, nikoli nástrojem ochrany.

Prvních 60 minut: neřešte situaci naslepo

Na začátku incidentu má tým téměř vždy k dispozici neúplné informace.

V tomto okamžiku jsou nebezpečné nejen akce útočníka, ale i impulzivní rozhodnutí obránců: hromadné vypínání serverů, předčasné vyčištění systémů, chaotická změna hesel nebo okamžité obnovení z neověřené zálohy.

1. Jmenujte vedoucího incidentu

Seriozní vyšetřování nelze vést prostřednictvím chaotických telefonátů, osobních zpráv a desítek paralelních chatů.

Je nezbytný jednotný „response bridge“ a jmenovaný vedoucí incidentu – Incident Commander.

Ten nemusí osobně provádět forenzní operace. Jeho úkolem je řídit proces:

  • dbát na dodržování jednotného plánu;
  • určovat odpovědné osoby za jednotlivé úkoly;
  • řešit konflikty priorit;
  • zaznamenávat rozhodnutí;
  • synchronizovat technické a řídící toky;
  • pravidelně aktualizovat potvrzený stav;
  • kontrolovat koordinaci kritických akcí.

Technicky nejzkušenější specialista nemusí nutně řídit celý incident. Analytici vyšetřují útok, zatímco velitel incidentu (Incident Commander) zajišťuje, aby se vyšetřování nezměnilo v soubor nekoordinovaných činností.

2. Přepněte na důvěryhodný komunikační kanál

Pokud může dojít ke kompromitaci firemní e-mailové schránky, systému identifikace nebo messengeru, nelze v nich diskutovat o vyšetřování.

Použijte předem připravený out-of-band kanál. Prostřednictvím potenciálně kompromitovaných systémů by se neměly předávat:

  • plány izolace;
  • hypotézy vyšetřování;
  • nová hesla;
  • klíče a tokeny;
  • shromážděné důkazy;
  • informace o komunikaci s útočníkem;
  • interní rozhodnutí vedení.

Útočník, který sleduje kroky týmu, získává možnost změnit taktiku, zahladit stopy a předem připravit alternativní přístupové kanály.

3. Potvrďte incident a určete jeho počáteční rozsah

Není třeba čekat na úplný přehled situace, abyste mohli začít reagovat.

Prvotní posouzení by mělo odpovědět alespoň na pět otázek:

  1. Co přesně bylo zjištěno?
  2. Kteří uživatelé, zařízení a služby mohou být zasaženi?
  3. Pokračuje aktivita útočníka?
  4. Hrozí riziko zastavení kritického procesu?
  5. Existují známky krádeže dat, zničení záložních kopií nebo zneužití privilegovaného přístupu?

Klasifikace se může v průběhu vyšetřování měnit. Hlavní je co nejdříve vytvořit pracovní hypotézu a stanovit priority.

Je užitečné hned od začátku rozlišovat mezi potvrzenými fakty, pravděpodobnými závěry, neověřenými hypotézami a neznámými okolnostmi. Tím se snižuje riziko, že domněnka jednoho analytika se stane základem pro katastrofální manažerské rozhodnutí.

4. Izolujte důkazy, ale nezničte je

Izolace a vypnutí nejsou totéž.

Napadený hostitel by měl být obvykle odpojen od sítě pomocí nástrojů EDR, NAC, VLAN, přepínače nebo cloudové politiky. Bez nutnosti však není vhodné jej okamžitě:

  • vypínat nebo restartovat;
  • mazat soubory;
  • spouštět antivirovou kontrolu;
  • přeinstalovat operační systém;
  • uvádět zařízení zpět do provozu po povrchní kontrole.

V operační paměti se mohou nacházet šifrovací klíče, aktivní síťová připojení, spuštěné procesy, přístupové tokeny, nezaznamenané příkazy a stopy nástrojů útočníka.

Výjimky jsou možné v případech, kdy další provoz systému představuje nepřijatelnou hrozbu pro osoby, kritickou infrastrukturu nebo podnikání. Takové rozhodnutí však musí být učiněno s plným vědomím a zaznamenáno do protokolu o incidentu.

5. Zaveďte jednotnou časovou osu

Zaznamenávejte každou významnou událost:

  • čas prvního signálu;
  • zdroj detekce;
  • změnu stavu systémů;
  • příkazy správců;
  • izolaci zařízení;
  • blokování účtů;
  • export protokolů;
  • vytváření snímků;
  • přijatá rozhodnutí;
  • osoby odpovědné a osoby, které opatření schválily.

Používejte jednotné časové pásmo, nejlépe UTC. Uchovávejte původní protokoly odděleně od pracovních kopií, vypočítávejte kontrolní součty shromážděných souborů a zaznamenávejte, kdo a kdy s důkazy pracoval.

Bez časové osy se vyšetřování rychle promění v soubor protichůdných vzpomínek.

6. Chraňte záložní kopie

Při incidentu s ransomwarem se zálohovací systémy často stávají jedním z prvních cílů útočníka.

Nezačínejte s hromadnou obnovou, dokud nezjistíte:

  • má útočník přístup k zálohovací konzoli;
  • zda byly kompromitovány účty operátorů;
  • zda byly smazány snímky;
  • zda byly změněny zásady ukládání dat;
  • kdy pravděpodobně došlo k původnímu vniknutí;
  • zda vybraná kopie neobsahuje mechanismus fixace;
  • zda byly zachovány izolované nebo neměnné kopie.

Úspěšný stav posledního zálohovacího úlohy potvrzuje pouze to, že kopie byla vytvořena. Nepotvrzuje, že je čistá a vhodná pro bezpečné obnovení.

V případě aktivního incidentu může tým DFIR PWN-ALL převzít technickou koordinaci: primární zadržení, zajištění důkazů, určení rozsahu kompromitace a přípravu bezpečného plánu obnovy. Naše společnost má zkušenosti s řešením případů ransomwaru, krádeží dat, BEC, zneužití přihlašovacích údajů a narušení cloudových prostředí.

Reakce by měla probíhat v několika paralelních vláknech

Častou chybou je nejprve dokončit technické vyšetřování a teprve poté zapojit vedení, právníky, pojišťovnu a majitele firmy.

Při skutečné události musí tyto procesy probíhat souběžně.

Technická linie

Tým musí lokalizovat útočníka, určit pravděpodobný počáteční vektor útoku, identifikovat postižené aktiva a subjekty, odhalit mechanismy proniknutí, vyhodnotit možný únik dat a připravit bezpečné obnovení.

Řídící tok

Vedení a vlastníci procesů musí posoudit dopad na podnikání, stanovit priority obnovy, určit přijatelnou dobu výpadku a koordinovat opatření, která mohou zastavit kritické procesy.

Právní a komunikační postup

Souběžně je nutné určit vlastníky dotčených dat, prověřit smluvní závazky, stanovit platné požadavky na oznamovací povinnost, kontaktovat pojistitele a připravit interní i externí sdělení.

Konkrétní požadavky se liší v závislosti na odvětví, smlouvách a jurisdikcích. Právní posouzení proto nesmí čekat na konečnou forenzní zprávu.

Úkolem týmu DFIR je poskytnout tomuto toku ověřitelné technické skutečnosti: časovou osu, seznam dotčených aktiv, potvrzené indikátory, posouzení počátečního přístupu a informace o možné exfiltraci. Konečné právní posouzení zůstává v kompetenci příslušných poradců organizace.

Identity takeback: znovuzískání kontroly nad identitami

V hybridní infrastruktuře nestačí pouze obnovit server. Organizace se nejprve musí ujistit, že opět ovládá svůj vlastní identifikační systém.

Kontrole podléhají:

  • privilegované a nouzové účty;
  • aktivní relace a refresh tokeny;
  • nové nebo změněné metody MFA;
  • aplikace OAuth a udělená oprávnění;
  • servisní subjekty a identity pracovních úloh;
  • pravidla federace;
  • zásady podmíněného přístupu;
  • delegovaný administrativní přístup;
  • klíče API, certifikáty a tajné klíče CI/CD;
  • pravidla pro přeposílání e-mailů;
  • registrovaná zařízení;
  • přístup dodavatelů.

Změna hesla ne vždy ukončí aktuální cloudovou relaci. Rotace přihlašovacích údajů by proto měla být doprovázena odvoláním tokenů, ukončením relací a ověřením důvěryhodných aplikací.

Zvláště nebezpečné je provádět hromadnou rotaci z napadeného administrativního prostředí.

Nejprve se vytvoří čistá pracovní zóna s ověřenými zařízeními, samostatným komunikačním kanálem, kontrolovanými účty a samostatným protokolováním. Teprve poté začíná koordinované převzetí identity.

Cloud a SaaS vyžadují samostatný postup

Incident v cloudu nelze vyšetřovat jako běžnou infekci pracovní stanice.

Část důkazů existuje pouze v protokolech poskytovatele a může být uchovávána pouze po omezenou dobu. V prvních hodinách je třeba zachovat:

  • přihlašovací a auditní protokoly;
  • historii změn IAM;
  • protokoly řídicí roviny;
  • události týkající se e-mailu a spolupráce;
  • změny zásad a síťových pravidel;
  • údaje o vytváření klíčů a tokenů;
  • snímky disků a konfigurací;
  • data SaaS aplikací propojených přes SSO nebo OAuth.

Samostatně je třeba zkontrolovat vytvoření nových správců, změnu federace, vydávání tokenů s dlouhou platností, udělení souhlasu OAuth, deaktivaci bezpečnostních zásad, spuštění nových cloudových zdrojů a export dat.

Postup pro nouzovou eskalaci k poskytovateli, pravomoci jednotlivých stran a postup pro uchovávání telemetrických údajů musí být stanoveny předem.

PWN-ALL využívá samostatné procesy pro vyšetřování kompromitace služeb Microsoft 365, Google Workspace, cloudové infrastruktury a firemních účtů. To umožňuje analyzovat akce, které nemusely zanechat stopy na tradičních koncových bodech.

Jak využít umělou inteligenci při vyšetřování

Umělá inteligence může urychlit:

  • normalizaci událostí;
  • seskupování výstrah;
  • vytváření časové osy;
  • přípravu dotazů pro vyhledávání hrozeb;
  • porovnání indikátorů;
  • vyhledávání anomálií;
  • analýzu velkých objemů protokolů;
  • příprava průběžných přehledů.

Model by však neměl samostatně přijímat rozhodnutí s vysokým potenciálním rizikem.

Bezpečný proces předpokládá použití kontrolovaného prostředí, minimalizaci citlivých dat, protokolování dotazů a odpovědí, ověření závěrů analytikem a přiřazení každé hypotézy k původním telemetrickým údajům.

Bez dodatečného schválení nelze modelu svěřit vypnutí kritického segmentu, smazání uživatelských účtů, hromadnou rotaci přístupových klíčů, zničení artefaktů, zveřejnění zpráv klientům ani konečný závěr o neexistenci úniku dat.

Umělá inteligence může navrhnout směr vyšetřování. Odpovědnost za závěr však zůstává na člověku.

Obnova neznamená návrat do původního stavu

Nejnebezpečnější věta během incidentu:

„Prostě to všechno obnovíme ze zálohy.“

Pokud obnovíte původní architekturu včetně původních zranitelností, kompromitovaných tajných údajů a chyb v konfiguraci, útočník se může vrátit.

Bezpečná obnova se provádí postupně:

  1. Vytvoří se čisté administrativní prostředí.
  2. Získá se zpět kontrola nad identitami.
  3. Uzavře se původní vektor proniknutí.
  4. Odstraní se mechanismy pro upevnění.
  5. Provede se rotace tajných údajů, klíčů, tokenů a certifikátů.
  6. Zkontrolují se záložní kopie.
  7. Obnovují se kritické závislosti.
  8. Systémy se připojují prostřednictvím kontrolovaných skupin.
  9. V každé fázi se kontroluje bezpečnost a funkčnost.
  10. Po spuštění pokračuje intenzivní monitorování.

Obchodní vlastník potvrzuje funkčnost služby a bezpečnostní tým potvrzuje, že neexistují žádné známky pokračujícího narušení bezpečnosti.

Dostupnost systému ještě neznamená ukončení incidentu.

V rámci obnovy společnost PWN-ALL vyhodnocuje čisté záložní kopie, možnost přestavby systémů, dostupné možnosti dešifrování a obnovy klíčů a následně stanoví priority pro zprovoznění infrastruktury. Výsledek závisí na rodině ransomwaru, stavu systémů, zachovaných důkazech a kvalitě záloh, proto nelze zaručit úplné dešifrování ani obnovení všech dat.

Pokud organizace zvažuje zaplacení výkupného

Profesionální přístup k ransomwaru by neměl vycházet z předpokladu, že zaplacení výkupného je za všech okolností vyloučeno.

Někdy vedení tuto možnost zvažuje kvůli ohrožení života nebo bezpečnosti osob, zastavení kritických procesů, nedostatku použitelných záložních kopií, riziku nevratné ztráty podnikání nebo mimořádně vysokým nákladům spojeným s dlouhodobým výpadkem.

Oficiální doporučení výplatu nepodporují: nezaručuje totiž obnovení přístupu k datům, odstranění škodlivého softwaru ani vymazání odcizených informací. Navíc se organizace, která zaplatila, může stát terčem znovu.

Platba přitom není technickým opatřením, ale výjimečným manažerským rozhodnutím v krizové situaci.

Nejprve je třeba zvážit alternativy

Před přijetím rozhodnutí je třeba posoudit:

  • vhodnost záložních kopií;
  • možnost částečné obnovy;
  • obnovu kritických služeb;
  • dočasné manuální procesy;
  • dostupnost dešifrovacích nástrojů;
  • možnost obnovy dat z jiných zdrojů;
  • přijatelnou dobu trvání nouzového režimu.

Tvrzení útočníka, že výplata je jediným řešením, nelze přijmout bez nezávislé technické prověrky.

Společnost PWN-ALL může posoudit skutečný stav infrastruktury a záložních kopií, prozkoumat možnost dešifrování nebo obnovení klíčů a poskytnout vedení srovnání dostupných scénářů. Konečné rozhodnutí zůstává na oprávněných zástupcích postižené organizace.

Je nutné zjistit skutečné důsledky

Nestačí porovnávat pouze výši výkupného a náklady na obnovu.

Je třeba zohlednit dopad na lidi, délku výpadku, stabilitu dočasných procesů, důsledky pro zákazníky a partnery, pravděpodobnost zveřejnění dat, náklady na bezpečné obnovení a poškození reputace.

Rozhodnutí by mělo vycházet z ověřených faktů, a nikoli pouze ze slibů a časových limitů útočníka.

Právní a sankční omezení se posuzují samostatně

Příjemce, související skupina, zprostředkovatel nebo použitá platební infrastruktura mohou podléhat sankčním či jiným omezením.

Oficiální sankční orgány výslovně varují před riziky pro společnosti, které napomáhají platbám za ransomware. Proto je třeba před jakýmkoli jednáním ověřit platná omezení u kvalifikovaných právních a sankčních poradců.

Společnost PWN-ALL zajišťuje technickou stránku procesu: shromažďuje údaje o infrastruktuře útočníka, ověřuje jeho tvrzení, dokumentuje komunikaci a poskytuje podklady pojistiteli a příslušným poradcům. Právní posouzení a rozhodnutí o transakci zůstávají na organizaci a jejích pověřených poradcích.

Komunikace s útočníkem musí být kontrolovaná

Samostatná korespondence s vyděračem může odhalit kritičnost jednotlivých systémů, vnitřní stav organizace nebo meze jejích možností.

Po příslušné dohodě může společnost PWN-ALL doprovázet kontrolovanou komunikaci a pomoci:

  • ověřit, zda útočník skutečně disponuje uváděnými údaji;
  • požádat o zkušební dešifrování;
  • posoudit funkčnost dešifrovacího nástroje;
  • stanovit technickou proveditelnost požadavků;
  • získat dodatečný čas;
  • uchovat kompletní historii zpráv a rozhodnutí.

Tato podpora nenahrazuje právní prověrku, neznamená doporučení k úhradě a nepřevádí na tým DFIR právo přijímat rozhodnutí jménem zákazníka.

Tvrzení útočníka je nutné ověřit

Před konečným rozhodnutím může být požadováno zkušební dešifrování omezeného souboru souborů, důkaz o přístupu k deklarovaným datům a potvrzení funkčnosti navrhovaného nástroje.

Avšak ani úspěšná kontrola nezaručuje úplné obnovení dat.

Útočník může předat nestabilní dešifrovací nástroj, dešifrovat pouze část dat, uchovat ukradené informace, předat je dalším účastníkům nebo se vrátit prostřednictvím zachovaného přístupu.

Získané nástroje je třeba analyzovat a testovat v izolovaném prostředí.

Jednání nezastavují vyšetřování

Komunikace s útočníkem nenahrazuje reakci.

Souběžně je nutné pokračovat v:

  • lokalizaci hrozby;
  • vyhledávání původního vektoru;
  • ukončení kompromitovaných relací;
  • rotaci přístupových údajů;
  • ochranu záložních kopií;
  • shromažďování důkazů;
  • kontrola cloudového prostředí;
  • vyhledání mechanismů zajištění;
  • příprava bezpečné obnovy.

Po vyplacení výkupného se incident nepovažuje za uzavřený. Systémy je i tak nutné vyčistit nebo přestavět, kompromitované přístupové údaje nahradit a mechanismy pro zajištění bezpečnosti odstranit.

Výplata může změnit jeden prvek krize, ale neodstraňuje kompromitaci a nenahrazuje bezpečné obnovení.

Co se nesmí dělat během aktivního incidentu

Vypínat celou infrastrukturu bez plánu

To může zničit pomíjivé důkazy, zkomplikovat analýzu a zastavit neovlivněné procesy. Izolace musí být bodová nebo segmentová a musí vycházet z posouzení rizika.

Přeinstalovat systémy před sběrem dat

Rychlé formátování odstraní stopy po počátečním přístupu, usazení a pohybu útočníka.

Vyhlašovat vítězství po odstranění malwaru

Škodlivý soubor může být pouze jedním z nástrojů. Je nutné zkontrolovat identity, cloudové relace, tokeny, vzdálený přístup, e-mailová pravidla, SaaS aplikace a správní infrastrukturu.

Nepovažovat změnu hesla za úplné zadržení útočníka

Útočníkovi mohou zůstat aktivní relace, refresh tokeny, oprávnění OAuth nebo alternativní metody MFA.

Využít kompromitované komunikační kanály

Útočník může číst zprávy týmu, přizpůsobovat taktiku a zahlazovat stopy.

Samostatně kontaktovat vyděrače

Nepřipravená komunikace může zhoršit vyjednávací pozici, odhalit kritičnost systémů nebo vytvořit další právní a provozní rizika.

Obnovovat systémy před uzavřením vstupního bodu

V opačném případě se obnovení stane opakovaným incidentem.

Považovat absenci šifrování za absenci úniku

K odcizení dat může docházet prostřednictvím legitimních cloudových služeb a aktivních uživatelských relací, aniž by docházelo k typickým událostem spojeným s ransomwarem.

Důvěřovat záložní kopii bez kontroly

Zálohu je nutné zkontrolovat nejen z hlediska čitelnosti, ale také z hlediska integrity, čistoty a absence uložených mechanismů připevnění.

Zveřejňovat nepotvrzené závěry

Nelze slibovat, že nedošlo k úniku dat, dokud to není potvrzeno vyšetřováním.

Prohlašovat prostředí za čisté kvůli absenci nových výstrah

Absence událostí nemusí znamenat, že útočník neexistuje, ale může být způsobena nedostatečnou viditelností.

Jak měřit připravenost

Počet uzavřených výstrah téměř nic nevypovídá o schopnosti organizace přečkat závažný útok.

Užitečnější ukazatele:

  • čas do potvrzení incidentu;
  • čas do jmenování velitele incidentu;
  • čas do první izolace;
  • doba do ukončení kompromitovaných relací;
  • doba získání cloudových protokolů;
  • doba ověření čisté zálohy;
  • podíl kritických systémů s dostatečnou telemetrií;
  • úplnost časové osy;
  • doba odstranění původního vektoru;
  • podíl opatření provedených po revizi po incidentu.

Je důležité měřit nejen rychlost, ale i kvalitu řešení:

  • kolik akcí bylo provedeno bez určeného odpovědného pracovníka;
  • kolik změn nebylo zaznamenáno do protokolu;
  • jaké důkazy byly ztraceny;
  • kolik systémů bylo nutné obnovit opakovaně;
  • které předpoklady z IR plánu se ukázaly jako nesprávné.

Po incidentu není zapotřebí formální dokument typu „byl proveden pohovor“, ale konkrétní plán změn s určenými odpovědnými osobami, termíny a kritérii kontroly.

Minimální připravenost organizace v roce 2026

Před incidentem musí společnost mít:

  • schválený plán reakce na incidenty (IR);
  • matice rolí a pravomocí;
  • komunikační kanál mimo síť;
  • samostatné příručky pro hlavní scénáře;
  • přehled kritických systémů a závislostí;
  • dostatečná doba uchovávání protokolů;
  • neměnné a ověřitelné záložní kopie;
  • postup uchovávání důkazů;
  • čisté administrativní prostředí;
  • kontakty na externí tým DFIR;
  • šablony interních a externích zpráv;
  • postup pro posuzování požadavků vyděrače;
  • pravidelné simulované a technické cvičení.

Kontrolovat by se neměl pouze technický tým. Na cvičeních by se mělo účastnit vedení, IT, bezpečnostní oddělení, vlastníci obchodních procesů, právní a komunikační oddělení, pojistitel, klíčoví dodavatelé a externí partner DFIR.

Plán, který nebyl ani jednou prověřen v časově omezených podmínkách, je pouhou domněnkou, nikoli prostředkem ochrany.

Reakce znamená zvládání nejistoty

Během útoku se málokdy podaří získat všechny odpovědi hned.

Silný tým nečeká na absolutní jistotu a zároveň nejedná naslepo. Odděluje fakta od hypotéz, přijímá zvratná rozhodnutí tam, kde je to možné, koordinuje destruktivní opatření, uchovává důkazy, vede jednotnou časovou osu a souběžně řídí technická i obchodní rizika.

Incident nelze učinit zcela předvídatelným.

Lze však zajistit předvídatelnost práce týmu.

Kdy je zapotřebí externí zásahový tým

PWN-ALL se zapojuje do incidentů, u nichž je důležitá rychlost, zachování důkazů a kontrolovaná obnova:

  • ransomware a vydírání bez šifrování;
  • krádež a zveřejnění dat;
  • BEC a kompromitace firemní e-mailové komunikace;
  • převzetí účtů;
  • kompromitace Microsoft 365 a Google Workspace;
  • útoky na cloudovou infrastrukturu;
  • napadení webových aplikací a serverů;
  • incidenty způsobené dodavateli a subdodavateli.

Práce může zahrnovat nouzové zadržení, digitální forenziku, určení rozsahu narušení, sběr a uchování důkazů, zkoumání možností dešifrování, kontrolu záložních kopií, technickou podporu řízené komunikace, bezpečné obnovení, přípravu zpráv a následné posílení ochrany. Pro aktivní incidenty má společnost PWN-ALL zavedený samostatný proces reakce fungující 24 hodin denně.

V případě aktivního incidentu:

Nevypínejte postižené systémy, neodstraňujte stopy, neodpovídejte útočníkovi sami a nezačínejte s hromadnou obnovou před provedením prvotního posouzení.

Prvním úkolem je omezit činnost útočníka, aniž by došlo ke zničení informací nezbytných pro vyšetřování, přijímání rozhodnutí a bezpečné obnovení provozu.