Kradzież danych z infrastruktury Medyc jest potwierdzona. Jej pełny zakres — jeszcze nie. Producent systemu, spółka Qbusoft, przyznaje, że napastnicy zabrali dane osobowe. Redakcje zajmujące się cyberbezpieczeństwem opisują incydent mogący dotyczyć około pięciu milionów ludzi. W doniesieniach powraca Fingerprint, pseudonim znany już ze sprawy MyDr. To poważne ustalenia, ale nie wszystkie mówią o tym samym i nie wszystkie mają jednakowe oparcie w dowodach.

Medyc.pl nie jest przychodnią ani szpitalem. To oprogramowanie do obsługi placówek i prowadzenia elektronicznej dokumentacji medycznej (EDM). Ta różnica wyjaśnia, dlaczego włamanie do infrastruktury jednej firmy może dotyczyć pacjentów wielu niezależnych gabinetów. Człowiek zapisujący się do lekarza może w ogóle nie znać nazwy dostawcy, któremu placówka powierzyła obsługę jego danych.

Sprawa Medyc zasługuje na więcej niż alarmujący nagłówek. Trzeba odtworzyć chronologię, wyjaśnić znaczenie szyfrowania, przyjrzeć się informacjom o sprawcach i oddzielić wyniki analizy od ich możliwych konsekwencji. Pomagają w tym również wcześniejsze incydenty: MyDr, ALAB i brytyjskiego Synnovis. Pokazują różne skutki ataków na ochronę zdrowia — nie stanowią jednak dowodu, że w Medyc wydarzyło się dokładnie to samo. Stan ustaleń: 27 września 2026 roku.

Atak w sierpniu, wykrycie we wrześniu

Najbardziej konkretną publiczną chronologię zawiera zawiadomienie ośrodka w Inowrocławiu, przytaczające ustalenia Qbusoft i wspierających spółkę ekspertów. Według tego dokumentu 22–23 sierpnia napastnik wykorzystał SQL injection, czyli podatność umożliwiającą ingerencję w zapytania do bazy danych. Wyprowadził zaszyfrowane archiwum bazy. Incydent wykryto w nocy z 8 na 9 września.

Między wskazanym atakiem a jego wykryciem minęły zatem ponad dwa tygodnie. Nie jest to automatycznie dowód, że przez cały ten czas sprawca pozostawał w systemie. Daty opisują dwa rozpoznane zdarzenia, nie kompletny zapis jego aktywności. Ustalenie, czy dochodziło do kolejnych wejść, wymagałoby odpowiednich logów — zapisów operacji wykonywanych w aplikacji i infrastrukturze.

24 września o sprawie pisały Sekurak oraz CyberDefence24. Sekurak zwrócił uwagę na zawiadomienie placówki i zastrzeżenia dotyczące skuteczności ochrony zaszyfrowanych informacji. Nie była to publikacja własnego pełnego raportu z informatyki śledczej. Następnego dnia pojawiły się szersze doniesienia o skali incydentu i zapowiedź kontroli Urzędu Ochrony Danych Osobowych (UODO).

W komunikacie producenta z 25 września, zaktualizowanym o 16:33, potwierdzono kradzież imion i nazwisk, numerów PESEL, adresów zamieszkania, telefonów i adresów e-mail. Qbusoft zaznaczył zarazem, że nie potwierdzono kradzieży dokumentacji medycznej. To najważniejszy punkt wyjścia: nie mówimy już wyłącznie o próbie włamania, lecz o potwierdzonej przez producenta kradzieży danych.

Data ataku, data rozpoznania jego skutków i data publicznego komunikatu nie są zamienne. Zawiadomienie ośrodka nie ma przy tym widocznej daty publikacji. Nie sposób na tej podstawie przypisać mu miejsca przed albo po określonej aktualizacji producenta i zbudować historii kolejnych zmian stanowiska.

