Najpopularniejsze wyzwania we wdrażaniu cyberbezpieczeństwa

Wdrażanie cyberbezpieczeństwa i zgodności regulacyjnej przestało być zadaniem wyłącznie dla działu IT. Dziś dotyczy zarządu, właścicieli procesów, HR, finansów, dostawców oraz każdego pracownika, który przetwarza dane lub korzysta z firmowych systemów.

Z perspektywy wielu projektów realizowanych w polskich organizacjach najtrudniejsze nie jest kupienie narzędzia bezpieczeństwa. Największym wyzwaniem jest zbudowanie spójnego modelu działania, który realnie ogranicza ryzyko, spełnia wymagania prawne i nie blokuje rozwoju biznesu.

Brak pełnej wiedzy o zasobach i danych

Pierwszym problemem jest niepełna inwentaryzacja. Firma często wie, jakie ma główne serwery, laptopy i aplikacje, ale nie widzi całego środowiska. Poza formalnym obiegiem mogą działać konta w usługach chmurowych, prywatne dyski współdzielone, stare subdomeny, testowe aplikacje, urządzenia mobilne czy systemy używane przez zewnętrznych partnerów.

Taka sytuacja znacząco utrudnia zarządzanie cyberbezpieczeństwem. Nie można skutecznie zabezpieczyć zasobu, którego istnienia, właściciela albo znaczenia biznesowego organizacja nie zna. Problem dotyczy także danych. W wielu firmach nie określono, gdzie znajdują się dane osobowe, informacje handlowe, dokumentacja techniczna, dane klientów i tajemnice przedsiębiorstwa.

W praktyce warto rozpocząć od czterech działań:

• przygotowania rejestru aktywów IT, usług chmurowych i aplikacji biznesowych
• przypisania właściciela do każdego istotnego systemu oraz zbioru danych
• klasyfikacji informacji według poufności, integralności i dostępności
• określenia przepływów danych między działami, dostawcami i systemami

To fundament zarówno dla ISO 27001, jak i GDPR, NIS 2 czy SOC 2. Dobrze wykonana inwentaryzacja pozwala też szybciej ustalić zakres badania podczas audytu cyberbezpieczeństwa i zidentyfikować obszary, które wymagają natychmiastowej poprawy.

Trudność w przełożeniu przepisów na konkretne działania

Przepisy europejskie opisują cele i obowiązki, ale rzadko dają jedną gotową instrukcję techniczną. To rodzi pytania: czy wystarczy szyfrowanie dysków, jak długo przechowywać logi, kto powinien zatwierdzać dostęp do systemu, jakie testy wykonywać wobec dostawcy i kiedy incydent trzeba zgłosić.

GDPR wymaga wdrożenia odpowiednich środków technicznych i organizacyjnych, uwzględniając ryzyko dla praw i wolności osób fizycznych. Dyrektywa NIS 2 koncentruje się na zarządzaniu ryzykiem cybernetycznym, ciągłości działania, obsłudze incydentów i odpowiedzialności kierownictwa. ISO 27001 wymaga ustanowienia systemu zarządzania bezpieczeństwem informacji, opartego na analizie ryzyka i ciągłym doskonaleniu. EU AI Act nakłada natomiast wymagania zależne od poziomu ryzyka systemu AI.

Najczęstszym błędem jest traktowanie regulacji jako listy dokumentów do przygotowania. Dokumentacja jest konieczna, lecz bez faktycznego działania pozostaje nieskuteczna. Polityka zarządzania dostępami nie pomaga, jeśli konta byłych pracowników nadal działają. Procedura reagowania na incydenty nie zabezpieczy firmy, jeśli nikt nie wie, kto podejmuje decyzje poza godzinami pracy.

Praktyczne podejście polega na zbudowaniu mapy wymagań. Dla każdego obowiązku należy wskazać proces, osobę odpowiedzialną, dowód realizacji i częstotliwość przeglądu. Przykładowo wymóg zarządzania dostępem powinien prowadzić do procesu nadawania uprawnień, przeglądów kont, stosowania MFA oraz archiwizacji zatwierdzeń.

Brak właściciela ryzyka po stronie biznesu

Cyberbezpieczeństwo bywa błędnie postrzegane jako koszt techniczny. Zarząd zleca temat IT, a IT ma samodzielnie rozwiązać ryzyko, które w rzeczywistości dotyczy całej organizacji. Tymczasem dział techniczny nie powinien sam podejmować decyzji, czy firma akceptuje ryzyko długiej niedostępności sklepu, wycieku bazy klientów albo przerwy w obsłudze produkcji.

Wymagania NIS 2 szczególnie mocno akcentują rolę organów zarządzających. Kierownictwo powinno rozumieć najważniejsze zagrożenia, zatwierdzać podejście do zarządzania ryzykiem oraz nadzorować realizację działań. W praktyce oznacza to regularne raportowanie ryzyka cybernetycznego w języku biznesowym, a nie wyłącznie listę technicznych podatności.

Dobry raport dla zarządu powinien odpowiadać na kilka pytań:

