Mettere in esercizio Sophos Central Endpoint in modo strutturato

L’implementazione di Sophos Central Endpoint implica molto più che l’esecuzione di un programma di installazione. Una distribuzione affidabile combina l’accesso dell’amministratore, le identità del dispositivo e dell’utente, l’ambito del software corretto, le policy, l’accesso alla rete, un progetto pilota rappresentativo e un monitoraggio e una risposta chiaramente gestiti.

Questo articolo fornisce un orientamento per il progetto complessivo. Segui i runbook collegati per l’installazione, la configurazione dei criteri e i dettagli sulla risoluzione dei problemi.

Il processo in breve

1. Definire ambito, proprietari e criteri di successo.
2. Proteggere l’accesso a Sophos Central e i ruoli di amministratore.
3. Verificare la licenza, l’Agent Mode e le piattaforme supportate.
4. Progettare identità, gruppi e modello delle policy.
5. Preparare i percorsi di rete e la distribuzione degli aggiornamenti.
6. Eseguire un pilota di Windows e macOS su dispositivi rappresentativi e un pilota Linux nel percorso separato Server Protection.
7. Convalidare protezione, comunicazione, eventi e rollback.
8. Solo allora espandersi in ondate controllate e passare alle operazioni.

Procedere solo quando la fase precedente ha un risultato documentato. Un programma di installazione completato non è un test di accettazione operativa.

Percorsi diretti per la messa in esercizio

Chi desidera soltanto installare può passare direttamente al percorso della piattaforma appropriata. Per un’implementazione completa, il punto di partenza sono i requisiti di sistema e i limiti del ciclo di vita e i requisiti di rete e proxy. Se nell’ambito rientra macOS, occorre considerare anche le autorizzazioni macOS. Per utenti e gruppi, Microsoft Entra ID può fungere da origine; Active Directory può fornire inoltre dispositivi e gruppi di dispositivi.

Proteggere l’accesso amministrativo prima del rollout

La protezione dell’accesso amministrativo parte da MFA, passkey e accesso federato. A seconda dell’Identity Provider, la federazione viene implementata con Microsoft Entra ID, OpenID Connect oppure Okta o AD FS. Per RBAC si limitano in base all’attività prima i ruoli amministrativi a livello di tenant, quindi i ruoli e le autorizzazioni specifici di Endpoint.

Installazione per piattaforma e metodo di distribuzione

Per un piccolo pilota o per singoli dispositivi, le guide manuali descrivono l’installazione su Windows e macOS. Il rollout automatizzato di Windows viene preparato nel runbook di distribuzione tramite riga di comando e software distribution; le macchine virtuali preconfigurate richiedono inoltre la procedura per le gold image VDI. Per i Mac, il percorso Jamf Pro e MDM descrive la distribuzione centralizzata, compresi i profili necessari.

Linux non è un’ulteriore variante dell’installer Endpoint per Windows/macOS. Sophos Central gestisce installazione, distribuzione tramite script e gold image come Sophos Protection for Linux o Server Protection; il processo specifico è descritto in Installare e distribuire Sophos Protection for Linux.

Configurare in modo mirato le funzioni di protezione

Una baseline non migliora attivando indiscriminatamente ogni opzione. Le impostazioni di Threat Protection illustrano, tra l’altro, la decrittografia HTTPS, le relative conseguenze sulla privacy e le esclusioni necessarie. Le esclusioni dalla scansione specifiche per prodotti o applicazioni vanno definite nel modo più circoscritto e comprensibile possibile. Il runbook sulle Scheduled Scans spiega se siano necessarie scansioni pianificate aggiuntive e come programmarle.

Per i controlli di utenti e dispositivi esistono percorsi decisionali e di configurazione distinti: Web Control per siti web e categorie, Application Control per le applicazioni, Peripheral Control per i dispositivi Windows e macOS collegati e Data Loss Prevention per le regole di controllo dei dati. Finestre di manutenzione, versioni software e infrastruttura di distribuzione vengono definite separatamente in Updates, Update Cache e Message Relay.

Estendere facoltativamente le integrazioni XDR e MDR