Pięć milionów osób i osiem milionów zdjęć: skąd pochodzą liczby

Liczba pięciu milionów pacjentów nie pochodzi wyłącznie od napastnika. CyberDefence24 napisał 25 września, że jego anonimowe źródło przekazało taki szacunek przed publicznym wpisem Fingerprint. Redakcja przywołała też informację Zaufanej Trzeciej Strony o drugim źródle potwierdzającym skalę. Sprowadzenie tych ustaleń do plotki powtarzanej za sprawcą byłoby nierzetelne.

Jednocześnie nie opublikowano oficjalnego bilansu, który pozwalałby sprawdzić metodę liczenia. UODO również przedstawia tę liczbę jako doniesienie mediów. Różnica między mocno uprawdopodobnioną informacją dziennikarską a zakończonym ustaleniem liczby poszkodowanych nadal więc istnieje.

W bazie medycznej liczba rekordów nie musi odpowiadać liczbie ludzi. Jedna osoba może mieć wiele wizyt, dokumentów i wpisów, a także występować w danych kilku placówek. Liczenie unikalnych pacjentów wymaga rozpoznania tych powtórzeń. Z kolei liczba kont użytkowników oznacza jeszcze coś innego: mogą to być konta personelu, nie pacjentów. To uwaga o sposobie interpretacji baz danych, a nie alternatywny szacunek skali Medyc. Bez odpowiedniego zestawienia nie ma podstaw, by ogłosić własną, mniejszą lub większą liczbę.

Osiem milionów zdjęć ma inny status: to deklaracja Fingerprint. CyberDefence24 zaznaczył, że charakter fotografii nie został jasno potwierdzony. Nie zweryfikował też niezależnie twierdzenia o siedmioletnim zakresie bazy. Nieuprawnione byłoby więc zamienianie ogólnego słowa „zdjęcia” w pewność, że chodzi o określony rodzaj intymnych fotografii pacjentów.

Dokładność liczb w wypowiedzi sprawcy nie zastępuje ich weryfikacji. Może on znać rzeczywisty rozmiar skopiowanego zbioru, ale może też używać imponującej wartości, by zwiększyć zainteresowanie i presję. Wiarygodność jednej sprawdzonej informacji nie przenosi się automatycznie na całą resztę przekazu.

Dokumentacja medyczna: wysokie prawdopodobieństwo nie jest pełnym bilansem

Zawiadomienie ośrodka przytacza ocenę dostawcy, według której pozyskanie wypisów medycznych jest bardzo prawdopodobne. Komunikat samego Qbusoft z 25 września mówi natomiast o braku potwierdzenia kradzieży dokumentacji. Te sformułowania opisują różne poziomy pewności. Mogą współistnieć: przesłanki wskazują na zdarzenie, ale jego zakres nie został jeszcze rozstrzygnięty.

Dokument placówki dotyczy jej pacjentów i okresu od 1 lipca 2024 do 23 sierpnia 2026 roku. Tego przedziału nie można rozszerzyć na wszystkich klientów Medyc. Podobnie potwierdzenie zabranych danych identyfikacyjnych nie uprawnia do stwierdzenia, że każdemu poszkodowanemu skradziono kompletną historię leczenia.

Z perspektywy analizy technicznej ważne jest rozróżnienie pomiędzy możliwością odczytania tabeli, wykonaniem operacji na niej, wyprowadzeniem jej zawartości i późniejszym wykorzystaniem danych. Każdy z tych etapów odpowiada na inne pytanie. Ślad próby dostępu nie jest jeszcze kopią dokumentu znalezioną u napastnika; z kolei brak takiej kopii w publicznym obiegu nie daje pewności, że dokument nie został zabrany.

