Cyberbezpieczeństwo: Twój SOC tonie w danych, a i tak niczego nie widzi

Wczoraj (12.07.2026) 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ć.

Jak rozsądnie zarządzać danymi?

W felietonie 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 rozporządzeniem]

• 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 kanały telewizyjne… No dobra, może trochę przesadziłem 🙂 Tak czy inaczej, to szalenie istotna kwestia.

Czytaj także: Europejskiej Rada ds. Ryzyka Systemowego o nowych cyberzagrożeniach w sektorze finansowym

A do tego dochodzi też AI Act i art. 10 czy Cyber Resilience Act…

No właśnie – Cyber Resilience Act, który będzie nas dotykał od końca grudnia 2027 roku, ale część obowiązków w tym w zakresie podatności będzie obowiązywać już we wrześniu 2026 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.”

Cyberbezpieczeńtwo 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ć – stay tuned!

Michał Nowakowski – doktor nauk prawnych i radca prawny z 13-letnim doświadczeniem w obszarze innowacji finansowych oraz nowych technologii. Specjalizuje się w zagadnieniach związanych z wdrażaniem przepisów i regulacji dotyczących danych, AI oraz budowaniu w organizacjach rozwiązań data governance i data management. Był prezesem zarządu PONIP. Pracował zarówno w sektorze publicznym, jak i prywatnym, gdzie zdobywał doświadczenie przy realizacji projektów uwzględniających szeroko rozumiane ryzyka ICT oraz outsourcing i ochronę prywatności. Był związany także z instytucjami finansowymi, w tym z bankami, gdzie doradzał m.in. zespołom R&D, bezpieczeństwa oraz IT. Autor książek, artykułów naukowych i prelegent na konferencjach i wydarzeniach branżowych. Prywatnie miłośnik kodowania i ML. Współzałożyciel i prezes zarządu spółki GovernedAI, zajmującej się tworzeniem i wdrażaniem bezpiecznego oprogramowania wykorzystującego systemy uczenia maszynowego i głębokiego, w tym tzw. generatywną sztuczną inteligencję.

Profil na LinkedIn:  https://www.linkedin.com/in/mjnowakowski/?originalSubdomain=pl