Przegląd raportów Sophos Managed Risk i usuwanie luk

Sophos Managed Risk co tydzień tworzy raporty dotyczące luk i zewnętrznej powierzchni ataku. W sekcji My Products > Managed Risk > Report History można je pobrać, zawęzić zakres systemów, których dotyczą, i określić kolejne kroki. Managed Risk zaleca działania naprawcze. Zmiany na serwerach, w aplikacjach, urządzeniach sieciowych lub zasobach chmurowych trzeba jednak wdrażać w kontrolowany sposób we własnej organizacji.

Skrócony przebieg:

1. Sprawdź powiadomienie o nowym raporcie i otwórz Report History bezpośrednio we właściwym tenantcie Sophos Fusion (dawniej Sophos Central).
2. Na karcie External, Internal lub Account znajdź oczekiwany raport tygodniowy na podstawie nazwy i kontekstu skanowania.
3. Otwórz raport luk w formacie HTML do wstępnej oceny; w razie potrzeby użyj też CSV i PDF.
4. Najpierw sprawdź wysokie ryzyka i zasoby krytyczne. Następnie zweryfikuj zasób, podstawę wykrycia i zalecenie Sophos.
5. Poza Managed Risk ustal właściciela systemu lub usługi, zaplanuj zmianę i zweryfikuj ją technicznie.
6. Pytania lub problemy dotyczące wyników skanowania i raportów zgłaszaj do zbadania w sprawie Managed Risk; zalecenia naprawcze omawiaj podczas regularnego przeglądu z zespołem Managed Risk.

Wybór właściwego typu i formatu raportu

Sekcja Report History jest podzielona na trzy karty. Nazwa pliku wskazuje, z którego przebiegu pochodzi raport:

Elementy Account_Name i Scan_name oznaczają odpowiednio nazwę konta i skanu. Są to symbole zastępcze, które trzeba dopasować do nazw we własnym tenantcie.

Formaty służą różnym celom:

• HTML to najlepszy widok roboczy do wstępnej oceny. Pokazuje aktywne i usunięte luki według poziomu ryzyka i zasobu oraz udostępnia interaktywne filtry.
• CSV nadaje się do ustrukturyzowanej analizy i porównania z wewnętrzną dokumentacją wykonanych prac. Raporty ASM i Discovery są dostępne wyłącznie jako CSV.
• PDF to statyczna, czytelna wersja raportu luk. Do zawężania wyników do poszczególnych zasobów zwykle lepiej nadaje się HTML.

Plik CSV ASM lub Discovery nie jest raportem luk w innym formacie. ASM opisuje wykrytą zewnętrzną powierzchnię ataku, a Discovery — zasoby znalezione w wewnętrznym skanie wykrywania. Oba mogą pomóc określić zakres dalszych kontroli, lecz nie zawierają tej samej analizy co raport luk.

Wyszukiwanie raportu tygodniowego i kontrola pobrania

1. Otwórz My Products > Managed Risk > Report History.
2. Wybierz odpowiednią kartę: External, Internal lub Account.
3. Wyszukaj oczekiwany raport tygodniowy na podstawie udokumentowanego wzorca nazwy i właściwego skanu.
4. W kolumnie Download report kliknij łącze wymaganego formatu.
5. Otwórz pobrany plik i przed oceną sprawdź, czy konto lub skan oraz typ raportu odpowiadają zadaniu przeglądu.

Sophos wysyła powiadomienie o dostępności nowych raportów. Powiadomienie inicjuje przegląd, ale źródłem rozstrzygającym jest Report History. Oczekiwany raport musi być dostępny do pobrania na właściwej karcie. Gdy istnieje kilka skanów wewnętrznych, porównanie nazwy skanu zapobiega przypadkowej ocenie raportu z innego segmentu sieci.

Jeśli oczekiwanego raportu brakuje, najpierw sprawdź tenant, wybraną kartę, wzorzec nazwy i właściwy skan. Następnie ustal, czy powiadomienie rzeczywiście dotyczy bieżącego przebiegu tygodniowego. Jeśli rozbieżność nie zniknie, zanotuj nazwę raportu, kartę, oczekiwany skan i czas powiadomienia na potrzeby zgłoszenia do zespołu Managed Risk. Nie umieszczaj w nim danych dostępowych ani innych tajnych informacji.

Każdy raport ze skanowania pozostaje dostępny w Sophos Fusion przez maksymalnie dwa lata od daty zakończenia danego skanu. Jest przeznaczony wyłącznie do użytku wewnętrznego klienta lub dostawcy MSP i nie może być dalej rozpowszechniany, odsprzedawany ani w inny sposób przekazywany poza jego organizację.

