1/55
ISO/IEC 27001 i 27002 – wymagania i kontrole bezpieczeństwa

Część 3 – Wymagania normatywne ISO/IEC 27001:2022 oraz katalog zabezpieczeń ISO/IEC 27002:2022

  • Przedmiot: Audyt bezpieczeństwa informacji (semestr 7, poziom PRK 6)
  • Temat wykładu 3: Wymagania normatywne ISO/IEC 27001:2022 oraz katalog zabezpieczeń ISO/IEC 27002:2022
  • Kluczowe pytanie: Jak audytować wymagania systemowe (klauzule 4–10) oraz zabezpieczenia z Załącznika A?
  • Rola standardów: Międzynarodowy punkt odniesienia dla budowy i oceny skuteczności Systemów Zarządzania Bezpieczeństwem Informacji
  • Forma materiałów: Część 3 materiałów dydaktycznych (wymagania systemowe i kontrole bezpieczeństwa)
Kluczowe przesłanie: Standardy ISO/IEC 27001 i ISO/IEC 27002 tworzą spójną całość – norma 27001 określa podlegające certyfikacji wymagania systemowe (klauzule 4–10) i zakres zabezpieczeń (Załącznik A), natomiast norma 27002 rozwija je w praktyczne wytyczne implementacyjne i taksonomię atrybutów.
Wykład 3 – ISO/IEC 27001 i 27002 ISO/IEC 27001:2022 WYMAGANIA SZBI Klauzule 4 – 10 (System) Załącznik A: 93 kontrole NORMA CERTYFIKACYJNA SoA ISO/IEC 27002:2022 PRZEWODNIK KONTROLI 4 Domeny zabezpieczeń 5 Atrybutów taksonomii KODEKS PRAKTYK / WYTYCZNE ARCHITEKTURA SYSTEMU ZARZĄDZANIA BEZPIECZEŃSTWEM INFORMACJI Wymagania audytowe • Deklaracja Stosowania • Katalog 93 zabezpieczeń
2/55
Spis treści części 3
Spis treści – Wykład 3 1 Geneza i struktura HLS Zharmonizowany układ 10 klauzul 2 Klauzula 4 i 5 (Kontekst, Lider) Zakres SZBI, polityka, RACI 3 Klauzula 6: Ryzyko i SoA Szacowanie, RTP i Deklaracja SoA 4 Klauzule 7 i 8 (Wsparcie i Operacje) Dokumentacja, zasoby, wdrożenie 5 Klauzule 9 i 10 (Ocena i Poprawa) Audyt wewn. 9.2, Przegląd 9.3, CAPA 6 Nowy Załącznik A (93 kontrole) 4 Kategorie zabezpieczeń 7 System 5 Atrybutów ISO 27002 Taksonomia i filtrowanie kontroli 8 Przegląd 4 Domen kontroli Organizacyjne, Ludzie, Fizyka, IT 9 11 Nowych Kontroli (2022) Chmura, Threat Intel, DLP, DevSecOps 10 Metodyka audytu i słownik Zarządcza vs techniczna, pytania
3/55
Cele uczenia się i powiązanie z sylabusem
  • Efekt W1: Student zna wymagania bezpieczeństwa informacji niejawnych i danych osobowych
  • Efekt W2: Student zna standardy: ISO 27001, ISO 27002, ISO 19011, ISO 27005, NIST CSF. Uwaga redakcyjna: wydanie 2018 (wydanie 3) normy ISO 19011 zostało wycofane 27 maja 2026 r. i zastąpione normą ISO 19011:2026 (wydanie 4, opublikowane 2026-05). Numeracja klauzul przywoływana w tym kursie odpowiada wydaniu 2018; przed wdrożeniem należy porównać ją z tekstem normy ISO 19011:2026.
  • Efekt W3: Student rozumie regulacje: RODO, KRI, NIS2/KSC
  • Efekt U1: Student potrafi opracować plan audytu ISMS
  • Efekt U2: Student identyfikuje niezgodności (NC1/NC2/NC3), obserwacje i OFI
  • Efekt U3: Student przeprowadza analizę ryzyka (risk-based audit)
  • Efekt K2: Student wykorzystuje nabytą wiedzę i umiejętności do zapewnienia właściwego poziomu bezpieczeństwa danych
  • Efekt K3: Student wykazuje postawę etyczną i profesjonalną
  • Zastosowanie praktyczne: podstawa merytoryczna do realizacji ćwiczeń laboratoryjnych (Lab 2 – Lab 5)
Matryca efektów kształcenia – Część 3 WIEDZA W2 Standardy ISO/IEC 27001 i 27002 Struktura klauzul 4-10, katalog 93 kontroli, system 5 atrybutów, powiązanie pomiędzy wymaganiami a wytycznymi przewodnika. PRAKTYKA U1, U2 Audyt Deklaracji Stosowania i kontroli technicznych Weryfikacja uzasadnień wyłączeń w SoA, badanie konfiguracji serwerów, ocena skuteczności wdrożenia 11 nowych kontroli (Lab2–Lab5). POSTAWA K2, K3 Rygor normatywny i obiektywizm audytorski Precyzyjne powiązywanie zidentyfikowanych uchybień z klauzulami normy, odróżnienie braków w dokumentacji od nieskuteczności technicznej.
4/55
Ewolucja standardu: od BS 7799 do ISO/IEC 27001:2022
  • Początki: brytyjski standard BS 7799 opracowany w 1995 r. przez British Standards Institution (BSI)
  • Przekształcenie w normy międzynarodowe: publikacja ISO/IEC 17799 (2000 r.), a następnie wydanie ISO/IEC 27001:2005
  • Rewizja 2013: wprowadzenie struktury HLS (Annex SL) i odejście od sztywnego wymogu cyklu PDCA w tekście głównym
  • Rewizja 2022 (obecna): dostosowanie do realiów chmury obliczeniowej, pracy hybrydowej oraz rozwoju zagrożeń, w tym pozyskiwanie wiedzy o zagrożeniach (threat intelligence)
  • Okres przejściowy i aktualny status: formalny 36-miesięczny okres przejściowy (IAF MD 26) upłynął 31 października 2025 r.; od 1 listopada 2025 r. certyfikacja prowadzona jest wyłącznie według normy ISO/IEC 27001:2022 (PN-EN ISO/IEC 27001:2023-08)
Rola audytora: weryfikacja dojrzałości organizacji oraz pełnego wdrożenia zaktualizowanych kontroli wydania 2022
Ewolucja standardu ISO/IEC 27001 1995 BS 7799 BSI (Wlk. Bryt.) Pierwszy standard praktyk infosec 2005 ISO 27001:2005 Cykl PDCA 133 kontrole 11 domen 2013 ISO 27001:2013 Struktura HLS 114 kontroli 11 sekcji A.5–A.15 2022 ISO 27001:2022 93 kontrole w 4 kategoriach 11 nowych kontroli Chmura, Threat Intel 5 atrybutów kontroli
5/55
Zharmonizowana struktura norm ISO (Harmonized Structure)
  • Harmonized Structure (dawniej High-Level Structure – HLS): zunifikowany format, wspólny rdzeń tekstu i standaryzowane słownictwo norm systemowych ISO
  • Układ 10 klauzul obowiązujący we wszystkich normach systemowych:
    • Klauzule 1–3: Zakres, Powołania normatywne, Terminy i definicje (klauzule wprowadzające i informacyjne)
    • Klauzula 4: Kontekst organizacji (Context of the organization)
    • Klauzula 5: Przywództwo (Leadership)
    • Klauzula 6: Planowanie (Planning)
    • Klauzula 7: Wsparcie (Support)
    • Klauzula 8: Działania operacyjne (Operation)
    • Klauzula 9: Ocena wyników (Performance evaluation)
    • Klauzula 10: Doskonalenie (Improvement)
  • Korzyść audytowa: identyczny układ w ISO 9001, ISO/IEC 27001, ISO 22301 umożliwia prowadzenie spójnego audytu zintegrowanego
Zharmonizowana struktura ISO (Harmonized Structure) KLAUZULE 1 – 3 (INFORMACYJNE): 1. Zakres • 2. Powołania • 3. Terminy i definicje WYMAGANIA SYSTEMOWE PODLEGAJĄCE AUDYTOWI (KLAUZULE 4 – 10) Klauzula 4 Kontekst org. i zakres SZBI Klauzula 5 Przywództwo Polityka i role Klauzula 6 Planowanie Ryzyko i SoA Klauzula 7 Wsparcie Zasoby i wiedza Klauzula 8 Operacje Działania w IT Klauzula 9 Ocena wyników Audyt i przegląd Klauzula 10 Doskonalenie CAPA i korekta
6/55
Klauzula 4: Kontekst organizacji (4.1 i 4.2)
  • 4.1 Zrozumienie organizacji i jej kontekstu:
    • Identyfikacja czynników zewnętrznych (prawne, technologiczne, rynkowe, kulturowe, geopolityczne) wpływających na SZBI: RODO; NIS2 / nowelizacja KSC z 23.01.2026 (Dz.U. 2026 poz. 252): wpis do wykazu do 03.10.2026, SZBI i S46 do 03.04.2027, pierwszy audyt podmiotów kluczowych do 03.04.2028; DORA (od 17.01.2025) → 27001: 5.19–5.22, 5.29–5.30, 8.15–8.16
    • Identyfikacja czynników wewnętrznych (struktura organizacyjna, kultura pracy, zasoby, cele strategiczne)
  • 4.2 Zrozumienie potrzeb i oczekiwań stron zainteresowanych:
    • Identyfikacja interesariuszy: klienci, pracownicy, akcjonariusze, dostawcy, organy nadzoru i regulatorzy (UODO, KNF) oraz krajowe i sektorowe zespoły reagowania na incydenty (CSIRT/CERT)
    • Określenie, które z oczekiwań stają się bezwzględnymi obowiązkami prawnymi lub kontraktowymi organizacji
  • Kryteria oceny audytorskiej:
    • Weryfikacja, czy analiza kontekstu nie jest dokumentem szablonowym i wiernie odzwierciedla realny profil działalności
    • Sprawdzenie powiązania kontekstu organizacji z późniejszym procesem szacowania ryzyka
    • Amd 1:2024: zmiany klimatu jako czynnik kontekstu (4.1) i oczekiwań stron (4.2)
Klauzula 4: Kontekst organizacji (4.1 i 4.2) SZBI ORGANIZACJI Klauzula 4.1-4.4 CZYNNIKI ZEWN. (4.1) • RODO; NIS2 / KSC 2026 (Dz.U. 2026 poz. 252) • Krajobraz cyberzagrożeń; DORA → 5.19–5.22, 5.29–5.30, 8.15–8.16; Amd 1:2024 (klimat 4.1/4.2) • Rynek i dostawcy chmurowi CZYNNIKI WEWN. (4.1) • Architektura IT i zasoby • Kultura bezpieczeństwa • Cele biznesowe firmy ZAINTERESOWANE STRONY I ICH WYMAGANIA (4.2) • Klienci (SLA, poufność) • UODO/KNF (Zgodność prawna) • Pracownicy Audytor weryfikuje rejestr wymagań stron trzecich oraz ich przełożenie na SZBI
7/55
Klauzula 4: Zakres SZBI i procesy systemu (4.3 i 4.4)
  • 4.3 Określenie zakresu Systemu Zarządzania Bezpieczeństwem Informacji:
    • Zakres musi być dostępny jako udokumentowana informacja (Documented Information)
    • Musi jednoznacznie określać granice fizyczne, lokalizacyjne, organizacyjne oraz teleinformatyczne (sieci, systemy, usługi w chmurze)
    • Wymóg uwzględnienia interfejsów, zależności zewnętrznych oraz usług realizowanych przez poddostawców
  • 4.4 System Zarządzania Bezpieczeństwem Informacji:
    • Obowiązek ustanowienia, wdrożenia, utrzymywania i ciągłego doskonalenia SZBI zgodnie z wymogami normy
  • Kluczowe pytania audytora:
    • Czy z zakresu nie wyłączono celowo procesów o najwyższym profilu ryzyka (nieuzasadnione zawężanie zakresu certyfikowanego systemu)?
    • Czy granice sieciowe systemu objętego zakresem są logicznie i fizycznie odseparowane od infrastruktury poza zakresem?
Klauzula 4: Zakres SZBI i granice systemu (4.3) OTOCZENIE BIZNESOWE POZA CERTYFIKACJĄ SZBI Spółki zależne, systemy legacy odizolowane, usługi zewnętrzne FORMALNY ZAKRES SZBI (SCOPE) LOKALIZACJE • HQ Warszawa • Data Center DC1 • Praca zdalna Fizyczne granice PROCESY I SYSTEMY • Platforma SaaS • Baza CRM/Klientów • Sieć korporacyjna Logiczne granice INTERFEJSY • API zewnętrzne • Łącza VPN • Dostawcy IT Styki i zależności
8/55
Klauzula 5: Zaangażowanie najwyższego kierownictwa (klauzula 5.1)
  • Zaangażowanie najwyższego kierownictwa nie może pozostać wyłącznie wewnętrzną sprawą działu IT
  • Dowody zaangażowania kierownictwa podlegające badaniu audytorskiemu:
    • Zapewnienie adekwatnych zasobów budżetowych, technologicznych i kadrowych na rozwój bezpieczeństwa
    • Włączenie celów bezpieczeństwa informacji do nadrzędnej strategii biznesowej organizacji
    • Przewodniczenie komitetom bezpieczeństwa i regularny, aktywny udział w przeglądach zarządzania
    • Systematyczne komunikowanie pracownikom wagi skutecznego zarządzania bezpieczeństwem
  • Praktyka audytowa: audytor wiodący przeprowadza bezpośredni wywiad z najwyższym kierownictwem odpowiedzialnym za bezpieczeństwo informacji