Niepewność nie powinna służyć ani uspokajaniu za wszelką cenę, ani dopisywaniu najgorszego scenariusza. Potwierdzony zakres jest już poważny. Imię, nazwisko, PESEL i dane kontaktowe identyfikują człowieka, a informacja o związku z określoną placówką może być dla niego szczególnie delikatna. Rozstrzygnięcie, jakie dodatkowe treści medyczne znalazły się poza kontrolą dostawcy, pozostaje jednak osobnym zadaniem śledztwa.

SQL injection: kiedy aplikacja wykonuje polecenie napastnika

SQL to język, w którym aplikacja może pytać bazę o informacje lub zlecać ich zmianę. W prawidłowym rozwiązaniu dane wpisane przez użytkownika pozostają danymi. Przy podatności SQL injection odpowiednio przygotowana wartość może zostać potraktowana jako fragment instrukcji. Program zaczyna wykonywać zapytanie o znaczeniu innym, niż zamierzył jego autor. Tak tę klasę ataków opisuje OWASP, organizacja zajmująca się bezpieczeństwem oprogramowania.

Skutki zależą od konkretnego błędu i uprawnień połączenia z bazą. Możliwy bywa odczyt informacji, a w niektórych konfiguracjach także ich zmiana lub usunięcie. Nie każda podatność tego typu daje kontrolę nad serwerem czy dostęp do wszystkich zasobów. Sama nazwa SQL injection nie ujawnia zatem pełnego przebiegu włamania do Medyc.

W dostępnych publicznych dokumentach nie przedstawiono kompletnego ciągu żądań i odpowiedzi aplikacji ani zakresu uprawnień wykorzystanego konta bazodanowego. Nie znamy też z nich dokładnego miejsca błędu w kodzie. Można opisać klasę podatności i wskazany skutek, lecz nie odtworzyć całej drogi atakującego. W szczególności nie należy dopisywać przejęcia komputerów lekarzy, włamania do każdego gabinetu z osobna czy wykorzystania nieznanej wcześniej luki w systemie operacyjnym.

Techniczna ochrona przed tą klasą błędów jest dobrze opisana. OWASP wskazuje zapytania parametryzowane, w których instrukcja i podstawiane wartości są oddzielone, oraz ograniczanie uprawnień bazodanowych. To dwie różne warstwy: pierwsza utrudnia zmianę znaczenia zapytania, druga ogranicza możliwe szkody, gdy błąd jednak wystąpi.

Właśnie dlatego analiza incydentu nie kończy się na zdaniu „znaleziono lukę”. Równie ważne jest ustalenie, co podatny fragment mógł odczytać i dlaczego. W systemie przechowującym dane wielu podmiotów zakres uprawnień ma znaczenie dla rozmiaru potencjalnego wycieku. Nie wynika z tego, że znamy architekturę Medyc; wynika, jakie brakujące informacje pozwoliłyby ocenić skutki błędu.

„Dane były zaszyfrowane” — dlaczego to nie zamyka sprawy

Szyfrowanie zamienia czytelną treść w postać, której odczytanie wymaga odpowiedniego klucza. Jego skuteczność zależy nie tylko od algorytmu, lecz również od tego, gdzie znajduje się klucz i kto może go użyć. Zalecenia OWASP dotyczące przechowywania danych rozróżniają ochronę na poziomie nośnika, bazy i aplikacji. Każda odpowiada na nieco inne zagrożenie.

Zaszyfrowany dysk może chronić informacje po fizycznej kradzieży sprzętu, ale niekoniecznie przed napastnikiem korzystającym z działającej aplikacji, która ma prawo te informacje odczytywać. Podobnie kopia bazy z zaszyfrowanymi polami może pozostać nieczytelna albo stać się możliwa do odczytania — zależnie od dostępu do kluczy. Dlatego hasło „szyfrowanie” bez opisu granicy ochrony niewiele mówi o konkretnym incydencie.

W sprawie Medyc zawiadomienie ośrodka podaje, że mimo zaszyfrowania części pól dostawca zalecił przyjąć możliwość ich odczytania. To istotne zastrzeżenie, a nie szczegół, który można pominąć przy ocenie ryzyka.

