Utilizzare correttamente il Sophos Firewall Health Check

Il Sophos Firewall Health Check è una verifica integrata della configurazione del firewall. Mostra nel Control Center se le impostazioni importanti corrispondono alle raccomandazioni di sicurezza e alle best practice. È particolarmente utile per gli amministratori perché rende visibili configurazioni rischiose prima che diventino un problema di sicurezza o operativo.

Per il contesto generale di hardening, consultare l’hub Sophos Firewall Hardening: best practice per una configurazione sicura.

L’Health Check è stato introdotto con Sophos Firewall v22. La funzione valuta le configurazioni rispetto a best practice e standard come i benchmark CIS. Con SFOS 22.0 MR1 è stato aggiornato anche il contesto CIS sottostante.

Video guida

Come utilizzare questa guida

L’Health Check fornisce un elenco, ma non prende la decisione. La guida aggiunge quindi una valutazione Avanet:

• Priorità alta: controllo fondamentale di sicurezza o di esercizio; correggere o motivare molto bene.
• Dipende dal contesto: utile, ma non per ogni regola, flusso o architettura.
• Coperto diversamente: l’obiettivo è già soddisfatto da un controllo equivalente di un altro fornitore o da un altro processo operativo. In questo caso, un override documentato può essere corretto.
• Opzionale: funzione di compliance o servizio Sophos aggiuntivo; uno stato rosso non significa automaticamente che il firewall sia insicuro.

Questa classificazione non sostituisce un’analisi del rischio. Evita che una gravità Sophos bassa riduca l’importanza di un backup critico o che un’integrazione opzionale diventi prematuramente un progetto di acquisto.

A cosa serve l’Health Check

L’Health Check non è uno stato di sistema classico né un sensore hardware. Non verifica se un alimentatore è difettoso o se un SSD sta per guastarsi. Per questo sono più adatti altri controlli operativi, come verificare lo stato di salute dell’SSD o il monitoraggio HA e hardware.

L’Health Check risponde piuttosto a queste domande:

• Gli accessi amministrativi sono troppo aperti?
• MFA è attivato per i login critici?
• Le regole del firewall sono troppo aperte?
• Backup, hotfix, logging o funzioni Central sono preparati correttamente?
• La configurazione si discosta dagli standard di sicurezza raccomandati?
• Ci sono risultati che dovrebbero essere risolti prima di un audit o di un go-live?

È quindi un buon strumento per il rafforzamento, la revisione e il controllo delle modifiche. Tuttavia, non sostituisce una buona architettura, una documentazione delle regole e una valutazione manuale.

⚠️ Un Health Check verde non significa automaticamente che il firewall sia pianificato in modo sicuro. Indica se determinate impostazioni verificabili sono corrette. Il design della rete, la logica aziendale, le eccezioni, i gruppi di utenti e i processi operativi devono essere ancora valutati professionalmente.

Valutare correttamente punteggio e status

L’Health Check è utile, ma non è un security audit vendor-neutral. Premia anche l’uso di Sophos Central, DNS Protection, NDR Essentials, MDR threat feeds e Synchronized Security. Dal punto di vista di Avanet, questa selezione contiene una chiara componente di cross-selling: Noncompliant può indicare una vera lacuna, come WebAdmin esposto senza MFA, oppure soltanto la scelta di non usare un servizio Sophos opzionale mentre Microsoft Defender, un altro EDR/NDR, un SIEM o un filtro DNS copre già l’obiettivo.

Raccomandazione Avanet: esaminare ogni finding, ma non implementarli tutti senza valutarli. Un punto rosso relativo a WebAdmin, MFA, autenticazione non cifrata, backup o regole aperte richiede molta attenzione. Un punto rosso relativo a un servizio Sophos non licenziato è innanzitutto una decisione architetturale e di prodotto, non una lacuna di sicurezza automaticamente dimostrata. L’obiettivo di sicurezza, le alternative esistenti e il processo operativo determinano se sia corretto attivare, coprire in altro modo o applicare un override motivato.

Pertanto, non si dovrebbe attivare ogni raccomandazione solo per far diventare verde l’indicatore. Un esempio è il disclaimer di login: in ambienti di audit o compliance, può essere richiesto un avviso di login. In molti ambienti operativi normali, però, genera soprattutto un clic aggiuntivo a ogni login e non porta praticamente alcun vantaggio tecnico in termini di sicurezza. Se aumenta solo il punteggio dell’Health Check, il valore aggiunto è limitato.