Klauzula 5: Przywództwo i zaangażowanie (5.1) NAJWYŻSZE KIEROWNICTWO (TOP MANAGEMENT) CEO CFO CTO CISO POLITYKA I CELE • Zgodność ze strategią firmy • Formalne zatwierdzenie • Komunikacja w organizacji ZASOBY SZBI • Budżet na cyberbezpieczeństwo • Etaty dla zespołu CISO • Narzędzia ochronne (SIEM, EDR) INTEGRACJA • Wbudowanie w procesy biznesowe • Nie jako „osobny byt” IT • Wspieranie kultury bezpieczeństwa PRZEGLĄD 9.3 • Osobisty udział Zarządu • Ocena skuteczności SZBI • Decyzje doskonalące i podpis
9/55
Klauzula 5: Polityka bezpieczeństwa informacji (5.2)
  • Polityka bezpieczeństwa informacji jako nadrzędny dokument strategiczny organizacji
  • Wymogi normatywne wobec polityki (klauzula 5.2):
    • Musi być odpowiednia do celów i kontekstu organizacji
    • Musi tworzyć ramy do ustanawiania celów bezpieczeństwa informacji
    • Musi zawierać formalne zobowiązanie do spełniania obowiązujących wymagań prawnych i umownych
    • Musi zawierać jednoznaczne zobowiązanie do ciągłego doskonalenia SZBI
    • Musi być udokumentowana, zakomunikowana w organizacji i udostępniona zainteresowanym stronom
  • Kluczowe pytania audytowe:
    • Kiedy polityka była ostatnio przeglądana i aktualizowana w reakcji na zmiany środowiska operacyjnego?
    • Czy losowo wybrani pracownicy podczas wywiadów potrafią wskazać, gdzie polityka się znajduje i jakie nakłada na nich obowiązki?
Klauzula 5: Architektura Polityki SZBI (5.2) POLITYKA SZBI (5.2) 1. Cel i kontekst organizacji 2. Ramy definiowania celów 3. Zobowiązanie do spełnienia wymagań prawnych i normatywnych 4. Zobowiązanie do ciągłego doskonalenia SZBI (PDCA) ZATWIERDZONO Zarząd Spółki KRYTERIA AUDYTOWE (5.2) Dostępność informacji: • Dostępna jako udokumentowana inf. Komunikacja wewn.: • Zakomunikowana w organizacji • Zrozumiana przez personel Dostępność dla stron: • Dostępna dla stron zainteresowanych (np. skrót na stronie www)
10/55
Klauzula 5: Role, odpowiedzialności i uprawnienia (5.3)
  • Wymóg klauzuli 5.3: najwyższe kierownictwo musi zapewnić, że odpowiedzialności i uprawnienia są formalnie przypisane i zakomunikowane w organizacji
  • Kluczowe role podlegające audytowi:
    • Właściciel SZBI / Pełnomocnik ds. SZBI (np. CISO – Chief Information Security Officer)
    • Właściciele aktywów informacyjnych i procesów biznesowych (Asset / Process Owners)
    • Inspektor ochrony danych (IOD / DPO)
    • Zespół reagowania na incydenty bezpieczeństwa teleinformatycznego (CSIRT / CERT)
  • Kryterium audytowe: sformalizowana macierz RACI (Responsible, Accountable, Consulted, Informed) oraz zakresy obowiązków w umowach
  • Krytyczna pułapka (konflikt interesów): niedopuszczalna kumulacja ról sprzecznych ze sobą (np. administrator IT będący jednocześnie audytorem wewnętrznym SZBI)
Klauzula 5: Macierz odpowiedzialności RACI (5.3) Zadanie / Proces SZBI Zarząd CISO IT Ops Pracownik Zatwierdzenie Polityki SZBI A R C I Szacowanie i postępowanie z ryzykiem I A R C Instalacja aktualizacji i hardening I C R I Zgłaszanie incydentu (np. phishing) I A R R Legenda: R (Responsible - wykonuje) • A (Accountable - odpowiada) • C (Consulted - doradza) • I (Informed - informowany)
11/55
Klauzula 6: Planowanie – zarządzanie ryzykiem i szansami (6.1.1)
  • Koncepcja: organizacja musi zaplanować działania odnoszące się zarówno do zagrożeń (ryzyk negatywnych), jak i do szans biznesowych
  • Cele planowania w SZBI:
    • Zapewnienie, że SZBI może osiągnąć zamierzone rezultaty biznesowe
    • Zapobieganie niepożądanym skutkom lub ich skuteczne ograniczanie
    • Osiąganie ciągłego doskonalenia systemu zarządzania
  • Dwa poziomy zarządzania ryzykiem:
    • Ryzyka dla systemu zarządzania (np. utrata kluczowych kompetencji, brak stabilności finansowej programu bezpieczeństwa)
    • Ryzyka dla aktywów informacyjnych (np. utrata poufności baz danych klientów wskutek ataku ransomware)
  • Weryfikacja audytowa: czy organizacja dostrzega szanse rozwojowe (np. bezpieczna transformacja cyfrowa) równolegle z analizą ryzyk negatywnych?
Klauzula 6: Równowaga ryzyk i szans (6.1.1) RYZYKA SZBI Zagrożenia i straty SZANSE BIZNES. Innowacja i zaufanie WYMÓG 6.1.1: OKREŚLENIE RYZYK I SZANS W KONTEKŚCIE CELÓW BIZNESOWYCH Zapewnienie, że SZBI może osiągnąć zamierzone wyniki oraz zapobiegać niepożądanym skutkom
12/55
Klauzula 6: Szacowanie ryzyka bezpieczeństwa informacji (6.1.2)
  • Wymogi normatywne wobec metodyki szacowania ryzyka (klauzula 6.1.2):
    • Ustanowienie i utrzymywanie sformalizowanych kryteriów ryzyka (kryteria akceptacji oraz kryteria oceny skutków)
    • Zapewnienie, że powtarzane szacowania ryzyka przynoszą spójne, trafne i porównywalne rezultaty
  • Elementy procesu szacowania ryzyka podlegające badaniu:
    1. Identyfikacja ryzyka: identyfikacja potencjalnej utraty poufności, integralności i dostępności dla aktywów objętych zakresem
    2. Identyfikacja właścicieli ryzyka (Risk Owners): wskazanie osób formalnie uprawnionych do zarządzania danym ryzykiem
    3. Analiza ryzyka: oszacowanie prawdopodobieństwa ziszczenia się zagrożenia oraz potencjalnych skutków biznesowych
    4. Ocena ryzyka: porównanie oszacowanych poziomów ryzyka z przyjętymi kryteriami akceptacji
Klauzula 6: Cztery etapy szacowania ryzyka (6.1.2) KROK 1 Identyfikacja Ryzyka • Aktywa info • Zagrożenia • Podatności KROK 2 Właściciele Ryzyka • Risk Owners • Odpowiedzialność • Uprawnienia KROK 3 Analiza P × S Wycena • Prawdopodobieństwo • Wpływ na C-I-A • Poziom ryzyka KROK 4 Ewaluacja vs Kryteria • Próg akceptacji • Priorytetyzacja • Wejście do RTP KLUCZ DLA AUDYTORA: POWTARZALNOŚĆ I SPÓJNOŚĆ WYNIKÓW SZACOWANIA Audytor weryfikuje czy metodyka daje porównywalne wyniki przy różnych sesjach analitycznych
13/55
Klauzula 6: Postępowanie z ryzykiem i Deklaracja Stosowania (6.1.3)
  • Wymogi postępowania z ryzykiem (Risk Treatment – klauzula 6.1.3):
    • Dobór odpowiednich opcji postępowania z ryzykiem: modyfikacja, akceptacja, unikanie lub dzielenie (transfer) ryzyka
    • Dobór zabezpieczeń niezbędnych do wdrożenia wybranej opcji postępowania z ryzykiem
    • Porównanie dobranych zabezpieczeń z katalogiem Załącznika A normy ISO/IEC 27001 (weryfikacja kompletności)
    • Opracowanie Planu Postępowania z Ryzykiem (Risk Treatment Plan – RTP) oraz uzyskanie akceptacji właścicieli ryzyka
  • Deklaracja Stosowania (Statement of Applicability – SoA):
    • Kluczowy dokument formalny SZBI stanowiący centralną oś badania certyfikacyjnego
    • Wykaz wszystkich 93 zabezpieczeń z Załącznika A z jednoznacznym określeniem: czy ma zastosowanie (Tak / Nie)
    • Uzasadnienie włączenia kontroli (wynik analizy ryzyka, wymóg prawny, zobowiązanie umowne)
    • Uzasadnienie wyłączenia kontroli (szczegółowe wyjaśnienie powodów braku zastosowania)
    • Aktualny status wdrożenia każdego zabezpieczenia
Klauzula 6: Deklaracja Stosowania – SoA (6.1.3) DEKLARACJA STOSOWANIA (STATEMENT OF APPLICABILITY - SoA) 93 KONTROLE Id Nazwa kontroli (Załącznik A) Stos. Uzasadnienie (Włączenia / Wyłączenia) Status 5.1 Polityki bezp. informacji TAK Wymóg normy, ryzyko braku reguł Wdrożone 8.28 Bezpieczne kodowanie TAK Wewnętrzny rozwój aplikacji SaaS W toku 7.11 Miejsca załadunku i rozład. NIE Brak ramp i dostaw towarów fizycznych N/D 8.12 Zapobieganie wyciekom (DLP) TAK Ryzyko eksfiltracji baz danych RODO Wdrożone ZASADA AUDYTORSKA: ŻADNA KONTROLA NIE MOŻE ZOSTAĆ POMINIĘTA Każde wyłączenie wymaga rzetelnego uzasadnienia biznesowo-technicznego. Brak uzasadnienia = NC!
14/55
Klauzula 6: Cele bezpieczeństwa i planowanie zmian (6.2 i 6.3)
  • 6.2 Cele bezpieczeństwa informacji i planowanie ich osiągnięcia:
    • Cele muszą być spójne z nadrzędną polityką, mierzalne (o ile to wykonalne), monitorowane, zakomunikowane i aktualizowane
    • Zasada SMART w formułowaniu celów audytowanych (np. „Wdrożenie MFA dla 100% użytkowników zdalnych do końca II kwartału”)
    • Plan realizacji celów: zakres działań, niezbędne zasoby, osoby odpowiedzialne, terminy zakończenia oraz metody oceny wyników
  • 6.3 Planowanie zmian (kluczowa nowość wydania 2022):
    • Wszelkie modyfikacje SZBI muszą być wprowadzane w sposób planowy, udokumentowany i ustrukturyzowany
    • Badanie wpływu zmian na integralność, spójność i skuteczność wdrożonego systemu bezpieczeństwa
Klauzula 6: Cele bezpieczeństwa SMART (6.2) S Specific Konkretny Precyzyjnie określony obszar IT M Measurable Mierzalny Wskaźnik KPI np. % załatanych podatności A Achievable Osiągalny Realny w ramach budżetu i ludzi R Relevant Istotny Spójny z Polityką SZBI i ryzykiem T Time-bound Terminowy Wyznaczona data (np. do Q3 2026) PRZYKŁAD CELU SZBI ZGODNEGO Z KLAUZULĄ 6.2: „Wdrożenie uwierzytelniania MFA dla 100% użytkowników VPN do dnia 30.06 z raportem wdrożenia”
15/55
Klauzula 7: Wsparcie – zasoby, kompetencje, świadomość, komunikacja (7.1–7.4)
  • 7.1 Zasoby: zapewnienie środków budżetowych, technologicznych i infrastrukturalnych niezbędnych do ustanowienia i utrzymania SZBI
  • 7.2 Kompetencje: weryfikacja kwalifikacji personelu wykonującego zadania mające wpływ na bezpieczeństwo (certyfikaty, szkolenia, oceny)
  • 7.3 Świadomość (Security Awareness):
    • Znajomość polityki bezpieczeństwa informacji przez pracowników wszystkich szczebli
    • Zrozumienie osobistego wkładu pracownika w skuteczność systemu ochrony informacji
    • Świadomość konsekwencji niestosowania się do obowiązujących wymagań SZBI
  • 7.4 Komunikacja: określenie procesów komunikacji wewnętrznej i zewnętrznej (co, kiedy, z kim i w jaki sposób komunikować)
  • Test audytowy świadomości: bezpośrednie wywiady ze współpracownikami z recepcji, działu kadr, księgowości oraz personelu wspierającego
Klauzula 7: Cztery filary wsparcia SZBI (7.1-7.4) 7.1 ZASOBY Finanse i IT: • Budżet cyber • Sprzęt i chmura • Licencje security Infrastruktura 7.2 KOMPETENCJE Kwalifikacje: • Certyfikaty CISSP • Audytor wiodący • Matryca wiedzy Edukacja i ocena 7.3 ŚWIADOMOŚĆ Security Awareness: • Kampanie phishing • Testy wiedzy • Znajomość polityk Czynnik ludzki 7.4 KOMUNIKACJA Przepływ info: • Co komunikować? • Kiedy i komu? • Wewnętrznie/Zewn. Kanały relacji
16/55
Klauzula 7: Udokumentowane informacje (7.5)
  • Pojęcie „udokumentowanej informacji” (Documented Information): zastąpienie w normach ISO tradycyjnych pojęć „dokument” i „zapis”
  • Wymagania dotyczące tworzenia i aktualizacji (klauzula 7.5.2):
    • Odpowiednia identyfikacja i opis (tytuł, data, autor, unikalny numer wersji)
    • Odpowiedni format i nośnik (język, format elektroniczny, nośnik fizyczny)
    • Formalny przegląd i zatwierdzenie pod kątem przydatności i adekwatności
  • Nadzór nad udokumentowanymi informacjami (klauzula 7.5.3):
    • Dostępność tam, gdzie jest potrzebna, oraz ochrona przed utratą poufności i integralności
    • Zasady dystrybucji, dostępu, wyszukiwania, bezpiecznego przechowywania i retencji
    • Nadzór nad dokumentami pochodzenia zewnętrznego (ustawy, normy, specyfikacje techniczne)
