Jak NIS 2 i ENISA redefiniują sposób kupowania i tworzenia systemów IT
W NIS 2 bezpieczeństwo nie zaczyna się w momencie wdrożenia systemu ani przy pierwszym incydencie.
Zaczyna się dużo wcześniej: na etapie decyzji zakupowych i projektowych.
Rozdział 6 wytycznych ENISA jasno pokazuje zmianę myślenia. Nie pytamy już tylko czy system jest zabezpieczony, ale jak został wybrany, zaprojektowany, zbudowany i utrzymywany. Pierwsze dwa podpunkty tego rozdziału są fundamentem całej reszty.
1. Bezpieczne pozyskiwanie ICT – bezpieczeństwo zaczyna się w przetargu
ENISA nie pozostawia tu wątpliwości: zakup systemu lub usługi ICT to decyzja bezpieczeństwa, a nie tylko decyzja techniczna czy finansowa.
Proces bezpiecznego pozyskiwania powinien:
- wynikać bezpośrednio z oceny ryzyka,
- obejmować cały cykl życia produktu lub usługi,
- być spójny z polityką bezpieczeństwa i bezpieczeństwem łańcucha dostaw.
To oznacza, że cyberbezpieczeństwo musi być stałym elementem procedur zakupowych, a nie dodatkiem w postaci jednego pytania w RFP.
Co ENISA uznaje za minimum
Proces secure acquisition powinien jasno określać m.in.:
- wymagania bezpieczeństwa wobec systemu lub usługi,
- zasady aktualizacji i wsparcia przez cały okres życia rozwiązania,
- transparentność komponentów sprzętowych i programowych,
- funkcje bezpieczeństwa, które system posiada i sposób ich bezpiecznej konfiguracji,
- metody weryfikacji, czy dostarczone rozwiązanie faktycznie spełnia deklarowane wymagania.
Coraz ważniejszy jest też temat końca życia produktu. ENISA wprost rekomenduje preferowanie dostawców, którzy jasno komunikują end-of-life, oferują poprawki bezpieczeństwa i nie zostawiają organizacji z „martwym” systemem w środku infrastruktury.
Open source też podlega ocenie ryzyka
Wytyczne wyraźnie wskazują, że FOSS (Free and Open Source Software), czyli wolne i otwarte oprogramowanie, również powinno być objęte procesem bezpiecznego pozyskiwania.
Nie oznacza to nakładania nierealnych obowiązków na społeczności open source, ale:
- świadomą ocenę ryzyk,
- dialog z maintainerami,
- dzielenie się wynikami testów i poprawek.
2. Secure Development Life Cycle – bezpieczeństwo jako cecha projektu, nie łatka
Kolejny punkt dotyczy tego, jak systemy są tworzone, zarówno wewnętrznie, jak i przez dostawców.
ENISA konsekwentnie promuje podejście secure by design i secure by default.
Bezpieczny system to nie taki, który przeszedł test penetracyjny na końcu, ale taki, w którym bezpieczeństwo było uwzględnione:
- w wymaganiach,
- w architekturze,
- w kodzie,
- w testach,
- w sposobie wdrożenia.
Co powinny obejmować zasady bezpiecznego wytwarzania
Zasady secure development lifecycle powinny:
- obowiązywać na wszystkich etapach cyklu życia systemu,
- uwzględniać analizę wymagań bezpieczeństwa już na etapie projektowania,
- stosować sprawdzone standardy i dobre praktyki, takie jak OWASP ASVS, ISO/IEC 27034 czy NIST,
- definiować wymagania dla środowisk deweloperskich i testowych,
- obejmować testy bezpieczeństwa jako stały element procesu, a nie incydentalne działanie.
Istotnym elementem jest także bezpieczne zarządzanie danymi testowymi. ENISA wyraźnie wskazuje na konieczność anonimizacji lub pseudonimizacji danych, jeśli do testów używane są dane zbliżone do produkcyjnych.
Outsourcing nie zwalnia z odpowiedzialności
Jeśli rozwój systemu jest zlecany na zewnątrz, obowiązki nie znikają.
Organizacja nadal odpowiada za:
- spójność zasad secure development z zasadami zakupowymi,
- komunikację wymagań bezpieczeństwa do wykonawcy,
- nadzór nad całym cyklem wytwarzania.
Bezpieczne wytwarzanie i bezpieczne zakupy muszą się zazębiać, a nie działać w silosach.
Dlaczego ENISA zaczyna właśnie tutaj
Te punkty nieprzypadkowo pojawia się przed konfiguracją, testami czy zarządzaniem podatnościami.
Jeżeli system:
- został źle wybrany,
- nie ma wsparcia,
- nie był projektowany z myślą o bezpieczeństwie,
to późniejsze procesy są tylko próbą ograniczania strat.
NIS 2 jasno przesuwa ciężar z reagowania na incydenty na zarządzanie jakością decyzji technologicznych.
W kolejnym wpisie z serii przejdziemy dalej:
konfiguracja i zarządzanie zmianą, czyli to, co dzieje się z systemem już po wdrożeniu i dlaczego „działało wczoraj” nie jest żadnym argumentem bezpieczeństwa.
Twoje bezpieczeństwo to nasza pasja! 🌐 Jeśli interesuje Cię ochrona danych osobowych, bezpieczeństwo informacji czy cyberbezpieczeństwo, zajrzyj na stronę CAB oraz Platformę Cyberbezpieczeństwa. Szukasz informacji o ochronie sygnalistów? 📢 Sprawdź stronę Kanału Zgłoszeniowego. Czekają tam praktyczne porady i ekspercka wiedza!