Zarządzanie podatnościami w NIS 2 na mocy artykułu 21(2)(e)
Zarządzanie podatnościami ma dwie strony w NIS 2. Jak postępujesz ze słabościami we własnych systemach. Oraz jak postępujesz ze słabościami, które ludzie Ci zgłaszają. Artykuł 21(2)(e) to miejsce, w którym mieści się ten obowiązek, CIR (UE) 2024/2690 §6.10 precyzuje szczegóły, a §30(2)(5) BSIG transponuje go do prawa niemieckiego.
W skrócie
Zarządzanie podatnościami to punkt (e) na liście artykułu 21(2). CIR zatytułowuje odpowiadającą mu sekcję 'Postępowanie z podatnościami i ich ujawnianie'. Ten tytuł zdradza istotę. NIS 2 dba jednocześnie o dwie rzeczy: słabości tkwiące w systemach, które prowadzisz, oraz słabości, które osoby z zewnątrz znajdują w Twoich produktach i chcą Ci o nich powiedzieć.
CIR §6.10 wymienia pięć działań. Pozyskuj informacje o podatnościach od CSIRT, organów, dostawców i usługodawców. Prowadź skanowanie podatności w udokumentowanym rytmie. Usuwaj krytyczne bez zbędnej zwłoki. Powiąż postępowanie z podatnościami z procesami zmian, łatania, ryzyka i incydentów. Oraz ustanów procedurę skoordynowanego ujawniania podatności (CVD) zgodną z krajową polityką CVD.
Niemcy wprowadzają tę samą zasadę do prawa krajowego poprzez §30(2)(5) BSIG. Krajowe ramy CVD przebiegają przez program skoordynowanego ujawniania CERT-Bund w BSI. Sam NIS 2 ustanawia również europejską bazę danych podatności na mocy artykułu 12, prowadzoną przez ENISA, do której podmioty mogą dobrowolnie ujawniać.
Artykuł 21(2)(e) dyrektywy NIS 2 (2022/2555)
Bezpieczeństwo w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych, w tym postępowanie z podatnościami i ich ujawnianie.
Punkt (e) na liście dziesięciu środków. Zwróć uwagę na ujęcie: postępowanie z podatnościami i ich ujawnianie mieszczą się w szerszym obowiązku dotyczącym nabywania, rozwoju i utrzymania. CIR dzieli to na odrębne sekcje (§6.9 nabywanie, §6.10 podatności). To połowa dotycząca ujawniania jest niedoceniana.
CIR (UE) 2024/2690, załącznik §6.10
Dane podmioty pozyskują informacje o podatnościach technicznych w swoich sieciach i systemach informatycznych, oceniają swoje narażenie na takie podatności oraz podejmują odpowiednie środki w celu zarządzania nimi.
Bezpośrednio wiążące prawo UE dla sektorów wymienionych w załączniku do CIR (DNS, TLD, chmura, centra danych, MSP, usługi zaufania i inne). §6.10.2 wymienia pięć konkretnych działań. §6.10.3 stanowi, że gdy pomijasz łagodzenie, zapisujesz dlaczego. §6.10.4 stanowi, że okresowo przeglądasz kanały, których używasz do monitorowania informacji o podatnościach.
§30(2)(5) BSIG (Niemcy)
Środki bezpieczeństwa w procesie nabywania, rozwoju i utrzymania systemów informatycznych, komponentów i procesów, w tym zarządzanie podatnościami i ich ujawnianie.
Niemcy kopiują tekst UE. Krajowe ramy CVD przebiegają przez program skoordynowanego ujawniania CERT-Bund w BSI, do czego w Niemczech odnosi się sformułowanie 'zgodne z obowiązującymi krajowymi politykami CVD' w CIR §6.10.2(e).
Wprowadź informacje do środka
Śledź informacje o podatnościach od CSIRT, organów, dostawców i usługodawców. Prowadź skanowanie podatności w rytmie odpowiednim do Twojego środowiska. Narzędzia skanujące (Tenable, Qualys, Nessus, OpenVAS) to strona inżynierska. Kanały (newsletter CERT-Bund, biuletyny dostawców, NVD) to strona świadomości. Potrzebujesz obu.
Napraw krytyczne, udokumentuj resztę
Krytyczne podatności są usuwane bez zbędnej zwłoki. Postępowanie z podatnościami musi zazębiać się z Twoim zarządzaniem zmianą, zarządzaniem łatkami, zarządzaniem ryzykiem i zarządzaniem incydentami. Tam, gdzie decydujesz się nie łagodzić, §6.10.3 stanowi, że tworzysz udokumentowany plan łagodzenia lub zapisujesz, dlaczego żadne działanie nie jest potrzebne. Żadnego cichego zaległościowca.
Prowadź skoordynowany proces ujawniania
Ustanów procedurę przyjmowania zgłoszeń podatności od osób z zewnątrz i koordynowania ich ujawniania, zgodną z obowiązującą krajową polityką CVD. Minimalna mechanika: opublikowany kanał kontaktu (skrzynka security@ lub plik security.txt), SLA potwierdzenia, harmonogram usuwania oraz skoordynowane publiczne ujawnienie. CERT-Bund pośredniczy w razie potrzeby.
Okresowo, nie reaktywnie
§6.10.2(b) stanowi, że skanowania przebiegają 'okresowo, stosownie do potrzeb'. §6.10.4 stanowi, że okresowo przeglądasz kanały, których używasz do monitorowania informacji o podatnościach. Oba sformułowania oznaczają: spisany rytm. Udokumentuj, jak często skanujesz, udokumentuj, jak często przeglądasz listę kanałów, i trzymaj się tego. Skanowanie raz w roku, bo ktoś sobie przypomniał, nie jest okresowe.
Skoordynowane ujawnianie to obowiązek, nie opcja
§6.10.2(e) stanowi, że procedura musi istnieć. Nie 'jeśli dostajesz zgłoszenia'. Procedura istnieje po to, by gdy badacz coś znajdzie, miał kanał, a Ty miał proces. Minimalna wersja: skrzynka security@twojadomena.com, którą ktoś czyta, okno potwierdzenia (zwykle 7 dni) i okno ujawnienia (zwykle 90 dni). Udokumentuj to, opublikuj i wskaż na to plikiem security.txt.
BSI / program CVD CERT-Bund
BSI prowadzi CERT-Bund, federalny CSIRT, i prowadzi program skoordynowanego ujawniania podatności. Badacze mogą zgłaszać przez CERT-Bund, a BSI będzie koordynować z dotkniętymi dostawcami. §30(2)(5) BSIG na to wskazuje. Jeśli ustanawiasz proces CVD po raz pierwszy, dopasowanie swoich harmonogramów i kanałów kontaktu do modelu CERT-Bund jest bezpiecznym domyślnym wyborem.
Europejska baza danych podatności (artykuł 12 NIS 2)
Artykuł 12 NIS 2 ustanawia europejską bazę danych podatności prowadzoną przez ENISA. Podmioty mogą dobrowolnie ujawniać do niej podatności. Nie jest to obowiązkowy kanał zgłaszania na mocy artykułu 23. To ogólnounijne źródło referencyjne, które agreguje informacje o podatnościach z całej UE.
Krajowe CSIRT jako koordynatorzy CVD
Każde państwo członkowskie ma swój krajowy CSIRT działający jako koordynator CVD (NCSC-NL w Holandii, CERT.at w Austrii, CCB w Belgii). Obowiązek jest taki sam w całej UE. Różni się: z którym CSIRT rozmawiasz i dokładna mechanika ich procesu koordynacji.
Łatamy w Patch Tuesday, to wystarczy.
Nie wystarczy. §6.10.2(c) stanowi, że krytyczne podatności są usuwane bez zbędnej zwłoki. Patch Tuesday to rytm wydawania dostawcy. Zero-day ujawniony w czwartek z aktywnym wykorzystywaniem nie czeka do następnego wtorku. Potrzebujesz rytmu łatania dla rutynowych poprawek oraz procesu poza-pasmowego dla problemów krytycznych.
Nie mamy procesu CVD, bo nikt nigdy nie zgłasza nam podatności.
§6.10.2(e) nie mówi 'ustanów proces, gdy zgłoszenia zaczną napływać'. Mówi, że procedura musi istnieć. Chodzi o to, by zapewnić, że gdy badacz coś znajdzie, będzie miał jasny kanał, a Twój zespół będzie wiedział, co robić. Skrzynka security@ i jednostronicowa polityka wystarczą do spełnienia obowiązku. Brak takiej skrzynki to nieprawidłowość.
Skanowanie podatności to zadanie zespołu bezpieczeństwa.
Jest nim, dopóki nie przeczytasz §6.10.2(d): postępowanie z podatnościami musi być spójne z zarządzaniem zmianą, zarządzaniem łatkami, zarządzaniem ryzykiem i zarządzaniem incydentami. Oraz §6.10.4: przeglądaj kanały na poziomie organizacyjnym. To czyni zarządzanie podatnościami procesem międzyzespołowym dotykającym operacji IT, rozwoju, ryzyka i organu zarządzającego, a nie odizolowaną działalnością bezpieczeństwa.
Strona inżynierska zwykle jest w rozsądnym stanie. Większość zespołów IT z Mittelstandu już prowadzi skaner (Tenable, Qualys, Nessus, OpenVAS) i ma jakiś rytm łatania, nawet jeśli to tylko 'Patch Tuesday dla klientów, kwartalnie dla serwerów'. Obowiązki CIR §6.10.2(a)+(b)+(c) sprowadzają się głównie do spisania tego, co już się dzieje, i zaostrzenia terminu naprawy krytycznych.
Strona CVD to niedoudokumentowana połowa. Realistyczne minimum: skrzynka security@twojadomena.com kierowana do dwóch osób, jednostronicowa polityka ujawniania (potwierdzenie w ciągu 7 dni, ujawnienie w ciągu 90 dni, uznanie badaczy, którzy tego chcą) oraz plik security.txt pod /.well-known/security.txt wskazujący na skrzynkę. Pół dnia pracy. Element, który audyty faktycznie wytykają.
Moduł PRO ujmuje Twoją inwentaryzację podatności, harmonogram skanowania, zadania naprawcze i decyzje akceptacyjne w jednym miejscu. Każde znalezisko ze skanowania jest kierowane do zadania z właścicielem, terminem i zatwierdzeniem. 'Udokumentuj, dlaczego żadne działanie nie jest potrzebne' z §6.10.3 to ta sama ścieżka zatwierdzania: spisane uzasadnienie, imiennie wskazany zatwierdzający, ślad audytowy. Żadnego osobnego arkusza.
Dostarczamy też szablon polityki CVD (konfiguracja skrzynki security@, treść security.txt, SLA potwierdzenia i ujawniania zgodne z CERT-Bund). Wpisujesz swoją domenę i kontakty i masz pokryty obowiązek z §6.10.2(e). Przychodzące zgłoszenia trafiają do tego samego potoku zadań co znaleziska ze skanowania, więc harmonogram reakcji jest śledzony w ten sam sposób.
- Dyrektywa (UE) 2022/2555 (NIS 2), artykuł 12 i artykuł 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 (CIR), załącznik §6.10 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ustawa BSI (BSIG), §30(2)(5) w brzmieniu zmienionym ustawą o wdrożeniu NIS2 i wzmocnieniu cyberbezpieczeństwa
- BSI / program skoordynowanego ujawniania podatności CERT-Bund — bsi.bund.de
- Europejska baza danych podatności ENISA (artykuł 12 NIS 2)