Konfiguracja i test powiadomień e-mail Sophos Firewall

Aby powiadomienia e-mail działały, Sophos Firewall wymaga dwóch oddzielnych konfiguracji: w sekcji Administration > Notification settings konfiguruje się transport poczty. W sekcji System services > Notification list określa się, które zdarzenia mają być faktycznie zgłaszane pocztą e-mail.

Ten transport wykorzystuje też raport kwarantanny dla użytkowników, ale jego harmonogram, link do portalu i przypisanie kont są oddzielnymi ustawieniami.

Widoczne teksty uwierzytelniania, SMTP, administracyjne i SMS w Administration > Messages stanowią trzeci, niezależny poziom. Konfiguracja komunikatu logowania i wiadomości w Sophos Firewall wyjaśnia ich treść i testy; zmiana wiadomości nie konfiguruje ani transportu SMTP, ani wyboru zdarzeń.

Szybka procedura:

Skonfiguruj serwer pocztowy, port, uwierzytelnianie, szyfrowanie, nadawcę i odbiorcę w sekcji Administration > Notification settings.
Wyślij wiadomość testową i potwierdź jej dostarczenie w docelowej skrzynce lub systemie śledzenia serwera pocztowego.
W sekcji System services > Notification list aktywuj globalny przełącznik Email notifications.
Wybierz tylko te zdarzenia, na które odpowiedzialny odbiorca może zareagować.
Oprócz wiadomości testowej wywołaj w kontrolowany sposób rzeczywiste wybrane zdarzenie i sprawdź jego dostarczenie.

Pomyślnie wysłana wiadomość testowa dowodzi jedynie, że tor SMTP zasadniczo działa. Nie potwierdza jeszcze, że aktywowano globalny przełącznik poczty i właściwe zdarzenia. Z drugiej strony wybrany wiersz zdarzenia nie wyśle wiadomości, dopóki nie działa transport poczty. Właśnie to rozdzielenie wyjaśnia, dlaczego sam skonfigurowany serwer SMTP nie spełnia jeszcze operacyjnie punktu Notification Emails w artykule Sophos Firewall Health Check.

Zmiana adresu odbiorcy przez Device Console

Jeśli WebAdmin jest niedostępny albo adres odbiorcy trzeba poprawić przez kontrolowany dostęp do konsoli, należy użyć 2. System Configuration > 3. Set Email ID for system notification. Ta opcja zmienia wyłącznie adres e-mail administratora dla alertów systemowych. Nie konfiguruje serwera pocztowego, nadawcy, uwierzytelniania i TLS ani globalnego przełącznika i zdarzeń na Notification list.

Najpierw należy udokumentować poprzedni adres. Następnie potwierdzić zmianę przez y, wprowadzić nowy adres i sprawdzić adres wyświetlony przez SFOS pod kątem literówek. Enter powoduje powrót do menu. Potem wiadomość testowa i kontrolowane rzeczywiste zdarzenie muszą dotrzeć do nowego odbiorcy; samo potwierdzenie w konsoli nie dowodzi dostarczenia.

Przygotowanie wysyłania poczty

Przed rozpoczęciem konfiguracji należy uzgodnić z administratorem poczty serwer, port i metodę uwierzytelniania. Jeśli używana jest nazwa FQDN, taka jak smtp.example.net, firewall musi móc ją rozwiązać i osiągnąć serwer przez przewidzianą trasę. Ogólne połączenie z Internetem jest potrzebne tylko wtedy, gdy wybrany serwer pocztowy lub dostawca OAuth znajduje się w Internecie. Wewnętrzny przekaźnik SMTP może działać także bez bezpośredniego dostępu firewalla do Internetu.

Realistyczny przykład:

Mailserver: smtp.example.net
Port: 587
Authentication: Basic
Connection security: STARTTLS
Sender: fw-zrh-01@example.net
Recipient: firewall-alerts@example.net
Management interface IP address: wewnętrzny interfejs zarządzający firewalla

Wszystkie wartości zawierające example.net należy zastąpić własną domeną i adresami zatwierdzonymi przez administratora poczty. Adres listy dystrybucyjnej jest zwykle lepszy od osobistej skrzynki: zakres odpowiedzialności można zmienić bez ponownej konfiguracji każdego firewalla.

