Incident response (reakcia na bezpečnostné incidenty) zahŕňa pripravené role, postupy a nástroje, vďaka ktorým organizácia pri kybernetickom útoku alebo úniku dát nekoná chaoticky. Cieľom je čo najrýchlejšie obmedziť škody, odstrániť príčinu, bezpečne obnoviť systémy a zabezpečiť dôkazy aj povinné hlásenia.

Podobá sa to požiarnemu poplachovému plánu: keď začne horieť, nie je čas vymýšľať, kto volá hasičov a kadiaľ vedie úniková cesta. Všetko musí byť dohodnuté a nacvičené vopred.

Fázy reakcie na incident

Najčastejšie sa vychádza z rámcov NIST alebo SANS, ktoré sa líšia skôr pomenovaním než obsahom:

  1. Príprava – plán, kontakty, oprávnenia, nástroje, zálohy a pravidelné cvičenia.
  2. Detekcia a analýza – rozpoznanie, že ide o skutočný bezpečnostný incident, určenie rozsahu a závažnosti; pomáhajú pri tom SIEM a monitoring.
  3. Obmedzenie (containment) – izolácia napadnutých zariadení, zablokovanie kompromitovaných účtov, oddelenie častí siete.
  4. Odstránenie a obnova – odstránenie škodlivého kódu, zatvorenie zneužitej slabiny, obnova z overených záloh a kontrolovaný návrat do prevádzky.
  5. Poučenie – vyhodnotenie, čo zlyhalo, a úprava opatrení, aby sa podobná situácia neopakovala.

Prečo na tom záleží

Pri útoku typu ransomware rozhodujú hodiny. Organizácia, ktorá má vopred určené, kto smie odpojiť systémy od siete, kto komunikuje s vedením a médiami a kde sú offline zálohy, spravidla zvládne situáciu s menšími škodami než tá, ktorá všetko rieši až počas krízy. Reakcia na incident preto úzko nadväzuje na plán kontinuity prevádzky a na ciele obnovy RPO a RTO.

Dôležitá je aj regulácia. Akt o kybernetickej odolnosti (CRA) ukladá výrobcom produktov s digitálnymi prvkami od 11. septembra 2026 povinnosť hlásiť aktívne zneužívané zraniteľnosti a vážne incidenty národnému CSIRT-u a agentúre ENISA – prvé varovanie do 24 hodín a podrobnejšie hlásenie do 72 hodín. Viac v článku o tom, ako Cyber Resilience Act mení vývoj softvéru. Povinnosti podľa NIS2 a zákona č. 69/2018 Z. z. závisia od postavenia organizácie, preto si ich overte s odborníkom.

Časté chyby

  • Plán existuje len na papieri a nikto ho nenacvičil.
  • Kontakty a postupy sú uložené iba v systémoch, ktoré útok vyradil z prevádzky.
  • Napadnuté stroje sa hneď preinštalujú, čím sa zničia dôkazy potrebné na zistenie príčiny.
  • Chýba evidencia – nie je jasné, kto čo kedy urobil. Pomáha jednotné vedenie záznamov v nástroji na manažment služieb, napríklad v moduloch incident a problem v Servio.

Časté otázky

Je incident response to isté ako riešenie porúch na helpdesku?

Nie celkom. Incident management podľa ITIL rieši akékoľvek výpadky a poruchy služieb, kým incident response sa zameriava na bezpečnostné udalosti, dôkazy, hlásenia a odstránenie útočníka. Oba procesy by však mali byť prepojené.

Ako často treba plán testovať?

Odporúča sa aspoň raz ročne a po každej významnej zmene infraštruktúry, napríklad formou stolového cvičenia (tabletop) s IT, vedením aj zodpovednými za komunikáciu.

Reakcia je rýchlejšia, keď sú systémy dopredu spevnené a slabiny pod kontrolou. Prečítajte si, ako systematicky posilňujeme kybernetickú odolnosť organizácií, a dohodnite si úvodné posúdenie.