La finestra di patch d'emergenza guidata da KEV — playbook decisionale CISO per BOD 26-04

Usa questo playbook nel momento in cui una qualsiasi di queste è vera per un prodotto nel tuo estate:

• Una CVE che affligge software o un'appliance che usi viene aggiunta al catalogo CISA Known Exploited Vulnerabilities (KEV). Nel solo giugno 2026 CISA ha aggiunto 23 voci, sei delle quali zero-day — esempi recenti includono CVE-2026-20245 (Cisco Catalyst SD-WAN Manager), CVE-2026-20230 (SSRF Cisco Unified Communications Manager) e tre falle Ubiquiti UniFi OS.
• Un advisory vendor o un report di ricercatore credibile dice che una CVE nel tuo stack è sfruttata in the wild, anche prima che CISA la elenchi.
• Il tuo scanning o un feed di threat-intel mostra una vulnerabilità attivamente sfruttata presente su un asset che possiedi.

Il playbook risponde a due domande in ordine: su quale clock sono, e patcho, mitigo o isolo. Assume che la vulnerabilità sia reale e presente; confermare la presenza è un prerequisito, non parte di questo playbook.

Fuori scope: un ciclo di patch mensile di routine senza evidenza di sfruttamento (è patch management), una CVE che lo scanning prova non essere presente nel tuo ambiente (chiudila e vai avanti), o una breach conclamata dove lo sfruttamento della *tua* istanza è già confermato — a quel punto sei in incident response, non in patch d'emergenza, e i clock di notifica al regolatore (NIS2 24h, DORA 4h) dominano.

Per quattro anni il benchmark è stato semplice: la BOD 22-01 dava alle agenzie federali 14 giorni per rimediare qualunque CVE KEV-listed (e sei mesi per smaltire il backlog iniziale). CISO, assicuratori e auditor del privato hanno adottato quel numero di 14 giorni come standard di tempo ragionevole, benché la direttiva vincolasse solo le agenzie civili federali USA.

Questo è cambiato il 10 giugno 2026. CISA ha emesso la BOD 26-04, "Prioritizing Security Updates Based on Risk", che revoca e sostituisce la BOD 22-01 (e la BOD 19-02). Abbandona la deadline KEV fissa e la prioritizzazione guidata da CVSS in favore di un tier risk-based deciso da una combinazione di quattro segnali binari:

• Esposizione pubblica — l'asset è raggiungibile su una rete pubblica da un utente non autenticato? *Trattalo come esposto di default, salvo che tu possa provare il contrario.*
• Stato KEV — la CVE è nel catalogo CISA KEV?
• Automazione dell'exploit — un avversario può automatizzare completamente lo sfruttamento (weaponizzato, affidabile, senza passo manuale)? EPSS e la disponibilità di exploit pubblici informano questo.
• Impatto tecnico — lo sfruttamento concede controllo totale del sistema o solo parziale?

La combinazione decide la fascia, non un conteggio dei segnali. I tier:

• 3 giorni di calendario + triage forense obbligatorio — la CVE è KEV-listed e produce controllo totale del sistema, indipendentemente da esposizione o automazione.
• 3 giorni di calendario (senza triage forense) — un asset esposto pubblicamente con un exploit automatizzabile che produce controllo totale, anche se non ancora KEV-listed.
• 14 giorni — la fascia standard per la maggior parte delle vulnerabilità KEV-listed e diverse combinazioni non-KEV ad alto rischio.
• 60 giorni — casi a rischio più basso, es. un asset non esposto con una falla automatizzabile ma solo a controllo parziale.
• Fix al prossimo upgrade di sistema pianificato — nessun criterio di rischio soddisfatto.

Due regole governano il clock. Parte quando CISA aggiunge la CVE al KEV *o* quando scopri la vulnerabilità sui tuoi sistemi — quale dei due avviene prima. Ed è dinamico: mettere un asset offline rimuove il segnale di esposizione e può spostarlo a una fascia più lenta, mentre un listing KEV lo stringe. Le agenzie devono allineare i processi entro i 60 giorni (agosto 2026) e raggiungere la piena conformità entro 180 giorni (dicembre 2026) — la finestra in cui questo diventa il benchmark su cui tutti gli altri sono giudicati.