W opracowaniu o zarządzaniu kluczami OWASP traktuje ich ochronę jako osobny problem bezpieczeństwa. W praktyce silny algorytm nie pomoże, jeśli ten sam nieuprawniony dostęp udostępni napastnikowi zarówno chronioną treść, jak i sposób jej odczytania. Nie musi on wtedy „łamać szyfru” w matematycznym sensie. Wykorzystuje informacje, które powinny pozostać poza jego zasięgiem.

Jest też różnica między hasłem do logowania a sekretem, który aplikacja musi odzyskać, aby wykonać określoną operację. Do weryfikacji logowania można używać specjalnych jednokierunkowych skrótów haseł: porównywać wynik przetworzenia, bez przechowywania odwracalnej kopii hasła. Gdy system potrzebuje oryginalnej wartości do współpracy z innym mechanizmem, sprawa jest trudniejsza. OWASP opisuje takie wyjątki, zalecając unikanie ich tam, gdzie można zmienić architekturę. Samo odwracalne przechowywanie sekretu nie rozstrzyga więc oceny; decyduje także ochrona dostępu do niego.

To ogólne zasady. Nie zastępują sprawdzenia, które z tych mechanizmów działały w Medyc podczas ataku i które zostały później zmienione.

Certyfikat lekarza nie jest tym samym co hasło do konta

Słowo „certyfikat” potrafi wprowadzać w błąd. W kryptografii certyfikat wiąże tożsamość z kluczem publicznym; sam nie jest tajnym kluczem służącym do składania podpisu. Poufności wymaga klucz prywatny. Te role rozdziela standard X.509 opisany w RFC 5280. W codziennym języku „plikiem certyfikatu” nazywa się jednak również pakiet zawierający materiał potrzebny do podpisywania, zabezpieczony hasłem.

Dlatego w ocenie wycieku liczy się zawartość pliku, a nie tylko jego nazwa. Sam publiczny certyfikat, plik z kluczem prywatnym oraz hasło otwierające taki plik to trzy różne rzeczy. Dopiero wiedza o tym, które elementy znalazły się poza kontrolą właściciela i jakie zabezpieczenia nadal działały, pozwala oceniać możliwość nadużycia.

ZUS wyjaśnia, że jego certyfikat pozwala lekarzowi podpisywać między innymi elektroniczne zwolnienia lekarskie. W materiałach o obsłudze e-ZLA przewiduje też unieważnienie certyfikatu po utracie pliku lub ujawnieniu hasła. To potwierdza wagę ochrony tych elementów, lecz nie świadczy o tym, że w sprawie Medyc doszło do skutecznego podszycia się pod lekarza.

Podobnie pojawienie się nazwy ZUS w analizie nie oznacza włamania do infrastruktury Zakładu. Kradzież materiału przechowywanego w systemie zewnętrznego dostawcy i naruszenie serwerów instytucji wystawiającej certyfikat są odrębnymi zdarzeniami. Łączenie ich jednym alarmującym skrótem zaciemniałoby problem zamiast go objaśniać.

Fingerprint: pseudonim, korespondencja i budowanie wiarygodności

Najmocniejszym publicznym punktem zaczepienia w opisie Fingerprint jest imienna relacja Adama Haertle, redaktora naczelnego Zaufanej Trzeciej Strony. W rozmowie z Interią z 3 września opisał korespondencję z tym kontem w sprawie MyDr i sprawdzenie części otrzymanej próbki. Według jego relacji badane informacje okazały się autentyczne; o incydencie powiadomił MyDr i CERT Polska, krajowy zespół reagowania na incydenty komputerowe.

To więcej niż sam post anonimowego konta. Mamy nazwanego rozmówcę, opis kontaktu i deklarowaną weryfikację konkretnego materiału. Nadal jednak potwierdzenie części próbki nie przesądza o całkowitym rozmiarze zbioru ani o prawdziwości każdej późniejszej wypowiedzi jej nadawcy.

