Sophos Firewall: Best Practices per la sicurezza di rete moderna

Le firewall sono state a lungo il luogo in cui si respingono gli attacchi. Oggi sono esse stesse uno degli obiettivi più attraenti. È logico: una firewall si trova in una posizione privilegiata tra Internet, reti locali, servizi cloud, accessi VPN e applicazioni interne. Chi trova una vulnerabilità, una password debole o una configurazione errata qui, non è più davanti alla porta, ma spesso già all’interno dell’edificio.

Proprio per questo non basta più considerare una firewall solo come un motore di policy per regole di consentire e negare. La sicurezza di rete moderna richiede tre pilastri: Rafforzamento, Protezione e Rilevamento e Risposta. Bisogna ridurre la superficie di attacco prima di un attacco, bloccare in modo pulito durante un attacco e poi riconoscere rapidamente cosa è successo.

Gestisco ambienti Sophos Firewall da molti anni in dimensioni e settori molto diversi. Le seguenti raccomandazioni non sono quindi intese come un elenco teorico di funzionalità, ma come ciò che si è dimostrato valido in ambienti clienti reali, migrazioni, audit e casi di supporto.

Perché le firewall sono così nel mirino

Una firewall è un obiettivo redditizio per gli aggressori perché è esposta, privilegiata e spesso critica per il business. Inoltre, molte ambienti gestiscono firewall, portali VPN o accessi di gestione remota per anni. Non ogni ambiente è ben patchato, non ogni superficie di gestione è veramente isolata e non ogni accesso è protetto da autenticazione multi-fattore.

Nella pratica, emergono soprattutto tre cause ricorrenti per attacchi riusciti:

• Vulnerabilità in firewall e sistemi edge, specialmente quando le patch vengono applicate in ritardo o non vengono applicate affatto.
• Credenziali compromesse e attacchi di identità, spesso senza MFA o con configurazione MFA debole. Il Sophos Active Adversary Report 2026 cita cause legate all’identità come causa principale nel 67,32% dei casi esaminati.
• Sistemi esposti, come RDP, portali VPN, portali utente o interfacce amministrative, che sono direttamente accessibili da Internet.

Il pensiero principale dietro a questo: molti attacchi oggi non sono più un “intrusione” spettacolare. Molto spesso gli aggressori semplicemente si loggano. Se un account utente, una password amministrativa o un accesso VPN è compromesso, il primo passo per la firewall sembra inizialmente un utilizzo legittimo.

I tre pilastri della sicurezza di rete moderna

La sicurezza delle reti moderne può essere intesa come uno spettro da proattivo a reattivo:

1. Rafforzamento: Ridurre la superficie di attacco, rimuovere i sistemi obsoleti, utilizzare prodotti sicuri, verificare le configurazioni, limitare l’accesso.
2. Protezione: Bloccare gli attacchi, controllare il traffico crittografato, utilizzare in modo sensato le funzioni di Web, IPS, Zero-Day e Application Control.
3. Rilevamento e Risposta: Riconoscere le anomalie, isolare i dispositivi compromessi, correlare i dati delle minacce e reagire automaticamente.

Molte firewall sono tradizionalmente forti nel secondo pilastro. Questi sistemi bloccano il traffico, controllano i pacchetti, riconoscono modelli noti e applicano le policy. Questo è importante, ma non più sufficiente. Se la firewall stessa è configurata in modo errato, se l’accesso remoto funziona senza MFA o se un sistema non patchato continua a essere produttivo, si ha un problema strutturale che nessuna singola regola IPS può risolvere in modo pulito.

La mia esperienza mostra: i migliori risultati non derivano da una singola funzione magica, ma da una configurazione di base pulita, revisioni regolari e una firewall che è integrata nel resto del processo di sicurezza.

Pilastro 1: Rafforzamento prima dell’attacco

Il rafforzamento è la parte del lavoro di sicurezza che raramente riceve applausi, ma che fa la differenza in caso di emergenza. Si tratta di meno superficie di attacco, meno eredità, meno percorsi di gestione aperti e meno dipendenza da reazioni manuali.

