Esaminare i report Sophos Managed Risk e correggere le vulnerabilità

Sophos Managed Risk crea ogni settimana report sulle vulnerabilità e sulla superficie di attacco esterna. Da My Products > Managed Risk > Report History è possibile scaricarli, circoscrivere i sistemi interessati e definire i passaggi successivi. Managed Risk consiglia le misure correttive. Le modifiche a server, applicazioni, dispositivi di rete o risorse cloud devono tuttavia essere implementate in modo controllato all’interno della propria azienda.

Per orientarsi rapidamente:

1. Controllare la notifica di un nuovo report e aprire Report History direttamente nel tenant Sophos Fusion (in precedenza Sophos Central) corretto.
2. In External, Internal o Account, individuare il report settimanale previsto in base al nome e al contesto della scansione.
3. Aprire il report delle vulnerabilità in formato HTML per il triage; usare CSV e PDF in base alle esigenze.
4. Esaminare prima i rischi elevati e gli asset critici. Verificare quindi l’asset interessato, gli elementi su cui si basa il rilevamento e la raccomandazione Sophos.
5. Individuare il responsabile del sistema o del servizio al di fuori di Managed Risk, pianificare la modifica e convalidarla tecnicamente.
6. Far esaminare domande o problemi relativi ai risultati delle scansioni e ai report tramite un caso Managed Risk; discutere le raccomandazioni correttive durante la revisione periodica con il team Managed Risk.

Scegliere il tipo e il formato di report corretti

Report History è suddiviso in tre schede. Il nome del file indica l’esecuzione da cui proviene il report:

Le parti Account_Name e Scan_name rappresentano rispettivamente il nome dell’account e quello della scansione. Sono segnaposto da confrontare con i nomi presenti nel proprio tenant.

I formati hanno finalità diverse:

• HTML è la vista di lavoro migliore per il triage. Mostra le vulnerabilità attive e risolte per livello di rischio e asset e offre filtri interattivi.
• CSV è adatto a una valutazione strutturata e al confronto con la documentazione interna del lavoro svolto. I report ASM e Discovery sono disponibili esclusivamente in formato CSV.
• PDF è una versione statica e leggibile di un report delle vulnerabilità. In genere HTML è più utile per circoscrivere i risultati a singoli asset.

Un file CSV ASM o Discovery non è un report delle vulnerabilità in un altro formato. ASM descrive la superficie di attacco esterna rilevata; Discovery descrive gli asset individuati da una scansione di rilevamento interna. Entrambi possono chiarire l’ambito delle verifiche successive, ma non contengono la stessa analisi di un report delle vulnerabilità.

Trovare un report settimanale e verificare il download

1. Aprire My Products > Managed Risk > Report History.
2. Selezionare la scheda appropriata: External, Internal o Account.
3. Cercare il report settimanale previsto in base al modello di nome documentato e alla scansione interessata.
4. Nella colonna Download report, fare clic sul collegamento del formato richiesto.
5. Aprire il file scaricato e, prima di valutarlo, verificare che l’account o la scansione e il tipo di report corrispondano all’attività di revisione.

Sophos invia una notifica quando sono disponibili nuovi report. La notifica avvia la revisione, ma Report History è la fonte autorevole. Il report previsto deve essere disponibile per il download nella scheda corretta. Se sono presenti più scansioni interne, il confronto del nome della scansione evita di valutare per errore il report di un altro segmento di rete.

Se manca un report previsto, controllare innanzitutto il tenant, la scheda selezionata, il modello del nome e la scansione interessata. Verificare poi se la notifica appartiene effettivamente all’esecuzione settimanale corrente. Se la discrepanza persiste, annotare nome del report, scheda, scansione prevista e ora della notifica per una richiesta al team Managed Risk. Non includere credenziali di accesso o altri segreti.

Ogni report di scansione rimane accessibile in Sophos Fusion per un massimo di due anni dalla data di completamento della relativa scansione. È destinato esclusivamente all’uso interno del cliente o dell’MSP e non può essere ridistribuito, rivenduto o altrimenti trasmesso al di fuori della sua organizzazione.