• jakie procesy biznesowe są najbardziej krytyczne
• jakie scenariusze mogą je zatrzymać lub poważnie zakłócić
• jaka jest aktualna skala ryzyka oraz koszt potencjalnego zdarzenia
• jakie działania redukują ryzyko i jakiego budżetu wymagają
• które ryzyka firma świadomie akceptuje

Warto ustanowić właścicieli ryzyka po stronie biznesowej. Właściciel systemu sprzedażowego powinien współdecydować o priorytecie zabezpieczeń tego systemu, a właściciel procesu HR o sposobie ochrony danych pracowników. Taki model skraca drogę od wykrycia problemu do podjęcia decyzji.

Zarządzanie dostępami bez kontroli cyklu życia użytkownika

Nadmierne uprawnienia należą do najczęstszych przyczyn naruszeń bezpieczeństwa. Pracownik dostaje dostęp w pierwszym dniu pracy, później zmienia stanowisko, uczestniczy w dodatkowym projekcie, a po kilku latach ma dostęp do systemów, których już nie potrzebuje. Podobnie wygląda sytuacja z kontami serwisowymi, współpracownikami zewnętrznymi i administratorami dostawców.

Podstawową zasadą powinno być minimalne uprawnienie. Użytkownik otrzymuje dostęp tylko do tych zasobów, które są potrzebne do wykonania aktualnych obowiązków. W praktyce ważne są jednak nie deklaracje, ale powtarzalny proces obejmujący zatrudnienie, zmianę roli i odejście z organizacji.

Skuteczny model zarządzania tożsamością powinien obejmować:

• centralne zarządzanie kontami i grupami uprawnień
• MFA dla kont zdalnych, uprzywilejowanych i chmurowych
• okresowe przeglądy dostępów przez właścicieli systemów
• szybką dezaktywację kont po zakończeniu współpracy
• oddzielne konta administracyjne dla działań uprzywilejowanych

W organizacjach rozwijających aplikacje webowe szczególnej kontroli wymagają panele administracyjne, konta wdrożeniowe, klucze API oraz środowiska testowe. Bezpieczeństwo powinno być uwzględnione już podczas tworzenia aplikacji webowych, a nie dopiero po uruchomieniu systemu dla klientów.

Zarządzanie dostawcami i usługami chmurowymi

Firmy coraz częściej korzystają z modelu SaaS, hostingu, platform chmurowych, zewnętrznych księgowych, operatorów płatności oraz dostawców oprogramowania. Każdy taki podmiot może przetwarzać informacje lub uzyskać dostęp do systemów. Odpowiedzialności za ryzyko nie można jednak całkowicie przenieść na dostawcę.

W przypadku GDPR administrator danych nadal odpowiada za prawidłowy wybór procesora i zawarcie odpowiedniej umowy powierzenia. NIS 2 wymaga uwzględniania bezpieczeństwa łańcucha dostaw. Z kolei SOC 2 często oczekuje udokumentowanej oceny dostawców, zwłaszcza tych obsługujących kluczowe dane lub procesy.

Ocena dostawcy nie musi zawsze oznaczać długiego formularza. Jej zakres powinien zależeć od ryzyka. Wobec dostawcy narzędzia do rezerwacji spotkań wystarczy zwykle podstawowa weryfikacja. Wobec operatora infrastruktury, CRM z danymi klientów albo partnera mającego dostęp administracyjny potrzebna jest głębsza analiza.

Należy sprawdzić między innymi lokalizację przetwarzania danych, warunki transferu poza Europejski Obszar Gospodarczy, stosowane zabezpieczenia, certyfikaty, historię incydentów, warunki zgłaszania naruszeń, prawo do audytu oraz zasady usuwania danych po zakończeniu usługi. Warto pamiętać, że certyfikat dostawcy jest ważnym dowodem, lecz nie zastępuje oceny konkretnego sposobu wykorzystania usługi w firmie.

Reagowanie na incydenty tylko na papierze

Wiele organizacji posiada procedurę reagowania na incydenty, ale nie przeprowadza ćwiczeń. W rezultacie podczas realnego zdarzenia pojawia się chaos: nie wiadomo, kto ma odłączyć system, kto kontaktuje się z dostawcą, kto ocenia obowiązek zgłoszenia do UODO i kto przygotowuje komunikację dla klientów.

Incydent może mieć różną postać. To nie tylko ransomware. Zdarzeniem wymagającym analizy może być wysłanie dokumentu do niewłaściwego odbiorcy, przejęcie skrzynki pocztowej, nietypowe logowanie administratora, ujawnienie klucza API w repozytorium czy awaria usług chmurowych.

Dobrze przygotowany proces powinien zawierać etap wykrycia, klasyfikacji, ograniczenia skutków, analizy przyczyn, odtworzenia działania oraz działań naprawczych. Dla naruszeń ochrony danych osobowych trzeba ocenić, czy zachodzi obowiązek zgłoszenia do Prezesa UODO w terminie 72 godzin. W zależności od charakteru podmiotu i zdarzenia zastosowanie mogą mieć również obowiązki raportowe wynikające z NIS 2 oraz krajowych przepisów wdrażających dyrektywę.