Ridurre l’infrastruttura e rimuovere i sistemi obsoleti

Il modo più semplice per ridurre una superficie di attacco è a volte il più scomodo: spegnere le cose. Ogni vecchio dispositivo, ogni servizio VPN dimenticato, ogni portale di gestione e ogni server non più supportato è un punto di attacco aggiuntivo. Particolarmente critici sono i sistemi che si trovano al bordo della rete o che consentono accesso privilegiato indiretto alle reti interne.

Per gli amministratori di Sophos Firewall significa concretamente:

• Verificare regolarmente quali firewall, RED, gateway VPN, controller WLAN, proxy inversi e componenti di accesso remoto sono ancora produttivi.
• Rimuovere i sistemi End-of-Life o End-of-Support da posizioni privilegiate.
• Consolidare le funzioni, se ciò riduce la complessità: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, Reporting e Central Management devono essere il più possibile ben coordinati.
• Documentare quali servizi devono essere veramente accessibili da Internet.

L’obiettivo non è inserire il più possibile in un prodotto. L’obiettivo è evitare eredità cieche. Un’infrastruttura piccola, aggiornata e ben controllata è quasi sempre più sicura di un ambiente grande, storicamente cresciuto con molte eccezioni “è sempre stato così”.

Proteggere l’accesso di gestione in modo coerente

Una delle best practice più importanti è semplice: la Web Admin Console e il User Portal non dovrebbero essere inutilmente accessibili dal WAN. Se è necessaria l’amministrazione remota, dovrebbe avvenire tramite Sophos Central, una rete di gestione dedicata, ZTNA o un altro percorso controllato.

Vedo spesso in ambienti clienti che non è la tecnica di attacco più complicata il problema, ma un vecchio accesso amministrativo, un portale storicamente cresciuto o un’eccezione “temporanea” che non è mai stata rimossa. Proprio questi punti appartengono a una revisione regolare della firewall.

I seguenti punti dovrebbero essere verificati in ogni ambiente Sophos Firewall:

• Attivare MFA per gli amministratori, specialmente per l’admin standard e tutti gli account con ampi diritti.
• Imporre MFA per le connessioni VPN e i portali, se tali accessi sono ancora utilizzati.
• Evitare l’accesso WAN alla Admin Console e al User Portal o limitarlo fortemente a reti di origine dedicate.
• Configurare regole di password forti per utenti e amministratori.
• Proteggere SSH, idealmente con autenticazione a chiave pubblica e senza ampia raggiungibilità WAN.
• Attivare backup centrali e proteggere l’accesso ai backup, poiché i backup delle configurazioni possono contenere informazioni sensibili.
• Attivare notifiche e logging, in modo che gli eventi rilevanti per la sicurezza non passino inosservati durante l’operazione.

Il punto sui backup è spesso sottovalutato. Un backup della firewall non contiene solo impostazioni innocue, ma informazioni su reti, regole, certificati, VPN e strutture interne. Pertanto, i backup devono essere crittografati, archiviati in modo controllato e testati regolarmente.

Impostare consapevolmente Device Access e Local Service ACL

Quando si parla di accesso WAN, bisogna parlare concretamente di Device Access e Local Service ACL nella Sophos Firewall. Nella matrice di accesso ai dispositivi si stabilisce per zona quali servizi locali della firewall sono raggiungibili: amministrazione HTTPS, User Portal, SSH, Ping, DNS, Captive Portal, portali VPN e altri servizi.

La best practice è molto semplice ma efficace: dalla zona WAN dovrebbe essere raggiungibile solo ciò che è veramente necessario. L’accesso amministrativo, SSH e User Portal non appartengono ampiamente su Internet. Se sono necessarie eccezioni, dovrebbero essere limitate tramite Local Service ACL Exception Rules a indirizzi IP di origine specifici o reti di gestione.

Regole di paese come protezione minima

