Art. 21(2)(e) NIS 2 + CIR §6

Bezpečný vývoj a pořizování podle NIS 2 v čl. 21 odst. 2 písm. e)

NIS 2 říká, že musíte zabezpečit systémy napříč pořizováním, vývojem a údržbou. Článek 21 odst. 2 písm. e) je zastřešující ustanovení. §6 CIR (EU) 2024/2690 jej rozděluje na deset pododdílů. Německo to zavádí do vnitrostátního práva prostřednictvím §30 odst. 2 bodu 5 BSIG.

Simon OrzelSimon Orzel·

Stručná verze

Článek 21 odst. 2 písm. e) je zastřešující povinnost pro bezpečnost napříč celým životním cyklem IT. Nejen kód. Nejen opravy. Celá cesta: nákup systému, jeho vývoj, konfigurace, změny, testování, opravy, provoz, vyřazení z provozu. Stejné pravidlo platí v celé EU.

CIR (EU) 2024/2690 doplňuje podrobnosti. §6 přílohy má deset pododdílů (§6.1 až §6.10), které povinnost zprovozňují. Tato stránka pokrývá stranu vývoje a změn: pořizování (§6.1), bezpečný životní cyklus vývoje (§6.2), řízení konfigurace (§6.3), řízení změn (§6.4), bezpečnostní testování (§6.5) a správa oprav (§6.6). Síťová bezpečnost, segmentace, antimalware a řízení zranitelností (§6.7 až §6.10) mají vlastní stránky.

Německo zavádí stejné pravidlo do vnitrostátního práva prostřednictvím §30 odst. 2 bodu 5 BSIG. Znění je téměř doslova text EU. Tato stránka prochází směrnici, navazující nařízení EU a německou transpozici v tomto pořadí.

Právní zdroj
Tři vrstvy poskládané na sebe. Směrnice (závazná pro každou zemi EU). Prováděcí nařízení (přímo použitelné právo EU pro sektory uvedené v příloze). Vnitrostátní transpozice (v Německu: BSIG).

Článek 21 odst. 2 písm. e) směrnice NIS 2 (2022/2555)

Bezpečnost při pořizování, vývoji a údržbě sítí a informačních systémů, včetně zveřejňování a řešení zranitelností.

Toto je bod e) na seznamu deseti opatření kybernetické bezpečnosti, která musí zavést každý základní a důležitý subjekt. Je to jediný bod na seznamu, který se výslovně táhne od objednávky po konec životnosti.

CIR (EU) 2024/2690, příloha §6

Bezpečnostní opatření při pořizování, vývoji a údržbě sítí a informačních systémů (čl. 21 odst. 2 písm. e) směrnice (EU) 2022/2555).

Protože jde o nařízení (nikoli směrnici), je to přímo závazné právo EU. Žádná vnitrostátní transpozice není potřeba. Vztahuje se na poskytovatele DNS, registry TLD, poskytovatele cloudu, datová centra, poskytovatele řízených služeb a další sektory uvedené v jeho příloze. §6 má deset číslovaných pododdílů, z nichž každý jmenuje konkrétní povinnost.

§30 odst. 2 bod 5 BSIG (Německo)

Bezpečnost při pořizování, vývoji a údržbě systémů informačních technologií, včetně řešení a zveřejňování zranitelností.

Německo přebírá text EU téměř doslova. 'Systémy informačních technologií' místo 'sítě a informační systémy' je věc znění, nikoli významu. BSI ukazuje na moduly IT-Grundschutz CON.8 (vývoj softwaru) a OPS.1.1.3 (správa oprav a změn) jako na praktickou cestu.

Tři z deseti pododdílů §6 CIR, vybrané proto, že formují zbytek
§6 CIR 2024/2690 má deset pododdílů. Tři níže jsou ty, které většina operátorů z Mittelstandu podceňuje. Pořizování nastavuje pravidla, která musejí dodržovat všichni ostatní. SDLC zavazuje vývojáře. Správa oprav zavazuje provoz.
§6.1

Zapište bezpečnostní požadavky do každého nákupu

Než koupíte produkt nebo službu IT, sepíšete, co musí splňovat z hlediska bezpečnosti. Ověřování, logování, podpora aktualizací, zveřejňování zranitelností, region hostingu, kde sedí data. Pak ověříte, že dodavatel požadavky skutečně splňuje. To leží na kupujícím subjektu, nikoli na dodavateli. 'Používáme SaaS' povinnost nepřenáší.

§6.2

Provozujte bezpečný životní cyklus vývoje

Bezpečnostní požadavky se analyzují během specifikace a návrhu. Uplatňují se zásady bezpečného kódování, včetně bezpečnosti již ve fázi návrhu a architektur nulové důvěry. Samotná vývojová prostředí jsou zabezpečena. Bezpečnostní testování probíhá před vydáním. S testovacími daty se zachází opatrně, nekopírují se z produkce. Celý životní cyklus je zdokumentován, nejen jedna nebo dvě praktiky.

§6.6

Opravujte ve vhodné lhůtě, nejprve testujte

Bezpečnostní opravy se uplatňují ve vhodné lhůtě (text CIR), navázané na závažnost zranitelnosti. Opravy se před produkcí testují. Nouzové opravy se dokumentují. 'Kdykoli má tým čas' není lhůta. Zvolte kadenci, sepište ji, prokažte, že ji dodržujete.

Dvě pravidla, která formují celý blok §6
Dvě myšlenky se táhnou §6.1 až §6.6. Říkají vám, co auditoři skutečně hledají, když procházejí vaším procesem vývoje a změn.

Bezpečnost od pořizování po vyřazení z provozu

§6 není o vývoji v úzkém smyslu. Pokrývá celý životní cyklus: jak vybíráte, co koupit, jak stavíte, jak konfigurujete, jak testujete, jak opravujete, jak měníte, jak vyřazujete. Mittelstand, který kupuje 95 procent svého softwaru, stále vlastní §6.1 (požadavky na pořizování) a §6.6 (správa oprav). Z životního cyklu se nemůžete vyvázat jen proto, že nepíšete kód.

Disciplína změn: žádné nesledované produkční změny

§6.4 je přímý: změny v produkci jsou řízené, zdokumentované a přezkoumané. Nouzové změny se také dokumentují, jen po faktu místo předem. Změna bez tiketu, bez schvalovatele a bez plánu vrácení požadavek nesplňuje, i když funguje. Auditoři porovnávají protokol změn se systémem tiketů. Pokud nedokážou zrekonstruovat, kdo co a kdy změnil, kontrola není zavedena.

Jak to vnitrostátní regulátoři skutečně řídí
EU stanoví pravidlo. Každá země je transponuje. Podstata je stejná. Místní mechanika se trochu liší.
Německo

BSI / IT-Grundschutz CON.8 + OPS.1.1.3

BSI mapuje §30 odst. 2 bod 5 BSIG na dva moduly Grundschutz. CON.8 'Software-Entwicklung' pokrývá stranu SDLC: požadavky, bezpečné kódování, test, vydání. OPS.1.1.3 'Patch- und Änderungsmanagement' pokrývá stranu změn a oprav. Pokud dodržujete CON.8 a OPS.1.1.3, jste uvnitř toho, co §30 BSIG vyžaduje.

Celá EU

Technické implementační pokyny ENISA

ENISA, agentura EU pro kybernetickou bezpečnost, zveřejňuje Technické implementační pokyny (TIG), které berou abstraktní text §6 CIR a ukazují vám, co dělat v praxi. Mapují každý pododdíl na kontroly ISO/IEC 27001:2022 (A.8.25 až A.8.32 o bezpečném vývoji, A.5.20 až A.5.23 o vztazích s dodavateli), takže stávající certifikace vám dají náskok.

Ostatní členské státy

Vnitrostátní transpoziční zákony

Každý členský stát má vlastní transpoziční zákon (Nizozemsko: Cyberbeveiligingswet, Rakousko: NISG, Belgie: NIS2-Wet). Povinnosti podle čl. 21 odst. 2 písm. e) jsou stejné, protože směrnice stanoví jeden celounijní standard. Liší se to, na jaký vnitrostátní rámec regulátor ukazuje jako na praktickou cestu.