Związek Fingerprint z atakiem na Medyc opisały Zaufana Trzecia Strona i CyberDefence24, powołujący się również na własne źródło. Jest to powiązanie oparte na ustaleniach dziennikarskich. W przywołanych publicznych materiałach nie przedstawiono identyfikacji konkretnych osób dokonanej przez organy ścigania.

Nie wiadomo, czy pseudonimem posługuje się jedna osoba, kilka osób, czy ktoś odpowiadający wyłącznie za kontakt. Nie ma też podstaw do przypisania narodowości lub działania na zlecenie określonego państwa. Nazwa internetowego konta może wskazywać ciągłość komunikacji, ale nie ujawnia sama z siebie całego zaplecza operacji.

W wywiadzie z 31 sierpnia Haertle opisywał deklarowaną przez sprawców misję poprawy bezpieczeństwa oraz oczekiwanie zapłaty za niezamówione testy. Oceniał takie żądanie jako okup. Wypowiedź dotyczyła MyDr — nie stanowi dowodu, że identyczne żądanie skierowano do Medyc.

Próba przedstawienia kradzieży jako usługi bezpieczeństwa ma znaczenie dla odbioru całej historii. Przesuwa uwagę z osób, których informacje zabrano, na samozwańczego oceniającego zabezpieczenia. Tymczasem wykazanie słabości programu i rozporządzanie cudzą dokumentacją to nie to samo. Nawet trafne wskazanie błędu nie daje sprawcy podstaw, by jego wersję wydarzeń traktować jak bezstronny raport.

Kradzież i szantaż nie wymagają zaszyfrowania serwerów

Nie każdy wyciek jest atakiem ransomware. W klasycznym wariancie ransomware złośliwe oprogramowanie blokuje dostęp do danych, zwykle przez ich zaszyfrowanie, a sprawcy żądają zapłaty za przywrócenie dostępu. Wymuszenie może jednak opierać się na innym nacisku: groźbie ujawnienia wcześniej skopiowanych informacji.

Amerykańska agencja CISA opisuje zarówno połączenie tych metod, jak i samą kradzież połączoną z groźbą publikacji. W drugim wariancie sprawny system i dobre kopie zapasowe nie odbierają napastnikowi całej przewagi. Organizacja może nadal pracować, lecz nie ma kontroli nad kopią pozostającą poza jej infrastrukturą.

To rozróżnienie pomaga czytać doniesienia o Medyc. Potwierdzono kradzież danych; z przywołanych materiałów nie wynika natomiast, że napastnicy zaszyfrowali produkcyjne serwery w celu wymuszenia okupu. Zaszyfrowane archiwum opisane w zawiadomieniu placówki nie oznacza tego samego co baza zaszyfrowana przez ransomware. W pierwszym przypadku mowa o postaci zabranych danych, w drugim — o narzędziu ataku.

Również sam fakt utrudnień w korzystaniu z usługi nie pozwala rozpoznać mechanizmu wymuszenia. Ograniczenia mogą wynikać z ataku, działań ochronnych lub przywracania usług. Do przypisania konkretnej przyczyny potrzebne są ustalenia dotyczące danego zdarzenia, a nie tylko obserwacja, że strona działa wolniej.

W sporze o bezpieczeństwo łatwo przeoczyć właśnie tę odrębność skutków. Przywrócenie dostępności kończy jeden problem. Nie usuwa kopii danych, nie unieważnia automatycznie przejętych sekretów i nie odpowiada na pytanie, czy ktoś zdążył użyć zabranych informacji.

MyDr: podobieństwo po stronie dostawcy, nie dowód identycznego włamania

