Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydenty typu data-theft extortion coraz częściej wykraczają poza klasyczne naruszenia danych osobowych. W sektorze farmaceutycznym stawką są nie tylko informacje o uczestnikach badań klinicznych, lecz także własność intelektualna, modele sztucznej inteligencji, kod źródłowy oraz konfiguracje środowisk obliczeniowych wspierających proces odkrywania leków.
Przypadek przypisywany grupie FulcrumSec pokazuje, że współczesny cyberatak może jednocześnie generować ryzyko regulacyjne, operacyjne i strategiczne. Gdy celem stają się zasoby badawczo-rozwojowe, skutki incydentu mogą być odczuwalne znacznie dłużej niż w przypadku jednorazowego wycieku danych.
W skrócie
Według dostępnych informacji grupa FulcrumSec miała rozpocząć publikację danych wykradzionych z Novo Nordisk po nieudanych negocjacjach wymuszeniowych. Spółka potwierdziła nieautoryzowany dostęp do ograniczonej liczby wewnętrznych systemów IT oraz ekspozycję pseudonimizowanych danych związanych z częścią badań klinicznych.
Napastnicy twierdzą jednak, że zakres przejętych materiałów był znacznie szerszy i obejmował również zasoby badawcze oraz komponenty środowisk AI i ML. Jeśli te deklaracje są choć częściowo prawdziwe, incydent należy traktować nie tylko jako wyciek danych, ale również jako potencjalną kradzież know-how badawczo-rozwojowego.
Kontekst / historia
FulcrumSec jest opisywana jako grupa działająca w modelu czystego wymuszenia, bez szyfrowania systemów ofiary. Tego rodzaju operacje polegają na uzyskaniu dostępu do środowiska, eksfiltracji danych, a następnie wywieraniu presji finansowej poprzez groźbę ich publikacji.
W analizowanym przypadku przestępcy mieli zażądać 25 mln USD okupu. Po braku porozumienia rozpoczęli publikację próbek danych oraz informacji sugerujących szeroki zakres wykradzionych zasobów.
Novo Nordisk potwierdziło incydent bezpieczeństwa i poinformowało, że naruszenie objęło ograniczoną liczbę systemów wewnętrznych. Firma zaznaczyła również, że dotknięte dane kliniczne były pseudonimizowane, czyli nie zawierały bezpośrednich identyfikatorów pacjentów, a także wdrożyła działania ograniczające skutki zdarzenia i zaangażowała zewnętrznych specjalistów.
Analiza techniczna
Najlepiej potwierdzonym elementem incydentu są dane związane z badaniami klinicznymi. Według dostępnych doniesień mogły one obejmować losowo przypisane identyfikatory uczestników, płeć, rok urodzenia, biomarkery, dane zdrowotne i immunogenności, a także wybrane informacje dotyczące stylu życia, takie jak BMI, palenie tytoniu czy spożycie alkoholu.
Taki zestaw danych nie musi umożliwiać bezpośredniej identyfikacji osoby, ale nadal stanowi zbiór informacji wrażliwych o wysokiej wartości analitycznej. W praktyce oznacza to ryzyko zarówno dla prywatności uczestników badań, jak i dla zgodności organizacji z wymogami regulacyjnymi.
Znacznie poważniejszy z perspektywy bezpieczeństwa strategicznego jest jednak drugi, nie w pełni potwierdzony obszar wycieku. Napastnicy deklarują przejęcie zasobów AI i machine learning, w tym checkpointów modeli multimodalnych, biologicznych i chemicznych zbiorów treningowych, kodu źródłowego narzędzi wewnętrznych, logów z treningów, map infrastruktury HPC, konfiguracji Slurm, ustawień SSH, obrazów kontenerów oraz informacji o prywatnych repozytoriach i deweloperach.
Technicznie taki zestaw artefaktów ma znacznie większą wartość niż pojedyncza baza danych. Checkpoint modelu, pipeline treningowy, dane wejściowe i konfiguracja obliczeniowa mogą umożliwić odtworzenie istotnej części zdolności badawczej organizacji. To z kolei pozwala analizować metodologię, rekonstruować środowisko eksperymentalne i identyfikować słabe punkty procesu wytwórczego.
Dodatkowym obszarem ryzyka jest potencjalne przejęcie danych uwierzytelniających lub sesyjnych. W podobnych kampaniach początkowy dostęp bywa uzyskiwany dzięki logom infostealerów, przejętym ciasteczkom sesyjnym, reuse haseł, niewystarczającej ochronie MFA albo przez zewnętrznie dostępne usługi developerskie. Jeśli w tym przypadku rzeczywiście doszło do pozyskania konfiguracji SSH, repozytoriów i obrazów kontenerów, może to wskazywać na głęboką penetrację środowiska inżynieryjnego.
Konsekwencje / ryzyko
Skutki takiego incydentu należy analizować wielowarstwowo. Pierwszym poziomem jest ryzyko regulacyjne i reputacyjne związane z danymi badań klinicznych. Nawet jeśli dane były pseudonimizowane, organizacja musi wykazać, że ponowna identyfikacja uczestników nie jest możliwa bez dostępu do odrębnych informacji powiązujących.
Drugim poziomem jest wpływ na relacje z partnerami badawczymi, CRO, dostawcami technologii i instytucjami nadzorującymi. Wyciek danych dotyczących badań może podważać zaufanie do sposobu zarządzania informacją medyczną oraz do bezpieczeństwa cyfrowego łańcucha dostaw.
Najpoważniejsze może być jednak ryzyko utraty przewagi konkurencyjnej. Kradzież modeli, danych treningowych, kodu i konfiguracji obliczeniowych oznacza możliwość przejęcia części efektów wieloletnich inwestycji badawczo-rozwojowych. W przeciwieństwie do klasycznego wycieku rekordów wartość tych zasobów nie zanika po ich publikacji.
Nie można też pomijać ryzyka wtórnych ataków. Ujawnienie szczegółów infrastruktury technicznej, harmonogramów zadań, mechanizmów dostępu zdalnego czy obrazów kontenerów może ułatwić kolejne operacje ofensywne, w tym ruch lateralny, utrzymanie trwałości oraz ataki na łańcuch dostaw oprogramowania.
Rekomendacje
Organizacje z sektora life sciences powinny traktować środowiska badawcze, AI/ML i HPC jako zasoby krytyczne na równi z systemami ERP czy infrastrukturą produkcyjną. Oznacza to konieczność segmentacji sieci, rozdzielenia domen użytkowników biurowych od środowisk badawczych oraz ścisłej kontroli przepływu danych między strefami.
Kluczowe znaczenie ma również odporny model IAM. Należy egzekwować MFA odporne na phishing, rotację i ochronę kluczy SSH, zasadę najmniejszych uprawnień dla kont serwisowych, regularne przeglądy dostępu do repozytoriów kodu oraz cykliczną walidację kont uprzywilejowanych.
Niezbędne jest także monitorowanie eksfiltracji i nietypowych działań w środowiskach danych. Same systemy EDR nie wystarczą, jeśli organizacja nie obserwuje warstwy danych, repozytoriów badawczych, zadań HPC, transferów do chmur publicznych oraz operacji wykonywanych na modelach i datasetach.
Z perspektywy reagowania na incydenty warto utrzymywać gotowe procedury dla scenariusza extortion-only. Powinny one obejmować szybkie odcięcie zagrożonych systemów, analizę artefaktów wycieku, ocenę wpływu na własność intelektualną, identyfikację danych regulowanych oraz współpracę z działem prawnym i komunikacją kryzysową.
- inwentaryzacja modeli, datasetów i pipeline’ów AI jako aktywów krytycznych,
- szyfrowanie danych badawczych w spoczynku i w tranzycie,
- podpisywanie i kontrola integralności obrazów kontenerów,
- izolacja środowisk treningowych od sieci korporacyjnej,
- regularne polowania na zagrożenia pod kątem infostealerów i przejętych poświadczeń,
- przegląd ekspozycji prywatnych repozytoriów, narzędzi developerskich i interfejsów administracyjnych.
Podsumowanie
Incydent związany z FulcrumSec i Novo Nordisk pokazuje, że nowoczesne naruszenia w sektorze farmaceutycznym nie ograniczają się do wycieku danych osobowych. Coraz częściej obejmują one również zasoby o najwyższej wartości biznesowej, takie jak modele AI, dane badawcze, kod źródłowy i konfiguracje środowisk obliczeniowych.
To zmienia sposób oceny skutków incydentu i wymaga rozszerzenia ochrony na cały cyfrowy łańcuch badań i rozwoju. Dla zespołów bezpieczeństwa najważniejszy wniosek jest jasny: własność intelektualna i artefakty AI muszą być chronione z taką samą dyscypliną jak systemy produkcyjne i dane regulowane.
Źródła
- Security Affairs — https://securityaffairs.com/193763/security/fulcrumsec-targets-novo-nordisk-leaks-clinical-and-research-data.html
- Novo Nordisk notice on the incident — https://www.novonordisk.com/