Per queste funzioni bisogna chiedersi: quale rischio riducono, esiste già un controllo equivalente, quali licenze e trasferimenti di dati richiedono e chi gestisce alert, eccezioni e falsi positivi? Senza risposte chiare, un override documentato è spesso più onesto di una funzione attivata ma non gestita.

Non bisogna confondere NDR Essentials e MDR. NDR Essentials analizza il traffico selezionato del firewall e genera rilevamenti. Sophos MDR significa Managed Detection and Response ed è un servizio aggiuntivo a pagamento con analisti e processi di gestione degli incidenti. I MDR threat feeds hanno senso solo se questo servizio è realmente licenziato e integrato nelle operazioni. Un finding NDR non significa automaticamente che sia necessario acquistare MDR.

Come regola generale:

• Accessi di gestione esposti a Internet, MFA, hotfix, backup, regole delle password, IPS Di solito elementi di base della sicurezza o operativi reali. Questi punti dovrebbero essere presi molto sul serio.
• Logging, reporting, notifiche, NTP Importante per l’operazione e la tracciabilità. Il percorso concreto dipende dal modello operativo.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Central e Synchronized Security sono possibili soluzioni, non requisiti universali. Un’alternativa efficace conta più del logo Sophos sul controllo.
• Disclaimer di login Di solito più una funzione di compliance/avviso che una misura di protezione tecnica. Attivare solo se realmente richiesto o desiderato.

Decisione rapida: cosa conviene implementare davvero?

Al primo utilizzo dell’Health Check, i finding possono essere suddivisi in quattro gruppi di lavoro:

• Controllare subito e normalmente correggere: 8, 9, 11, 13-20, 22, 25, 28 e 31. Comprendono hotfix, protezione del login, password amministratore, MFA, autenticazione cifrata, SSH, esposizione WAN, pattern update, IPS, regole troppo ampie e ora corretta.
• Molto importanti anche se Sophos li valuta Low o Medium: 16 e 21. I backup richiedono un restore testato. Gli alert richiedono un canale funzionante tramite e-mail, monitoring, Central o SIEM.
• Decidere per flusso e architettura: 3, 5, 10 e 23-27. X-Ops, Heartbeat, regole password utente, Web Policy, Zero-Day Protection, Application Control e TLS Inspection non sono ugualmente utili su ogni regola.
• Attivare solo con l’ecosistema Sophos appropriato o con una scelta consapevole del servizio cloud: 1, 2, 4, 6, 12, 29 e 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection e le funzioni Central non sono requisiti minimi universali. Il punto 7, Login disclaimer, è soprattutto una decisione di compliance.

Questa classificazione è volutamente più diretta della gravità Sophos. Valuta ciò che riduce prima il rischio nell’ambiente reale, non ciò che Sophos può vendere o integrare tecnicamente.

Aprire l’Health Check

Lo stato dell’Health Check appare nel Control center. La vista dettagliata si trova anche tramite il menu principale:

Monitor & analyze > Firewall health check

Lì si vede il numero di configurazioni verificate, i punti conformi e i punti non conformi. Sophos mostra le voci non conformi in base al grado di gravità. I dati vengono aggiornati quando una configurazione monitorata cambia. Pertanto, l’Health Check è adatto anche per un controllo diretto dopo le modifiche.

Per la revisione, non si dovrebbe solo annotare lo stato complessivo. Sono più importanti i risultati concreti, il contesto del rischio e la misura pianificata. Un singolo risultato critico sulla raggiungibilità WAN del WebAdmin è più importante in operazione di diversi risultati minori senza esposizione a Internet.

Comprendere status, gravità e override

La vista dettagliata mostra per ogni controllo se la configurazione è compliant, non compliant oppure sovrascritta manualmente. Per l’esercizio operativo questi tre stati sono più importanti della sola percentuale.

• Compliant: la configurazione controllata soddisfa la policy corrispondente. Dopo modifiche importanti va comunque validata tecnicamente.
• Noncompliant: la configurazione controllata non soddisfa la policy. Rischio, esposizione e fattibilità devono essere valutati.
• Manual policy status override: la configurazione non soddisfa la policy, ma è stata marcata manualmente come compliant. Questo stato va usato solo con motivazione, owner e data di revisione.