Pole Management interface IP address nie określa, przez który interfejs połączenie SMTP opuszcza firewall. Wybrany adres IP jest dołączany do powiadomienia i pomaga zidentyfikować wysyłający firewall. Przy wielu lokalizacjach należy więc wybrać trwale zrozumiały adres IP do zarządzania; przy jednym firewallu może wystarczyć również None.

Konfiguracja serwera pocztowego

Wybór Built-in lub External email server

Sophos Firewall może korzystać z opcji Built-in email server albo External email server. Wbudowana wysyłka jest praktyczna na prosty początek. W środowiskach produkcyjnych własny przekaźnik lub chmurowy serwer pocztowy jest często łatwiejszy do monitorowania, ponieważ uwierzytelnianie, śledzenie poczty, uprawnienia nadawców i błędy dostarczania są widoczne w jednym centralnym miejscu.

Dlatego zalecamy External email server, jeśli dostępna jest już niezawodnie obsługiwana usługa SMTP.

Dla wbudowanej wysyłki wystarczy ta krótka procedura:

W sekcji Administration > Notification settings aktywuj Built-in email server.
Wprowadź nadawcę, odbiorcę i opcjonalnie Management interface IP address.
Zapisz ustawienia i wyślij wiadomość testową.

W przypadku Built-in email server nie ma własnego systemu śledzenia przekaźnika, w którym administrator może sprawdzić przyjęcie i przekazanie wiadomości. Dlatego rzeczywiste dostarczenie należy skontrolować szczególnie uważnie. Jeśli wielokrotnie się nie powiedzie albo domena odbiorcy i wymagania bezpieczeństwa wymagają kontrolowanego toru SMTP, External email server jest łatwiejszym w utrzymaniu wariantem.

Konfiguracja External email server

Otwórz Administration > Notification settings.
Wybierz External email server.
Wprowadź adres IPv4 lub FQDN serwera pocztowego oraz wskazany port.
W sekcji Authentication wybierz odpowiednio do serwera None, Basic albo OAuth 2.0.
W sekcji Connection security ustaw szyfrowanie transportu wymagane przez serwer pocztowy.
Wprowadź nadawcę, odbiorcę i opcjonalnie Management interface IP address.
Zapisz ustawienia i uruchom funkcję wiadomości testowej.

Domyślnym portem w SFOS jest 25, ale nie jest on zaleceniem dla każdego środowiska. Decydujący jest listener własnego przekaźnika. Typowe wartości to 25 dla wewnętrznego przekaźnika dopuszczonego na podstawie źródłowego adresu IP, 587 dla uwierzytelnionego przesyłania z STARTTLS albo 465 dla bezpośredniego SSL/TLS. Port, uwierzytelnianie i tryb szyfrowania muszą jako zestaw pasować do serwera pocztowego.

None nie oznacza tego samego w obu polach wyboru: w sekcji Authentication wyłącza logowanie do serwera pocztowego. Może to być prawidłowe w przypadku wewnętrznego przekaźnika, który dopuszcza wyłącznie źródłowy adres IP firewalla. W sekcji Connection security None oznacza natomiast nieszyfrowaną transmisję SMTP. To ustawienie nie nadaje się do połączeń przez Internet i również wewnętrznie powinno być używane tylko wtedy, gdy model bezpieczeństwa wyraźnie na to pozwala.

W przypadku Basic firewall używa nazwy użytkownika i hasła. Według Sophos nazwa użytkownika rozróżnia wielkość liter. Przekaźnik musi obsługiwać używaną metodę logowania; komunikat o błędzie dotyczącym Authentication method wskazuje w szczególności na rozbieżność w obsłudze LOGIN lub PLAIN.

STARTTLS można łatwo źle zrozumieć: firewall dostosowuje się do możliwości serwera pocztowego. Jeśli serwer oferuje STARTTLS, połączenie jest szyfrowane; jeśli go nie oferuje, wiadomość może zostać przesłana bez szyfrowania. Jeśli szyfrowanie musi być wymuszone, należy użyć SSL/TLS z odpowiednim portem i listenerem serwera.

⚠️ Opcji Allow invalid certificate w sekcji Email > General settings nie należy aktywować jako szybkiego obejścia. Wygasły, niezaufany albo niezgodny z nazwą serwera certyfikat lepiej poprawić na serwerze pocztowym lub w łańcuchu zaufania.

Jeśli firewall korzysta z Mail Protection w MTA Mode, certyfikat używany do wysyłania poczty zależy dodatkowo od konfiguracji w sekcji Email > General settings. Dlatego nie należy wprowadzać takiej zmiany w oderwaniu od produkcyjnego przepływu poczty.

