Comprendere Sophos Incident Response, Readiness e assessment

In caso di incidente di sicurezza attivo o sospetto, si avvia il processo già concordato. Un attacco in corso non è un normale progetto di implementazione. Si utilizza il contatto previsto dal piano di emergenza e il diritto al servizio confermato, invece di ordinare prima un assessment o un nuovo retainer.

Il Digital Forensics and Incident Response (DFIR) combina indagine forense e risposta a un incidente concreto. La Readiness prepara responsabili e procedure. Security Testing e assessment esaminano un perimetro di sicurezza definito in anticipo. Questi servizi producono risultati differenti e non si sostituiscono a vicenda.

Trasferire correttamente un incidente

Sophos descrive DFIR come supporto per identificare e neutralizzare minacce attive, analizzare le cause, svolgere Compromise Assessment e Threat Hunting. Il lavoro effettivamente svolto dipende dal servizio commissionato e dal diritto confermato. La descrizione di un team operativo a ogni ora non è una promessa individuale sull’inizio dell’intervento, presenza in sede o durata del ripristino.

Per la prima consegna si prepara un quadro breve e tracciabile:

1. Referenti e potere decisionale: coordinamento tecnico dell’incidente, responsabili aziendali e canale di risposta autorizzato.
2. Osservazioni anziché supposizioni: orario con fuso, sistemi o identità coinvolti, messaggi concreti ed effetti visibili.
3. Misure già adottate: ad esempio isolamento, limitazioni degli account o ripristini, con orario ed esecutore.
4. Evidenze disponibili: log, ID dei casi e backup esistenti, con origine e luogo di conservazione. L’eventuale completezza sconosciuta va dichiarata.
5. Diritto e perimetro: cliente, contratto o retainer e area interessata nota. Un diritto non confermato non si presenta come acquisito.

Questo elenco è una raccomandazione Avanet per organizzare la consegna, non una procedura forense completa. Consente una prima gestione senza perdere informazioni con modifiche premature. I sistemi contaminati non si reinstallano soltanto per ottenere una «base pulita». I responsabili dell’incidente decidono isolamento, arresto, conservazione delle prove e ripristino secondo il caso concreto.

Le evidenze possono contenere password, dati personali o informazioni aziendali riservate. Si trasmette solo quanto necessario attraverso un canale sicuro confermato. Ticket pubblici, chat o collegamenti a file non protetti non sono alternative adeguate. Se gli account di comunicazione possono essere compromessi, si concorda prima un canale di ritorno affidabile.

Distinguere MDR e DFIR

MDR è il servizio gestito continuativo di ricerca delle minacce, rilevamento e risposta concordata. DFIR tratta un incidente specifico nel perimetro d’indagine confermato. Anche se lo stesso fornitore offre entrambi, un avviso del prodotto non commissiona automaticamente DFIR e non dà diritto a un’indagine illimitata.

Nel servizio MDR esistente sono determinanti contatti e modalità Threat Response, oltre al responsabile effettivo del caso e alle azioni richieste al cliente. Un caso customer-managed non viene automaticamente analizzato dal team MDR soltanto perché esiste una licenza Sophos. Le azioni cliente aperte richiedono un responsabile e non spariscono con un presunto cambio di servizio.

L’articolo Security Services Retainer spiega le Service Units e le condizioni DFIR particolari. Un saldo SU non costituisce un tempo di risposta generale né garantisce la chiusura dell’incidente entro un certo numero di ore. I diritti esistenti si verificano negli accordi specifici.

Readiness: esercitarsi prima dell’emergenza

Preparazione significa rendere utilizzabili responsabilità, accessi e percorsi decisionali prima di un incidente. Una Tabletop Exercise è una discussione guidata su uno scenario: il team esamina decisioni e passaggi senza lanciare un vero attacco nell’ambiente produttivo.

Si definiscono obiettivo e partecipanti, per esempio il coordinamento fra IT, direzione e comunicazione quando vengono compromesse identità amministrative. L’esercitazione dovrebbe chiarire chi dichiara l’incidente, chi autorizza il contenimento, come comunicare fuori dai sistemi potenzialmente colpiti e come decidere il ripristino. Il risultato sono osservazioni documentate e miglioramenti concreti con responsabili e scadenze.

Un piano di emergenza esistente non dimostra da solo che il ripristino funzioni o che i contatti siano raggiungibili. Avanet consiglia di ricontrollare catena dei contatti e delle approvazioni e un percorso di ripristino adeguato dopo modifiche rilevanti. Una discussione non sostituisce un test tecnico di restore pianificato separatamente.

Scegliere assessment e test di sicurezza

L’External Penetration Testing esamina l’accesso dall’esterno. I test interni possono verificare che cosa diventi possibile con un accesso di rete già disponibile. I test wireless valutano percorsi d’attacco Wi-Fi; i Web Application Assessment esaminano applicazioni e relativi problemi specifici. Il nome del servizio non garantisce l’inclusione di ogni sede, applicazione o interfaccia.

Un assessment non dimostra neppure la completa assenza di compromissioni. Un Compromise Assessment cerca indizi di intrusione nel perimetro concordato; un penetration test verifica percorsi d’attacco selezionati. Entrambi si distinguono dalle attività continuative di Managed Risk e dalla risposta a un incidente già attivo.

Prima di un test si documentano sistemi e esclusioni, autorizzazioni dei proprietari, metodi consentiti, finestre, accesso ai dati e criteri di arresto. Per sistemi cloud o di terzi occorre la relativa autorizzazione al test. Deve essere raggiungibile un contatto per interrompere le attività; disponibilità e impatti sulla produzione vanno considerati esplicitamente. Senza autorizzazione chiara, nessun test inizia.

Il risultato comprende rilievi comprensibili con sistemi interessati, evidenze, impatto e rimedi prioritari. Un nuovo test verifica i punti corretti concordati; il preventivo conferma se è incluso, quando e in quale misura. Un rapporto non certifica l’invulnerabilità futura. Realizzazione e accettazione dei miglioramenti restano attività distinte e visibili.

Per le modifiche pianificate dopo i rilievi, la distinzione tra TAM, supporto e Deployment Services aiuta a trasformare una raccomandazione in un incarico definito con passaggio tecnico, invece di trasferire rischi aperti fra fornitori.