Prvé hodiny kybernetického incidentu: čo má mať firma pripravené

Keď sa niečo pokazí, firma potrebuje vedieť tri veci

Kto problém rieši. Kto rozhoduje. A čo treba urobiť ako prvé.

Pri kybernetickom incidente sa tieto otázky objavia veľmi rýchlo. Ak na ne firma hľadá odpoveď až počas problému, stráca čas práve vo chvíli, keď ho má najmenej.

Preto má význam mať pripravený stručný zoznam krokov pre prvé hodiny incidentu. Nemá nahradiť podrobný plán ani technické postupy. Má na jednom mieste ukázať najdôležitejšie kontakty, úlohy a rozhodnutia.

Podobný princíp využívajú aj medzinárodné odporúčania pre zvládanie kybernetických incidentov: dobrá reakcia sa nezačína až vo chvíli útoku. Organizácia musí mať ešte predtým jasno v tom, kto je zodpovedný, koho treba zapojiť a ako bude postupovať.

Načo ďalší dokument, keď už firma má bezpečnostný plán?

Pretože počas incidentu spravidla nechcete čítať desiatky strán dokumentácie.

Potrebujete rýchlo zistiť napríklad:

• kto má prevziať koordináciu,
• kto rieši technickú časť,
• koho treba informovať,
• kto môže rozhodnúť o odstavení systému,
• kde nájsť kontakty na dodávateľov,
• čo treba zachovať,
• čo už bolo vykonané.

Stručný zoznam krokov má byť pracovná pomôcka, nie ďalší dokument vytvorený iba preto, aby existoval.

Jeho hodnota sa ukáže najmä vtedy, keď sú ľudia pod tlakom, informácií je málo a situácia sa mení každých pár minút.

1. Čo sa vlastne stalo?

Na začiatku incidentu firma často nevie presne, čo rieši.

Môže ísť o:

• napadnutý používateľský účet,
• podozrivý e-mail,
• škodlivý program,
• únik údajov,
• výpadok systému,
• kompromitáciu dodávateľa,
• alebo technickú poruchu, ktorá sa až neskôr ukáže ako bezpečnostný problém.

Preto by mal byť prvým krokom jednoduchý záznam:

Kedy sme problém zistili? Kto ho nahlásil? Čo nefunguje alebo sa správa nezvyčajne? Ktorý systém alebo služba je dotknutá?

Veľmi pomáha rozlišovať aj tri veci:

Čo vieme. Čo si zatiaľ iba myslíme. Čo ešte potrebujeme zistiť.

Napríklad:

Vieme, že niekto použil administrátorský účet z neznámeho miesta. Nevieme ešte, či získal prístup aj k ďalším systémom.

Takáto formulácia je užitočnejšia než rýchly záver:

Máme únik dát.

Počas prvých hodín je totiž jednoduché zameniť predpoklad za fakt.

2. Čo je zasiahnuté?

Technický problém s jedným počítačom a incident, ktorý zastaví výrobu alebo zákaznícky systém, sú dve veľmi rozdielne situácie.

Firma preto potrebuje rýchlo pochopiť dopad.

Má zmysel preveriť:

• fungujú kľúčové služby,
• sú dotknutí zákazníci,
• môžu byť ohrozené údaje,
• šíri sa problém ďalej,
• ovplyvňuje incident výrobu alebo poskytovanie služieb,
• závisia od zasiahnutého systému ďalšie časti firmy.

Nemusíte mať hneď presnú odpoveď na všetko.

Dôležité je vedieť, či problém zostáva lokálny alebo už ovplyvňuje fungovanie firmy.

3. Kto to celé riadi?

Technickú časť incidentu môže riešiť IT oddelenie, externý správca alebo bezpečnostný tím.

Niekto však musí držať celý priebeh pokope.

Firma by mala ešte pred incidentom vedieť:

• kto koordinuje riešenie,
• kto zastupuje technický tím,
• kto komunikuje s vedením,
• kto rieši dodávateľov,
• kto posudzuje prípadné oznamovacie povinnosti,
• kto môže prijať zásadné rozhodnutie.

V menšej firme môže jedna osoba zastávať viacero úloh. To nie je problém.

Problém je, keď počas incidentu nikto nevie, kto má posledné slovo a kto komu podáva informácie.

Prečo je pri vážnejšom incidente dôležitý CISO alebo manažér kybernetickej bezpečnosti

Technický tím rieši najmä otázku:

Čo sa stalo v systémoch a ako to zastavíme?

Vedenie potrebuje odpoveď skôr na:

Čo to znamená pre firmu a o čom musíme rozhodnúť?