Gmail i Microsoft 365 z OAuth 2.0

W przypadku Gmaila i Microsoft 365 aktualna pomoc SFOS 22 wymaga OAuth 2.0. W tym celu w sekcji Notification settings wprowadza się Provider, Client ID, Client secret i Refresh token. Ogólna pomoc Sophos określa Client secret dla Microsoft 365 jako opcjonalny, jednak udokumentowana przez Sophos procedura Microsoft 365 wyraźnie go tworzy i używa. Dlatego w tej procedurze również należy go skonfigurować.

W przypadku Gmaila w Google Cloud należy skonfigurować projekt i Gmail API, a także utworzyć klienta OAuth i Refresh Token. Poniższa procedura odpowiada aktualnej instrukcji Sophos Configure OAuth 2.0 on Gmail.

Konfiguracja Gmail OAuth 2.0 krok po kroku

Zalogować się w Google Cloud Console przy użyciu przeznaczonego do tego konta Google, utworzyć nowy projekt i go wybrać.
Otworzyć APIs & Services > Library, wyszukać Gmail API i włączyć API.
W sekcji APIs & Services > Credentials kliknąć Create credentials > OAuth client ID.
Jeśli najpierw wymagany jest ekran zgody, otworzyć Configure the OAuth consent screen > Get started. Wprowadzić nazwę aplikacji i adres e-mail, wybrać User type: External, dodać adres kontaktowy dewelopera i utworzyć konfigurację.
Wybrać Create OAuth client, ustawić Application type: Web application i nadać jednoznaczną nazwę.
W sekcji Authorized redirect URIs dodać dokładnie https://developers.google.com/oauthplayground.
Utworzyć klienta OAuth i natychmiast bezpiecznie zapisać Client ID oraz Client secret.
W sekcji Audience > Add users dodać konto Google, które będzie później wysyłać powiadomienia.
Otworzyć Google OAuth 2.0 Playground. Za pomocą ikony koła zębatego włączyć Use your own OAuth credentials, a następnie wprowadzić Client ID i Client secret.
W sekcji Step 1 Select & authorize APIs rozwinąć Gmail API v1, wybrać zakres https://mail.google.com i uruchomić Authorize APIs. Użyć przeznaczonego konta wysyłającego.
W sekcji Step 2 Exchange authorization code for tokens wymienić kod na tokeny i bezpiecznie skopiować Refresh token.
Na firewallu skonfigurować External email server w sekcji Administration > Notification settings, wybierając Authentication: OAuth 2.0 i Provider: Gmail. Wprowadzić Client ID, Client secret i Refresh token, zapisać oraz wysłać wiadomość testową.

Google nie traktuje projektu OAuth z User type External i Publishing status Testing jako trwałej konfiguracji produkcyjnej: przy użyciu zakresu Gmail Refresh Token wygasa według dokumentacji Google OAuth 2.0 po siedmiu dniach. Używany przez Sophos zakres Gmail https://mail.google.com pozwala oprócz wysyłania również czytać, tworzyć i trwale usuwać wiadomości e-mail. Dlatego aplikacja OAuth, dane dostępowe i najlepiej dedykowane konto wysyłające muszą być chronione i utrzymywane tak samo jak hasło do serwera pocztowego.

W Microsoft 365 aplikacja wymaga delegowanych uprawnień SMTP.Send i offline_access; dla konta wysyłającego musi być aktywna funkcja Authenticated SMTP. Udokumentowana standardowa metoda wykorzystuje smtp.office365.com, port 587 i STARTTLS. Jeśli adres nadawcy różni się od zalogowanej skrzynki, konto potrzebuje dodatkowo uprawnienia Send As. Aktualne kroki w Entra opisano na stronie Configure OAuth 2.0 on Microsoft 365.

Konfiguracja Microsoft 365 OAuth 2.0 krok po kroku

