BOD 26-04 di CISA: le scadenze di patch basate sul rischio

Una Binding Operational Directive è un'istruzione vincolante di CISA per le agenzie del ramo esecutivo federale USA, ai sensi del 44 U.S.C. § 3554. La BOD 26-04, "Prioritizing Security Updates Based on Risk", è stata emessa il 10 giugno 2026 e sostituisce e revoca due direttive precedenti:

• BOD 22-01 (3 novembre 2021): ha creato il catalogo Known Exploited Vulnerabilities (KEV) e dava alle agenzie due settimane per correggere ogni CVE in KEV assegnata dal 2021 in poi, sei mesi per quelle più vecchie.
• BOD 19-02 (29 aprile 2019): fissava 15 giorni per le vulnerabilità critiche e 30 per quelle alte sui sistemi esposti su internet, in base al CVSS.

L'idea della nuova direttiva è che non tutte le vulnerabilità, e non tutti i sistemi, meritano la stessa urgenza. CISA osserva anche che l'AI può accorciare il tempo tra il rilascio di una patch e lo sfruttamento: per questo la scadenza più breve ora è di tre giorni invece di due settimane.

La BOD 26-04 decide l'urgenza da quattro valori, ognuno sì/no. Due, Automatable e Technical Impact, arrivano dal programma Vulnrichment di CISA, che pubblica nel record CVE i punti decisionali SSVC.

• Esposizione dell'asset. Un asset è esposto pubblicamente se soggetti non autenticati o non fidati possono raggiungerlo da una rete pubblica, ovunque si trovi fisicamente o logicamente. Se un qualsiasi metodo, come il CDM o le scansioni Cyber Hygiene di CISA, lo trova esposto, il valore è sì.
• Stato KEV. Se la CVE è nel catalogo KEV.
• Automazione dell'exploit. Se un avversario può automatizzare tutti i passi dell'exploit. Il criterio pratico di CISA: se un proof of concept pubblico ottiene l'esecuzione di codice remoto e funziona in modo affidabile contro un sistema vulnerabile, la risposta è sì.
• Impatto tecnico. Totale se l'attaccante ottiene il pieno controllo del comportamento del software, per esempio installando ed eseguendo software arbitrario, o rivelando in modo affidabile credenziali di accesso (CISA cita Heartbleed e Citrixbleed). Parziale indica un controllo limitato o un'esposizione di informazioni; il denial of service è parziale.

I valori predefiniti contano quanto le definizioni. Se un'agenzia non ha dati di esposizione, la guida attuativa di CISA considera pubblico un asset che comunica su un IP pubblicamente instradabile, che ha tipo "network" o, per le CVE in KEV, il cui software è di norma esposto al pubblico; altrimenti lo considera interno. Se una CVE fuori dal KEV non ha ancora dati Vulnrichment, CISA la tratta come non automatizzabile ma con impatto totale.

I quattro segnali danno 16 combinazioni possibili, che la Tabella 1 della direttiva assegna a cinque esiti. Tutte le scadenze sono in giorni di calendario e sono massimi: le agenzie possono correggere prima.

• 3 giorni e triage forense. La fascia più alta: vulnerabilità in KEV che danno il controllo totale (nel feed conta anche la valutazione di esposizione di CISA; vedi la sezione seguente). L'asset va corretto o mitigato entro tre giorni ed esaminato per tracce di una compromissione avvenuta prima della patch.
• 3 giorni. Combinazioni ad alto rischio senza obbligo di triage, per esempio un asset esposto con una falla automatizzabile a controllo totale che non è ancora nel KEV.
• 14 giorni. La fascia per gran parte delle altre vulnerabilità in KEV e per diverse combinazioni ad alto rischio fuori dal KEV.
• 60 giorni. Combinazioni a rischio minore, come un asset non esposto con una falla automatizzabile che dà solo un controllo parziale.
• Correzione al prossimo upgrade. Nessun criterio di rischio soddisfatto: si corregge al prossimo upgrade importante o ricostruzione pianificata dell'asset. La guida di CISA dice che le agenzie "non devono dare priorità" a queste vulnerabilità.

La Tabella 1 è pubblicata solo come immagine nella pagina della direttiva e CISA la rivede una volta per anno fiscale. Per una voce KEV non serve ricavare la fascia: CISA la calcola e la pubblica nel catalogo.