Se gli indirizzi IP di origine fissi non sono realistici, consiglio almeno di lavorare con regole di paese. L’accesso solo da pochi paesi rilevanti è comunque molto meglio della raggiungibilità mondiale. In alternativa, si possono bloccare i paesi con cui l’azienda non ha alcun rapporto e in cui non ci sono tipicamente dipendenti o amministratori in viaggio. Questo non sostituisce MFA, ruoli forti e ACL pulite, ma riduce il rumore inutile e molti tentativi di accesso automatizzati.

Dal mio punto di vista, questo è uno dei primi punti in ogni revisione della firewall. Molte configurazioni rischiose non nascono da cattive intenzioni, ma perché un servizio è stato aperto brevemente per una migrazione, un caso di supporto o un test e non è mai stato chiuso successivamente. Proprio questi dettagli distinguono una firewall che funziona semplicemente da una firewall che è veramente gestita in modo pulito.

Verificare la sicurezza del login e i ruoli amministrativi

MFA è importante, ma il livello di login è composto da più di un secondo fattore. Gli amministratori dovrebbero utilizzare account propri e tracciabili e non lavorare permanentemente con un amministratore completo condiviso. I diritti basati sui ruoli aiutano a separare gli accessi di supporto, reporting o helpdesk dall’amministratore effettivo della firewall.

Inoltre, i tentativi di login falliti dovrebbero essere limitati, le sessioni terminate correttamente e gli accessi amministrativi limitati a reti definite. Un disclaimer di login può essere legalmente utile in determinati ambienti, ma non sostituisce controlli tecnici reali. Più importanti sono politiche di password forti, sessioni inattive brevi, protezione contro il brute-force e il principio del minimo privilegio.

Evitare la fatica da patch: gli hotfix devono agire rapidamente

Il patching è uno dei temi in cui teoria e pratica sono molto distanti. Ovviamente ogni amministratore sa che gli aggiornamenti del firmware sono importanti. Nella realtà, però, significano finestre di manutenzione, valutazione del rischio, pianificazione HA, comunicazione con i dipartimenti e talvolta anche downtime. Questo porta alla fatica da patch: gli aggiornamenti vengono posticipati perché sono impegnativi.

Proprio qui la componente temporale è pericolosa. Gli attacchi di identità sono ormai la causa principale, ma lo sfruttamento delle vulnerabilità rimane un vettore reale, specialmente nei sistemi edge come firewall, VPN e altri servizi vicini a Internet. Il Sophos Active Adversary Report 2026 cita come esempio CVE-2024-40766 in SonicOS, visibile in una grande parte dei casi di exploit confermati nel dataset. Allo stesso tempo, il tempo mediano tra l’advisory del produttore o la patch e lo sfruttamento osservato era di 322 giorni. Questo è un segnale piuttosto chiaro: la fatica da patch non è un problema operativo astratto, ma una finestra di attacco.

Sophos Firewall fa un passo importante qui: Automated Hotfixes consentono patch di sicurezza rilevanti senza una finestra di manutenzione classica. Per gli amministratori è estremamente prezioso, perché l’effetto di protezione critico non si verifica solo quando arriva la prossima finestra di manutenzione libera.

Tuttavia, vale: gli hotfix non sostituiscono una strategia di aggiornamento pulita. Gli hotfix chiudono la pericolosa lacuna tra vulnerabilità scoperta e aggiornamento firmware regolare. La best practice è quindi:

• Lasciare attivati gli hotfix.
• Verificare regolarmente gli stati del firmware e documentare la preparazione dell’aggiornamento del firmware.
• Leggere in anticipo i percorsi di aggiornamento e la compatibilità.
• Preparare backup e piano di rollback.
• Pianificare separatamente cluster HA e sedi remote.

Non trattare VPN come prova di fiducia

Il Remote Access VPN è stato per anni lo standard. Il problema: il VPN classico spesso pensa in termini di reti, non di applicazioni. Chi è connesso con successo si trova, dal punto di vista di molti ambienti, già in un’area di fiducia. Se il dispositivo finale è compromesso o le credenziali sono state rubate, un aggressore può muoversi da lì.