W Microsoft Entra admin center utworzyć New registration w sekcji Identity > Applications > App registrations.
Nadać jednoznaczną nazwę. Dla procedury udokumentowanej przez Sophos wybrać Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) i w polu Redirect URI ustawić platformę Web z adresem https://outlook.office365.com/. Później należy użyć dokładnie tego samego URI.
Zarejestrować aplikację i bezpiecznie zapisać Application (client) ID.
W sekcji API permissions > Add a permission > Microsoft Graph > Delegated permissions dodać SMTP.Send i offline_access. Następnie wykonać Grant admin consent.
Dla konta wysyłającego włączyć Authenticated SMTP w sekcji Users > Active users > Mail > Email apps > Manage email apps.
W sekcji Certificates & secrets > Client secrets > New client secret utworzyć sekret z monitorowaną datą wygaśnięcia. Natychmiast bezpiecznie skopiować wyświetlaną Value; po ponownym załadowaniu strony Entra już jej nie pokaże.
Otworzyć w przeglądarce poniższy adres URL. Zastąpić YOUR_CLIENT_ID identyfikatorem Application ID; wartość redirect_uri musi odpowiadać rejestracji aplikacji.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://outlook.office365.com/&response_mode=query&scope=https://outlook.office365.com/.default+offline_access&state=12345

Zalogować się przy użyciu przeznaczonego konta wysyłającego i skopiować krótkotrwały kod autoryzacyjny z adresu przekierowania.
Wysłać kod za pomocą klienta API jako application/x-www-form-urlencoded do punktu końcowego tokenu. Zastąpić wszystkie wartości tymczasowe danymi tej aplikacji.

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

client_id=YOUR_CLIENT_ID
&scope=https://outlook.office365.com/.default offline_access
&code=YOUR_AUTHORIZATION_CODE
&redirect_uri=https://outlook.office365.com/
&grant_type=authorization_code
&client_secret=YOUR_CLIENT_SECRET

Natychmiast bezpiecznie zapisać zwrócony Refresh token. Kod autoryzacyjny, Client secret, Access token i Refresh token nie mogą trafiać do zgłoszeń, niezabezpieczonych zrzutów ekranu ani logów.
Na firewallu skonfigurować External email server w sekcji Administration > Notification settings, wybierając Authentication: OAuth 2.0 i Provider: Microsoft 365. Wprowadzić smtp.office365.com, port 587, STARTTLS, Client ID, Client secret i Refresh token, zapisać oraz wysłać wiadomość testową.

Sophos wymaga, aby podczas generowania tokenu system z klientem API i firewall korzystały z tej samej strefy czasowej. Przed rozpoczęciem należy sprawdzić czas systemowy i strefę czasową. Nie należy spontanicznie zmieniać strefy czasowej firewalla w środowisku produkcyjnym; Sophos wymaga potem restartu, który należy zaplanować w oknie serwisowym.

Microsoft Security Defaults wyłącza SMTP AUTH. Nie należy wyłączać tego zabezpieczenia ogólnie w całym tenancie tylko po to, aby firewall mógł wysyłać wiadomości. Jeśli selektywne zezwolenie dla konta wysyłającego nie pasuje do modelu bezpieczeństwa, lepszym rozwiązaniem jest przeznaczony do tego wewnętrzny lub zewnętrzny przekaźnik.

⚠️ Sophos nadal wymienia NC-166854 w aktualnej Known Issues list: OAuth Microsoft 365 dla Notifications nie działa w podanych tam buildach 22.0.0.274, 22.0.0.323, 21.0.2.349 i 21.5.1.261. Nie wskazano wersji z poprawką. Dlatego należy sprawdzić dokładny build SFOS i wymagać pomyślnego dostarczenia wiadomości testowej. Samo zapisanie pól Client ID, Secret i Token nie dowodzi jeszcze działania.

Jeśli wymieniony build jest objęty problemem, należy użyć obsługiwanego przekaźnika SMTP albo innego zweryfikowanego toru pocztowego do czasu wiarygodnego potwierdzenia poprawionej wersji firmware. Niebezpieczne wyjątki TLS lub niesprawdzone Basic Authentication nie są dobrym zamiennikiem działającego toru alarmowania.

Wybór zdarzeń na Notification list

Po pomyślnym teście poczty należy otworzyć System services > Notification list. Najpierw aktywuj tam Email notifications, następnie zaznacz pola w kolumnie Email dla potrzebnych zdarzeń i zapisz przyciskiem Save.

Nie każdy firewall wymaga takiego samego wyboru. Rozsądny zestaw podstawowy powinien odpowiadać ryzykom i faktycznie używanym funkcjom:

