MyDr x Cybersecurity / NIS2. Czy zawiodło zarządzanie ryzykiem? Studium przypadku #2
Michał Nowakowski · 17 sierpnia 2026
Przekazuję Wam część drugą studium przypadku MyDr (pierwszą znajdziecie tutaj). Tym razem zajmiemy się hipotetyczną sytuacją, tj. taką w której MyDr jest już podmiotem kluczowym / ważnym i realizuje konkretne obowiązki
Zanim opadną emocje i wszyscy wrócą do swoich zajęć, zapominając o tym jak ważne jest budowanie odporności w świecie cyfrowym, przekazuję Wam część drugą studium przypadku MyDr (pierwszą znajdziecie tutaj). Tym razem zajmiemy się hipotetyczną sytuacją, tj. taką w której MyDr jest już podmiotem kluczowym / ważnym i realizuje konkretne obowiązki (te które ustawą nowelizującą przesunięto w czasie i wprowadzono moratorium na kary) wynikające z ustawy o krajowym systemie cyberbezpieczeństwa (uKSC).
Dzisiaj druga część analizy, w której zaczniemy bardziej wchodzić w "abstrakcję", bowiem obowiązki z uKSC (ku naszemu nieszczęściu) jeszcze nie obowiązują. No, ale zobaczymy jak - przy pewnych założeniach - powinno to wyglądać. I to jest coś co spokojnie możecie wziąć jako punkt wyjścia dla Waszych implementacji - niezależnie od tego czy chodzi o uKSC 2.0, ISO 27001/22301 czy Waszą odporność i odpowiedzialność.
Znowu też zastrzeżenie - bazuję na informacjach zebranych w ramach OSINT, czyli na podstawie powszechnie dostępnych informacji i analiz, które wygenerowały modele AI (Fable 5 odmawia, więc pozostał Opus 4.8) i które zostały przeze mnie sprawdzone na tyle, na ile to możliwe. I jeszcze jedno - nie aspiruję do postrzegania mnie jako technicznego eksperta. Analiza skupia się na wątkach organizacyjnych, na których znam się po prostu lepiej.
Zanim przejdziemy do konkretów jeszcze ogłoszenia drobne:
ruszył newsletter, który jest dostępny na stronie - zapisy znajdziecie m.in. w prawym górnym rogu - to NAJLEPSZA DROGA DO DOSTĘPU DO AKTUALNYCH TREŚCI, ruszyła trzecia edycja szkolenia "Zostań AI Governance Officer'em", która odbędzie się 22 września.
Zacznijmy od najważniejszego - art. 8. Nie mam wątpliwości, że podmiot wielkości MyDr posiada swój własny system zarządzania bezpieczeństwem informacji, choć nie wiemy na czym został on zbudowany. Jest to w zasadzie fundament naszej odporności, choć musimy mieć świadomość, że sama dokumentacja na niewiele się zda, jeżeli nie będziemy mieli do tego oprzyrządowania i ludzi, którzy będą potrafili z niego skorzystać.
Mapowanie przygotowane w oparciu o materiały i wiedzę własną oraz model Opus 4.8. Sama ustawa wprowadza nawet podział na dokumentację normatywną i operacyjną (art. 10 ust. 2). Ta druga ma być swoistym potwierdzeniem, że zrobiliśmy wszystko jak trzeba.
Dokumentację operacyjną stanowią zapisy poświadczające wykonywanie czynności wymaganych przez postanowienia zawarte w dokumentacji normatywnej, w tym automatycznie generowane zapisy w dziennikach systemów informacyjnych. Do tego jeszcze przejdziemy. Wróćmy do MyDr. Pewne sprawy nie poszły po myśli organizacji. Czy gdyby wdrożony system zarządzania bezpieczeństwem informacji (SZBI) był zgodny z art. 8 uKSC (może był, tego nie wiemy), to cokolwiek by to zmieniło?
Ważnym aspektem SZBI jest zarządzanie ryzykiem, które ma charakter stały, wręcz ciągły, co pozwala "w czasie rzeczywistym" dostosowywać się do zmieniających się okoliczności. Na to na ile będziemy mieli roboty wpływa szereg czynników, w tym:
✅ wielkość i złożoność architektury rozwiązań z których korzystamy i zależności, które między nimi występują, np. wspomniany w cz. 1 dostęp do repozytorium kodu dawał dostęp do ważnych sekretów, które umożliwiły dostanie się do infrastruktury chmurowej,
✅ liczba dostawców i poddostawców z których usług korzystamy - w przypadku dużej zależności powierzchnia potencjalnego ataku rośnie,
✅ "nowości" z których korzystamy (także rozwiązań AI), które mogą być jeszcze niesprawdzone, a podatności mniej rozpoznane.
Wpływa na to wszystko ma także poziom wiedzy i kompetencji naszych pracowników, którzy mogą lepiej lub gorzej radzić sobie z analizą ryzyka. Mało tego, jeżeli nasi pracownicy nie są zwyczajnie kompetentni (czego rzecz jasna nie zarzucam MyDr) lub nie mają czasu na realizację zadań (bo np. są zatrudnieni w organizacji na 1/8 etatu, a takich etatów jest wiele), to potencjalne ryzyko dla organizacji rośnie, a skuteczność systemy zarządzania nim maleje.
Ustawa o uKSC mówi o szacowaniu ryzyka wystąpienia incydentu i potem podejmowanych krokach, ale prawda jest taka, że system zarządzania ryzykiem (ZR) bezpieczeństwa informacji nie może być oderwany od całego systemu, którego stanowi przecież część. Tak powinno to wyglądać w praktyce, choć bywa z tym różnie.
Przykład jak może wyglądać bardzo prosty kawałek kodu podatny na ataki. Przygotowane na bazie wiedzy własnej i modelu zaszytego w replit. Czy MyDr tutaj mógł zawinić? Potencjalnie, jeżeli np. w swoim systemie ZR pominął lub mniej poważnie potraktowano ryzyka podatności aplikacyjnych. No, ale to wykaże dopiero kontrola, którą zaplanował już Urząd Ochrony Danych Osobowych.
Ale wyciągnijmy z tego lekcję, zanim przejdziemy dalej. Częstym problemem każdego systemu zarządzania ryzykiem jest jego "wybitnie" organizacyjny i zgodnościowy charakter, który sprowadza się do dość lakonicznego określenia samego ryzyka i pominięcie aspektów związanych z kodem źródłowym czy architekturą rozwiązań oraz infrastruktury. Dlaczego? Dlatego, że:
⚠️ to trudna działka, która wymaga dość interdyscyplinarnej wiedzy i podejścia oraz
⚠️ brak informacji i przejrzystości w samej organizacji - ilu z nas interesuje się architekturą?
W praktyce więc zamiast schodzić na niższe poziomy klas podatności ze względu na źródło (oprogramowanie, infrastruktura, sieci etc.), tkwimy w dość abstrakcyjnych pojęciach jak awaria systemu ICT. I tu trzeba poczynić pewną uwagę - to często nie jest wyniki jakiejś złej woli, ale zwyczajnie przeciążenia naszych pracowników lub po prostu ich braku.
Jeżeli przyjmiemy, wyłącznie na potrzeby naszej analizy, że mógł być to realny scenariusz, to mogły się wydarzyć następujące rzeczy, które nie powinny mieć miejsca w modelowym systemie zarządzania bezpieczeństwem informacji, a mianowicie:
cała potencjalna powierzchnia ataku nie została właściwie zinwentaryzowana i zmapowana pod kątem ewentualnych podatności, a rodzaj podatności, którą wykorzystali atakujący może sugerować, że to się właśnie wydarzyło, nie aktualizowano i przekazywano wiedzy o podatnościach, co pozwala na dostosowywanie się, np. poprzez aktualizację luk czy wprowadzanie lepszych zabezpieczeń, a niekiedy nawet zmian architektonicznych, nie przeprowadzano odpowiedniego i adekwatnego szacowania ryzyka oraz nie przeprowadzano testów (niestety dość kosztownych, więc może było ich zwyczajnie za mało) dopasowanych do kategorii danych (osobowych, wrażliwych) oraz potencjalnych zależności pomiędzy administratorami a przetwarzającym, nie do końca (lub w ogóle) nie wzięto pod uwagę, że taka rolą jaką ma MyDr może generować ryzyko systemowe (co zresztą się wydarzyło), co mogłoby uratować przed tak poważnym incydentem, o ile byłoby właściwie zaadresowane, nie posiadano odpowiednich mechanizmów komunikacji i eskalacji wewnątrz organizacji, wydaje się prawdopodobne, że konkretnie zawiodły też procedury bezpiecznego wytwarzania kodu sSDLC (a więc i nie uwzględniono tego ryzyka i właściwie go nie zaadresowano) oraz "ryzyka deweloperskie", w tym związane z testami SCA/SAST.
Szczególnie ten ostatni wątek jest ciekawy w kontekście MyDr, bo pokazuje, że repozytorium kodu nie można traktować jako wyłącznie narzędzia, z którego korzystają deweloperzy, ale po prostu bardzo ważny element całej architektury. Staje się to też ogromnym wyzwaniem, bo repozytoria kodu:
❌ puchną i coraz trudniej się połapać co w nich jest ważne, a co mniej,
❌ nie są mapowane pod kątem zależności pomiędzy różnymi rozwiązaniami i ich wpływem na inne,
❌ zawierają coraz więcej "śmieciowego" kodu generowanego przez asystentów AI,
❌ dostępy są "wydawane jak leci" z pominięciem procedur i procesów nadawania uprawnień (IAM).
Dzięki dostępowi do kodu można zrobić naprawdę dużo a jeszcze więcej, jeżeli uda się nam ten kodu wykonać. To wtedy prawdziwa katastrofa.
W tym przypadku nie wiemy rzecz jasna czy tak było, no ale... pewne wnioski same się nasuwają po informacjach o specyfice ataku. Czy to jednak koniec?
Hah, nie! Mało tego, to dopiero początek, ale to już na świeżą głowę. Dajcie tylko mi znać czy taka forma jest dla Was atrakcyjna ;) A może chcielibyście o tym posłuchać w trakcie webinaru?