Klauzula 7: Cykl życia udokumentowanych informacji (7.5) 1 Tworzenie Id, wersja, autor 2 Przegląd Ocena merytoryczna 3 Zatwierdzenie Podpis właściciela 4 Dystrybucja Intranet, uprawnienia 5 Wycofanie Archiwum / Zniszcz. NADZÓR NAD DOKUMENTAMI (7.5.3) – CHECKLISTA AUDYTORA ✓ Dostępność i przydatność we właściwych miejscach (np. procedury awaryjne w serwerowni) ✓ Ochrona przed utratą poufności i nieuprawnioną modyfikacją (wersjonowanie i uprawnienia) ✓ Kontrola wersji: uniemożliwienie stosowania nieaktualnych formularzy i procedur przez personel
17/55
Klauzula 8: Działania operacyjne (Operation)
  • 8.1 Planowanie i sterowanie operacyjne:
    • Wdrożenie procesów niezbędnych do spełnienia wymagań bezpieczeństwa informacji oraz realizacji działań z klauzuli 6
    • Ustanowienie kryteriów dla procesów i wdrożenie kontroli procesów zgodnie z kryteriami
    • Kontrola zmian planowanych i przegląd konsekwencji zmian niezamierzonych
    • Zapewnienie nadzoru nad procesami realizowanymi przez podmioty zewnętrzne (outsourcing ICT)
  • 8.2 Szacowanie ryzyka bezpieczeństwa informacji:
    • Prowadzenie szacowania ryzyka w zaplanowanych odstępach czasu lub w przypadku wystąpienia istotnych zmian architektonicznych
  • 8.3 Postępowanie z ryzykiem bezpieczeństwa informacji:
    • Praktyczne wdrażanie Planu Postępowania z Ryzykiem (Risk Treatment Plan – RTP) w środowisku produkcyjnym
Klauzula 8: Pomost planowania i operacji (8.1) PLAN RTP (6.1.3) Planowanie działań: • Wymogi kontroli • Terminy wdrożeń • Właściciele ryzyk • Kryteria sukcesu KLAUZULA 8.1 OPERATIONAL CONTROL REALIZACJA W IT Katalog Załącznika A: • Hardening serwerów • Konfiguracja sieci • Procedury Helpdesk • Nadzór nad zmianą ISTOTA KLAUZULI 8: EGZEKUCJA KONTROLI I KONTROLA ZMIAN OPERACYJNYCH Zapewnienie dowodów, że procesy są realizowane zgodnie z przyjętymi kryteriami
18/55
Klauzula 9: Monitorowanie, pomiar, analiza i ocena (9.1)
  • Wymóg klauzuli 9.1: organizacja musi określić co, kiedy, w jaki sposób i przez kogo ma być monitorowane i mierzone
  • Kategorie metryk bezpieczeństwa podlegające badaniu audytorskiemu:
    • Metryki operacyjne: liczba wykrytych incydentów, średni czas do wykrycia (MTTD, Mean Time To Detection) i średni czas odtworzenia (MTTR, Mean Time To Recovery)
    • Metryki zgodności: odsetek stacji roboczych z aktualnymi łatkami, odsetek pracowników przeszkolonych z zakresu cyberzagrożeń
    • Metryki skuteczności zabezpieczeń: rezultaty cyklicznych próbnych odtworzeń danych z backupu, wyniki testów penetracyjnych
  • Analiza i ocena wyników: dane z pomiarów muszą być syntetyzowane, interpretowane i regularnie raportowane najwyższemu kierownictwu
  • Praktyka audytowa: weryfikacja, czy zbierane metryki prowadzą do realnych decyzji usprawniających mechanizmy ochronne
Klauzula 9: Pulpit wskaźników bezpieczeństwa (9.1) SECURITY DASHBOARD – METRYKI KLAUZULI 9.1 Otwarte podatności 3 Krytyczne CVSS>9 Czas reakcji (MTTR) 42 min (SLA: <60m) Sukces kopii zapasowych 99,8% Cel: 99,5% Trend incydentów miesięcznych vs Wyniki audytów wewnętrznych I II III IV V (Peak) VI Klauzula 9.1 wymaga: • CO ma być mierzone • KIEDY i KTO analizuje wyniki
19/55
Klauzula 9: Audyt wewnętrzny SZBI (9.2)
  • Wymóg bezwzględny klauzuli 9.2: organizacja musi prowadzić audyty wewnętrzne w zaplanowanych odstępach czasu
  • Kryteria badania procesu audytu wewnętrznego przez audytora certyfikującego:
    • Czy program audytów uwzględnia ważność procesów oraz wyniki poprzednich audytów?
    • Czy dla każdego audytu jednoznacznie określono cele, zakres oraz kryteria badania?
    • Czy zapewniono bezstronność i obiektywizm audytorów (brak audytowania własnej pracy i własnych konfiguracji)?
    • Czy wyniki audytów są terminowo raportowane właściwemu kierownictwu?
    • Czy udokumentowane informacje z programu i wyników audytów są należycie zachowywane?
  • Zależność audytowa: stwierdzenie, że audyty wewnętrzne są powierzchowne lub pozorowane, stanowi podstawę do orzeczenia dużej niezgodności (Major Nonconformity)
Klauzula 9: Wymogi audytu wewnętrznego (9.2) KLAUZULA 9.2 AUDYT WEWNĘTRZNY 1. Program audytów wewnętrznych Uwzględnia wagę procesów, zmiany w SZBI i wyniki ubiegłych audytów 2. Kryteria i zakres każdego audytu Określenie standardu odniesienia (norma, procedury, regulacje) 3. Obiektywizm i bezstronność audytorów Audytorzy NIE MOGĄ audytować własnej pracy (np. CISO nie audytuje SoA) 4. Raportowanie do kierownictwa Wyniki audytu trafiają bezpośrednio do właściwego kierownictwa Audyt wewnętrzny to dla organizacji pierwsza linia obrony przed utratą certyfikatu ISO 27001
20/55
Klauzula 9: Przegląd zarządzania (9.3)
  • Istota przeglądu (klauzula 9.3): cykliczne posiedzenie najwyższego kierownictwa poświęcone formalnej ocenie adekwatności, przydatności i skuteczności SZBI
  • Obowiązkowe dane wejściowe do przeglądu (klauzula 9.3.2 Inputs):
    • Status działań podjętych w następstwie poprzednich przeglądów zarządzania
    • Zmiany w kwestiach zewnętrznych i wewnętrznych oraz potrzebach stron zainteresowanych
    • Informacje zwrotne o wynikach: incydenty, wyniki pomiarów, ustalenia audytów wewnętrznych
    • Status szacowania ryzyka i realizacja Planu Postępowania z Ryzykiem (RTP)
    • Szanse na ciągłe doskonalenie systemu
  • Obowiązkowe dane wyjściowe (klauzula 9.3.3 Outputs): decyzje dotyczące możliwości doskonalenia oraz alokacji niezbędnych zasobów (zapisane w sformalizowanym protokole)
Klauzula 9: Przegląd zarządzania przez Zarząd (9.3) DANE WEJŚCIOWE (INPUTS) • Status działań z poprz. przeglądu • Zmiany w czynnikach zewn./wewn. • Wyniki pomiarów i wskaźniki • Wyniki audytów wewnętrznych • Informacje o incydentach • Nowe ryzyka i szanse • Rekomendacje doskonalenia POSIEDZENIE ZARZĄDU (9.3) Ocena przydatności, adekwatności i skut. WYNIKI PRZEGLĄDU (OUTPUTS) 1. Decyzje doskonalące: • Zmiany w Polityce SZBI • Nowe cele bezpieczeństwa 2. Alokacja zasobów: • Zgoda na budżet IT/Security • Dodatkowe etaty w zespole 3. Protokół z podpisem KLUCZ AUDYTORSKI: DOWODEM JEST FORMALNY PROTOKÓŁ Z DECYZJAMI ZARZĄDU Samo spotkanie bez zapisanych decyzji i przydzielonych zasobów skutkuje niezgodnością dużą (major, NC1)
21/55
Klauzula 10: Doskonalenie – ciągłe doskonalenie oraz niezgodności i działania korygujące (10.1 i 10.2)
  • 10.1 Ciągłe doskonalenie (Continual improvement): wymóg stałego zwiększania przydatności, adekwatności i skuteczności SZBI
  • 10.2 Niezgodności i działania korygujące (Nonconformity and corrective action):
    • Zareagowanie na niezgodność: podjęcie natychmiastowych działań w celu jej opanowania, skorygowania i złagodzenia skutków
    • Ocena potrzeby podjęcia działań eliminujących przyczynę źródłową (Root Cause Analysis):
      1. Przegląd i analiza zidentyfikowanej niezgodności
      2. Ustalenie przyczyn źródłowych powstania uchybienia
      3. Ustalenie, czy podobne niezgodności istnieją lub mogą wystąpić w innych obszarach
    • Wdrożenie wszelkich niezbędnych działań korygujących i weryfikacja ich skuteczności
    • Wprowadzenie trwałych modyfikacji w strukturze SZBI, jeśli okaże się to konieczne
Klauzula 10: Pętla korygująca CAPA (10.2) 1. BŁĄD Identyfikacja • Wykrycie NC • Incydent IT • Zgłoszenie wewn. Rejestracja 2. DORAŹNE Korekcja • Opanowanie • Odcięcie sieci • Blokada konta Ugaszenie 3. PRZYCZYNA Root Cause • Metoda 5 Why • Diagram Ryby • Dlaczego doszło? Źródło błędu 4. KORYGOWANIE Działanie trwałe • Zmiana reguły • Nowa polityka • Szkolenie ludzi Prewencja 5. SKUTECZNOŚĆ Weryfikacja • Czy błąd wrócił? • Reskan / Test • Zamknięcie NC Walidacja PĘTLA MUSI BYĆ ZAMKNIĘTA: SAMO USUNIĘCIE SKUTKU TO TYLKO KOREKCJA DORAŹNA Norma ISO 27001 bezwzględnie wymaga weryfikacji skuteczności działania korygującego (10.2 d)
22/55
Rewolucja wydania 2022: Nowa struktura Załącznika A
  • Wydanie 2013: 114 kontroli w 14 sekcjach Załącznika A (A.5–A.18) normy ISO/IEC 27001:2013 (układ przejęty z ISO/IEC 27002:2013, rozdziały 5–18) – struktura silosowa
  • Wydanie 2022: 93 zabezpieczenia skonsolidowane w zaledwie 4 przejrzystych kategoriach tematycznych:
    • Kategoria 5: Zabezpieczenia organizacyjne (Organizational controls) – 37 zabezpieczeń
    • Kategoria 6: Zabezpieczenia osobowe (People controls) – 8 zabezpieczeń
    • Kategoria 7: Zabezpieczenia fizyczne (Physical controls) – 14 zabezpieczeń
    • Kategoria 8: Zabezpieczenia technologiczne (Technological controls) – 34 zabezpieczenia
  • Bilans nowelizacji: 24 zabezpieczenia scalono z poprzednich kontroli, 58 zaktualizowano, a 11 dodano jako całkowicie nowe zabezpieczenia
Porównanie struktury Załącznika A: 2013 vs 2022 ISO/IEC 27001:2013 114 kontroli 11 sekcji (A.5 – A.15) Duplikacje i rozproszenie REORGANIZACJA ISO/IEC 27001:2022 93 kontrole 4 NOWE KATEGORIE 5. Org. 37 kontr. 6. Ludzie 8 kontr. 7. Fizyka 14 kontr. 8. IT 34 kontr. + 11 NOWYCH KONTROLI Połączenie zdublowanych kontroli i dostosowanie do nowoczesnych technologii chmurowych
23/55
System pięciu atrybutów zabezpieczeń w ISO/IEC 27002:2022
  • Innowacja wydania 2022: każde z 93 zabezpieczeń zostało opisane przy użyciu 5 wystandaryzowanych atrybutów:
    • 1. Typ zabezpieczenia (Control type): Prewencyjne, Detekcyjne, Korygujące
    • 2. Właściwości bezpieczeństwa informacji (Information security properties): Poufność, Integralność, Dostępność (triada CIA)
    • 3. Pojęcia cyberbezpieczeństwa (Cybersecurity concepts): Identyfikacja, Ochrona, Wykrywanie, Reagowanie, Odtwarzanie (zgodność z NIST CSF) (inspirowane NIST CSF 2.0 z 2024 r.: Govern, Identify, Protect, Detect, Respond, Recover – atrybut ISO nie jest tożsamy z CSF)
    • 4. Zdolności operacyjne (Operational capabilities): 15 zdolności operacyjnych (np. Zarządzanie tożsamością i dostępem, Bezpieczeństwo sieci, Kryptografia)
    • 5. Domeny bezpieczeństwa (Security domains): Ład korporacyjny i ekosystem, Ochrona, Obrona, Odporność
  • Zastosowanie audytowe: możliwość natychmiastowego wygenerowania widoku tabelarycznego, np. „wszystkie kontrole prewencyjne dla poufności danych osobowych”
System pięciu atrybutów kontroli w ISO/IEC 27002:2022 CONTROL TYPES Typ kontroli #Preventive (Prewencyjna) #Corrective (Korygująca) #Detective (Detekcyjna) INFOSEC PROP. Właściwości #Confidentiality (Poufność) #Integrity (Integralność) #Availability CYBER CONCEPTS Koncepcje (NIST) #Identify #Protect #Detect #Respond #Recover OPERATIONAL Zdolności oper. #Governance #Asset_mgmt #Info_protect #App_security #Identity_mgmt SEC. DOMAINS Domeny bezp. #Governance_and _ecosystem #Protection #Defense #Resilience Atrybuty pozwalają filtrować i mapować kontrole na inne standardy (np. NIST CSF, CIS Controls)
24/55
Domena 5: Zabezpieczenia organizacyjne (Część 1)
  • Zakres: 37 zabezpieczeń dotyczących ładu organizacyjnego, procedur, zarządzania zasobami i relacji zewnętrznych
  • Kluczowe kontrole ładu korporacyjnego:
    • 5.1 Polityki bezpieczeństwa informacji: hierarchia, przegląd i formalne zatwierdzanie dokumentów
    • 5.2 Role i odpowiedzialności w bezpieczeństwie: jednoznaczny podział zadań ochronnych
    • 5.3 Rozdział obowiązków (Segregation of Duties – SoD): zapobieganie sytuacjom, w których jedna osoba może dokonać nadużycia i zataić jego ślady
    • 5.4 Odpowiedzialność kierownictwa: egzekwowanie przestrzegania zasad bezpieczeństwa przez podległy personel
    • 5.5 i 5.6 Kontakty z władzami i grupami specjalistycznymi: współpraca z organami ścigania, zespołami CSIRT i forami branżowymi
    • 5.8 Bezpieczeństwo informacji w zarządzaniu projektami: uwzględnianie rygorów bezpieczeństwa od fazy koncepcyjnej
  • Praktyka badania SoD: weryfikacja, czy administrator baz danych nie posiada jednocześnie uprawnień do zatwierdzania własnych wniosków o dostęp produkcyjny
