Managementul vulnerabilităților NIS 2 conform Articolului 21(2)(e)
Managementul vulnerabilităților are două laturi conform NIS 2. Cum gestionați slăbiciunile din propriile sisteme. Și cum gestionați slăbiciunile pe care oamenii vi le raportează. Articolul 21(2)(e) este locul unde stă obligația, CIR (UE) 2024/2690 §6.10 detaliază specificitățile, iar §30(2)(5) BSIG o transpune în legea germană.
Pe scurt
Managementul vulnerabilităților este punctul (e) din lista Articolului 21(2). CIR intitulează secțiunea sa corespunzătoare 'Gestionarea și divulgarea vulnerabilităților'. Acel titlu este indiciul. NIS 2 se preocupă de două lucruri deodată: slăbiciunile care stau în sistemele pe care le operați și slăbiciunile pe care le găsesc persoane din afară în produsele dvs. și vor să vi le spună.
CIR §6.10 stabilește cinci acțiuni. Aduceți informații despre vulnerabilități de la CSIRT-uri, autorități, vânzători și furnizori de servicii. Rulați scanări de vulnerabilități la o cadență documentată. Remediați-le pe cele critice fără întârziere. Legați gestionarea vulnerabilităților de procesele dvs. de schimbare, patch-uri, risc și incidente. Și stabiliți o procedură de divulgare coordonată a vulnerabilităților (CVD) care se aliniază cu politica națională CVD.
Germania pune aceeași regulă în legea națională prin §30(2)(5) BSIG. Cadrul național CVD trece prin programul de divulgare coordonată CERT-Bund de la BSI. NIS 2 în sine stabilește de asemenea o bază de date europeană a vulnerabilităților conform Articolului 12, operată de ENISA, în care entitățile pot divulga în mod voluntar.
Articolul 21(2)(e) Directiva NIS 2 (2022/2555)
Securitatea în achiziția, dezvoltarea și întreținerea rețelelor și sistemelor informatice, inclusiv gestionarea și divulgarea vulnerabilităților.
Punctul (e) din lista celor zece măsuri. Observați încadrarea: gestionarea și divulgarea vulnerabilităților stau în interiorul unei obligații mai largi privind achiziția, dezvoltarea și întreținerea. CIR împarte asta în secțiuni separate (§6.9 achiziția, §6.10 vulnerabilități). Jumătatea de divulgare este cea care este subevaluată.
CIR (UE) 2024/2690, Anexa §6.10
Entitățile relevante obțin informații despre vulnerabilitățile tehnice din rețelele și sistemele lor informatice, evaluează expunerea lor la astfel de vulnerabilități și iau măsuri corespunzătoare pentru a le gestiona.
Drept UE direct obligatoriu pentru sectoarele numite în Anexa CIR (DNS, TLD-uri, cloud, centre de date, MSP-uri, servicii de încredere și celelalte). §6.10.2 listează cinci acțiuni concrete. §6.10.3 spune că atunci când săriți peste atenuare, notați de ce. §6.10.4 spune că revizuiți periodic canalele pe care le folosiți pentru a monitoriza informațiile despre vulnerabilități.
§30(2)(5) BSIG (Germania)
Măsuri de securitate pentru achiziția, dezvoltarea și întreținerea sistemelor, componentelor și proceselor de tehnologie a informației, inclusiv managementul și divulgarea vulnerabilităților.
Germania copiază textul UE. Cadrul național CVD trece prin programul de divulgare coordonată CERT-Bund de la BSI, ceea ce indică în Germania 'aliniat cu politicile naționale CVD aplicabile' din CIR §6.10.2(e).
Aduceți informația înăuntru
Urmăriți informațiile despre vulnerabilități de la CSIRT-uri, autorități, vânzători și furnizori de servicii. Rulați scanări de vulnerabilități la o cadență corespunzătoare mediului dvs. Instrumentele de scanare (Tenable, Qualys, Nessus, OpenVAS) sunt latura de inginerie. Fluxurile (buletinul informativ CERT-Bund, avizele vânzătorilor, NVD) sunt latura de conștientizare. Aveți nevoie de ambele.
Remediați-le pe cele critice, documentați restul
Vulnerabilitățile critice sunt remediate fără întârziere. Gestionarea vulnerabilităților trebuie să se conecteze la managementul dvs. de schimbare, managementul de patch-uri, managementul riscului și managementul incidentelor. Acolo unde decideți să nu atenuați, §6.10.3 spune că creați un plan de atenuare documentat sau notați de ce nu este necesară nicio acțiune. Fără un backlog tăcut.
Rulați un proces de divulgare coordonată
Stabiliți o procedură pentru primirea rapoartelor de vulnerabilități de la persoane din afară și coordonarea divulgării lor, aliniată cu politica națională CVD aplicabilă. Mecanica minimă: un canal de contact publicat (căsuța de e-mail security@ sau un fișier security.txt), un SLA de confirmare, o cronologie de remediere și o publicare publică coordonată. CERT-Bund va media dacă este nevoie.
Periodic, nu reactiv
§6.10.2(b) spune că scanările rulează 'periodic, după caz'. §6.10.4 spune că revizuiți periodic canalele pe care le folosiți pentru a monitoriza informațiile despre vulnerabilități. Ambele formulări înseamnă: cadență scrisă. Documentați cât de des scanați, documentați cât de des revizuiți lista de fluxuri și respectați-o. O scanare o dată pe an pentru că și-a amintit cineva nu este periodică.
Divulgarea coordonată este o obligație, nu opțională
§6.10.2(e) spune că procedura trebuie să existe. Nu 'dacă primiți rapoarte'. Procedura există astfel încât atunci când un cercetător chiar găsește ceva, el să aibă un canal și dvs. să aveți un proces. Minim viabil: o căsuță poștală security@domeniuldvs.com pe care o citește cineva, o fereastră de confirmare (de obicei 7 zile) și o fereastră de divulgare (de obicei 90 de zile). Documentați-o, publicați-o, îndreptați un fișier security.txt spre ea.
BSI / programul CVD CERT-Bund
BSI rulează CERT-Bund, CSIRT-ul federal, și operează un program de divulgare coordonată a vulnerabilităților. Cercetătorii pot raporta prin CERT-Bund, iar BSI va coordona cu vânzătorii afectați. §30(2)(5) BSIG indică spre asta. Dacă stabiliți un proces CVD pentru prima dată, alinierea cronologiilor și a canalelor de contact cu modelul CERT-Bund este alegerea sigură implicită.
Baza de date europeană a vulnerabilităților (Articolul 12 NIS 2)
Articolul 12 NIS 2 stabilește o bază de date europeană a vulnerabilităților operată de ENISA. Entitățile pot divulga vulnerabilități în ea în mod voluntar. Nu este un canal de raportare obligatoriu conform Articolului 23. Este o resursă de referință la nivelul UE care agregează informații despre vulnerabilități în statele membre.
CSIRT-uri naționale ca coordonatori CVD
Fiecare stat membru are CSIRT-ul său național acționând ca coordonator CVD (NCSC-NL în Țările de Jos, CERT.at în Austria, CCB în Belgia). Obligația este aceeași la nivelul UE. Ce diferă: cu ce CSIRT vorbiți și mecanica exactă a procesului lor de coordonare.
Aplicăm patch-uri de Patch Tuesday, asta este suficient.
Nu este. §6.10.2(c) spune că vulnerabilitățile critice sunt remediate fără întârziere. Patch Tuesday este o cadență de lansare a vânzătorului. Un zero-day divulgat într-o zi de joi cu exploatare activă nu așteaptă până marțea viitoare. Aveți nevoie de o cadență de aplicare a patch-urilor pentru remedierile de rutină și de un proces în afara benzii pentru problemele critice.
Nu avem un proces CVD pentru că nimeni nu ne raportează vreodată vulnerabilități.
§6.10.2(e) nu spune 'stabiliți un proces când încep să vină rapoartele'. Spune că procedura trebuie să existe. Ideea este să vă asigurați că atunci când un cercetător chiar găsește ceva, el are un canal clar și echipa dvs. știe ce să facă. O căsuță security@ și o politică de o pagină sunt suficiente pentru a satisface obligația. A nu avea una este o constatare.
Scanarea vulnerabilităților este treaba echipei de securitate.
Este, până citiți §6.10.2(d): gestionarea vulnerabilităților trebuie să fie consecventă cu managementul de schimbare, managementul de patch-uri, managementul riscului și managementul incidentelor. Și §6.10.4: revizuiți canalele la nivel organizațional. Asta face din managementul vulnerabilităților un proces între echipe care atinge operațiunile IT, dezvoltarea, riscul și organul de conducere, nu o activitate de securitate izolată.
Latura de inginerie este de obicei în formă rezonabilă. Majoritatea echipelor IT din Mittelstand rulează deja un scaner (Tenable, Qualys, Nessus, OpenVAS) și au un fel de cadență de aplicare a patch-urilor, chiar dacă este doar 'Patch Tuesday pentru clienți, trimestrial pentru servere'. Obligațiile CIR §6.10.2(a)+(b)+(c) sunt în mare parte despre a nota ce se întâmplă deja și a strânge cronologia de remediere critică.
Latura CVD este jumătatea subdocumentată. Minim realist: o căsuță security@domeniuldvs.com direcționată către două persoane, o politică de divulgare de o pagină (confirmare în 7 zile, divulgare în 90 de zile, creditarea cercetătorilor care doresc) și un fișier security.txt la /.well-known/security.txt care indică spre căsuță. O jumătate de zi de muncă. Piesa pe care auditurile o semnalează de fapt.
Modulul PRO captează inventarul dvs. de vulnerabilități, programul de scanare, sarcinile de remediere și deciziile de acceptare într-un singur loc. Fiecare constatare de scanare este direcționată într-o sarcină cu un proprietar, un termen și o aprobare. 'Documentați de ce nu este necesară nicio acțiune' din §6.10.3 este aceeași cale de aprobare: justificare scrisă, aprobator numit, pistă de audit. Fără o foaie de calcul separată.
De asemenea, livrăm un șablon de politică CVD (configurarea căsuței security@, conținutul security.txt, SLA-uri de confirmare și divulgare aliniate cu CERT-Bund). Introduceți domeniul și contactele dvs. și aveți obligația §6.10.2(e) acoperită. Rapoartele primite sunt direcționate în aceeași conductă de sarcini ca și constatările de scanare, astfel încât cronologia de răspuns este urmărită în același mod.
- Directiva (UE) 2022/2555 (NIS 2), Articolul 12 și Articolul 21(2)(e). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamentul de punere în aplicare al Comisiei (UE) 2024/2690 (CIR), Anexa §6.10. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legea BSI (BSIG), §30(2)(5) astfel cum a fost modificată prin Legea de punere în aplicare a NIS2 și de consolidare a securității cibernetice
- BSI / programul de divulgare coordonată a vulnerabilităților CERT-Bund. bsi.bund.de
- Baza de date europeană a vulnerabilităților ENISA (Articolul 12 NIS 2)