Hodnocení kybernetických rizik produktů: Proč je většina bezpečnostních analýz zdánlivě správná, ale v praxi nepoužitelná?

V naprosté většině technologických firem už proces označovaný jako hodnocení kybernetických rizik existuje. Obvykle má podobu rozsáhlé tabulky, složité matice nebo spreadsheetu, kde dominují hodnoty „low“, „medium“ a „high“. Tento dokument obsahuje dlouhý seznam obecných hrozeb, stručné popisy možných zranitelností a sadu standardních kontrolních opatření. Z formálního hlediska je vše v pořádku: dokument je kompletní, podepsaný vedením a bezpečně archivovaný.

Problém je v tom, že v inženýrské praxi tento dokument nezmění vůbec nic.

Neovlivní architekturu navrhovaného zařízení. Neurčuje rozhodnutí o způsobu dodávání aktualizací. Nemění model poprodejní podpory ani nereviduje vztahy s dodavateli komponent. Jde o dokument správný z pohledu compliance, ale zcela lhostejný k reálnému kybernetickému zabezpečení produktů. Není to však důsledek nedostatku kompetencí v inženýrských nebo security týmech. Jde o problém zásadně chybně zvoleného výchozího bodu.

Většina tradičních analýz rizik začíná otázkou: „Jaké hrozby mohou nastat?“. Nový regulační přístup Evropské unie – jasně patrný v aktech jako Cyber Resilience Act (CRA), ve zdravotnických směrnicích (MDR) nebo v novém strojním nařízení 2023/1230 – však vynucuje úplně jinou perspektivu. Ta začíná otázkou:

Za jakých podmínek používání se může produkt stát nositelem rizika pro uživatele, systém nebo trh – a je výrobce schopen toto riziko řídit po celý jeho životní cyklus?

Jde o zásadní změnu paradigmatu. Hodnocení kybernetických rizik v kontextu produktu není jen další analýza hrozeb pro IT infrastrukturu. Není to ani penetrační test, ani mechanické uplatnění doporučení normy ISO 27001. Je to důkladná analýza schopnosti samotného produktu i jeho výrobce udržet bezpečnost v čase, v reálném provozním prostředí.

Technická zranitelnost vs. riziko produktu – rozlišení v kybernetické bezpečnosti

Aby se hodnocení rizik přestalo omezovat na úřednickou tabulku a stalo se inženýrským rozhodovacím nástrojem, musíme přesně oddělit dva pojmy, které se na trhu často zaměňují. Pamatujme: zranitelnost se nerovná riziku produktu.

• Technická zranitelnost je konkrétní, identifikovatelná chyba v softwaru, hardwarové konfiguraci nebo v samotném návrhu. Může jít o nesprávnou validaci dat, zastaralou programovou knihovnu nebo mezeru v mechanismu autentizace. Takové chyby se evidují v databázích, jako je systém CVE (Common Vulnerabilities and Exposures). Pořád je to ale hodnocení čistě na technické úrovni.
• Riziko produktu se objeví teprve ve chvíli, kdy je uvedená zranitelnost (nebo dokonce její dočasná absence) zasazena do tvrdé reality používání.

Tento kontext zahrnuje řadu proměnných: pracovní prostředí (otevřená nebo izolovaná síť), způsob integrace s dalšími systémy, chování uživatelů, dostupnost bezpečnostních aktualizací (tzv. patch management) a organizační schopnost výrobce reagovat na incidenty.

Produkt nemusí mít v den uvedení na trh žádné známé zranitelnosti, a přesto může vytvářet kritické riziko, pokud jeho výrobce nemá procesy pro dlouhodobou podporu. Pochopení tohoto rozdílu uspořádá celou inženýrskou práci. Právě na tom stojí přístup založený na riziku (risk-based approach). Bezpečnostní opatření musí být úměrná předvídatelným scénářům zneužití, nikoli abstraktnímu seznamu z internetu.

Paradox zabezpečení: Kdy ochrana zvyšuje riziko v IT a OT

Při návrhu kybernetické bezpečnosti se často předpokládá, že přidání dalšího „zámku“ vždy snižuje riziko. Praxe ukazuje, že to může být přesně naopak. Opatření zavedené bez pochopení kontextu vytváří nové vektory hrozeb.

1. Silná autentizace v průmyslovém prostředí (OT)

Představme si zavedení vícefaktorové autentizace (MFA) do průmyslového stroje. Z pohledu IT je to ukázkový krok, jenže kybernetická bezpečnost v průmyslové automatizaci je úplně jiná realita. Ve výrobním prostředí zařízení běží 24/7 a servisní zásahy probíhají pod časovým tlakem. Když selže síť, technik nemůže token online autorizovat. Výroba stojí. Výsledek? Frustrovaný zákazník tento mechanismus natrvalo vypne a zabezpečení úplně obejde. Opatření, které mělo chránit, vytvořilo významné provozní riziko.

2. Automatické aktualizace ve zdravotnických zařízeních (IoMT)