Admin: nieudane logowania i zbyt wiele nieudanych prób logowania.
HA: odłączone monitorowane porty lub interfejsy, jeśli działa klaster HA.
Disk/Memory: ostrzeżenia o miejscu, aby zapełniony obszar raportów lub systemu nie został zauważony dopiero podczas okna serwisowego. Progi i konsekwencje wyjaśnia artykuł Sprawdzanie pamięci i raportów na Sophos Firewall.
Firmware: nowe wersje firmware, a przede wszystkim nieudane instalacje, zgodnie z własnym procesem aktualizacji.
System: nieudane aktualizacje sygnatur lub baz danych, uruchomienie systemu, wysokie obciążenie CPU i Gateway status.
IPS i Active threat response: na początku zdarzenia krytyczne lub blokujące, jeśli istnieje dla nich proces triage.
RED, AP i VPN: tylko dla faktycznie używanych urządzeń i ważnych połączeń.
Web - Instant alerts: świadomie wybrane kategorie internetowe. Powiadomienia te są wysyłane w pięciominutowych pakietach i wymagają oddzielnej aktywacji kategorii zgodnie z opisem w artykule Web Categories i Instant Alerts.

Aktywowanie wszystkich zdarzeń bez wyjątku szybko powoduje zmęczenie alarmami. Szczególnie powiadomienia VPN mogą być powtarzane mniej więcej co 60 sekund do czasu usunięcia przyczyny; przy wielu sieciach lokalnych i zdalnych może również powstać jedna wiadomość na każdą parę podsieci. Lepszy jest mały wybór z jasno określoną reakcją: kto otrzyma alert, jak pilny on jest i jaki powinien być pierwszy krok kontrolny?

Niektóre Default Notifications firewall wysyła automatycznie i nie pozwala ich wyłączyć. Należą do nich określone zmiany roli i stanu HA, stan hostów wirtualnych oraz ponowne uruchomienie lub wyłączenie przez WebAdmin. Również dla tych wiadomości skonfigurowany tor pocztowy musi być osiągalny.

Test wiadomości i rzeczywistego zdarzenia

Kontrola składa się z dwóch etapów.

1. Potwierdzenie dostarczenia SMTP wiadomością testową

Wyślij wiadomość testową w sekcji Administration > Notification settings. Komunikat firewalla o powodzeniu nie wystarczy: w docelowej skrzynce, filtrze spamu lub systemie śledzenia serwera pocztowego musi być widoczne, że wiadomość została rzeczywiście przyjęta i dostarczona.

Należy przy tym sprawdzić:

Nadawca i odbiorca są prawidłowi.
Oczekiwany firewall można rozpoznać na podstawie tematu, treści lub adresu IP do zarządzania.
Wiadomość nie trafia na stałe do spamu ani kwarantanny.
Lista dystrybucyjna przyjmuje wiadomości od skonfigurowanego nadawcy.

2. Test pełnego łańcucha zdarzenia

Następnie należy w kontrolowany sposób wywołać wybrane zdarzenie. Odpowiednie przykłady to:

pojedyncze nieudane logowanie przy użyciu konta testowego, po sprawdzeniu blokad i progów logowania;
zmiana Up/Down tunelu testowego VPN przeznaczonego specjalnie do tego celu;
Gateway status podczas zaplanowanego testu przełączania WAN.

Ponowne uruchamianie lub odłączanie produkcyjnej bramy, portu HA albo samego firewalla wyłącznie w celu testu wiadomości e-mail byłoby nieproporcjonalne. Lepszym testem jest już zaplanowany scenariusz konserwacji lub przełączania awaryjnego.

Dopiero gdy zdarzenie dotrze w oczekiwanym czasie do właściwego odbiorcy, potwierdzony jest cały łańcuch: wykrycie zdarzenia, wybór zdarzenia, globalny przełącznik poczty, transport SMTP i dostarczenie.

Systematyczne zawężanie błędów

Wiadomość testowa już się nie udaje

API SFOS 22 rozróżnia kilka klas błędów:

Failed to connect lub SMTP server failed to respond: sprawdź rozwiązywanie FQDN, trasę, port, poprzedzający firewall i listener serwera pocztowego.
Password mismatch: sprawdź nazwę użytkownika, wielkość liter, hasło i ewentualnie zablokowane konto.
Authentication method mismatch: sprawdź, czy przekaźnik i SFOS wspólnie obsługują LOGIN lub PLAIN dla Basic Authentication.
STARTTLS not supported: port i Connection security nie pasują do listenera serwera.
Mail server refused to communicate: sprawdź zezwolenie przekaźnika, adres nadawcy, dozwolony źródłowy adres IP i logi serwera pocztowego.
Couldn’t generate the OAuth 2.0 access token: sprawdź Provider, Client ID, Secret, Refresh Token, uprawnienia i czas systemowy.