Filtrowanie i ustalanie priorytetów w raporcie HTML

Pobierz raport luk w formacie HTML i otwórz go lokalnie. W tym widoku wyniki można filtrować według Risk level, Device type i IP address.

Raport Account dodaje filtry typów skanowania i poszczególnych skanów. Podsumowuje dane zewnętrznego skanu luk i wszystkich wewnętrznych skanów luk. Nadaje się więc do przekrojowego ustalania priorytetów, ale w szczegółowych kwestiach nie zastępuje analizy odpowiedniego raportu indywidualnego.

Wstępną ocenę zacznij od najwyższych poziomów ryzyka, a następnie zawęź wyniki według zasobu, typu urządzenia lub skanu. Sam poziom ryzyka nie określa jednak kolejności. System dostępny z Internetu lub zasób krytyczny dla działalności może być pilniejszy niż izolowany system testowy na tym samym poziomie. Sprawdź też, czy kilka wpisów nie dotyczy tej samej przyczyny technicznej na tym samym zasobie.

Rozpoznawanie zasobów krytycznych

Po lewej stronie raportu HTML znajduje się lista Assets. Po umieszczeniu wskaźnika myszy nad nazwą odpowiednio oznaczonego systemu wyskakujące okno pokazuje etykietę Critical Asset, a niżej Critical Asset Description. Opcja Show critical assets only ogranicza widok do luk dotyczących zasobów krytycznych. Widżety u góry pokazują wtedy liczbę powiązanych luk i zasobów, których one dotyczą.

Oznaczenie zapewnia kontekst biznesowy, ale nie rozstrzyga automatycznie o konkretnym sposobie usunięcia luki. Opis, rzeczywistą funkcję i obecnego właściciela systemu nadal trzeba porównać z własną dokumentacją zasobów.

Skany mogą dawać wyniki fałszywie dodatnie i fałszywie ujemne. Sophos nie gwarantuje ponadto, że zapewniają one pełny i dokładny obraz luk w zabezpieczeniach. Dlatego wynik wymaga weryfikacji technicznej; z kolei brak wyniku nie dowodzi, że luka nie istnieje. Nie należy polegać wyłącznie na skanach.

Od wyniku do bezpiecznego usunięcia luki

Wpis w raporcie jest punktem wyjścia do oceny technicznej, a nie zatwierdzoną zmianą. Wszelkie działania podejmowane na podstawie sugestii Sophos dotyczących instalowania poprawek i usuwania luk wykraczają poza zakres usługi; wyłączną odpowiedzialność za ich wykonanie i skutki ponosi klient lub dostawca MSP. Dla każdego wyniku o wysokim priorytecie wykonaj następujący cykl:

1. Potwierdź zasób: porównaj adres IP, nazwę hosta, typ urządzenia, typ skanu i — jeśli dotyczy — opis zasobu krytycznego z aktualną dokumentacją. Jeśli nie można zidentyfikować zasobu, nie wprowadzaj zmian na podstawie przypuszczeń.
2. Zrozum wynik: przeczytaj poziom ryzyka, nazwę składnika i informacje lub dowody zawarte w raporcie. Sprawdź, czy raport pochodzi ze skanu zewnętrznego, wewnętrznego, uwierzytelnionego czy nieuwierzytelnionego; różne typy skanów mogą zapewniać różny poziom szczegółowości.
3. Oceń zalecenie: porównaj poprawkę zalecaną przez Sophos z instrukcjami producenta, używaną wersją, zależnościami i rzeczywistym stanem systemu. Ogólne zalecenie, takie jak aktualizacja lub zmiana konfiguracji, musi pasować do produktu i własnego środowiska.
4. Ustal właściciela technicznego: zidentyfikuj osobę odpowiedzialną za system, aplikację, sieć lub chmurę w ramach własnego procesu operacyjnego. Report History nie dokumentuje funkcji przypisywania; zapis prac i zatwierdzenie zmiany powinny zatem znaleźć się we właściwym systemie wewnętrznym.
5. Zabezpiecz zmianę: przed wdrożeniem określ wpływ, okno serwisowe, kopię zapasową lub możliwość wycofania oraz odpowiedni test funkcjonalny. Szczególnie w przypadku zasobów produkcyjnych lub krytycznych poziom ryzyka nie uzasadnia pomijania zależności.
6. Usuń lukę i zweryfikuj: po zatwierdzonej zmianie sprawdź wersję lub konfigurację systemu docelowego i przetestuj właściwą funkcję. Sam wpis w raporcie nie dowodzi prawidłowego działania systemu.
7. Sprawdź kolejny raport: w następnym dostępnym raporcie ponownie zbadaj ten sam skan i zasób. Zmieniony raport jest dodatkowym dowodem, ale nie zastępuje technicznej kontroli systemu ani gwarantowanej funkcji ponownego skanowania lub zamknięcia.

