CERT-In impone patch 12 ore: reagire all'AI-assisted exploitation
CERT-In riduce a 12 ore la finestra di patching per sistemi esposti. Motivo: gli attacchi assistiti da AI e LLM comprimono i tempi di weaponizzazione.
Contenuto
Il 26 maggio 2026 CERT-In, il Computer Emergency Response Team indiano, ha pubblicato un blueprint di 38 pagine che stravolge i parametri della sicurezza operativa: le organizzazioni devono correggere vulnerabilità note e sfruttate su sistemi internet-facing entro 12 ore, ove fattibile. Non è un advisory di routine. È la risposta a una trasformazione della minaccia in cui modelli linguistici e agenti AI automatizzano discovery, weaponizzazione e attacco a velocità incompatibile con gli SLA tradizionali.
- CERT-In richiede remediation entro 12 ore per flaw sfruttati su sistemi esposti a Internet e critici, 1 giorno per vulnerabilità critiche esternamente esposte, 3 giorni per sistemi interni ad alto valore, 5 giorni per vulnerabilità di alta gravità.
- Il mandato è motivato esplicitamente dalla compressione dei tempi di exploitation causata da strumenti AI e LLM usati dagli attori della minaccia.
- Trend Micro ha documentato campagne reali (Shadow-Aether-040 e 064) in cui agenti AI generano tool di hacking custom, rendendo inefficaci i controlli di sicurezza tradizionali.
- Il blueprint raccomanda Zero Trust, defense-in-depth e secure-by-design, ma non specifica meccanismi di verifica o sanzioni per il rispetto delle finestre temporali.
Da 38 pagine, un nuovo orizzonte temporale
Il documento CERT-In non si limita a fissare la barra più alta. Definisce una scala di priorità che annulla la logica del patching settimanale o mensile. Una giornata per le vulnerabilità critiche esposte esternamente, tre giorni per quelle interne su asset ad alto valore, cinque giorni per le flaw di alta gravità: questi intervalli, pur se più larghi dei 12 ore iniziali, restano drammaticamente più aggressivi della prassi industriale consolidata.
La scelta di differenziare per esposizione e criticità riflette una consapevolezza tecnica: non tutti i sistemi hanno la stessa superficie di attacco. Ma la soglia di 12 ore per i target internet-facing è il segnale politico e operativo più netto. CERT-In riconosce che l'esposizione a Internet, combinata con la notorietà dello sfruttamento, crea una condizione di rischio che non ammette cicli di remediation tradizionali.
Perché l'AI-assisted exploitation cambia il calcolo
Il nesso causale tra mandato e minaccia è dichiarato senza ambiguità. CERT-In scrive che "l'AI-assisted cyber exploitation riduce il tempo necessario agli avversari per identificare, armare e sfruttare vulnerabilità, servizi esposti, identità deboli, API insicure e sistemi misconfigurati". La compressione non è marginale: si misura nell'eliminazione delle fasi manuali che tradizionalmente intercorrevano tra disclosure pubblica e primo sfruttamento su larga scala.
Le campagne documentate da Trend Micro attraverso la ricerca Shadow-Aether corroborano questa tesi con evidenza operativa. Tra dicembre 2025 e gennaio 2026, l'attività Shadow-Aether-040 ha compromesso circa sei entità governative in Messico. In entrambe le campagne osservate, gli attori della minaccia hanno impiegato agenti AI per generare tool e script di hacking custom, dinamicamente variati ad ogni esecuzione. Questa variabilità sostituisce i tool open source più facilmente rilevabili, bypassando le firme dei sistemi di sicurezza tradizionali.
"Because these dynamically generated commands, scripts, and code differ with each execution, they effectively replace open source hacking tools that are more likely to be detected, reducing the possibility of detection by traditional security solutions" — TrendAI Research via Dark Reading
Il contesto geografico di queste campagne è il Messico, non l'India. Tuttavia, la logica tecnica che CERT-In incorpora nel proprio mandato è indipendente dalla geografia: se un attore della minaccia può generare exploit unici e non firmabili in tempo reale, la difesa basata su rilevamento post-fatto diventa insostenibile. La risposta deve essere preventiva e temporale, non signature-based.
Cosa fare adesso
Le linee guida CERT-In, pur senza indicare sanzioni o meccanismi di verifica, tracciano un perimetro d'azione concreto per le organizzazioni che rientrano nel perimetro di applicazione — ancora non quantificato nelle fonti disponibili.
- Ricalibrare i processi di vulnerability management verso prioritizzazione automatica e continua dei sistemi internet-facing, con pipeline di patching in grado di operare in finestre orarie anziché giornaliere o settimanali.
- Implementare controlli tecnici in tempo reale come Web Application Firewall, segmentazione di rete e hardening di superficie d'attacco, riducendo la dipendenza dalla sola velocità di remediation.
- Adottare architetture Zero Trust e defense-in-depth come strutturale, non opzionale: il blueprint le raccomanda esplicitamente come risposta alla natura distribuita e adattiva degli attacchi AI-assisted.
- Valutare l'automazione del patching stesso dove compatibile con i requisiti di stabilità dei sistemi, poiché il margine manuale di 12 ore è incompatible con le procedure di change management tradizionali.
I margini grigi del mandato
Restano aperture operative significative. Il requisito di 12 ore è qualificato da "ove fattibile", una clausola che lascia spazio di negoziazione ma anche di incertezza giuridica. Non è chiaro come CERT-In intenda verificare il rispetto, né quali conseguenze derivino dalla mancata adesione. La data di entrata in vigore effettiva non è indicata nelle fonti disponibili, complicando la pianificazione delle organizzazioni interessate.
Anche il perimetro soggettivo resta indeterminato: non è quantificato quante organizzazioni in India debbano conformarsi, né è documentato un numero specifico di incidenti AI-assisted avvenuti sul territorio nazionale che abbiano direttamente motivato questo livello di urgenza. Il mandato appare prospettico, fondato su proiezione di minaccia piuttosto che su cronaca incidentale consolidata.
Il ricalibro globale della sicurezza operativa
Il passo di CERT-In si inserisce in una dinamica più ampia: i regulatori nazionali stanno internalizzando che l'automazione offensiva, particolarmente quella assistita da modelli di linguaggio di ampia scala, altera in modo strutturale l'economia della cybersicurezza. Quando il costo di generare un exploit custom tende a zero e il tempo di weaponizzazione si comprime a ore o minuti, la difesa deve spostare il proprio baricentro dal rilevamento alla riduzione della superficie d'attacco e alla velocità di contenimento.
Le linee guida indiane non sono normativa primaria vincolante, ma il segnale è inequivocabile. Gli SLA di patching misurati in giorni lavorativi stanno diventando anacronismi operativi. L'alternativa proposta è un modello di sicurezza continuamente validato, tecnicamente stratificato e organizzativamente riprogettato per l'assenza di tolleranza temporale.
Se altre autorità di regolazione seguiranno questa traiettoria, il 12 ore potrebbe non restare un'eccezione indiana ma un nuovo standard di riferimento. Per le organizzazioni che operano infrastrutture esposte, la progettazione della sicurezza deve ora anticipare un orizzonte in cui la finestra di esposizione vulnerabile è misurata in cicli di orologio, non in cicli di sprint.
Fonti
- https://thehackernews.com/2026/05/cert-in-mandates-12-hour-patching-for.html
- https://www.darkreading.com/cloud-security/ai-agents-generate-custom-hacking-tools
- https://www.varindia.com/news/cert-in-mandates-12-hour-fix-for-critical-cyber-flaws-as-ai-threats-surge
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.