Zero Trust Network Access (ZTNA) risolve questo problema non con la magia, ma con un principio migliore: Non fidarti di nulla, verifica tutto. L’accesso non viene concesso in modo generico a una rete, ma valutato per utente, dispositivo, stato e applicazione. Un dispositivo deve essere sano e conforme, l’identità deve essere verificata e la policy decide in modo granulare quale applicazione è raggiungibile.

ZTNA non è una decisione automatica di Sophos

È importante notare che: ZTNA non è una decisione che deve automaticamente parlare per Sophos ZTNA. A seconda dell’ambiente, fornitori specializzati di ZTNA, SSE o SASE possono essere più avanzati funzionalmente, offrire migliori integrazioni o adattarsi meglio a livello organizzativo. Ciò che conta non è il nome del produttore, ma se identità, stato del dispositivo, accesso alle applicazioni, logging e operatività funzionano bene insieme.

Questa è anche la mia posizione fondamentale nei progetti Sophos: non scelgo automaticamente Sophos per ogni argomento. Se una soluzione di terze parti per ZTNA, SSE, Threat Intelligence, SIEM o NDR si adatta meglio, è proprio quella la raccomandazione migliore. Una buona architettura di sicurezza non nasce dalla massima dipendenza dal produttore, ma da componenti ben integrate con responsabilità chiare.

Per ambienti puramente Sophos, l’integrazione può comunque essere interessante, perché ZTNA, Endpoint, Firewall e Sophos Central possono essere utilizzati insieme. Un dispositivo compromesso o non conforme può perdere l’accesso senza che un amministratore debba prima modificare manualmente le regole della firewall. Vale anche la pena dare un’occhiata al ZTNA Gateway sulla Sophos Firewall. In ambienti misti o più grandi, tuttavia, si dovrebbe confrontare consapevolmente e non impostare automaticamente il produttore della firewall esistente come piattaforma ZTNA.

Chi oggi si affida ancora fortemente a SSL VPN o IPsec Remote Access dovrebbe almeno verificare questi punti:

• Imporre MFA per ogni accesso remoto.
• Rimuovere utenti VPN vecchi o non utilizzati.
• Controllare l’importazione di gruppi da AD o Entra ID, in modo che l’accesso remoto non venga attivato involontariamente.
• Ridurre al minimo il tunnel diviso, le reti consentite e le autorizzazioni.
• Pianificare una migrazione graduale a una soluzione ZTNA, SSE o SASE adatta, specialmente per app web interne, RDP, SSH, portali di amministrazione e applicazioni aziendali.

Segmentazione contro il movimento laterale

Se gli aggressori entrano con credenziali valide o tramite un servizio esposto, la segmentazione interna decide quanto possono muoversi. Una firewall non dovrebbe quindi essere solo un gateway perimetrale, ma dovrebbe separare chiaramente le zone interne: utenti, server, gestione, IoT, rete ospiti, produzione, backup e sistemi particolarmente critici non appartengono ciecamente allo stesso modello di fiducia.

Praticamente significa: costruire VLAN e zone non solo per amore dell’ordine, ma proteggerle con vere regole di firewall. Tra le reti utente e server dovrebbero essere consentite solo le applicazioni necessarie. Gli accessi di gestione appartengono a reti amministrative dedicate. Le reti IoT e delle stampanti non dovrebbero parlare liberamente con i server. I backup e i controller di dominio meritano regole particolarmente restrittive e un buon logging.

Proprio qui si chiude il cerchio con l’affermazione “gli aggressori si loggano”. Se un account compromesso ha accesso solo a un’applicazione, ma non all’intera rete, un incidente non diventa automaticamente una compromissione completa.

Nei nuovi progetti pianifico quindi la segmentazione il prima possibile. Successivamente è ancora possibile, ma molto più faticoso, perché applicazioni, eccezioni e dipendenze storiche devono essere prima districate.

Rendere visibili le configurazioni errate