La gravità aiuta a ordinare i risultati, ma non sostituisce la valutazione tecnica. È una valutazione Sophos statica e non conosce esposizione o controlli compensativi. Un finding Low per backup mancanti può essere più urgente di un Medium per un servizio Sophos non utilizzato.

Se un finding appare illogico, bisogna controllare anche la versione firmware e i problemi noti. SFOS 22.0 MR1 ha corretto falsi stati Doesn't comply per le regole firewall e per NDR Essentials sui firewall virtuali. Uno stato chiaramente errato non giustifica quindi una modifica rischiosa della configurazione né un override affrettato.

Le funzioni di ricerca e ordinamento della tabella Health Check aiutano a raggruppare i risultati per policy, modulo, standard o gravità. Per firewall grandi è più pratico che guardare solo il riquadro del dashboard.

Valutazione delle singole verifiche dell’Health Check

La lista si basa sulle 31 verifiche della vista inglese usate per questa analisi. Sophos può modificare numero, nome, standard o gravità con un aggiornamento firmware. Se il firewall locale mostra finding aggiuntivi o con nomi diversi, la sua visualizzazione fa fede. Lo stato non è riportato perché varia in base al firewall. È più importante capire ogni verifica e valutarla correttamente.

Active Threat Response e Advanced Security

• 1. Synchronized Application Control dovrebbe essere attivato. Standard: Recommended, Gravità: Medium. Identifica le applicazioni con maggiore precisione tramite Sophos Endpoint e richiede Security Heartbeat; al primo utilizzo deve essere attivato anche in Sophos Central. Valutazione Avanet: opzionale. Attivare solo con endpoint Sophos compatibili e se le applicazioni rilevate saranno poi classificate e utilizzate tramite Application Filter. Con Microsoft Defender o un altro prodotto endpoint, un override motivato è più utile di un’attivazione inefficace.
• 2. NDR Essentials dovrebbe essere attivato e monitorare almeno un’interfaccia. Standard: Recommended, Gravità: Medium. Il firewall analizza il traffico selezionato tramite il servizio cloud Sophos NDR, rileva gli IoC e li registra, ma non li blocca automaticamente. Sono supportate determinate interfacce nelle zone LAN, DMZ e Custom; WAN, Wi-Fi e vari tipi di interfaccia, come RED o XFRM, sono esclusi. Active-Active HA non è supportato. Devono inoltre essere attivi i log di Active Threat Response e, in base al tipo di IoC, i controlli firewall, DNS, IPS o decryption. Valutazione Avanet: dipende dal contesto o opzionale. Attivare solo quando licenza, analisi cloud, privacy, interfacce adatte e responsabilità sugli alert sono chiariti. Non sostituire un NDR esistente solo per rendere verde l’Health Check.
• 3. Sophos X-Ops dovrebbe essere attivato, azione Log and drop. Standard: CIS, Gravità: High. Rilevante per la sicurezza se i Threat Feeds sono attivamente utilizzati. I falsi positivi e il logging devono essere verificati.
• 4. MDR threat feeds dovrebbero essere attivati, azione Log and drop. Standard: Recommended, Gravità: High. Richiede Sophos MDR, registrazione in Sophos Central e licenze appropriate. Valutazione Avanet: opzionale. Senza un contratto MDR non è una lacuna di configurazione, ma una raccomandazione di prodotto e servizio.
• 5. Una regola firewall dovrebbe utilizzare Synchronized Security Heartbeat. Standard: CIS, Gravità: Medium. Valutazione Avanet: dipende dal contesto. Offre grande valore con Sophos Endpoint, ma non è adatto con Microsoft Defender o un altro EDR. È essenziale un test pilota: a seconda della regola, i dispositivi che non hanno mai inviato un heartbeat possono continuare ad accedere. Le opzioni Block clients with no heartbeat e Block request to destination with no heartbeat applicano il comportamento previsto a tali dispositivi.
• 6. Security Heartbeat dovrebbe essere attivato. Standard: CIS, Gravità: High. Importante se viene utilizzato Sophos Endpoint. Altrimenti, chiarire prima il design dell’Endpoint.
• 12. DNS Protection dovrebbe essere configurato e attivo. Standard: Recommended, Gravità: Medium. Lo stato attivo richiede la licenza appropriata, i resolver DNS Protection sul firewall e l’IP pubblico del firewall come Location in Sophos Central. Valutazione Avanet: opzionale. Attivare solo se il servizio viene gestito consapevolmente come livello di sicurezza DNS e i suoi log vengono controllati. Altri filtri DNS possono coprire lo stesso obiettivo senza risultare compliant nel Sophos Health Check.

