Cybersecurity. Poniedziałek, 9:00 - SOC nie daje rady

Michał Nowakowski · 12 lipca 2026

O tym dlaczego jakość danych ma znaczenie także w kontekście cyberbezpieczeństwa. I dlaczego nie możemy tego ignorować.

W ostatnim wydaniu newslettera przyjrzeliśmy się hipotetycznej sytuacji (a jednak dość powszechnej), gdy nagle do pokoju prezesa zarządu wpada CISO (człowiek odpowiedzialny za bezpieczeństwo informacji) i oznajmia - mamy problem. Dzisiaj zostajemy w obszarze cyberbezpieczeństwa, a wszystko za sprawą ciekawego wątku.

Wczoraj natrafiłem na ciekawy artykuł "When Too Much Security Data Becomes the Risk" poświęcony (nie)właściwemu zarządzaniu danymi, ale nie w odniesieniu do stricte biznesowych zagadnień, ale w kontekście cyberbezpieczeństwa. To dość rzadki temat na Linkedin, a łączący dwa tematy, które dla organizacji powinny mieć kluczowe znaczenie. No i tak myślałem i myślałem aż w końcu stwierdziłem, że warto i o tym napisać.

Zanim przejdziemy do merytoryki kilka ogłoszeń związanych z portalem:

zostało kilka ostatnich miejsc na drugi termin (21 lipca) na szkolenie "AI Governance Officer" - cały dzień praktycznej wiedzy, na stronie powstał kokpit, który pozwala na personalizację dostępu do strony - wybieracie rolę i dostajecie sugestie co do tego jak z niej korzystać, znajdziecie nową grę RPG poświęconą incydentom cyberbezpieczeństwa, kompas modeli open source doznał aktualizacji.

Wróćmy jednak do felietonu, gdzie znajdziemy takie oto stwierdzenie:

Przez lata powszechna zasada w operacjach bezpieczeństwa była prosta: zbieraj wszystko. Logi były tanie. Miejsca na przechowywanie danych było pod dostatkiem. A im więcej danych miał zespół, tym pewniej mógł się czuć w kwestii wykrywania zagrożeń i analizy śledczej. Dzisiaj okazuje się, że zbieranie wszystkiego jest kosztowne. Decyzja zarządu o angażowaniu się w budowanie systemu zarządzania bezpieczeństwem informacji (SZBI) nie opiera się wyłącznie o zrozumienie wartości jako takiej, ale także szacowanie poniesienia ewentualnych kosztów, które taki system na nas wymusi. To koszty widoczne "od razu", jak i ukryte, które ponosimy wraz z rozwojem naszego systemu.

Tu dochodzimy do ważnego aspektu jakim jest rozsądne zarządzanie danymi. Danymi, które mają realną wartość dla organizacji i jakościowo odpowiadają naszym oczekiwaniom.

Jakość danych, bo to właściwie ten wątek, jest istotna z perspektywy cyberbezpieczeństwa, bo m.in.:

od niej zależy jakość naszych działań operacyjnych, w tym jak będziemy zarządzali fałszywymi alertami i na ile nasz SOC (nasze centrum operacji bezpieczeństwa, czasem będzie to jeden człowiek) będzie dociążony zadaniami, z których trudno będzie się mu wywiązać,
brak odpowiedniego inwentaryzowania zasobów (IT) powoduje, że nie mamy oglądu całości i nie możemy tym samym lepiej chronić naszej organizacji - rejestr zasobów, także w kontekście AI, ma ogromne znaczenie i nie powinniśmy tego ignorować - > niektóre dane podają, że nawet 73% CISO zostało zaskoczonych incydentem, bo nawet nie wiedziało, że "coś" poddane incydentowi w organizacji funkcjonowało,

[Tutaj dodałbym także kwestię nierejestrowania wszystkich umów z dostawcami, które mogą mieć wpływ na naszą (nie)podatność - wymóg prowadzenia rejestrów umów ICT dla instytucji finansowych wynikający z DORA, to przykład dobrej praktyki dla nieobjętych rozporzadzeniem]

niewiedza na temat tego kto, gdzie i kiedy ma określone uprawnienia powoduje, że zwiększamy powierzchnię ataku i oddajemy adwersarzom pole do popisu; jest to o tyle ważny wątek, że ilość ataków skierowanych do konkretnych osób (tożsamości) istotnie wzrasta z każdym rokiem,
zbieranie nieistotnych danych powoduje tylko większy szum informacyjny, o którym mowa w artykule otwierającym; mało tego, samo gromadzenie danych (logów wszystkiego o wszystkim) zmierza do przeciążania infrastruktury i wzrostu kosztów przechowywania, które mogą przygnieść nie jeden budżet.
niewłaściwe zarządzanie podatnościami na skutek braku wiedzy może stanowić o naszym "być albo nie być", na co wskazuje chociażby raport Palo Alto Networks, gdzie wskazano, że:

Większość naruszeń była możliwa z powodu ekspozycji na zagrożenia, a nie wyrafinowania atakujących. W rzeczywistości w ponad 90% przypadków możliwe do uniknięcia luki w istotny sposób umożliwiły włamanie: ograniczona widoczność, niekonsekwentnie stosowane mechanizmy kontrolne lub nadmierne zaufanie do tożsamości. Czynniki te opóźniły wykrycie, stworzyły ścieżki do ruchu bocznego (lateral movement) i zwiększyły skalę szkód, gdy atakujący uzyskali już dostęp.

Jest jeszcze kwestia audytowa i raportowa...