Filtrare e definire le priorità nel report HTML

Scaricare un report delle vulnerabilità in formato HTML e aprirlo localmente. In questa vista è possibile filtrare i risultati per Risk level, Device type e IP address.

Il report Account aggiunge filtri per i tipi di scansione e per le singole scansioni. Riassume i dati della scansione delle vulnerabilità esterna e di tutte le scansioni interne. È quindi adatto a una definizione complessiva delle priorità, ma per domande dettagliate non sostituisce l’esame del singolo report appropriato.

Per il primo triage, iniziare dai livelli di rischio più elevati e restringere poi i risultati per asset, tipo di dispositivo o scansione. Il livello di rischio, tuttavia, non determina da solo l’ordine. A parità di livello, un sistema esposto a Internet o un asset critico per l’attività può essere più urgente di un sistema di test isolato. Occorre inoltre verificare se più voci riguardano la stessa causa tecnica sullo stesso asset.

Riconoscere gli asset critici

Nel report HTML, a sinistra si trova l’elenco Assets. Posizionando il puntatore del mouse sul nome di un sistema contrassegnato, un riquadro mostra l’etichetta Critical Asset e, più in basso, la Critical Asset Description. Con Show critical assets only si limita la vista alle vulnerabilità che interessano asset critici. I widget in alto mostrano quindi il numero delle vulnerabilità associate e degli asset interessati.

Questa indicazione fornisce il contesto aziendale, ma non determina automaticamente la correzione concreta. La descrizione, la funzione effettiva e l’attuale responsabile del sistema devono comunque essere confrontati con la propria documentazione degli asset.

Le scansioni possono produrre falsi positivi e falsi negativi. Sophos, inoltre, non garantisce che forniscano un quadro completo e accurato delle falle di sicurezza. Un risultato richiede quindi una verifica tecnica; viceversa, l’assenza di un risultato non dimostra che non esista alcuna vulnerabilità. Non fare affidamento esclusivamente sulle scansioni.

Dal risultato alla correzione sicura

Una voce del report è il punto di partenza di una verifica tecnica, non una modifica già approvata. Qualsiasi intervento basato sui suggerimenti di Sophos relativi all’applicazione delle patch e alla correzione delle vulnerabilità non rientra nell’ambito del servizio; il cliente o l’MSP è l’unico responsabile della sua esecuzione e delle relative conseguenze. Per ogni risultato prioritario, seguire questo ciclo:

1. Confermare l’asset: confrontare indirizzo IP, nome host, tipo di dispositivo, tipo di scansione e, se pertinente, descrizione dell’asset critico con la documentazione aggiornata. Se non è possibile identificare l’asset, non apportare modifiche sulla base di supposizioni.
2. Comprendere il risultato: leggere il livello di rischio, il componente interessato e le informazioni o prove contenute nel report. Controllare se il report proviene da una scansione esterna, interna, autenticata o non autenticata; i diversi tipi possono fornire livelli di dettaglio differenti.
3. Valutare la raccomandazione: confrontare la correzione consigliata da Sophos con le istruzioni del produttore, la versione in uso, le dipendenze e lo stato effettivo del sistema. Una raccomandazione generica, come un aggiornamento o una modifica di configurazione, deve essere adatta al prodotto e al proprio ambiente.
4. Individuare il responsabile tecnico: identificare il responsabile di sistema, applicazione, rete o cloud tramite il proprio processo operativo. Report History non documenta una funzione di assegnazione; la registrazione del lavoro e l’approvazione della modifica devono quindi avvenire nel sistema interno previsto.
5. Mettere in sicurezza la modifica: definire impatto, finestra di manutenzione, backup o possibilità di ripristino e un test funzionale adeguato prima dell’implementazione. Soprattutto per gli asset di produzione o critici, il livello di rischio non giustifica la mancata considerazione delle dipendenze.
6. Correggere e convalidare: dopo la modifica autorizzata, verificare la versione o lo stato della configurazione sul sistema di destinazione e testare la funzione interessata. La sola voce del report non dimostra che il sistema funzioni correttamente.
7. Controllare il report successivo: nel prossimo report disponibile, riesaminare la stessa scansione e lo stesso asset. Un report modificato costituisce una prova aggiuntiva, ma non sostituisce la verifica tecnica del sistema né una funzione garantita di nuova scansione o chiusura.

