- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (77)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
7 nejčastějích chyb při tvorbě plánu reakce na incidenty
Evropská kyberbezpečnostní směrnice NIS2, která plně vstoupí v platnost ji v přítím roce, se dotkne mnoha tisíc českých podniků. Firmy se musí připravit na řadu nových povinností. Kromě přímých investic do technologií je neminou procesní záleitosti, jako například povinné hláení incidentů, analýza rizik, vytvoření bezpečnostních týmů či definice bezpečnostní politiky. I v kyberbezpečnosti přitom plně funguje otřepané rčení těko na cvičiti, lehko na bojiti.

Perfektně zpracovaný Incident Response Plan (IRP) představuje klíčový dokument, který můe při skutečném hackerském útoku zachránit miliony. Vystříhejte se proto 7 nejčastějích chyb, které firmy při sestavování IRP dělají:
1. Podcenění hierarchie dokumentů
Dbejte na jasnou hierarchii dokumentů, abyste se vyhnuli nadbytečnosti a zmatku mezi dokumenty kybernetické bezpečnosti. Častou chybou je, e na IRP se pohlíí jako na izolovaný dokument bez ohledu na ostatní materiály ke kybernetické bezpečnosti, které firma má. Jedině dokument přiměřené délky a hloubky detailu má anci na to, e jej bude někdo číst a řídit se jím. Vyhněte se duplicitám a skutečné podrobnosti svěřte jiným dokumentům.

2. Příliná obecnost
Dobrý IRP by měl odpovědět na základní otázky: Kdo, co, kdy a jak? v případě kybernetického bezpečnostního incidentu:
- Kdo. Kteří pracovníci jsou součástí procesu IR, jaké dovednosti nebo schopnosti jsou u nich vyadovány?
- Co. Jaké činnosti se provádějí v jednotlivých fázích procesu reakce na incident? Plán by měl určit postup, jak přesně identifikovat povahu incidentu, dostupné zdroje dat organizace a moné příručky, podle kterých se bude postupovat, jakmile povaha incidentu definována.
- Kdy. Je třeba předem stanovit pořadí činností, které se mají provést, kdykoli k incidentu dojde. A musí být jasné, kdo za jakou činnost odpovídá.
- Jak. IRP by měl obsahovat přehled nástrojů, které má tým k dispozici pro technickou reakci a komunikaci v případě incidentu.
3. Příliná konkrétnost
IRP se má týkat skutečně postupů při řeení incidentů, není to uivatelská příručka s podrobným návodem, jaký stisknout kde knoflík. Do podrobností naopak musí jít návody věnované konkrétním typům incidentů.
4. Izolovaná příprava
Tvorba IRP není jen záleitostí ajáků. Do přípravy zapojte dalí pracovníky s různými úhly pohledu. Spolupracujte s techniky, právníky, komunikačními experty, personalisty a dalími, abyste zajistili komplexní pohled na incident.
5. Neotestovaný plán
Plán je tak dobrý, jak dobré je jeho pouití během skutečného incidentu. Nejlepím způsobem, jak identifikovat případné mezery, je vyzkouet jej v praxi. Pravidelně testujte procesy, nástroje a reakce týmů, abyste zjistili nedostatky, které je třeba odstranit.
6. Neaktuální plán
Obnovujte a aktualizujte svůj IRP alespoň jednou ročně a vdy po významných softwarových, hardwarových nebo organizačních změnách. Prověřte jej po závaných incidentech, abyste zajistili jeho trvalou účinnost.
7. Příliné zaměření na IT
Pokud se budete příli soustředit na technické aspekty řeení incidentu, riskujete, e vytvoříte neúplný dokument. Podpůrné týmy by měly být součástí procesu vývoje i testování. Spolupráce napříč firmou zajistí komplexní přístup k reakci na incidenty.
Tvorba dobrého IRP představuje jen jedno z úskalí NIS2. Poadavky se počítají v desítkách a řada z nich skutečně není triviálních. Vyhněte se riziku vysokých pokut a konzultujte svůj postup s odborníky. Obrátit se můete například na alianci NIS2READY, která sdruuje technologické, poradenské i právní firmy a pomáhá podnikům s přípravou na NIS2.
Autor je kyberbezpečnostní expert společnosti Cisco.





