Con una licenza XDR o MDR adeguata, il tenant può riunire dati provenienti da altri prodotti Sophos e di terze parti. Il runbook valido per l’intero ambiente Central Configurare e verificare le integrazioni XDR tratta selezione, limiti di licenza, collegamento e verifica funzionale; non è una policy di protezione Endpoint.

Stato e report

Dopo il rollout, la Protection Overview con eventi e report consente di verificare la plausibilità dello stato di protezione e del flusso di eventi. L’Account Health Check integra questa vista mostrando le differenze rispetto alle raccomandazioni Sophos, ma non sostituisce né l’accettazione del pilota né i test funzionali. Destinatari ricorrenti, pianificazioni e recapiti non riusciti vengono configurati e monitorati tramite i report pianificati.

Se l’installazione o il funzionamento non riescono, Endpoint Self Help e SDU forniscono la diagnostica locale e i log necessari. È quindi possibile aprire un ticket di supporto Sophos con informazioni utili. L’accesso di un partner non va improvvisato: deve essere concesso e revocato tramite Partner Assistance e Remote Assistance a tempo.

1. Definire ambito e proprietà

Prima della prima installazione, documentare quali dispositivi e sistemi operativi rientrano nell’ambito, quali sono esclusi e chi approva le modifiche. Occorre assegnare responsabilità precise per tenant e ruoli, Endpoint e policy, rete e proxy, alert e incidenti, accettazione delle applicazioni e sostituzione in caso di decisioni critiche.

Definire anche criteri di accettazione misurabili: il dispositivo compare nel tenant e nel gruppo corretti, riceve l’Agent Mode e le policy previsti, segnala uno stato integro e produce gli eventi di test pianificati. Prima che si verifichi un errore, vanno stabiliti il rollback, il percorso di supporto e chi ha l’autorità di decidere.

2. Accesso sicuro per tenant e amministratore

Configurare MFA per tutti gli amministratori. Non utilizzare privilegi estesi per le attività quotidiane; assegnare i ruoli in base alle mansioni e riesaminarli regolarmente. Verificare le procedure di recupero e sostituzione, invece di improvvisare dopo la perdita di un dispositivo di autenticazione.

Consultare Accesso sicuro a Sophos Central con MFA e un IdP e Pianificazione di ruoli e autorizzazioni per Sophos Central Endpoint per decisioni dettagliate.

3. Determinare l’ambito del software e i limiti della piattaforma

Controllare insieme la licenza, il tipo di dispositivo, il sistema operativo e la modalità agente prevista. Ciò che appare in un tenant dipende dall’abbonamento e dalla piattaforma effettivi, quindi non dedurre la disponibilità da uno screenshot o da una pagina generale del prodotto.

Endpoint fornisce la protezione Sophos Endpoint, XDR aggiunge le funzioni previste di detection e response, mentre XDR Sensor non offre una protezione antimalware autonoma. Un deployment basato sul solo sensore richiede quindi un prodotto di protezione gestito separatamente. Gestire Agent Mode e software di Sophos Endpoint spiega selezione, modifica e controllo; Comprendere le licenze di Sophos Central Endpoint illustra i limiti commerciali e tecnici.

Utilizzare percorsi pilota separati per Windows e macOS. Prima di approvare una piattaforma, verificare i requisiti di sistema correnti e gli avvisi di ritiro consultando Pianificare i requisiti di sistema e il ciclo di vita di Sophos Endpoint.

I profili Linux Runtime Detection riguardano la protezione dei workload Linux e degli ambienti cloud-native. La scelta delle policy e il deployment dei sensori vanno pianificati come un percorso distinto, con i requisiti Sophos correnti, e non come un’aggiunta marginale a un rollout Endpoint per Windows o macOS.

Il ciclo di vita inizia in My Products > Global Settings > Protection and Remediation > Linux Profiles. Create Profile crea la versione 1; Profile Name, Content Version e l’eventuale Change Description ne documentano lo stato. Attivare quindi le regole necessarie nelle schede Detection Analytics, Smart Policy e BETA Ransomware. Assegnare prima ogni profilo nuovo o modificato a una Linux Runtime Detection Policy per server pilota e verificare un alert di test previsto. Create New Version conserva la cronologia. Duplicate clona l’ultima versione come profilo indipendente; modifiche e assegnazioni della copia non influiscono sul profilo di origine. Un profilo attivo può essere eliminato solo dopo averlo rimosso da tutte le policy.