Una firewall può essere tecnicamente molto potente e tuttavia diventare pericolosa a causa di una configurazione errata. Regole troppo ampie, oggetti “Any”, autenticazione debole, politiche IPS mancanti, aggiornamenti dei pattern disattivati o portali aperti sono esempi tipici. La difficoltà è che in ambienti cresciuti non si vedono sempre immediatamente questi rischi.

Il Sophos Firewall Health Check affronta proprio questo problema. Controlla dozzine di impostazioni rispetto alle best practice e ai benchmark e mostra nel Control Center dove le configurazioni sono rischiose o deviano dagli standard raccomandati. I risultati sono prioritizzati per rischio, conducono con un clic alle impostazioni interessate e possono essere risolti o consapevolmente ignorati a seconda della situazione.

Particolarmente utile è il Health Check per i processi operativi ricorrenti:

• dopo un nuovo rollout della firewall,
• dopo grandi cambiamenti di regole,
• prima e dopo gli aggiornamenti del firmware,
• prima degli audit,
• dopo migrazioni da hardware vecchio,
• come controllo trimestrale regolare.

È importante però anche: un Health Check non toglie agli amministratori il pensiero. Non ogni raccomandazione si adatta a ogni ambiente. Alcuni punti hanno motivi di conformità o operativi, altri sono chiare vulnerabilità di sicurezza. Ciò che conta è valutare consapevolmente le deviazioni e non lasciarle crescere inosservate.

Dal mio punto di vista, il Health Check è soprattutto uno strumento operativo continuo. Non è solo qualcosa per il primo go-live, ma un buon punto di partenza per revisioni trimestrali, preparazione agli audit e la pulizia di vecchi set di regole.

Secure by Design: Rafforzare la firewall stessa

Dal mio punto di vista, non servono solo prodotti di sicurezza, ma prodotti di sicurezza sicuri. Questa è una differenza importante. Una firewall non deve solo bloccare gli attacchi ad altri sistemi, ma deve essere essa stessa rafforzata contro gli attacchi.

Nella Sophos Firewall ciò include diversi livelli:

• Kernel rafforzato e architettura modernizzata: La più recente architettura Xstream si basa maggiormente su isolamento, modularizzazione, containerizzazione e separazione dei privilegi. Ciò riduce determinate classi di vulnerabilità e limita gli impatti grazie a un migliore isolamento. Inoltre, ci sono mitigazioni contro vulnerabilità di canale laterale e CPU. Questo rende la piattaforma più robusta, ma non immune alle vulnerabilità.
• Automated Hotfixes: Le correzioni di sicurezza possono essere distribuite molto rapidamente e senza una finestra di manutenzione classica.
• Remote Integrity Monitoring: Il sensore Linux integrato Sophos XDR può monitorare l’integrità del sistema in tempo reale, ad esempio modifiche di configurazione non autorizzate, esportazioni di regole, esecuzione di programmi sospetti o manomissione di file. Tuttavia, è utile solo se la funzione è attivata, con licenza, collegata e monitorata durante l’operazione.
• Gestione centrale sicura: L’amministrazione può avvenire tramite Sophos Central, senza aprire ampiamente le porte di gestione su Internet.
• Health Check: Le configurazioni rischiose diventano immediatamente visibili.
• Backup crittografati: I dati di configurazione vengono trasmessi e archiviati in modo protetto.

Inoltre, Sophos si basa sul monitoraggio proattivo della base installata della firewall. La telemetria dalle firewall può aiutare a riconoscere prima i segnali di attacchi o manipolazioni. Se emerge un modello, Sophos può supportare clienti o partner in modo mirato e distribuire rapidamente hotfix su larga scala.

Questi punti sono meno spettacolari nella vita quotidiana rispetto a una nuova regola della firewall o a un attacco bloccato nel log. A lungo termine, però, sono decisivi. Un prodotto rafforzato riduce la probabilità che la firewall stessa diventi un punto di ingresso. Tuttavia, non sostituisce un processo di patch pulito, un monitoraggio e una verifica regolare delle configurazioni.

