„Stan formalny vs stan faktyczny” cyberbezpieczeństwa w Polsce
Po przeprocesowaniu wielu audytów i wdrożeń dokonaliśmy podziału na 7 kluczowych obszarów:
| Obszar | Stan formalny (na papierze) | Stan faktyczny (w praktyce) |
|---|---|---|
| 1. Ramy prawne i obowiązki | Obowiązuje ustawa o KSC, wymagająca m.in. wyznaczenia IOD/PSI, prowadzenia analiz ryzyka, zgłaszania incydentów. Dochodzi NIS2, ISO/IEC 27001 i przepisy sektorowe (NFZ, KNF). | Ustawa znana głównie osobom z działów IT lub prawnym. W JST lub szpitalach – często nikt nie wie, że podlegają pod KSC. Dokumenty tworzone tylko do projektów lub kontroli. |
| 2. Polityki i procedury SZBI | Powinny być wdrożone: polityka bezpieczeństwa, plan ciągłości działania, procedury incydentowe, rejestry zasobów, rejestry ryzyk, plan szkoleń. | Najczęściej: istnieją pliki Word, utworzone przez firmy zewnętrzne. Często nikt ich nie czyta. Brakuje aktualizacji, szkoleń z dokumentów, brak realnych testów. |
| 3. Organizacja cyberbezpieczeństwa | Wyznaczony Inspektor Bezpieczeństwa (lub Pełnomocnik ds. SZBI), planowane przeglądy, audyty wewnętrzne, działania naprawcze. | Najczęściej nie ma dedykowanej osoby. Rolę pełni informatyk lub zewnętrzna firma „od wszystkiego” (serwery, oprogramowanie, SZBI). Brak realnych audytów. |
| 4. Zasoby techniczne i ochrona systemów | Wymagana ochrona: antywirus, firewall, backupy, segmentacja sieci, kontrola dostępu, szyfrowanie, aktualizacje. | Zakupy dokonywane wg kryterium ceny. Sprzęt często niekonfigurowany poprawnie. Backupy ręczne. Brak kontroli kont uprzywilejowanych, brak EDR/SIEM. |
| 5. Reakcja na incydenty | Każdy incydent powinien być klasyfikowany, rejestrowany, analizowany. W przypadku incydentu poważnego – zgłoszenie do CSIRT. |
Często incydenty są ignorowane lub „załatwiane na miejscu” bez analizy. Zgłoszenia do CSIRT zdarzają się bardzo rzadko. Brak procedur reagowania i ćwiczeń. |
| 6. Szkolenia i świadomość pracowników | Obowiązkowe szkolenia z cyberbezpieczeństwa dla personelu – coroczne lub okresowe. | Szkolenia realizowane rzadko, często online „na zaliczenie”. Brak testów socjotechnicznych. Świadomość phishingu niska, linki otwierane bez weryfikacji. |
| 7. Monitorowanie i audyt | Stałe monitorowanie infrastruktury (np. SIEM, Zabbix, Wazuh), przeglądy bezpieczeństwa, testy penetracyjne, aktualizacje polityk. | Brak stałego monitorowania. Brak logowania działań użytkowników. Testy penetracyjne to rzadkość. Dokumentacja nie aktualizowana przez lata. |
Wnioski:
- Formalnie: Polska posiada dobre ramy prawne i wytyczne (KSC, NIS2, ISO 27001).
- Faktycznie: Większość instytucji (zwłaszcza samorządy, SPZOZ, mniejsze podmioty) nie spełnia realnie wymagań.
- Często cyberbezpieczeństwo kończy się na „kopii zapasowej” i antywirusie.
Często nasi Klienci oczekuje MAPA RYZYK CYBERBEZPIECZEŃSTWA. Poniżej przedstawiamy Naszą wersję ogólną (do adaptacji)
Nr |
Ryzyko |
Opis zagrożenia |
Skutek dla organizacji |
Poziom ryzyka |
Rekomendowane działanie |
R1 |
Atak phishingowy na pracowników |
Kliknięcie w fałszywy link lub podanie loginu/hasła |
Utrata danych, przejęcie konta, wyciek danych osobowych |
Krytyczne |
Szkolenie, MFA, filtracja poczty, testy socjotechniczne |
R2 |
Brak aktualizacji systemów i oprogramowania |
Stare wersje Windows, systemów ERP, CMS |
Luka bezpieczeństwa, ransomware |
Krytyczne |
Automatyczne aktualizacje, harmonogram patchowania, nadzór IT |
R3 |
Utrata danych wskutek braku backupu |
Awarie sprzętowe, błąd ludzki |
Brak dostępu do danych, przestoje w pracy |
Wysokie |
Backup codzienny, testy odtwarzania, polityka backupu |
R4 |
Brak segmentacji sieci i kontroli dostępu |
Każdy ma dostęp do wszystkiego |
Ryzyko sabotażu lub błędu ludzkiego |
Wysokie |
Zasada najmniejszych uprawnień, VLAN, kontrola dostępów |
R5 |
Brak nadzoru nad kontami uprzywilejowanymi |
Brak logowania działań adminów, konta bez haseł |
Nieautoryzowane zmiany lub nadużycia |
Wysokie |
Rejestr działań, polityka kont, monitoring SIEM/EDR |
R6 |
Brak planu reagowania na incydenty |
Nie wiadomo co robić w razie ataku |
Chaos, wydłużona reakcja, wyciek danych |
Wysokie |
Opracować i przetestować plan IRP, ćwiczenia |
R7 |
Brak szkoleń z cyberbezpieczeństwa |
Pracownicy nieświadomi zagrożeń |
Błędy ludzkie, otwieranie złośliwych plików |
Wysokie |
Szkolenia co rok, e-learning + testy |
R8 |
Nieaktualna polityka bezpieczeństwa informacji |
Brak formalnych zasad |
Ryzyko braku zgodności z RODO, KSC, ISO |
Średnie |
Aktualizacja polityki raz w roku, SZBI |
R9 |
Dostęp z urządzeń prywatnych (BYOD) |
Pracownicy łączą się spoza urzędu / SPZOZ |
Ryzyko zainfekowania sieci |
Średnie |
Zakaz lub VPN, MDM, polityka urządzeń |
R10 |
Nieautoryzowane oprogramowanie |
Pracownicy instalują nielegalne lub niezatwierdzone programy |
Ryzyko złośliwego oprogramowania |
Średnie |
Whitelist, polityka oprogramowania, kontrola IT |
Legendy:
- Prawdopodobieństwo: Niskie / Średnie / Wysokie
- Wpływ: Niski / Średni / Wysoki
- Poziom ryzyka: Automatycznie wynika z dwóch powyższych (np. Wysokie + Wysokie = Krytyczne)
Co naprawdę chroni organizację?
Aby mapa ryzyk realnie chroniła, musi być elementem całego cyklu zarządzania bezpieczeństwem, czyli:
| Etap | Co trzeba zrobić |
|---|---|
| 1. Identyfikacja ryzyk | Mapa ryzyk – ✔️ (to już masz) |
| 2. Ocena ryzyk | Nadanie poziomu wpływu i prawdopodobieństwa |
| 3. Planowanie reakcji | Wskazanie, co zrobisz z każdym ryzykiem: akceptacja, minimalizacja, eliminacja |
| 4. Wdrożenie środków ochrony | Szkolenia, backupy, segmentacja sieci, EDR, SIEM, itp. |
| 5. Monitorowanie i aktualizacja | Czy coś się zmieniło? Czy nadal działa? |
Co daje mapa ryzyk w praktyce?
| Korzyść | Opis |
|---|---|
| Podstawa do planu działań | Dzięki niej wiadomo, co trzeba zabezpieczyć w pierwszej kolejności |
| Dowód „należytej staranności” | W razie kontroli (UODO, NIK, audyt ISO) możesz udowodnić, że świadomie zarządzasz ryzykiem |
| Fundament SZBI i ISO 27001 | Obowiązkowy element zgodności z normami (a od 2024 – również z ustawą NIS2) |
| Narzędzie dla zarządu / kierownictwa | Pomaga w podejmowaniu decyzji strategicznych i budżetowych |
Co się dzieje, gdy mapa ryzyk jest „na półce”?
- Nie wiadomo, co jest priorytetem.
- Działania są reaktywne, nie planowane.
- Przy incydencie – chaos.
- Audytorzy i inspektorzy mówią: „dokumentacja nie wdrożona, tylko papierowa”.
Podsumowując:
Mapa ryzyk nie chroni, jeśli nie prowadzi do działania.
Ale dobrze wykonana i aktualizowana jest jednym z najważniejszych narzędzi ochrony, szczególnie w instytucjach publicznych i medycznych.
Aby rzetelnie i skutecznie stworzyć mapę ryzyk cyberbezpieczeństwa oraz cały system zarządzania ryzykiem, potrzebny jest zespół interdyscyplinarny, a nie jedna osoba.
Dlaczego? Bo prawnik, informatyk i administrator patrzą na zagrożenia z zupełnie różnych perspektyw.
Kto i za co odpowiada? – Rola każdego z kluczowych członków:
| Rola | Zakres odpowiedzialności |
|---|---|
| 1. Informatyk / administrator systemów IT | Identyfikacja zagrożeń technicznych (np. brak backupu, dostępów, podatności). Wskazuje co może się zepsuć w sprzęcie, sieci, systemach. |
| 2. Prawnik oraz Inspektor Ochrony Danych (IOD) | Identyfikacja zagrożeń prawnych (RODO, KSC, wycieki danych, naruszenia obowiązków). Wskazuje co grozi prawnie i jak to dokumentować. |
| 3. Kierownik jednostki / osoba zarządzająca (np. sekretarz, dyrektor, kierownik IT) | Oszacowanie wpływu danego ryzyka na działanie urzędu/szkoły/SPZOZ (czyli co będzie, jak coś się stanie). Decyduje, czy coś akceptujemy, eliminujemy czy zabezpieczamy. |
| 4. Pełnomocnik ds. SZBI (jeśli jest) | Koordynuje wszystko, zbiera dane, aktualizuje dokumenty, pilnuje wdrożeń. |
Czy informatyk z doświadczeniem administracyjnym może zrobić to sam?
Może zacząć, zebrać dane techniczne i stworzyć projekt.
Ale IOD nie rozpozna ryzyk.
Bez zarządu/kierownictwa nie podejmie decyzji, które ryzyka akceptować, a które eliminować.
Jak to robić dobrze?
Forma warsztatowa – spotkanie z prawnikiem, informatykiem, kierownikiem, IOD.
Każdy dostarcza swoje ryzyka, ocenia wpływ i prawdopodobieństwo.
Całość scala osoba odpowiedzialna za SZBI lub pełnomocnik ds. bezpieczeństwa informacji.
Podsumowanie:
Mapa ryzyk powinna być efektem współpracy informatyka, IOD i zarządu/kierownictwa.
Nie da się tego zrobić dobrze w pojedynkę.
