Dezvoltare și achiziție securizată NIS 2 în temeiul articolului 21(2)(e)
NIS 2 spune că trebuie să securizați sistemele pe parcursul achiziției, dezvoltării și întreținerii. Articolul 21(2)(e) este umbrela. §6 din CIR (UE) 2024/2690 îl împarte în zece subsecțiuni. Germania îl introduce în legislația națională prin §30(2)(5) BSIG.
Pe scurt
Articolul 21(2)(e) este obligația-umbrelă pentru securitate pe întreg ciclul de viață al IT. Nu doar codul. Nu doar aplicarea de patch-uri. Întregul parcurs: achiziția unui sistem, construirea lui, configurarea lui, modificarea lui, testarea lui, aplicarea de patch-uri, operarea lui, scoaterea lui din uz. Aceeași regulă se aplică în toată UE.
CIR (UE) 2024/2690 completează detaliile. §6 din anexă are zece subsecțiuni (§6.1 până la §6.10) care operaționalizează obligația. Această pagină acoperă partea de dezvoltare și modificare: achiziția (§6.1), ciclul de viață al dezvoltării securizate (§6.2), gestionarea configurației (§6.3), gestionarea modificărilor (§6.4), testarea securității (§6.5) și gestionarea patch-urilor (§6.6). Securitatea rețelelor, segmentarea, protecția împotriva programelor malware și gestionarea vulnerabilităților (§6.7 până la §6.10) au propriile pagini.
Germania introduce aceeași regulă în legislația națională prin §30(2)(5) BSIG. Formularea este aproape cuvânt cu cuvânt textul UE. Această pagină parcurge directiva, regulamentul UE de aplicare și transpunerea germană, în această ordine.
Articolul 21(2)(e) din Directiva NIS 2 (2022/2555)
Securitatea în achiziția, dezvoltarea și întreținerea rețelelor și a sistemelor informatice, inclusiv gestionarea și divulgarea vulnerabilităților.
Acesta este punctul (e) de pe lista celor zece măsuri de securitate cibernetică pe care fiecare entitate esențială și importantă trebuie să le pună în aplicare. Este singurul punct de pe listă care se extinde explicit de la comanda de achiziție până la sfârșitul duratei de viață.
CIR (UE) 2024/2690, anexa §6
Măsuri de securitate în achiziția, dezvoltarea și întreținerea rețelelor și a sistemelor informatice (articolul 21(2)(e) din Directiva (UE) 2022/2555).
Deoarece este un regulament (nu o directivă), este legislație UE direct obligatorie. Nu este necesară transpunerea națională. Se aplică furnizorilor de DNS, registrelor TLD, furnizorilor de cloud, centrelor de date, furnizorilor de servicii gestionate și celorlalte sectoare enumerate în anexa sa. §6 are zece subsecțiuni numerotate, fiecare numind o obligație specifică.
§30(2)(5) BSIG (Germania)
Securitatea în achiziția, dezvoltarea și întreținerea sistemelor de tehnologie a informației, inclusiv gestionarea și divulgarea vulnerabilităților.
Germania copiază textul UE aproape cuvânt cu cuvânt. 'Sisteme de tehnologie a informației' în loc de 'rețele și sisteme informatice' este o chestiune de formulare, nu de sens. BSI indică modulele IT-Grundschutz CON.8 (dezvoltarea software-ului) și OPS.1.1.3 (gestionarea patch-urilor și a modificărilor) ca rută practică.
Înscrieți cerințele de securitate în fiecare achiziție
Înainte de a cumpăra un produs sau serviciu IT, scrieți ce trebuie să facă pe planul securității. Autentificare, jurnalizare, suport pentru actualizări, divulgarea vulnerabilităților, regiunea de găzduire, unde se află datele. Apoi validați că furnizorul îndeplinește efectiv cerințele. Aceasta revine entității care cumpără, nu furnizorului. 'Folosim SaaS' nu transferă obligația.
Rulați un ciclu de viață de dezvoltare securizată
Cerințele de securitate sunt analizate în timpul specificării și al proiectării. Se aplică principii de codare securizată, inclusiv securitate prin proiectare și arhitecturi zero-trust. Mediile de dezvoltare în sine sunt securizate. Testarea securității are loc înainte de lansare. Datele de testare sunt tratate cu grijă, nu copiate din producție. Întreg ciclul de viață este documentat, nu doar una sau două practici.
Aplicați patch-uri într-un interval adecvat, testați mai întâi
Patch-urile de securitate sunt aplicate într-un interval adecvat (textul CIR), legat de gravitatea vulnerabilității. Patch-urile sunt testate înainte de producție. Patch-urile de urgență sunt documentate. 'Oricând are echipa timp' nu este un interval. Alegeți o cadență, scrieți-o, dovediți că o respectați.
Securitate de la achiziție până la scoaterea din uz
§6 nu se referă la dezvoltare în sens restrâns. Acoperă întreg ciclul de viață: cum alegeți ce cumpărați, cum construiți, cum configurați, cum testați, cum aplicați patch-uri, cum modificați, cum retrageți. Un Mittelstand care cumpără 95% din software-ul său deține totuși §6.1 (cerințe de achiziție) și §6.6 (gestionarea patch-urilor). Nu puteți renunța la ciclul de viață doar pentru că nu scrieți cod.
Disciplina modificărilor: niciio modificare în producție neînregistrată
§6.4 este direct: modificările aduse producției sunt gestionate, documentate și revizuite. Modificările de urgență sunt și ele documentate, doar după producere în loc de înainte. O modificare fără tichet, fără aprobator și fără plan de revenire nu îndeplinește cerința, chiar dacă funcționează. Auditorii verifică jurnalul de modificări față de sistemul de tichete. Dacă nu pot reconstitui cine ce a modificat și când, controlul nu este implementat.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
BSI corelează §30(2)(5) BSIG cu două module Grundschutz. CON.8 'Software-Entwicklung' acoperă partea de SDLC: cerințe, codare securizată, testare, lansare. OPS.1.1.3 'Patch- und Änderungsmanagement' acoperă partea de modificare și patch-uri. Dacă urmați CON.8 și OPS.1.1.3, vă încadrați în ceea ce cere §30 BSIG.
Orientările tehnice de implementare ENISA
ENISA, agenția UE pentru securitate cibernetică, publică orientări tehnice de implementare (TIG) care preiau textul abstract al §6 CIR și vă arată ce să faceți în practică. Acestea corelează fiecare subsecțiune cu controale ISO/IEC 27001:2022 (A.8.25 până la A.8.32 privind dezvoltarea securizată, A.5.20 până la A.5.23 privind relațiile cu furnizorii), astfel încât certificările existente vă oferă un avans.
Legi naționale de transpunere
Fiecare stat membru are propria lege de transpunere (Țările de Jos: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obligațiile în temeiul articolului 21(2)(e) sunt aceleași deoarece directiva stabilește un singur standard la nivelul UE. Ce diferă: cadrul național pe care autoritatea îl indică drept rută practică.
Folosim SaaS, deci dezvoltarea securizată este treaba furnizorului.
Pe jumătate corect. Furnizorul deține codul. Dvs. dețineți totuși §6.1: cerințe de securitate documentate pentru fiecare produs sau serviciu IT pe care îl cumpărați, plus validarea că furnizorul le îndeplinește. Autentificare, jurnalizare, suport pentru actualizări, locația datelor, notificarea încălcărilor. Dacă dosarul dvs. de achiziție este gol, obligația nu este îndeplinită, chiar dacă furnizorul este excelent.
Facem revizuiri de cod, deci partea SDLC este acoperită.
Revizuirea codului este o singură practică. §6.2 cere documentarea întregului ciclu de viață: cerințe de securitate în timpul specificării, principii de codare securizată (inclusiv securitate prin proiectare și zero-trust), medii de dezvoltare securizate, proceduri de testare a securității înainte de lansare, tratarea atentă a datelor de testare. O singură practică deasupra unui proces nedocumentat nu îndeplinește secțiunea.
Aplicăm patch-uri când are echipa timp.
§6.6 cere un interval adecvat legat de gravitate, plus testare înainte de producție și documentare pentru patch-urile de urgență. 'Când este timp' nu este un interval. Alegeți o cadență (de exemplu, critic în 72 de ore, ridicat în 14 zile), scrieți-o, dovediți că o respectați în jurnalul de modificări. Un auditor va reconstitui istoricul dvs. de patch-uri din sistemul de tichete.
Majoritatea IT-ului din Mittelstand-ul german arată astfel: 90% software de furnizor (ERP, salarizare, e-mail, partajare de fișiere, CRM), niște elemente de integrare, scripturi interne ocazionale. Efortul mare la §6 pentru acest profil nu este SDLC. Este achiziția §6.1 și gestionarea patch-urilor §6.6.
Scrieți o singură dată modelul de cerințe de securitate. Autentificare, jurnalizare, divulgarea vulnerabilităților, suport pentru actualizări, regiunea de găzduire, exportul datelor, notificarea încălcărilor. Aplicați-l fiecărei achiziții noi și fiecărei reînnoiri. Asociați-l cu o cadență scrisă de aplicare a patch-urilor (critic / ridicat / mediu cu câte un interval) și cu un jurnal de modificări pe care îl folosește toată lumea. Aceasta acoperă cea mai mare parte a §6 pentru un Mittelstand tipic, fără a angaja un specialist în securitatea software-ului.
Am integrat cerințele de achiziție §6.1, documentația SDLC §6.2, jurnalul de modificări §6.4 și cadența de patch-uri §6.6 în modulul PRO al platformei. Completați o singură dată modelul de achiziție și îl reutilizați. Fiecare produs sau serviciu IT nou trece prin aceeași listă de verificare a securității cu o aprobare.
Jurnalul de modificări și cadența de patch-uri rulează pe aceeași pistă de audit ca restul platformei: tichet, aprobator, plan de revenire, fișier de dovadă. Modificările de urgență primesc formularul ulterior producerii. Nu mențineți un jurnal de conformitate separat. Când un auditor întreabă cum ați aplicat un patch pentru un CVE, răspunsul este o singură interogare, nu trei foi de calcul.
- Directiva (UE) 2022/2555 (NIS 2), articolul 21(2)(e). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamentul de punere în aplicare (UE) 2024/2690 al Comisiei (CIR), anexa §6. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legea BSI (BSIG), §30(2)(5), astfel cum a fost modificată prin Legea de implementare NIS2 și de consolidare a securității cibernetice
- Modulele IT-Grundschutz BSI CON.8 'Software-Entwicklung' și OPS.1.1.3 'Patch- und Änderungsmanagement'
- Orientările tehnice de implementare ENISA pentru CIR (UE) 2024/2690 (la data de mai 2026)