Domena 5: Zasada rozdzielenia obowiązków – SoD (5.3) 1 INICJATOR • Tworzy wniosek • Pisze kod źródłowy 2 AKCEPTANT • Weryfikacja kodu • Niezależna zgoda 3 OPERATOR • Wdrożenie prod. • Brak praw do edycji ZAKAZ ŁĄCZENIA RÓL Programista != Wdrażający Prod. Audytor weryfikuje logi systemu ticketowego i uprawnienia w repozytorium kodu CI/CD
25/55
Domena 5: Zabezpieczenia organizacyjne (Część 2)
  • Kluczowe kontrole zarządzania zasobami:
    • 5.9 Inwentaryzacja informacji i innych powiązanych aktywów: kompletność i aktualność rejestru aktywów IT
    • 5.10 Dopuszczalne użytkowanie aktywów (Acceptable Use Policy – AUP): regulamin korzystania ze sprzętu i usług firmowych
    • 5.11 Zwrot aktywów: sformalizowane procedury zdawania sprzętu, tokenów i kart dostępu przy odejściu pracownika
    • 5.12 Klasyfikacja informacji: schemat oznaczania wrażliwości (np. Publiczne, Wewnętrzne, Poufne, Ściśle poufne (Restricted)) – przypis: klauzule Ściśle tajne/Tajne zastrzeżone są dla informacji niejawnych w rozumieniu ustawy o ich ochronie
    • 5.13 Etykietowanie informacji: znakowanie dokumentów papierowych, plików cyfrowych i nagłówków poczty
    • 5.14 Przesyłanie informacji: bezpieczne kanały wymiany danych z partnerami biznesowymi
  • Badanie audytowe: próbkowanie sprzętu w biurze – zgodność oznakowania fizycznego z ewidencją w systemie CMDB / rejestrze aktywów
Domena 5: Poziomy klasyfikacji informacji (5.12) ŚCIŚLE POUFNE Tajemnica przedsiębiorstwa, klucze HSM (Restricted) Szyfrowanie AES-256, dostęp imienny dla 2-3 osób, audyt dostępu; klauzule Ściśle tajne/Tajne – tylko informacje niejawne w rozumieniu ustawy POUFNE Dane osobowe (RODO), finanse, umowy SLA Ochrona hasłem, zakaz wysyłki bez TLS, zasada Need-to-Know WEWNĘTRZNE Procedury operacyjne, struktura sieci, intranet Dostępne dla wszystkich pracowników, zakaz publikacji na zewnątrz PUBLICZNE Materiały marketingowe, cenniki publiczne, strona WWW Brak ograniczeń w poufności, wymagana dbałość o integralność treści ZARZĄDZANIE CYKLEM ŻYCIA: ZNAKOWANIE (5.13) I BEZPIECZNY TRANSFER (5.14) Brak etykiet na dokumentach poufnych lub przesyłanie ich jawnym e-mailem to standardowa niezgodność
26/55
Domena 5: Zabezpieczenia organizacyjne (Część 3)
  • Kontrola dostępu i tożsamości:
    • 5.15 Kontrola dostępu: polityka przyznawania uprawnień oparta na zasadzie potrzeby wiedzy (need to know) i minimalnych uprawnień (least privilege)
    • 5.16 Zarządzanie tożsamością: unikalna identyfikacja użytkownika i ograniczenie stosowania kont współdzielonych
    • 5.17 Informacje uwierzytelniające: bezpieczne zarządzanie hasłami, kluczami SSH i certyfikatami
    • 5.18 Prawa dostępu: procedury nadawania, cyklicznego przeglądu (rekoncyliacji) i odbierania uprawnień
  • Bezpieczeństwo w relacjach z dostawcami:
    • 5.19 Bezpieczeństwo informacji w relacjach z dostawcami: ocena ryzyka kontrahentów
    • 5.20 Uwzględnianie bezpieczeństwa w umowach z dostawcami: klauzule SLA, NDA, prawo do audytu (Right to Audit)
    • 5.21 Zarządzanie bezpieczeństwem w łańcuchu dostaw ICT: ograniczanie ryzyk związanych z dostawcami podrzędnymi
    • 5.22 Monitorowanie, przegląd i zarządzanie zmianami w usługach dostawców: audytowanie ciągłości dostaw
Domena 5: Cykl tożsamości JML i relacje z dostawcami CYKL ŻYCIA TOŻSAMOŚCI I DOSTĘPÓW (JOINER – MOVER – LEAVER) 1. JOINER (Nowy) • Wniosek HR + weryfikacja • Dostęp „least privilege” 2. MOVER (Zmiana roli) • Odbiór starych uprawnień • Nadanie nowych uprawnień 3. LEAVER (Odejście) • Blokada kont w dniu odejścia • Zwrot tokenów i laptopa BEZPIECZEŃSTWO W RELACJACH Z DOSTAWCAMI IT (5.19 – 5.22) • Umowy SLA i DPA (RODO): formalne klauzule poufności (NDA) i prawo do audytu (Right-to-Audit) • Bezpieczeństwo łańcucha dostaw (5.21): monitorowanie podatności bibliotek third-party (SBOM) • Dostęp serwisowy dostawców: wyłącznie na żądanie (Just-in-Time), przez VPN z MFA i nagrywaniem
27/55
Domena 5: Zabezpieczenia organizacyjne (Część 4)
  • Zarządzanie incydentami bezpieczeństwa informacji:
    • 5.24 Planowanie i przygotowanie zarządzania incydentami: procedury reagowania i role CSIRT
    • 5.25 Ocena zdarzeń i podejmowanie decyzji o klasyfikacji incydentu: formalne progi eskalacji
    • 5.26 Reagowanie na incydenty: izolacja zagrożenia, powstrzymanie i eliminacja skutków
    • 5.27 Wyciąganie wniosków z incydentów: analiza poincydentalna (Post-Mortem / Lessons Learned)
    • 5.28 Zbieranie materiału dowodowego: procedury informatyki śledczej i łańcuch dowodowy (Chain of Custody)
  • Ciągłość działania i odporność:
    • 5.29 Gotowość bezpieczeństwa informacji w warunkach zakłóceń: plany ciągłości działania (BCP)
    • 5.30 Gotowość ICT do ciągłości działania: odporność architektury teleinformatycznej (nowa kontrola wydania 2022)
  • Zgodność prawna i procedury operacyjne:
    • 5.31 Identyfikacja wymagań prawnych, regulacyjnych i umownych: rejestr zgodności (Compliance)
    • 5.32 Prywatność i ochrona danych osobowych: zapewnienie zgodności z prawem o ochronie danych osobowych
    • 5.33 Ochrona danych osobowych – procesy realizacji: uwzględnienie RODO w projektowaniu i rozwoju systemów
    • 5.34 Prywatność i ochrona danych osobowych w systemach IT: ograniczenie przetwarzania danych do celów określonych
    • 5.35 Niezależny przegląd bezpieczeństwa informacji: okresowe, niezależne oceny wdrożenia zabezpieczeń
    • 5.36 Zgodność z politykami i standardami bezpieczeństwa informacji: weryfikacja wewnętrzna
    • 5.37 Udokumentowane procedury operacyjne: standaryzacja instrukcji i procedur eksploatacyjnych IT
Domena 5: Cykl życia incydentu bezpieczeństwa (5.24-5.28) 1 Wykrycie • Alert SIEM/EDR • Zgłoszenie usera • Punkt kontaktowy 2 Ocena i Triaż • Zdarzenie czy NC? • Skala i krytyczność • Kwalifikacja RODO 3 Powstrzymanie • Izolacja hosta • Blokada konta • Zabezp. RAM/Dysk 4 Usunięcie • Czyszczenie kodu • Patch luki • Odtworzenie bazy 5 Wnioski • Post-Mortem • Zmiana reguł • Rejestr (5.27) KONTROLA 5.27: WYCIĄGANIE WNIOSKÓW Z INCYDENTÓW BEZPIECZEŃSTWA Audytor weryfikuje czy po incydencie zaktualizowano analizę ryzyka i zabezpieczenia techniczne
28/55
Domena 6: Zabezpieczenia osobowe (People controls)
  • Etap przed zatrudnieniem (Pre-employment):
    • 6.1 Sprawdzanie kandydatów (Screening): weryfikacja tożsamości, referencji i kwalifikacji zawodowych zgodnie z prawem pracy
    • 6.2 Warunki zatrudnienia: klauzule bezpieczeństwa informacji, zachowania poufności i odpowiedzialności w umowach
  • Etap w trakcie zatrudnienia (During employment):
    • 6.3 Świadomość, edukacja i szkolenia w zakresie bezpieczeństwa informacji: cykliczne programy podnoszenia kwalifikacji i testy phishingowe
    • 6.4 Proces dyscyplinarny: formalne procedury reagowania na celowe lub zawinione łamanie zasad ochrony danych
    • 6.6 Umowy o zachowaniu poufności (NDA): formalne zobowiązania pracowników i kontrahentów
    • 6.7 Praca zdalna (Remote working): zasady bezpieczeństwa pracy poza biurem i ochrona połączeń domowych
    • 6.8 Zgłaszanie zdarzeń bezpieczeństwa: obowiązek i kanały niezwłocznego raportowania anomalii przez personel
  • Etap zakończenia lub zmiany zatrudnienia (Termination):
    • 6.5 Odpowiedzialności po ustaniu zatrudnienia: trwała ochrona tajemnicy przedsiębiorstwa, rozliczenie ze sprzętu i odebranie uprawnień
Domena 6: Ochrona na ścieżce pracownika (6.1-6.8) PRZED ZATRUDNIENIEM Kontrola 6.1 (Screening) • Sprawdzenie referencji • Weryfikacja dyplomów • Zaświadczenie o niekaralności (jeśli dozwolone prawem) Selekcja kadr W TRAKCIE PRACY Kontrole 6.2 – 6.4 • Podpisanie NDA i regulaminu • Szkolenia awareness (6.3) • Proces dyscyplinarny (6.4) • Czyste biurko i ekran (7.7) Świadomość & Nadzór PO ROZWIĄZANIU UMOWY Kontrola 6.5 (Odejście) • Natychmiastowa blokada kont • Rozliczenie karty obiegowej • Zwrot laptopa, tokenów MFA • Trwałe zobowiązanie NDA Zero aktywnych kont KLUCZOWY TEST AUDYTORSKI: PRÓBKA ZWOLNIONYCH PRACOWNIKÓW Audytor pobiera listę osób zwolnionych w ostatnim kwartale i sprawdza w Active Directory datę wyłączenia konta
29/55
Domena 7: Zabezpieczenia fizyczne (Physical controls – Część 1)
  • Koncepcja obrony w głąb (Defense-in-Depth) w wymiarze fizycznym:
    • 7.1 Fizyczny obwód bezpieczeństwa: ogrodzenia terenu, szlabany, bramy wjazdowe, ochrona stref perymetrycznych
    • 7.2 Fizyczna kontrola wejścia: czytniki kart zbliżeniowych, zamki biometryczne, śluzy osobowe, ewidencja gości w recepcji
    • 7.3 Bezpieczeństwo biur, pomieszczeń i urządzeń: strefowanie dostępów, podział na strefy ogólne, chronione oraz strefy o szczególnym zabezpieczeniu
  • Typowe techniki badania audytorskiego:
    • Test nieautoryzowanego wejścia (tzw. tailgating / piggybacking): próba wejścia do strefy chronionej za pracownikiem posiadającym uprawnienia
    • Weryfikacja ewidencji gości: czy osoby z zewnątrz przebywają w strefach chronionych wyłącznie w asyście pracownika
    • Inspekcja fizyczna drzwi ewakuacyjnych i samozamykaczy: czy nie są blokowane odbojami lub klinami
Domena 7: Koncentryczne strefy ochrony fizycznej (7.1) STREFA 1: PERYMETR (Ogrodzenie, szlaban, brama wjazdowa) STREFA 2: RECEPCJA I KONTROLA DOSTĘPU (KD) STREFA 3: BIURA DC STREFA 4 ZASADA „DEFENCE IN DEPTH” W BEZPIECZEŃSTWIE FIZYCZNYM: • Pokonanie perymetru nie daje dostępu do biura • Pokonanie karty biurowej nie otwiera serwerowni • Serwerownia (7.4): podwójna autoryzacja (karta + biometria), CCTV 24/7 i rejestracja wejść
30/55
Domena 7: Zabezpieczenia fizyczne (Physical controls – Część 2)
  • Ochrona infrastruktury technicznej i pomieszczeń krytycznych:
    • 7.5 Ochrona przed zagrożeniami fizycznymi i środowiskowymi: wczesna detekcja dymu (VESDA), stałe urządzenia gaśnicze gazowe, sensory zalania
    • 7.6 Praca w strefach bezpiecznych: procedury bezpieczeństwa w serwerowniach, zakaz wnoszenia rejestratorów obrazu i dźwięku
    • 7.7 Czyste biurko i czysty ekran (Clear Desk and Clear Screen Policy): blokada stacji roboczych po bezczynności, szafy zamykane na klucz
    • 7.8 Umiejscowienie i ochrona urządzeń: lokalizacja szaf rack z dala od pionów wodno-kanalizacyjnych i okien
    • 7.9 Bezpieczeństwo aktywów poza terenem organizacji: ochrona laptopów i nośników w podróżach służbowych
    • 7.10 Nośniki pamięci: procedury niszczenia dysków (demagnetyzacja degausserem, niszczarki do nośników zgodne z DIN 66399: poziomy O-3 (nośniki optyczne), T-4 (taśmy magnetyczne) i H-4 (dyski twarde) oraz P-4/P-5 dla dokumentacji papierowej)
    • 7.11 Infrastruktura wspierająca i zasilanie: redundancja zasilania (UPS, agregaty prądotwórcze) oraz klimatyzacja precyzyjna
    • 7.12 Bezpieczeństwo okablowania: ochrona korytarzy kablowych sieci LAN i zasilania przed podsłuchem i uszkodzeniem mechanicznym
    • 7.13 Utrzymanie sprzętu: regularne przeglądy techniczne, konserwacja i naprawa urządzeń
    • 7.14 Bezpieczne usuwanie lub ponowne wykorzystanie sprzętu: utylizacja nośników i trwałe usuwanie danych z wycofywanych urządzeń
