Zanim ransomware przetestuje Twoje backupy, sprawdź trzy rzeczy samodzielnie: czy ktokolwiek może je usunąć, czy skradzione konto administratora może się do nich dostać oraz ile trwa realne odtworzenie w porównaniu z tym, co firma jest w stanie znieść.
Wytyczne NCSC dotyczące ograniczania ryzyka malware i ransomware są jednoznaczne. Aktualne kopie zapasowe to najskuteczniejszy sposób odzyskiwania danych po ataku ransomware, ransomware celowo je atakuje, żeby zwiększyć szansę na zapłatę okupu, a napastnicy niszczyli skopiowane pliki lub zakłócali odtwarzanie jeszcze przed uruchomieniem ataku. Testuj więc backupy tak, jak zrobiłby to atakujący.
Test 1: spróbuj usunąć własny backup
Przykłady poniżej wykorzystują Amazon S3 Object Lock. W innych środowiskach znajdź w swoim produkcie do backupu odpowiednik blokady niezmienności (immutability) lub retencji. Sprawdź, czy jest włączona, jaki jest okres retencji i kto może go skrócić lub zdjąć blokadę. Następnie spróbuj trwale usunąć dane jako zwykły użytkownik, jako Twój najbardziej uprzywilejowany administrator backupu oraz jako konto, które atakujący mógłby realnie przejąć. Zapisz, komu się udało.
W przypadku S3 pracuj w testowym bucketcie. Object Lock działa tylko w bucketach z włączonym S3 Versioning, więc zacznij od sprawdzenia tego. Użyj trybu governance, który AWS opisuje jako sposób na przetestowanie ustawień retencji przed utworzeniem okresu retencji w trybie compliance.
Nigdy nie włączaj trybu compliance w testowym bucketcie. W trybie compliance nie można zmienić trybu retencji ani skrócić jej okresu, a jedynym sposobem na wcześniejsze usunięcie obiektu zablokowanego w tym trybie jest usunięcie powiązanego konta AWS.
Wykonaj te próby zarówno przez konsolę, jak i przez API lub CLI, a następnie porównaj wyniki:
| Próba | Udokumentowany wynik |
|---|---|
| Trwałe usunięcie (żądanie z identyfikatorem wersji) przez użytkownika bez uprawnienia bypass | Access Denied, 403 Forbidden |
| Zwykłe usunięcie (bez identyfikatora wersji) | 200 OK oraz znacznik usunięcia (delete marker) na wierzchu |
Usunięcie z konsoli przez użytkownika z s3:BypassGovernanceRetention | Udaje się |
Drugi wiersz nie oznacza porażki: zablokowana wersja pozostaje, ponieważ okresy retencji nie uniemożliwiają tworzenia nowych wersji ani znaczników usunięcia. Niepokojący jest trzeci wiersz. Konsola S3 domyślnie dodaje nagłówek x-amz-bypass-governance-retention:true, więc każdy, kto ma to uprawnienie, może kilkoma kliknięciami skasować obiekty zablokowane w trybie governance.
Następnie wyślij to samo żądanie trwałego usunięcia jako ten użytkownik przez API lub CLI, bez tego nagłówka. AWS wymaga go przy każdym żądaniu, które nadpisuje tryb governance, więc wynikiem powinno być Access Denied. Jeśli operacja się powiedzie, sprawdź tryb retencji bucketa oraz ustawienia blokady na wersji obiektu.
Następnie sprawdź, kto może cofnąć blokadę
Wypisz wszystkie podmioty (principals), których polityki zezwalają na s3:BypassGovernanceRetention, w tym role, grupy i polityki inline. Zrób to samo dla s3:PutObjectLegalHold: legal hold nie ma daty wygaśnięcia, a każdy użytkownik z tym uprawnieniem może dowolnie nakładać i zdejmować blokady.
Usuń oba uprawnienia z kont, które atakujący mógłby realnie przejąć. W przypadku danych, których nie możesz stracić, rozważ tryb compliance ze świadomie dobranym okresem retencji.
Test 2: spróbuj dostać się do backupu z niewłaściwymi poświadczeniami
Niezmienne przechowywanie nic nie da, jeśli atakujący kontroluje konsolę, która nim zarządza. Spróbuj zalogować się do konsoli backupu i do magazynu danych jako administrator domeny, konto backup operatora i użytkownik IAM w chmurze, a potem sprawdź, czy każde z nich może usuwać dane lub zmieniać ustawienia retencji.
Wytyczne NCSC zalecają dla kont backupowych takie zabezpieczenia:
- Privileged Access Workstations oraz sprzętowe firewalle wymuszające allow listing adresów IP.
- MFA, przy czym metoda MFA nie może być zainstalowana na urządzeniu używanym do administrowania backupami.
- Privileged Access Management, aby administratorzy nie łączyli się bezpośrednio z systemami backupu o wysokiej wartości.
Dyski backupowe i pendrive'y nie powinny być na stałe podłączone do sieci, a produkty do backupu wymagają aktualizacji. W przypadku usługi w chmurze upewnij się, że poprzednie wersje są chronione przed natychmiastowym usunięciem i że możesz do nich przywrócić dane, ponieważ usługi często synchronizują się zaraz po tym, jak Twoje pliki zostaną zastąpione zaszyfrowanymi kopiami.
Test 3: odtwórz coś ze stoperem w ręku
Wybierz system, którego firmie zabrakłoby w ciągu doby, i odtwórz go z backupu do czystego, odizolowanego środowiska, aby odtworzona infekcja nie dotarła do systemów produkcyjnych. Zapisz upływający czas, kto co robił oraz każdy moment, w którym ktoś musiał szukać hasła, klucza licencyjnego lub dokumentu znajdującego się na odtwarzanych serwerach.
Jeśli odtwarzanie zakończy się niepowodzeniem w trakcie, zapisz krok, czas, przyczynę i poprawkę, a następnie zacznij od tego kroku od nowa i osobno zapisz pozostały czas. Zachowaj identyczne kroki między kolejnymi próbami, aby wyniki były porównywalne.
Przed odtwarzaniem podłączaj backupy wyłącznie do znanych, czystych urządzeń i przeskanuj je pod kątem malware, zanim przywrócisz pliki. Ransomware mógł zreplikować się do backupów, zanim go wykryto, więc punkt przywracania, który wygląda na czysty, może taki nie być.
Porównaj zmierzony czas z tym, jaki firma deklaruje jako akceptowalny. Zdobądź tę liczbę od właściciela systemu przed testem, żeby nie dopasowywać celu do wyniku. Pełne odtworzenie po ataku ransomware, o ile w ogóle jest możliwe, może trwać kilka tygodni, więc traktuj wynik dla pojedynczego systemu jako dolną granicę.
Na papierze przeanalizuj, co się stanie, jeśli zarówno systemy lokalne, jak i serwery backupu w chmurze będą niedostępne, a Ty będziesz musiał odbudować środowisko z backupów offline, oraz jak utrzymasz działanie krytycznych usług biznesowych. Sprawdź, czy playbooki, checklisty i dane kontaktowe znajdują się w miejscu dostępnym bez korzystania z Twoich systemów komputerowych. Nasza usługa reagowania na incydenty obejmuje tego typu ćwiczenia, jeśli chcesz uzyskać spojrzenie z zewnątrz.
Od czego zacząć
- Wybierz jeden krytyczny dla biznesu system i zapytaj jego właściciela, jak długo może być niedostępny. Zapisz tę liczbę jako pierwszą.
- Utwórz testowy bucket S3 z versioningiem i Object Lock w trybie governance, nigdy compliance. Spróbuj wykonać trwałe usunięcie i zwykłe usunięcie, a odpowiedzi zapisz.
- Powtórz trwałe usunięcie jako użytkownik z
s3:BypassGovernanceRetention, z konsoli oraz z API lub CLI bez nagłówka bypass. Następnie wypisz wszystkich posiadaczy tego uprawnienia is3:PutObjectLegalHold, a tym, którzy ich nie potrzebują, odbierz je. - Spróbuj zalogować się do konsoli backupu jako administrator domeny, backup operator i użytkownik IAM w chmurze. Tam, gdzie logowanie się udało, zaplanuj MFA na oddzielnym urządzeniu i allow listing adresów IP. Potwierdź, że istnieje kopia offline, że nie jest stale podłączona i że wykonano już z niej odtworzenie.
- Odtwórz wybrany system do odizolowanego środowiska z przeskanowanego backupu, mierząc czas każdego kroku, i porównaj wynik z liczbą z kroku 1.
- Usuń największą lukę, a testy powtarzaj za każdym razem, gdy zmienia się architektura backupu.
