System zarządzania bezpieczeństwem informacji (SZBI) — jak spełnić art. 8 ust. 1 UKSC krok po kroku
Wdrożenie systemu zarządzania bezpieczeństwem informacji zapewniającego systematyczne szacowanie ryzyka i zarządzanie nim, wdrożenie odpowiednich i proporcjonalnych do ryzyka środków technicznych i organizacyjnych oraz stosowanie środków zapobiegających i ograniczających wpływ incydentów. 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.
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.
Podmioty kluczowe i Podmioty ważne
Ten obowiązek wiąże podmioty kluczowe i podmioty ważne. Jeśli jesteście w wykazie w tej klasie, ta ścieżka jest Waszą listą zadań.
Podmioty ważne — sektor publiczny
Ten obowiązek Was nie wiąże — art. 8 ust. 3 UKSC daje Wam własny zestaw wymagań. Wasza ścieżka to Środki bezpieczeństwa podmiotu publicznego (art. 8 ust. 3).
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.
Art. 21 ust. 1 · art. 21 ust. 2 NIS2 → art. 8 ust. 1 UKSC
Dyrektywa NIS2 wiąże państwa, nie Was — dlatego nie ma osobnej ścieżki. Ma za to 2 przepisy ogólne, które Polska przeniosła do tego przepisu ustawy.
Art. 21 ust. 1 · art. 21 ust. 2 NIS2
art. 21 ust. 1 NIS2 „Wprowadzenie odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych zarządzania ryzykiem, zapewniających poziom bezpieczeństwa odpowiedni do istniejącego ryzyka"
art. 21 ust. 2 NIS2 „Środki zarządzania ryzykiem bazują na podejściu uwzględniającym wszystkie zagrożenia, mają na celu ochronę sieci i systemów informatycznych oraz środowiska fizycznego tych systemów przed incydentami i obejmują CO NAJMNIEJ elementy wyliczone w lit. a–j (norma minimum katalogu; treść poszczególnych elementów niosą obowiązki OB_NIS2_21_2_a … OB_NIS2_21_2_j)."
Model łączy ten obowiązek z 2 przepisami dyrektywy relacją „transponuje", z oceną „równoważna".
Art. 8 ust. 1 UKSC
„system zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi przez ten podmiot"; „prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu oraz zarządzanie tym ryzykiem"; „wdrożenie odpowiednich i proporcjonalnych do oszacowanego ryzyka środków technicznych i organizacyjnych"; „uwzględniających najnowszy stan wiedzy, koszty wdrożenia, wielkość podmiotu, prawdopodobieństwo wystąpienia incydentów, narażenie podmiotu na ryzyka, skutki społeczne i gospodarcze"; „stosowanie środków zapobiegających i ograniczających wpływ incydentów na bezpieczeństwo systemu informacyjnego wykorzystywanego do świadczenia usługi"; „stosowanie mechanizmów zapewniających poufność, integralność, dostępność i autentyczność danych przetwarzanych w systemie informacyjnym"; „regularne przeprowadzanie aktualizacji oprogramowania, stosownie do zaleceń producenta, z uwzględnieniem analizy wpływu aktualizacji na bezpieczeństwo świadczonej usługi oraz poziomu krytyczności poszczególnych aktualizacji"; „ochronę przed nieuprawnioną modyfikacją w systemie informacyjnym"; „niezwłoczne podejmowanie działań po dostrzeżeniu podatności lub cyberzagrożeń, w tym również czasowe ograniczenie ruchu sieciowego przychodzącego do infrastruktury podmiotu kluczowego lub podmiotu ważnego, które może skutkować zakłóceniem usług świadczonych przez ten podmiot, z uwzględnieniem konieczność minimalizacji skutków ograniczenia dostępności tych usług, z uwagi na podjęte działania"
Polska przeniosła te przepisy do ustawy — to wiersze tabeli niżej (10 wymagań wiążących). Treść cytowana z modelu, nie pisana.
Od ustawy do narzędzia i szablonu
Diagram pokazuje jedną nitkę ścieżki — wymaganie 1 z 10 wiążących — w komplecie warstw. Tabela niżej rozwija pozostałe wymagania.
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 | ||
| System zarządzania bezpieczeństwem informacji zapewnia zarządzanie oszacowanym ryzykiem wystąpienia incydentu. | organizacyjne | ISO 27001 · 6.1.3 ISO 27001 · 8.3 NIST CSF · ID.RA-06 |
| System zarządzania bezpieczeństwem informacji zapewnia wdrożenie środków technicznych i organizacyjnych odpowiednich i proporcjonalnych do oszacowanego ryzyka. | organizacyjne | ISO 27001 · 6.1.3 ISO 27001 · 8.3 NIST CSF · ID.RA-06 |
| Dobór środków technicznych i organizacyjnych uwzględnia najnowszy stan wiedzy, koszty wdrożenia, wielkość podmiotu, prawdopodobieństwo wystąpienia incydentów, narażenie podmiotu na ryzyka oraz skutki społeczne i gospodarcze. | organizacyjne | ISO 27001 · 6.1.3 NIST CSF · GV.RM-06 |
| Podmiot wdraża system zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi przez ten podmiot. | organizacyjne | ISO 27001 · 4.3 ISO 27001 · 4.4 |
| System zarządzania bezpieczeństwem informacji zapewnia stosowanie środków zapobiegających i ograniczających wpływ incydentów na bezpieczeństwo systemu informacyjnego wykorzystywanego do świadczenia usługi. | organizacyjne | NIST CSF · PR.IR-03 NIST CSF · RS.MI-01 |
| Procesy i procedurywymagania wiążące — proceduralne | ||
| System zarządzania bezpieczeństwem informacji zapewnia prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu. | proceduralne | ISO 27001 · 6.1.2 ISO 27001 · 8.2 NIST CSF · ID.RA-05 |
| Środki zapobiegające i ograniczające wpływ incydentów obejmują regularne przeprowadzanie aktualizacji oprogramowania, stosownie do zaleceń producenta, z uwzględnieniem analizy wpływu aktualizacji na bezpieczeństwo świadczonej usługi oraz poziomu krytyczności poszczególnych aktualizacji. | proceduralne | ISO 27001 · A.8.8 NIST CSF · PR.PS-02 |
| Środki zapobiegające i ograniczające wpływ incydentów obejmują niezwłoczne podejmowanie działań po dostrzeżeniu podatności lub cyberzagrożeń, w tym również czasowe ograniczenie ruchu sieciowego przychodzącego do infrastruktury podmiotu mogące skutkować zakłóceniem świadczonych usług, z uwzględnieniem konieczności minimalizacji skutków ograniczenia dostępności tych usług. | proceduralne | ISO 27001 · A.8.8 NIST CSF · ID.RA-06 |
| Technikawymagania wiążące — techniczne | ||
| Środki zapobiegające i ograniczające wpływ incydentów obejmują stosowanie mechanizmów zapewniających poufność, integralność, dostępność i autentyczność danych przetwarzanych w systemie informacyjnym. | techniczne | ISO 27001 · A.8.24 NIST CSF · PR.DS-01 NIST CSF · PR.DS-02 |
| Środki zapobiegające i ograniczające wpływ incydentów obejmują ochronę przed nieuprawnioną modyfikacją w systemie informacyjnym. | techniczne | ISO 27001 · A.8.9 NIST CSF · PR.DS-01 |
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.
Czym to zrealizować — rekomendacje referencyjne
Kontrole prowadzą do 20 kategorii rozwiązań (taksonomia ECSO); model wskazuje dla nich 16 rozwiązań referencyjnych; dla 11 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.
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.
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.
Proxmox Backup Server
Open source serwer kopii zapasowych: deduplikacja, szyfrowanie, weryfikacja kopii i odtwarzanie — techniczny fundament planów ciągłości i odtworzenia.
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: Opis CSIRT wg RFC 2350
Autorski szablon opisu zespołu reagowania wg RFC 2350 — zakres, kontakt, zasady zgłaszania i obsługi incydentów.
Szablon: Plan reagowania na incydenty i komunikacji
Autorski szablon planu reagowania na incydenty i komunikacji — klasyfikacja, eskalacja, terminy zgłoszeń, komunikaty do stron.
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.
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.
Containment support · Cyber Threat Intelligence · Data Leakage Prevention · DDoS protection · Digital Signature · Hardware Security Modules (HSM) · Patch Management · PC/Mobile/End Point Security · Penetration Testing / Red Teaming · Remote Access / VPN · Software & Security Lifecycle Management — 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.
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.
Inne obowiązki z tego samego przepisu (art. 8 ust. 1 UKSC)
Ten przepis rozpada się w modelu na osobne obowiązki — każdy z własną ścieżką. Ta strona to jeden z nich; pozostałe:
- Zbieranie informacji o zagrożeniach i podatnościach (art. 8 ust. 1 UKSC)
- Katalog środków bezpieczeństwa SZBI (art. 8 ust. 1 UKSC)
- Bezpieczna komunikacja w KSC (art. 8 ust. 1 UKSC)
- Monitorowanie w trybie ciągłym (art. 8 ust. 1 UKSC)
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.