Domena 7: Infrastruktura techniczna serwerowni (7.6-7.8) INFRASTRUKTURA TECHNICZNA STREFY KRYTYCZNEJ (DATA CENTER) GASZENIE Kontrola 7.5 • Gaz obojętny (Inergen/Novec) • Wczesna detekcja dymu (VESDA) KLIMATYZACJA Kontrola 7.11 • Precyzyjna HVAC • Układ N+1 • Korytarze zimne i gorące ZASILANIE Kontrola 7.11 • Dwa tory zasilania • UPS centralny • Agregat prądotw. • Testy pod obciąż. UTYLIZACJA Kontrola 7.14 • Szafa depozytowa • Demagnetyzacja • Rozdrabniacz (DIN 66399) AUDYT FIZYCZNY: INSPEKCJA W TERENIE ORAZ PROTOKOŁY SERWISOWE Audytor bada fizyczne plomby, daty przeglądów butli z gazem oraz protokoły próbnego rozruchu agregatu
31/55
Domena 8: Zabezpieczenia technologiczne (Część 1 – Urządzenia końcowe i uprawnienia)
  • Kluczowe kontrole warstwy końcowej i dostępowej:
    • 8.1 Urządzenia końcowe użytkowników (Endpoint devices): centralne zarządzanie przez MDM / GPO, wymuszone szyfrowanie nośników, blokowanie portów USB
    • 8.2 Uprzywilejowane prawa dostępu (Privileged Access Management – PAM):
      • Ścisła kontrola uprawnień kont administratorskich (root, Enterprise Admin)
      • Rozdział tożsamości – zakaz używania kont administracyjnych do codziennej pracy biurowej (poczta, przeglądanie sieci)
      • Wdrożenie systemów klasy PAM: nagrywanie sesji, sejf haseł, automatyczna rotacja poświadczeń technicznych bez udziału użytkownika
    • 8.3 Ograniczenie dostępu do informacji: uprawnienia do zasobów oparte na rolach (RBAC) zgodnie z zasadą minimalnych uprawnień
    • 8.4 Dostęp do kodu źródłowego: ochrona repozytoriów, autoryzacja dostępu i audytowalność zmian (system Git)
    • 8.5 Bezpieczne uwierzytelnianie: obowiązkowe uwierzytelnianie wieloskładnikowe (MFA) dla dostępów uprzywilejowanych i zdalnych
Domena 8: Architektura PAM i stacja administratora (8.2-8.5) Admin Użytkownik Uprzywilejowany MFA BASTION PAM (8.2) 1. Wymuszone MFA (FIDO2) 2. Magazyn Haseł (Vault): Admin nie zna hasła roota! 3. Session Recording: Wideo-rejestracja poleceń Dostęp Just-in-Time (JIT) SSH/RDP PRODUKCJA Baza SQL Prod Klastry K8s Active Directory KONTROLA 8.2: PRAWA DOSTĘPU UPRZYWILEJOWANEGO POD ŚCISŁYM NADZOREM Bezpośrednie logowanie SSH/RDP na serwer produkcyjny z ominięciem bastionu to poważne uchybienie!
32/55
Domena 8: Zabezpieczenia technologiczne (Część 2 – Ochrona przed złośliwym kodem i podatności)
  • Ochrona operacyjna i zarządzanie podatnościami:
    • 8.7 Ochrona przed złośliwym oprogramowaniem (Malware protection): systemy ochrony punktów końcowych klasy EDR/XDR, analiza behawioralna, automatyczna izolacja stacji
    • 8.8 Zarządzanie podatnościami technicznymi (Technical vulnerability management):
      • Cykliczne skanowanie podatności infrastruktury sieciowej i aplikacji
      • Ocena krytyczności podatności według standardu CVSS (Common Vulnerability Scoring System)
      • Formalny proces instalacji poprawek (Patch Management): okna serwisowe, testowanie w środowiskach pre-prod
  • Praktyka badania audytorskiego:
    • Weryfikacja czasu (SLA) od publikacji krytycznej łatki przez producenta systemu do jej wdrożenia na serwerach produkcyjnych
    • Analiza raportów ze skanerów podatności (np. Tenable Nessus, Qualys, Greenbone OpenVAS) pod kątem luk nierozwiązanych
Domena 8: Lejek zarządzania podatnościami (8.8) 1. SKANOWANIE I WYKRYCIE (CVE): 1500 podatności z publicznych baz NVD 2. OCENA CVSS I KONTEKSTU: 45 krytycznych dla systemów w SZBI 3. TESTY ŁATKI W STAGING PRODUKCJA KONTROLA 8.8: ZARZĄDZANIE TECHNICZNYMI PODATNOŚCIAMI Audytor weryfikuje raporty z Nessus/Qualys, terminy instalacji łatek (SLA) i ponowne skany potwierdzające usunięcie
33/55
Domena 8: Zabezpieczenia technologiczne (Część 3 – Kopie zapasowe i redundancja)
  • Ciągłość danych i odporność infrastruktury:
    • 8.13 Tworzenie kopii zapasowych (Information backup):
      • Powszechnie stosowana praktyka branżowa reguła 3-2-1: 3 kopie danych, na 2 różnych rodzajach nośników, w tym 1 kopia przechowywana poza siedzibą (off-site / w niezależnej chmurze); reguła ta nie jest wymogiem normy
      • Niezmienność kopii (WORM / immutable backups) jako ochrona przed zaszyfrowaniem przez oprogramowanie typu ransomware
      • Szyfrowanie kopii zapasowych w spoczynku (at rest) oraz podczas przesyłania (in transit)
      • Kluczowe kryterium audytowe: udokumentowane, cykliczne testy odtwarzania danych z kopii zapasowych
    • 8.14 Redundancja urządzeń przetwarzających informacje: klastry wysokiej dostępności (High Availability), zwielokrotnione zasilacze, zapasowe łącza internetowe (BGP multi-homing)
  • Kluczowe pytanie audytora: „Kiedy dokładnie przeprowadzono ostatni udokumentowany test odtworzenia pełnej bazy danych i czy osiągnięto założone wskaźniki RTO (Recovery Time Objective) i RPO (Recovery Point Objective)?”
Domena 8: Złota reguła backupu 3-2-1 (8.13) 3 KOPIE DANYCH • 1 produkcyjna • 2 kopie zapasowe Ochrona przed utratą 2 RÓŻNE NOŚNIKI • Macierz dyskowa • Taśma LTO / NAS Odporność sprzętowa 1 POZA SIEDZIBĄ • Immutable Cloud (Tryb WORM w S3) • Anty-Ransomware NAJWAŻNIEJSZY TEST AUDYTORSKI: PRÓBNE ODTWORZENIE DANYCH (RESTORE TEST) Brak regularnych, udokumentowanych testów odtwarzania = Niezgodność z kontrolą 8.13!
34/55
Domena 8: Zabezpieczenia technologiczne (Część 4 – Logowanie i sieci)
  • Audytowalność zdarzeń i architektura bezpieczeństwa sieci:
    • 8.15 Rejestrowanie zdarzeń (Logging): logowanie prób uwierzytelniania, operacji uprzywilejowanych, zmian konfiguracji i błędów systemowych
    • 8.17 Synchronizacja zegarów: obowiązkowe stosowanie protokołu NTP dla zapewnienia spójności znaczników czasu we wszystkich logach
    • 8.20 Bezpieczeństwo sieci: mechanizmy filtrowania ruchu, zapory sieciowe nowej generacji (NGFW), systemy IPS/IDS
    • 8.21 Bezpieczeństwo usług sieciowych: bezpieczne protokoły komunikacyjne, stosowanie bezpiecznych protokołów (co do zasady TLS 1.2+/1.3, SSHv2, IPsec; wyjątki tylko z analizą ryzyka i planem migracji)
    • 8.22 Segregacja sieci: separacja stref produkcyjnych od biurowych, gościnnych (Guest Wi-Fi), sieci zarządzających (OOB) i środowisk testowych
    • 8.24 Stosowanie kryptografii: zasady doboru algorytmów, długości kluczy oraz formalne procedury zarządzania kluczami kryptograficznymi
Domena 8: Segmentacja sieci i logowanie SIEM (8.15-8.20) INTERNET FIREWALL (8.20) DMZ (Strefa Zdemilitaryzowana) Serwery Web, Reverse Proxy LAN BIUROWY (VLAN 10) Stacje robocze, drukarki SERWERY PROD (VLAN 50) Bazy danych, Active Directory SYSTEM SIEM (8.15) • Centralne Syslog TLS • Niezmienne logi (WORM) • Synchronizacja NTP (8.17) Retencja min. 12 m-cy KONTROLA 8.15 & 8.17: CENTRALNE LOGOWANIE I JEDNOLITY CZAS ZEGAROWY Zabroniony jest lokalny zapis logów na dysku admina; czas musi być synchronizowany serwerem NTP
35/55
Szczegółowa analiza 11 nowych kontroli (Wydanie 2022)
Geneza zmian: 11 nowych kontroli odzwierciedla transformację cyfrową ostatniej dekady – powszechność chmury, rozwój ataków ukierunkowanych, pracę hybrydową oraz wymogi prywatności danych.
  • Zabezpieczenia organizacyjne (Domena 5):
    • 5.7 Rozpoznawanie zagrożeń (Threat intelligence)
    • 5.23 Bezpieczeństwo informacji w korzystaniu z usług chmurowych (Information security for use of cloud services)
    • 5.30 Gotowość ICT do ciągłości działania (ICT readiness for business continuity)
  • Zabezpieczenia fizyczne (Domena 7):
    • 7.4 Monitorowanie bezpieczeństwa fizycznego (Physical security monitoring)
  • Zabezpieczenia technologiczne (Domena 8):
    • 8.9 Zarządzanie konfiguracją (Configuration management)
    • 8.10 Usuwanie informacji (Information deletion)
    • 8.11 Maskowanie danych (Data masking)
    • 8.12 Zapobieganie wyciekom danych (Data leakage prevention – DLP)
    • 8.16 Monitorowanie aktywności (Monitoring activities)
    • 8.23 Filtrowanie sieci (Web filtering)
    • 8.28 Bezpieczne kodowanie (Secure coding)
Przegląd 11 nowych kontroli w ISO/IEC 27002:2022 5.7 THREAT INTEL Rozpoznawanie zagrożeń cyber 5.23 CLOUD SEC Usługi chmurowe Shared respons. 5.30 ICT READINESS Ciągłość ICT RTO / RPO / DRC 7.4 PHYS MONITOR Monitorowanie fiz. CCTV / SSWiN 8.9 CONFIG MGMT Linie bazowe i dryf konfiguracji 8.10 DATA DELETION Trwałe usuwanie NIST / Crypto-shred 8.11 DATA MASKING Maskowanie DDM Anonimizacja RODO 8.12 DATA LEAK DLP Ochrona wycieku USB, Mail, Cloud 8.16 ACTIVITIES Monitorowanie UEBA Anomalie zachowań 8.23 WEB FILTER Filtrowanie WWW Blokada Phishing/C2 8.28 SECURE CODE Bezpieczny kod DevSecOps / SAST NOWE WYZWANIE AUDYTORA: WERYFIKACJA 11 KONTROLI W TRAKCIE MIGRACJI DO 2022 Wszystkie organizacje certyfikowane przed 2022 musiały zaimplementować te kontrole do końca 2025 r.
36/55
Nowa kontrola: 5.7 Rozpoznawanie zagrożeń (Threat intelligence)
  • Wymóg normatywny: informacje o zagrożeniach bezpieczeństwa muszą być systematycznie gromadzone, analizowane i wykorzystywane do wzmacniania ochrony
  • Trzy poziomy analizy Threat Intelligence podlegające badaniu:
    • Poziom strategiczny: trendy cyberataków, motywacje adwersarzy, profilowanie grup APT z myślą o kadrze menedżerskiej
    • Poziom taktyczny: techniki, taktyki i procedury atakujących (TTP na podstawie macierzy MITRE ATT&CK)
    • Poziom operacyjny: techniczne wskaźniki kompromitacji (IoC: skróty złośliwego oprogramowania, adresy IP serwerów C2, złośliwe domeny)
  • Integracja technologiczna: automatyczne zasilanie systemów SIEM, SOAR oraz zapór sieciowych strumieniami danych (STIX / TAXII)
  • Kryterium audytowe: czy organizacja nie tylko subskrybuje biuletyny zagrożeń, ale aktywnie przekłada je na reguły detekcyjne?