Admin, autenticazione e Device Access

• 7. Login disclaimer dovrebbe essere attivato. Standard: CIS, Gravità: Medium. Tema di compliance. Poco effetto protettivo tecnico, ma genera un clic aggiuntivo al login.
• 8. Hotfix setting dovrebbe essere attivato. Standard: CIS, Gravità: High. Valutazione Avanet: priorità alta. In SFOS 22 attuale non appare più un blocco Hotfix separato in Backup & firmware > Firmware. Sophos installa gli hotfix automaticamente per default; lo stato si può verificare con system hotfix show nella Device Console. L’assenza della casella nell’interfaccia non è un finding.
• 9. Le sessioni inattive dovrebbero essere terminate e i login bloccati dopo tentativi falliti. Standard: CIS, Gravità: High. Chiaramente un rafforzamento del login. Particolarmente importante per portali esposti e accessi amministrativi.
• 10. La complessità delle password dovrebbe essere configurata per gli utenti. Standard: CIS, Gravità: High. Utile, soprattutto per utenti locali e portali. Con IdP esterno, verificare anche la sua politica di password e MFA.
• 11. La complessità delle password dovrebbe essere configurata per gli amministratori. Standard: CIS, Gravità: High. Rafforzamento di base. Ancora più importanti sono amministratori individuali, MFA e accesso limitato.
• 13. MFA dovrebbe essere attivo per i login VPN Remote Access. Standard: CIS, Gravità: High. Molto importante per SSL VPN e IPsec Remote Access. Pianificare il rollout con amministratore di fallback e utenti di test.
• 14. MFA dovrebbe essere attivo per WebAdmin Console e VPN Portal. Standard: CIS, Gravità: High. Molto importante, soprattutto se i portali sono accessibili da reti meno controllate.
• 15. Le connessioni ai server di autenticazione dovrebbero essere crittografate. Standard: CIS, Gravità: Medium. Importante per connessioni AD/LDAP/RADIUS. Evitare l’autenticazione non crittografata.
• 17. L’autenticazione a chiave pubblica dovrebbe essere attivata per SSH. Standard: Recommended, Gravità: High. Molto utile. Inoltre, consentire SSH solo da reti fidate.
• 18. User Portal non dovrebbe essere accessibile dalla zona WAN. Standard: Recommended, Gravità: High. Corretto in molte ambienti. Se l’accesso WAN è necessario, limitarlo fortemente e utilizzare MFA.
• 19. WebAdmin Console non dovrebbe essere accessibile dalla zona WAN. Standard: CIS, Gravità: High. Uno dei punti più importanti. Non aprire mai WebAdmin ampiamente su Internet.
• 20. MFA dovrebbe essere configurato per l’amministratore predefinito. Standard: CIS, Gravità: High. Importante, ma meglio è anche un processo amministrativo pulito con account amministrativi personali.

Backup, aggiornamenti, regole e inspection

