KSC: wymagania techniczne. Jak zabezpieczyć firmę?

Atak ransomware rzadko zaczyna się od spektakularnego włamania do serwerowni. Częściej od przejętego konta Microsoft 365, kliknięcia w wiadomość phishingową albo nieaktualnej usługi dostępnej z internetu. Dlatego pytanie „KSC – wymagania techniczne. Jak zabezpieczyć firmę zgodnie z ustawą?” nie powinno sprowadzać się do zakupu pojedynczego narzędzia. Chodzi o zbudowanie ochrony, która pozwoli wykryć problem, ograniczyć jego skutki i przywrócić działanie firmy.

Dla zarządu Krajowy System Cyberbezpieczeństwa jest przede wszystkim tematem ciągłości działania i odpowiedzialności za ryzyko. Dla działu IT oznacza uporządkowanie dostępu, aktualizacji, kopii zapasowych, monitoringu i procedur reagowania. Te dwie perspektywy muszą się spotkać, ponieważ nawet najlepsza polityka bezpieczeństwa nie pomoże, jeśli firma nie zauważy podejrzanego logowania wystarczająco szybko.

KSC: wymagania techniczne a realne środowisko firmy

KSC określa obowiązki dla podmiotów objętych ustawą, a zmiany regulacyjne związane między innymi z NIS2 rozszerzają oczekiwania wobec wielu organizacji i ich łańcuchów dostaw. To, czy konkretna firma podlega określonym wymaganiom oraz w jakim zakresie, wymaga oceny jej działalności, roli i aktualnego stanu prawnego. Sama technologia nie przesądza więc o zgodności.

W praktyce wymagania techniczne należy rozumieć jako zdolność do zarządzania ryzykiem cybernetycznym. Organizacja powinna wiedzieć, jakie systemy posiada, kto ma do nich dostęp, gdzie przechowuje dane i co stanie się, gdy kluczowa usługa przestanie działać. Potrzebuje również mechanizmów, które pozwalają rozpoznać incydent oraz przeprowadzić właściwą obsługę incydentów.

Nie każda firma potrzebuje rozbudowanego centrum bezpieczeństwa budowanego wewnętrznie. MŚP korzystające z Microsoft 365, systemu księgowego, komputerów pracowników, serwerów lub chmury powinny jednak wdrożyć ochronę proporcjonalną do ryzyka. Zasadą nie jest maksymalna liczba narzędzi, lecz kontrola nad najważniejszymi zagrożeniami.

Zacznij od obrazu ryzyka, nie od listy produktów

Najpierw warto ustalić, co w firmie ma największe znaczenie biznesowe. W biurze rachunkowym będą to dane klientów, poczta i system finansowo-księgowy. W firmie logistycznej – systemy planowania tras, dostępność urządzeń i komunikacja z kontrahentami. W zakładzie produkcyjnym szczególnej ochrony wymagają systemy wspierające proces operacyjny, bo ich niedostępność może zatrzymać pracę.

Następnie trzeba wskazać prawdopodobne scenariusze. Przejęcie konta pocztowego może służyć do wyłudzenia zmiany rachunku na fakturze. Zainfekowany laptop może zostać punktem wejścia do sieci. Administrator używający jednego hasła do kilku systemów zwiększa skalę problemu po jego ujawnieniu. Taka analiza pozwala podjąć racjonalne decyzje i uniknąć wydatków na zabezpieczenia, które nie odpowiadają rzeczywistym zagrożeniom.

Inwentaryzacja aktywów i odpowiedzialności

Firma powinna utrzymywać aktualny wykaz urządzeń, systemów, kont uprzywilejowanych, usług chmurowych i dostawców IT. Wiele incydentów komplikuje nie brak technologii, ale brak odpowiedzi na proste pytania: czy ten serwer nadal jest potrzebny, kto odpowiada za aktualizacje i czy były pracownik nadal ma dostęp?

Warto wyznaczyć właścicieli kluczowych systemów. Nie muszą być oni administratorami, ale powinni rozumieć, jakie dane i procesy chronią oraz kogo powiadomić w razie problemu. To skraca czas decyzji podczas incydentu.

Minimalny poziom ochrony technicznej

Bezpieczeństwo wymaga kilku współpracujących warstw. Najbardziej uniwersalne elementy dla firmy objętej KSC lub przygotowującej się do nowych wymagań to:

• wieloskładnikowe uwierzytelnianie, szczególnie dla poczty, VPN, paneli administracyjnych i kont z podwyższonymi uprawnieniami;
• zarządzanie aktualizacjami systemów, aplikacji i urządzeń sieciowych, oparte na ustalonych terminach oraz kontroli wyjątków;
• zasada minimalnych uprawnień, dzięki której użytkownik ma dostęp tylko do zasobów potrzebnych mu w pracy;
• kopie zapasowe odseparowane od głównego środowiska, regularnie testowane pod kątem możliwości odtworzenia;
• ochrona stacji roboczych i serwerów oraz bezpieczna konfiguracja dostępu zdalnego;
• centralne gromadzenie istotnych logów, aby możliwe było odtworzenie przebiegu zdarzeń.

