- Přehledy IS
- APS (21)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (9)
- Cloud computing (SaaS) (29)
- CRM (49)
- DMS/ECM - správa dokumentů (19)
- EAM (16)
- Ekonomické systémy (68)
- ERP (87)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (47)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (40)
- Dodavatelé CRM (36)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (80)
- Informační bezpečnost (42)
- IT řešení pro logistiku (46)
- IT řešení pro stavebnictví (25)
- Řešení pro veřejný a státní sektor (26)
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 | ||
Co nás naučil požár katedrály Notre-Dame o bezpečnosti IT?
Patnáctého dubna 2019 vypukl požár pařížské katedrály Notre-Dame. Unikát světového kulturního dědictví utrpěl rozsáhlé škody a chybělo málo k tomu, aby kompletně lehl popelem. Zatímco si lidé po celém světě kladli otázku, jak k něčemu takovému mohlo dojít, experti požární ochrany se po týdnech intenzivního vyšetřování divili, že k požáru nedošlo již mnohem dříve. V dnešním článku spolu projdeme klíčové momenty celé události a ukážeme si, co si z toho můžeme odnést pro řízení bezpečnosti v IT.
Kritických prvních 31 minut a selhání lidského faktoru
Robustní systém detekce požáru v katedrále budovali 6 let. V osudný den poprvé upozornil na oheň přibližně v 18:20. Trvalo ale dlouhých 31 minut, než někdo zavolal hasiče. Těchto 31 minut umožnilo rozšíření plamenů způsobem, který extrémně zkomplikoval následující pokusy o uhašení požáru. Proč to trvalo tak dlouho? První, kdo si alarmu všiml, byl nový zaměstnanec požární bezpečnosti. Ve své nové práci byl ten den teprve potřetí. Informaci ze systému nedokázal správně interpretovat a poslal ochranku zkontrolovat špatné místo v katedrále.
Protože si nebyl jistý, zda informaci ze systému správně pochopil, ještě raději zavolal svému nadřízenému. Tomu se podařilo sdělení systému dešifrovat. Člen ochranky nyní dostal správné informace o lokaci požáru. Katedrála Notre-Dame je ale obrovský komplex. Aby se dostal na správné místo, musel vystoupat 300 strmých schodů. Když se tam konečně dostal, požár byl již mimo kontrolu. Teprve nyní konečně zavolali hasiče.
Když trošku odstoupíme od specifických okolností požáru, můžeme z těchto událostí extrahovat několik obecných principů. Můžete mít dokonalý systém detekce rizik a dostat včas varování, nicméně pokud nedokážete správně zareagovat, je vám to k ničemu.
Tři věci mohly patnáctého dubna proběhnout lépe: 1) Pracovník zodpovědný za monitorování požáru měl dostat lepší školení a supervizi. Nesvěřujme kritické úkoly lidem bez odpovídajícího zaškolení. 2) Systém měl mluvit srozumitelným jazykem. Odborníci na bezpečnost (požární či IT) mají svůj žargon, ve kterém se bezpečně orientují. Neměli by ale předpokládat, že mu rozumí ostatní lidé. 3) Proces reakce byl špatně navržený. I bez lidské chyby by ověření požáru před zavoláním hasičů příliš protáhlo reakční dobu. Analogicky se můžeme zamyslet nad firemními procesy. Máme správně definované, kdo reaguje na vážné incidenty? Nenecháváte na L1 podpoře věci, kde je riziko příliš vysoké?
Neověřené předpoklady a nedotknutelná architektura
Krov katedrály tvořila propletená struktura dubových trámů. Při návrhu požární ochrany autoři přepokládali, že se oheň mezi starými dubovými chrámy nebude šířit příliš rychle. Tento předpoklad se ukázal jako osudný. Zároveň v průběhu diskuse o instalaci systému vznikl určitý konflikt mezi požární bezpečností a zachováním původní architektury bez zásahů. Nakonec se upustilo od instalace sprinklerů a protipožárních stěn, které památkáři vnímali jako příliš silný zásah.
Odsud si můžeme odnést další dvě ponauční: První se týká neověřených předpokladů. Vždy pracujeme s nějakými předpoklady. Z principu není nikdy možné z lidského jednání odstranit nejistotu, nicméně pokud jde o vysoké riziko, měli bychom si všechny předpoklady sepsat a ohodnotit dle dopadu, který by měla chyba v úsudku. Ty s vysokým dopadem bychom měli důsledně prověřovat.
Druhé ponaučení odvozujeme od konfliktu mezi nároky bezpečnosti a památkáři. I v diskusích o IT bezpečnosti narážíme na konflikty. Nenahrazujte nám prosím tenhle nepodporovaný legacy systém. Neměňte nám tenhle riskantní proces. Nepřidělávejte nám práci s řízením oprávnění. Atd. Nedá se kategoricky říct, že pravda je vždy na straně týmu, který argumentuje za větší bezpečnost. Požár Notre-Damu nám ale může posloužit jako připomínka, že investice do bezpečnosti, která se v dané chvíli jeví jako čistá ztráta, může ve skutečnosti předejít ztrátě mnohem rozsáhlejší.
Krizové řízení a hrdinství hasičů
V článku o požáru katedrály Notre-Dame nesmí chybět zmínka o hlavních hrdinech onoho večera. Hasiči po příjezdu vběhli do budovy, jenže sílící požár je brzy donutil k ústupu. Pokračovali s hašením z vnějšku. V klíčový moment si hasiči všimli, že oheň se blíží k severní věži. Pokud by vzplála dřevěná konstrukce držící zvony severní věže, hrozil kolaps celé věže, což by mohlo spustit dominový efekt a zničit katedrálu.
Aby katedrálu zachránili, přišli s riskantní strategií. Tým hasičů vytáhne 2 hadice do jižní věže, kde budou mít lepší pozici pro boj s ohněm. Problém byl, že pokud se oheň rozšíří, může jim odříznout cestu bez možnosti záchrany. Když místní hasičský tým odmítl risk podstoupit, našel se tým dobrovolníků, kteří se vydali vstříc smrtelnému nebezpečí. Jejich mise naštěstí byla úspěšná. Notre-Dame byl zachráněn díky jejich ochotě riskovat život.
Finále celého požáru nám připomíná dvě věci. Když prevence selže, nezbývá než přepnout do módu krizového řízení a minimalizovat škody. A systémové selhání má reálné důsledky. Pokud problémy odmítneme řešit na systémové rovině, můžeme lidi, kteří se na procesu podílí vystavit extrémní zátěži a riskovat kolaps celého systému.
Jan Škrabánek Autor článku je konzultantem společnosti ALVAO. |
duben - 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 | 1 | 2 | 3 | 4 | 5 |
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13.5. | Konference ISSS 2024 |
15.5. | Digitalizácia procesov vo výrobe a obchode |
15.5. | Kontajnery v praxi 2024 - Bratislava |
22.5. | Cloud Computing Conference 2024 |
Formulář pro přidání akce
16.5. | Virtuální konference "Security as a Service"... |
22.5. | DYTRON EXPERIENCE FORUM 2024 |
13.6. | Konference ABIA CZ 2024: Inovacemi k růstu |