Per la documentazione interna del lavoro, registrare i fatti verificabili: report e settimana, scansione, asset, vulnerabilità, raccomandazione esaminata, area tecnica responsabile, modifica autorizzata e risultato della convalida tecnica. Non dedurne campi o stati di Managed Risk che non siano documentati nell’interfaccia.

Limite della funzione di report: per la vista dei report Managed Risk non sono documentate funzioni di assegnazione, accettazione del rischio, nuova verifica avviata manualmente, chiusura o gestione degli SLA. Questi processi possono essere necessari internamente, ma non sono controlli garantiti né stati del prodotto Managed Risk. Anche le denominazioni “active” e “resolved” nel report HTML non equivalgono a uno stato di ticket controllabile dall’amministratore.

Usare le raccomandazioni e le revisioni periodiche

Il team Managed Risk esamina i report, formula raccomandazioni e discute risultati attuali, nuovi rischi e misure consigliate in riunioni periodiche. Per prepararsi, raccogliere i risultati ad alto rischio ancora irrisolti, gli asset interessati, i fatti tecnici già verificati e le domande specifiche. In questo modo si chiarisce se occorre spiegare il rilevamento, precisare il contesto della scansione o valutare una misura alternativa.

Un caso Managed Risk è il canale documentato quando il proprio team non riesce a chiarire domande o problemi relativi ai risultati delle scansioni delle vulnerabilità o ai report. Ciò vale, ad esempio, se:

• un risultato della scansione ad alto rischio non è chiaro o plausibile,
• il report e lo stato attuale del sistema non coincidono,
• il contesto della scansione, il rilevamento o il contenuto del report sollevano domande.

Le domande sulla correzione consigliata possono anche essere preparate per la revisione periodica con il team Managed Risk. Un caso non sostituisce l’approvazione interna della modifica né costituisce un’accettazione o una chiusura garantita della correzione.

La richiesta deve includere nome esatto del report, scheda e settimana, scansione interessata, asset, vulnerabilità in questione, discrepanza osservata e verifiche sicure già eseguite. Non trasmettere password, chiavi private o altri segreti.

Distinguere la correzione delle vulnerabilità dalla risposta attiva agli incidenti

Managed Risk è un servizio di gestione delle vulnerabilità e richiede una licenza MDR o MDR Plus esistente. Il normale processo descritto in questo articolo valuta le vulnerabilità, pianifica l’hardening o gli aggiornamenti e ne verifica gli effetti tecnici. Non equivale alla risposta a una compromissione attiva.

Se l’indagine rileva indizi di abuso in corso, una minaccia attiva o sistemi già compromessi, non attendere il report della settimana successiva. Si applica invece il percorso concordato di risposta agli incidenti o di escalation MDR. Il report delle vulnerabilità può fornire contesto, ma non sostituisce l’indagine, il contenimento e il ripristino dell’incidente.

Controllo finale per ogni ciclo di revisione

Al termine di ogni ciclo, verificare che:

• siano stati esaminati tutti i report settimanali previsti in External, Internal e Account,
• tipo, nome, scansione e formato del report corrispondano alla rispettiva valutazione,
• i rischi elevati e le vulnerabilità sugli asset critici siano stati valutati tecnicamente per primi,
• l’asset e gli elementi alla base del rilevamento siano tracciabili,
• ogni correzione implementata sia stata convalidata sul sistema di destinazione e con un test funzionale appropriato,
• i risultati ad alto rischio aperti o non chiari siano preparati per il team Managed Risk con domande concrete,
• gli indizi di una minaccia attiva non siano stati confusi con la normale correzione delle vulnerabilità.

Questo controllo documenta la propria revisione. Non crea uno stato finale in Managed Risk né garantisce un termine entro il quale una modifica sarà visibile in un report successivo.