Per la configurazione avanzata usare i filtri Category, Enabled, Modified e Configurable. Hide filters li nasconde soltanto; Clear All li rimuove. Le Allow/Block List valgono per la regola selezionata. Sophos Protection for Linux aggiorna automaticamente il contenuto SophosLabs, mentre Sophos Linux Sensor richiede un aggiornamento manuale. Il file YAML di Export Latest Version contiene solo le modifiche ai valori predefiniti e non un runtimedetections.yaml completo. Per Sophos Linux Sensor integrare solo tali modifiche nel file esistente e modificare esclusivamente campi e tipi di dati supportati dallo schema della versione del contenuto distribuita. Interrompere prima del pilota in caso di errori concreti: sintassi o rientro YAML non validi, chiavi sconosciute, tipi di dati errati, campi obbligatori mancanti o valori di regola non validi. Solo dopo il superamento della validazione del parser e dello schema, versionare il file, distribuirlo sui server pilota e controllare alert e stato runtime; in caso di problemi riassegnare la versione precedente o ripristinare la precedente configurazione validata del sensore.

4. Progettare identità, gruppi e politiche

I criteri utente seguono una persona, mentre i criteri computer seguono un dispositivo. Innanzitutto definire la fonte autorevole per utenti e gruppi e come verranno evitati duplicati o identità obsolete. Gestione utenti e gruppi di Sophos Central Endpoint spiega l’implementazione.

Un modello di dispositivo manutenibile inizia normalmente con alcuni gruppi chiari: dispositivi pilota supportati attivamente, dispositivi di produzione standard, dispositivi critici o tecnicamente diversi, eccezioni limitate nel tempo e dispositivi di test per nuove versioni del software.

Per ciascun tipo si applica la prima policy attiva corrispondente. Verificare quindi baseline, ordine e assegnazione effettiva prima del rollout di massa. L’eliminazione di una policy in Central è irreversibile: esportare o documentare impostazioni e assegnazioni e identificare prima i dispositivi interessati. Il modello completo è descritto in Configurare correttamente le policy di Sophos Central Endpoint.

Non attivare o disattivare i controlli indiscriminatamente. Valutare Threat Protection, Web, applicazioni, periferiche, DLP, DNS Protection, aggiornamenti, Tamper Protection, Data Collection e Response in base alla licenza, alla piattaforma e alle esigenze aziendali. Dove possibile e opportuno, introdurre i nuovi controlli in un piccolo gruppo pilota. Ogni eccezione richiede un motivo, un owner, un ambito limitato e una data di revisione.

5. Verificare rete e aggiornamenti prima dell’installazione

L’Endpoint deve raggiungere i servizi Sophos richiesti nel contesto del dispositivo e del servizio effettivamente utilizzato. Una richiesta del browser effettuata con successo da un amministratore non dimostra che l’installazione, la comunicazione dell’agente e gli aggiornamenti funzionino tramite un proxy, un’ispezione TLS o una rete segmentata.

Prima del pilota, verificare DNS, HTTPS, autenticazione proxy, validazione dei certificati e percorsi di fallback previsti. L’ordine di connessione corrente e le destinazioni Sophos dinamiche sono descritti in Requisiti di rete e proxy di Sophos Endpoint.

La banda per gli aggiornamenti, i Software Package, le fasi di manutenzione, Update Cache e Message Relay richiedono una decisione operativa distinta. L’impostazione globale della larghezza di banda non sostituisce né la pianificazione della capacità né un pilota. I dettagli e gli scenari di guasto sono descritti in Aggiornamenti, Update Cache e Message Relay di Sophos Endpoint.

6. Distribuire un pilota rappresentativo

Ottenere il programma di installazione destinato al tenant e allo scopo in My Environment > Installers. Trattare gli installatori come materiale di accesso e distribuirli solo attraverso canali controllati.

Mantenere separati i percorsi delle diverse piattaforme:

• Windows: Installare Sophos Central Intercept X
• macOS: Installa Sophos Central Endpoint
• implementazione automatizzata di Windows: Implementazione automatizzata di Sophos Endpoint su Windows