Obiettivo: entro il primo giorno, stabilire i quattro segnali e assegnare la fascia corretta. Assegna un owner — è una decisione, non uno scan.

Checklist di triage:

• Conferma che la CVE si applichi a una versione che usi davvero. Confronta il range di versioni affette dell'advisory contro il tuo inventario asset / SBOM. Una voce KEV per una famiglia di prodotti che non deployi non è il tuo clock.
• Determina l'esposizione. Il servizio vulnerabile è raggiungibile da una rete non fidata da un utente non autenticato? Se non puoi rispondere con evidenza — dati di attack-surface esterna, regole firewall, un test di raggiungibilità — default a esposto. È la regola BOD 26-04 e l'assunzione sicura.
• Determina l'automazione dell'exploit. Esiste un exploit pubblico weaponizzato e affidabile? È KEV-listed (l'uso in-the-wild è confermato per definizione)? Controlla la probabilità EPSS e la disponibilità di PoC pubblici. Un listing KEV più un PoC funzionante significa assumere automatizzabile.
• Determina l'impatto tecnico. Lo sfruttamento riuscito dà controllo totale (RCE come root/SYSTEM, bypass completo dell'autenticazione, takeover admin) o parziale (info disclosure, privilegio limitato, DoS)?
• Assegna la fascia dalla lista dei tier e scrivi *perché* — i valori dei quattro segnali e la deadline risultante. Quella giustificazione in una riga è la tua audit trail e ciò che un assicuratore o regolatore chiederà.

Esempio pratico: una RCE pre-autenticazione KEV-listed sul tuo gateway internet-facing → KEV = sì, esposizione = sì, automazione = sì, impatto = totale. Fascia: 3 giorni con triage forense (KEV + controllo totale), e poiché è esposto e sfruttato apri anche un binario di incident response in parallelo. Contrasta una CVE di info-disclosure parziale su un host solo-interno senza PoC pubblico → probabilmente la fascia 60 giorni o prossimo upgrade. Stessa settimana, stesso feed KEV, due clock molto diversi.

Una volta fissata la fascia, hai tre mosse. Scegli per asset, non per CVE — la stessa vulnerabilità su un gateway esposto e su un host air-gapped sono decisioni diverse.

1. Patch — la scelta di default quando esiste una fix vendor e puoi deployarla *e validarla* entro la fascia. Deploya prima sulle istanze a rischio più alto (esposte, controllo totale), poi scendi. Una patch non è remediation finché non confermi che il percorso vulnerabile è effettivamente chiuso — alcune fix richiedono una modifica di configurazione o un restart del servizio che la stringa di versione non riflette.

2. Mitigazione (controlli compensativi) — quando non esiste patch, la patch non può essere validata in tempo, o patchare romperebbe un servizio critico. Opzioni, in ordine approssimativo di forza: disabilita la feature o l'endpoint vulnerabile, applica il workaround fornito dal vendor, aggiungi una signature WAF/IPS per l'exploit, restringi la raggiungibilità di rete al servizio vulnerabile, o irrobustisci l'autenticazione davanti a esso. Documenta la mitigazione come temporanea con una data target di patch — un controllo compensativo è un allunga-clock, non una chiusura.

3. Isola / metti offline — quando non puoi né patchare né mitigare adeguatamente un asset esposto ad alto impatto. Rimuovere la raggiungibilità pubblica rimuove direttamente il segnale di esposizione, che sotto BOD 26-04 può spostare l'asset a una fascia più lenta e comprare il tempo per patchare in sicurezza. Non è una mossa di sconfitta; è la mossa corretta quando l'alternativa è far girare una falla nota-sfruttata, internet-facing, a controllo totale. Per un asset di cui puoi permetterti di perdere l'accesso temporaneamente, l'isolamento è spesso più veloce e sicuro di una patch di produzione affrettata.

