Jak interpretować User & Device Insights w Sophos Firewall

Control Center > User & device insights to widok do wstępnej analizy, a nie jeden wspólny alarm. Kafelki korzystają z różnych źródeł i okresów. Czerwony endpoint, wysoki User Threat Quotient (UTQ), błąd TLS i wiele sesji mogą mieć wspólną przyczynę, ale nie muszą.

Bezpieczna kolejność: zapisać kafelek i okres, otworzyć szczegóły, skorelować użytkownika/IP/hostname oraz czas z logami i faktycznie dopasowaną regułą, a dopiero potem zmieniać policy lub wyjątek. Przed zmianą zachować zrzut lub eksport, filtry, licznik błędów, cel, właściciela i oczekiwany wynik.

Co każdy sygnał potwierdza, a czego nie

• Security Heartbeat pokazuje stan przesłany przez endpointy Sophos. Nie potwierdza blokady każdego połączenia ani pełnego braku zagrożeń na zielonym urządzeniu.
• Synchronized Application Control pokazuje aplikacje zgłoszone przez zarządzane urządzenia. Wpis potwierdza wykrycie, nie egzekwowanie policy ani złośliwą aktywność.
• Zero-day protection zlicza przeanalizowane pliki i ustalenia. Licznik nie dowodzi, że każdy download był widoczny lub szkodliwy.
• UTQ priorytetyzuje konta na podstawie siedmiu dni przeglądania. To wskazówka, nie dowód winy ani kompromitacji.
• SSL/TLS connections opisuje obserwowane połączenia i wybrane błędy deszyfrowania. Procenty nie dowodzą ochrony pojedynczego przepływu.
• Firewall sessions pokazuje aktywne połączenia i zbliżanie się do pojemności. Wysoka liczba sama nie potwierdza ataku ani przeciążenia.

Zawsze szukać co najmniej dwóch zgodnych dowodów, np. kafelka i szczegółowego logu albo zdarzenia endpointu i Firewall Rule ID. Dla aktywnych przepływów użyć Live Connections i Connection List.

Sprawdzanie Security Heartbeat i aplikacji

Stany to At risk (czerwony) — aktywne malware; Missing (czerwony) — endpoint generuje ruch, ale nie przesyła stanu zdrowia; Warning (żółty) — malware nieaktywne albo wykryte i usunięte; Connected (zielony) — nie wykryto malware, endpoint zgłasza prawidłowy stan.

Kafelek zlicza wszystkie stany, lecz szczegóły pokazują tylko czerwone i żółte endpointy z hostname, IP, użytkownikiem oraz czasem od zmiany. Gdy wszystkie są zielone, widok pozostaje pusty. Nie jest to błąd ani pełny inwentarz.

Jeśli endpoint opuści sieć, gdy jego Heartbeat ma stan Missing, stan ten pozostaje w Control Center i raportach. Zmieni się dopiero po ponownym połączeniu endpointu. Przed usunięciem potwierdzonego nieaktualnego wpisu zapisać nazwę endpointu, wiek stanu, ostatniego znanego użytkownika i czas oraz bieżący widok w Control Center i raporcie. Najpierw zakończyć analizę przyczyny, następnie otworzyć CLI i wybrać 4. Device Console. Można usunąć wszystkie wpisy Missing, które osiągnęły lub przekroczyły określony wiek od 1 do 90 dni, albo wpis o dokładnej nazwie endpointu:

system synchronized-security missing-endpoints delete days-missing 7
system synchronized-security missing-endpoints delete name endpoint1

7 i endpoint1 to przykłady, które należy zastąpić zatwierdzonym wiekiem lub dokładną nazwą. Polecenie według wieku obejmuje wszystkie wpisy pozostające Missing przez podaną liczbę dni lub dłużej i może usunąć z Control Center i raportów więcej urządzeń niż zamierzono; polecenie według nazwy ma węższy zakres dla jednego znanego wycofanego urządzenia. Usunięcie nie naprawia endpointu ani Heartbeat i nie przywraca usuniętej historii. Następnie ponownie wczytać Control Center i odpowiedni raport, potwierdzić zniknięcie tylko zamierzonych wpisów, a dla nadal używanego urządzenia sprawdzić ponowne połączenie i nowy stan Heartbeat.

Dla czerwonego lub żółtego wpisu najpierw sprawdzić czas i endpoint w Sophos Fusion (dawniej Sophos Central), następnie ustalić, czy dopasowana reguła zawiera warunek Heartbeat. Sama widoczność nie blokuje ruchu. Łączenie Sophos Firewall z Sophos Fusion opisuje wymagania i egzekwowanie; analiza Missing Heartbeat obejmuje trwałe stany.

Kafelek Synchronized Application Control pokazuje New, Categorized i sumę oraz otwiera Applications > Synchronized Application Control. Nową aplikację ocenić według urządzenia, użytkownika i czasu, skategoryzować, a dopiero potem sterować nią za pomocą odpowiedniego filtra aplikacji (Application Filter). Bezpośrednie czyszczenie bazy nie jest krokiem triage; dla problemów zbierania lub przestrzeni stosować bezpieczną procedurę. Przypisanie reguł opisuje Application Control.

Interpretacja liczników Zero-day i UTQ

Kafelek Zero-day wymaga aktywnej subskrypcji Zero-Day Protection. W Administration > Licensing moduł musi mieć stan Subscribed lub Evaluating; bez subskrypcji łącze w Control Center umożliwia rozpoczęcie bezpłatnej 30-dniowej oceny.