Il pilota non deve includere soltanto notebook IT privi di complessità. Deve rappresentare le versioni dei sistemi operativi, i segmenti di rete, l’home office o la VPN, le applicazioni business-critical e i software di sicurezza, backup, DLP e cifratura già presenti. Osservare prima le modifiche su pochi dispositivi; un intervallo tra le ondate non sostituisce l’accettazione tecnica.

7. Convalidare tecnicamente il pilota

Approvare un dispositivo pilota solo quando tutti i controlli pianificati sono stati superati:

1. L’agente locale segnala che è sano.
2. Il dispositivo viene visualizzato nel tenant corretto e nel gruppo pianificato.
3. La modalità agente e i componenti installati corrispondono al progetto approvato.
4. La pagina del dispositivo mostra le policy effettive previste.
5. Last Active, gli eventi e gli aggiornamenti avanzano in modo plausibile.
6. Un test di protezione approvato produce l’evento o l’avviso previsto.
7. Sono state testate le applicazioni aziendali, le modifiche alla rete e qualsiasi riavvio richiesto.
8. La consegna degli avvisi, il triage e l’escalation funzionano.
9. La disinstallazione o un altro rollback definito è stato verificato su un dispositivo di prova.

Test sicuro delle funzionalità di protezione di Sophos Endpoint copre i test sicuri. Se un dispositivo non è integro, non reinstallarlo alla cieca: utilizzare Gestione avvisi di Sophos Endpoint e integrità dell’account e Risoluzione sistematica degli errori di installazione di Sophos Endpoint.

L’Account Health Check è una visualizzazione di controllo aggiuntiva. Identifica deviazioni selezionate dalle raccomandazioni di Sophos, ma non dimostra la funzionalità dell’applicazione o la completa sicurezza del tenant. Le correzioni automatiche possono interessare molti dispositivi o policy e devono essere gestite come una modifica. Vedere Utilizzare correttamente Sophos Central Account Health Check.

8. Decidere deliberatamente la risposta e la prontezza forense

Prima del rollout esteso, stabilire chi gestisce gli alert, quando isolare un dispositivo e quali dati possono essere raccolti per indagini e supporto. I Forensic Snapshot acquisiscono dati sull’attività del dispositivo; archiviazione, esportazione, trasferimento facoltativo in un bucket S3 dell’organizzazione e accesso richiedono quindi una decisione consapevole in materia di sicurezza e privacy.

Creare, conservare e convertire i Forensic Snapshot

Creare uno snapshot da My Environment > Computers & Servers > dispositivo > Summary > More actions > Create forensic snapshot > Create now oppure con Create forensic snapshot in un Threat Graph. Gli snapshot manuali si trovano per impostazione predefinita in %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Forensic Snapshots\, quelli generati da una detection in %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Saved Data\. Con Tamper Protection attivo serve un prompt elevato. Il periodo predefinito è di due settimane; modificarlo o scegliere All log data in Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots. Definire prima spazio libero, accessi, conservazione e cancellazione sicura.

Per l’analisi, conservare una copia probatoria del .tgz. Su Windows a 64 bit scegliere l’exporter a 64 bit; solo Windows a 32 bit richiede l’altra versione. Prima del download verificare l’architettura in PowerShell con (Get-CimInstance Win32_OperatingSystem).OSArchitecture.

Solo a questo punto avviare l’acquisizione da Sophos tramite HTTPS: ottenere SDR Exporter a 64 bit oppure ottenere SDR Exporter a 32 bit. Compilare il modulo Sophos e accettare esclusivamente il file poi fornito da Sophos. Salvarlo in una nuova directory di lavoro scrivibile solo dagli investigatori responsabili; non usare allegati e-mail o mirror di terze parti. Prima dell’esecuzione verificare la firma Authenticode e calcolare un hash probatorio. L’hash identifica esattamente la versione acquisita, ma senza un valore di riferimento Sophos pubblicato separatamente non è una prova indipendente dell’origine:

$tool = '.\SDRExporterx64.exe'
$expectedSubject = $env:SDR_EXPORTER_EXPECTED_SUBJECT
$expectedThumbprint = $env:SDR_EXPORTER_EXPECTED_THUMBPRINT
if ([string]::IsNullOrWhiteSpace($expectedSubject) -or
    [string]::IsNullOrWhiteSpace($expectedThumbprint)) {
    throw 'Set the approved signer subject and thumbprint before validation.'
}
$expectedThumbprint = ($expectedThumbprint -replace '\s', '').ToUpperInvariant()
if ($expectedThumbprint -notmatch '\A[0-9A-F]+\z') {
    throw 'The approved signer thumbprint is not hexadecimal.'
}

$sig = Get-AuthenticodeSignature -FilePath $tool
if ($sig.Status -ne 'Valid' -or $null -eq $sig.SignerCertificate) {
    throw "SDR Exporter: Authenticode status is $($sig.Status)."
}
$actualThumbprint = ($sig.SignerCertificate.Thumbprint -replace '\s', '').ToUpperInvariant()
if (-not [string]::Equals($sig.SignerCertificate.Subject, $expectedSubject,
        [StringComparison]::Ordinal) -or
    -not [string]::Equals($actualThumbprint, $expectedThumbprint,
        [StringComparison]::Ordinal)) {
    throw 'SDR Exporter: signer does not exactly match the approved acquisition record.'
}

$chain = [Security.Cryptography.X509Certificates.X509Chain]::new()
$chainBuilt = $chain.Build($sig.SignerCertificate)
[pscustomobject]@{
    Status              = $sig.Status
    StatusMessage       = $sig.StatusMessage
    SignerSubject       = $sig.SignerCertificate.Subject
    SignerThumbprint    = $actualThumbprint
    SignerIssuer        = $sig.SignerCertificate.Issuer
    SignerNotBefore     = $sig.SignerCertificate.NotBefore
    SignerNotAfter      = $sig.SignerCertificate.NotAfter
    ChainBuilt          = $chainBuilt
    ChainStatus         = ($chain.ChainStatus.Status -join ', ')
    TimestampSubject    = $sig.TimeStamperCertificate.Subject
    TimestampThumbprint = $sig.TimeStamperCertificate.Thumbprint
}
$chain.ChainElements | ForEach-Object {
    [pscustomobject]@{
        ChainSubject    = $_.Certificate.Subject
        ChainThumbprint = $_.Certificate.Thumbprint
        ChainStatus     = ($_.ChainElementStatus.Status -join ', ')
    }
}
Get-FileHash -Algorithm SHA256 -Path $tool

Prima di eseguire il blocco, impostare SDR_EXPORTER_EXPECTED_SUBJECT e SDR_EXPORTER_EXPECTED_THUMBPRINT sui valori esatti contenuti in un registro di acquisizione approvato internamente e ottenuto tramite un processo attendibile separato; non copiarli mai dal file sottoposto a controllo. Lo stato Valid e la corrispondenza esatta di entrambi i valori sono criteri di approvazione. Conservare come prove i dettagli visualizzati della catena del firmatario e della marca temporale insieme all’output SHA-256. L’hash identifica il file acquisito ma, senza un valore di riferimento attendibile separato, non ne stabilisce la provenienza. Se manca un valore approvato, un controllo non riesce o l’hash cambia in seguito, non eseguire il file: eliminarlo e investigare oppure acquisirlo nuovamente dal link Sophos sopra indicato. Eseguire poi strumento e input solo dalla posizione protetta, in un prompt elevato e con percorsi di input e output distinti:

SDRExporterx64.exe -i <snapshot.tgz> -o <snapshot.sqlite> -f sqlite

Per JSON usare -f json e un nome di output adatto; l’eseguibile a 32 bit è SDRExporterx86.exe. Racchiudere tra virgolette i percorsi con spazi. Dopo una conclusione senza errori, verificare che l’output non sia vuoto e possa essere aperto e interrogato come SQLite o analizzato come JSON. Registrare nel log dell’incidente gli hash dell’input e dell’exporter, il comando, l’ora e il percorso di output; proteggere e conservare il file convertito come lo snapshot.

