NIS 2 (dyrektywa (UE) 2022/2555) określa dziesięć środków zarządzania ryzykiem cyberbezpieczeństwa w art. 21 ust. 2, a większość opracowań dotyczących zgodności traktuje je jako kwestie polityki i procesów: polityka bezpieczeństwa informacji, procedura postępowania w przypadku incydentów, plan ciągłości działania. To prawda w przypadku większości punktów z listy. Jest to jednak niepełne w odniesieniu do środka, który zależy od tego, co zespół faktycznie dostarcza: art. 21 ust. 2 lit. e, dotyczący bezpieczeństwa w zakresie pozyskiwania, rozwoju i utrzymania sieci oraz systemów informatycznych, w tym postępowania z lukami i ich ujawniania.
Ten przewodnik jest przeznaczony dla programistów, których organizacja podlega NIS 2, jest kluczowym lub ważnym podmiotem w rozumieniu dyrektywy albo dostawcą zaopatrującym taki podmiot, i którzy chcą wiedzieć, którą część tego środka recenzja pull request może faktycznie wykryć, odrębnie od środków dotyczących łańcucha dostaw i higieny cybernetycznej, które są już uwzględnione w centralnym hubie frameworków.
Dla kogo jest ten przewodnik oraz reguła wielkości
NIS 2 dotyczy średnich i dużych podmiotów zgodnie z regułą wielkości (ogólnie: co najmniej 50 pracowników lub roczny obrót i suma bilansowa przekraczające 10 milionów euro), działających w sektorach wymienionych w załączniku I i II dyrektywy: energetyka, transport, bankowość, ochrona zdrowia i cyfrowa infrastruktura wśród innych w załączniku I; usługi pocztowe, chemikalia, żywność i produkcja wśród innych w załączniku II. Sam sektor nie decyduje o klasyfikacji jako kluczowy lub ważny: w załączniku I duży podmiot spełniający kryterium wielkości jest zwykle klasyfikowany jako „kluczowy”, a średni jako „ważny”; podmiot z załącznika II spełniający kryterium wielkości jest zwykle klasyfikowany jako „ważny”, niezależnie od tego, czy jest średni, czy duży (wielkość nie dzieli go dalej tak, jak w załączniku I); mniejsza grupa podmiotów (niektóre dostawcy cyfrowej infrastruktury, administracja publiczna i kilka innych specjalnych kategorii) jest objęta zakresem, a czasem klasyfikowana jako kluczowa, niezależnie od wielkości, na podstawie nazwy, a nie reguły wielkości. Czy Twoja organizacja lub klient, dla którego tworzysz oprogramowanie, jest kluczowa, ważna czy poza zakresem, to kwestia klasyfikacji prawnej dla zespołu ds. zgodności lub prawników, a nie coś, co decyduje recenzja kodu. Jeśli ta rozmowa jeszcze nie miała miejsca, przeprowadź ją, zanim potraktujesz ten przewodnik jako program zgodności.
Ten przewodnik zakłada, że kwestia klasyfikacji została już rozstrzygnięta i organizacja podlega NIS 2. Nie jest on substytutem ram zarządzania ryzykiem wymaganych przez dyrektywę, postępowania w przypadku incydentów (art. 21 ust. 2 lit. b) i zgłaszania incydentów (art. 23), ani odpowiedzialności organów zarządzających (art. 20). Dotyczą one jednego środka z art. 21 ust. 2, który może zostać osłabiony w diffie.
Środek, który faktycznie pojawia się w diffie: art. 21 ust. 2 lit. e
Dwa z dziesięciu środków z art. 21 ust. 2 mają już swoje własne strony kontroli w kodzie na tej stronie: bezpieczeństwo łańcucha dostaw (art. 21 ust. 2 lit. d, nieprzypięta lub niezweryfikowana zależność) oraz podstawowa higiena cybernetyczna (art. 21 ust. 2 lit. g, znana luka pozostawiona bez poprawki). Punkt (e), dotyczący bezpieczeństwa w zakresie pozyskiwania, rozwoju i utrzymania sieci oraz systemów informatycznych, to inny aspekt: obejmuje on sposób budowania oprogramowania oraz sposób wykrywania i ujawniania luk w nim, a nie to, które zależności są importowane lub które poprawki są później stosowane.
W praktyce sprowadza się to do dwóch nawyków inżynierskich. Po pierwsze, testy bezpieczeństwa, które proces rozwoju przeprowadza przed dostarczeniem zmiany: brama analizy statycznej, wymagany krok recenzji bezpieczeństwa, sprawdzenie zależności lub fuzzing, które muszą zostać zaliczone. Po drugie, działający kanał ujawniania luk dla oprogramowania po jego uruchomieniu: kontakt ds. bezpieczeństwa, opublikowany formularz dla zewnętrznych zgłoszeń, droga dla osoby, która znajdzie lukę, aby poinformować o niej. Każdy z tych elementów może zostać osłabiony w pojedynczym pull request: brama zostaje wyłączona, aby odblokować wydanie, lub nowa powierzchnia dostępna z zewnątrz zostaje dostarczona bez dołączonego kanału ujawniania.
Przykład praktyczny: brama wyłączona, aby dotrzymać terminu
Zespół jest pod presją czasu, aby dostarczyć nowy publiczny punkt końcowy API, pierwszy interfejs klienta dostępny z otwartego internetu w firmie. Pull request dodający ten punkt końcowy zawiera również niezwiązaną jednowierszową zmianę: wymagana brama bezpieczeństwa analizy statycznej w repozytorium, która normalnie musi zostać zaliczona przed scalonym, zostaje oznaczona jako nienadpisywalna z komentarzem odnoszącym się do biletu follow-up. Sam punkt końcowy jest dobrze zbudowany, z walidacją wejścia i sprawdzeniami autoryzacji, które przechodzą recenzję ludzką. Bilet follow-up wymieniony w komentarzu nie istnieje, a nic w PR nie przywraca bramy do stanu nadpisywalnego po wydaniu. Ponadto firma nie ma kontaktu ds. bezpieczeństwa, pliku `security.txt` ani opublikowanego kanału zgłaszania luk: dotychczas narażone były jedynie narzędzia wewnętrzne, więc nikt nie potrzebował takiego kanału.
Recenzowany wyłącznie jako funkcjonalność, ten PR jest w porządku: punkt końcowy działa, testy przechodzą, termin zostaje dotrzymany. Recenzowany pod kątem art. 21 ust. 2 lit. e, jest jednocześnie dwoma rzeczami. Osłabia testy bezpieczeństwa, które proces rozwoju miał przeprowadzać przed dostarczeniem kodu, bez wyjątku o określonym zakresie lub ścieżki przywracania, co dokładnie dotyczy pierwszej części środka (pozyskiwanie i rozwój). Jest to także moment, w którym brakujący kanał ujawniania luk w firmie przestaje być luką papierową i staje się realną: istnieje teraz aktywna, dostępna z zewnątrz powierzchnia, a nie ma drogi, aby osoba, która znajdzie w niej lukę, mogła poinformować firmę, co dotyczy drugiej części (ujawnianie). Żaden z problemów nie dotyczy tego, czy kod punktu końcowego jest poprawny. Oba dotyczą tego, czy proces i organizacja nadal spełniają środek, który zakładał, że brama pozostanie włączona, a kanał ujawniania istniał gdzieś.
Znalezisko powołujące się na art. 21 ust. 2 lit. e nie decyduje, czy brama powinna zostać wyłączona z ważnego powodu, nie projektuje polityki ujawniania ani nie przeprowadza samego testu bezpieczeństwa. Sprawia, że zmiana staje się widoczna, gdy PR jest jeszcze otwarty, aby autor lub recenzent mógł albo przywrócić bramę z rzeczywistym, śledzonym wyjątkiem, albo zaznaczyć, że organizacja potrzebuje kanału ujawniania, zanim ten punkt końcowy stanie się głównym miejscem dla zgłoszenia, które nie ma gdzie trafić. Jeśli kanał ujawniania już istniał na poziomie organizacji, druga część nie miałaby zastosowania: luka jest realna tylko dlatego, że go nie ma.
Na co zwrócić uwagę podczas recenzji, nie stając się prawnikiem NIS 2
Gdy pull request dotyczy konfiguracji CI, zapytaj, czy wyłącza, osłabia lub omija wymagany krok testów bezpieczeństwa, i jeśli tak, czy ten sam PR (lub powiązany) dokumentuje, dlaczego i kiedy zostanie przywrócony. Brama wyłączona bez ścieżki przywracania to sygnał art. 21 ust. 2 lit. e. Gdy pull request dodaje nowy punkt końcowy, usługę lub integrację dostępną z zewnątrz, zapytaj, czy kanał ujawniania luk dla niej już istnieje na poziomie organizacji; jeśli tak, nowa powierzchnia dziedziczy go i nic więcej nie jest potrzebne; jeśli nie, to luka, którą warto zgłosić, nawet jeśli jest to jednorazowa poprawka organizacyjna, a nie na poziomie PR.
To węższe żądanie niż pełny środek. Nie obejmuje on tego, czy dokumentacja cyklu życia rozwoju jest kompletna, ani czy proces postępowania z lukami spełnia wszystkie elementy opisane w dyrektywie; to kwestie procesowe dla osoby odpowiedzialnej za program NIS 2 w organizacji. Obejmuje on dwie sytuacje, w których pull request może cicho cofnąć pracę, którą program ten już wykonał.
Rola heygrc oraz granica odpowiedzialności
heygrc został zaprojektowany do sprawdzania każdego pull request względem wybranych frameworków, w tym NIS 2 (jeśli włączony), oraz do identyfikowania punktu, którego dotyczy zmiana, np. art. 21 ust. 2 lit. e w przypadku wyłączonej bramy bezpieczeństwa lub nowego punktu końcowego bez widocznego kanału ujawniania, art. 21 ust. 2 lit. d w przypadku nieprzypiętej zależności, art. 21 ust. 2 lit. g w przypadku wstrzymanej poprawki. Znalezisko to komentarz recenzji z dołączonym artykułem, aby autor i recenzent mogli podjąć decyzję z pełną wiedzą. Nie certyfikuje zgodności z NIS 2, nie pisze polityki ujawniania luk, nie przeprowadza testów bezpieczeństwa, nie klasyfikuje podmiotu ani nie składa wymaganych zgłoszeń incydentów (art. 23). Te obowiązki pozostają po stronie ludzi i organizacji.
Jeśli Twój zespół już uruchamia narzędzie SAST lub do kontroli jakości kodu na tym samym pull request, zachowaj je. To narzędzie sprawdza, czy sam kod jest poprawny i bezpieczny. Art. 21 ust. 2 lit. e sprawdza, czy proces wokół kodu, brama, która miała zostać uruchomiona, oraz droga, której ktoś używa do zgłoszenia luki, nadal obowiązują. Punkt końcowy opisany powyżej może przejść wszystkie kontrole jakości i nadal pozostawić środek słabszy niż wcześniej. Uruchom obie warstwy; żadna nie zastępuje drugiej.