Rychlé záplatování zranitelností minimalizuje vystavení útokům, což je ve světě IT standard. Ve světě zdravotnických prostředků však vynucená aktualizace během probíhajícího zákroku může změnit chování systému nebo narušit komunikaci s nemocniční sítí. V takovém případě technologická ochrana vytváří kritické klinické a regulatorní riziko (porušení certifikace MDR).

3. Uzavírání rozhraní ve spotřební elektronice (IoT)

Výrobce fyzicky odstraní z chytrého domácího zařízení lokální diagnostické porty, aby útočníkům ztížil přístup. V praxi pak autorizované servisy začnou závady diagnostikovat přes nestabilní rozhraní bez šifrování a pokročilí uživatelé ve velkém instalují upravený software (custom firmware). Výsledkem je, že výrobce zcela ztratí kontrolu nad vlastním ekosystémem.

Skutečná analýza kybernetických rizik se ptá: „Jak se po přidání tohoto konkrétního mechanismu změní stabilita, použitelnost a bezpečnost celého ekosystému?“.

5 nejčastějších chyb v analýze rizik technologických produktů

Při hodnocení procesů ve firmách uvádějících na trh elektroniku a software vidí odborníci na kybernetickou bezpečnost opakující se vzorce.

1. Přenášení korporátního IT modelu do světa produktů. Produkt není serverovna. Funguje v neznámém prostředí, často offline, a konfigurují ho laici. Aplikace IT nástrojů na analýzu produktu končí přehlížením klíčových problémů: životního cyklu zařízení a absence vynucených aktualizací.
2. Analýza abstraktních hrozeb místo reálných scénářů. Vyplňování tabulky frázemi typu „neautorizovaný přístup“ je analyticky k ničemu. Analýza musí stát na konkrétnostech: Kdo? Přes jaké rozhraní? Za jakým účelem? S jakým dopadem?
3. Ignorování životního cyklu produktu (End-of-Life). Analýza rizik se obvykle vztahuje k okamžiku uvedení na trh. Jenže riziko s časem roste – open-source knihovny stárnou a dodavatelé komponent ukončují podporu. Bez zohlednění modelu údržby je analýza zavádějící.
4. Izolace od vývojového týmu (R&D). Brát posouzení rizik jako checklist před auditem je přímá cesta ke katastrofě. Výstupy se musí vracet k inženýrům jako závazné architektonické požadavky (Secure by Design).
5. Fetišizace technologií na úkor procesů. Firmy investují jmění do pokročilé kryptografie, ale nevědí, kdo ve firmě odpovídá za vydání bezpečnostní opravy (patch) po nahlášení zranitelnosti výzkumníkem (Vulnerability Disclosure Program).

Jak provést analýzu v souladu s Cyber Resilience Act? 7 inženýrských kroků

Posuzování kybernetických rizik musí přestat být byrokratickou zátěží. Níže je uveden tržně použitelný provozní model v souladu s unijním přístupem (mj. požadavky CRA).

1. Vymez hranice produktu. Produkt není jen hardware. Patří sem také mobilní aplikace, cloud, OTA servery a rozhraní API.
2. Popiš nekompromisní realitu prostředí použití. Nepopisuj laboratorní prostředí. Odpověz na otázky týkající se skutečné internetové konektivity, kompetencí uživatelů a možností fyzického přístupu k zařízení.
3. Identifikuj scénáře zneužití (Threat Modeling). Odhoď generické seznamy. Využij ověřené inženýrské metody a nástroje pro odhad rizik, abys se soustředil na přesné vektory útoků přizpůsobené tvému odvětví.
4. Kvantifikuj nefinanční důsledky. Zhodnoť riziko odstávky výroby, ohrožení zdraví nebo porušení regulatorních povinností.
5. Polož otázku kontroly. Dokážeš jako výrobce předcházet, detekovat a rychle reagovat na identifikovaný scénář zneužití?
6. Navrhni přiměřené ochranné mechanismy. Rozhodnutí o šifrování nebo segmentaci sítě musí přímo vycházet z odpovědí z předchozích kroků.
7. Navrhni proces údržby (Lifecycle). Zdokumentuj politiku dodávání bezpečnostních záplat, dobu podpory a komunikační kanály se zákazníkem.

Shrnutí: Co má zůstat po poctivém posouzení rizik?

Vyvrcholením správného posouzení kybernetických rizik produktu by nikdy neměl být textově hutný poem pro auditora. Z této práce musí vzejít hmatatelné artefakty: jasná mapa hranic systému, závazná architektonická rozhodnutí v R&D, schválený rozpočet na politiku aktualizací a konzistentní auditní stopa prokazující soulad s unijními směrnicemi.

Technologicky vyspělá organizace už se neptá: „Jsme na 100 % v bezpečí?“. Místo toho se ptá: „Kde přesně jsme zranitelní a umíme to v čase řídit?“.

Je váš produkt připraven na nové regulace?

Bezpečnost je proces, ne jednorázový certifikát. Pokud nechceš, aby hodnocení rizik ve tvé firmě bylo jen „papírování“, vyplatí se jednat proaktivně. Podívej se, jak produkt skutečně připravit na Cyber Resilience Act (CRA) v letech 2026-2027, ještě než se objeví oficiální harmonizované normy.