Kanał zgłaszania podatności dla NIS2 i CRA
Kanał zgłaszania podatności dla NIS2 i CRA daje badaczowi z zewnątrz jedno bezpieczne miejsce, w którym zgłosi lukę w Twoim produkcie. Akt o cyberodporności czyni taki kanał obowiązkiem prawnym producentów od 11 grudnia 2027 roku. NIS2 tego nie wymaga i ramy audytowe, o które pytają kupujący, także nie.
Aktywnie wykorzystywaną podatność trzeba zgłosić krajowemu zespołowi CSIRT
Dla każdego nowego produktu trzeba opublikować politykę ujawniania oraz adres kontaktowy
Zgłoszenia przychodzące i zgłoszenia wychodzące
Dwa różne obowiązki nazywa się tak samo. Żeby je rozróżnić, zapytaj, w którą stronę idzie zgłoszenie.
Ktoś spoza Twojej firmy znajduje lukę w produkcie i Ci o niej mówi. Nazywa się to skoordynowanym ujawnianiem podatności. Potrzebny jest opublikowany adres do przyjmowania takich zgłoszeń, spisana polityka oraz bezpieczny sposób odpowiedzi.
Informujesz krajowy zespół do spraw cyberbezpieczeństwa albo organ nadzoru, że coś poszło nie tak. Artykuł 23 NIS2 oraz artykuł 14 CRA działają w ten sposób i oba wyznaczają krótkie terminy. Kanał dla badaczy nie spełnia żadnego z tych obowiązków.
Które przepisy wymagają kanału zgłaszania podatności
Tylko jeden z nich tworzy obowiązek prawny dla firm europejskich. Pozostałe cztery to normy oraz wytyczne, o które często pytają klienci.
Załącznik I wymaga od producenta prowadzenia polityki skoordynowanego ujawniania podatności. Producent musi też opublikować adres, pod którym można zgłaszać luki. Nie ma progu wielkości firmy. Kary sięgają 15 milionów euro albo 2,5 procent światowego obrotu. Obowiązek spoczywa na producentach, więc firma, która tylko kupuje oprogramowanie, nie jest nim objęta. Dla każdego produktu zaczyna się w dniu, w którym produkt trafia do sprzedaży albo zostaje istotnie zmieniony, od 11 grudnia 2027 roku.
NIS2 nie wymaga od Twojej firmy prowadzenia publicznego kanału dla badaczy. Artykuł 12 powierza to zadanie każdemu państwu członkowskiemu oraz krajowemu zespołowi do spraw cyberbezpieczeństwa, który ono wyznaczy. Korzystanie z unijnej bazy podatności jest dobrowolne. Firmy objęte dyrektywą dostają jedno zdanie, w artykule 21 ustęp 2 litera e: obsługa i ujawnianie podatności. Jeśli dostawca mówi, że NIS2 wymaga kanału zgłoszeń, sprawdź najpierw prawo krajowe.
29147 opisuje część widoczną dla badacza: jak przyjmujesz zgłoszenie, jak odpowiadasz osobie, która je wysłała, oraz jak publikujesz wynik. 30111 opisuje badanie i naprawę wewnątrz Twojego zespołu. Żadna z nich nie jest prawem i żadna nie daje certyfikatu. Większość publikowanych polityk ujawniania idzie za nimi, więc zespół bezpieczeństwa czytający Twoją będzie oczekiwał takiej samej struktury.
Dyrektywa 20-01 nakazuje agencjom federalnym Stanów Zjednoczonych opublikować politykę ujawniania podatności. NIST SP 800-216 opisuje tę samą pracę dokładniej. Żaden z tych dokumentów nie wiąże firmy europejskiej. Warto je przeczytać, bo ustaliły format, którego kupujący dziś szukają. Chodzi o wskazanie, które systemy badacz może testować, obietnicę, że nie podejmiesz kroków prawnych wobec osoby działającej w dobrej wierze, oraz jeden adres do zgłoszeń.
SOC 2 nie wspomina o ujawnianiu podatności. Cyber Essentials również o tym nie mówi. ISO/IEC 27002 nie ma zabezpieczenia obejmującego zewnętrzny kanał zgłoszeń. W praktyce prośba przychodzi w ankietach bezpieczeństwa od klientów. Lista kontrolna MVSP wymaga opublikowanej polityki, która mówi, co wolno testować, obiecuje, że badacz działający w dobrej wierze nie zostanie pozwany, oraz podaje dane kontaktowe.
Daty oraz progi pochodzą z tekstów unijnych. Twój organ nadzoru albo Twoja branża mogą wymagać więcej.
Skieruj swój plik security.txt na ten kanał
RFC 9116 opisuje krótki plik tekstowy pod adresem /.well-known/security.txt, dzięki któremu badacz znajdzie właściwy kontakt bez szukania. Plik dotyczy tylko domeny, z której jest serwowany, więc musi zostać na Twojej. Adres w środku może wskazywać Twoją stronę w WeMoral.
Pole Expires jest wymagane i powinno wskazywać datę bliższą niż rok. Ktoś musi odnowić plik, zanim straci ważność. Sprawdziliśmy 155 domen. Wśród znalezionych plików 48 procent łamało zasady, a 21 procent już wygasło.
Contact: https://wemoral.com/report/demo Policy: https://example.com/security-policy Preferred-Languages: en, pl Expires: 2027-03-01T00:00:00.000Z
Co kanał obejmuje
WeMoral przyjmuje zgłoszenie i daje Ci bezpieczny wątek, w którym na nie odpowiesz. To nie jest platforma bug bounty.
Działa na tym samym koncie oraz w tym samym panelu spraw co pozostałe zgłoszenia. Nie trzeba kupować drugiego systemu.
Najczęściej zadawane pytania
Czy moja firma musi prowadzić kanał zgłaszania podatności?
Tylko jeśli jesteś producentem w rozumieniu aktu o cyberodporności. Ten obowiązek zaczyna się 11 grudnia 2027 roku i dotyczy każdego produktu w chwili, gdy trafia do sprzedaży albo zostaje istotnie zmieniony. Firma, która tylko kupuje oprogramowanie, nie jest nim objęta. Sprawdź najpierw przepisy krajowe.
Czy to to samo co zgłaszanie incydentów w NIS2?
Nie, a różnicą jest kierunek. Zgłaszanie incydentów idzie na zewnątrz: mówisz organowi nadzoru, że coś Ci się przydarzyło, w krótkim terminie. Kanał ujawniania idzie do środka: ktoś z zewnątrz mówi Ci o luce. Większość zespołów potrzebuje obu i trzyma je osobno.
Czy WeMoral może hostować nasz plik security.txt?
Nie. RFC 9116 mówi, że plik dotyczy tylko domeny, z której jest serwowany, więc musi leżeć na Twojej. Możemy być adresem, na który wskazuje. Wpisz swoją stronę zgłoszeń w WeMoral w linii Contact.
Czy jeden kanał przyjmie zgłoszenia pracowników oraz zgłoszenia o podatnościach?
Tak i wiele zespołów tak robi. Trzymaj jednak te dwa rodzaje zgłoszeń osobno. Pracownik zgłaszający nieprawidłowość ma ochronę prawną, której badacz z zewnątrz nie dostaje. Ustaw inne osoby prowadzące oraz inne zasady przechowywania, w tym samym panelu.