Práve medzi týmito dvoma pohľadmi je dôležitá úloha CISO, externého CISO alebo manažéra kybernetickej bezpečnosti.

Jeho úlohou nie je opravovať server alebo analyzovať každý technický záznam.

Má pomôcť udržať spoločný obraz o situácii a prepájať:

• technické zistenia,
• dopad na firmu,
• najväčšie riziká,
• dodávateľov,
• zákazníkov,
• vedenie,
• prípadné oznamovacie povinnosti.

Jednoducho povedané:

IT rieši technický problém. Manažér bezpečnosti pomáha firme zvládnuť incident ako celok.

To je dôležité najmä v situáciách, keď technicky najbezpečnejší krok môže mať veľký prevádzkový dopad.

Napríklad IT môže odporučiť okamžité odstavenie systému. Ak však systém riadi výrobu, objednávky alebo kritickú zákaznícku službu, rozhodnutie už nemusí byť iba technickou otázkou.

Manažér bezpečnosti má pomôcť vedeniu pochopiť riziko a možnosti. Konečné obchodné rozhodnutie však zostáva tam, kam patrí – na vedení alebo vlastníkovi danej služby.

Prečo nestačí zavolať odborníka až v deň incidentu

Počas vážnej udalosti je veľkou výhodou, keď človek koordinujúci bezpečnosť už pozná:

• kľúčové systémy firmy,
• najdôležitejšie služby,
• dodávateľov,
• zodpovedných ľudí,
• spôsob zálohovania,
• hlavné bezpečnostné riziká,
• kontakty a rozhodovacie právomoci.

Ak firma zavolá externého odborníka prvýkrát až po útoku, musí sa toto všetko najskôr naučiť.

Časť prvých hodín tak strávi otázkami typu:

Kto vám spravuje tento systém? Ktoré služby sú kritické? Kde máte zálohy? Kto môže rozhodnúť o odstavení?

Práve preto je pravidelné riadenie bezpečnosti dôležité ešte pred incidentom. Aj moderný prístup NIST chápe reakciu na incident ako súčasť celkového riadenia rizík firmy, nie iba ako technickú činnosť vykonávanú po útoku.

4. Čo treba urobiť ako prvé?

Na túto otázku neexistuje jeden univerzálny návod.

Pri jednom incidente môže byť správne okamžite odpojiť zariadenie. Pri inom tým môžete zničiť časť informácií potrebných na pochopenie útoku.

Preto by stručný plán nemal hovoriť:

Vždy vypnite server.

Má skôr pripomenúť, čo treba posúdiť:

• treba zasiahnutý účet zablokovať,
• treba systém oddeliť od siete,
• treba obmedziť prístupy,
• treba zmeniť heslá alebo kľúče,
• môže sa problém šíriť ďalej,
• treba zapojiť externého odborníka,
• treba začať pripravovať obnovu.

Najdôležitejšie je nevykonávať veľké zmeny bez koordinácie.

Počas incidentu totiž môže vzniknúť paradoxná situácia: každý sa snaží pomôcť, ale práve nekoordinované zásahy sťažia ďalšie vyšetrovanie.

5. Nezničte si stopy

Prirodzenou reakciou na napadnutý počítač je:

Vymažeme ho a nainštalujeme nanovo.

Niekedy to bude správny krok. Nemal by však byť automatický.

Pred väčším zásahom treba zvážiť, či firma ešte nebude potrebovať:

• bezpečnostné záznamy,
• históriu prihlásení,
• informácie o procesoch,
• konfiguráciu systému,
• časovú os udalostí,
• ďalšie technické stopy.

Ak sa všetko príliš rýchlo vymaže, neskôr môže byť ťažké zistiť:

• kadiaľ útočník prišiel,
• kam sa dostal,
• čo vykonal,
• či problém stále pretrváva.

NIST preto medzi oblasti úzko súvisiace s reakciou na incidenty zaraďuje aj správu bezpečnostných záznamov a digitálne vyšetrovanie.

Nemusí to znamenať, že každá malá firma má vlastný forenzný tím.

Mala by však vedieť, kedy prestať „opravovať“ a zavolať niekoho, kto vie dôkazy zachovať.

6. Zapisujte, čo sa deje

Počas incidentu sa ľudia spoliehajú na pamäť.

O niekoľko hodín už však nikto presne nevie:

• kto zablokoval účet,
• kedy sa odpojil server,
• kto zavolal dodávateľovi,
• čo bolo v danom čase známe,
• prečo sa prijalo konkrétne rozhodnutie.