Nowa kontrola 5.7: Pętla Threat Intelligence 1. ŹRÓDŁA ZEWN. • CERT Polska / CSIRT • Platformy MISP • Feedy komercyjne • Bazy CVE / NVD 2. ANALIZA CTI • Kontekst SZBI • TTP (MITRE ATT&CK) • Wskaźniki IOC: IP, Hashe, Domeny Czy dotyczy nas? 3. ZASILENIE IT • Reguły NGFW / WAF • Sygnatury EDR • Korelacja SIEM • Filtry pocztowe 4. WYNIK BLOKADA ZAGROŻENIA Zanim dotrze do systemów SZBI CO SPRAWDZA AUDYTOR: CZY ORGANIZACJA POBIERA I WYKORZYSTUJE DANE CTI? Zapis w polityce bez dowodów w postaci reguł w SIEM lub firewallu = brak wdrożenia kontroli 5.7
37/55
Nowa kontrola: 5.23 Bezpieczeństwo informacji w chmurze
  • Wymóg normatywny: procesy nabywania, użytkowania, zarządzania i opuszczania usług chmurowych muszą być formalnie uregulowane pod kątem bezpieczeństwa
  • Model współdzielonej odpowiedzialności (Shared Responsibility Model):
    • Weryfikacja świadomości podziału odpowiedzialności w modelach IaaS, PaaS oraz SaaS
    • Zrozumienie kluczowej zasady: organizacja zlecająca pozostaje odpowiedzialna za poufność, integralność i dostępność swoich danych oraz za konfigurację i zarządzanie dostępem, niezależnie od modelu usługi
  • Kryteria oceny audytorskiej w chmurze:
    • Weryfikacja niezależnych raportów poświadczeniowych dostawcy chmury (raporty SOC 2 Type II, zaświadczenia zgodności z ISO/IEC 27017 i ISO/IEC 27018)
    • ISO/IEC 27017 (kontrole chmurowe) i 27018 (PII w chmurze publicznej) jako normatywne uzupełnienie 5.23
    • Stosowanie narzędzi klasy CSPM (Cloud Security Posture Management) do wykrywania błędów konfiguracyjnych w chmurze
    • Istnienie sformalizowanej strategii wyjścia (Exit Strategy) i procedury bezpiecznego przeniesienia danych do innego dostawcy
Nowa kontrola 5.23: Model Wspólnej Odpowiedzialności w chmurze Warstwa / Odpowiedzialność On-Prem IaaS (EC2) PaaS (RDS) SaaS (M365) Dane i tożsamość (IAM) KLIENT KLIENT KLIENT KLIENT Aplikacje i bezpieczny kod KLIENT KLIENT KLIENT Dostawca System operacyjny i łatki KLIENT KLIENT Dostawca Dostawca Hiperwizor i sieć fizyczna KLIENT Dostawca Dostawca Dostawca Fizyka serwerowni i prąd KLIENT Dostawca Dostawca Dostawca PRAWDA AUDYTORSKA: W CHMURZE ODPOWIEDZIALNOŚĆ ZA DANE NIGDY NIE PRZECHODZI NA AWS/AZURE Organizacja musi wykazać konfigurację uprawnień IAM, szyfrowanie KMS i audyt raportów SOC 2 dostawcy
38/55
Nowa kontrola: 5.30 Gotowość ICT do ciągłości działania
  • Pojęcie normatywne: ICT Readiness for Business Continuity – zapewnienie, że infrastruktura IT utrzyma wymagany poziom ciągłości w razie zakłóceń
  • Ścisłe powiązanie z normą ISO 22301 (Systemy zarządzania ciągłością działania)
  • Kluczowe wskaźniki podlegające weryfikacji audytorskiej:
    • RTO (Recovery Time Objective): dopuszczalny czas przywrócenia sprawności krytycznych usług teleinformatycznych
    • RPO (Recovery Point Objective): maksymalna akceptowalna utrata danych mierzona w jednostkach czasu
  • Dowody audytowe badane na miejscu:
    • Architektura zapasowego centrum danych (Disaster Recovery Center – DRC)
    • Protokoły z cyklicznych testów przełączania ruchu produkcyjnego na środowisko zapasowe (Failover Tests)
    • Dostępność procedur awaryjnych w wersji drukowanej (na wypadek całkowitego braku zasilania i sieci)
Nowa kontrola 5.30: Gotowość ICT i parametry RTO / RPO AWARIA (T0) RPO (Utrata danych) Ostatni backup (np. 15 min) RTO (Czas odzyskania) Wznowienie usług (np. 2 godz.) Centrum Główne (DC) Status: Offline (Awaria) FAILOVER Ośrodek Zapasowy (DRC) Status: Online (Aktywny) KONTROLA 5.30 WYMAGA TESTÓW PRZEŁĄCZENIA: PROTOKÓŁ Z TESTÓW FAILOVER Brak testów przełączenia awaryjnego w ciągu ostatnich 12 miesięcy skutkuje niezgodnością audytową
39/55
Nowa kontrola: 7.4 Monitorowanie bezpieczeństwa fizycznego
  • Wymóg normatywny: strefy bezpieczne i fizyczne obwody ochronne muszą być stale monitorowane przez systemy nadzoru
  • Elementy systemu monitorowania podlegające badaniu:
    • Telewizja przemysłowa (CCTV): pokrycie kamerami, brak martwych stref przy wejściach do serwerowni i stref chronionych
    • Systemy Sygnalizacji Włamania i Napadu (SSWiN): czujki ruchu PIR, czujki kontaktronowe w oknach i drzwiach, sensory zbicia szyby
    • Integracja z systemami alarmowymi i agencją ochrony (weryfikacja czasów dojazdu grup interwencyjnych)
  • Kwestie formalno-prawne (zgodność z RODO):
    • Prawidłowe oznakowanie stref objętych nadzorem kamer (klauzule informacyjne o monitoringu wizyjnym)
    • Uzasadniony okres retencji nagrań wideo (przepisy nie narzucają konkretnego terminu) oraz ścisła kontrola uprawnień do przeglądania zapisu CCTV
Nowa kontrola 7.4: System monitoringu fizycznego CCTV/SSWiN DETEKCJA (SSWiN) • Czujniki PIR / ruchu • Kontaktrony drzwiowe • Czujki zbicia szyby • Naruszenie strefy KAMERY CCTV (7.4) • Obraz HD / Termowizja • Brak martwych stref • Rejestrator NVR w bezpiecznej strefie Retencja: 30 dni REAKCJA 24/7 • Pulpit dyżurnego • Grupa interwencyjna • Powiadomienie CISO • Rejestr zdarzeń KLUCZOWE W KONTROLI 7.4: AUTOMATYZACJA ALARMOWANIA ORAZ OCHRONA LOGÓW CCTV Dostęp do nagrań CCTV musi być ściśle ograniczony i audytowany zgodnie z przepisami RODO
40/55
Nowa kontrola: 8.9 Zarządzanie konfiguracją (Configuration management)
  • Wymóg normatywny: konfiguracje sprzętu, oprogramowania, usług i sieci muszą być formalnie zdefiniowane, wdrożone, monitorowane i kontrolowane
  • Wzorcowe linie bazowe bezpieczeństwa (Security Baselines / Golden Images):
    • Wzorcowa, utwardzona konfiguracja systemu (Hardening wg zaleceń CIS Benchmarks lub DISA STIG)
    • Wyłączenie niepotrzebnych usług, portów, przestarzałych protokołów i domyślnych kont fabrycznych
  • Nadzór nad dryfem konfiguracji (Configuration Drift):
    • Automatyzacja zarządzania konfiguracją i infrastruktura jako kod (IaC – Ansible, Terraform, Puppet)
    • Wykrywanie nieautoryzowanych modyfikacji parametrów systemowych w czasie rzeczywistym
  • Praktyka audytowa: weryfikacja losowego serwera produkcyjnego na zgodność z zatwierdzoną specyfikacją bazową
Nowa kontrola 8.9: Zarządzanie konfiguracją i zwalczanie dryfu LINIA BAZOWA (8.9) Zatwierdzony profil: • CIS Benchmarks • Zamknięte zbędne porty • Wyłączone konto guest • Szyfrowanie dysków GITOPS Ansible / IaC SERWER PROD (DRYF) Wykryty dryf konfig.: ⚠️ Admin otworzył port 22 ⚠️ Zmieniono hasło roota Automatyczny Rollback do wzorca z repozytorium KONTROLA 8.9: ZABRONIONA JEST RĘCZNA MODYFIKACJA SERWERÓW „W LOCIE” Wszystkie zmiany konfiguracji muszą przechodzić przez repozytorium kodu infrastruktury (IaC)
41/55
Nowa kontrola: 8.10 Usuwanie informacji (Information deletion)
  • Wymóg normatywny: dane przechowywane w systemach teleinformatycznych i na nośnikach muszą być bezpiecznie i trwale usuwane, gdy nie są już potrzebne
  • Kontekst regulacyjny: realizacja prawa do bycia zapomnianym (art. 17 RODO) oraz realizacja korporacyjnych polityk retencji danych
  • Metody bezpiecznego usuwania danych w zależności od nośnika:
    • Crypto-shredding: natychmiastowe zniszczenie klucza szyfrującego dane w chmurze lub w bazach danych, uniemożliwiające ich odczyt
    • Wielokrotne nadpisywanie nośników magnetycznych: NIST SP 800-88 Rev. 2 z 2025 r. (Clear / Purge / Destroy) oraz IEEE 2883 (DoD 5220.22-M jedynie jako metoda historyczna, nieskuteczna dla SSD)
    • Fizyczne niszczenie nośników (Destroy): demagnetyzacja degausserem, mielenie mechaniczne lub utylizacja termiczna
  • Dowody audytowe: protokoły zniszczenia nośników, certyfikaty utylizacji wystawione przez wyspecjalizowane firmy zewnętrzne
Nowa kontrola 8.10: Trzy metody sanitarnego usuwania danych 1. NADPISYWANIE NIST SP 800-88 • Wielokrotne nadpisywanie • Narzędzia Blancco / DBAN • Certyfikat czyszczenia Dla dysków do ponownego użycia 2. CRYPTO-SHREDDING Niszczenie w chmurze • Dane zaszyfrowane KMS • Trwałe skasowanie klucza • Dane stają się szumem Standard w AWS / Azure 3. NISZCZENIE FIZYCZNE DIN 66399 (H-4/H-5) • Demagnetyzator (Degausser) • Zmielenie na wióry • Protokół utylizacji Dla uszkodzonych nośników DOWÓD DLA AUDYTORA: PROTOKÓŁ ZNISZCZENIA Z NUMERAMI SERYJNYMI (SN) Brak protokołu utylizacji wymienionego dysku twardego = natychmiastowa niezgodność z kontrolą 8.10!
42/55
Nowa kontrola: 8.11 Maskowanie danych (Data masking)
  • Wymóg normatywny: techniki maskowania danych powinny być stosowane zgodnie z polityką kontroli dostępu i wymogami prawa ochrony danych osobowych
  • Główne techniki maskowania danych podlegające ocenie:
    • Maskowanie statyczne (Static Data Masking): trwała, nieodwracalna modyfikacja danych produkcyjnych przed ich zasileniem do środowisk testowych i deweloperskich
    • Maskowanie dynamiczne (Dynamic Data Masking – DDM): zaciemnianie danych w czasie rzeczywistym na poziomie bazy w zależności od roli i uprawnień użytkownika (np. numer karty płatniczej: •••• •••• •••• 1234)
    • Pseudonimizacja i tokenizacja: zastąpienie danych identyfikacyjnych losowym tokenem (odwracalne wyłącznie z użyciem zabezpieczonego rejestru kluczy)
  • Typowa niezgodność audytowa: kopiowanie produkcyjnej bazy danych klientów bez żadnego maskowania do środowiska testowego programistów!
Nowa kontrola 8.11: Dynamiczne maskowanie danych (DDM) BAZA PROD (RODO) Dane jawne: • Jan Kowalski • PESEL: 85012302054 • Karta: 4532 ... 8912 • Wynagrodzenie: 18 500 KONTROLA 8.11 Dynamic Data Masking (DDM) Reguły zaciemniania ŚRODOWISKO DEV/TEST Dane zamaskowane: • J. K[UKRYTE] • PESEL: 850123XXXXX • Karta: XXXX XXXX XXXX 8912 • Wynagrodzenie: [UKRYTE] BEZWZGLĘDNY ZAKAZ AUDYTORSKI: KOPIOWANIE DANYCH PRODUKCYJNYCH DO TESTÓW Użycie nieanonimizowanej bazy klientów w stagingu to podwójna niezgodność: ISO 27001 i Art. 32 RODO
43/55
Nowa kontrola: 8.12 Zapobieganie wyciekom danych (Data leakage prevention - DLP)
  • Wymóg normatywny: środki zapobiegania wyciekom danych powinny być wdrożone dla systemów przetwarzających, przechowujących i przesyłających informacje, a wyciek takich informacji powinien być zapobiegnięty
  • Trzy stany danych objęte nadzorem systemów klasy DLP:
    • Data in Use (Endpoint DLP): blokowanie kopiowania wrażliwych plików na nośniki USB, blokada schowka, zrzutów ekranu i wydruków
    • Data in Motion (Network DLP): inspekcja ruchu wychodzącego (poczta elektroniczna, komunikatory, upload do chmur publicznych)
    • Data at Rest (Storage DLP): automatyczne skanowanie repozytoriów sieciowych, baz i dysków w poszukiwaniu niechronionych danych poufnych
  • Kryteria oceny audytorskiej: reguły klasyfikacji w systemie DLP, odsetek fałszywych alarmów (False Positives) oraz procedura powiadamiania pracowników o monitoringu