L'anti-pattern che questo sostituisce: patchare in ordine di punteggio CVSS. Un CVSS 9.8 su un host interno non esposto e a impatto parziale può aspettare; un CVSS 7.2 che è KEV-listed, esposto e produce controllo totale è un fire di 3 giorni. La BOD 26-04 esiste proprio perché il punteggio base CVSS è un cattivo proxy del rischio reale.

Una fascia di 3 giorni si scontra con processi di change management costruiti per cicli di due settimane. Pre-costruisci il percorso d'emergenza così che il clock non sia consumato dal processo:

• Corsia di change d'emergenza pre-autorizzata. Concorda in anticipo — con il change board e i service owner — che una finding KEV-listed, esposta, a controllo totale qualifichi automaticamente per change d'emergenza, senza attendere il board settimanale. Cattura la traccia di approvazione; non saltarla.
• Piano di rollback prima. Prima di deployare, conosci il rollback esatto: snapshot/restore point, versione precedente del pacchetto, backup di configurazione. Il fallimento della patch d'emergenza più probabile che ti faccia male è una patch difettosa che butta giù proprio il servizio che stavi proteggendo.
• Canary, poi fan out. Deploya su un'istanza rappresentativa, conferma che il servizio sia sano e il percorso vulnerabile sia chiuso, poi propaga al resto. Anche in una finestra di 3 giorni c'è tempo per un canary di un'ora.
• Valida la chiusura, non solo il deploy. Ri-testa la primitiva di exploit specifica contro l'istanza patchata, o conferma che la modifica di configurazione abbia avuto effetto. "La patch è installata" e "l'exploit non funziona più" sono affermazioni diverse; il regolatore e il tuo assicuratore tengono alla seconda.
• Registra la timeline. Clock-start (data KEV o scoperta), fascia assegnata, decisione (patch/mitigazione/isolamento), tempo di deploy, esito di validazione. È l'evidenza che un auditor allineato a BOD, un cyber-assicuratore, o un supervisore NIS2/DORA chiederà di vedere.

Tieni pronti questi, ordinati per quale gate li consuma — il punto è provare, a un auditor o assicuratore, di aver eseguito un processo risk-based difendibile invece di patchare a istinto:

• Trigger record — CVE ID, data di listing KEV (o la tua data di scoperta), l'advisory/report di ricercatore che ha stabilito lo sfruttamento in-the-wild, e il timestamp in cui ne sei venuto a conoscenza. Fissa il clock-start.
• Evidenza di applicabilità — la query di inventario asset / SBOM che prova che la versione vulnerabile è (o non è) presente, e dove.
• Il worksheet dei quattro segnali — esposizione, stato KEV, automazione, impatto, ciascuno con l'evidenza dietro, e la fascia risultante con la sua deadline. L'artefatto singolo più importante.
• Decision record — patch / mitigazione / isolamento, per asset, con motivazione.
• Change + rollback record — approvazione della change d'emergenza, timestamp di deploy, esito canary, piano di rollback.
• Validazione di chiusura — prova che il percorso vulnerabile è effettivamente chiuso (esito del ri-test o conferma di configurazione), non solo che un pacchetto si è installato.
• Registro del rischio residuo — ogni asset lasciato su un controllo compensativo, con la sua data target di patch.

Il collo di bottiglia ricorrente che le organizzazioni peer riportano non è deployare la patch — è **decidere in modo difendibile quale delle voci KEV della settimana è davvero un fire di 3 giorni nel *loro* ambiente**, perché i quattro segnali (in particolare esposizione reale e sfruttabilità reale) sono costosi da stabilire a mano sotto deadline. Validare in continuo se una CVE KEV-listed è genuinamente raggiungibile e sfruttabile contro la tua configurazione deployata — prima che arrivi, non durante il fire drill — è esattamente ciò per cui è costruito il pilastro AI Generative Pentest di Zero Hunt: uno swarm di 10 agenti scrive una catena di exploit per-target, backtestata nell'AI Gym prima di girare, così "esposto" e "sfruttabile" diventano fatti provati sul *tuo* estate invece di assunzioni worst-case. Sincronizza il catalogo CISA KEV ed EPSS come due dei suoi feed di threat-intel, così un nuovo listing KEV per un prodotto che usi innesca automaticamente una campagna di validazione — trasformando il worksheet dei quattro segnali da corsa manuale a risposta permanente.