Cosa cercare nel produttore della firewall

Secure by Design non è solo una caratteristica del prodotto, ma anche una questione di produttore. I clienti dovrebbero aspettarsi dai produttori che trattino le vulnerabilità in modo trasparente, comunichino chiaramente le informazioni sul ciclo di vita, distribuiscano rapidamente le correzioni di sicurezza e costruiscano i loro prodotti in modo che le configurazioni errate e le componenti compromesse emergano il prima possibile.

La responsabilità è condivisa. I produttori devono fornire prodotti sicuri e reagire in modo trasparente. I clienti devono applicare gli aggiornamenti, sostituire i sistemi EOL, utilizzare MFA e verificare regolarmente l’operatività. Entrambi vanno insieme.

Pilastro 2: Protezione durante l’attacco

Il rafforzamento è la base. Successivamente, la firewall deve continuare a fare ciò per cui è stata utilizzata: controllare il traffico e bloccare gli attacchi. Nella Sophos Firewall ciò include tra l’altro IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection e Threat Intelligence Feeds.

Sophos punta fortemente sull’architettura Xstream. Il traffico affidabile può essere elaborato in modo più efficiente, compiti intensivi come le operazioni crittografiche vengono eseguiti su percorsi ottimizzati e per il traffico con rischio più elevato rimane più riserva di prestazioni per Deep Packet Inspection, TLS Inspection e Zero-Day Protection.

Proprio TLS Inspection è un buon esempio dell’equilibrio tra sicurezza e operatività. Senza decrittazione, una grande parte del traffico moderno rimane invisibile. Con regole TLS pianificate male, però, si generano casi di supporto, problemi di certificati o colli di bottiglia di prestazioni. La best practice non è quindi “decrittare tutto alla cieca”, ma classificare in modo pulito:

• gruppi di utenti e server critici prima,
• escludere in modo pulito categorie bancarie, sanitarie, di privacy e note problematiche,
• testare pagine di blocco e avviso,
• documentare la distribuzione dei certificati,
• analizzare attivamente i log.

La mia raccomandazione è di non avviare TLS Inspection come progetto tutto o niente. Meglio è un rollout pulito con gruppi di utenti chiari, eccezioni, finestre di test e analisi dei log. In questo modo aumenta la visibilità, senza che l’helpdesk venga travolto il primo giorno.

Anche i Threat Feeds appartengono a quest’area di protezione. Tali feed aiutano a bloccare direttamente al perimetro della rete IP, domini o URL noti malevoli. Nelle versioni più recenti di Sophos Firewall sono notevolmente più integrati in Active Threat Response e meccanismi di protezione.

I Threat Feeds diventano particolarmente interessanti quando non vengono utilizzati solo elenchi generici, ma feed di terze parti curati con contesto attuale. Un esempio è Cybora.io, dove IP e domini malevoli da varie fonti e telemetria della firewall vengono combinati in feed utilizzabili. Come tali feed possono essere utilizzati sulle firewall, l’ho descritto più dettagliatamente nell’articolo Threat Intelligence Feeds per la firewall.

Anche qui vale: i Threat Feeds devono essere testati e monitorati. Feed troppo aggressivi, processi di allowlist mancanti o responsabilità poco chiare possono bloccare traffico legittimo e causare più danni che benefici nell’operatività. I buoni feed non sostituiscono una revisione delle regole, ma sono un ulteriore elemento con un proprio tuning.

Inoltre, non bisogna dimenticare le classiche rafforzamenti SFOS: Spoof Protection e impostazioni DoS appropriate e il Geo-IP-Blocking possono ridurre accessi semplici, rumorosi o evidentemente indesiderati. Questo non sostituisce una policy pulita, ma toglie alla firewall rumore inutile e blocca percorsi di attacco che in molti ambienti non hanno alcun scopo legittimo.