Wdrożenie MFA samo w sobie nie rozwiązuje problemu przejęcia kont. Może jednak zatrzymać część prób logowania z użyciem wykradzionego hasła. Podobnie backup nie zapobiega ransomware, ale daje firmie realną możliwość odzyskania danych. Właśnie dlatego zabezpieczenia należy oceniać jako całość, a nie jako odrębne projekty.

Logi mają wartość tylko wtedy, gdy ktoś je analizuje

Zapora sieciowa, Microsoft 365, serwery Windows i Linux oraz usługi chmurowe generują informacje o zdarzeniach. Wśród nich mogą pojawić się sygnały przejęcia konta: logowanie z nietypowej lokalizacji, masowe przekazywanie wiadomości, utworzenie reguły w skrzynce pocztowej czy próba wyłączenia zabezpieczeń.

Samo przechowywanie logów nie jest jednak równoznaczne z monitoringiem. Centralny system SIEM może zbierać i korelować dane z kluczowych źródeł, lecz alerty wymagają oceny kontekstu. Czy nocne logowanie administratora jest uzasadnione? Czy pobranie dużej liczby plików oznacza pracę projektową, czy kradzież danych? Bez analizy alertów firma może przeoczyć istotny sygnał albo stracić czas na fałszywe alarmy.

Dlatego stały monitoring bezpieczeństwa IT i model SOC as a Service są praktycznym rozwiązaniem dla organizacji, które nie mają własnych analityków bezpieczeństwa. Usługa SOC lub MDR, czyli Managed Detection and Response, łączy technologię wykrywania zagrożeń z pracą specjalistów analizujących zdarzenia i wspierających reagowanie na zagrożenia. Monitoring 24/7 ma szczególne znaczenie, gdy firma działa poza standardowymi godzinami albo atakujący próbują wykorzystać czas, w którym nikt nie obserwuje infrastruktury.

Reagowanie na incydent trzeba przygotować przed incydentem

Przy wykryciu podejrzanej aktywności liczą się pierwsze minuty. Pracownik powinien wiedzieć, gdzie zgłosić wiadomość phishingową. Administrator musi mieć możliwość czasowego zablokowania konta lub odizolowania urządzenia. Zarząd potrzebuje jasnej ścieżki eskalacji, która pozwoli podjąć decyzję bez chaosu.

Procedura nie musi być wielostronicowym dokumentem. Powinna określać, kto odbiera zgłoszenie, kto ocenia jego wagę, kto może odłączyć system od sieci, gdzie znajdują się kontakty do dostawców oraz jak dokumentować działania. Warto przećwiczyć scenariusz przejęcia skrzynki pocztowej lub zaszyfrowania plików. Test ujawnia luki, których nie widać podczas przeglądu dokumentacji.

Istotne jest też rozróżnienie między incydentem technicznym a jego konsekwencjami biznesowymi. Awaria jednego komputera może być ograniczonym zdarzeniem. Utrata dostępu do poczty całej organizacji, danych klientów lub systemu produkcyjnego wymaga szerszej koordynacji. Dobrze przygotowany plan pomaga ustalić priorytety i odzyskać kontrolę nad sytuacją.

Ludzie, dostawcy i ciągłe doskonalenie

Cyberbezpieczeństwo nie kończy się na konfiguracji narzędzi. Szkolenia powinny uczyć pracowników rozpoznawania phishingu, bezpiecznej pracy z dokumentami i szybkiego zgłaszania błędów. Celem nie jest obwinianie osoby, która kliknęła w podejrzany link, lecz ograniczenie czasu, w którym zagrożenie pozostaje niewykryte.

Warto także ocenić dostawców mających dostęp do systemów lub danych. Zewnętrzny serwis IT, dostawca aplikacji czy partner integrujący systemy może stać się elementem łańcucha ryzyka. Należy ustalić zasady dostępu, zakres uprawnień, sposób zgłaszania incydentów i odbierania dostępów po zakończeniu współpracy.

Wymagania KSC nie powinny być traktowane jako jednorazowy projekt zakończony audytem. Środowisko firmy zmienia się wraz z nowymi pracownikami, aplikacjami i usługami chmurowymi. Regularny przegląd ryzyka, testowanie kopii zapasowych, analiza incydentów oraz stały monitoring pozwalają dostosowywać ochronę do tego, jak firma rzeczywiście działa.

Najlepszym pierwszym krokiem jest uczciwe sprawdzenie, czy organizacja potrafi dziś wykryć podejrzane logowanie, zatrzymać rozprzestrzenianie się ataku i odtworzyć kluczowe dane. Jeśli odpowiedź nie jest jednoznaczna, warto potraktować to jako konkretny plan działania, a nie powód do paniki.

Dyrektor ds. Technologii (CTO) D.B.