1. Prioritizzare per CVSS invece che per rischio. L'abitudine esatta che la BOD 26-04 abolisce. Un CVSS 9.8 su un host non esposto a impatto parziale non è un fire di 3 giorni; un CVSS 7.x KEV-listed, esposto, a controllo totale lo è. Classifica per i quattro segnali, non per il punteggio base.

2. Assumere "non esposto" senza prova. La BOD 26-04 dice di trattare ogni asset come esposto pubblicamente finché non dimostri il contrario. I team sottovalutano di routine l'esposizione perché si fidano di un diagramma di rete non aggiornato; verifica la raggiungibilità, non assumerla.

3. Trattare ogni voce KEV come un'emergenza di 3 giorni. Il fallimento opposto — bruciare il team su ogni listing finché smette di rispondere a qualsiasi. La maggior parte delle voci KEV cade nella fascia dei 14 giorni; riserva il fire drill di 3 giorni a KEV + controllo totale (o esposto + automatizzabile + controllo totale).

4. Chiamare "patch installata" la linea del traguardo. Se la fix ha bisogno di una modifica di configurazione, un restart del servizio, o una rotazione di certificato che la stringa di versione non cattura, l'exploit può funzionare ancora. Valida la chiusura contro il percorso di exploit reale — la stessa trappola che documenta il playbook edge-device.

5. Dimenticare che l'isolamento è una mossa legittima. Sotto un clock risk-based, mettere offline un asset esposto non patchato rimuove il segnale di esposizione e compra tempo — spesso la scelta giusta, non una sconfitta.

6. Non validare mai la sfruttabilità reale. Il fallimento più costoso su scala: riversare sforzo d'emergenza di 3 giorni su voci KEV che non sono realmente sfruttabili nella tua configurazione, mentre una genuinamente raggiungibile aspetta. Senza validazione avversariale continua del tuo estate, il triage a quattro segnali gira su assunzioni — e le assunzioni sono ciò che la BOD 26-04 è stata scritta per sostituire.

La BOD 26-04 vincola solo le agenzie civili federali USA, ma la sua portata è molto più ampia perché è la dichiarazione governativa più concreta di "tempo ragionevole per rimediare" — e quello è lo standard su cui tutti gli altri sono misurati:

• NIS2 (entità essenziali/importanti) richiede un processo risk-based di gestione delle vulnerabilità e patch; una falla KEV-listed, esposta, sfruttata lasciata oltre una finestra ragionevole è precisamente la negligenza che un supervisore cerca dopo un incidente. Se lo sfruttamento della tua istanza è confermato, il clock di notifica 24h/72h/1-mese parte sopra al clock di patch.
• DORA (entità finanziarie) impone la gestione delle vulnerabilità ICT e la remediation rapida delle falle sfruttate che affliggono funzioni critiche o importanti; il clock di incidente 4h/72h/1-mese si applica nel momento in cui lo sfruttamento è classificato come incidente maggiore.
• Assicurazione cyber. I questionari di rinnovo chiedono sempre più un SLA di patch allineato a KEV; una polizza può sub-limitare o contestare un claim dove una CVE KEV-listed è rimasta non rimediata oltre la finestra dichiarata. I tier della BOD 26-04 stanno diventando il riferimento su cui quegli SLA sono scritti.
• Il benchmark de facto. Che tu sia federale o no, "abbiamo rimediato secondo i tier di rischio CISA BOD 26-04" è una risposta difendibile a un auditor, un board, o un tribunale; "non ci eravamo ancora arrivati" contro una falla KEV-listed, esposta, sfruttata non lo è.

La disciplina operativa è quella che attraversa ogni playbook di incidente: decidi una volta, evidenzia ovunque. Il worksheet dei quattro segnali, il decision record e la validazione di chiusura sono gli stessi artefatti da cui attingono il tuo audit NIS2 di gestione vulnerabilità, la tua evidenza di resilience-testing DORA, e il tuo rinnovo assicurativo — costruisci il record una volta ed esportalo in ciascun frame.