CERT-IN: patch entro 12 ore contro gli attacchi AI
L'agenzia indiana CERT-In impone un nuovo standard: patch entro 12 ore per sistemi esposti, rispondendo alla compressione dei tempi di exploitation causata da…
Contenuto
Il 25 maggio 2026 CERT-In ha pubblicato il blueprint CISG-2026-02, un documento di 38 pagine che imposta tempistiche di remediation senza precedenti per un CERT nazionale: 12 ore per le vulnerabilità note su sistemi Internet-facing e "crown jewel", 1 giorno per quelle critiche esternamente esposte, 3 giorni per le criticità interne su asset ad alto valore. La posta in gioco è la compressione asimmetrica dei tempi d'attacco: l'intelligenza artificiale e i large language model stanno riducendo da settimane a ore — e potenzialmente a minuti — il ciclo discovery-weaponization-exploitation, rendendo incompatibili i cicli tradizionali di patch management.
- CERT-In ha pubblicato il blueprint CISG-2026-02 che raccomanda il patching entro 12 ore per vulnerabilità note su sistemi Internet-facing e "crown jewel", dove fattibile.
- Le tempistiche si estendono a 1 giorno per criticità esterne, 1 giorno per note sfruttate internamente senza mitigazioni, 3 giorni per criticità interne su sistemi high-value, 5 giorni per vulnerabilità high-severity con risk prioritization.
- L'agenzia documenta che l'AI-assisted cyber exploitation comprime i tempi di identificazione, weaponizzazione e sfruttamento delle vulnerabilità, con scenari futuri di attacchi autonomi.
- Il caso concreto del Google Threat Intelligence Group — zero-day 2FA bypass con exploit probabilmente generato da LLM, identificato in the wild — corrobora il trend teorico descritto da CERT-In.
Il documento: tempistiche e architettura della risposta
Il blueprint, intitolato "Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure", struttura una scala temporale differenziata. La finestra di 12 ore si applica ai "known exploited vulnerabilities affecting internet-facing and critical systems", con la qualifica "where applicable" che introduce un margine di fattibilità operativa non ulteriormente quantificato nel dossier. Le tempistiche successive — 1, 3 e 5 giorni — scalano in base alla severità e all'esposizione della superficie d'attacco.
L'approccio è esplicitamente risk-based: il documento non impone uniformità assoluta ma una gerarchizzazione del rischio in funzione della criticità dell'asset e della sua esposizione. Ciò riflette una consapevolezza pratica: non tutte le organizzazioni dispongono della capacità operativa per patching entro 12 ore su tutti i sistemi. Tuttavia, la direzione indicata è inequivocabile: il punto di riferimento difensivo si sposta verso la soglia delle ore, non dei giorni.
"AI-assisted cyber exploitation reduces the time required for adversaries to identify, weaponize, and exploit vulnerabilities, exposed services, weak identities, insecure APIs, and misconfigured systems" — CERT-In, blueprint CISG-2026-02
Il meccanismo: come l'AI comprime l'asimmetria offensiva-difensiva
CERT-In descrive un meccanismo strutturale, non un rischio ipotetico. L'automazione AI-assisted — che include reconnaissance automatizzata, generazione di exploit e potenziale autonomia operativa — riduce il tempo tra discovery e exploitation in modo non lineare. Secondo l'agenzia, "organizations should expect exploitation timelines to collapse significantly and attacks to become autonomous".
Il dossier non specifica tecniche di AI particolari né modelli coinvolti. Il riferimento è generico a AI e LLM, con un'attenzione specifica sul fatto che l'accelerazione riguarda l'intero stack di vulnerabilità: non solo CVE note, ma anche servizi esposti, identità deboli, API insicure e sistemi mal configurati. Questo allarga il perimetro d'intervento oltre il tradizionale vulnerability management verso una exposure management continua.
Il contesto immediato del blueprint è rilevante: il documento arriva un mese dopo un advisory di CERT-In sulle capacità cyber dei frontier AI models di Anthropic e OpenAI, suggerendo che l'agenzia stia costruendo un arco narrativo coerente sui rischi di frontiera AI.
La prova in campo: il caso Google GTIG e il primo zero-day AI-generated
La lettura teorica di CERT-In trova un corrispettivo concreto nel lavoro del Google Threat Intelligence Group, pubblicato nello stesso arco temporale. GTIG ha identificato quello che definisce "the first zero-day exploit in the wild likely developed with AI": uno script Python che bypassa l'autenticazione a due fattori, contenente "an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data".
Questo caso non è citato nel blueprint CERT-In — restano eventi separati — ma funge da evidence indipendente del fenomeno descritto. L'exhibit tecnico è particolarmente significativo: la presenza di un CVSS score "allucinato" (un numero che il modello ha generato coerentemente con il formato ma senza fondamento nell'architettura di scoring ufficiale) è un marker di generazione LLM che sfugge alla mera automazione tradizionale. Il codice non è solo prodotto velocemente: è prodotto con le caratteristiche strutturali — e i difetti cognitivi — tipici del training su corpus tecnici.
Il caso GTIG dimostra che la compressione dei tempi non è prospettica: è già avvenuta. La weaponizzazione di un zero-day, attività che tradizionalmente richiede competenze specialistiche e tempi di sviluppo prolungati, è stata eseguita con strumenti di generazione codice accessibili commercialmente.
Cosa fare adesso
- Ridurre la superficie di esposizione Internet-facing attraverso una mappatura continua dei servizi esposti, con prioritizzazione automatica basata su criticità dell'asset.
- Implementare controlli tecnici stratificati, risk-based e con validazione continua, come indicato nel blueprint, per ridurre la dipendenza dalla velocità di patching come unica linea di difesa.
- Rivalutare continuamente l'esposizione, validare i controlli di sicurezza esistenti, rafforzare le capacità di resilienza e potenziare la preparedness operativa, in un ciclo di reassessment non event-driven ma continuo.
- Riallineare i processi di patch management su metriche di tempo compatibili con la nuova scala: dove il ciclo attuale è settimanale o mensile, la tempistica di 12 ore richiede automazione del deployment e testing, non solo accelerazione manuale.
Il confine tra raccomandazione e obbligo: cosa il dossier non chiarisce
Il dossier presenta zone di incertezza rilevanti per chi deve operare. Non è specificato se le timeline siano vincolanti legalmente o meramente raccomandatorie: una fonte generalista afferma che "the blueprint itself does not create new legal obligations", ma resta ambiguo se questo escluda l'attivazione di poteri direttivi preesistenti sotto Section 70B IT Act. Non è chiaro, inoltre, quante organizzazioni rientrino nel perimetro di applicazione — solo entità governative o anche settore privato — né come CERT-In intenda verificare il rispetto o quali conseguenze in caso di inadempimento.
Il qualificatore "where feasible" nelle timeline più aggressive introduce un criterio di fattibilità non oggettivato, lasciando aperto un margine interpretativo che potrebbe ridurre la forza prescrittiva del documento in contesti operativi complessi.
Perché questo cambia il quadro per i CISO
Il segnale di CERT-In non è isolato ma si inserisce in una tendenza più ampia: gli standard difensivi stanno correndo per colmare un gap che l'offensiva AI sta aprendo sistematicamente. CISA negli Stati Uniti ha imposto timeline aggressive con i Binding Operational Directive; il framework di CERT-In è il primo caso di un CERT nazionale che quantifica esplicitamente la risposta difensiva in funzione della velocità degli attacchi AI-assisted.
La conseguenza operativa per i CISO è una trasformazione dei processi, non una semplice accelerazione. Il patching entro 12 ore su sistemi critici richiede pipeline di deployment automatizzate, capacità di rollback, testing in ambienti che replicano la produzione, e una governance del change management che tolleri latenze decisionali vicine allo zero. Non è una questione di volontà: è una questione di infrastruttura operativa che la maggior parte delle organizzazioni non possiede oggi.
Per i policy maker, il blueprint è un segnale di allarme sulla struttura del gap: le difese tradizionali operano su scale temporali che gli strumenti di AI-assisted exploitation stanno rendendo obsoleti. La risposta non può essere solo tecnica, ma richiede un ripensamento degli investimenti in resilienza e nella capacità di assorbimento dell'impatto quando la prevenzione fallisce.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/05/cert-in-mandates-12-hour-patching-for.html
- https://www.helpnetsecurity.com/2026/05/29/claroty-claire/
- https://thecyberexpress.com/cert-in-12-hour-patching-ai-llm-cyber-threats/
- https://www.firstpost.com/tech/indias-cybersecurity-agency-sounds-alarm-on-ai-powered-attacks-urges-firms-to-patch-flaws-within-12-hours-14016099.html
- https://www.cert-in.org.in/s2cMainServlet?pageid=GUIDLNVIEW02&refcode=CISG-2026-02
- https://www.helpnetsecurity.com/2026/03/03/pwc-healthcare-cybersecurity-threats-2026/
- https://thehackernews.com/2026/05/hackers-used-ai-to-develop-first-known.html
- https://thehackernews.com/2026/05/claude-mythos-ai-finds-10000-high.html