• 16. I backup dovrebbero essere pianificati sul firewall o in Sophos Central. Standard: CIS, Gravità: Low. Gravità bassa, ma estremamente importante in caso di emergenza. Testare anche il processo di ripristino.
• 21. Le email di notifica dovrebbero essere configurate per eventi di sistema e di sicurezza. Standard: CIS, Gravità: Low. Sophos Firewall può inviare notifiche via email e SNMP; gli eventi desiderati si selezionano in System services > Notification list. Valutazione Avanet: dipende dal contesto. Conta un percorso di allarme affidabile e testato. Se Syslog, SIEM, monitoraggio o Central Alerts sono gestiti correttamente, l’email non è obbligatoria. Un server SMTP configurato senza eventi selezionati e senza prova di consegna non costituisce ancora un processo di allarme.
• 22. Gli aggiornamenti automatici dei pattern dovrebbero essere attivati. Standard: CIS, Gravità: High. Valutazione Avanet: priorità alta. Senza pattern aggiornati, varie funzioni di protezione perdono efficacia. Gli aggiornamenti sono attivi automaticamente per impostazione predefinita, ma lo stato e l’ultimo aggiornamento riuscito devono comunque essere controllati. Il firmware di Access Point e dispositivi RED viene solo scaricato e installato separatamente perché richiede un riavvio. Negli ambienti Air-Gap serve un processo manuale di pattern e licenze.
• 23. Una Web Policy dovrebbe essere selezionata in una regola firewall. Standard: Recommended, Gravità: Medium. Utile per il traffico web degli utenti. Non applicare ciecamente al traffico server-to-server o specializzato.
• 24. La protezione zero-day dovrebbe essere selezionata in una regola firewall. Standard: CIS, Gravità: High. Utile per percorsi web e di download appropriati. Considerare licenza, prestazioni e falsi positivi.
• 25. IPS dovrebbe essere attivato e una policy IPS dovrebbe essere selezionata in una regola firewall. Standard: CIS, Gravità: High. Punto di protezione molto importante. IPS deve essere scelto in modo appropriato per ogni percorso di traffico e registrato.
• 26. Una policy di Application Control dovrebbe essere selezionata in una regola firewall. Standard: CIS, Gravità: Medium. Utile per regole Internet client. Testare prima per traffico critico.
• 27. Una regola di ispezione SSL/TLS dovrebbe utilizzare l’azione Decrypt. Standard: CIS, Gravità: High. Non attivare ciecamente. TLS Inspection richiede distribuzione CA, eccezioni, fase pilota e processo di risoluzione dei problemi.
• 28. Una regola Allow non dovrebbe utilizzare Any ovunque nei campi di rete e servizio. Standard: CIS, Gravità: Medium. Molto importante per l’igiene delle regole. Any può essere necessario consapevolmente, ma deve essere giustificato e registrato.

Sophos Central e ora

• 29. Sophos Central Reporting dovrebbe essere attivato. Standard: Recommended, Gravità: Medium. Utile per reporting e analisi più lunghe. Non obbligatorio se Syslog/SIEM è gestito correttamente.
• 30. Il firewall dovrebbe essere registrato per Sophos Central Management e Central Management attivato. Standard: Recommended, Gravità: Medium. Pratico per gestione centralizzata, backup e reporting. Non tutti gli ambienti vogliono o richiedono una gestione cloud.
• 31. Un server NTP dovrebbe essere configurato. Standard: CIS, Gravità: Low. Requisito di base. Senza tempo corretto, log, certificati, autenticazione e risoluzione dei problemi ne risentono.

Dare priorità e implementare i risultati

Non ogni risultato ha la stessa importanza in ogni ambiente. Una buona revisione ordina quindi le voci non solo per gravità tecnica, ma anche per esposizione e rischio operativo.

Questa sequenza si è dimostrata efficace:

1. Verificare accessi di gestione e portali esposti a Internet.
2. Verificare MFA e sicurezza dei login per amministratori, VPN Portal, User Portal e Remote Access.
3. Correggere regole firewall con fonti, destinazioni o servizi troppo ampi.
4. Controllare logging, backup e hotfix.
5. Verificare funzioni di protezione per regola, ad esempio IPS, Web Policy, Application Control, TLS Inspection o Zero-Day Protection.
6. Valutare Central, Reporting o risultati NDR in base all’effettivo utilizzo e gestione della funzione nell’ambiente.

La sequenza è pragmatica: prima le cose che sono direttamente visibili su Internet o consentono l’accesso al firewall. Poi l’igiene delle regole e le funzioni di protezione. Poi i temi operativi e dell’ecosistema.

Risultati tipici e misure appropriate

WebAdmin, User Portal o VPN Portal troppo accessibili

Se i portali amministrativi o vicini agli utenti sono accessibili da troppe zone, aumenta il rischio di scansioni, tentativi di forza bruta e stuffing delle credenziali. L’articolo più importante a riguardo è Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Per ambienti produttivi, si dovrebbe verificare:

• WebAdmin è realmente necessario dalla zona WAN?
• Esiste una regola di eccezione Local Service ACL per IP di gestione o rete amministrativa?
• SSH è consentito solo da reti fidate?
• User Portal e VPN Portal sono accessibili solo dove necessario?

MFA mancante o non attivato in modo coerente

MFA dovrebbe essere presente almeno sugli accessi amministrativi e Remote Access. Se l’Health Check mostra risultati MFA, non si dovrebbe passare ciecamente a tutti gli utenti contemporaneamente. Meglio è un rollout controllato con utente di test, amministratore di fallback e processo di token pulito.

La guida pratica è in Abilitare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access.

Regole firewall troppo aperte

Regole molto ampie con Any su fonte, destinazione o servizio sono spesso cresciute storicamente. Non ogni regola ampia è automaticamente sbagliata, ma ognuna dovrebbe essere giustificata.

