- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (87)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (40)
- Dodavatelé CRM (37)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (63)
- Informační bezpečnost (43)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)
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 údržby
Úč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 zpravodaje SystemNEWS na LinkedIn, který každý 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áležitosti, 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čišti, lehko na bojišti“.
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řílišná 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 vyžadová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 možné 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řílišná konkrétnost
IRP se má týkat skutečně postupů při řešení incidentů, není to uživatelská 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áležitostí „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 použití během skutečného incidentu. Nejlepším způsobem, jak identifikovat případné mezery, je vyzkoušet 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 vždy po významných softwarových, hardwarových nebo organizačních změnách. Prověřte jej po závažných incidentech, abyste zajistili jeho trvalou účinnost.
7. Přílišné zaměření na IT
Pokud se budete příliš soustředit na technické aspekty řešení 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. Požadavky 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á sdružuje technologické, poradenské i právní firmy a pomáhá podnikům s přípravou na NIS2.
Autor je kyberbezpečnostní expert společnosti Cisco.
prosinec - 2024 | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | 1 | 2 | 3 | 4 | 5 |
23.1. | Odborný webinář Zabezpečení digitální identity zaměstnanců... |
24.1. | CyberEdu NIS2 Academy - druhý běh |
31.3. | HANNOVER MESSE 2025 |
Formulář pro přidání akce
9.4. | Digital Trust |