Audyt bezpieczeństwa w kontekście KSC nie powinien być traktowany jako formalność, ale jako narzędzie, które pokazuje, czy organizacja faktycznie kontroluje swoje bezpieczeństwo. W trakcie audytu weryfikowany jest faktyczny poziom zabezpieczeń, ich skuteczność oraz spójność z wymaganiami KSC. Analiza obejmuje zarówno środowisko IT i OT, jak i kwestie organizacyjne, takie jak role i odpowiedzialności, zarządzanie ryzykiem, ciągłość działania czy nadzór nad łańcuchem dostaw.
Efektem audytu nie jest sam raport, ale konkretna mapa ryzyk oraz rekomendacje działań – często rozpisane w czasie i dopasowane do możliwości organizacji. W przypadku podmiotów kluczowych audyt jest obowiązkowy i musi być realizowany cyklicznie, natomiast jego realna wartość polega na tym, że pozwala przejść od deklaratywnego bezpieczeństwa do faktycznej kontroli nad środowiskiem i świadomego zarządzania ryzykiem.
Audyt bezpieczeństwa przygotowujący organizację do spełnienia wymagań ustawy o Krajowym Systemie Cyberbezpieczeństwa nie powinien być traktowany wyłącznie jako formalny obowiązek. Jego głównym celem jest określenie, na ile organizacja jest odporna na incydenty bezpieczeństwa, gdzie znajdują się jej słabe punkty i jakie działania należy wdrożyć, aby ograniczyć ryzyka związane z naruszeniem poufności, integralności, dostępności i autentyczności informacji.
W praktyce audyt ma odpowiedzieć na kilka podstawowych pytań:
- jaki jest faktyczny poziom bezpieczeństwa organizacji,
- czy stosowane zabezpieczenia są skuteczne,
- które obszary wymagają poprawy,
- czy organizacja spełnia wymagania KSC,
- jakie działania należy podjąć, aby te wymagania zaadresować w sposób odpowiedni i proporcjonalny.
Obowiązek audytu w KSC a jego realna wartość dla organizacji
W przypadku podmiotów kluczowych audyt bezpieczeństwa jest obowiązkiem, który powinien być realizowany cyklicznie, czyli raz na trzy lata. Podmioty ważne nie mają takiego obowiązku, chyba że zostaną do tego zobowiązane decyzją właściwego organu lub CSIRT-u sektorowego, na przykład w związku z wystąpieniem incydentu.
Dobrze przeprowadzony audyt powinien jasno wskazać rzeczywiste słabe punkty organizacji. Jego celem nie jest spełnienie formalnych wymagań, ale identyfikacja podatności i obszarów, które mogą zostać wykorzystane jako wektor ataku. Dlatego audyt powinien obejmować nie tylko środowisko IT, ale również procesy, strukturę organizacyjną, dokumentację, zarządzanie ryzykiem, monitorowanie incydentów, ciągłość działania, bezpieczeństwo fizyczne, łańcuch dostaw oraz bezpieczeństwo środowiska OT.
Kto powinien przeprowadzać audyt?
Rozporządzenie Ministra Cyfryzacji z dnia 12 października 2018 r. w sprawie wykazu certyfikatów uprawniających do przeprowadzenia audytuoraz akta wykonawcze wskazują, że audyt powinien być realizowany przez osoby posiadające odpowiednie, potwierdzone kompetencje. W praktyce oznacza to m.in. certyfikaty takie jak CISA, CISM, CRISC, CISSP, CIA, audytora wiodącego ISO/IEC 27001 lub ISO 22301, a także certyfikacje związane z bezpieczeństwem systemów przemysłowych, np. ISA/IEC 62443 Cybersecurity Expert.
Audyt może zostać przeprowadzony wewnętrznie, jeśli organizacja posiada odpowiednie kompetencje. W praktyce jednak dużą wartość daje zaangażowanie niezależnego podmiotu zewnętrznego. Taka perspektywa ogranicza ryzyko oceniania samego siebie, zwiększa obiektywność i pozwala spojrzeć na środowisko bez organizacyjnych przyzwyczajeń.
Jakie obszary obejmuje audyt KSC?
Zakres audytu powinien obejmować trzy główne perspektywy:
- organizacyjną,
- procesową,
- techniczną.
Pominięcie jednej z nich może sprawić, że obraz bezpieczeństwa będzie niepełny, a środowisko nadal pozostanie podatne na ataki.
Struktura zarządzania bezpieczeństwem
Po stronie organizacyjnej audyt sprawdza m.in. strukturę zarządzania bezpieczeństwem informacji, role i odpowiedzialności, zaangażowanie najwyższego kierownictwa oraz to, czy w organizacji wyznaczono osoby odpowiedzialne za cyberbezpieczeństwo.
Zarządzanie ryzykiem
Drugim istotnym obszarem jest zarządzanie ryzykiem.. Audyt powinien sprawdzić, czy organizacja identyfikuje ryzyka, ocenia ich wpływ, określa akceptowalny poziom ryzyka i wdraża działania ograniczające prawdopodobieństwo wystąpienia incydentu lub jego skutki. Nie każde ryzyko musi zostać wyeliminowane, ale każde powinno zostać świadomie ocenione, udokumentowane i zaakceptowane przez właściwe osoby.
Monitorowanie i reagowanie na incydenty
KSC wymaga, aby organizacja była w stanie wykrywać zdarzenia bezpieczeństwa i reagować na nie w odpowiednim czasie. W praktyce oznacza to potrzebę wdrożenia rozwiązań detekcyjnych, takich jak EDR, NDR IDS, IPS oraz innych systemów monitorujących środowisko. Samo posiadanie narzędzia nie wystarczy.
Ustawowy obowiązek dotyczący ciągłego monitorowania powoduje, że albo trzeba zbudować wewnętrzny zespół reagujący 24/7 bądź wynająć profesjonalną usługę SOC, w której analitycy zareagują na alerty w ustalonym czasie, odróżnią fałszywe alarmy od rzeczywistych incydentów i uruchomią procedury reagowania.
Zarządzanie ciągłością działania
Audyt powinien również objąć zarządzanie ciągłością działania. Chodzi o sprawdzenie czy organizacja wie, jak utrzymać lub odtworzyć kluczowe procesy w przypadku incydentu, awarii lub ataku. W tym kontekście znaczenie mają procedury kryzysowe, sztab kryzysowy, zasady komunikacji, backupy, testy odtworzeniowe i realna możliwość przywrócenia działania systemów.
W części technicznej audyt obejmuje m.in. bezpieczeństwo brzegu sieci, konfigurację firewalli, segmentację sieci, separację usług, bezpieczeństwo LAN i Wi-Fi, środowiska chmurowe, serwery, stacje końcowe, urządzenia mobilne, pocztę, inne kanały komunikacji, bezpieczeństwo danych, wykorzystanie AI, backupy oraz zarządzanie dostępem i użytkownikami uprzywilejowanymi.
Łańcuch dostaw
KSC wymaga, aby organizacje zwracały uwagę nie tylko na własne systemy, ale także na dostawców, którzy są istotni z punktu widzenia świadczenia usług lub prowadzenia działalności. Weryfikacja łańcucha dostaw może obejmować ankiety bezpieczeństwa, klauzule umowne, oświadczenia dotyczące stosowanych zabezpieczeń oraz ocenę, czy dostawca spełnia wymagania zgodne z najlepszymi praktykami, ISO lub KSC.
Jak przebiega audyt krok po kroku?
Spotkanie otwierające
To bardzo ważny etap, ponieważ pozwala ustalić zakres, harmonogram, osoby zaangażowane, oczekiwania oraz dokumenty potrzebne do analizy. W takim spotkaniu powinien uczestniczyć nie tylko dział IT, ale także przedstawiciele kierownictwa oraz właściciele biznesowi kluczowych obszarów: compliance, prawnego, HR oraz bezpieczeństwa.
Następnie audytor przekazuje formularz dojrzałości, ankietę oraz listę dokumentów do analizy. Odpowiedzi pozwalają zidentyfikować obszary wymagające pogłębienia i przygotować bardziej konkretne pytania na kolejne etapy. Dzięki temu audyt nie jest ogólną rozmową o bezpieczeństwie, ale skupia się na realnych elementach środowiska.
Analiza dokumentacji
Audytor sprawdza, czy organizacja posiada polityki, procedury i instrukcje tworzące system zarządzania bezpieczeństwem informacji. Częstym problemem jest sytuacja, w której cała dokumentacja bezpieczeństwa sprowadza się do polityki ochrony danych osobowych. To za mało, aby mówić o dojrzałym systemie zarządzania bezpieczeństwem informacji zgodnym z wymaganiami KSC.
Weryfikacja techniczna
Na tym etapie audytorzy i inżynierowie sprawdzają konfigurację systemów, zabezpieczeń, firewalli, poczty, serwerów, stacji końcowych, backupów, segmentacji sieci czy dostępu uprzywilejowanego. W praktyce już na tym etapie można podnosić poziom bezpieczeństwa. Jeśli podczas audytu zostanie wykryta ryzykowna konfiguracja, na przykład zbyt szeroka reguła na firewallu, można ją poprawić od razu, a następnie opisać to w raporcie.
Raport końcowy
Raport końcowy powinien zawierać podsumowanie dla kierownictwa napisane prostym, nietechnicznym językiem, wykaz podatności, opis stanu faktycznego, rekomendacje oraz roadmapę działań. Roadmapa może dzielić rekomendacje na działania do wykonania w perspektywie 0–3 miesięcy, 3–6 miesięcy oraz 6–12 miesięcy.
Najczęstsze błędy organizacji przygotowujących się do audytu
Brak zaangażowania zarządu
Cyberbezpieczeństwo bywa delegowane do działu IT, ale bez wsparcia kierownictwa trudno wdrożyć realne zmiany, zapewnić budżet i wymusić przestrzeganie zasad w całej organizacji. Tymczasem to najwyższe kierownictwo odpowiada za zapewnienie środków organizacyjnych, procesowych i finansowych potrzebnych do budowania bezpieczeństwa.
Dokumentacja niespójna z praktyką
Drugim częstym problemem jest dokumentacja niespójna z praktyką. Organizacje posiadają polityki i procedury, ale często są to dokumenty niedopasowane do realnego środowiska. W efekcie formalnie istnieje system zarządzania bezpieczeństwem informacji, ale pracownicy go nie znają, nie stosują albo nie jest on możliwy do zastosowania w codziennej pracy.
Nieuwzględnianie OT
Firmy produkcyjne często skupiają się na klasycznym IT, pomijając systemy automatyki przemysłowej, mimo że to właśnie one mogą być krytyczne dla działalności operacyjnej. Brak separacji IT i OT, niewspierane systemy, niekontrolowany dostęp serwisowy czy brak nadzoru nad osobami trzecimi mogą stać się istotnym źródłem ryzyka.
Niezaadresowane bezpieczeństwo łańcucha dostaw
Organizacje często nie wiedzą, jakie zabezpieczenia stosują ich kluczowi dostawcy, mimo że ich działanie bezpośrednio wpływa na ciągłość biznesu. Dotyczy to szczególnie dostawców ICT, usług chmurowych, SOC, utrzymania infrastruktury, systemów produkcyjnych czy innych usług krytycznych dla działalności.
Założenie, że bezpieczeństwo informacji to wyłącznie zadanie IT
W rzeczywistości każdy właściciel biznesowy odpowiada za informacje w swoim obszarze, a każdy użytkownik ma wpływ na bezpieczeństwo organizacji. Dotyczy to również osób, które nie pracują na co dzień przy komputerze, ale mogą zauważyć niestandardowe sytuacje, nieuprawniony dostęp fizyczny lub zachowanie odbiegające od normy.
Najczęstsze pytania dotyczące KSC
Czy poważna podatność jest incydentem bezpieczeństwa?
Sama podatność nie jest jeszcze incydentem bezpieczeństwa. Jest wektorem ataku i powinna zostać zaadresowana w procesie zarządzania ryzykiem, ale dopóki nie wywołuje negatywnego wpływu na system informacyjny, nie powinna być rejestrowana jako incydent. Rejestr podatności powinien być prowadzony osobno od rejestru incydentów.
Czy monitorowanie w trybie ciągłym oznacza SOC 24/7?
Monitorowanie ciągłe oznacza potrzebę stałego nadzoru nad alertami generowanymi przez systemy detekcji. W praktyce taką funkcję często realizuje Security Operations Center które działa w trybie 24/7, analizuje zgłoszenia, odróżnia false positive od realnych incydentów i uruchamia procedury reagowania.
Czy ankiety bezpieczeństwa wystarczą do nadzoru nad łańcuchem dostaw?
Ankiety są dobrym i potrzebnym elementem nadzoru nad łańcuchem dostaw, ale nie powinny być jedynym mechanizmem. Wyniki ankiet można przełożyć na klauzule umowne, wymagania bezpieczeństwa, oświadczenia dostawców i decyzje dotyczące dalszej współpracy. Jeśli kluczowy dostawca unika podstawowej transparentności w zakresie bezpieczeństwa, organizacja powinna poważnie rozważyć ryzyko takiej współpracy.
Czym jest incydent poważny?
Incydent poważny to taki, który może spowodować obniżenie jakości lub przerwanie świadczenia usługi kluczowej. Sama definicja incydentu znajduje się w ustawie o KSC, natomiast szczegółowe progi incydentu poważnego wynikają z aktu wykonawczego.
Czy analiza ryzyka powinna uwzględniać wpływ społeczny i biznesowy?
Tak, szczególnie w sektorach, których działalność ma bezpośredni wpływ na społeczeństwo. Jeżeli organizacja świadczy usługi istotne dla dużej liczby osób, na przykład w energetyce, ciepłownictwie, ochronie zdrowia czy infrastrukturze komunalnej, analiza ryzyka powinna uwzględniać skutki incydentu nie tylko dla samej firmy, ale również dla odbiorców jej usług.
Od kiedy podmiot musi zgłaszać incydenty do CSIRT-u?
Obowiązek zgłaszania incydentów powstaje po zaklasyfikowaniu organizacji jako podmiot kluczowy lub ważny. Po uzyskaniu informacji o takiej klasyfikacji organizacja powinna realizować obowiązki wynikające z KSC, w tym zgłaszanie incydentów do właściwego CSIRT-u.
Jakie dokumenty i procedury są potrzebne do zgodności z KSC?
Nie wystarczy jeden dokument. Potrzebny jest system zarządzania bezpieczeństwem informacji, który może obejmować m.in. politykę bezpieczeństwa informacji, procedury zarządzania incydentami, politykę backupu, politykę ciągłości działania, zasady dostępu uprzywilejowanego, procedury zarządzania ryzykiem, instrukcje dla użytkowników oraz zasady korzystania z prywatnego sprzętu, jeśli taka praktyka jest dopuszczona.
Jak sprawdzić, czy organizacja powinna zarejestrować się do S46?
Należy sprawdzić sektor działalności wskazany w załącznikach do ustawy, progi zatrudnienia, obroty oraz faktycznie wykonywaną działalność. Istotne może być również PKD, ale nie powinno ono zastępować realnej oceny tego, czym organizacja faktycznie się zajmuje.
Czy każdy dostawca musi być objęty weryfikacją bezpieczeństwa?
Nie każdy. Weryfikacja powinna dotyczyć przede wszystkim dostawców kluczowych dla działalności organizacji, świadczenia usług lub utrzymania systemów. Drobni dostawcy, którzy nie mają istotnego wpływu na bezpieczeństwo i ciągłość działania, nie muszą być objęci takim samym poziomem kontroli.
Czy system S46 jest płatny?
Nie. System S46 jest systemem nadzorowanym przez NASK i jest bezpłatny dla podmiotów. Organizacje mają zostać do niego dopisane po uznaniu za podmiot kluczowy lub ważny.
Audyt przygotowujący do KSC dość szybko pokazuje, czy organizacja realnie kontroluje swoje bezpieczeństwo.
Autorzy tekstu:
