Co się dzieje, gdy atakujący poruszają się szybciej niż służba zdrowia może wprowadzać poprawki?

Sektor ochrony zdrowia od dawna napotyka realną przeszkodę w łatanie problemów bezpieczeństwa: Zespół ds. bezpieczeństwa szpitala może w ciągu jednego popołudnia zidentyfikować lukę w systemie klinicznym, ale bezpieczne wdrożenie poprawki jest zazwyczaj utrudnione przez praktyczną rzeczywistość gorącego, codziennego tempa szpitala. Producent urządzenia może potrzebować zweryfikować aktualizację, szpital może musieć ją przetestować i zaplanować przestój, a niektóre zmiany mogą wymagać nawet przeglądu regulacyjnego.

Atakujący nie mają żadnych z tych ograniczeń. Dzięki narzędziom AI przyspieszającym rozpoznawanie i badanie luk oraz opracowywanie exploitów, już obciążone procesy naprawcze w ochronie zdrowia są pod jeszcze większą presją.

Co czyni to szczególnie bolesnym problemem, to fakt, że opóźnienia w łatach są często wydłużane przez zależności od dostawców. Na przykład poprawka do systemu MRI może wymagać weryfikacji przez dostawcę, ale często musi być również zatwierdzona przez kontrolę zmian w szpitalu. I wszystko to musi zostać wykonane bez zakłócania opieki.

Health-ISAC’s Frontier AI in the Health Sector raport wymienia opóźnione łatanie jako jedno z kluczowych zagrożeń sektora. Co pozostawia szpitale z jedną realną drogą naprzód: mogą nie być w stanie kontrolować każdego elementu harmonogramu łatania, ale mogą ograniczyć, co atakujący może zrobić, gdy aktualizacja jest wdrażana.

Harmonogram łatania ma dolny pułap z przyczyną

Wiele kroków w harmonogramie łatania szpitala może irytować specjalistów ds. bezpieczeństwa informacji, ale istnieją one w celu zapewnienia bezpieczeństwa pacjentów. Żadna nieprzetestowana aktualizacja respiratora czy pompy infuzyjnej, mająca zamknąć ryzyko cyberbezpieczeństwa, nie jest warta kosztu utrudniania opieki nad pacjentem. Odpowiedzią jest więc przyspieszenie części procesu, które można przyspieszyć bez osłabiania istniejących protokołów.

Audytorzy i zarządy mają tendencję traktować długie okna napraw jako problem dojrzałości programu lub budżetu i czasem mają rację. Zazwyczaj długie terminy łatania są symptomem słabej realizacji, braku zasobów lub wąskich gardeł poza kontrolą zespołu bezpieczeństwa. Więcej analityków może poprawić wykrywanie luk, triage i priorytetyzację, ale nie mogą skrócić terminów dostawcy ani przesunąć okien przestojów.

Wraz z tym, że eksploatacja luk staje się najczęstszym sposobem, w jaki atakujący uzyskują dostęp do docelowych sieci, Verizon 2026 Data Breach Investigations Report (DBIR) pokazuje, jak niewiele miejsca organizacje mają na wdrażanie poprawek. Mediana czasu potrzebnego na pełną naprawę znanej wykorzystywanej luki wzrosła w 2026 roku do 43 dni z 32 dni w roku poprzednim, podczas gdy odsetek w pełni zamkniętych luk spadł do 26% z 38%.

Fakt, że te liczby nie są specyficzne dla opieki zdrowotnej, pokazuje, jak trudna jest już naprawa, nie licząc dodatkowo ograniczeń klinicznych i dostawców, które szpitale muszą również zarządzać.

Czas spojrzeć poza oceny krytyczności

Podczas gdy okna napraw wydłużyły się, atakujący stają się szybsi. DBIR wykazał, że eksploatacja luk jest teraz najważniejszym sposobem, w jaki hakerzy włamują się do systemów, stanowiąc 31% naruszeń, wyprzedzając skradzione poświadczenia po raz pierwszy w 19 latach publikacji raportu.

Verizon twierdzi, że AI pomogło przyspieszyć odkrywanie i eksploatację luk, tak bardzo, że to, co kiedyś zajmowało miesiące, może teraz trwać godziny lub dni. I to jeszcze przed wypuszczeniem obecnej generacji modeli frontier, ponieważ zestaw danych DBIR zakończył się w październiku 2025 roku.

Jednak wszyscy oczekują takiej szybkości w dzisiejszych czasach. Raport Health-ISAC wskazuje na coś jeszcze istotniejszego: nowsze modele AI mogą łączyć niskocentryczne wykrycia w krytyczne ścieżki ataku, identyfikując kombinacje słabości, które w izolacji mogą wydawać się mniej istotne. Tworzy to kolejny problem dla programów naprawczych, które priorytetyzują oceny krytyczności, ponieważ niskocentryczne wykrycia, często ignorowane lub odkładane na później, mogą nagle stać się znacznie ważniejsze, jeśli wpływają na dostęp lub krytyczne systemy.