Tři pasti, na které narážíme pořád
Tři předpoklady, které se objevují téměř v každém hovoru o přípravě na audit. Všechny tři vytvářejí mezery, které auditor najde.
  • Používáme SaaS, takže bezpečný vývoj je práce dodavatele.

    Napůl pravda. Dodavatel vlastní kód. Vy stále vlastníte §6.1: zdokumentované bezpečnostní požadavky na každý produkt nebo službu IT, kterou koupíte, plus ověření, že je dodavatel splňuje. Ověřování, logování, podpora aktualizací, umístění dat, oznámení o narušení. Pokud je vaše složka o pořizování prázdná, povinnost není splněna, i když je dodavatel vynikající.

  • Děláme code review, takže část SDLC je pokrytá.

    Code review je jedna praktika. §6.2 chce zdokumentovaný celý životní cyklus: bezpečnostní požadavky během specifikace, zásady bezpečného kódování (včetně bezpečnosti již ve fázi návrhu a nulové důvěry), zabezpečená vývojová prostředí, postupy bezpečnostního testování před vydáním, opatrné zacházení s testovacími daty. Jediná praktika navrch nad nezdokumentovaným procesem oddíl nesplňuje.

  • Opravujeme, když má tým čas.

    §6.6 vyžaduje vhodnou lhůtu navázanou na závažnost, plus testování před produkcí a dokumentaci nouzových oprav. 'Až bude čas' není lhůta. Zvolte kadenci (např. kritické do 72 hodin, vysoké do 14 dnů), sepište ji, prokažte v protokolu změn, že ji dodržujete. Auditor zrekonstruuje vaši historii oprav ze systému tiketů.

Jak to skuteční operátoři z Mittelstandu opravdu dělají

Většina německého IT z Mittelstandu vypadá takto: 90 procent dodavatelský software (ERP, mzdy, mail, sdílení souborů, CRM), nějaké integrační lepidlo, občasné interní skripty. Velkým úkolem §6 pro tento profil není SDLC. Je to §6.1 pořizování a §6.6 správa oprav.

Šablonu bezpečnostních požadavků napište jednou. Ověřování, logování, zveřejňování zranitelností, podpora aktualizací, region hostingu, export dat, oznámení o narušení. Uplatněte ji na každé nové pořízení a každé prodloužení. Spárujte ji s písemnou kadencí oprav (kritické / vysoké / střední s lhůtou u každého) a protokolem změn, který používají všichni. To pokryje většinu §6 pro typický Mittelstand bez najímání specialisty na bezpečnost softwaru.

Jak to řešíme na platformě

Do modulu PRO platformy jsme zabudovali §6.1 požadavky na pořizování, §6.2 dokumentaci SDLC, §6.4 protokol změn a §6.6 kadenci oprav. Šablonu pořizování vyplníte jednou a znovu ji použijete. Každý nový produkt nebo služba IT projde stejným bezpečnostním kontrolním seznamem se schválením.

Protokol změn a kadence oprav běží na stejné auditní stopě jako zbytek platformy: tiket, schvalovatel, plán vrácení, soubor s důkazem. Nouzové změny dostanou formulář po faktu. Neudržujete samostatný protokol pro compliance. Když se auditor zeptá, jak jste opravili CVE, odpovědí je jeden dotaz, ne tři tabulky.

Zdroje
  • Směrnice (EU) 2022/2555 (NIS 2), čl. 21 odst. 2 písm. e). eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Prováděcí nařízení Komise (EU) 2024/2690 (CIR), příloha §6. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • Zákon o BSI (BSIG), §30 odst. 2 bod 5 ve znění implementačního zákona NIS2 a posílení kybernetické bezpečnosti
  • Moduly BSI IT-Grundschutz CON.8 'Software-Entwicklung' a OPS.1.1.3 'Patch- und Änderungsmanagement'
  • Technické implementační pokyny ENISA pro CIR (EU) 2024/2690 (k květnu 2026)
Provozujte pořizování, změny a opravy na jedné platformě
Bezpečnostní požadavky na dodavatele, protokol změn, kadence oprav a důkazy o schválení na jednom místě. Zdarma, open source, bez vázanosti na dodavatele.