Preto má zmysel viesť veľmi jednoduchý záznam:

Čas

Čo sa stalo

Čo sme urobili

Kto

09:10

zistené neznáme prihlásenie

účet zablokovaný

IT

09:25

podozrenie na ďalší systém

začala kontrola záznamov

IT

09:40

možný dopad na zákazníkov

informované vedenie

manažér bezpečnosti

Nemusí ísť o komplikovaný systém.

Dôležité je, aby počas incidentu existovala jedna spoločná časová os.

7. Ktoré rozhodnutia patria vedeniu?

Technický tím by nemal sám niesť zodpovednosť za rozhodnutia, ktoré môžu významne ovplyvniť fungovanie firmy.

Napríklad:

• odstavenie kritického systému,
• zastavenie výroby,
• informovanie zákazníkov,
• aktivácia náhradného spôsobu prevádzky,
• zapojenie externého tímu,
• návrat systému do produkcie napriek zostávajúcemu riziku.

Práve tieto rozhodnutia by mal manažér bezpečnosti vedieť včas dostať pred vedenie.

Nie formou dvadsaťminútového technického vysvetľovania, ale jednoducho:

Máme tieto informácie. Vidíme tieto riziká. Máme tieto možnosti. Toto odporúčame.

Takto má bezpečnosť pomáhať rozhodovať.

8. Koho treba kontaktovať?

Kontakty sa majú hľadať pred incidentom, nie počas neho.

Podľa firmy môžu byť potrebné kontakty na:

• interné IT,
• manažéra bezpečnosti,
• externého správcu,
• poskytovateľa cloudu,
• dodávateľa kritickej aplikácie,
• tím na riešenie kybernetických incidentov,
• právnu podporu,
• človeka zodpovedného za ochranu osobných údajov,
• poisťovňu,
• komunikačný tím.

Pri každom dôležitom kontakte je dobré mať aj náhradníka.

A ideálne nie iba e-mail.

Ak totiž incident zasiahol firemnú poštu alebo používateľské účty, zoznam uložený iba v nich môže byť nepoužiteľný.

Aj odporúčania ISO pre prípravu na incidenty zdôrazňujú, že organizácia má mať vopred vytvorené väzby na potrebné interné aj externé osoby a organizácie.

9. Treba incident niekomu oznámiť?

Nie každý incident treba hlásiť úradu.

Pri niektorých udalostiach však môže vzniknúť povinnosť informovať:

• príslušný orgán alebo tím na riešenie incidentov,
• zákazníka,
• obchodného partnera,
• poisťovňu,
• prípadne ďalšie subjekty podľa charakteru udalosti.

Pre bežného človeka, ktorý incident technicky rieši, nemusí byť jednoduché vedieť, aké povinnosti platia.

Preto by v stručnom zozname mala byť minimálne otázka:

Treba preveriť oznamovaciu povinnosť?

A pri nej meno človeka, ktorý ju má posúdiť.

Pri regulovaných organizáciách treba vychádzať z aktuálnych pravidiel a lehôt NBÚ a príslušného regulačného režimu. Tie sa neoplatí držať iba v pamäti – mali by byť súčasťou pripraveného interného postupu.

10. Kto bude komunikovať?

Počas väčšieho incidentu začnú veľmi rýchlo prichádzať otázky.

Od vedenia.

Od zamestnancov.

Od zákazníkov.

Možno od médií alebo obchodných partnerov.

Najhoršie je, ak každý komunikuje vlastnú verziu udalostí.

Firma by preto mala vopred vedieť:

• kto informuje vedenie,
• kto komunikuje so zákazníkmi,
• kto komunikuje s dodávateľmi,
• kto môže poskytnúť verejné vyjadrenie.

A komunikácia by mala vždy rozlišovať:

čo vieme, čo predpokladáme a čo ešte zisťujeme.

Čo počas prvých hodín radšej nerobiť

Krátky zoznam môže byť niekedy užitočnejší než ďalších desať pokynov.

Počas incidentu sa oplatí vyhnúť najmä tomu, aby firma:

• bez rozmyslu vymazala alebo preinštalovala zasiahnuté zariadenia,
• nechala viacerých ľudí nezávisle meniť konfiguráciu,
• oznamovala neoverené informácie ako fakty,
• obnovila systém bez overenia, či problém skutočne zmizol,
• zabudla zaznamenávať dôležité kroky,
• príliš dlho čakala so zapojením vedenia alebo odborníkov.

Prvé hodiny často nie sú o dokonalom rozhodnutí.

Sú o tom, neurobiť chybu, ktorá výrazne zhorší ďalší priebeh.