Na potrzeby własnej dokumentacji prac zapisz weryfikowalne fakty: raport i tydzień, skan, zasób, lukę, sprawdzone zalecenie, odpowiedzialny obszar techniczny, zatwierdzoną zmianę i wynik walidacji technicznej. Nie wyprowadzaj z nich pól ani stanów Managed Risk, których nie udokumentowano w interfejsie.

Ograniczenie funkcji raportowania: dla widoku raportów Managed Risk nie udokumentowano przypisywania, akceptacji ryzyka, ręcznie uruchamianej ponownej kontroli, zamykania ani zarządzania SLA. Procesy te mogą być potrzebne wewnętrznie, ale nie są gwarantowanymi mechanizmami ani stanami produktu Managed Risk. Określenia “active” i “resolved” w raporcie HTML również nie oznaczają stanu zgłoszenia, którym może sterować administrator.

Korzystanie z zaleceń i regularnych przeglądów

Zespół Managed Risk analizuje raporty, wydaje zalecenia i omawia bieżące wyniki, nowe ryzyka oraz rekomendowane działania podczas regularnych spotkań. W ramach przygotowania zbierz nierozwiązane wyniki wysokiego ryzyka, zasoby, których dotyczą, sprawdzone już fakty techniczne i konkretne pytania. Pozwoli to ustalić, czy trzeba wyjaśnić wykrycie, doprecyzować kontekst skanowania lub ocenić alternatywne działanie.

Sprawa Managed Risk jest udokumentowaną drogą postępowania, gdy własny zespół nie potrafi wyjaśnić pytań lub problemów dotyczących wyników skanowania luk albo raportów. Dotyczy to na przykład sytuacji, gdy:

• wynik skanowania wysokiego ryzyka jest niejasny lub niewiarygodny,
• raport różni się od bieżącego stanu systemu,
• kontekst skanowania, wykrycie lub treść raportu budzą pytania.

Pytania dotyczące zalecanej poprawki można również przygotować na regularny przegląd z zespołem Managed Risk. Sprawa nie zastępuje wewnętrznego zatwierdzenia zmiany ani nie stanowi gwarantowanego odbioru lub zamknięcia działań naprawczych.

Zgłoszenie powinno zawierać dokładną nazwę raportu, kartę i tydzień, właściwy skan, zasób, daną lukę, zaobserwowaną rozbieżność oraz wykonane już bezpieczne kontrole. Nie przesyłaj haseł, kluczy prywatnych ani innych tajnych informacji.

Oddzielenie usuwania luk od aktywnej reakcji na incydent

Managed Risk jest usługą zarządzania lukami i wymaga istniejącej licencji MDR lub MDR Plus. Standardowy proces opisany w tym artykule ocenia luki, planuje utwardzanie lub aktualizacje i sprawdza ich skutki techniczne. Nie jest to tym samym co reakcja na aktywne naruszenie zabezpieczeń.

Jeśli dochodzenie ujawni oznaki trwającego nadużycia, aktywne zagrożenie lub już przejęte systemy, nie czekaj na raport z następnego tygodnia. Zastosuj uzgodnioną ścieżkę reagowania na incydenty lub eskalacji MDR. Raport luk może dostarczyć kontekstu, lecz nie zastępuje zbadania incydentu, ograniczenia jego zasięgu ani przywrócenia systemów.

Kontrola końcowa w każdym cyklu przeglądu

Na koniec każdego cyklu sprawdź, czy:

• przejrzano wszystkie oczekiwane raporty tygodniowe na kartach External, Internal i Account,
• typ, nazwa, skan i format raportu odpowiadają danej ocenie,
• w pierwszej kolejności oceniono technicznie wysokie ryzyka i luki w zasobach krytycznych,
• zasób i podstawa wykrycia są możliwe do prześledzenia,
• każde wdrożone działanie naprawcze zweryfikowano na systemie docelowym i odpowiednim testem funkcjonalnym,
• otwarte lub niejasne wyniki wysokiego ryzyka przygotowano dla zespołu Managed Risk wraz z konkretnymi pytaniami,
• oznak aktywnego zagrożenia nie połączono ze standardowym procesem usuwania luk.

Ta kontrola dokumentuje własny przegląd. Nie ustanawia końcowego stanu w Managed Risk ani gwarantowanego terminu, w którym zmiana pojawi się w późniejszym raporcie.