Sophos Fusion: configurare e verificare Server Threat Protection in sicurezza

Dopo l’installazione di un agente server, la presenza di un criterio nell’interfaccia non prova che la protezione sia efficace. Se installazione e verifica dell’agente non sono ancora concluse, per Windows Server consultare la procedura di installazione e verifica di Windows Server; i server Linux richiedono invece la procedura di installazione SPL. Per una baseline sicura in Sophos Fusion (in precedenza Sophos Central), verificare prima il server effettivo e la sua piattaforma, mantenere poi le impostazioni consigliate in un piccolo gruppo pilota e infine controllare nelle schede Policies, Status ed Events del server quali impostazioni sono state recepite. I server Windows e Linux condividono l’interfaccia dei criteri, ma non tutte le funzionalità di protezione.

Prima della modifica: registrare piattaforma e ambito

Annotare tenant, nome del server, sistema operativo, agente installato, licenza disponibile o funzionalità acquistate, ruolo del server e criterio attuale. Confrontare un server pilota Windows e uno Linux con lo stesso profilo di produzione; i server database, i domain controller e gli host di container Linux richiedono test separati per le differenze di carico e di accesso ai file. Gli esempi Pilot-Windows-App e Pilot-Linux-App sono nomi di gruppi di server liberamente selezionabili, non valori prescritti da Sophos. In My Products > Server > Servers, aprire la scheda Server Groups e selezionare Add Server Group. Creare un gruppo per ciascuna piattaforma e assegnarvi singoli server. Un server può appartenere a un solo gruppo: assegnarlo a un gruppo pilota lo rimuove dal gruppo precedente e può modificare anche altri criteri effettivi. Prima dello spostamento, documentare per ogni server il gruppo precedente, i criteri applicati e il relativo ordine, le assegnazioni e le impostazioni come base per il ripristino. Iniziare con pochi server rappresentativi, non con l’intera produzione.

La Base Policy protegge i server quando non si applica alcun criterio corrispondente con priorità superiore. I criteri aggiuntivi consentono deroghe mirate. Sophos Fusion applica, per ogni tipo di criterio, il primo criterio attivo corrispondente dall’alto; le impostazioni di più criteri Threat Protection non vengono combinate. Il documento sui principi dei criteri spiega questo modello di selezione comune; per questo progetto pilota contano però i criteri Server e i gruppi di server, non i gruppi di computer endpoint. Posizionare il criterio specifico per il gruppo pilota sopra un criterio generale e mantenere il resto della baseline consigliata. Le modifiche a un criterio condiviso interessano tutti i server a cui è assegnato: controllare l’assegnazione prima di premere Save.

Configurare Server Threat Protection nel progetto pilota

Aprire My Products > Server > Policies e selezionare Add Policy. Se compare una scelta, selezionare Threat Protection; per modificare un criterio esistente, aprire prima il tipo di criterio e poi il nome. Assegnare il nuovo criterio al piccolo gruppo pilota in Assigned to e controllare Excluded from, se visualizzato. Non modificare inavvertitamente la Base Policy per tutti i server.
Aprire Settings e lasciare attivo il criterio. In Show filters > Operating System selezionare prima Windows, premere Apply, ripetere per Linux e premere nuovamente Apply. Il filtro mostra le impostazioni disponibili per la rispettiva piattaforma; non abilita funzionalità sull’agente. Recommended ed Enabled/Disabled aiutano a individuare le differenze rispetto alle impostazioni consigliate.
Mantenere, se possibile, le impostazioni consigliate per Live Protection, Deep Learning e Real-time Scanning - Local Files and Network Shares. In Real-time Scanning - Local Files and Network Shares, Scan controlla la scansione in tempo reale dei file locali e dei file a cui si accede tramite rete; Local limita la scansione ai file del dispositivo. Il passaggio a Local richiede un caso d’uso motivato e una prova delle condivisioni interessate.
La protezione Linux on-access è disattivata per impostazione predefinita. Per un progetto pilota Linux con protezione all’accesso ai file deve essere installato il prodotto SPL antivirus, ossia il relativo plugin AV. Nel criterio Server Threat Protection effettivo, sotto Real-time Scanning - Local Files and Network Shares, devono essere attivati sia Scan sia Enable scan for Server Protection for Linux Agent; la seconda opzione è disattivata all’origine. Verificare il componente AV installato sul server pilota come descritto nel documento sull’installazione SPL collegato sopra. Se manca il componente o anche solo una delle due opzioni attivate, non considerare verificata la protezione on-access del progetto pilota: documentare la lacuna e interrompere l’estensione. Una scansione pianificata non sostituisce quella in tempo reale: controlla i file a orari stabiliti, non all’accesso. Enable scheduled scan è disponibile per entrambe le piattaforme; se necessario, scegliere una fascia oraria a basso carico. L’orario segue l’ora locale del dispositivo. Su Linux, la scansione pianificata usa Live Protection indipendentemente dalla relativa impostazione nel criterio.
Lasciare attivo Enable event journals, se possibile: senza queste registrazioni mancano i dati per le indagini successive relative al periodo in cui era disattivato; inoltre Threat Graphs e, se utilizzato, Server File Integrity Monitoring non funzionano. Non configurare qui le dimensioni globali dei journal. Salvare la modifica e verificare il criterio effettivo sul dispositivo prima di assegnare altri server.