Stručný plán musí byť dostupný aj vtedy, keď firma nemá prístup k svojim systémom

Je trochu paradoxné mať plán reakcie na incident uložený iba v systéme, ktorý môže byť počas incidentu nedostupný.

Preto má zmysel mať základnú verziu:

• bezpečne uloženú aj mimo bežného firemného systému,
• dostupnú kľúčovým ľuďom,
• s aktuálnymi telefónnymi kontaktmi.

Nemusí ísť o vytlačenú knihu.

Stačí, aby firma mala realistickú odpoveď na otázku:

Ako sa k tomuto postupu dostaneme, ak nám nefunguje e-mail, firemný disk alebo prihlasovanie?

Ako môže vyzerať jedna strana

Stručný plán pre prvé hodiny incidentu môže obsahovať iba tieto bloky:

Čo sa stalo

• čas zistenia,
• stručný opis,
• dotknutý systém.

Čo vieme

• potvrdené,
• predpokladané,
• neznáme.

Kto to rieši

• koordinátor,
• IT,
• manažér bezpečnosti,
• vedenie,
• potrební dodávatelia.

Čo treba preveriť

• šírenie problému,
• ochrana údajov,
• zachovanie stôp,
• potreba obnovy.

Čo musí niekto rozhodnúť

• odstavenie,
• obnova,
• komunikácia,
• oznámenie incidentu.

Čo sa už stalo

• jednoduchá časová os krokov a rozhodnutí.

To môže byť pre prvú hodinu užitočnejšie než množstvo podrobnej dokumentácie.

A potom ho treba vyskúšať

Najlepší spôsob, ako zistiť, či plán funguje, nie je čítať ho.

Je to vyskúšať si ho.

Firma si môže položiť jednoduchú otázku:

Čo by sme dnes urobili, keby niekto získal administrátorský účet?

A potom prejsť:

• komu zavoláme,
• kto rozhoduje,
• kde sú kontakty,
• čo odstaviť,
• čo zachovať,
• ako budeme komunikovať.

Veľmi rýchlo sa ukáže, že:

• kontakt už neplatí,
• chýba náhradník,
• dvaja ľudia si myslia, že rozhoduje ten druhý,
• nikto nemá číslo na dodávateľa,
• alebo plán existuje, ale ľudia o ňom nevedia.

Aj preto sa pri príprave na incidenty kladie dôraz nielen na samotný dokument, ale aj na ľudí, zodpovednosti a pravidelné precvičenie reakcie.

Checklist nemá byť dokonalý. Má byť použiteľný.

Firma nemusí mať na prvý deň pripravený dvadsaťstranový manuál pre každý možný útok.

Mala by však vedieť:

• kto preberie koordináciu,
• kto rieši technickú stránku,
• kto prepája technický problém s vedením,
• koho treba kontaktovať,
• čo treba zachovať,
• ktoré rozhodnutia nesmie urobiť technický tím sám,
• a kde sa zaznamenáva priebeh incidentu.

Práve tu má CISO, externý CISO alebo manažér kybernetickej bezpečnosti významnú úlohu ešte pred incidentom. Pomáha tieto zodpovednosti, kontakty a rozhodovacie pravidlá nastaviť tak, aby ich firma nemusela vymýšľať pod tlakom.

Stručný plán sám útok nezastaví.

Môže však zabrániť tomu, aby sa k technickému problému pridal ešte jeden:

organizačný chaos.

Zdroje a ďalšie informácie

• NIST – Incident Response Recommendations and Considerations for Cybersecurity Risk Management, SP 800-61 Rev. 3 – aktuálne odporúčania z roku 2025, ktoré prepájajú reakciu na incidenty s celkovým riadením kybernetických rizík organizácie.
• NIST – Incident Response Project – súvisiace materiály k reakcii na incidenty, obnove prevádzky, bezpečnostným záznamom a digitálnemu vyšetrovaniu.
• ISO/IEC 27035-1:2023 – Information security incident management – rámec pre prípravu, odhalenie, nahlasovanie, posúdenie, reakciu a poučenie z bezpečnostných incidentov.
• ISO/IEC 27035-2:2023 – Guidelines to plan and prepare for incident response – odporúčania pre prípravu organizácie vrátane rolí, incidentného tímu, kontaktov, podpory vedenia a školení.
• Národný bezpečnostný úrad SR / Národná jednotka CSIRT – aktuálne slovenské informácie k hláseniu a riešeniu kybernetických incidentov. Konkrétne povinnosti a lehoty treba vždy posúdiť podľa postavenia organizácie a charakteru incidentu.