Rosnące zaległości tylko pogarszają sytuację. Pisząc w Nature, dyrektor Max Planck Institute Thorsten Holz opisał, że Mozilla użyła modelu frontier do znalezienia i naprawienia 271 luk w jednej wersji Firefoksa, znacznie przewyższając to, co jej dotychczasowe narzędzia i recenzenci wykryli w typowym miesiącu w poprzednim roku.

Ten nacisk na triage rozciąga się również na stronę dostawców: Linus Torvalds, opiekun jądra Linux, w maju zwrócił uwagę, że zgłoszenia błędów generowane przez AI przeciążają opiekunów.

Gdy nie możesz naprawić szybciej, ogranicz to, co jest osiągalne

Na szczęście zaległość, której nie da się wyeliminować, wciąż można zarządzać. Jeśli poprawka musi czekać, priorytetem powinno być obniżenie szansy na wykorzystanie jakiejkolwiek luki. Przenosi to pracę z szybkości naprawy na dostępność, co szpitale mogą kontrolować.

Segmentacja może służyć jako silny środek kompensacyjny. Urządzenie obrazujące z szerokim dostępem może dotrzeć do kontrolera domeny, udostępnionego pliku i otwartego internetu. Jednak jeśli jest ograniczone do odizolowanego segmentu, który zezwala na ruch do jego serwera PACS i punktu aktualizacji producenta, jednocześnie domyślnie odmawiając dostępu do reszty, każda luka w nim może pozostać odizolowana tak długo, jak trwa wdrażanie poprawki.

Tam, gdzie pozwalają na to wymagania urządzenia i dostawcy, szpitale mogą stosować segmentację, kontrolę wychodzącego ruchu oraz reguły deny-by-default, aby zawęzić, a nawet zamknąć ścieżki dostępu, gdy poprawka jest w toku.

Szpitale nie potrzebują pełnego spisu zasobów, zanim rozpoczną ograniczanie narażonej powierzchni. Najpierw policz systemy odpowiadające w internecie, utrzymuj tę liczbę aktualną w miarę rozbudowy ogólnego spisu i priorytetowo ograniczaj, co te systemy mogą osiągnąć wewnątrz sieci.

Dane z ankiety Health-ISAC wskazują, że branża już zaczyna zmierzać w tym kierunku. Około 80% członków Health-ISAC mówi, że planuje zwiększyć budżety na narzędzia bezpieczeństwa oparte na AI lub oceny podatności. Jedną z przydatnych dróg może być analiza, które ścieżki ataku działają w twoim własnym środowisku: znajdź kombinacje niskocentrycznych luk, które mogą wymagać uwagi, zanim wynik priorytetu przyciągnie twoją uwagę.

Rozmowy z dostawcami muszą również wyjść poza język umowy SLA. Kontrakty zawierają to, co ty i twoi dostawcy zobowiązali się lata temu, ale model zagrożeń zmienił się dramatycznie. Dlatego najpierw określ, jak długo może potrwać wydanie zweryfikowanej poprawki po publicznym ujawnieniu luki, a następnie dowiedz się, jakie środki łagodzące są dostępne, gdy czekasz na aktualizację. Warto również zapytać, czy testują swój produkt pod kątem aktualnych technik ataku wspomaganych AI.

Zarządzaj ekspozycją, której nie możesz usunąć

Większość organizacji nie potrafi określić, jak długo zajmuje wprowadzenie zweryfikowanej poprawki do produkcji po publicznym ujawnieniu exploita. Skup się na ustaleniu tej liczby, aby przestać debatować o oknach łatania i zacząć koncentrować się na tym, które dostawcy i systemy pozostają narażone najdłużej. To pozwoli ci zdecydować, co twoje działania naprawcze powinny priorytetyzować.

Udostępnianie informacji może znacznie skrócić ten cykl decyzyjny. Niektóre z najszybszych decyzji naprawczych, które widziałem, pojawiają się, gdy szpital dowiaduje się od kolegi o platformie dostawcy, która jest wykorzystywana, zanim luka zostanie publicznie ujawniona.

Okno weryfikacji samo w sobie nie będzie się wydłużać. Szpitale będą nadal uruchamiać systemy kliniczne z otwartymi lukami, co oznacza, że strategia segmentacji tych systemów musi mieć większe znaczenie niż harmonogram łatania. Każdy szpital powinien móc określić, dla każdej ze swoich krytycznych platform, co stałoby się w sieci, gdyby ta platforma została naruszona jutro.