Nowa kontrola 8.12: Trzy filary ochrony przed wyciekiem (DLP) 1. ENDPOINT DLP Stacja robocza • Blokada portów USB • Zakaz zrzutów ekranu • Blokada schowka (Ctrl+C) Ochrona laptopa 2. NETWORK DLP Ruch sieciowy • Inspekcja e-maili • Skan załączników • Blokada wysyłki PESEL Brama pocztowa i Web 3. STORAGE / CLOUD Repozytoria danych • Skan dysków SharePoint • Wykrywanie haseł w plikach • Blokada publicznych linków Ochrona w chmurze BADANIE AUDYTORSKIE KONTROLI 8.12: TEST PRÓBNEJ EKSTRYKCJI DANYCH Audytor weryfikuje czy próba skopiowania pliku z fikcyjnymi numerami PESEL na pendrive generuje alert SOC
44/55
Nowa kontrola: 8.16 Monitorowanie aktywności (Monitoring activities)
  • Wymóg normatywny: sieci, systemy i aplikacje muszą być stale monitorowane pod kątem nietypowych zachowań i podejrzanych zdarzeń
  • Ewolucja od biernego logowania do aktywnej detekcji anomalii:
    • Systemy klasy SIEM (Security Information and Event Management) – centralizacja, korelacja i archiwizacja logów
    • Systemy klasy UEBA (User and Entity Behavior Analytics) – profilowanie zachowań użytkowników z wykorzystaniem uczenia maszynowego
  • Przykłady wykrywanych anomalii behawioralnych:
    • Logowanie użytkownika z Warszawy, a po kilkunastu minutach z Singapuru (tzw. zjawisko niemożliwej podróży – Impossible Travel)
    • Masowe pobieranie plików z dysku sieciowego o godzinie 03:00 w nocy przez konto z działu księgowości
    • Nietypowe próby dostępu do wrażliwych baz danych poza godzinami pracy
  • Kryterium audytowe: zdefiniowane reguły progowe i czasy reakcji dyżurnych analityków SOC na wygenerowane alerty krytyczne
Nowa kontrola 8.16: Behawioralna analityka anomalii (UEBA) PROFIL BAZOWY (NORMALNY) • Godziny pracy: 08:00 – 17:00 • Transfer danych: ~200 MB / dzień • Lokalizacja logowania: Warszawa • Używane systemy: CRM, Poczta Status: Ryzyko Niskie (0.05) UEBA 8.16 WYKRYTA ANOMALIA (ALERT SOC) 🚨 Godzina logowania: 03:15 w nocy 🚨 Transfer: 45 GB z bazy danych 🚨 IP z VPN Tor / Nietypowy kraj Automatyczna reakcja: Blokada sesji Status: ALARM KRYTYCZNY (0.98) KONTROLA 8.16 WYKRACZA POZA ZWYKŁY SYSLOG: WYMAGA DETEKCJI ODCHYLEŃ Audytor weryfikuje czy system monitorowania potrafi automatycznie wychwycić podejrzane zachowanie konta
45/55
Nowa kontrola: 8.23 Filtrowanie sieci (Web filtering)
  • Wymóg normatywny: dostęp do zewnętrznych witryn internetowych musi być zarządzany i ograniczany w celu redukcji narażenia na złośliwe oprogramowanie
  • Mechanizmy techniczne filtrowania ruchu webowego:
    • Filtrowanie na poziomie serwerów DNS (np. mechanizmy DNS sinkholing, Cisco Umbrella) – blokowanie translacji złośliwych domen
    • Bezpieczne bramy sieciowe (Secure Web Gateway – SWG) wraz z inspekcją i deszyfrowaniem ruchu HTTPS (SSL/TLS Inspection)
    • Blokowanie kategorii stron wysokiego ryzyka: malware, phishing, botnety, anonimizatory sieciowe (proxy, węzły sieci Tor), serwisy hazardowe i nielegalne
  • Praktyka audytowa: kontrolowana próba wywołania ze stacji testowej bezpiecznej domeny symulującej zagrożenie oraz weryfikacja procedury wnioskowania o wyjątki (allowlisting)
Nowa kontrola 8.23: Brama Secure Web Gateway (SWG) User Przeglądarka Żądanie HTTP/S BRAMA SWG (8.23) • Kategoryzacja stron • Odszyfrowanie SSL • Reputacja domen • Blokada malware Polityka URL SZBI DOZWOLONY • Portale biznesowe • Usługi chmurowe SaaS BLOKOWANY (EKRAN BLOKADY) • Strony phishingowe • Serwery C2 malware KONTROLA 8.23 CHRONI PRZED PRZEJĘCIEM STACJI POPRZEZ LINK W PHISHINGU Audytor weryfikuje czy próba wejścia na domenę testową (np. malware.example) jest natychmiast blokowana
46/55
Nowa kontrola: 8.28 Bezpieczne kodowanie (Secure coding)
  • Wymóg normatywny: formalne zasady bezpiecznego kodowania muszą być zdefiniowane i stosowane przy wytwarzaniu oprogramowania
  • Kluczowe filary bezpiecznego cyklu wytwórczego oprogramowania (SSDLC):
    • Standardy i wytyczne bezpiecznego kodowania (np. wytyczne OWASP Secure Coding Practices, standardy CERT C/C++)
    • Ochrona przed typowymi podatnościami (OWASP Top 10: SQL Injection, XSS, SSRF, Broken Access Control)
    • Narzędzia automatycznej analizy w potokach CI/CD:
      • SAST (Static Application Security Testing) – statyczna analiza kodu źródłowego
      • DAST (Dynamic Application Security Testing) – dynamiczne testowanie uruchomionej aplikacji z zewnątrz
      • SCA (Software Composition Analysis) – wykrywanie znanych podatności w zewnętrznych komponentach i bibliotekach open source
    • Zarządzanie sekretami: bezwzględny zakaz wpisywania haseł, kluczy kryptograficznych i tokenów API do kodu źródłowego (Hardcoded Secrets)
Nowa kontrola 8.28: Potok DevSecOps i bezpieczeństwo kodu 1. KOD (IDE) • Lintery bezp. • Wzorce OWASP • Zakaz hardcod. haseł i kluczy 2. SAST SCAN • SonarQube • Analiza statyczna • SQLi / XSS Quality Gate 3. SCA (SBOM) • Snyk / Trivy • Zależności npm • Podatne biblioteki Łańcuch dostaw 4. DAST SCAN • OWASP ZAP • Test dynamiczny • Atak na API Środowisko test 5. RELEASE PRODUKCJA • Podpisany artefakt • Blokada wdrożenia przy błędach SAST KONTROLA 8.28 WYMAGA FORMALNYCH ZASAD KODOWANIA I AUTOMATYCZNYCH BRAMEK Audytor sprawdza konfigurację repozytorium (branch protection rules) i blokady pull requestów
47/55
Metodyka audytu wymagań zarządczych (Klauzule 4-10)
  • Charakterystyka audytu systemowego (zarządczego):
    • Badanie ukierunkowane na ład organizacyjny, przepływ decyzji, architekturę procesową i rozliczalność
    • Główne metody: wywiady z kadrą menedżerską, przegląd dokumentacji polityk, protokołów i rejestrów ryzyka
  • Kluczowe pytania audytora wymagań zarządczych:
    • „Jakie jest formalne uzasadnienie biznesowe dla podjętej decyzji?”
    • „Kto personalnie zatwierdził ten rejestr ryzyk i plan postępowania z ryzykiem?”
    • „W jaki sposób zarząd monitoruje, czy wyznaczone cele bezpieczeństwa są osiągane?”
  • Ocena zgodności: zero-jedynkowa (0/1) w odniesieniu do wymagań normy; w oryginale normy „shall” oznacza wymóg, a „should” – zalecenie
Metodyka audytu wymagań zarządczych (Klauzule 4-10) KROK 1: Wywiad z Najwyższym Kierownictwem (5.1, 5.2, 9.3) Audyt zarządczy KROK 2: Weryfikacja Kontekstu i Zakresu SZBI (4.1 – 4.4) Granice systemu KROK 3: Badanie Metodyki i Rejestru Ryzyk (6.1.1, 6.1.2) Serce SZBI KROK 4: Weryfikacja Planu RTP i Spójności SoA (6.1.3) Most do kontroli KROK 5: Przegląd Audytów Wewnętrznych i CAPA (9.2, 10.2) Doskonalenie SPECYFIKA AUDYTU ZARZĄDZEGO: GŁÓWNYM NARZĘDZIEM JEST POGŁĘBIONY WYWIAD Audytor weryfikuje świadomość i zrozumienie celów przez Zarząd, a nie tylko istnienie podpisanych kartek
48/55
Metodyka audytu kontroli technicznych (Załącznik A)
  • Charakterystyka audytu kontroli technicznych:
    • Badanie skoncentrowane na parametrach konfiguracyjnych, urządzeniach sieciowych, serwerach, bazach danych i stacjach roboczych
    • Główne metody: bezpośrednia inspekcja fizyczna, próbkowanie konfiguracji z konsoli, skrypty audytowe tylko do odczytu, demonstracja działania w praktyce
  • Maksyma dowodowa audytora technicznego: „trust, but verify” (ufaj, ale weryfikuj konfigurację w terenie)
  • Przykłady twardej weryfikacji technicznej:
    • Zamiast pytać: „Czy szyfrujecie dyski laptopów?”, zażądaj wygenerowania raportu statusu szyfrowania (BitLocker / FileVault) z centralnej konsoli MDM
    • Zamiast pytać: „Czy wymuszacie MFA?”, zażądaj prezentacji logów logowania administratora w usłudze tożsamości (np. Microsoft Entra ID / Okta)
Metodyka audytu kontroli technicznych Załącznika A POLITYKA I DEKLARACJA Zapis w procedurze: 'Hasła użytkowników wygasają co 90 dni i mają min. 14 znaków. MFA jest bezwzględnie wymagane dla wszystkich połączeń VPN.' Deklaracja w SoA: WDROŻONE VS POWERSHELL / ACTIVE DIRECTORY PS> Get-ADDefaultDomainPasswordPolicy MinPasswordLength : 8 MaxPasswordAge : 00:00:00 (Nigdy) PS> Get-MgAuditLogSignIn | ft User,App jnowak, mkowal: brak MFA w logu CA WYNIK: NIEZGODNOŚĆ (NC) ZASADA PRAWDY MATERIALNEJ: PAPIER PRZYJMIE WSZYSTKO, KONSOLA POKAŻE PRAWDĘ Audytor techniczny zawsze żąda zrzutu ekranu lub polecenia w konsoli potwierdzającego stan faktyczny
49/55
Powiązanie SoA z analizą ryzyka i audytem kontroli
  • Logiczny łańcuch audytowy:
    1. Identyfikacja i szacowanie ryzyka wykazuje niedopuszczalne ryzyko wycieku danych z urządzeń przenośnych
    2. W Planie Postępowania z Ryzykiem (RTP) zaplanowano wdrożenie szyfrowania dysków oraz systemu centralnego zarządzania MDM
    3. W Deklaracji Stosowania (SoA) kontrola 8.1 (Urządzenia końcowe) zostaje oznaczona jako: „Zastosowano” wraz z uzasadnieniem merytorycznym („Wymóg wynikający z analizy ryzyka”)
    4. Audytor weryfikuje zapis w SoA i przechodzi do badania terenowego kontroli 8.1: bada losową próbkę 20 urządzeń służbowych pod kątem aktywnego szyfrowania i zdalnego kasowania danych
  • Spójność systemu: jakakolwiek sprzeczność pomiędzy rejestrem ryzyk, SoA a stanem faktycznym stanowi bezpośrednią przesłankę do orzeczenia niezgodności!
Łańcuch powiązań audytowych: Ryzyko – SoA – Dowód 1. REJESTR RYZYK Zidentyfikowane ryzyko: • Zagrożenie: Ransomware • Wpływ: Utrata danych • Poziom ryzyka: Wysoki RTP: Wdrożenie 8.13 2. DEKLARACJA SoA Kontrola 8.13 (Backup): • Wybór: TAK (Włączona) • Uzasadnienie: Ochrona przed skutkami ransomware Status: WDROŻONA 3. BADANIE PRÓBKI Dowód audytowy: • Logi Veeam z wczoraj • Niezmienne repozytorium • Raport z testu restore POTWIERDZENIE (OK) JEŚLI ŁAŃCUCH JEST PRZERWANY W KTÓRYMKOLWIEK MIEJSCU, AUDYTOR IDENTYFIKUJE UCHYBIENIE Brak kontroli w SoA mimo ryzyka = NC! Kontrola w SoA bez dowodów wdrożenia = NC!
50/55
Typowe niezgodności w audytach ISO/IEC 27001
  • Najczęstsze niezgodności w warstwie wymagań systemowych (klauzule 4–10):
    1. Fikcyjne lub powierzchowne audyty wewnętrzne nieobejmujące wszystkich procesów (naruszenie klauzuli 9.2)
    2. Brak dowodów realizacji decyzji podjętych podczas przeglądów zarządzania (naruszenie klauzuli 9.3)
    3. Brak aktualizacji rejestru ryzyk po istotnych zmianach w infrastrukturze lub organizacji (naruszenie klauzuli 6.1.2)
    4. Niemierzalne lub nieaktualizowane cele bezpieczeństwa informacji (naruszenie klauzuli 6.2)
  • Najczęstsze niezgodności w zabezpieczeniach operacyjnych (Załącznik A):
    1. Nieodebrane uprawnienia dostępowe byłych pracowników (naruszenie kontroli 5.18 oraz 6.5)
    2. Brak regularnych, udokumentowanych testów odtwarzania kopii zapasowych (naruszenie kontroli 8.13)
    3. Niezabezpieczone konta z uprawnieniami uprzywilejowanymi i brak MFA (naruszenie kontroli 8.2 i 8.5)
    4. Brak nadzoru nad terminową instalacją poprawek krytycznych (naruszenie kontroli 8.8)
    5. Brak sformalizowanych linii bazowych konfiguracji i procedur nadzoru nad dryfem (naruszenie kontroli 8.9)