Okresy są różne: Recent obejmuje nowe raporty malicious, suspicious lub PUA z siedmiu dni; Incidents zlicza wszystkie takie pliki, a raporty przechowuje do sześciu miesięcy, konfigurowalnie w Report settings > Data management; Scanned obejmuje cały wykryty ruch, również czyste pliki, zależnie od retencji wpisów bazy.

Nie odejmować liczników od siebie. Otworzyć Zero-day protection > Downloads and attachments i skorelować plik, werdykt, użytkownika/IP, czas oraz ścieżkę web lub mail. Brak wykrycia może wynikać też z licencji, policy, nieodszyfrowanego ruchu lub retencji. Zobacz przewodnik Zero-day Protection.

UTQ analizuje siedem dni przeglądania. Pokazuje brak ryzykownych użytkowników albo liczbę użytkowników odpowiadających łącznie za 80 procent ryzyka sieci. W Reports > Dashboards sprawdzić użytkowników, Threat Score, kategorie, cele, czas i jakość identyfikacji. Wspólne konto, NAT lub brak uwierzytelniania zniekształcają przypisanie; wysoki wynik nie uzasadnia automatycznej blokady.

Bezpieczna analiza SSL/TLS connections

Szczegóły aktualizują się co pięć minut. Jeśli brakuje ich w Control Center i Log Viewer, sprawdzić SSL/TLS inspection w Rules and policies > SSL/TLS inspection rules oraz Enabled w SSL/TLS inspection settings > Advanced settings > SSL/TLS engine.

Of traffic to udział SSL/TLS w całym ruchu; Decrypted — udział odszyfrowanych połączeń SSL/TLS; Failed — liczba niepowodzeń. Failed zeruje się o północy lub ręcznie przez Reset ‘Failed’ count. Ręcznego resetu nie można cofnąć ani odzyskać poprzedniej wartości. Najpierw zapisać wartość, czas i test; potem powtórzyć przepływ, odczekać cykl i sprawdzić logi. Reset nie usuwa przyczyny.

Drill-down pokazuje sesje z ostatnich 24 godzin i błędy z ostatnich 7 dni. Oba zbiory wykluczają połączenia przez web proxy. Top websites oraz Top users lub IP zawężają problem; kliknięcie liczby otwiera filtrowane logi z celem w Server name. Lista zawiera tylko błędy potencjalnie rozwiązywalne regułą SSL/TLS lub wskazujące brak zaufania do CA/aplikacji na kliencie, bez blokad Web Policy i innych Security Policies.

W Fix errors opcja Hide ukrywa witrynę, użytkownika lub IP bez zmiany deszyfrowania; Show hidden i Unhide to odwracają. Zapisać filtr, aby nie pomylić ukrycia z naprawą.

Exclude from decryption to zmiana bezpieczeństwa. Add domain lub Add subdomain dodaje cel do grupy Local TLS exclusion list, edytowanej w Web > URL groups. Najpierw zapisać dokładny FQDN, klientów, Error ID, właściciela, datę wygaśnięcia oraz test pozytywny i negatywny. Gdy dotyczy jednego hosta, wybrać bardziej szczegółową subdomenę. Następnie potwierdzić działanie aplikacji, brak deszyfrowania tego przepływu i dalsze stosowanie reguły TLS do innych domen. Zobacz etapowe wdrażanie TLS Inspection.

Rollback polega na usunięciu tylko dokładnie dodanego wpisu po potwierdzeniu właściciela i bieżącego użycia. Powtórzyć test i obserwować nowe błędy trust/TLS. Nie usuwać współdzielonego lub istniejącego wcześniej wyjątku.

Sesje firewalla i pojemność deszyfrowania

Wykres oferuje Live, 24h, 48h, Week, Month i Year. Live odświeża się co 30 sekund, pozostałe co pięć minut. Kategorie: Other traffic, Undecrypted SSL/TLS i Decrypted SSL/TLS.

Decryption peak to maksimum równocześnie odszyfrowywanych połączeń w okresie i pojawia się tylko, gdy ruch zbliża się do tego poziomu lub go przekracza. Decryption limit to pojemność modelu i także pojawia się dopiero blisko limitu. Brak linii nie oznacza nieskończonej pojemności. Krótki skok nie dowodzi przeciążenia: porównać okresy i powtarzalność z opóźnieniami, zasobami, dropami i błędami użytkowników.

Walidacja i wycofywanie zmian

1. Zachować wartość bazową, okres, filtry, użytkownika/IP/hostname, Error ID i Rule ID.
2. Testować jedną hipotezę możliwie wąską zmianą.
3. Powtórzyć identyczny test pozytywny; dla wyjątku także negatywny poza zakresem.
4. Uwzględnić interwał aktualizacji i porównywać szczegółowe logi, nie tylko procenty.
5. Bez poprawy wycofać zmianę i sprawdzić źródło, okres, web proxy, uwierzytelnianie i dopasowanie reguły.

Hide/Unhide jest w pełni odwracalne. Nowy wyjątek TLS wycofuje się, usuwając dokładnie ten wpis, jeśli nikt inny go nie używa. Ręcznie wyzerowanego licznika Failed nie można przywrócić; wcześniejszy zapis jest jedynym wiarygodnym odniesieniem historycznym.