W świecie, w którym musimy raportować i audytować się na szeroką skalę, bo przepisy (uKSC - NIS2, DORA czy CER) jakość danych staje się naprawdę kluczowa. Załóżmy, że jesteśmy podmiotem kluczowym lub ważnym i mamy obowiązki w zakresie wczesnego ostrzegania i realizacji obowiązków raportowych względem CSIRT. Musimy w naszej organizacji zapewnić, że zbieranie danych będzie nie tylko zapewniało jakość, ale także szybkość dostarczania wiarygodnych informacji.

Innymi słowy musimy zapewnić, że współpracujące ze sobą działy będą miały dostęp do informacji i szybko, i z odpowiednim poziomem wiarygodności/jakości.

Odnieśmy się tutaj do konkretnego obowiązku związanego z zarządzaniem incydentami poważnymi. Art. 12 ust. 3 zobowiązuje nas, aby zgłoszenie (72h!) zawierało m.in. opis wpływu incydentu poważnego na świadczenie usługi, w tym:

wskazanie usługi, na którą incydent poważny miał wpływ,
liczbę użytkowników usługi, na których incydent poważny miał wpływ, zasięg geograficzny obszaru, którego dotyczy incydent poważny,
wpływ incydentu poważnego na świadczenie usługi przez inne podmioty, a dodatkowo także
opis przyczyn tego incydentu, sposób jego przebiegu oraz prawdopodobne skutki oddziaływania na systemy informacyjne lub świadczone usługi
informacje o podjętych działaniach zapobiegawczych; informacje o podjętych działaniach naprawczych; aktualizację informacji, o których mowa w ust. 1, jeżeli nastąpiła ich zmiana.

Wyobraźmy sobie teraz, że polegamy wyłącznie na nieuporządkowanych procesach i nie mamy zapewnionego dostępu do rzetelnych danych. Konsekwencje mogą być tutaj co najmniej dwojakiego charakteru:

organ nadzorczy kwestionuje to jak działa nasz system zarządzania bezpieczeństwem informacji i ocenia go bardzo nisko co skutkuje odpowiedzialnością regulacyjną, w tym może nawet karą,
nasze zespoły nie są w stanie znaleźć konkretnych informacji, które pozwalają na eliminację skutków incydentu (tego i każdego kolejnego), a dział security popada w coraz większą frustrację - słusznie obwiniając za to inne zespoły, które nie zapewniły takich informacji, które są niezbędne (i przydatne) w operacyjnej działalności.

Koszty złej jakości danych mogą być więc całkiem spore. Mało tego - jest jeszcze wątek samej organizacji danych (w odłączeniu od bezpieczeństwa informacji). Z danych IBM wynika (i spokojnie można to przełożyć na nasz rynek), że "43% COO uznaje kwestie jakości danych za swój najważniejszy priorytet w obszarze zarządzania danymi i to nie bez powodu, bo ponad jedna czwarta organizacji szacuje, że z powodu złej jakości danych traci rocznie ponad 5 milionów USD, a 7% z nich zgłasza straty rzędu 25 milionów USD lub więcej". Z drugiej strony dobre governance dla danych może poprawić wyniki i przynieść realną wartość organizacji.

No i jeszcze ogólna kwestia dotycząca zarządzania ryzykiem ICT. To jeden z głównych obowiązków podmiotów objętych ustawą o krajowym systemie cyberbezpieczeństwa i odpowiedzialność zarządów. Dobre zarządzanie tymi ryzykami nie obejdzie się bez zapewnienia jakościowo dobrych danych, które będą dostępne na żądanie - zupełnie jak Netflix. No dobra, może trochę przesadziłem :) Tak czy inaczej, to szalenie istotna kwestia.

A do tego dochodzi też AI Act i art. 10 czy Cyberresilience Act...

No właśnie - Cyberresilience Act, który będzie nas "dotykał" od końca grudnia 2027 r., ale część obowiązków w tym w zakresie podatności będzie obowiązywać już we wrześniu tego roku. Będziemy musieli w sposób ciągły identyfikować, oceniać, ograniczać i raportować podatności przez cały cykl życia naszych rozwiązań. Jak to zrobić, jeżeli nie mamy odpowiednich mechanizmów ich zbierania?

Co z tego, że mamy portale, które regularnie monitorujemy, jeżeli jakieś podatności zignorujemy, bo są "nie nasze"?

Tak tylko zostawię Wam treść art. 14 :)

Producent [produktu z elementami cyfrowymi] jednocześnie zgłasza jakiekolwiek aktywnie wykorzystywane podatności zawarte w produkcie z elementami cyfrowymi, o których się dowiedział, CSIRT-owi wyznaczonemu na koordynatora zgodnie z ust. 7 niniejszego artykułu oraz ENISA. Producent zgłasza aktywnie wykorzystywaną podatność za pośrednictwem pojedynczej platformy sprawozdawczej ustanowionej na podstawie art. 16.

To jednak praca wspólna...

Dobrego podejścia do danych oraz informacji nie da się zbudować w pojedynkę. Projekty Data Governance są zazwyczaj projektami strategicznymi o zaangażowaniu interesariuszy z wielu obszarów. Jednocześnie nie zawsze stać będzie nas na podjęcie rękawicy w takiej postaci, bo koszty, bo niezdolność operacyjna, bo brak ludzi.

W takiej sytuacji możemy działać punktowo - wybierając te obszary, które jako pierwsze musimy dobrze ogarnąć. Prawdopodobnie z takiego pilotażu wyjdą nam dalsze kroki, które będziemy musieli podjąć dalej.

I o tych krokach będziemy jeszcze rozmawiać, a już niedługo na portalu pojawi się sekcja poświęcona danymi dla nietechnicznych, a w budowie mamy też szkolenie z cyberbezpieczeństwa AI. Stay tuned!