Non equiparare le piattaforme: la scansione Internet in tempo reale, la decrittazione HTTPS, la protezione CryptoGuard/exploit, AMSI, Adaptive Attack Protection e Security Heartbeat sono documentate come funzionalità Windows di questo criterio. Questo non implica che abbiano un effetto equivalente su Linux. Linux runtime detections è una funzionalità Linux separata che richiede una licenza idonea; la sola presenza dell’opzione nell’interfaccia non dimostra né il diritto d’uso né l’attivazione del rilevamento a runtime. Verificare la licenza specifica e lo stato dell’agente e del tenant prima di prevederne l’uso. Anche le opzioni Linux per la scansione in tempo reale e per la terminazione dei processi dannosi ad essa associati non equivalgono ai moduli di protezione runtime di Windows.

Esclusioni solo per conflitti documentati

Un’esclusione dalla scansione riduce la protezione, anche se per l’oggetto escluso possono continuare a valere altri controlli. In caso di falso rilevamento, cercare nella scheda Events ora, rilevamento e percorso interessato; confrontarli con la versione dell’applicazione, le indicazioni del produttore e un errore riproducibile. Un’applicazione database può però subire un impatto misurabile dalle scansioni a causa dei frequenti accessi ai file anche senza un evento di rilevamento: confrontare in modo riproducibile tempi di esecuzione, carico e accessi interessati prima e dopo un test a tempo limitato nel gruppo pilota. Un servizio semplicemente lento, senza un legame verificabile con la scansione, non giustifica un’esclusione.

In Settings > Exclusions > Add Exclusion, scegliere Exclusion Type e inserire soltanto l’oggetto specificamente interessato. Per File or folder, limitare Active for a Real-time Scanning o Scheduled Scanning, se non è dimostrato che siano interessate entrambe. In caso di carico documentato su un database Windows, valutare prima Process (Windows) con il percorso completo dell’applicazione secondo le indicazioni del produttore: vengono esclusi soltanto i file utilizzati da quel processo durante i suoi accessi, anziché escludere un intero albero di file anche per altri processi. Per Linux, File or folder (Linux) supporta percorsi di file e cartelle e i caratteri ? e *; un percorso completo come /mnt/hgfs/excluded è un esempio di sintassi tratto dalla documentazione Sophos, non una raccomandazione generale a escludere quella cartella. Sostituirlo esclusivamente con un percorso verificato sul server interessato. Non considerare le esclusioni Windows per processi o exploit come equivalenti su Linux. Non usare esclusioni Detected Exploits o per hashing come soluzione generica ai problemi di scansione; prima di creare esclusioni per hashing, coinvolgere Sophos Support. Un’esclusione del criterio vale solo per i server a cui quel criterio viene applicato; una Global Exclusion ha invece effetto sull’intero tenant. Durante l’esame degli eventi, non creare un’esclusione globale del rilevamento tramite Don’t detect this again. La guida alle esclusioni per endpoint e server illustra tipi, ambito e ripristino; la scelta qui resta una decisione relativa al criterio server. Documentare l’evento di rilevamento oppure dati prestazionali riproducibili, indicazioni del produttore, motivo, responsabili, server interessati, test e data di scadenza prevista. Dopo aver salvato, verificare il flusso di lavoro interessato e rimuovere l’esclusione non appena la causa è risolta e il ripristino è stato verificato.

Dimostrare l’effetto sul server specifico

Aprire My Products > Server > Servers, selezionare il server pilota e controllare:

Policies: sotto Threat Protection compare davvero il criterio previsto? In caso contrario, controllare assegnazione, attivazione e ordine. Un clic sul criterio ne apre le impostazioni; le modifiche apportate qui interessano anche gli altri server a cui è assegnato.
Status: sui server Windows più recenti, Health status e le valutazioni Communication, Operations, Services, System, Threat e Update segnalano possibili problemi. Su Linux e sui server Windows meno recenti, Security Health mostra fra l’altro l’ultimo contatto con Sophos Fusion e i servizi Sophos in esecuzione; questa visualizzazione non corrisponde alla valutazione dettagliata di Windows. Il solo stato verde non dimostra che la protezione dagli attacchi sia stata testata.
Events: controllare le segnalazioni, gli aggiornamenti riusciti e, se presente, un rilevamento precedente tramite Details nell’intervallo di tempo rilevante. L’assenza di eventi malware non è un test funzionale. Non avviare appositamente azioni malware o exploit su un server di produzione. L’ora indicata da Last active può essere anteriore a un evento perché viene aggiornata circa una volta all’ora.

