3 modi per adottare la mentalità “Assume Breach’’

“Assume Breach” significa progettare la sicurezza partendo da un’ipotesi scomoda ma utile: un’identità, un endpoint, una sessione, un’applicazione o una porzione della rete potrebbero essere già compromessi. Non è pessimismo operativo e non significa rinunciare alla prevenzione. Significa eliminare la fiducia implicita e costruire controlli capaci di limitare il danno, rilevare rapidamente l’attività anomala e ripristinare i servizi anche quando una barriera preventiva fallisce.

Nel modello Zero Trust Microsoft, Assume Breach è uno dei tre principi fondamentali insieme a Verify Explicitly e Use Least Privilege Access. L’obiettivo non è rendere ogni sistema “sospetto” in modo indiscriminato, ma evitare che una singola compromissione possa propagarsi liberamente nell’organizzazione.

NIST esprime lo stesso cambio di paradigma nella Zero Trust Architecture: nessun utente o asset riceve fiducia implicita solo perché si trova nella rete aziendale o perché è di proprietà dell’organizzazione. Autenticazione, autorizzazione, postura del dispositivo e contesto devono essere valutati rispetto alla risorsa richiesta.

Assume Breach non significa “dare per certo che saremo violati”

La formulazione può essere fraintesa. Assume Breach non afferma che ogni organizzazione subirà inevitabilmente un data breach. È un principio di progettazione: i controlli non devono dipendere dall’ipotesi che tutto ciò che si trova “dentro” sia affidabile.

Il modello perimetrale tradizionale tendeva a concentrare molte difese sul confine della rete. Cloud, SaaS, lavoro ibrido, identità federate, dispositivi mobili e supply chain hanno reso quel confine molto meno significativo. Un token rubato, un account compromesso o un endpoint già autenticato possono consentire all’attaccante di operare senza attraversare il firewall nel modo classico.

Assume Breach sposta quindi la domanda da “come impediamo qualsiasi ingresso?” a “se un controllo fallisce, quanto può muoversi l’attaccante, quanto velocemente lo vediamo e quanto velocemente possiamo contenerlo e recuperare?”.

1. Limitare il blast radius: segmentare accessi, identità e privilegi

Il primo effetto pratico di Assume Breach è ridurre l’ampiezza del danno possibile. Se un account standard viene compromesso, non dovrebbe poter diventare amministratore del dominio, accedere ai backup, modificare le policy di sicurezza e raggiungere indistintamente tutti i server.

Questo richiede controlli che impediscano all’attaccante di trasformare un singolo accesso in una compromissione estesa:

• Least Privilege: ogni identità riceve solo i permessi necessari, per il tempo necessario e sulla risorsa necessaria.
• Separazione degli account amministrativi: l’account usato per email e navigazione non deve coincidere con quello privilegiato.
• Privileged Access e Just-in-Time: i privilegi elevati non devono essere permanenti quando possono essere attivati solo su richiesta.
• Segmentazione di rete e applicativa: workstation, server, sistemi OT, backup e servizi critici non devono convivere in una rete piatta.
• Segmentazione delle identità: proteggere Tier 0/asset critici e impedire che credenziali privilegiate vengano usate su sistemi meno affidabili.
• Conditional Access e device posture negli ambienti cloud: l’accesso va valutato in base a identità, dispositivo, rischio e contesto, non solo alla password.

La misura corretta non è “quanti controlli abbiamo?”, ma “quanto lontano può arrivare un attaccante dopo aver compromesso un singolo asset?”. Il blast radius è una metrica architetturale: più sono separati privilegi, identità e zone di sicurezza, minore è il danno potenziale di una singola violazione.

Approfondimento Nexsys: Active Directory Security Assessment & Hardening per analizzare privilegi, attack path, deleghe e possibilità di escalation nell’ambiente identità.

2. Rilevare e contenere: progettare sapendo che la prevenzione può fallire

Un’organizzazione che applica Assume Breach non considera il blocco dell’attacco come unico criterio di successo. Deve essere in grado di osservare ciò che accade dopo un’eventuale compromissione: autenticazioni anomale, escalation di privilegi, movimento laterale, esecuzioni sospette, modifiche alle policy, attività sui dati e tentativi di disabilitare i controlli.

Per questo la telemetria deve attraversare più domini: identità, endpoint, rete, cloud, email e applicazioni. Un singolo alert isolato spesso è ambiguo; la correlazione tra più segnali consente invece di ricostruire una catena di attacco.