Per la correzione, queste domande sono utili:

• Quale zona può realmente accedere a quale zona?
• Le reti di destinazione o i servizi possono essere limitati?
• Il logging è attivo, in modo che i colpi siano visibili?
• Ci sono vecchie regole di test o eccezioni temporanee?
• La regola può essere suddivisa in più regole comprensibili?

Le basi sono in Comprendere e configurare correttamente le regole di Sophos Firewall. Se non è chiaro quale regola si applica, aiuta Testare le regole del firewall con Log Viewer, Policy Test e Packet Capture.

Mancanza di backup, hotfix e processo di aggiornamento

Un Health Check può indicare la mancanza di backup o temi di aggiornamento/hotfix. Questi punti sembrano meno spettacolari rispetto all’esposizione dei portali, ma sono decisivi in caso di emergenza.

Prima di grandi modifiche, si dovrebbe creare un backup e sapere come funziona un ripristino. La procedura è descritta in Creare o ripristinare un backup di Sophos Firewall. Per i temi del firmware, è adatto Aggiornamento del firmware di Sophos Firewall - Preparazione e best practice.

Logging e reporting incompleti

Se mancano i log, l’operazione è cieca. L’Health Check può fornire indicazioni su temi di logging o reporting, ma la decisione effettiva dipende dal modello operativo.

Per l’analisi locale, sono rilevanti Log Viewer, log di servizio e Packet Capture. Per una conservazione più lunga, è necessario Central Firewall Reporting o Syslog/SIEM. Se non si vogliono esaminare singoli eventi di log, ma flussi di traffico, picchi di larghezza di banda o relazioni di comunicazione sospette, è adatto anche Monitoraggio sFlow. Le basi locali sono in Risoluzione dei problemi di Sophos Firewall: servizi e log.

Funzioni di protezione non attive nelle regole

Un punto frequente sono le regole senza IPS, Web Policy, Application Control, TLS Inspection o Zero-Day Protection. Qui non si dovrebbe attivare tutto indiscriminatamente, ma comprendere il percorso del traffico.

Esempi:

• Il traffico web degli utenti richiede controlli diversi rispetto al traffico server-to-server.
• TLS Inspection deve essere introdotta pianificata, poiché può disturbare le applicazioni.
• IPS e Application Control richiedono logging e una routine di revisione.
• Le funzioni NDR o Threat Feed aiutano solo se i risultati vengono successivamente valutati.

Per TLS Inspection è adatto Introdurre correttamente TLS Inspection di Sophos Firewall. Per Threat Feeds è adatto Sophos Firewall Threat Feeds.

Documentare e ricontrollare la revisione

Sophos Firewall consente di sovrascrivere manualmente lo stato di singole verifiche. Questo può essere utile se una raccomandazione non viene implementata consapevolmente nel proprio ambiente.

Gli override non dovrebbero però essere fraintesi come una funzione di pulizia. Se un punto viene sovrascritto, dovrebbe essere documentato:

• Perché la raccomandazione non è adatta?
• Chi ha approvato la decisione?
• L’eccezione è permanente o solo temporanea?
• Quando verrà riesaminata?
• Esiste una misura compensativa?

⚠️ Un override non è una soluzione. È un’accettazione consapevole del rischio o un’eccezione documentata. Senza giustificazione, l’Health Check diventa meno prezioso.

Documentare correttamente il risultato

Una revisione dell’Health Check dovrebbe produrre un risultato tracciabile. Altrimenti si vede solo brevemente un dashboard, ma non si sa più quale decisione è stata presa e quali punti sono ancora aperti.

Per ambienti piccoli, spesso basta una semplice tabella:

• Data: Quando è stato verificato l’Health Check?
• Firmware: Su quale versione SFOS è stata valutata?
• Risultato: Quale punto non conforme è stato segnalato?
• Rischio: Perché il punto è rilevante o meno rilevante in questo ambiente?
• Misura: Cosa verrà cambiato, testato o consapevolmente accettato?
• Responsabile: Chi chiarisce il punto professionalmente o tecnicamente?
• Termine: Entro quando la misura deve essere completata o riesaminata?
• Prova: Screenshot, ticket, ID di modifica o riferimento al log di audit

