NIS2 art. 20: za cyberbezpieczeństwo odpowiada zarząd. Osobiście

Przez lata cyberbezpieczeństwo było w praktyce sprawą działu IT. Zarząd zatwierdzał budżet, słuchał kwartalnej prezentacji i wracał do spraw, które uważał za swoje. NIS2 zmienia w tym jedną rzecz, o której mówi się zaskakująco mało: odpowiedzialność przestaje być działu IT, a staje się zarządu. Osobiście.
To nie jest chwyt retoryczny. Artykuł 20 dyrektywy nakłada obowiązki wprost na organy zarządzające, a polska ustawa o KSC przekłada je na konkretne obowiązki kierownika podmiotu. Delegowanie zadań nie zwalnia kierownika z odpowiedzialności. Piszę to bez straszenia, bo strach jest złym doradcą przy decyzjach o pieniądzach i priorytetach. Zastrzeżenie: nie jestem prawnikiem, to nie jest porada prawna, wykładnię dla Waszej sytuacji potwierdźcie z obsługą prawną.
Co art. 20 nakłada na zarząd
Trzy rzeczy, każda konkretna.
Zatwierdzanie środków zarządzania ryzykiem. Zarząd ma nie tylko wiedzieć, że firma coś robi w obszarze bezpieczeństwa, ale formalnie zatwierdzić przyjęte środki. To znaczy, że gdzieś istnieje decyzja z datą i podpisem, a nie domniemanie, że "IT się tym zajmuje".
Nadzór nad wdrażaniem. Zatwierdzenie to nie koniec. Zarząd ma nadzorować, czy zatwierdzone środki są faktycznie wdrażane i czy działają. Nadzór bez śladu nie istnieje, więc musi zostawiać dowód.
Szkolenia. Kierownik podmiotu ma odbywać szkolenie co najmniej raz w roku, żeby rozumieć ryzyka, o których decyduje. Nie chodzi o certyfikat na ścianę, tylko o to, żeby osoba podejmująca decyzję o akceptacji ryzyka wiedziała, co akceptuje.
Polska ustawa przewiduje również kary dla kierownika: do 300 procent miesięcznego wynagrodzenia w podmiocie prywatnym i do 100 procent w podmiocie publicznym. To górne granice, a nie automatyczna stawka za każde uchybienie.
Co znaczy "dowód nadzoru"
To jest pojęcie, które w praktyce sprawia najwięcej kłopotu, bo brzmi miękko, a musi mieć twardą postać. Nadzór, którego nie da się pokazać, dla organu kontrolnego nie miał miejsca. W praktyce dowód nadzoru to:
- regularne raporty o stanie bezpieczeństwa trafiające do zarządu, z datami i z tym, że ktoś je faktycznie omawiał, a nie tylko dostał na skrzynkę,
- zatwierdzone polityki i decyzje z datą, pokazujące, kiedy i co organ przyjął,
- decyzje o akceptacji istotnych ryzyk z podpisem osoby uprawnionej, nie z anonimowym wpisem w arkuszu,
- budżet na bezpieczeństwo z uzasadnieniem, pokazujący, że środki są adekwatne do ryzyka, a nie przypadkowe.
Wspólny mianownik: każda z tych rzeczy zostawia ślad z datą i odpowiedzialną osobą. Nadzór to nie stan świadomości zarządu, tylko udokumentowana sekwencja decyzji.
Pięć pytań, które zarząd powinien zadać swojemu IT
Nie musisz znać się na technice, żeby ocenić, czy proces istnieje. Wystarczy zadać pięć pytań i posłuchać, czy odpowiedzi są konkretne, czy wymijające.
Które nasze systemy są objęte NIS2 i skąd to wiemy. Dobra odpowiedź zawiera liczbę i uzasadnienie. Zła zaczyna się od "no, w zasadzie".
Kiedy ostatnio wykryliśmy krytyczną podatność i ile czasu zajęło jej usunięcie. Dobra odpowiedź to konkretna data i konkretna liczba dni. Zła to "na bieżąco to obsługujemy".
Co mamy otwarte, czego świadomie nie naprawiamy, i kto to zaakceptował. Dobra odpowiedź wskazuje wpisy w rejestrze ryzyka z nazwiskami. Zła sugeruje, że wszystko jest naprawione, co samo w sobie jest podejrzane.
Gdyby jutro przyszedł organ kontrolny i poprosił o dowody za ostatni rok, ile czasu zajmie ich zebranie. Dobra odpowiedź to godziny. Zła to tygodnie, co oznacza, że dowody nie istnieją, tylko dają się odtworzyć, a to nie to samo.
Kto oprócz jednej osoby rozumie, jak działa nasz proces bezpieczeństwa. Dobra odpowiedź wymienia więcej niż jedną osobę i wskazuje dokumentację. Zła to imię jednego admina, po którego odejściu proces zniknie.
Po tych pięciu odpowiedziach będziesz wiedział więcej o realnym stanie bezpieczeństwa firmy niż z niejednej prezentacji.
Czego narzędzie nie załatwi
Tu muszę być uczciwy, bo sprzedaję narzędzie, a narzędzie ma swoje granice. Żaden system ani delegowanie zadań nie zdejmie z kierownika odpowiedzialności ustawowej. Działający, udokumentowany proces może natomiast wykazać należytą realizację obowiązków. Narzędzie obniża koszt prowadzenia części takiego procesu i sprawia, że ślad decyzji powstaje przy codziennej pracy, zamiast być składany ręcznie przed kontrolą.
To realna wartość, ale nie magia. Jeśli proces nie istnieje, narzędzie go nie stworzy. Jeśli istnieje, narzędzie sprawi, że jego udowodnienie przestanie być projektem.
Co z tym zrobić
Najprostszy pierwszy krok to zobaczyć, jak wygląda raport o stanie bezpieczeństwa napisany pod kątem zarządu, a nie pod kątem administratora. Jeśli chcesz zobaczyć taki raport i całą resztę procesu na własnych oczach, załóż konto i przejdź przez to od strony osoby, która ma za to odpowiadać przed organem.
Art. 20 nie wymaga, żeby zarząd znał się na technice. Wymaga, żeby zarząd panował nad ryzykiem i umiał to udowodnić. Różnica między tymi dwoma rzeczami to różnica między prezentacją a dokumentem, a na kontroli liczy się to drugie.
Źródła
Cotygodniowy digest CVE
Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.
Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.

