External attack surface management — il playbook di onboarding in 90 giorni

L'external attack surface management (EASM) è la discovery e il monitoraggio continui degli asset che un attaccante può raggiungere dalla rete pubblica — domini, sottodomini, interfacce di management esposte, API, storage cloud, micrositi di marketing dimenticati e le proprietà che una controllata appena acquisita si è portata dietro. È la vista outside-in: ciò che un attaccante non autenticato vede prima di avere qualsiasi foothold.

I board finanziano l'EASM in modo reattivo. Il trigger è quasi sempre un competitor bucato tramite un'appliance esposta su internet — le due RCE zero-day su NetScaler ADC/Gateway CVE-2026-88771 e CVE-2026-88772, aggiunte al catalogo Known Exploited Vulnerabilities di CISA il 27 settembre 2026, ne sono l'esempio da manuale: remote code execution non autenticata che colpisce le configurazioni di default, sfruttata prima che esistesse una patch. Ogni organizzazione che ne aveva una si è posta la stessa domanda — 'ne abbiamo una esposta, e dove'.

In scope: tutto ciò che è raggiungibile da internet e porta l'identità o i dati della tua organizzazione. Fuori scope: il vulnerability management interno (è un programma separato di scanning autenticato) e l'intero loop di esposizione interno (è il CTEM, che l'EASM alimenta ma non sostituisce). Tieni il confine di scope esplicito — un programma EASM che si allarga silenziosamente allo scanning interno si blocca e non produce nessuno dei due.

Un programma EASM fallisce in tre punti prevedibili, e il piano di 90 giorni qui sotto è organizzato per fare bene ciascuno:

• Discovery — la mappa manca asset che nessuno ricorda di possedere. Shadow IT, workload cloud effimeri, sottodomini scaduti ma ancora risolti e proprietà ospitate da terze parti sono esattamente da dove arriva la breccia, ed esattamente ciò che un CMDB classico non elenca.
• Attribuzione di ownership — la discovery produce una lista, ma nessun owner responsabile, quindi niente viene sistemato. Un finding senza un nome attaccato invecchia in un report trimestrale e non si chiude mai.
• Triage e SLA di remediation — le esposizioni vengono ordinate per CVSS grezzo invece che per sfruttabilità reale, così il team brucia il budget di remediation su finding ad alto CVSS irraggiungibili mentre un'esposizione davvero sfruttabile resta aperta.

Sbaglia questi tre e hai comprato una dashboard. Falli bene e hai un programma che il board e il tuo regolatore sanno leggere.

Obiettivo: un seed set completo e un primo exposure ledger entro il giorno 30.

La discovery vale quanto i suoi seed. Parti da ciò che puoi affermare di possedere, poi lascia che la discovery si espanda verso l'esterno:

• Assembla il seed set: domini e brand registrati, range IP e ASN di proprietà, ID di account e organizzazione dei provider cloud, tenant SaaS noti e — cosa critica — i domini e lo spazio IP di ogni controllata acquisita negli ultimi cinque anni. La guida all'acquisto EASM dell'NCSC britannico è un buon riferimento neutrale su cosa deve coprire una capability di discovery.
• Esegui discovery continua, non uno scan una tantum: enumera i sottodomini, risolvi il DNS, fai fingerprinting di servizi e tecnologie, e recupera i log di certificate transparency per intercettare host che non sono mai comparsi nel tuo DNS. Configurala per rieseguirsi a cadenza fissa — giornaliera per i cambi DNS e certificati, settimanale per la ri-enumerazione completa.
• Produci il primo exposure ledger: ogni asset esposto su internet, i suoi servizi aperti, tecnologie e versioni rilevate, e se espone un'interfaccia di management o login non autenticata. Aspettati sorprese — le prime baseline scoprono di routine il 20-40% di asset esposti in più di quanti ne elencasse l'inventory.

Checklist per la Fase A:

• Seed set approvato da IT, cloud e ogni business unit.
• Discovery attiva a cadenza schedulata, non lanciata a mano.
• Primo exposure ledger prodotto, con provenienza di discovery registrata per ogni asset (quale seed e quale tecnica l'ha trovato).
• Ogni asset che espone un'interfaccia admin non autenticata segnalato per review immediata, prima della fase di triage completa.

Obiettivo: ogni asset del ledger ha un owner responsabile e con nome entro il giorno 60.

È la fase che la maggior parte dei programmi salta, ed è quella che decide se il programma produce azione o rumore.

• Attribuisci un owner a ogni asset: mappa ciascun asset a una business unit e a una persona responsabile con nome e cognome. Automatizza ciò che puoi — WHOIS, tag degli account cloud, campo organization dei certificati TLS, join con il CMDB interno — ma metti a budget l'attribuzione manuale della coda lunga.
• Risolvi gli orphan deliberatamente: alcuni asset risolvono al tuo brand ma non mappano ad alcun owner noto — il microsito di un contractor, un account cloud shadow, la proprietà dimenticata di una controllata. Ogni orphan è una decisione, non un mistero da lasciare aperto: rivendicalo (assegna un owner) o dismettilo (mettilo offline). 'Non è di nessuno' non è uno stato finale accettabile — gli asset esposti su internet senza owner sono il punto d'ingresso di breccia più comune in assoluto.
• Assegna i tier per blast radius: un'interfaccia raggiungibile da internet e non autenticata davanti a dati sensibili o a un management plane è tier 1; una pagina di marketing statica è tier 3. Il tier guida la SLA di remediation nella Fase C.

Checklist per la Fase B:

• 100% degli asset del ledger attribuiti a una business unit e a un owner con nome, o esplicitamente messi in coda di dismissione.
• Registro degli orphan prodotto, ogni voce con una decisione rivendica-o-dismetti e una data.
• Tier degli asset assegnati, rivisti con il business e registrati nel ledger.
• Azioni di dismissione per gli asset non rivendicati tracciate fino alla chiusura.

Obiettivo: un modello di triage basato sulla sfruttabilità e SLA di remediation applicate entro il giorno 90.

L'errore di prioritizzazione che spreca più budget è ordinare per CVSS grezzo. Ordina invece per sfruttabilità nel tuo ambiente:

• Raggiungibilità da internet — il servizio vulnerabile è davvero raggiungibile non autenticato dalla rete pubblica? L'EASM te l'ha già detto.
• Sfruttamento noto — la CVE è nel catalogo KEV di CISA? Una RCE non autenticata in KEV su un asset esposto batte un CVSS 9.8 dietro MFA e segmentazione.
• Probabilità di sfruttamento — usa lo score EPSS di FIRST per separare le CVE che verranno probabilmente sfruttate nei prossimi 30 giorni dalla coda lunga che non lo sarà mai.

Definisci le SLA di remediation per tier e falle rispettare:

• Tier 1 (raggiungibile da internet, non autenticato, sensibile): in KEV → finestra d'emergenza, mitiga o isola entro 24-48h anche prima di una patch (vedi il playbook della finestra di patch d'emergenza guidata da KEV); critico non-KEV → 7 giorni.
• Tier 2: 30 giorni.
• Tier 3: 90 giorni o risk acceptance documentata.

Vincola la chiusura al retest. Un ticket segnato 'risolto' è un'ipotesi finché l'esposizione non viene ri-verificata dall'esterno e confermata sparita. 'Trovato' non è 'risolto'. Tutto ciò che resta aperto oltre la SLA richiede una risk acceptance documentata e firmata dall'owner — non silenzio.

Checklist per la Fase C:

• Modello di triage per sfruttabilità (raggiungibilità + KEV + EPSS) applicato all'intero ledger.
• SLA definite per tier e cablate nel sistema di ticketing con date di scadenza.
• Retest gating attivo — nessuna esposizione si chiude senza una ri-verifica esterna.
• Primo readout al board consegnato: conteggio esposizioni per tier, tempo medio di remediation e registro dei rischi accettati.

Tieni questi artefatti sempre pronti, firmati e con timestamp — sono ciò che un auditor, un assicuratore o un regolatore chiede, e ciò che ti serve quando un asset scoperto risulta già compromesso:

• Inventory degli asset con provenienza di discovery — ogni asset esposto su internet, e come è stato trovato (quale seed, quale tecnica, quale data).
• Registro di ownership — asset verso business unit verso owner con nome, con le decisioni rivendica-o-dismetti degli orphan.
• Exposure ledger — per ogni asset: servizi, versioni, CVE, flag KEV, score EPSS, tier e stato corrente.
• Log di remediation e retest — azione intrapresa, data, approvatore e il risultato della ri-verifica esterna che ha chiuso ogni voce.
• Registro delle risk acceptance — ogni esposizione lasciata aperta oltre la SLA, con la firma dell'owner e la giustificazione di business.

Il gap ricorrente che questa lista mette in luce è che uno scanner produce una lista di finding, non evidenza di ciò che è sfruttabile. Lo step che converte l'una nell'altra è la validazione: dimostrare, dall'esterno, che un'esposizione scoperta può davvero essere raggiunta e sfruttata, mappata alla tecnica MITRE ATT&CK per la notifica al regolatore. L'AI red team autonomo di Zero Hunt riesegue quella validazione in continuo e a ogni cambiamento della superficie — ogni nuovo asset esposto su internet viene testato adversarially, e ogni esposizione confermata si chiude con un artefatto di proof-of-exploit firmato, così il ledger registra ciò che un attaccante può davvero fare invece di ciò che un banner di versione lascia intendere.

1. Lo scan puntuale. Una superficie mappata una volta diventa obsoleta in poche settimane — un nuovo sottodominio, una porta riaperta, un bucket cloud appena creato. Se la discovery non è continua, la mappa descrive una rete che non esiste più. È il fallimento che le zero-day NetScaler hanno punito: l'appliance esposta era spesso una che nessuno ri-verificava da quando era stata messa su.

2. Discovery senza ownership. Il modo più comune di sprecare un investimento EASM è produrre una bella lista di asset di cui nessun owner è responsabile. I finding senza un nome attaccato non si chiudono mai.

3. Prioritizzazione solo per CVSS. Ordinare puramente per CVSS brucia il budget di remediation su finding ad alta severità irraggiungibili mentre un'esposizione in KEV e raggiungibile da internet resta aperta. Raggiungibilità e sfruttamento noto battono la severità grezza ogni volta. La metodologia di testing tecnico SP 800-115 del NIST è il riferimento neutrale per costruire lo step di validazione che produce questo ordinamento.

4. Dimenticare di aggiornare i seed. I seed non sono set-and-forget. Salta un'acquisizione e la piattaforma fa sparire silenziosamente l'intera presenza internet di una controllata dalla mappa. Aggiorna il seed set dopo ogni evento di M&A e ogni lancio di prodotto importante.

5. Trattare l'EASM come un inventario completo — o 'trovato' come 'risolto'. L'EASM è la vista esterna outside-in; non è il tuo inventario completo degli asset e non conferma la remediation. Abbinalo a un programma interno autenticato, alimenta con esso il tuo loop CTEM, e vincola ogni chiusura a un retest esterno.

L'EASM è il layer di discovery e monitoraggio. Tre programmi adiacenti consumano il suo output, e tracciare i confini previene sia il lavoro duplicato sia gli handoff mancati:

• CTEM — il loop di continuous threat exposure management prende il ledger esterno come uno degli input, accanto alle esposizioni interne, e guida il ciclo scope-discover-prioritize-validate-mobilize. L'EASM è il front end di discovery esterna; il CTEM è l'intero loop.
• Patching d'emergenza — quando un asset esposto scoperto finisce in KEV, la risposta passa alla finestra di patch d'emergenza guidata da KEV time-boxed, decisa da esposizione e sfruttamento noto invece che da un calendario fisso.
• Incident response su edge device — se la discovery rivela un'appliance esposta già compromessa, non sei più in exposure management ma in incident response; passa il testimone al playbook di compromissione degli edge device e preserva l'evidenza volatile prima di toccare la macchina.

Per l'inquadramento regolatorio — perché il testing continuo e produttore di evidenza è sempre più ciò che NIS2 e DORA si aspettano — vedi NIS2 + DORA e pentest continuo.