Se la conversione fallisce, non fare prove sull’originale. Controllare architettura e nome, firma, virgolette, permessi di lettura e scrittura, spazio libero e integrità della copia di lavoro .tgz, quindi usare un nuovo percorso di output. Un output parziale non è un risultato. L’exporter non installa nulla: il rollback consiste nell’arrestare il processo e rimuovere in sicurezza gli output incompleti e, al termine, l’exporter dalla directory di lavoro. Eliminare una copia di lavoro .tgz solo dopo aver verificato la conversione e secondo il processo di incidente. Conservare invariati l’originale probatorio e i log necessari fino al termine della retention.

Caricare facoltativamente nel proprio bucket S3

Il caricamento diretto richiede Windows e una licenza XDR o MDR. In AWS limitare una Managed Policy dedicata a s3:ListBucket su arn:aws:s3:::<bucketName> e s3:PutObject su arn:aws:s3:::<bucketName>/*. Attivare Upload forensic snapshot to an AWS S3 bucket in Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots. Usare AWS Account ID e AWS External ID mostrati nella Trust Policy di un ruolo IAM dedicato per sts:AssumeRole, quindi salvare S3 bucket name, la directory opzionale e Role ARN dopo la propagazione AWS.

Scegliere la regione AWS considerando residenza dei dati, latenza e costi di trasferimento e requisiti di disaster recovery. Prima di salvare in Central, attendere la propagazione del ruolo IAM in tutte le regioni AWS, che può richiedere fino a cinque minuti.

Una Bucket Policy e una IAM Permissions Boundary limitano l’accesso al ruolo e agli investigatori autorizzati. Una regola Lifecycle elimina upload multipart incompleti e dati scaduti. I bucket cifrati con KMS non sono supportati; AES-256 è supportato e richiesto da Sophos durante l’upload. Evitare caratteri speciali non supportati e consentire S3 nel firewall. Convalidare con uno snapshot pilota completo, leggibile e convertibile da un investigatore autorizzato, negando l’accesso non autorizzato. Rimuovere poi ruoli, policy e assegnazioni non più necessari.

Analizzare le detection e i Threat Graph di Sophos Endpoint descrive il resto del processo di Investigation.

Consentire o bloccare file nell’intero tenant

In Global Settings > Protection and Remediation > Allow and Block > Files, Allowed Applications mostra l’origine di un’autorizzazione. A seconda della piattaforma si può consentire per certificato, SHA-256 o percorso; certificati e percorsi possono includere più versioni. L’applicazione viene consentita a tutti gli utenti ed esclusa dalle ulteriori Threat Detection, mentre restano i controlli exploit, ransomware e comportamento malevolo. Prima di Allow verificare produttore, firma o hash, owner, motivo, ambito e scadenza. Remove revoca l’autorizzazione; controllare poi su un pilota che la detection torni a funzionare.

Blocked Items richiede XDR e blocca su Windows le applicazioni sospette tramite SHA-256, ma non file con reputazione trusted o altri oggetti. Selezionare Add, inserire SHA-256 e Reason, quindi Save. Le voci di file consentiti e bloccati condividono un unico limite tenant-wide di 5.000 voci; verificare la capacità combinata di entrambe le liste prima di aggiunte massive. Su un pilota controllare che l’applicazione non parta e che compaia l’evento previsto. Remove è il rollback e va anch’esso testato. Per altre esclusioni vedere Configurare in sicurezza le esclusioni di Sophos Central Endpoint.

9. Approvare le ondate e trasferirle alle operazioni

Per ogni ondata, definire i dispositivi inclusi, il responsabile del monitoraggio e i segnali di arresto. I segnali di arresto idonei includono errori di installazione in cluster, comunicazione assente con l’agente, assegnazioni di policy impreviste, errori delle applicazioni o un volume di avvisi che non può essere gestito.

Le attività ordinarie comprendono almeno:

• responsabilità quotidiana per gli alert critici e gli outbreak;
• verifica periodica dei dispositivi inattivi o non integri;
• revisione di licenze, Agent Mode e ciclo di vita delle piattaforme;
• piloti controllati per software e policy;
• controllo della scadenza delle eccezioni;
• verifica di proxy, Update Cache e Message Relay;
• percorsi documentati per Response, privacy e supporto.

Un’onda è completa solo quando i suoi dispositivi non sono semplicemente installati, ma tecnicamente accettati e incorporati in questi processi operativi.

Domande frequenti