Ścieżka zgodności · CIR 2024/2690
Bezpieczny rozwój i utrzymanie systemów — jak spełnić załącznik pkt 6 CIR 2024/2690 krok po kroku
Odpowiednie podmioty zapewniają bezpieczeństwo w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych: zarządzają ryzykiem nabycia usług i produktów ICT, prowadzą bezpieczny cykl rozwojowy, zarządzają konfiguracją, zmianą i poprawkami zabezpieczeń, testują bezpieczeństwo, chronią i segmentują sieci, bronią się przed szkodliwym oprogramowaniem oraz postępują z podatnościami i je ujawniają. Poniżej ta norma rozłożona na warstwy: wymagania → kontrole standardów → rozwiązania. Zacznijcie od pytania, czy ten obowiązek Was wiąże — odpowiedź jest pierwszą sekcją pod spodem.
Krok zero
Kogo wiąże ten obowiązek?
Zanim przeczytacie choć jedno wymaganie — sprawdźcie, czy ta ścieżka jest Wasza. Odpowiedź nie jest pisana ręcznie: wynika z zakresu obowiązku zapisanego w modelu prawnym.
Dostawcy cyfrowi z art. 8b ust. 1 UKSC
Dostawcy usług DNS, rejestry nazw domen najwyższego poziomu (TLD), dostawcy usług chmurowych, dostawcy usługi centrum przetwarzania danych, dostawcy sieci dostarczania treści, dostawcy usług zarządzanych, dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa, dostawcy internetowych platform handlowych, dostawcy wyszukiwarek internetowych oraz dostawcy platform usług sieci społecznościowych. Dla Was rozporządzenie CIR 2024/2690 jest obowiązkiem — ta ścieżka to Wasza lista zadań.
Pozostałe podmioty kluczowe i ważne
CIR Was nie obowiązuje — art. 8b ust. 2 UKSC odsyła do przyszłych aktów wykonawczych Komisji Europejskiej dla Waszego rodzaju podmiotu. Wasz wiążący obowiązek to art. 8b ust. 2 UKSC — tę ścieżkę czytajcie jako sprawdzony wzorzec, nie jako listę wymagań audytora.
Sprawdźcie swój rodzaj podmiotu
Klasa podmiotu to nie wszystko — decyduje rodzaj podmiotu, sektor i wielkość. Kwalifikator KSC wskaże Wasz rodzaj, a wynik powie wprost, czy ten obowiązek jest w Waszym katalogu.
Ten blok wygląda tak samo na każdej ścieżce: obowiązek z UKSC pokaże tu klasy podmiotów (kluczowy / ważny / publiczny), obowiązek z CIR — dostawców cyfrowych. Dyrektywa NIS2 nie ma własnych ścieżek — pokazujemy ją niżej, jako źródło obowiązku.
Skąd ten obowiązek
Zdanie dyrektywy i akty, które je wypełniają
Dyrektywa NIS2 wiąże państwa, nie Was — dlatego nie ma osobnej ścieżki. Konkrety dopisały akty, które ją wykonują — ten, na którym jesteście, i jego krajowe odbicie.
Art. 21 ust. 2 lit. e NIS2
„Środki zarządzania ryzykiem obejmują bezpieczeństwo w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych, w tym postępowanie w przypadku podatności i ich ujawnianie."
Tyle mówi dyrektywa. Co konkretnie zrobić — mówią akty obok. Treść cytowana z modelu, nie przepisywana.
Załącznik pkt 6 CIR 2024/2690
„6.1.1. Do celów art. 21 ust. 2 lit. e) dyrektywy (UE) 2022/2555 odpowiednie podmioty określają i wdrażają procesy zarządzania ryzykiem wynikającym z nabycia usług ICT lub produktów ICT od dostawców lub usługodawców w odniesieniu do komponentów, które mają kluczowe znaczenie dla bezpieczeństwa sieci i systemów…"
Komisja Europejska rozpisała lit. e na 78 wymagań wiążących — ale tylko dla dostawców cyfrowych z art. 8b ust. 1 UKSC. To jest ścieżka, na której jesteście. Treść cytowana z modelu, nie pisana.
Ta sama litera w ustawie o KSC
Polska przeniosła tę samą literę do ustawy — tam wiąże ona podmioty w klasach z zakresu każdego z tych obowiązków, także dostawców cyfrowych.
- Katalog środków bezpieczeństwa SZBI (art. 8 ust. 1 UKSC · kluczowy i ważny)
- Środki bezpieczeństwa podmiotu publicznego (art. 8 ust. 3) (art. 8 ust. 3 UKSC · tylko ważny (sektor publiczny))
Przebieg ścieżki
Od rozporządzenia do narzędzia i szablonu
Diagram pokazuje jedną nitkę ścieżki — wymaganie 12 z 78 wiążących — w komplecie warstw. Tabela niżej rozwija pozostałe wymagania.
przepis
obowiązek
wymaganie
kontrola standardu
rozwiązanie
Diagram wygenerowany z żywego modelu IRNIS przy publikacji tej strony.
Warstwa wymagań i kontroli
Wymagania tego obowiązku i ich odpowiedniki w standardach
Każdy wiersz to jedno atomowe wymaganie — dokładnie w brzmieniu z modelu, o które zapyta audytor — z kontrolami, na które mapuje je model. Wiersze pogrupowane po charakterze wymagania.
| Wymaganie (brzmienie z modelu) | Charakter | Kontrole standardów |
|---|---|---|
| Organizacja i politykiwymagania wiążące — organizacyjne | ||
| Podmiot przed przystąpieniem do rozwoju sieci i systemu informatycznego, w tym oprogramowania, określa zasady bezpiecznego rozwoju sieci i systemów informatycznych i stosuje je zarówno przy rozwoju wewnętrznym, jak i przy zlecaniu rozwoju na zewnątrz. | organizacyjne | ISO 27001 · A.8.25 NIST CSF · PR.PS-06 |
| Zasady bezpiecznego rozwoju obejmują wszystkie fazy rozwoju, w tym specyfikację, projektowanie, opracowywanie, wdrażanie i testowanie. | organizacyjne | ISO 27001 · A.8.25 NIST CSF · PR.PS-06 |
| Podmiot określa wymogi bezpieczeństwa dotyczące środowisk rozwoju. | organizacyjne | ISO 27001 · A.8.31 |
| W przypadkach, gdy poprawka zabezpieczeń nie jest dostępna lub nie jest stosowana na podstawie udokumentowanej decyzji, podmiot wprowadza dodatkowe środki i akceptuje ryzyko rezydualne. | organizacyjne | ISO 27001 · A.8.8 NIST CSF · ID.RA-06 |
| Systemy służące do zarządzania wdrażaniem polityki bezpieczeństwa nie są wykorzystywane do innych celów. | organizacyjne | ISO 27001 · A.8.18 ISO 27001 · A.8.2 |
| Podmiot przyjmuje plan wdrożenia pełnego przejścia na protokoły komunikacyjne warstwy sieciowej najnowszej generacji w bezpieczny, odpowiedni i stopniowy sposób oraz ustanawia środki przyspieszające to przejście. | organizacyjne | NIST_SP_800_119 · 6.3 NIST_SP_800_119 · 6.8 |
| Podmiot przyjmuje plan wdrożenia uzgodnionych na szczeblu międzynarodowym i interoperacyjnych nowoczesnych standardów komunikacji elektronicznej zmniejszających podatność na zagrożenia związane z pocztą elektroniczną oraz ustanawia środki przyspieszające to wdrażanie. | organizacyjne | NIST_SP_800_177R1 · 4.4 NIST_SP_800_177R1 · 4.5 NIST_SP_800_177R1 · 4.6 |
| Procesy i procedurywymagania wiążące — proceduralne | ||
| Podmiot określa i wdraża procesy zarządzania ryzykiem wynikającym z nabycia usług ICT lub produktów ICT od dostawców lub usługodawców w odniesieniu do komponentów o kluczowym znaczeniu dla bezpieczeństwa sieci i systemów informatycznych, w oparciu o ocenę ryzyka przeprowadzoną zgodnie z pkt 2.1 załącznika do rozporządzenia 2024/2690, w całym cyklu życia tych komponentów. | proceduralne | ISO 27001 · A.5.21 NIST CSF · GV.SC-09 |
| Procesy zarządzania ryzykiem nabycia obejmują zapewnienie, aby nabywane usługi ICT lub produkty ICT spełniały określone dla nich wymogi bezpieczeństwa. | proceduralne | ISO 27001 · A.5.21 NIST CSF · GV.SC-07 |
| Procesy zarządzania ryzykiem nabycia obejmują metody walidacji zgodności świadczonych usług ICT lub dostarczanych produktów ICT z określonymi wymogami bezpieczeństwa wraz z dokumentacją wyników walidacji. | proceduralne | ISO 27001 · A.5.21 NIST CSF · GV.SC-07 |
| Podmiot dokonuje przeglądu i, w stosownych przypadkach, aktualizacji procesów zarządzania ryzykiem nabycia w zaplanowanych odstępach czasu oraz w przypadku wystąpienia poważnych incydentów. | proceduralne | ISO 27001 · 9.1 NIST CSF · ID.IM-03 |
| Podmiot przeprowadza analizę wymogów bezpieczeństwa na etapie specyfikacji i projektowania każdego projektu rozwoju lub nabycia realizowanego przez podmiot lub w jego imieniu. | proceduralne | ISO 27001 · A.8.25 ISO 27001 · A.8.26 |
| Podmiot ustanawia i wdraża procesy testowania bezpieczeństwa w cyklu rozwojowym. | proceduralne | ISO 27001 · A.8.29 |
| Podmiot odpowiednio wybiera i chroni dane dotyczące testów bezpieczeństwa oraz nimi zarządza. | proceduralne | ISO 27001 · A.8.33 |
| Podmiot dokonuje przeglądu i, w razie konieczności, aktualizacji zasad bezpiecznego rozwoju w zaplanowanych odstępach czasu. | proceduralne | ISO 27001 · A.5.1 |
| Podmiot dokonuje przeglądu i, w stosownych przypadkach, aktualizacji konfiguracji w zaplanowanych odstępach czasu lub w przypadku wystąpienia poważnych incydentów lub istotnych zmian w działalności lub poziomie ryzyka. | proceduralne | ISO 27001 · A.8.9 |
| Podmiot stosuje procedury zarządzania zmianą w celu kontrolowania zmian w sieciach i systemach informatycznych. | proceduralne | ISO 27001 · A.8.32 NIST CSF · ID.RA-07 |
| Procedury zarządzania zmianą są zgodne z ogólną polityką zarządzania zmianą podmiotu. | proceduralne | ISO 27001 · A.8.32 |
| Procedury zarządzania zmianą stosowane są w odniesieniu do wersji, modyfikacji i zmian awaryjnych wszelkiego używanego oprogramowania i sprzętu komputerowego oraz zmian konfiguracji. | proceduralne | ISO 27001 · A.8.32 ISO 27001 · A.8.9 |
| Procedury zarządzania zmianą zapewniają, aby zmiany były dokumentowane. | proceduralne | ISO 27001 · A.8.32 NIST CSF · ID.RA-07 |
| Procedury zarządzania zmianą zapewniają, aby zmiany były, w oparciu o ocenę ryzyka przeprowadzoną zgodnie z pkt 2.1 załącznika do rozporządzenia 2024/2690, testowane i oceniane przed wdrożeniem pod kątem potencjalnego wpływu. | proceduralne | ISO 27001 · A.8.32 NIST CSF · ID.RA-07 |
| Podmiot dokumentuje wynik zmiany przeprowadzonej poza regularnymi procedurami zarządzania zmianą oraz wyjaśnienie, dlaczego procedur tych nie można było zastosować. | proceduralne | ISO 27001 · A.8.32 NIST CSF · ID.RA-07 |
| Podmiot dokonuje przeglądu i, w stosownych przypadkach, aktualizacji procedur zarządzania zmianą w zaplanowanych odstępach czasu oraz w przypadku poważnych incydentów lub istotnych zmian w działalności lub poziomie ryzyka. | proceduralne | ISO 27001 · 9.1 NIST CSF · ID.IM-03 |
| Podmiot ustanawia, wdraża i stosuje politykę i procedury testowania bezpieczeństwa. | proceduralne | ISO 27001 · A.5.1 ISO 27001 · A.8.29 |
| Podmiot ustala, na podstawie oceny ryzyka przeprowadzonej zgodnie z pkt 2.1 załącznika do rozporządzenia 2024/2690, potrzebę, zakres, częstotliwość i rodzaj testów bezpieczeństwa. | proceduralne | ISO 27001 · A.8.29 ISO 27001 · 9.1 |
| Podmiot dokumentuje rodzaj, zakres, czas i wyniki testów bezpieczeństwa, w tym ocenę krytyczności i działań łagodzących w odniesieniu do każdego stwierdzonego naruszenia. | proceduralne | ISO 27001 · A.8.29 NIST CSF · ID.RA-01 |
| Podmiot dokonuje przeglądu i, w stosownych przypadkach, aktualizacji polityki testowania bezpieczeństwa w zaplanowanych odstępach czasu. | proceduralne | ISO 27001 · A.5.1 NIST CSF · GV.PO-02 |
| Podmiot określa i stosuje procedury zarządzania poprawkami zabezpieczeń spójne z procedurami zarządzania zmianą, zarządzania podatnością, zarządzania ryzykiem i innymi odpowiednimi procedurami zarządzania. | proceduralne | ISO 27001 · A.8.8 NIST CSF · PR.PS-02 |
| Podmiot należycie dokumentuje i uzasadnia powody decyzji o niestosowaniu poprawek zabezpieczeń. | proceduralne | ISO 27001 · A.8.8 NIST CSF · ID.RA-07 |
| Podmiot na bieżąco i w zrozumiały sposób dokumentuje architekturę sieci. | proceduralne | ISO 27001 · A.8.20 NIST CSF · ID.AM-03 |
| Podłączenie usługodawców dozwolone jest wyłącznie po złożeniu wniosku o autoryzację i na określony czas, np. na czas trwania prac konserwacyjnych. | proceduralne | ISO 27001 · A.5.18 ISO 27001 · A.5.19 |
| Podmiot dokonuje przeglądu i, w stosownych przypadkach, aktualizacji środków bezpieczeństwa sieci w zaplanowanych odstępach czasu oraz w przypadku poważnych incydentów lub istotnych zmian w działalności lub poziomie ryzyka. | proceduralne | ISO 27001 · 9.1 NIST CSF · ID.IM-03 |
| Podmiot dokonuje przeglądu i, w stosownych przypadkach, aktualizacji segmentacji sieci w planowanych odstępach czasu oraz w przypadku poważnych incydentów lub istotnych zmian w działalności lub ryzyku. | proceduralne | ISO 27001 · 9.1 NIST CSF · ID.IM-03 |
| Podmiot uzyskuje informacje na temat podatności technicznych w swoich sieciach i systemach informatycznych, ocenia narażenie na takie podatności oraz podejmuje odpowiednie środki w celu zarządzania nimi. | proceduralne | ISO 27001 · A.8.8 NIST CSF · ID.RA-01 |
| Podmiot monitoruje informacje na temat podatności za pośrednictwem odpowiednich kanałów, takich jak ogłoszenia CSIRT, właściwych organów i informacje dostarczane przez dostawców lub usługodawców. | proceduralne | ISO 27001 · A.8.8 NIST CSF · ID.RA-02 |
| Postępowanie podmiotu w przypadku podatności jest zgodne z jego procedurami zarządzania zmianą, zarządzania poprawkami zabezpieczeń, zarządzania ryzykiem i zarządzania incydentami. | proceduralne | ISO 27001 · A.8.8 |
| Podmiot ustanawia procedurę ujawniania podatności zgodną z obowiązującą krajową polityką skoordynowanego ujawniania podatności. | proceduralne | ISO 27001 · A.8.8 NIST CSF · ID.RA-08 |
| Podmiot opracowuje i wdraża plan łagodzenia skutków podatności. | proceduralne | ISO 27001 · A.8.8 NIST CSF · ID.RA-06 |
| Podmiot dokumentuje i uzasadnia przyczynę, dla której podatność nie wymaga środków zaradczych. | proceduralne | ISO 27001 · A.8.8 NIST CSF · ID.RA-07 |
| Podmiot dokonuje przeglądu i, w stosownych przypadkach, aktualizacji w zaplanowanych odstępach czasu kanałów, z których korzysta do monitorowania informacji o podatnościach. | proceduralne | ISO 27001 · A.8.8 |
| Umowy z dostawcamiwymagania wiążące — kontraktowe | ||
| Procesy zarządzania ryzykiem nabycia obejmują wymogi bezpieczeństwa mające zastosowanie do nabywanych usług ICT lub produktów ICT. | kontraktowe | ISO 27001 · A.5.21 NIST CSF · GV.SC-05 |
| Procesy zarządzania ryzykiem nabycia obejmują wymogi dotyczące aktualizacji zabezpieczeń w całym cyklu życia usług ICT lub produktów ICT lub ich wymiany po zakończeniu okresu wsparcia. | kontraktowe | ISO 27001 · A.5.21 NIST CSF · PR.PS-02 |
| Procesy zarządzania ryzykiem nabycia obejmują informacje opisujące elementy sprzętu i oprogramowania wykorzystywane w usługach ICT lub produktach ICT. | kontraktowe | ISO 27001 · A.5.21 NIST CSF · GV.SC-05 |
| Procesy zarządzania ryzykiem nabycia obejmują informacje opisujące wdrożone funkcje cyberbezpieczeństwa usług ICT lub produktów ICT oraz konfigurację wymaganą do ich bezpiecznego działania. | kontraktowe | ISO 27001 · A.5.21 NIST CSF · GV.SC-05 |
| Przy zlecaniu na zewnątrz rozwoju sieci i systemów informatycznych podmiot stosuje również zasady i procedury bezpieczeństwa łańcucha dostaw oraz bezpieczeństwa nabywania określone w pkt 5 i 6.1 załącznika do rozporządzenia 2024/2690. | kontraktowe | ISO 27001 · A.5.21 ISO 27001 · A.8.30 |
| Technikawymagania wiążące — techniczne | ||
| Podmiot stosuje zasady inżynierii bezpieczeństwa systemów i zasady bezpiecznego kodowania we wszystkich działaniach związanych z rozwojem systemów informatycznych, takich jak cyberbezpieczeństwo na etapie projektowania i architektura zerowego zaufania. | techniczne | ISO 27001 · A.8.27 ISO 27001 · A.8.28 NIST CSF · PR.PS-06 |
| Podmiot dokonuje sanityzacji i anonimizacji danych testowych na podstawie oceny ryzyka przeprowadzonej zgodnie z pkt 2.1 załącznika do rozporządzenia 2024/2690. | techniczne | ISO 27001 · A.8.33 |
| Podmiot podejmuje odpowiednie środki w celu ustanowienia, dokumentowania, wdrażania i monitorowania konfiguracji, w tym konfiguracji bezpieczeństwa sprzętu, oprogramowania, usług i sieci. | techniczne | ISO 27001 · A.8.9 NIST CSF · PR.PS-01 |
| Podmiot określa i zapewnia bezpieczeństwo w konfiguracjach dla sprzętu, oprogramowania, usług i sieci. | techniczne | ISO 27001 · A.8.9 NIST CSF · PR.PS-01 |
| Podmiot ustanawia i wdraża procesy i narzędzia egzekwujące określone bezpieczne konfiguracje sprzętu, oprogramowania, usług i sieci dla systemów nowo zainstalowanych oraz działających w całym ich cyklu życia. | techniczne | ISO 27001 · A.8.9 NIST CSF · PR.PS-01 |
| Podmiot przeprowadza testy bezpieczeństwa zgodnie z udokumentowaną metodyką testowania, obejmujące elementy uznane w analizie ryzyka za istotne dla bezpiecznego działania. | techniczne | ISO 27001 · A.8.29 |
| Podmiot stosuje działania łagodzące w przypadku stwierdzenia krytycznych naruszeń. | techniczne | ISO 27001 · A.8.8 NIST CSF · ID.RA-06 |
| Poprawki zabezpieczeń stosowane są w rozsądnym terminie po ich udostępnieniu. | techniczne | ISO 27001 · A.8.8 NIST CSF · PR.PS-02 |
| Poprawki zabezpieczeń testowane są przed zastosowaniem w systemach produkcyjnych. | techniczne | ISO 27001 · A.8.19 ISO 27001 · A.8.8 |
| Poprawki zabezpieczeń pochodzą z zaufanych źródeł i są sprawdzane pod kątem integralności. | techniczne | ISO 27001 · A.8.8 |
| Podmiot wprowadza odpowiednie środki w celu ochrony swoich sieci i systemów informatycznych przed cyberzagrożeniami. | techniczne | ISO 27001 · A.8.20 NIST CSF · PR.IR-01 |
| Podmiot określa i stosuje środki kontroli chroniące domeny sieci wewnętrznych przed nieuprawnionym dostępem. | techniczne | ISO 27001 · A.8.20 NIST CSF · PR.IR-01 |
| Podmiot konfiguruje mechanizmy kontroli uniemożliwiające dostęp i komunikację sieciową, które nie są wymagane do jego działania. | techniczne | ISO 27001 · A.8.20 NIST CSF · PR.IR-01 |
| Podmiot określa i stosuje kontrole zdalnego dostępu do sieci i systemów informatycznych, w tym dostępu usługodawców. | techniczne | ISO 27001 · A.8.20 ISO 27001 · A.8.21 |
| Podmiot wyraźnie zakazuje niepotrzebnych połączeń i usług lub je dezaktywuje. | techniczne | ISO 27001 · A.8.20 ISO 27001 · A.8.9 |
| Dostęp do sieci i systemów informatycznych podmiotu możliwy jest wyłącznie przez urządzenia przez niego autoryzowane. | techniczne | ISO 27001 · A.8.20 NIST CSF · PR.AA-03 |
| Komunikacja między odrębnymi systemami nawiązywana jest wyłącznie za pośrednictwem zaufanych kanałów odizolowanych od innych kanałów komunikacji za pomocą logicznego, kryptograficznego lub fizycznego oddzielenia, zapewniających niezawodną identyfikację punktów końcowych i ochronę danych kanału przed modyfikacją lub ujawnieniem. | techniczne | ISO 27001 · A.8.20 ISO 27001 · A.8.24 NIST CSF · PR.DS-02 |
| Podmiot stosuje najlepsze praktyki w zakresie bezpieczeństwa DNS oraz bezpieczeństwa routingu internetowego i higieny routingu ruchu pochodzącego z sieci i do niej kierowanego. | techniczne | ISO 27001 · A.8.20 |
| Podmiot dokonuje segmentacji systemów na sieci lub strefy zgodnie z wynikami oceny ryzyka przeprowadzonej zgodnie z pkt 2.1 załącznika do rozporządzenia 2024/2690. | techniczne | ISO 27001 · A.8.22 NIST CSF · PR.IR-01 |
| Podmiot oddziela swoje systemy i sieci od systemów i sieci osób trzecich. | techniczne | ISO 27001 · A.8.22 NIST CSF · PR.IR-01 |
| Przy segmentacji podmiot uwzględnia funkcjonalny, logiczny i fizyczny związek, w tym położenie, między wiarygodnymi systemami i usługami. | techniczne | ISO 27001 · A.8.22 |
| Podmiot udziela dostępu do sieci lub strefy na podstawie oceny jej wymogów bezpieczeństwa. | techniczne | ISO 27001 · A.8.22 |
| Systemy o kluczowym znaczeniu dla funkcjonowania podmiotu lub dla bezpieczeństwa utrzymywane są w strefach bezpieczeństwa. | techniczne | ISO 27001 · A.8.22 |
| Podmiot wdraża strefę zdemilitaryzowaną w ramach swoich sieci łączności w celu zapewnienia bezpiecznej komunikacji pochodzącej z jego sieci lub do nich kierowanej. | techniczne | ISO 27001 · A.8.22 |
| Dostęp i łączność między strefami i w ich obrębie ograniczone są do zakresu niezbędnego do działania podmiotu lub do zapewnienia bezpieczeństwa. | techniczne | ISO 27001 · A.8.22 NIST CSF · PR.IR-01 |
| Specjalna sieć zarządzania sieciami i systemami informatycznymi oddzielona jest od sieci operacyjnej podmiotu. | techniczne | ISO 27001 · A.8.20 ISO 27001 · A.8.22 |
| Kanały zarządzania siecią oddzielone są od innego ruchu sieciowego. | techniczne | ISO 27001 · A.8.20 |
| Systemy produkcji usług podmiotu oddzielone są od systemów wykorzystywanych do opracowywania i testowania, w tym do tworzenia kopii zapasowych. | techniczne | ISO 27001 · A.8.31 |
| Podmiot chroni swoje sieci i systemy informatyczne przed szkodliwym i niedozwolonym oprogramowaniem. | techniczne | ISO 27001 · A.8.7 NIST CSF · PR.PS-05 |
| Podmiot wdraża środki, które wykrywają użycie złośliwego lub nieuprawnionego oprogramowania lub mu zapobiegają. | techniczne | ISO 27001 · A.8.7 NIST CSF · DE.CM-09 NIST CSF · PR.PS-05 |
| Sieci i systemy informatyczne podmiotu wyposażone są w oprogramowanie do wykrywania i reagowania, regularnie aktualizowane zgodnie z oceną ryzyka przeprowadzoną zgodnie z pkt 2.1 załącznika do rozporządzenia 2024/2690 oraz umowami z dostawcami. | techniczne | ISO 27001 · A.8.7 NIST CSF · DE.CM-09 |
| Podmiot przeprowadza skanowanie podatności na zagrożenia i rejestruje w zaplanowanych odstępach czasu dowody potwierdzające wyniki skanowania. | techniczne | ISO 27001 · A.8.8 NIST CSF · ID.RA-01 |
| Podmiot niezwłocznie usuwa podatności zidentyfikowane jako krytyczne dla jego działalności. | techniczne | ISO 27001 · A.8.8 NIST CSF · PR.PS-02 |
| Zalecenia ENISAdoradcze — dobra praktyka ponad minimum (Technical Implementation Guidance) | ||
| Proces zakupowy podmiotu zawiera stały, dedykowany komponent cyberbezpieczeństwa, obejmujący także nabywanie wolnego i otwartego oprogramowania, a proces bezpiecznego nabywania usług, systemów i produktów ICT jest udokumentowany wraz ze wspierającymi go procedurami. | doradcze | — |
| Wymogi bezpieczeństwa dla nabywanych usług lub produktów ICT obejmują co najmniej środki wykrywania i monitorowania nieuprawnionych zmian oprogramowania i informacji oraz ochrony przed takimi zmianami. | doradcze | ISO 27001 · A.5.21 NIST CSF · ID.RA-09 |
| Umowy wsparcia dla nabywanych systemów obejmują cały cykl życia systemu i wymogi zarządzania przestarzałością, w tym datę, do której system musi być wspierany, oraz ciągłe powiadamianie. | doradcze | — |
| Dokumentacja przetargowa wymaga od dostawców i usługodawców dostarczania przetestowanych rozwiązań problemów bezpieczeństwa w technologiach nowych i schyłkowych, nieodpłatnie i niezwłocznie po ujawnieniu istotnego problemu bezpieczeństwa. | doradcze | ISO 27001 · A.5.20 NIST CSF · GV.SC-05 |
| Procesy bezpiecznego nabywania usług, systemów i produktów ICT oraz oparte na nich procedury podlegają przeglądowi co najmniej raz w roku. | doradcze | — |
| Podmiot wdraża proces bezpiecznego cyklu rozwoju oprogramowania (SSDLC). | doradcze | — |
| Rzeczywiste dane produkcyjne lub ich pochodne wykorzystywane w testach są właściwie sanityzowane lub anonimizowane (np. maskowanie lub pseudonimizacja pól, usuwanie identyfikatorów, anonimizacja nieodwracalna). | doradcze | — |
| Wewnętrzne zasady bezpiecznego rozwoju są komunikowane właściwemu personelowi wykonawców rozwoju zlecanego na zewnątrz. | doradcze | ISO 27001 · A.8.30 |
| Zasady bezpiecznego rozwoju sieci i systemów informatycznych podlegają przeglądowi co najmniej raz na dwa lata. | doradcze | — |
| Podmiot stosuje zautomatyzowane mechanizmy centralnego zarządzania ustawieniami konfiguracji oprogramowania i sprzętu, ich egzekwowania i weryfikacji, z objęciem urządzeń mobilnych i połączonych pojazdów podmiotu. | doradcze | ISO 27001 · A.8.9 |
| Uruchamianie oprogramowania podlega polityce domyślnej odmowy z zezwoleniami wyjątkowymi (deny-all, permit-by-exception), dopuszczającej wyłącznie oprogramowanie autoryzowane. | doradcze | ISO 27001 · A.8.7 NIST CSF · PR.PS-05 |
| Odstępstwa od ustalonych ustawień konfiguracji są identyfikowane, dokumentowane i zatwierdzane na podstawie zdefiniowanych wyjątków wynikających z wymagań operacyjnych. | doradcze | ISO 27001 · A.8.9 NIST CSF · ID.RA-07 |
| Podmiot stosuje zabezpieczenia wykrywające nieuprawnione zmiany zdefiniowanych ustawień konfiguracji i reagujące na te zmiany. | doradcze | ISO 27001 · A.8.9 NIST CSF · DE.CM-09 |
| Podmiot ustanawia plan zarządzania konfiguracją, obejmujący role, odpowiedzialności, procesy i procedury zarządzania konfiguracją oraz identyfikację elementów konfiguracji i zarządzanie nimi w całym cyklu życia, i chroni ten plan przed nieuprawnionym ujawnieniem i modyfikacją. | doradcze | ISO 27001 · A.8.9 |
| Dla produktów pozbawionych oficjalnych aktualizacji po zakończeniu wsparcia dostawcy podmiot wdraża wzmocnione kontrole kompensacyjne: regularne skanowanie podatności, rygorystyczne utwardzanie konfiguracji, izolację tam, gdzie to wykonalne, oraz ciągłe monitorowanie. | doradcze | ISO 27001 · A.8.19 ISO 27001 · A.8.8 NIST CSF · PR.PS-02 |
| Konfiguracje podlegają przeglądowi i, w stosownych przypadkach, aktualizacji co najmniej raz w miesiącu, z weryfikacją zastosowania poprawek, wykonania kopii zapasowych zgodnie z planem oraz działania monitoringu niezwłocznie alarmującego o krytycznych błędach serwerów, urządzeń i dysków. | doradcze | — |
| Dla każdej zmiany rejestrowane są kroki zastosowanej procedury, a zmiany podlegają przeglądowi i zatwierdzeniu zgodnie z procedurami zarządzania zmianą przed ich wdrożeniem. | doradcze | ISO 27001 · A.8.32 |
| Zmiany w sieciach i systemach informatycznych są przeprowadzane, w stosownych przypadkach, w sposób uwierzytelniony, autoryzowany i niezaprzeczalny. | doradcze | ISO 27001 · A.8.32 |
| Zmiany są wykonywane wyłącznie zatwierdzonymi narzędziami z udokumentowanym wykonaniem, a użycie narzędzi serwisowych jest ograniczone do upoważnionego personelu. | doradcze | ISO 27001 · A.8.18 |
| Regularne procedury kontroli zmian, których nie można było zastosować z powodu zmiany awaryjnej, stosuje się niezwłocznie po przeprowadzeniu zmiany awaryjnej. | doradcze | ISO 27001 · A.8.32 |
| Procedury zarządzania zmianą podlegają przeglądowi co najmniej raz na dwa lata. | doradcze | — |
| Sieci i systemy informatyczne podlegają testom bezpieczeństwa w sposób ciągły — w szczególności w środowiskach stosujących praktyki ciągłej integracji i ciągłego wdrażania — a testy regularne przeprowadza się przy uruchomieniu, po istotnych modernizacjach lub modyfikacjach oraz po pracach serwisowych. | doradcze | — |
| Dowody są rejestrowane podczas testów, a potrzeba, zakres, częstotliwość, rodzaj i wyniki testów są dokumentowane w sposób zrozumiały dla biegłej strony trzeciej. | doradcze | — |
| Polityka i procedury testowania bezpieczeństwa podlegają przeglądowi co najmniej raz na dwa lata. | doradcze | — |
| Podmiot ustanawia, w powiązaniu z inwentarzem aktywów, proces zapewniający informowanie o publikacji nowych poprawek zabezpieczeń i odpowiednie planowanie ich wdrożeń. | doradcze | ISO 27001 · A.5.9 ISO 27001 · A.8.8 |
| Poprawki zabezpieczeń są priorytetyzowane i wdrażane na podstawie ryzyka, z uwzględnieniem powagi podatności, ekspozycji dotkniętego systemu i prawdopodobieństwa wykorzystania. | doradcze | ISO 27001 · A.8.8 NIST CSF · ID.RA-05 |
| Podmiot wdraża technologie zarządzania podatnościami identyfikujące oprogramowanie pozbawione poprawek lub błędnie skonfigurowane. | doradcze | — |
| Podmiot dokumentuje rozważenie alternatywnych środków ochrony, takich jak rygorystyczne utwardzanie konfiguracji, systemy wykrywania włamań, regularne skanowanie podatności, segmentacja lub izolacja sieci tam, gdzie to wykonalne, kontrola dostępu i monitorowanie. | doradcze | — |
| Sieci bezprzewodowe podmiotu mają wdrożone bezpieczne konfiguracje. | doradcze | ISO 27001 · A.8.22 ISO 27001 · A.8.9 |
| Zdalna konserwacja sieci i systemów informatycznych jest zatwierdzana, rejestrowana i prowadzona w sposób zapobiegający nieuprawnionemu dostępowi. | doradcze | ISO 27001 · A.7.13 |
| Podmiot dokumentuje rozważenie środków zabezpieczenia komunikacji poczty elektronicznej, w tym standardów takich jak STARTTLS, DANE, DMARC, DKIM i SPF, wewnętrznego filtrowania spamu, oszustw i wirusów oraz ochrony adresów URL (przepisywanie, skanowanie, detonacja w piaskownicy). | doradcze | ISO 27001 · A.8.7 |
| Podmiot dokumentuje rozważenie dobrych praktyk bezpieczeństwa DNS: wdrożenia DNSSEC, ochronnego DNS i szyfrowania ruchu DNS wewnętrznego i zewnętrznego tam, gdzie to technicznie wykonalne, oraz dedykowanych serwerów DNS. | doradcze | — |
| Segmentacja wynikająca z oceny ryzyka jest odwzorowana w schemacie sieci, a segmenty pozostają zgodne z wynikami oceny ryzyka. | doradcze | — |
| Publicznie dostępne komponenty systemów są umieszczone w podsieciach fizycznie lub logicznie oddzielonych od wewnętrznych sieci organizacyjnych podmiotu. | doradcze | ISO 27001 · A.8.22 |
| Komunikacja jest monitorowana i kontrolowana na zewnętrznej granicy systemu oraz na kluczowych granicach wewnętrznych, z objęciem naruszeń segmentacji. | doradcze | ISO 27001 · A.8.16 ISO 27001 · A.8.22 NIST CSF · DE.CM-01 |
| Uprzywilejowane dostępy sieciowe są kierowane przez dedykowany, zarządzany interfejs na potrzeby kontroli dostępu i audytu, a dla każdej zewnętrznej usługi telekomunikacyjnej wdrożony jest zarządzany interfejs. | doradcze | ISO 27001 · A.8.20 ISO 27001 · A.8.22 |
| Zasady segmentacji sieci podlegają przeglądowi i, w razie konieczności, aktualizacji co najmniej raz w roku. | doradcze | — |
| Mechanizmy wykrywania złośliwego i nieuprawnionego oprogramowania oraz ochrony przed nim działają w punktach wejścia i wyjścia z systemu oraz na stacjach roboczych, serwerach i mobilnych urządzeniach komputerowych, obejmując złośliwy kod przenoszony pocztą elektroniczną i jej załącznikami, przez dostęp do stron internetowych, nośniki wymienne oraz przez wykorzystanie podatności systemu. | doradcze | — |
| Mechanizmy ochrony przed złośliwym kodem są skonfigurowane tak, aby działały nieprzerwanie, wykonywały regularne skany okresowe systemu i skany plików z zewnątrz w czasie rzeczywistym, generowały powiadomienia o podejrzeniu wykrycia, dezynfekowały i poddawały kwarantannie zainfekowane pliki oraz przywracały ustawienia systemu z ochroną ustawień krytycznych przed wyłączeniem lub ograniczeniem. | doradcze | — |
| Wdrożone są mechanizmy uniemożliwiające użytkownikom obchodzenie zabezpieczeń przed złośliwym i nieuprawnionym oprogramowaniem. | doradcze | ISO 27001 · A.8.7 |
| Mechanizmy ochrony przed spamem działają w punktach wejścia do systemu, takich jak stacje robocze, serwery i mobilne urządzenia komputerowe w sieci. | doradcze | ISO 27001 · A.8.7 |
| Mechanizmy ochrony przed złośliwym kodem, w tym definicje sygnatur, są aktualizowane niezwłocznie po udostępnieniu nowych wydań, zgodnie z regułami konfiguracji i procedurami zarządzania poprawkami podmiotu. | doradcze | — |
| Podmiot przyjmuje ramy oceny powagi podatności oparte na uznanych modelach (np. CVSS, EPSS, SANS), odpowiednio uzupełnione o metryki środowiskowe i metryki zagrożeń. | doradcze | ISO 27001 · A.8.8 NIST CSF · GV.RM-06 |
| Co najmniej podatności o wyższych klasyfikacjach powagi (np. krytyczne i wysokie w CVSS lub równoważne według klasyfikacji krajowego CSIRT) są usuwane bez zbędnej zwłoki. | doradcze | — |
| Podmiot wyznacza pojedynczy punkt kontaktowy i kanały komunikacji z dostawcami i usługodawcami w sprawach bezpieczeństwa sieci i informacji. | doradcze | ISO 27001 · A.5.20 NIST CSF · GV.SC-02 |
| Zidentyfikowane podatności, powiązane oceny ryzyka i plany łagodzenia są kompleksowo dokumentowane, a plany łagodzenia zawierają jednoznaczne terminy, przypisane odpowiedzialności i procedury następcze. | doradcze | — |
| Plany łagodzenia podatności oraz uzasadnienia decyzji o braku środków zaradczych podlegają przeglądowi i walidacji przez organ zarządzający odpowiedzialny za nadzór nad ryzykiem. | doradcze | ISO 27001 · 9.3 |
| Kanały monitorowania informacji o podatnościach podlegają przeglądowi co najmniej dwa razy w roku. | doradcze | — |
Komplet wymagań tego obowiązku — 126 wierszy, generowanych z modelu przy każdej publikacji. Każde mapowanie na kontrolę ma w modelu pisemne uzasadnienie i ocenę dopasowania — na stronie pokazujemy cel mapowania. Wiersz bez chipa kontroli („—") to wymaganie, dla którego model nie wskazuje kontroli standardu — dobra praktyka lub norma, której standardy nie mierzą wprost. Wersja krajowa tych przepisów (wiąże każdy podmiot w swoim zakresie): Katalog środków bezpieczeństwa SZBI, Środki bezpieczeństwa podmiotu publicznego (art. 8 ust. 3).
Kolumna „kontrole" mówi Wam, gdzie tę samą rzecz mierzy Wasz certyfikat ISO albo profil NIST — jeśli kontrolę już macie wdrożoną i udokumentowaną, ta część ścieżki jest do reużycia, nie do budowy od zera.
Warstwa rozwiązań
Czym to zrealizować — rekomendacje referencyjne
Kontrole prowadzą do 36 kategorii rozwiązań (taksonomia ECSO); model wskazuje dla nich 17 rozwiązań referencyjnych; dla 21 kategorii — żadnego, i strona mówi to wprost. Wasze własne narzędzie tej samej kategorii też domyka ścieżkę.
CISO Assistant
Narzędzie open source do prowadzenia SZBI: rejestr ryzyk, plan postępowania, dowody skuteczności środków — z gotowymi ramami ISO 27001 i NIST CSF, na które mapuje ta ścieżka.
DFIR-IRIS
Platforma open source do obsługi incydentów: sprawy, oś czasu, artefakty i zadania zespołu reagowania — operacyjny zapis tego, o co zapyta CSIRT i audytor.
GLPI
Open source ITSM i ewidencja aktywów: inwentaryzacja systemów i usług, zgłoszenia, zmiany — baza faktów dla zarządzania aktywami i ciągłością.
Greenbone Community Edition
Skaner podatności open source (Greenbone Community Edition): cykliczne skanowanie systemów i raporty podatności pod zarządzanie podatnościami.
Keycloak
Serwer tożsamości open source — realizacja polityk kontroli dostępu i zarządzania tożsamością: role, uprawnienia, MFA, federacja.
OpenBao
Open source zarządzanie sekretami i kluczami: przechowywanie haseł, certyfikatów i kluczy kryptograficznych z kontrolą dostępu i audytem.
Probo
Narzędzie open source do oceny i monitorowania dostawców: rejestr dostawców, oceny ryzyka, śledzenie zobowiązań umownych — operacyjna strona łańcucha dostaw.
Smallstep step-ca
Open source urząd certyfikacji (Smallstep step-ca): automatyczne wystawianie i odnawianie certyfikatów — PKI dla systemów i usług.
StackRox
Open source bezpieczeństwo Kubernetes: wykrywanie włamań i anomalii w kontenerach, polityki wdrożeniowe, skanowanie obrazów.
Szablon: Metodyka zarządzania ryzykiem
Autorski szablon metodyki szacowania i postępowania z ryzykiem — kryteria, skale, rejestr i cykl przeglądów pod wymagania SZBI.
Szablon: Polityka bezpieczeństwa łańcucha dostaw
Autorski szablon polityki domykający wymagania organizacyjne łańcucha dostaw — rola w łańcuchu, kryteria wyboru dostawców, blok klauzul umownych do wpięcia w umowy.
Szablon: Polityka bezpieczeństwa zasobów ludzkich
Autorski szablon polityki bezpieczeństwa zasobów ludzkich — obowiązki przed zatrudnieniem, w trakcie i po jego zakończeniu, weryfikacja, szkolenia, sankcje.
Szablon: Polityka nadrzędna bezpieczeństwa informacji
Dokument, od którego zaczyna się SZBI: ramy systemu, polityki tematyczne, role i przeglądy — autorski szablon polityki nadrzędnej bezpieczeństwa informacji.
Szablon: Procedura przyjmowania zgłoszeń podatności (CVD)
Autorski szablon procedury przyjmowania i obsługi zgłoszeń podatności (coordinated vulnerability disclosure) — kanał, terminy, komunikacja ze zgłaszającym.
Szablon: Program budowania świadomości bezpieczeństwa
Autorski szablon programu budowania świadomości bezpieczeństwa — plan szkoleń, grupy docelowe, mierniki skuteczności.
Trivy
Skaner open source podatności i błędów konfiguracji: obrazy kontenerów, zależności, infrastruktura jako kod — kontrola w cyklu wytwórczym.
Wazuh
Platforma open source SIEM z wykrywaniem włamań: zbieranie i korelacja logów, monitorowanie integralności plików, wykrywanie podatności — rdzeń monitorowania w trybie ciągłym.
Anti Spam · Anti Virus/Worm/Malware · Application Security · Content Filtering & Monitoring · Cyber Threat Intelligence · Data Leakage Prevention · Digital Signature · Firewalls / NextGen Firewalls · Hardware Security Modules (HSM) · Mobile Security / Device management · Patch Management · PC/Mobile/End Point Security · Penetration Testing / Red Teaming · Remote Access / VPN · Security Operations Center (SOC) · Social Media & Brand Monitoring · Software & Security Lifecycle Management · Static Application Security Testing (SAST) · Underground/Darkweb investigation · Unified Threat Management (UTM) · Wireless Security — bez rekomendacji w modelu
Kontrole prowadzą też do tych kategorii, ale model nie wskazuje dla nich rozwiązania referencyjnego. Wasze własne narzędzie tej kategorii domyka ścieżkę tak samo.
Uczciwie o granicach
Czego ta ścieżka nie zrobi za Was
Nie zastąpi dowodów operacyjnych
Ścieżka daje strukturę i uzasadnienia — mapę tego, co wykazać. Zapisy, decyzje, logi i podpisane dokumenty musicie wytworzyć u siebie; o oczekiwaniach audytora więcej na stronie audyt KSC/NIS2.
Chcecie przejść tę ścieżkę z przewodnikiem?
Inteca poprowadzi wdrożenie warstwa po warstwie: od wymagań przepisu, przez kontrole standardów, po narzędzia i bazę dowodową pod audyt.