MyDr jest najbliższym punktem odniesienia ze względu na czas, rynek oraz opisane przez media powiązanie z Fingerprint. Istotna jest jednak także konstrukcja relacji z pacjentem. W komunikacie z 13 sierpnia 2026 roku UODO wskazał, że placówki powierzały spółce MyDr przetwarzanie danych. Zapowiedział kontrolę zabezpieczeń, ich regularnego testowania i praktycznego wykorzystania analizy ryzyka.

W późniejszym, wrześniowym komunikacie urząd podał skalę MyDr wynoszącą 19 milionów osób. Informował też, że do 17 września otrzymał ponad 50 skarg i sygnałów oraz ponad dwa tysiące zawiadomień od administratorów danych. To wartości podane przez UODO, nie wynik własnego przeliczenia zbioru przez autora tego artykułu.

Najważniejsza analogia nie sprowadza się do zestawienia dużych liczb. Pacjenci kontaktują się z różnymi placówkami, lecz część ryzyka może skupiać się u wspólnego usługodawcy. Jeden incydent prowadzi wtedy do wielu osobnych zawiadomień i dotyczy ludzi, którzy nie zawierali z tym dostawcą bezpośredniej umowy.

Nie jest to argument przeciwko samemu korzystaniu z wyspecjalizowanego oprogramowania. Wspólny dostawca może również centralnie wdrażać poprawki i utrzymywać kompetencje, których nie ma każdy gabinet. Problemem do zbadania jest zakres dostępu i skuteczność zabezpieczeń, nie sam fakt zlecenia obsługi danych. Powiązanie medialne z tym samym pseudonimem nie dowodzi natomiast identycznej podatności, architektury ani sposobu wyprowadzenia informacji.

ALAB: kiedy potwierdzone są także wyniki badań

W przypadku ALAB laboratoria pismo z 8 grudnia 2023 roku podaje, że naruszenie stwierdzono 19 listopada. Firma potwierdziła udostępnienie przez przestępców plików zawierających wyniki badań i umowy. Wśród ujawnionych kategorii wymieniła nie tylko dane identyfikacyjne, lecz także wyniki laboratoryjne. To inny poziom potwierdzenia niż sama możliwość dostępu do dokumentacji.

UODO informował 30 listopada, że analizuje zgłoszenie otrzymane 21 listopada. Opisał zdarzenie jako ransomware połączony z wyciekiem i zapowiedział współpracę z Rzecznikiem Praw Pacjenta. Zaznaczał zarazem, że do wyjaśnienia pozostają szczegóły, przyczyny i skala. Potwierdzenie naruszenia oraz trwające ustalanie jego rozmiarów nie wykluczały się.

Przykład ALAB pokazuje, dlaczego w danych medycznych znaczenie ma nie tylko liczba osób. Informacja o zdrowiu dotyczy konkretnego etapu życia i nie znika dlatego, że dostawca usunął lukę. Hasło można zmienić; udokumentowanej historii leczenia nie da się zastąpić nową historią. To zasadnicza różnica między utratą poufności a awarią, po której wystarczy odtworzyć system.

Nie oznacza to, że w Medyc potwierdzono taki sam zakres. Porównanie służy pokazaniu różnicy: w ALAB sam administrator wymienił wyniki badań w ujawnionym materiale. W sprawie Medyc część informacji o dokumentacji nadal ma charakter oceny prawdopodobieństwa. W przytoczonych źródłach dotyczących ALAB nie ma też podstaw, by dopisać identyczny sposób włamania lub powiązanie z Fingerprint.

Synnovis: wyciek danych i opóźnione leczenie to dwa osobne skutki

3 czerwca 2024 roku ransomware zaatakował Synnovis, dostawcę usług laboratoryjnych dla brytyjskiej ochrony zdrowia. NHS England opisuje, że skradzione pliki opublikowano 20 czerwca. Usługi świadczone przed atakiem przywrócono do grudnia 2024 roku, ale analiza ujawnionych danych zajęła ponad rok. Odbudowa działania i rozpoznanie utraty poufności miały więc różne harmonogramy.

