Sophos Incident Response, Readiness i oceny bezpieczeństwa

Przy aktywnym lub podejrzewanym incydencie bezpieczeństwa uruchamia się ustalony proces incydentowy. Trwający atak nie jest zwykłym projektem wdrożeniowym. Korzysta się z kontaktu wskazanego w planie awaryjnym i potwierdzonego uprawnienia do usługi, zamiast najpierw zamawiać ocenę lub nowy retainer.

Digital Forensics and Incident Response (DFIR) łączy analizę informatyki śledczej z reakcją na konkretny incydent. Readiness przygotowuje ludzi i procedury. Security Testing i oceny bezpieczeństwa badają wcześniej określony zakres. Usługi te mają różne rezultaty i nie zastępują się wzajemnie.

Prawidłowo przekazać incydent

Sophos opisuje DFIR jako pomoc w identyfikacji i neutralizacji aktywnych zagrożeń, analizie przyczyn, Compromise Assessment i Threat Hunting. Faktyczna praca zależy od zleconej usługi i potwierdzonego uprawnienia. Opis zespołu dostępnego całą dobę nie jest indywidualną obietnicą czasu rozpoczęcia, obecności na miejscu lub długości odtwarzania.

Na pierwsze przekazanie przygotowuje się krótki i weryfikowalny obraz sytuacji:

1. Kontakty i uprawnienia decyzyjne: techniczny kierownik incydentu, osoby odpowiedzialne biznesowo i zatwierdzony kanał zwrotny.
2. Obserwacje zamiast założeń: czas ze strefą, dotknięte systemy lub tożsamości, konkretne komunikaty i widoczne skutki.
3. Już podjęte środki: np. izolacja, ograniczenia kont lub odtwarzanie, wraz z czasem i wykonawcą.
4. Dostępne dowody: logi, identyfikatory spraw i istniejące kopie wraz z pochodzeniem i miejscem przechowywania. Nieznaną kompletność zaznacza się wprost.
5. Uprawnienie i zakres: klient, umowa lub retainer i znany obszar objęty incydentem. Niepotwierdzonego uprawnienia nie przedstawia się jako istniejącego.

To zalecenie Avanet dotyczące organizacji przekazania, a nie pełna procedura informatyki śledczej. Umożliwia pierwszą obsługę bez utraty ważnych informacji wskutek przedwczesnych zmian. Zainfekowanych systemów nie reinstaluje się tylko po to, by uzyskać „czysty punkt wyjścia”. O izolacji, wyłączeniu, zabezpieczeniu dowodów i odtworzeniu decydują odpowiedzialni za incydent stosownie do przypadku.

Dowody mogą zawierać hasła, dane osobowe lub poufne informacje biznesowe. Przekazuje się tylko potrzebne dane potwierdzonym bezpiecznym kanałem. Publiczne zgłoszenie, czat lub niechroniony link do pliku nie są właściwą alternatywą. Jeśli konta komunikacyjne mogą być przejęte, przed przekazaniem uzgadnia się zaufany kanał odpowiedzi.

Rozróżnić MDR i DFIR

MDR to ciągła usługa zarządzana obejmująca wyszukiwanie zagrożeń, wykrywanie i uzgodnioną reakcję. DFIR obsługuje konkretny incydent w potwierdzonym zakresie dochodzenia. Nawet gdy oba oferuje ta sama organizacja, alert produktu nie zamawia automatycznie DFIR ani nie daje prawa do nieograniczonego badania.

W istniejącym MDR decydują kontakty i tryb Threat Response oraz rzeczywisty właściciel sprawy i wymagana akcja klienta. Sprawa customer-managed nie jest automatycznie badana przez zespół MDR tylko dlatego, że istnieje licencja Sophos. Otwarte działania klienta potrzebują właściciela i nie znikają wskutek domniemanej zmiany usługi.

Security Services Retainer wyjaśnia Service Units i szczególne warunki DFIR. Saldo SU nie jest ogólnym czasem reakcji ani gwarancją zamknięcia incydentu w określonej liczbie godzin. Istniejące prawa weryfikuje się w konkretnych umowach.

Readiness: przećwiczyć reakcję wcześniej

Przygotowanie oznacza gotowość odpowiedzialności, dostępów i ścieżek decyzyjnych przed wystąpieniem incydentu. Tabletop Exercise to moderowane ćwiczenie scenariuszowe: zespół omawia decyzje i przekazania bez przeprowadzania prawdziwego ataku w produkcji.

Określa się cel i uczestników, np. współpracę IT, zarządu i komunikacji przy przejęciu tożsamości administratorów. Ćwiczenie powinno ustalić, kto ogłasza incydent, kto zatwierdza ograniczenie zagrożenia, jak komunikować się poza potencjalnie dotkniętymi systemami i jak podejmować decyzje o odtwarzaniu. Wynikiem są udokumentowane obserwacje oraz konkretne poprawki z właścicielami i terminami.

Istniejący plan awaryjny nie dowodzi sam w sobie sprawnego odtwarzania ani osiągalności kontaktów. Avanet zaleca po istotnych zmianach ponownie sprawdzić łańcuch kontaktów i zatwierdzeń oraz odpowiednią procedurę odtwarzania. Sama rozmowa nie zastępuje osobno zaplanowanego technicznego testu przywracania.

Dobrać oceny i testy bezpieczeństwa

External Penetration Testing bada dostęp z zewnątrz. Testy wewnętrzne mogą ustalić, co jest możliwe przy istniejącym dostępie do sieci. Testy wireless analizują ścieżki Wi-Fi, a Web Application Assessment — aplikacje i ich konkretne słabości. Nazwa usługi nie gwarantuje objęcia każdej placówki, aplikacji czy interfejsu.

Ocena nie jest też dowodem całkowitego braku naruszenia. Compromise Assessment szuka oznak włamania w uzgodnionym zakresie; test penetracyjny sprawdza wybrane ścieżki ataku. Oba różnią się od ciągłej obsługi Managed Risk i reakcji na aktywny już incydent.

Przed testem pisemnie określa się cele i wyłączenia, zgody właścicieli, dozwolone metody, okna czasowe, dostęp do danych i kryteria przerwania. Dla systemów chmurowych lub innych podmiotów potrzebna jest właściwa zgoda na test. Musi istnieć osiągalny kontakt do przerwania prac; dostępność i wpływ na produkcję uwzględnia się wyraźnie. Bez jasnej zgody test nie startuje.

Wynik obejmuje zrozumiałe ustalenia: dotknięte systemy, dowody, skutki i priorytety napraw. Powtórny test sprawdza uzgodnione naprawione punkty; oferta potwierdza, czy jest wliczony, kiedy i w jakim zakresie. Raport nie jest certyfikatem przyszłej odporności na każdy atak. Wdrożenie i odbiór poprawek pozostają osobnymi, widocznymi zadaniami.

Przy planowanych zmianach po ustaleniach pomaga rozróżnienie TAM, wsparcia i Deployment Services. Dzięki temu zalecenie staje się określonym zleceniem z przekazaniem technicznym, zamiast przerzucania otwartych ryzyk między dostawcami.