Najlepszym testem gotowości jest ćwiczenie scenariuszowe. Można zasymulować atak phishingowy na dział finansowy albo niedostępność systemu obsługi klientów. Kluczowe jest sprawdzenie nie tylko narzędzi, ale też jakości komunikacji i szybkości decyzji. W budowaniu scenariuszy pomocna jest analiza threat intelligence, która pozwala odnosić zabezpieczenia do rzeczywistych metod działania cyberprzestępców.

Sztuczna inteligencja wdrażana bez zasad

Systemy generatywnej AI szybko trafiają do codziennej pracy. Pracownicy wykorzystują je do tworzenia ofert, analizy dokumentów, generowania kodu, obsługi klienta i przygotowywania materiałów marketingowych. Problem pojawia się wtedy, gdy organizacja nie określiła, jakie dane wolno przekazywać do narzędzi AI i kto zatwierdza ich użycie.

Ryzyka obejmują ujawnienie danych osobowych, tajemnicy przedsiębiorstwa i kodu źródłowego, ale również błędne odpowiedzi modelu, dyskryminację, naruszenia praw autorskich oraz brak wyjaśnialności decyzji. EU AI Act wprowadza podejście oparte na ryzyku. Szczególne wymagania dotyczą systemów wysokiego ryzyka, a obowiązki są wdrażane etapami zgodnie z harmonogramem rozporządzenia.

Firma powinna stworzyć rejestr wykorzystywanych systemów AI i przypisać im właścicieli. Następnie warto ocenić cel użycia, rodzaje przetwarzanych danych, wpływ na osoby fizyczne, dostawcę modelu, sposób nadzoru człowieka oraz wymagania dokumentacyjne. Istotne jest również szkolenie pracowników, ponieważ nawet dobrze skonfigurowane narzędzie nie ochroni danych, jeśli użytkownik wklei do niego poufny raport bez refleksji.

W praktyce polityka AI powinna jasno określać dozwolone narzędzia, zasady anonimizacji danych, ograniczenia dla decyzji automatycznych i proces zatwierdzania nowych zastosowań. W tym obszarze pomocne jest doradztwo AI i zgodność z EU AI Act, łączące ocenę technologii z wymaganiami prawnymi oraz organizacyjnymi.

Dokumentacja oderwana od rzeczywistości

Wdrożenie ISO 27001, SOC 2 lub NIS 2 bywa traktowane jako projekt dokumentacyjny. Organizacja przygotowuje polityki, rejestry i procedury, aby przejść audyt, lecz pracownicy nie znają ich treści albo procesy nie są faktycznie realizowane. Taka rozbieżność szybko wychodzi na jaw podczas incydentu, audytu klienta lub kontroli regulatora.

Dokumentacja powinna być krótka, zrozumiała i powiązana z codzienną pracą. Zamiast tworzyć ogólną procedurę zarządzania zmianą, warto opisać, kto zatwierdza wdrożenia, gdzie są zapisy decyzji, jak testuje się zmianę i co dzieje się w razie konieczności wycofania aktualizacji.

Dobrym podejściem jest budowanie systemu zarządzania bezpieczeństwem informacji na podstawie istniejących praktyk, a następnie uzupełnianie luk. Wdrożenie ISO 27001 powinno uporządkować odpowiedzialności, ryzyka i dowody działania, a nie mnożyć dokumenty bez wartości operacyjnej.

Jak ustalić priorytety bez paraliżu organizacji

Lista potrzeb w obszarze cyberbezpieczeństwa niemal zawsze jest dłuższa niż dostępny budżet i czas zespołu. Firmy próbujące poprawić wszystko naraz często kończą bez widocznego efektu. Lepszy rezultat daje podejście oparte na ryzyku i kolejnych etapach.

Najpierw należy zabezpieczyć elementy, które redukują największe zagrożenia w skali całej organizacji. Zwykle są to MFA, aktualizacje, kopie zapasowe testowane pod kątem odtworzenia, kontrola dostępów, szkolenia antyphishingowe, monitoring krytycznych systemów i podstawowy plan reagowania na incydenty. Następnie można rozwijać bardziej zaawansowane obszary, takie jak segmentacja sieci, centralne zarządzanie logami, testy penetracyjne, DLP czy automatyzacja zarządzania tożsamością.

Ważne jest mierzenie postępu. Przykładowe wskaźniki to odsetek kont objętych MFA, liczba krytycznych podatności usuniętych w terminie, czas dezaktualizacji konta po odejściu pracownika, skuteczność odtwarzania kopii zapasowych oraz odsetek ocenionych dostawców krytycznych. Takie miary pozwalają zarządowi zobaczyć, czy inwestycje w bezpieczeństwo rzeczywiście zmniejszają ryzyko.

Najpopularniejsze wyzwania we wdrażaniu cyberbezpieczeństwa wynikają najczęściej z braku spójności między technologią, procesami i odpowiedzialnością biznesową. Firma, która zna swoje zasoby, priorytetyzuje ryzyko i regularnie sprawdza działanie zabezpieczeń, ogranicza problem pozornej zgodności, czyli sytuacji, w której dokumenty istnieją, ale organizacja nie jest gotowa na realny incydent.