Co zrobić w placówce medycznej po wycieku MyDR?

Ta checklista jest przeznaczona dla osoby zarządzającej placówką i dla informatyka, który ją obsługuje. Nie wymaga zaawansowanej wiedzy technicznej do zrozumienia, ale część punktów wymaga jej do wykonania — przy tych zaznaczamy, że warto je zlecić.

Kolejność nie jest przypadkowa: pierwsze cztery punkty ograniczają ryzyko natychmiast, pozostałe porządkują stan zabezpieczeń na dłużej. Bardziej techniczny zakres, obejmujący Active Directory, segmentację sieci i urządzenia brzegowe, opisujemy w osobnym materiale: Co jeszcze sprawdzić w infrastrukturze IT placówki.

Konta i hasła

Największe realne ryzyko po wycieku danych uwierzytelniających to nie włamanie do systemu dostawcy, a wykorzystanie tych samych haseł w innych miejscach. W placówkach medycznych powtarzalność haseł jest wysoka, bo systemy obsługuje wiele osób na zmianach.

• zmień hasła do systemu medycznego dla wszystkich kont, także tych rzadko używanych,
• zmień hasła do poczty firmowej — szczególnie do skrzynek, na które przychodzą wyniki badań i korespondencja z pacjentami,
• zmień hasła kont administracyjnych: systemu medycznego, poczty, routera, serwera, panelu hostingu,
• sprawdź, czy któreś hasło nie jest używane w kilku miejscach jednocześnie; jeżeli tak, rozdziel je,
• przejrzyj listę kont użytkowników i usuń konta osób, które już nie pracują w placówce,
• sprawdź, czy nie istnieją konta współdzielone przez kilka osób — jeżeli tak, zaplanuj przejście na konta imienne.

Uwierzytelnianie dwuskładnikowe

MFA jest najskuteczniejszym pojedynczym zabezpieczeniem przy wycieku danych logowania. Nawet znajomość hasła nie wystarcza wtedy do zalogowania się.

• włącz MFA w poczcie firmowej — to priorytet, bo skrzynka służy do resetowania haseł w innych usługach,
• sprawdź, czy system medyczny obsługuje uwierzytelnianie dwuskładnikowe, i włącz je, jeżeli jest dostępne,
• włącz MFA na kontach administracyjnych wszystkich usług chmurowych,
• zabezpiecz dostęp zdalny drugim składnikiem — VPN bez MFA jest słabym punktem.

Jeżeli placówka korzysta z Microsoft 365 lub Google Workspace, MFA jest dostępne w standardzie i włącza się je z poziomu panelu administracyjnego. Przy systemach medycznych zakres zależy od dostawcy — warto zapytać wprost.

Komputery i oprogramowanie

• zainstaluj zaległe aktualizacje systemu operacyjnego na wszystkich stanowiskach,
• zaktualizuj przeglądarki i aplikacje biurowe,
• sprawdź, czy na każdym komputerze działa ochrona antywirusowa lub EDR i czy ma aktualne bazy,
• uruchom pełne skanowanie na stanowiskach, z których korzystano z systemu medycznego,
• sprawdź, czy w systemach nie ma nieznanego oprogramowania zdalnego dostępu zainstalowanego kiedyś doraźnie,
• zweryfikuj, czy dyski komputerów przenośnych są szyfrowane — laptop z dokumentacją medyczną bez szyfrowania to osobne ryzyko.

Komputery z systemem, który nie otrzymuje już aktualizacji bezpieczeństwa, powinny zostać odłączone od danych medycznych. To punkt, który regularnie odkłada się na później i regularnie okazuje się przyczyną incydentu.

Poczta, serwery i dostęp zdalny

Poczta jest w placówkach najczęstszym wektorem ataku, a dostęp zdalny — najczęstszym niedopatrzeniem konfiguracyjnym.

• sprawdź reguły przekierowań w skrzynkach — automatyczne przekazywanie wiadomości na zewnętrzny adres jest klasycznym śladem przejęcia konta,
• przejrzyj historię logowań do poczty pod kątem nietypowych lokalizacji,
• zweryfikuj, czy pulpit zdalny nie jest wystawiony bezpośrednio do internetu; jeżeli tak, ukryj go za VPN,
• sprawdź listę użytkowników VPN i usuń nieaktywnych,
• przejrzyj reguły firewalla — czy wszystkie otwarte porty są nadal potrzebne,
• sprawdź, czy serwery mają aktualne poprawki bezpieczeństwa,
• zweryfikuj, kto ma dostęp zdalny ze strony firm zewnętrznych i czy jest on nadal uzasadniony.

Ostatni punkt bywa zaskakujący: w wielu placówkach dostęp zdalny mają jednocześnie dostawca systemu medycznego, serwisant sprzętu, firma od księgowości i informatyk sprzed dwóch lat. Warto to uporządkować.

Kopie zapasowe i monitoring

Kopie zapasowe nie chronią przed wyciekiem — chronią przed utratą danych. Po incydencie warto je jednak sprawdzić, bo to moment, w którym najczęściej okazuje się, że dokumentacja prowadzona w chmurze nie ma żadnej kopii po stronie placówki.

• ustal, czy placówka posiada własną kopię danych z systemu medycznego, czy polega wyłącznie na dostawcy,
• sprawdź, kiedy ostatnio wykonała się kopia i czy proces nie zatrzymał się po cichu,
• wykonaj próbne odtworzenie wybranych danych i zapisz, ile trwało,
• upewnij się, że jedna kopia znajduje się poza siedzibą placówki,
• sprawdź, czy ktokolwiek otrzymuje powiadomienia o błędach kopii zapasowych,
• zweryfikuj, czy logi systemu medycznego, poczty i serwerów są zachowywane i jak długo.

Zasadę kopii 3-2-1 opisujemy szczegółowo w materiale Backup 3-2-1: jak zabezpieczyć dane firmy. Logi mają w kontekście incydentu wartość szczególną — bez nich nie da się odtworzyć, czy w placówce wystąpiły zdarzenia powiązane.

Zapisz, co zostało zrobione

Każde z powyższych działań powinno trafić do dokumentacji incydentu jako element środków zaradczych. To nie biurokracja: art. 33 i art. 34 RODO wymagają opisania środków zastosowanych w celu zaradzenia naruszeniu i zminimalizowania jego skutków, a wykaz przeprowadzonych prac jest dokładnie tym opisem. Zakres informacji wymaganych w zgłoszeniu opisuje UODO: jakie informacje musi zawierać zgłoszenie naruszenia.

Notuj datę wykonania, zakres i osobę odpowiedzialną. Zakres dokumentacji opisujemy w artykule Jak udokumentować naruszenie danych.