Bilans NHS London obejmuje 10 152 przełożone wizyty ambulatoryjne i 1710 planowych procedur w dwóch najbardziej dotkniętych zespołach szpitali. To liczby świadczeń, nie unikalnych pacjentów. Problemy z obsługą doboru krwi zwiększyły też zapotrzebowanie na krew grupy O. W tym incydencie skutki informatyczne przełożyły się zatem na organizację realnej opieki.

Późniejsze wyjaśnienia NHS przynoszą jeszcze jedną ważną korektę uproszczonego obrazu. Skradzione materiały pochodziły z administracyjnego dysku roboczego. Według Synnovis nie było dowodu publikacji odrębnej bazy systemu laboratoryjnego LIMS. Nie oznaczało to, że w ujawnionych plikach nie było wyników badań. Materiały robocze mogą zawierać informacje medyczne, mimo że nie są główną bazą dokumentacji.

To szczególnie użyteczna analogia do debaty o Medyc: nazwa systemu i ogólne określenie „baza” nie zastępują ustalenia, co faktycznie skopiowano. Podobnie powrót usługi do normalnego działania nie odpowiada na pytania o osoby, których dane ujawniono.

Nie należy jednak przenosić bilansu brytyjskich opóźnień na polski incydent. Dostępne materiały nie pozwalają przypisać Medyc takich samych następstw dla leczenia. Nie ma również podstaw, by z tych dwóch historii budować tezę o wspólnych sprawcach. Wspólna jest zależność wielu podmiotów od dostawcy; mechanizm i skala szkód wymagają odrębnego ustalenia.

Spór o zgłoszenia nie rozstrzyga się samą listą instytucji

24 września minister cyfryzacji Krzysztof Gawkowski informował o braku zgłoszenia od Qbusoft do CERT Polska lub CSIRT CeZ, zespołu reagowania na incydenty w Centrum e-Zdrowia. Jego wypowiedź przytoczył następnego dnia UODO, zapowiadając kontrolę spółki.

Qbusoft w komunikacie z 25 września wymienił natomiast jako poinformowane instytucje Centralne Biuro Zwalczania Cyberprzestępczości (CBZC), UODO, CSIRT NASK, Centrum e-Zdrowia i ZUS. Producent deklarował współpracę ze służbami. Już 24 września CSIRT CeZ w odpowiedzi dla CyberDefence24 potwierdził udział ekspertów w usuwaniu skutków incydentu oraz wiodącą rolę CBZC.

Brzmi to jak sprzeczność, ale same te wypowiedzi nie wystarczają do jej rozstrzygnięcia. Udział zespołu w obsłudze zdarzenia nie musi oznaczać, że zgłoszenie wpłynęło od określonej firmy, w określonym terminie i wymaganym trybie. Późniejsza lista poinformowanych podmiotów nie przesądza też, jaki był stan dzień wcześniej.

Znaczenie ma ponadto nazewnictwo. CERT Polska wykonuje część zadań CSIRT NASK, więc nie są to całkowicie niezależne od siebie kanały. Centrum e-Zdrowia, producent systemu i korzystająca z niego placówka mają z kolei odmienne role. Odrębność zespołu reagowania wyjaśniamy szerzej w materiale o obsłudze incydentów przez CSIRT CeZ.

Do oceny postępowania Qbusoft potrzebne są daty, adresaci i potwierdzenia odbioru, a nie wybór komunikatu, który lepiej pasuje do przyjętej tezy. Zapowiedź kontroli jest informacją o działaniu organu, nie gotowym rozstrzygnięciem odpowiedzialności. Jednocześnie brak takiego rozstrzygnięcia nie unieważnia pytań o zabezpieczenia i sposób informowania poszkodowanych.

Co oznacza naprawa po kradzieży danych