Ogni voce del feed JSON del KEV ha ora un campo dueDate calcolato secondo la BOD 26-04 e un campo forensicTriage. Abbiamo contato le 137 voci aggiunte da CISA tra il 10 giugno e il 21 ottobre 2026 (versione del catalogo 2026.10.21):

• 89 (65%) avevano una scadenza di 3 giorni con triage forense.
• 22 (16%) avevano 3 giorni senza triage.
• 26 (19%) avevano 14 giorni.
• Nessuna aveva 60 giorni o "prossimo upgrade".

In pratica, per una nuova voce KEV i 3 giorni sono la norma, non l'eccezione. Il confronto delle stesse voci con i valori Vulnrichment di CISA mostra altre due cose. Il triage forense non dipende dall'automazione: 31 delle 89 voci con triage risultano non automatizzabili. E il controllo totale da solo non basta a farlo scattare: 27 voci KEV con impatto totale non hanno il triage, segno che conta anche la valutazione di esposizione del software fatta da CISA. La regola sicura è leggere entrambi i campi per ogni CVE invece di dedurli. Il nostro tracker CISA KEV li mostra per ogni aggiunta degli ultimi 90 giorni.

Il conteggio parte dal primo di due eventi: CISA aggiunge la CVE al catalogo KEV, oppure l'agenzia trova la vulnerabilità su un asset e la registra nelle dashboard CDM dell'agenzia e federale. Un team che trova da sé un asset vulnerabile, prima che CISA inserisca la CVE, è già in conteggio.

Le scadenze cambiano in entrambe le direzioni:

• Togliere un asset da internet cambia il suo valore di esposizione e può spostarlo su una scadenza più lunga.
• L'inserimento nel KEV di una CVE già tracciata accorcia la scadenza.

Secondo la guida di CISA l'unica mitigazione nota per una voce KEV è l'azione richiesta indicata nel catalogo. Se non si riesce in tempo, l'asset esce dalla rete: dismissione, rimozione del prodotto vulnerabile, segmentazione, perimetro software-defined o proxy. CISA non concede deroghe né eccezioni; per i casi particolari le agenzie scrivono a [email protected] per le opzioni di mitigazione.

La BOD 26-04 richiede "un'adeguata analisi di triage forense" per la fascia più alta: la patch chiude la porta ma non caccia un attaccante entrato prima. La guida attuativa di CISA indica sei passi, con tempi dall'inserimento nel KEV che presenta come buona pratica, non come obbligo:

1. 1Perimetro, prime 2 ore. Attiva il team di risposta, delimita sistemi e servizi coinvolti e apri un canale fuori banda che non dipenda da infrastrutture forse compromesse.
2. 2Preserva e raccogli le evidenze, da 2 a 24 ore. Prima i dati volatili (memoria, cache, registri, stato di rete), poi quelli meno volatili, senza alterare prima il sistema. Tieni un registro delle evidenze: elemento, sistema, ora, chi l'ha raccolto.
3. 3Patch critica e stabilizzazione, da 2 a 24 ore. Applica la patch dopo aver raccolto le evidenze, poi stabilizza i sistemi di business toccati dalla patch.
4. 4Contenimento, da 6 a 24 ore. Isola i sistemi colpiti o sospetti senza mettere in allarme l'attaccante e documenta ogni azione.
5. 5Analisi di triage, da 24 a 48 ore. Cerca accessi non autorizzati, movimenti laterali, persistenza e preparazione o esfiltrazione di dati; verifica gli indicatori di compromissione e cercali altrove.
6. 6Decisione di escalation, da 48 a 72 ore. Scrivi un report di triage (cronologia, azioni, risultati, contenimento, passi successivi). Nessuna prova di compromissione: segnala, aumenta il monitoraggio, completa la correzione. Compromissione confermata: segnalala a CISA e passa alla piena risposta all'incidente. Sospetta: continua il triage e coordinati con CISA.

Quando CISA ha indicatori di compromissione o indicazioni forensi specifiche per una CVE, le aggiunge alla voce KEV.

Le azioni richieste dalla direttiva arrivano in tre fasi, contate dal 10 giugno 2026:

• Subito. Aggiornare le policy di gestione delle vulnerabilità, monitorare il KEV e correggere entro le sue scadenze, automatizzare il reporting sullo stato KEV tramite la dashboard CDM (o riferire a mano ogni due settimane) e lasciare libere le scansioni Cyber Hygiene di CISA.
• Entro 60 giorni (circa 9 agosto 2026). Aggiornare i processi per coprire le vulnerabilità dell'intero database CVE, non solo del KEV.
• Entro 180 giorni (circa 7 dicembre 2026). Correggere entro le scadenze della Tabella 1; etichettare ogni asset raggiungibile dall'esterno per organizzazione, ambiente, esposizione e tipo; includere nella dashboard CDM anche gli indirizzi privati RFC 1918 e RFC 4193. Le agenzie non del tutto automatizzate tramite CDM inviano le etichette ogni sette giorni.

Ambito: la direttiva copre gli asset delle agenzie in qualsiasi sistema informativo federale, compresi quelli gestiti da terzi per conto di un'agenzia. Non vincola i fornitori se il contratto non lo prevede ed esclude i sistemi di sicurezza nazionale e alcuni sistemi del Department of War e dell'Intelligence Community. Per i servizi cloud le agenzie passano dal FedRAMP PMO, che chiederà regole equivalenti ai provider entro il 7 dicembre 2026; per gli altri provider, direttamente con il fornitore cloud.

Un'azienda privata, una banca europea o un ospedale non sono vincolati dalla BOD 26-04. La direttiva conta comunque per tre ragioni pratiche:

• Ha sostituito il numero che tutti copiavano. Per cinque anni "14 giorni per il KEV" è stato il riferimento di tempo ragionevole in policy di patch, questionari assicurativi e rilievi di audit, anche se a rispettarlo erano tenute solo le agenzie federali. Quel numero non esiste più; il riferimento pubblico più vicino è ora di 3 giorni per gran parte delle nuove voci KEV.
• Contratti e servizi cloud la trasmettono. I contratti federali possono imporla e FedRAMP sta allineando le proprie regole per i provider cloud.
• I regolatori chiedono un processo basato sul rischio. NIS2 e DORA non fissano scadenze di patch in giorni, ma si aspettano una gestione delle vulnerabilità basata sul rischio. Una policy che cita i quattro segnali della BOD 26-04 e li registra per ogni vulnerabilità è facile da difendere.

Il modello si può usare anche senza le dashboard CDM. Una versione praticabile per un team di sicurezza privato:

• Usa la scadenza KEV come limite massimo. Iscriviti al feed KEV e tratta i campi dueDate e forensicTriage come il massimo per ogni asset coinvolto che gestisci.
• Valuta le CVE fuori dal KEV con gli stessi quattro valori. Automatable e Technical Impact sono gratuiti nel record CVE, nel container CISA ADP di Vulnrichment. L'esposizione è l'unico valore che solo tu puoi stabilire.
• Fai dell'esposizione un'evidenza, non una stima. Tieni un inventario degli asset che registri quali sistemi sono raggiungibili da utenti non fidati, e aggiornalo quando cambia una regola firewall o un'impostazione cloud. Nel dubbio, il default di CISA va verso "esposto".
• Prepara in anticipo la corsia dei 3 giorni. Change d'emergenza pre-approvate, piani di rollback e un runbook di triage che segua i sei passi qui sopra. Tre giorni non bastano per negoziare una finestra di change.
• Registra perché hai fissato ogni scadenza. I quattro valori, la fonte di ciascuno, la scadenza risultante e la verifica di chiusura. È quello che chiederanno un auditor, un assicuratore o un'autorità di vigilanza.

Il playbook sulla finestra di patch d'emergenza KEV segue la scelta tra patch, mitigazione o isolamento una volta nota la scadenza.

Dei quattro segnali, lo stato KEV e i valori Vulnrichment arrivano da CISA. Esposizione e sfruttabilità reale sono fatti della tua rete, e sono proprio quelli che i team di solito stimano sotto scadenza.

Zero Hunt è un red team AI autonomo che gira su un'appliance on-premise con AI privata. Sincronizza il feed CISA KEV, comprese le scadenze di CISA, e i punteggi EPSS di FIRST, poi testa reti e infrastrutture in modalità black box o gray box: se un servizio vulnerabile è raggiungibile da dove si troverebbe un attaccante e se l'exploit funziona davvero sulla tua configurazione. I passi di sfruttamento attendono l'approvazione di una persona al livello di autonomia che scegli, e ogni risultato resta come evidenza firmata Ed25519 e concatenata con hash, da consegnare a un auditor. Non fissa al posto tuo la fascia BOD 26-04: ti dà le evidenze per il valore di esposizione e ti dice quali voci a 3 giorni sono reali nel tuo ambiente. È il ciclo continuo descritto dal CTEM.