Consiglio di procedere in modo pragmatico: prima controllare bene i grandi rischi, poi affinare gradualmente le funzioni di protezione e documentare con i log ciò che funziona davvero. Una policy sovraccarica che nessuno capisce più non è un guadagno di sicurezza a lungo termine.

Pilastro 3: Rilevamento e Risposta dopo il primo segnale

La parte più interessante della sicurezza di rete moderna è la reazione. Una firewall non dovrebbe lavorare isolata, ma utilizzare segnali da Endpoint, Server, NDR, MDR, XDR e Threat Intelligence. Sophos può sfruttare vantaggi dell’ecosistema qui, ma solo se queste integrazioni si adattano davvero all’ambiente.

Gli ecosistemi aiutano solo se si adattano

Synchronized Security e Security Heartbeat sono buone idee: la firewall può considerare lo stato degli endpoint e limitare o bloccare la comunicazione in caso di dispositivi compromessi. Nella realtà, però, sempre più aziende utilizzano Microsoft Defender o altre soluzioni Endpoint. In tal caso, questa parte dell’ecosistema Sophos funziona solo in modo limitato o per nulla. Proprio per questo non si dovrebbe prendere automaticamente tutto dallo stesso produttore solo perché viene offerto come ecosistema integrato.

La mia raccomandazione è chiara: ciò che conta è ciò che si adatta all’azienda e può essere implementato in modo pulito. Se Microsoft Defender, un altro EDR, un NDR di terze parti o un SIEM esterno è la base migliore, allora la firewall dovrebbe essere integrata bene in questa architettura. Più importante del cross-selling è che i log finiscano nel posto giusto, gli allarmi siano compresi e qualcuno verifichi regolarmente ciò che i sistemi segnalano. Senza analisi dei log, tuning e processo di incident, anche la migliore integrazione aiuta poco.

Con Active Threat Response le minacce riconosciute possono essere tradotte automaticamente in decisioni di rete. E con NDR Essentials la firewall ottiene una visione aggiuntiva sul traffico di rete sospetto, anche dove non è installato un classico agente Endpoint.

L’automazione ha bisogno di Runbook

L’automazione ha però bisogno di linee guida. Dovrebbe essere chiaro quali segnali possono bloccare automaticamente, chi revoca un’isolamento, come vengono gestiti i falsi positivi e come vengono testati tali processi. Senza Runbook, responsabilità e esercitazioni regolari, in caso di emergenza nessuno sa se un blocco era voluto, corretto o troppo aggressivo.

Cosa succede in caso di emergenza? Un dispositivo compromesso può essere isolato, la comunicazione C2 viene interrotta, l’esfiltrazione può essere bloccata e un analista MDR o XDR può attivare una Active Threat Response senza dover prima costruire manualmente una regola nella firewall. Questo è particolarmente prezioso se un attacco viene rilevato al di fuori degli orari normali di lavoro.

Per gli amministratori è importante soprattutto una cosa: la reazione deve essere abbastanza veloce. Se un analista MDR o XDR deve prima chiamare, scrivere un ticket e un amministratore locale deve poi costruire manualmente una regola il venerdì sera, il tempo di reazione è troppo lungo. La reazione automatizzata non significa che le persone vengano sostituite. Significa che il primo contenimento avviene immediatamente e il team può poi indagare in modo pulito.

Proprio nei team IT più piccoli, questa automazione è preziosa. Non tutte le aziende hanno un esperto di firewall disponibile 24 ore su 24. Se Endpoint, Firewall, NDR, MDR e SIEM collaborano in modo sensato tra produttori, si guadagna tempo, e il tempo è spesso il fattore più importante negli attacchi attivi.

Lista di controllo pratica per gli amministratori di Sophos Firewall

Chi desidera rafforzare oggi la propria Sophos Firewall può iniziare con questa lista:

Verificare immediatamente

