Sytuacja
Prywatna klinika w Wilnie na Litwie: 150 pracowników, trzy lokalizacje, laboratorium i własny system informacji o pacjentach. Serwery znajdowały się na terenie kliniki, kopie zapasowe zapisywano na urządzeniu NAS w tej samej sieci, a antywirus był standardowym produktem bez centralnej konsoli.
W piątek wieczorem administrator zauważył, że dokumentacja pacjentów przestała się otwierać na komputerze w recepcji. W nocy ransomware zaszyfrował serwer plików, bazę danych systemu pacjentów i, co najboleśniejsze, urządzenie NAS z kopiami zapasowymi, bo było podłączone jako zwykły dysk sieciowy. Przez tydzień klinika pracowała na papierze: rejestracja telefoniczna, wyniki badań drukowane w laboratorium, część wizyt odwołana. Dane odtworzono ze starszej, wykonywanej nieregularnie kopii na dysku zewnętrznym oraz z miesięcznej kopii dostawcy systemu pacjentów. Część zapisów z tamtego tygodnia nie udało się odzyskać.
Dyrektor kliniki skontaktował się z nami dwa tygodnie po incydencie. Zadanie było jasne: zadbać, by to się nigdy nie powtórzyło, a jeśli się powtórzy, by odtworzenie trwało godziny, a nie tydzień.
Czego potrzebowano
- Kopie zapasowe, do których atakujący nie dotrze nawet z uprawnieniami administratora w sieci.
- Czas odtworzenia, który nie zatrzyma przyjmowania pacjentów na dłużej niż dobę.
- Regularne testy odtwarzania z pisemnymi raportami, o które prosił także inspektor ochrony danych kliniki.
- Ochrona stacji końcowych, która zatrzymuje szyfrowanie, a nie tylko o nim informuje.
- Rozwiązanie utrzymywane przez zewnętrzny zespół, bo klinika nie ma własnego administratora IT.
Co zrobiliśmy
Tydzień 1: uporządkowanie środowiska po incydencie
Najpierw upewniliśmy się, że złośliwego oprogramowania już nie ma: odbudowaliśmy serwer plików, zmieniliśmy wszystkie hasła administracyjne, wyłączyliśmy przestarzałe protokoły i oddzieliliśmy sieć serwerową od stacji roboczych. Było to kluczowe, bo nie ma sensu robić kopii środowiska, w którym może nadal tkwić dostęp atakującego.
Tygodnie 2–3: Veeam i niezmienialne kopie zapasowe
Wdrożyliśmy kopie zapasowe Veeam według zasady 3-2-1: kopia na lokalnym nośniku do szybkiego odtwarzania, kopia w centrum danych MDP CLOUD na Litwie oraz dodatkowa kopia w centrum danych Amazon w Niemczech. Kluczowa różnica względem poprzedniego rozwiązania to niezmienialna kopia zapasowa: repozytorium jest niewidoczne z sieci kliniki, kopii nie można zmienić przez ustalony okres przechowywania, a nawet administrator Veeam nie może ich usunąć ani nadpisać. Lokalne repozytorium również jest odizolowane: komunikuje się z nim tylko serwer kopii zapasowych, a nie stacje robocze.
Dla bazy danych systemu pacjentów ustawiliśmy kopie co godzinę, a dla plików i poczty e-mail codziennie. Okresy przechowywania dostosowano do wymagań kliniki dotyczących przechowywania dokumentacji. Nasz zespół monitoruje kondycję kopii: nieudane zadanie lub niezgodna suma kontrolna tego samego dnia staje się zgłoszeniem w helpdesku, a kierownictwo kliniki co tydzień dostaje krótki raport o liczbie wykonanych kopii i ilości wolnego miejsca.
Najbardziej skomplikowany był system informacji o pacjentach: jego dostawca wymagał, by bazę danych kopiować wyłącznie własnymi narzędziami. Uzgodniliśmy schemat podwójny. Kopia dostawcy zostaje, a Veeam dodatkowo wykonuje kopię całego serwera, żeby przy odtwarzaniu nie trzeba było instalować i konfigurować systemu od nowa.
Tydzień 4: ochrona EDR
Na wszystkich komputerach i serwerach wdrożyliśmy Bitdefender GravityZone z EDR i ochroną przed ransomware, która zatrzymuje masowe szyfrowanie i cofa zmiany w dotkniętych plikach. Nasz zespół monitoruje konsolę; podejrzaną aktywność przekazujemy odpowiedzialnej osobie w klinice.
Tydzień 5: test odtwarzania
Pierwszy pełny test odtwarzania: z niezmienialnej kopii odtworzyliśmy serwer systemu pacjentów i serwer plików w izolowanym środowisku w chmurze MDP CLOUD. Zajęło to 6 godzin, z czego większość poświęcono na weryfikację bazy danych razem z dostawcą systemu. Raport podpisali dyrektor kliniki i inspektor ochrony danych.
Rezultat
Czas odtworzenia skrócił się z tygodnia do 6 godzin, a zmierzono to podczas testu, a nie oszacowano w planie. Liczba kopii zapasowych dostępnych z sieci kliniki wynosi teraz zero. Testy odtwarzania odbywają się co miesiąc w mniejszej skali (pojedyncze pliki, jeden serwer), a pełne odtworzenie powtarza się co sześć miesięcy.
Klinika ma teraz raport audytowy z każdego testu: data, odtworzone systemy, czas trwania, napotkane problemy. O te raporty prosili zarówno inspektor ochrony danych, jak i ubezpieczyciel przy odnowieniu polisy cyberubezpieczenia. W pierwszych sześciu miesiącach konsola EDR dwukrotnie zatrzymała podejrzaną aktywność na komputerach pracowników, oba razy za sprawą zainfekowanych załączników e-mail, i żaden z tych przypadków nie dotarł do serwerów.
„Kiedyś myśleliśmy, że mamy kopie zapasowe. Teraz wiemy, że w ciągu sześciu godzin znów będziemy przyjmować pacjentów.”
Co poradzilibyśmy w podobnej sytuacji
- Kopia zapasowa widoczna jako dysk sieciowy nie chroni przed ransomware. Co najmniej jedna kopia musi być niezmienialna i niedostępna z sieci.
- Czas odtworzenia ustal według potrzeb biznesu: ile godzin możesz pracować bez systemu. Z tego wynikają częstotliwość kopii i układ przechowywania.
- Testuj odtwarzanie regularnie i spisuj raporty. Kopia zapasowa bez testu to tylko założenie.
- Po incydencie najpierw oczyść środowisko, a dopiero potem przenoś kopie, inaczej skopiujesz także dostęp atakującego.
