Ing. Lenka Gondová CISA, CGEIT, CRISC, CDPSE – je rešpektovanou autoritou v oblasti informačných technológií, umelej inteligencie a kybernetickej bezpečnosti s viac ako dvadsaťročnou praxou v strategickom poradenstve a audite pre významné spoločnosti z rôznych odvetví priemyslu a služieb. Študovala medzinárodný obchod na Ekonomickej univerzite v Bratislave a svoje odborné vedomosti si rozšírila štátnicou zo strategického poradenstva na prestížnej Wirtschaftsuniversität Wien. Počas svojej kariéry sa špecializovala na poradenstvo v oblasti riadenia zmeny, predovšetkým v implementácii informačných technológií a systémov manažérstva podľa noriem ISO. Je prezidentkou ISACA Slovensko a predsedníčkou technickej komisie 37 pre informačné technológie, ktorá predstavuje zastúpenie slovenskej odbornej obce v rámci participácii na príprave, pripomienkovaní, preberaní a prekladoch medzinárodných štandardov v oblasti informačných technológií, vrátane kybernetickej bezpečnosti a umelej inteligencie. Konzultácie v oblasti ISO štandardov ju priviedli k výkonu činnosti auditu. Od roku 2000 vykonala vyše 400 auditov v 100+ spoločnostiach, pričom sa zameriavala na oblasti kybernetickej bezpečnosti, informačných systémov a ochrany dát. Jej skúsenosti viedli k aktívnej účasti na príprave legislatívnych zmien, vrátane implementácie auditov podľa eIDAS, certifikácie audítorov kybernetickej bezpečnosti, ako aj zavedenia európskych smerníc NIS a NIS II, CSA a EUCC.
Jaké technické požadavky klade Cyber Resilience Act na výrobce digitálních produktů a služeb? V čem se tyto požadavky zásadně liší od dosavadních regulací, jako jsou NIS2 nebo GDPR?
Cyber Resilience Act (CRA) prináša zásadnú zmenu tým, že posúva požiadavky na kybernetickú bezpečnosť priamo do fázy návrhu, vývoja a uvádzania produktov na trh. Výrobcovia budú musieť preukázať, že ich produkty – od softvérových aplikácií až po zariadenia IoT – spĺňajú základné požiadavky na bezpečnosť ako je zvládanie zraniteľností, bezpečná konfigurácia, overovanie integrity, či ochrana pred neautorizovaným prístupom.
Zásadný rozdiel oproti NIS2 alebo GDPR je v tom, že CRA je produktová regulácia s dopadom na vývojový cyklus a architektúru. NIS2 rieši najmä organizačné opatrenia a riadenie rizík na úrovni prevádzkovateľa služieb. GDPR sa zameriava na ochranu osobných údajov, nie na kybernetickú odolnosť produktov ako takých.
CRA prináša doplnenie CE označenia aj o aspekt kybernetickej bezpečnosti. Tiež je potrebné podotknúť, že požiadavky sa kladú aj na distribútorov a dovozcov produktov, ktorí musia zabezpečiť, že výrobca mimo EÚ zabezpečil primerané bezpečnostné opatrenia produktu.
V praxi to znamená, že aj firmy, ktoré digitálny produkt len dovážajú alebo predávajú, sa musia zaujímať o jeho bezpečnosť. Zodpovednosť je rozdelená medzi celý dodávateľský reťazec.
Významnou zmenou je tiež to, že sankcie za nedodržanie požiadaviek CRA sa netýkajú len pokút ale aj povinnosti stiahnuť produkt z trhu.
Které typy organizací budou technicky nejvíce zatíženy implementací CRA? Dotkne se CRA i malých vývojářských firem, nebo primárně větších dodavatelů a výrobců embedded systémů?
Najviac dotknuté budú organizácie, ktoré vyvíjajú a uvádzajú na trh hardvérové a softvérové produkty určené pre pripojenie do internetu – tzv. „proukty s digitálnymi prvkami“. Výrazne sa to dotkne najmä firiem vyrábajúcich embedded systémy, zariadenia IoT, sieťové komponenty, ale aj softvérových produktov ako sú aplikácie, operačné systémy alebo bezpečnostné nástroje bez ohľadu na veľkosť, dôležitá je klasifikácia produktov.
Aj malé firmy, vrátane startupov, budú teda CRA podliehať, ak uvádzajú produkty na trh EÚ. Veľkosť firmy nie je rozhodujúca – dôležité je, či vystupuje ako výrobca resp. distribútor alebo dovozca v zmysle CRA.
To znamená, že aj menšia vývojárska firma, ak vyvíja napríklad softvér pre inteligentné senzory, bude musieť preukázať súlad s technickými požiadavkami, a to vrátane správy zraniteľností, aktualizácií a bezpečnej dokumentácie. CRA avšak zavádza viaceré úľavy a formy podpory pre MSP (malé a stredné podniky) ako sú sandboxy, zjednodušená technická dokumentácia avšak tieto neznamenajú výnimku zo základných požiadaviek CRA.
Jak CRA technicky ovlivní zabezpečení v rámci dodavatelského řetězce? Jaká opatření budou muset firmy zavést vůči svým subdodavatelům a třetím stranám?
Výrobcovia budú musieť preukázať, že komponenty, ktoré integrujú od tretích strán, sú bezpečné a že poznajú pôvod a stav ich zabezpečenia.
Z technického hľadiska to znamená zavedenie systémov na evidenciu softvérových komponentov (napr. SBOM – Software Bill of Materials), kontrolu aktualizácií, sledovanie zraniteľností a procesy na overenie integrity kódu. Špecifickou novinkou CRA je, že vyžaduje, aby hospodárske subjekty v reťazci (výrobcovia, dovozcovia, distribútori) viedli evidenciu o tom, komu produkt dodali a od koho ho nadobudli. Ide o tzv. princíp spätnej vysledovateľnosti (traceability), ktorý má umožniť rýchlu reakciu v prípade výskytu zraniteľnosti alebo incidentu.
Každý hospodársky subjekt je povinný:
- uchovávať informácie o priamom predchodcovi a následníkovi v reťazci (napr. kto dodal produkt, komu bol dodaný),
- poskytnúť tieto údaje príslušnému dozornému orgánu na požiadanie,
- zabezpečiť, aby tieto informácie boli dostupné počas najmenej 10 rokov od uvedenia produktu na trh.
Táto evidencia umožňuje v prípade potreby rýchlo identifikovať všetkých partnerov, ktorí môžu byť ovplyvnení zraniteľnosťou alebo incidentom, a efektívne koordinovať stiahnutie produktov, opravy alebo varovania.
Jaká je podle Vás technická připravenost firem v Česku a na Slovensku na plnění požadavků CRA? Vnímáte rozdíly v přístupu mezi těmito dvěma prostředími?
Firmy v oboch krajinách sú zatiaľ prevažne v štádiu oboznamovania sa s CRA. Veľké nadnárodné firmy alebo pobočky medzinárodných výrobcov už majú prvé analýzy a pripravujú interné stratégie. U menších hráčov vnímame istý odstup – podobne ako to bolo kedysi pri GDPR. Mnohé firmy stále podceňujú rozsah zmien, ktoré CRA prinesie. Nepomáha ani to, že na niektoré kľúčové aspekty implementácie – ako napríklad presné technické normy, formát posudzovania zhody alebo špecifikácia požiadaviek pre rôzne kategórie produktov – zatiaľ nie sú vydané. To v praxi znamená, že firmy síce tušia, čo bude CRA vyžadovať, ale nemajú dostatok konkrétnych podkladov, podľa ktorých by mohli bezpečne investovať čas a peniaze. Tento stav podporuje skôr váhanie než prípravu, pričom čas na implementáciu definovaný platnosťou CRA je limitovaný a podľa môjho názoru absolútne nedostatočný vzhľadom na závažnosť a komplexitu požiadaviek.
V jakých oblastech IT infrastruktury a vývoje jsou české a slovenské firmy nejzranitelnější z pohledu CRA? Kde je potřeba začít s úpravami nejdříve?
CRA prináša množstvo výziev. Prvou výzvou je nejasnosť, či sa daný produkt vôbec dostane pod pôsobnosť CRA. Rozhodovanie, či ide o „produkt s digitálnymi prvkami“ podľa definícií nariadenia, vyžaduje analýzu architektúry, spôsobu distribúcie aj aktualizácie. Mnohé firmy si nie sú isté, či sa ich softvérové riešenie klasifikuje ako samostatný produkt, alebo len ako súčasť iného systému – a práve táto nejednoznačnosť brzdí prípravu.
Cieľom CRA je zvýšiť kybernetickú odolnosť produktov na trhu EÚ. Veľkou výzvou pri adresovaní požiadaviek CRA je absencia formalizovaných vývojových procesov so zameraním na bezpečnosť. Veľa firiem síce používa DevOps, ale nemá integrované DevSecOps praktiky – napr. automatické testovanie zraniteľností, bezpečnostné revízie kódu, overovanie knižníc.
Ďalším slabým miestom je nedostatočná evidencia použitého softvéru a komponentov – bez SBOM nie je možné CRA splniť. Problémom býva aj chýbajúci systém pre správu bezpečnostných aktualizácií po uvedení produktu na trh. Práve tieto oblasti sú základom a je potrebné ich riešiť ako prvé.
Zaujímavým aspektom sú aj povinnosti v súvislosti s používaním open source. Jednou z najväčších slabín firiem z pohľadu CRA je používanie externých komponentov bez toho, aby mali prehľad o ich pôvode, zraniteľnostiach či licenčných podmienkach. Týka sa to najmä open source knižníc, ktoré sú síce dostupné zadarmo, ale pri ich integrácii do komerčného produktu výrobca nesie za ich bezpečnosť plnú zodpovednosť z pohľadu požiadaviek CRA.
Jak CRA mění roli bezpečnostního auditu z technického hlediska? Budou auditoři muset reálně hodnotit i vývojová prostředí, CI/CD procesy nebo konfiguraci zařízení?
Nielen to. Hodnotenie vývojového prostredia, CI/CD procesov alebo konfigurácie poznáme už dnes pri existujúcich auditných rámcoch (napr. ISO 27001 kapitola o bezpečnom vývoji). Audit v súvislosti s požiadavkami CRA dostáva úplne novú úroveň komplexity.
Ak to porovnávame s auditmi napr. podľa ISO 27001, zásadnou zmenou je hodnotenie bezpečnosti produktu a teda nie systému (manažérstva firmy, relevantné napr. pri NIS2). To prináša výzvu v oblasti definovania štandardov, voči ktorým sa audituje nakoľko spektrum a rôznorodosť produktov s digitálnymi prvkami je obrovská. Určite je iné auditovať SW na kontrolu prístupu alebo hardvérový bezpečnostný modul a teda aj štandardy s požiadavkami na ne (stále sa len pripravujú) sa budú líšiť. To znamená aj náročnosť auditu pre audítorov a požiadavky na notifikované osoby z pohľadu znalosti produktu. Moduly auditov podľa CRA sa tiež líšia podľa klasifikácie produktov a majú rôzny rozsah (čo vychádza z Blue book). Najkomplexnejšou formou auditu pre kontext CRA je certifikácia podľa schémy EUCC. Tento prísny auditný rámec je zároveň ale aj veľmi smerodajným dôkazom o bezpečnosti produktov, čo je nepochybne dôležité pre produkty, ktoré môžu predstavovať vysoké riziko v prípade zlyhania ich bezpečnosti.
Je z technického hlediska možné naplnit požadavky CRA při agilním vývoji softwaru? Jak integrovat požadavky CRA do DevSecOps praxe?
Typ metódy vývoja nie je na prekážku alebo determinantom bezpečnosti výsledného produktu. Agilný vývoj a CRA sa nevylučujú – naopak, práve DevSecOps je jedným z najefektívnejších prístupov, ako naplniť technické požiadavky CRA. Kľúčové je, aby bezpečnosť nebola až na konci vývoja, ale zakomponovaná už pri návrhu riešenia a ideálne s podporou automatizovaných nástrojov.
Napr. pri každom šprinte implementované minimálne automatické testovanie zraniteľností, statická aj dynamická analýzu kódu, kontrola licencovania a revízie architektúry.
Jak to bude s prototypováním a uváděním nových produktů? Nezpůsobí to útlum v inovacích?
CRA neobmedzuje vytváranie prototypov. Ak ide o interné testovanie alebo vývojový prototyp, ktorý nie je sprístupnený zákazníkom, na takýto produkt sa povinnosti podľa CRA ešte nevzťahujú.
Súlad s CRA je potrebný až v momente, keď výrobca sprístupní produkt koncovým používateľom – či už formou predaja, nájmu alebo iného komerčného uvedenia na trh. Vtedy už aj produkt, ktorý bol pôvodne prototypom, musí spĺňať všetky technické a procesné požiadavky vrátane bezpečnostného návrhu, dokumentácie a aktualizačných mechanizmov.
Firmy teda budú môcť naďalej rýchlo inovovať a overovať si nové riešenia, ale v momente ich sprístupnenia zákazníkom musia preukázať, že produkt je bezpečný. Tým sa netlmí samotná inovácia, ale vytvára sa rámec, ktorý zabezpečí, že inovácie nebudú zároveň zdrojom zraniteľností.
Auditovat se bude muset jen relativně malý počet subjektů. Jak tedy CRA reálně ovlivní běžné firmy?
Nie je správne sa domnievať, že Cyber Resilience Act sa dotkne len malej skupiny firiem, ktoré budú povinne auditované treťou stranou. V skutočnosti sa požiadavky CRA vzťahujú na všetkých výrobcov produktov s digitálnymi prvkami, ktorí ich uvádzajú na trh EÚ – bez ohľadu na to, či podliehajú auditu tzv. notifikovanou osobou.
Každý výrobca totiž musí vykonať posúdenie zhody – buď sám, interne, alebo prostredníctvom externej, notifikovanej osoby, ak to vyžaduje rizikovosť produktu. Aj samohodnotenie je však formálny proces, pri ktorom sa výrobca zaväzuje, že jeho produkt spĺňa všetky príslušné požiadavky CRA. Na tomto základe môže udeliť svojmu produktu označenie CE – a nesie za to plnú zodpovednosť.
Navyše, viaceré povinnosti nariadenia sú platné bez ohľadu na to, či sa audit treťou stranou vykonáva alebo nie. Ide napríklad o povinnosť vypracovať technickú dokumentáciu, poskytnúť informácie používateľom o bezpečnom používaní produktu, zabezpečiť postupy pre hlásenie zraniteľností a incidentov, či spolupracovať s orgánmi dohľadu pri kontrolách.
Regulátor teda môže zakročiť aj voči firmám, ktoré sa nedomnievajú, že im audit hrozí – a vyžiadať si dôkaz, že produkt bol riadne posúdený, je bezpečný a že výrobca splnil všetky svoje povinnosti. CRA je univerzálny rámec – rozdiely sú vo formáte procesu posúdenia zhody podľa rizikovosti produktu prípadne v štandardoch voči ktorým sa hodnotí (v súvislosti s typom produktu), nie v rozsahu zodpovednosti.
Mohou firmy snížit byrokratickou zátěž tím, že ze svého produktu udělají open source?
Open source ako model distribúcie môže niektorým firmám poskytnúť výnimku z CRA, ale len za veľmi špecifických podmienok – napríklad ak je softvér vyvíjaný plne komunitne, bez obchodného účelu, a nie je súčasťou komerčného produktu.
Vo väčšine prípadov však open source nebude automaticky oslobodený. Ak firma napríklad poskytuje komerčnú podporu k open source riešeniu, alebo ho distribuuje ako súčasť hardvéru, CRA sa na ňu bude stále vzťahovať. Preto je potrebné tento krok zvážiť veľmi obozretne.
Které konkrétní požadavky CRA podle Vás v praxi způsobí firmám největší problémy? Jsou to procesní otázky, technická opatření, nebo dokumentace a auditní stopa?
Najviac náročná bude kombinácia všetkých aspektov – najmä ak firma nie je zvyknutá pracovať v regulovanom prostredí, nemá vybudovaný systematický proces manažérstva kybernetickej resp. informačnej bezpečnosti (napr. ISO 27001). Nie že by plnenie povinností ISO 27001 automaticky znamenalo, že firma je v súlade s CRA ale ak pristupuje k certifikačným požiadavkám systémovo a zodpovedne, má vybudované procesy, do ktorých je jednoduchšie implementovať požiadavky CRA. Z mojej skúsenosti s auditmi (podľa štandardov ISACA alebo ISO 27001 resp. ISO 42001) majú SW firmy spravidla problém so spracovaním kvalitnej dokumentácie. Procesne bude problematické zaviesť riadenie zraniteľností počas celého životného cyklu produktu. Technicky je výzvou zabezpečiť možnosť bezpečnej aktualizácie a overenie integrity každého komponentu vrátane používania open source knižníc. V konečnom dôsledku je CRA najmä o profesionalizácii vývoja.
Děkuji za rozhovor.
Za DSM se ptal Martin Haloda.