Per Linux, verificare anche localmente il prodotto antivirus/plugin AV installato e il criterio recepito (le procedure di verifica sono nel documento sull’installazione SPL). Policies, Status, Events e uno stato di salute verde non dimostrano, da soli, né che la scansione on-access sia attiva né che rilevi le minacce. Solo su un sistema non di produzione autorizzato, un test funzionale controllato con l’innocuo file di prova EICAR, secondo le istruzioni Sophos, può verificare la reazione all’accesso al file, la registrazione nel log AV e l’alert in Fusion; rimuovere il file di prova e gestire l’alert del test secondo la procedura locale. Senza questo test, l’efficacia del rilevamento resta non confermata; non eseguire test malware in produzione.

Inoltre, Account Health Check mostra le divergenze dei criteri Server Threat Protection rispetto alle raccomandazioni Sophos. In presenza di un avviso, aprire il criterio indicato, controllare le impostazioni evidenziate in rosso e correggerle in modo mirato. Fix automatically ripristina le impostazioni consigliate per tutte le opzioni dei criteri interessati e può sovrascrivere le deroghe intenzionali del progetto pilota: prima di confermare, verificare i server coinvolti e la portata della modifica. Esaminare separatamente l’avviso relativo alle Policy exclusions rischiose: il controllo rileva solo le esclusioni particolarmente insicure; uno stato verde non attesta che tutte le esclusioni siano innocue. Anche in questo caso, non applicare correzioni automatiche senza verificare l’intero ambito dei criteri interessati: potrebbero essere rimosse esclusioni da tutti i criteri coinvolti. L’audit log registra le modifiche automatiche. Dopo ogni correzione, ricontrollare criterio, stato ed eventi sul server pilota.

Se il risultato non corrisponde alla configurazione

Criterio errato o criterio atteso assente: controllare tenant, gruppo di server, attivazione del criterio e priorità nell’elenco. Leggere il nome corretto nella scheda Policies del server; non dedurre l’effetto dal solo elenco dei criteri.
Scansione in tempo reale Linux incerta: nel criterio Linux effettivo, filtrato per piattaforma, controllare Scan e Enable scan for Server Protection for Linux Agent sotto Real-time Scanning - Local Files and Network Shares, nonché il plugin AV/prodotto SPL antivirus in locale. Se manca un elemento o l’effetto resta incerto, non dichiarare attiva la protezione on-access, non estendere il progetto pilota e trasmettere a Sophos Support dettagli dell’agente e della licenza e dati diagnostici.
Avviso o valutazione Health rossa: su Windows aprire la valutazione specifica per Communication, Services o Update; su Linux confrontare l’ultima attività in Fusion, i servizi in esecuzione e gli alert. Risolvere prima i problemi di comunicazione o aggiornamento, poi ricontrollare la ricezione del criterio.
Applicazione lenta o file bloccato: in caso di blocco, controllare l’evento contemporaneo e il percorso; in caso di rallentamento senza evento, raccogliere confronti riproducibili di carico e accessi insieme alle indicazioni del produttore. Non escludere per supposizione un’intera struttura di directory o l’intero tenant. Un’esclusione ristretta nel progetto pilota è giustificabile solo con una causa documentata e una via di ripristino. Se la divergenza persiste, documentare i risultati, l’assegnazione del criterio e lo stato dell’agente, quindi chiedere supporto.

Interrompere il progetto pilota e ripristinare lo stato precedente

Interrompere l’estensione in caso di assenza della protezione Linux on-access, criterio effettivo errato, agente persistentemente in stato non sano, blocchi non chiariti o disturbo misurabile di un carico di lavoro critico per l’attività. Registrare i server interessati e la divergenza; concordare il ripristino durante la finestra di modifica con i responsabili del carico di lavoro. Riportare ogni server spostato nel gruppo precedente oppure rimuoverlo dal gruppo pilota se prima non apparteneva ad alcun gruppo. Se le modifiche del progetto pilota hanno alterato un criterio esistente, la sua priorità o la sua assegnazione, ripristinare anche ordine, assegnazioni e impostazioni documentati; il solo ritorno al gruppo precedente non ripara un criterio modificato. Ritirare in modo mirato le esclusioni del progetto pilota dopo aver verificato il carico di lavoro interessato: assicurarsi prima che la rimozione non faccia ricomparire il blocco o il rallentamento precedente; se necessario, accertare la causa e nel frattempo documentare l’eventuale necessità residua, strettamente limitata e temporanea, invece di rimuovere le esclusioni senza controllo. Verificare poi su ogni server interessato appartenenza al gruppo, criteri effettivi, Status/Health, Events e flusso di lavoro precedentemente compromesso. In assenza di una verifica riuscita, mantenere bloccata l’estensione e inoltrare il problema ai responsabili competenti.