Z systemu administracyjnego korzystającego z porównywalnej trasy sieciowej można wstępnie sprawdzić DNS i STARTTLS bez zmian na serwerze pocztowym:

nslookup smtp.example.net
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.net

Zastąp smtp.example.net i 587 własnym serwerem i portem. nslookup potwierdza jedynie rozwiązywanie nazw w systemie administracyjnym. openssl s_client pokazuje osiągalność SMTP, uzgadnianie TLS i łańcuch certyfikatów, ale nie sprawdza ani trasy z perspektywy firewalla, ani jego logowania lub późniejszego dostarczenia.

W Log Viewer, a przy głębszej analizie również w cschelper.log, można skorelować czas testu z wiadomością e-mail wygenerowaną przez system. Dostęp do logów usług i rozróżnienie względem Advanced Shell opisano w artykule Usługi i logi Sophos Firewall. Logi MTA, takie jak smtpd_main.log, należą przede wszystkim do Mail Protection i nie są ogólnym logiem Notifications.

Wiadomość testowa dociera, ale brakuje powiadomień o zdarzeniach

W takim przypadku transport działa, a poszukiwania rozpoczynają się w sekcji System services > Notification list:

Czy Email notifications jest aktywne globalnie?
Czy konkretne zdarzenie jest wybrane w kolumnie Email?
Czy oczekiwane zdarzenie rzeczywiście wystąpiło i należy do właściwej kategorii?
Czy występuje znane opóźnienie lub grupowanie, na przykład w przypadku Web Instant Alerts?
Czy filtr spamu, kwarantanna lub system śledzenia serwera pocztowego pokazują przyjęcie albo odrzucenie?

W przypadku pojedynczego zdarzenia specjalnego należy dodatkowo sprawdzić warunek merytoryczny. Przykładowo alert IPS nie powstaje wyłącznie wskutek zaznaczenia pola, lecz dopiero wtedy, gdy odpowiednia reguła IPS zarejestruje i odrzuci zdarzenie. Powiadomienie VPN zależy od typu tunelu oraz jego rzeczywistego stanu Up/Down.

Microsoft 365 OAuth zapisuje się, ale nie wysyła

Najpierw porównaj wersję i build SFOS z NC-166854. Następnie sprawdź Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP dla konta wysyłającego oraz prawidłowy czas systemowy.

Jeśli wiadomość testowa nadal nie działa w buildzie, który nie jest wymieniony jako dotknięty, nie oznacza to automatycznie tego samego błędu. Dokładny komunikat, build SFOS i logi logowania dostawcy należy wtedy uwzględnić w dalszej analizie lub zgłoszeniu do pomocy technicznej.

Utrzymanie powiadomień

Utrzymuj odbiorcę jako funkcjonalną listę dystrybucyjną z przypisanym właścicielem.
Po zmianach serwera pocztowego, DNS, routingu, certyfikatu, danych dostępowych, aplikacji OAuth lub firmware ponownie sprawdź wiadomość testową i rzeczywiste zdarzenie.
Testuj cały tor alarmowania co najmniej raz na kwartał, jeśli nie jest stale monitorowany przez centralny system.
Dokumentuj wygaśnięcie i rotację haseł, Client Secrets i Tokens.
Regularnie dostosowuj wybór zdarzeń do nowych funkcji i wyłączonych usług.
Dla każdego ważnego alertu określ pierwszy krok kontrolny i ścieżkę eskalacji.

Codzienna lista administratora Sophos Firewall zbiera sygnały stanu, bezpieczeństwa i administracyjne, które należy dodatkowo aktywnie kontrolować podczas eksploatacji.

E-mail jest dobrym bezpośrednim kanałem alarmowania, ale nie zastępuje centralnego przechowywania ani korelacji logów. Do dłuższej historii i analizy bezpieczeństwa nadaje się artykuł Wysyłanie Syslog z Sophos Firewall do SIEM. Klasyczne monitorowanie stanu i pułapek uzupełnia Monitorowanie sprzętu przez SNMP.

Do analiz PDF wysyłanych codziennie lub co tydzień nie używa się Notification list, lecz oddzielnego harmonogramu raportu. Artykuł Planowanie i wysyłanie raportów Sophos Firewall e-mailem wyjaśnia wybór raportu, bookmark, test transportu i kontrolę treści.