Zawiadomienie ośrodka opisuje usunięcie podatności przez Qbusoft, ograniczenie uprawnień, zmianę haseł i sekretów oraz dodatkowy monitoring. Producent informuje zarazem o dalszych próbach ataków i możliwych ograniczeniach dostępności. Nie są to wzajemnie wykluczające się wiadomości: zamknięcie jednej drogi wejścia nie powstrzymuje kogoś przed szukaniem następnej.

W opisie napraw łatwo jednak pomieszać trzy zadania. Pierwsze polega na przerwaniu nieuprawnionego dostępu. Drugie — na przywróceniu bezpiecznej pracy usługi. Trzecie — na ustaleniu, co zabrano i jakie skutki może mieć posiadanie tego materiału przez osoby trzecie. Każde wymaga innych dowodów. Sprawna strona internetowa nie potwierdza zakończenia wszystkich trzech.

Zalecenia NIST dotyczące reagowania na incydenty łączą reakcję z zarządzaniem ryzykiem i wyciąganiem wniosków z wydarzeń. W tym ujęciu naprawa nie ogranicza się do pojedynczej poprawki. Obejmuje również rozpoznanie przyczyn, sprawdzenie skuteczności działań i wykorzystanie ustaleń do lepszego przygotowania organizacji.

W odniesieniu do Medyc oznacza to, że pełniejszej oceny dostarczy dopiero opis przeprowadzonych zmian i ich weryfikacji. Nie muszą mu towarzyszyć publiczne szczegóły ułatwiające następny atak. Między milczeniem a ujawnieniem sekretów istnieje miejsce na rzetelną informację: jaki problem usunięto, jaki zakres objęło sprawdzenie i które pytania wciąż pozostają otwarte.

Dla pacjentów ważna jest także trwałość skutków. Przyszłe zabezpieczenia chronią przyszłe przetwarzanie, ale nie odbierają napastnikowi wcześniej zdobytej wiedzy. Dlatego ocena poprawy systemu i ocena konsekwencji już dokonanej kradzieży muszą pozostać rozdzielone.

Medyc po ataku: szansa na większe bezpieczeństwo, nie automatyczna gwarancja

Podział na systemy „przed atakiem” i „po ataku” dobrze oddaje moment, w którym ogólne przekonanie o odporności zderza się z konkretnym testem. Włamanie ujawnia słabości, które wcześniej mogły pozostawać niewidoczne. Może uruchomić gruntowną zmianę: od sposobu tworzenia oprogramowania po ochronę kluczy, zakres uprawnień i wykrywanie nietypowej aktywności.

Nie ma jednak podstaw, by z tego obrazu robić statystyczną regułę, że każdy produkt po incydencie jest bezpieczniejszy od produktu bez znanego wycieku. Samo doświadczenie ataku niczego nie naprawia. Znaczenie mają wyciągnięte wnioski i ich wdrożenie. Równie słabe byłoby przeciwne założenie: że raz zaatakowane oprogramowanie pozostanie na zawsze niegodne zaufania.

Medyc może wyjść z tego kryzysu znacznie lepiej zabezpieczony niż wcześniej, jeśli Qbusoft usunie przyczyny incydentu i podda efekty prac niezależnej weryfikacji. To realna możliwość, nie ocena wykonania tych zadań. Nie dysponujemy dziś wynikiem takiej całościowej oceny, który pozwalałby ogłosić zakończenie problemu.

Odbudowa zaufania nie wymaga zapewniania, że nic poważnego się nie stało. Wymaga uczciwego bilansu tego, co wiadomo, konsekwentnych napraw i gotowości do przedstawienia ich rezultatów. W interesie pacjentów jest zarówno rzetelne wyjaśnienie kradzieży, jak i to, by system, z którego nadal korzystają lekarze, stał się odporniejszy. Te oczekiwania nie stoją ze sobą w sprzeczności.

Źródła