• Gli hotfix sono attivati?
• MFA è attivo per gli amministratori?
• La Web Admin Console e il User Portal sono accessibili dal WAN?
• SSL VPN o IPsec Remote Access sono protetti con MFA?
• Ci sono ancora account amministrativi locali non utilizzati?
• I backup sono pianificati, crittografati e testati?
• Device Access e Local Service ACL sono ridotti al minimo?
• I servizi raggiungibili dal WAN sono almeno limitati a paesi rilevanti o reti di origine conosciute?
• Gli aggiornamenti dei pattern e gli stati del firmware sono aggiornati?

Entro le prossime settimane

• Eseguire il Health Check e prioritizzare i risultati.
• Verificare le vecchie regole della firewall con “Any” in origine, destinazione o servizio.
• Verificare i ruoli amministrativi, la sicurezza del login, i timeout delle sessioni e la protezione contro il brute-force.
• Inventariare i servizi esposti come RDP, SSH, server web, portali e regole NAT.
• Verificare le zone interne e le regole VLAN contro il movimento laterale.
• Confrontare le opzioni ZTNA, SSE o SASE per le applicazioni di accesso remoto tipiche.
• Verificare i Threat Feeds e la DNS Protection.
• Attivare Spoof Protection, protezione DoS e Geo-IP-Blocking in base al rischio.
• Testare strutturalmente TLS Inspection e distribuirlo gradualmente.

Pianificare strategicamente

• Sostituire i sistemi End-of-Life.
• Coordinare in modo sensato l’operatività di firewall, VPN, DNS, SD-WAN e ZTNA/SSE.
• Standardizzare la gestione centrale, il reporting e l’alerting, ad esempio tramite Sophos Central, SIEM o piattaforme di sicurezza esistenti.
• Definire l’export Syslog/SIEM e la conservazione dei log per analisi forensi.
• Integrare i segnali MDR/XDR/NDR nel processo di incident.
• Introdurre revisioni ricorrenti di rafforzamento della firewall.

Conclusione

Le best practice per la sicurezza di rete non sono un progetto una tantum, ma un modello operativo. Proprio perché le firewall sono così privilegiate al bordo della rete, devono essere regolarmente rafforzate, patchate, verificate e integrate nel rilevamento.

La mia raccomandazione dopo molti anni con Sophos Firewall è quindi chiara: una firewall moderna deve oggi essere più di un prodotto di protezione. Ciò che conta è un design sicuro, configurazioni errate visibili, correzioni di sicurezza rapide e una reazione che in caso di emergenza collabori con Endpoint, NDR, XDR e MDR.

O, detto in modo pratico: se una firewall è così vecchia che dovrebbe stare più in un museo che in un rack, non è solo un rischio operativo. È una superficie di attacco. E proprio questa superficie di attacco la tengo il più piccola possibile.

Supporto da Avanet

Se è necessario supporto per il rafforzamento di una Sophos Firewall, è possibile contattare Avanet. Come specialista Sophos di lunga data, supporto in audit di firewall, revisioni di Health Check, pulizia delle regole, accesso remoto e pianificazione ZTNA/SSE, strategie di aggiornamento e formazione per i team IT.

Un’occhiata esterna su accessi di gestione, configurazione VPN, vecchie regole, servizi esposti al WAN e stato degli aggiornamenti spesso vale la pena. Molti rischi non nascono da una singola impostazione errata, ma da eccezioni cresciute che nessuno mette più in discussione nella vita quotidiana.

In caso di interesse, basta un breve messaggio tramite il modulo di contatto. Successivamente si può chiarire insieme se una revisione compatta della firewall, un audit o una formazione per l’ambiente specifico sia la soluzione più sensata.

FAQ

Link utili

• Blog Avanet: Sophos Firewall v22: Panoramica e tutte le nuove funzionalità
• Blog Avanet: Threat Intelligence Feeds per la firewall
• Blog Avanet: Sophos ZTNA Gateway sulla Sophos Firewall
• Blog Avanet: Sophos NDR - Eliminare i punti ciechi nella rete
• KB Avanet: Aggiornamento del firmware Sophos Firewall - Preparazione e Best Practices

Fonti

• Sophos: Firewall: Network Security Best Practices
• Documenti Sophos: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report