Rozkład ilustracyjny niezgodności w audytach ISO/IEC 27001 Nadzór nad dostawcami (5.19): 28% (Brak NDA/SLA) Błędy w SoA / Wyłączenia (6.1.3): 24% (Brak uzasadnień) Kopie zapasowe (8.13): 20% (Brak testów restore) Zarządzanie dostępem (5.16): 16% (Konta zwolnionych) Przegląd Zarządu (9.3): 12% (Brak decyzji zarządu) WNIOSKI DLA AUDYTORA: GDZIE ROZPOCZĄĆ POGŁĘBIONE PRÓBKOWANIE? Najwięcej niezgodności krytycznych kryje się w relacjach z zewnętrznymi dostawcami IT i chmury
51/55
Podsumowanie części 3: kluczowe przesłania
  • ISO/IEC 27001:2022 to jedyna norma rodziny ISO/IEC 27000, którą można poddać certyfikacji w ramach schematu ISO/IEC 27001, oparta na zharmonizowanej strukturze (Harmonized Structure)
  • Klauzule 4–10 wyznaczają wymagania zarządcze systemu i wymagają wykazania rzeczywistego zaangażowania najwyższego kierownictwa
  • Deklaracja Stosowania (SoA) stanowi oś i serce każdego badania audytowego w obszarze doboru kontroli
  • Wydanie 2022 zreorganizowało Załącznik A do 93 kontroli zgrupowanych w 4 kategoriach: Organizacyjne, Osobowe, Fizyczne i Technologiczne
  • Wprowadzono 11 nowych, kluczowych zabezpieczeń odpowiadających współczesnym zagrożeniom (m.in. Threat Intelligence, Bezpieczeństwo chmury, DLP, Maskowanie danych, Bezpieczne kodowanie)
  • Skuteczny audytor harmonijnie łączy badanie procedur i ładu zarządczego z weryfikacją twardych parametrów technicznych w infrastrukturze
Podsumowanie Części 3: System SZBI i Załącznik A CZĘŚĆ ZARZĄDCZA (4–10) • Klauzule 4-10 = Wymagania audytowe • Kontekst i zakres (Klauzula 4) • Przywództwo i zasoby (Klauzula 5) • Szacowanie ryzyka (Klauzula 6) • Audyt 9.2 i Przegląd 9.3 Naruszenie = NC bezpośrednia MOST SoA ZAŁĄCZNIK A (93 KONTROLE) • 4 Domeny (5, 6, 7, 8) • 11 Nowych kontroli wydania 2022 • System 5 atrybutów taksonomii • Hardening, PAM, DLP, DevSecOps • Weryfikacja w konsoli i testy Wytyczne w ISO/IEC 27002 ZŁOTA REGUŁA AUDYTU SZBI: SYSTEM I KONTROLE STANOWIĄ NIEROZŁĄCZNĄ CAŁOŚĆ Certyfikat ISO 27001 potwierdza zarówno sprawność procesów zarządczych, jak i realną odporność techniczną
52/55
Słownik pojęć norm ISO 27001 i 27002 (Część A)
SZBI (System Zarządzania Bezpieczeństwem Informacji): część ogólnego systemu zarządzania organizacji, oparta na podejściu do ryzyka biznesowego, służąca do ustanawiania, wdrażania, eksploatacji, monitorowania, przeglądu, utrzymywania i doskonalenia bezpieczeństwa informacji
Deklaracja Stosowania (Statement of Applicability – SoA): udokumentowane zestawienie celów i zabezpieczeń stosowanych w SZBI wraz z uzasadnieniem ich włączenia lub wyłączenia z Załącznika A normy ISO/IEC 27001
Zabezpieczenie / Kontrola (Control): środek modyfikujący ryzyko; obejmuje polityki, procedury, wytyczne, praktyki lub struktury organizacyjne, które mogą mieć charakter administracyjny, techniczny, zarządczy lub prawny
Właściciel aktywa (Asset Owner): osoba lub jednostka organizacyjna ponosząca formalną odpowiedzialność zarządczą za określone aktywo informacyjne w całym cyklu jego życia
Właściciel ryzyka (Risk Owner): osoba lub jednostka posiadająca formalną odpowiedzialność i uprawnienia do zarządzania zidentyfikowanym ryzykiem bezpieczeństwa informacji
Harmonized Structure (dawniej HLS): zunifikowana architektura wysokiego poziomu, wspólny tekst podstawowy i identyczna terminologia stosowana we wszystkich normach systemów zarządzania ISO
Niezgodność duża / mała / OFI: niezgodność duża (major, roboczo NC1) / mała (minor, NC2) / obserwacja–OFI; 27001 stosuje shall (wymóg), 27002 – should (zalecenie)
Słownik pojęć ISO 27001 – Część A (Systemowe) LEKSYKON POJĘĆ SYSTEMOWYCH ISO/IEC 27000 SZBI / ISMS: System Zarządzania Bezpieczeństwem Informacji oparty na ryzyku SoA: Deklaracja Stosowania – zestawienie 93 kontroli z uzasadnieniami Kontrola (Control): Środek modyfikujący ryzyko (polityka, mechanizm techniczny, proces) Asset Owner: Właściciel aktywa ponoszący odpowiedzialność zarządczą za zasób Risk Owner: Właściciel ryzyka mający uprawnienia do decydowania o mitygacji HLS / HS: Harmonized Structure – ujednolicona struktura 10 klauzul norm ISO PRECYZJA TERMINOLOGICZNA: JĘZYK NORMY WYKLUCZA DOWOLNOŚĆ INTERPRETACJI Wszystkie definicje źródłowe pochodzą z normy ISO/IEC 27000:2026 (wydanie 6)
53/55
Słownik pojęć norm ISO 27001 i 27002 (Część B)
Threat Intelligence (Rozpoznawanie zagrożeń): ustrukturyzowana, zanalizowana wiedza o zagrożeniach, wektorach ataków, taktykach (TTP) i motywacjach cyberprzestępców, umożliwiająca podejmowanie decyzji obronnych
Crypto-shredding: technika trwałego uniemożliwienia odczytu zaszyfrowanych danych poprzez bezpowrotne zniszczenie klucza kryptograficznego użytego do ich zaszyfrowania
Data Masking (Maskowanie danych): ograniczenie widoczności danych; powinno być stosowane zgodnie z polityką maskowania danych oraz polityką kontroli dostępu
Configuration Drift (Dryf konfiguracji): stopniowe, niekontrolowane odchylenie parametrów systemu od zatwierdzonej wzorcowej linii bazowej w toku jego eksploatacji
Security Baseline (Wzorcowa linia bazowa): formalnie zatwierdzony zestaw specyfikacji będący podstawą konfiguracji i eksploatacji danego komponentu; linia bazowa bezpieczeństwa zawiera utwardzoną konfigurację systemu
Immutable Backup (Niezmienna kopia zapasowa): kopia zapasowa zapisana w technologii WORM uniemożliwiającej jej modyfikację, nadpisanie lub usunięcie przez określony czas, nawet przez konto administratora
Słownik pojęć ISO 27002 – Część B (Technologiczne) LEKSYKON POJĘĆ TECHNOLOGICZNYCH ISO/IEC 27002:2022 Threat Intel (5.7): Ustrukturyzowana wiedza o zagrożeniach, wektorach ataków i IOC Crypto-shredding (8.10): Uniemożliwienie odczytu danych przez zniszczenie klucza szyfrującego Data Masking (8.11): Zaciemnianie danych (DDM/pseudonimizacja) chroniące dane w dev/test Configuration Drift (8.9): Niekontrolowane odchylenie parametrów systemu od zatwierdzonego wzorca Security Baseline (8.9): Minimalny utwardzony profil konfiguracyjny (np. CIS Benchmark) Immutable Backup (8.13): Kopia w trybie WORM uniemożliwiająca usunięcie przez ransomware NOWOCZESNY WARSZTAT AUDYTORA CYBERBEZPIECZEŃSTWA Zrozumienie tych pojęć jest niezbędne do weryfikacji architektury Zero Trust i środowisk chmurowych
54/55
Pytania kontrolne i analiza studiów przypadku
  1. Organizacja wyłączyła w Deklaracji Stosowania (SoA) kontrolę 8.28 (Bezpieczne kodowanie), argumentując, że „używa wyłącznie gotowego systemu SAP”. W toku audytu okazuje się, że wewnętrzny zespół programistów tworzy zaawansowane skrypty ABAP modyfikujące struktury bazodanowe. Jak powinien zakwalifikować tę sytuację audytor wiodący?
  2. Wyjaśnij fundamentalną różnicę pomiędzy wymogiem klauzuli 9.2 (Audyt wewnętrzny) a klauzuli 9.3 (Przegląd zarządzania) w cyklu nadzoru nad SZBI.
  3. W jaki sposób kontrola 8.9 (Zarządzanie konfiguracją) chroni infrastrukturę teleinformatyczną przed zjawiskiem dryfu konfiguracyjnego?
  4. Scharakteryzuj zasadę podziału obowiązków (SoD – kontrola 5.3) na przykładzie procesu wdrażania zmian w kodzie źródłowym na serwery produkcyjne.
  5. Jakie obiektywne dowody audytowe musi przedstawić audytowany, aby wykazać skuteczną i kompletną realizację kontroli 8.13 (Tworzenie kopii zapasowych)?
Wskazówka dydaktyczna: Kazusy i pytania problemowe odzwierciedlają realne dylematy audytorów wiodących podczas audytów certyfikacyjnych i nadzorczych w jednostkach akredytowanych przez PCA / UKAS.
Pytania kontrolne i kazusy audytowe – Część 3 KAZUS 1: WYŁĄCZENIE 8.28 W SoA Firma używa SAP, ale pisze skrypty ABAP. Wyłączyła kontrolę 8.28. Jak orzekasz? Kwalifikacja: Nieuzasadnione wyłączenie! KAZUS 2: AUDYT 9.2 VS PRZEGLĄD 9.3 Czym różni się ocena zgodności audytora od strategicznej ewaluacji Zarządu? Weryfikacja dowodów vs Decyzje budżetowe KAZUS 3: DRYF KONFIGURACJI (8.9) Jak wykazać kontrolę nad zmianami w 500 wirtualnych maszynach w chmurze? Ansible / Terraform state compliance KAZUS 4: DOWODY DLA BACKUPU (8.13) Firma pokazuje zielone logi backupu, ale nigdy nie odtworzyła bazy. Co robisz? NC: Brak weryfikacji odtwarzalności! STUDIA PRZYPADKÓW STANOWIĄ BAZĘ DO DYSKUSJI NA WARSZTATACH LABORATORYJNYCH Zadaniem studenta jest obrona kwalifikacji uchybienia przed „klientem audytowanym”
55/55
Literatura, standardy i źródła uzupełniające

Międzynarodowe i polskie normy źródłowe:

  • PN-EN ISO/IEC 27001:2023-08 / ISO/IEC 27001:2022 – Bezpieczeństwo informacji, cyberbezpieczeństwo i ochrona prywatności – Systemy zarządzania bezpieczeństwem informacji – Wymagania (w tym ISO/IEC 27001:2022/Amd 1:2024 – zmiany klimatu w 4.1/4.2).
  • PN-EN ISO/IEC 27002:2023-08 / ISO/IEC 27002:2022 – Bezpieczeństwo informacji, cyberbezpieczeństwo i ochrona prywatności – Środki kontroli bezpieczeństwa informacji.
  • PN-EN ISO/IEC 27005:2025-01 / ISO/IEC 27005:2022 – Bezpieczeństwo informacji, cyberbezpieczeństwo i ochrona prywatności – Wytyczne dotyczące zarządzania ryzykiem w bezpieczeństwie informacji.
  • PN-EN ISO 19011:2018-08 / ISO 19011:2018 – Wytyczne dotyczące audytowania systemów zarządzania. Uwaga redakcyjna: wydanie 2018 (wydanie 3) zostało wycofane 27 maja 2026 r. i zastąpione normą ISO 19011:2026 (wydanie 4, opublikowane 2026-05). Numeracja klauzul przywoływana w tym kursie odpowiada wydaniu 2018; przed wdrożeniem należy porównać ją z tekstem normy ISO 19011:2026.
  • ISO/IEC 27000:2026 – Information security, cybersecurity and privacy protection – Information security management systems – Overview (wydanie 2018 zostało wycofane).
  • PN-EN ISO/IEC 27701:2025-11 (wersja angielska; poprzednio PN-EN ISO/IEC 27701:2021-09) / ISO/IEC 27701:2019 – Techniki bezpieczeństwa – Rozszerzenie do ISO/IEC 27001 i ISO/IEC 27002 w zakresie zarządzania informacjami o ochronie prywatności (PIMS).
  • ISO/IEC 27017:2015 – kontrole bezpieczeństwa dla usług chmurowych oraz ISO/IEC 27018:2019 – ochrona PII w chmurze publicznej (normatywne uzupełnienie kontroli 5.23).

Podręczniki i monografie akademickie:

  • J. Krawiec, G. Ożarek, „System Zarządzania Bezpieczeństwem Informacji w praktyce. Zabezpieczenia”, Wydanie II zaktualizowane, Wyd. PKN, Warszawa 2014.
  • E. Humphreys, „Implementing the ISO/IEC 27001:2013 ISMS Standard”, Artech House, Boston/London 2016.
  • Publikacje i wytyczne CIS Benchmarks (Center for Internet Security) dotyczące utwardzania konfiguracji systemów operacyjnych i baz danych.
Dostępność norm: Oficjalne Polskie Normy z rodziny ISO/IEC 27000 są dostępne w uczelnianym punkcie dostępu do Polskich Norm oraz elektronicznej czytelni PKN.
Literatura i standardy źródłowe – Wykład 3 PN-EN ISO 27001 • Wydanie 2023-08 • Wymagania SZBI • Klauzule 4-10 • Załącznik A Kryterium oceny PN-EN ISO 27002 • Wydanie 2023-08 • Przewodnik kontroli • 93 zabezpieczenia • 5 atrybutów Dobre praktyki BENCHMARKS • CIS Benchmarks • ISO/IEC 27000 • NIST SP 800-53 • Publikacje PKN Standardy tech. MATERIAŁY DOSTĘPNE W BIBLIOTECE UCZELNIANEJ I W CZYTELNI NORM PKN Zaleca się wnikliwą lekturę norm PN-EN ISO/IEC 27001 i 27002 przed przystąpieniem do laboratoriów