Per firewall produttivi, la prova non dovrebbe consistere solo in uno screenshot. Se una configurazione è stata modificata, ticket di modifica, audit trail, regola firewall interessata e risultato del controllo successivo devono essere insieme. Per modifiche a regole, interfacce, host e servizi, Verificare i log di audit trail di Sophos Firewall è particolarmente utile.

Verificare nuovamente dopo le modifiche

Dopo una correzione, si dovrebbe riaprire l’Health Check e controllare se il risultato è realmente scomparso. Inoltre, è necessaria una verifica tecnica del funzionamento, poiché uno stato verde da solo non prova che il traffico produttivo continui a funzionare correttamente.

Esempi:

• Dopo una modifica a Device access, verificare se l’accesso amministrativo dalla rete di gestione prevista funziona ancora e non è più accessibile da reti indesiderate.
• Dopo modifiche MFA, accedere con un utente di test e verificare separatamente l’amministratore di fallback.
• Dopo modifiche alle regole, testare Log Viewer, Policy Test e applicazioni interessate.
• Dopo modifiche al logging o al reporting, controllare se i nuovi eventi sono realmente visibili localmente, in Sophos Central o nel Syslog.
• Dopo un override, impostare un promemoria in modo che l’eccezione non venga dimenticata permanentemente.

Se vengono gestiti più risultati contemporaneamente, si dovrebbero suddividere le modifiche in piccoli blocchi. Altrimenti, in caso di un problema successivo, non è chiaro se l’accesso al dispositivo, MFA, regole del firewall, TLS Inspection o un’altra modifica sia la causa.

Utilizzare l’Health Check come processo operativo

L’Health Check è più efficace se eseguito regolarmente e dopo modifiche importanti.

Momenti opportuni:

• dopo la configurazione iniziale o un go-live,
• prima e dopo grandi modifiche alle regole,
• prima degli aggiornamenti del firmware,
• dopo un ripristino o una sostituzione hardware,
• dopo migrazioni o grandi cambiamenti architetturali,
• prima degli audit,
• trimestralmente come revisione della sicurezza.

Per le modifiche stesse, dovrebbe essere utilizzato anche l’audit trail. L’articolo Verificare i log di audit trail di Sophos Firewall spiega come valutare configuration-audit.log e tracciare le modifiche di configurazione.

Procedura pratica di revisione

Una revisione pragmatica dell’Health Check si svolge così:

1. Aprire l’Health Check nel Control Center.
2. Ordinare i risultati non conformi per gravità.
3. Verificare prima i servizi e gli accessi amministrativi esposti a Internet.
4. Gestire i temi di MFA, password e sessione.
5. Identificare le regole firewall ampie e validarle con Log Viewer.
6. Verificare backup, hotfix, logging e reporting.
7. Valutare le funzioni di protezione per regola.
8. Documentare le eccezioni giustificate invece di sovrascriverle senza commenti.
9. Verificare nuovamente dopo le modifiche.
10. Documentare il risultato con data, responsabile e punti aperti.

Per revisioni ricorrenti, spesso basta una semplice tabella con risultato, rischio, misura, responsabile, stato e promemoria. È importante che i risultati non siano solo visti, ma affrontati o consapevolmente accettati.

Limiti

L’Health Check è utile, ma ha limiti chiari.

• Non conosce la logica aziendale completa dell’ambiente.
• Non valuta se una regola è necessaria professionalmente.
• Non sostituisce la segmentazione della rete e un modello di zone.
• Non riconosce automaticamente ogni caso speciale rischioso.
• Non sostituisce un audit esterno e una revisione manuale delle regole.
• Non dice se gli avvisi verranno successivamente gestiti.

Pertanto, l’Health Check dovrebbe essere visto come un punto di partenza. Rende tangibili le deviazioni visibili, ma la vera qualità della sicurezza nasce da una buona architettura, processi puliti e manutenzione costante.

Checklist operativa

• Eseguire l’Health Check dopo il go-live e dopo grandi modifiche.
• Dare priorità ai risultati in base alla gravità e all’esposizione.
• Verificare la raggiungibilità WAN di WebAdmin, SSH, User Portal e VPN Portal.
• Attivare MFA per amministratori, portali e Remote Access.
• Correggere o giustificare le regole firewall ampie.
• Attivare il logging nelle regole importanti.
• Verificare backup e processo di ripristino.
• Documentare il processo di hotfix e firmware.
• Impostare gli override solo con giustificazione.
• Documentare regolarmente il risultato dell’Health Check.

FAQ