• EDR/XDR sugli endpoint per osservare processi, persistenza, credential theft e lateral movement.
• Telemetria identity per individuare autenticazioni anomale, privilegi elevati e abuso di account.
• SIEM e correlazione centralizzata per unire eventi provenienti da fonti differenti.
• Threat intelligence e detection engineering per aggiornare le regole sulla base delle tecniche realmente osservate.
• Playbook di contenimento: isolamento endpoint, blocco identità, revoca sessioni/token, blocco indicatori e escalation verso il team IR.
• Tabletop exercise e simulazioni tecniche per verificare che alert, contatti e procedure funzionino prima dell’incidente reale.

In questo modello il tempo di rilevamento e di contenimento diventa una misura di resilienza. Non basta chiedersi se EDR, SIEM o XDR siano installati: serve verificare se producono segnali utili, se gli alert vengono presi in carico e se esiste un percorso operativo per passare dalla detection alla risposta.

Approfondimenti Nexsys: Endpoint Protection EDR/XDR per la telemetria endpoint e SOC as a Service per monitoraggio, correlazione e risposta continuativa.

3. Preparare il recovery: progettare per tornare operativi dopo una compromissione

Il terzo pilastro è spesso trascurato: Assume Breach riguarda anche la capacità di recupero. Se l’attaccante riesce a cifrare server, cancellare dati, compromettere account privilegiati o manipolare configurazioni, l’organizzazione deve poter ricostruire un ambiente affidabile senza dipendere dai sistemi compromessi.

Backup esistenti ma non isolati, account di backup appartenenti allo stesso dominio, restore mai testati e runbook non aggiornati non sono una strategia di recovery. Una postura coerente con Assume Breach prevede invece:

• backup protetti da credenziali e domini amministrativi separati rispetto ai workload protetti;
• immutabilità o meccanismi equivalenti che rendano difficile la cancellazione da parte di un amministratore compromesso;
• copie offline/air-gapped o architetture che riducano la dipendenza dal dominio di produzione;
• restore test periodici e verifica dell’integrità dei dati ripristinati;
• ordine di ricostruzione definito: identità e servizi fondamentali prima dei workload applicativi;
• runbook di cyber recovery con ruoli, dipendenze, escalation e criteri di rientro in produzione.

Il recovery non è la fase “dopo la sicurezza”: è parte della sicurezza. Se un attacco distruttivo può eliminare contemporaneamente produzione e copie di ripristino, il blast radius include anche la capacità dell’azienda di tornare operativa.

Approfondimenti Nexsys: Incident Response per preparazione e gestione dell’incidente e Ransomware Recovery per gli scenari di ripristino post-attacco.

Assume Breach applicato a identità, endpoint, rete e dati

Come capire se l’azienda sta davvero applicando Assume Breach

Una verifica utile parte da scenari concreti, non dal numero di prodotti acquistati. Per esempio:

• Se un utente Microsoft 365 subisce session hijacking, quali dati può raggiungere prima che la sessione venga revocata?
• Se una workstation IT viene compromessa, può essere usata per amministrare Domain Controller o hypervisor?
• Se un Domain Admin viene compromesso, l’attaccante può cancellare anche i backup?
• Se un endpoint genera un alert di credential dumping, chi lo vede, entro quanto tempo e quale azione viene eseguita?
• Se l’identità cloud viene compromessa, esistono separazione e controlli sufficienti per impedire il passaggio verso l’on-premises?
• Se un ransomware cifra i server principali, l’ordine di recovery è documentato e testato?

Se le risposte dipendono da una singola persona, da controlli manuali non documentati o dal presupposto che “questo account non verrà mai compromesso”, l’architettura non sta ancora applicando realmente Assume Breach.

Assume Breach, Zero Trust e Incident Response: concetti collegati ma diversi

Zero Trust è la strategia complessiva. Assume Breach è uno dei suoi principi guida. Incident Response è invece il processo che si attiva quando un evento o incidente richiede analisi, contenimento, eradication e recovery. Confondere i tre concetti porta a pagine e progetti troppo generici.

Assume Breach influenza l’architettura prima dell’incidente: riduce privilegi e trust implicito, migliora visibilità, segmenta le risorse e prepara il recovery. Incident Response usa poi queste capacità quando serve reagire a un evento reale.