CERT-In impone patch entro 12 ore per vulnerabilità esposte su internet

Il CERT-In introduce un cambio di passo nella gestione delle vulnerabilità imponendo la correzione entro 12 ore, dove fattibile, per le vulnerabilità note sfruttate che colpiscono sistemi esposti su internet. L’Indian Computer Emergency Response Team pubblica un blueprint di 38 pagine per rafforzare la resilienza delle organizzazioni davanti a minacce cibernetiche accelerate dall’intelligenza artificiale e dai large language model. Il documento parte da un presupposto netto: gli attaccanti non operano più con i tempi tradizionali della ricerca manuale, ma usano strumenti AI per scoprire servizi esposti, analizzare falle, generare exploit, automatizzare phishing e comprimere i cicli di attacco. Questa accelerazione riduce drasticamente la finestra utile per intervenire dopo la pubblicazione di una vulnerabilità o la conferma del suo sfruttamento. Le organizzazioni indiane, pubbliche e private, devono quindi adottare un modello di vulnerability management continuo, basato sul rischio e orientato alla riduzione immediata dell’esposizione. Il focus principale cade sugli asset internet-facing, perché rappresentano il punto più accessibile per campagne automatizzate, scansioni massive, exploit rapidi e operazioni di compromissione iniziale. Il CERT-In collega questa urgenza alla crescente dipendenza da cloud, supply chain software, API, tecnologie operative e piattaforme abilitate all’IA, tutte componenti che ampliano l’impatto potenziale di una vulnerabilità non corretta.

Le vulnerabilità internet-facing diventano priorità assoluta

Il mandato più forte del nuovo blueprint riguarda le vulnerabilità note e sfruttate su sistemi esposti a internet, che devono essere corrette entro 12 ore quando l’intervento è tecnicamente possibile. Questa finestra temporale rappresenta una rottura rispetto a molte pratiche tradizionali di patching, spesso costruite su cicli settimanali, mensili o su finestre di manutenzione più lente. Il CERT-In ritiene che il tempo operativo degli attaccanti sia ormai troppo breve per consentire ritardi prolungati, soprattutto quando una falla riguarda servizi pubblicamente raggiungibili, identità deboli, API insicure o configurazioni errate. La regola si applica in particolare a vulnerabilità critiche che colpiscono asset internet-facing e sistemi essenziali, dove il rischio di sfruttamento automatizzato è più alto. Le organizzazioni devono documentare le azioni intraprese, verificare l’efficacia delle patch applicate e mantenere tracciabilità sulle decisioni di remediation. L’obiettivo non è soltanto chiudere rapidamente la singola falla, ma ridurre la finestra di opportunità in cui un attaccante può passare dalla ricognizione all’exploit. La logica è quella di un patching quasi operativo, integrato con monitoraggio continuo, inventario aggiornato degli asset e capacità di prioritizzazione dinamica. In questo schema, la vulnerabilità esposta su internet non viene più trattata come elemento tecnico da inserire in una coda ordinaria, ma come rischio immediato per continuità, dati e resilienza dell’organizzazione.

L’intelligenza artificiale comprime i tempi degli attacchi

Il CERT-In descrive un panorama in cui l’intelligenza artificiale aumenta velocità, scala e precisione degli attacchi. Gli aggressori possono usare modelli AI per identificare servizi esposti, leggere advisory tecnici, trasformare proof-of-concept in exploit più affidabili, generare contenuti di phishing credibili e automatizzare parti della creazione di malware. I large language model abbassano la barriera d’ingresso per attori meno esperti, ma offrono anche vantaggi operativi a gruppi più maturi che vogliono industrializzare ricognizione, sviluppo di payload e social engineering. Il documento avverte che questa evoluzione può portare a un collasso dei tempi di sfruttamento, con attacchi sempre più autonomi e meno dipendenti da lavoro manuale. La minaccia non riguarda soltanto i sistemi tradizionali, ma anche le piattaforme AI stesse, esposte a rischi come prompt injection, fughe di dati, jailbreaking, manipolazione dei modelli e compromissione dell’integrità delle risposte. Le organizzazioni che adottano strumenti AI senza governance adeguata aumentano quindi la propria superficie d’attacco. Il CERT-In interpreta questa trasformazione come un motivo per abbandonare modelli di sicurezza reattivi e passare a una difesa continua, validata e anticipatoria. L’IA rende più veloci gli attaccanti, ma obbliga anche i difensori a essere più rapidi nella scoperta degli asset, nella valutazione del rischio e nella correzione delle vulnerabilità più esposte.

Tempistiche scalate per remediation e sistemi critici

Il blueprint del CERT-In introduce tempistiche differenziate in base alla criticità della vulnerabilità, alla posizione del sistema e al valore operativo dell’asset. Le vulnerabilità critiche esposte esternamente devono ricevere intervento entro un giorno, mentre le vulnerabilità note sfruttate sui sistemi interni devono essere risolte entro un giorno salvo mitigazioni alternative documentate. Le falle critiche interne che colpiscono asset ad alto valore richiedono correzione entro tre giorni, mentre le vulnerabilità ad alta severità seguono una finestra di cinque giorni secondo priorità di rischio. Questa impostazione permette alle organizzazioni di concentrare risorse sui sistemi più esposti senza perdere controllo sugli ambienti interni. Il criterio fondamentale resta la combinazione tra esposizione, sfruttamento noto, impatto sul business e valore dell’asset. Il CERT-In chiede un modello di gestione continuo, non episodico, in cui inventario, scansione, threat intelligence, patching e verifica siano collegati. Le scadenze non devono essere lette come semplici obblighi formali, ma come strumenti per imporre disciplina operativa in ambienti dove i ritardi nella remediation continuano a produrre compromissioni evitabili. Le organizzazioni devono aggiornare le priorità in tempo reale quando emergono nuovi exploit, nuove campagne o nuove informazioni sulla criticità di un servizio. Il punto centrale è che la vulnerabilità non viene più valutata soltanto con il punteggio tecnico, ma con la sua esposizione reale e con la probabilità concreta di essere sfruttata in un contesto AI-assisted.

Zero Trust, defense-in-depth e secure-by-design

Le linee guida del CERT-In promuovono un impianto difensivo fondato su Zero Trust, defense-in-depth e secure-by-design. Il principio di base è assumere la compromissione e prepararsi a rilevare, contenere e recuperare rapidamente. L’approccio Zero Trust richiede verifiche continue, privilegi minimi, segmentazione, controllo delle identità e riduzione della fiducia implicita tra sistemi. La defense-in-depth introduce controlli stratificati per evitare punti singoli di fallimento, mentre il paradigma secure-by-design impone di integrare sicurezza in sistemi, applicazioni e workflow AI fin dalle fasi iniziali di progettazione. Il documento insiste anche sulla protezione dei dati sensibili lungo l’intero ciclo di vita, sulla continuità operativa durante incidenti e interruzioni e sulla necessità di validare continuamente l’efficacia dei controlli. Red teaming, vulnerability assessment e penetration testing diventano strumenti di verifica ricorrente, non attività occasionali. Il CERT-In richiama inoltre la gestione dei rischi di supply chain software attraverso SBOM, validazione della provenienza e valutazioni regolari dei fornitori. La presenza di piattaforme AI nei processi aziendali richiede governance formale, visibilità sulle integrazioni e controllo dei comportamenti operativi. La sicurezza non viene quindi ridotta al patching, ma inserita in un modello più ampio in cui esposizione, identità, dati, supply chain e intelligenza artificiale vengono gestiti come componenti dello stesso rischio sistemico.

Mitigazioni temporanee quando la patch non è disponibile

Il CERT-In riconosce che non sempre una patch può essere applicata immediatamente o che, in alcuni casi, il vendor potrebbe non aver ancora rilasciato una correzione definitiva. In queste situazioni, il blueprint indica mitigazioni temporanee che devono essere documentate, verificate e mantenute fino alla risoluzione completa. Le organizzazioni possono isolare i sistemi vulnerabili, restringere l’accesso a indirizzi o reti fidate, applicare protezioni tramite WAF o API gateway, rafforzare il monitoraggio, disattivare funzionalità non essenziali e ridurre l’esposizione dei servizi pubblicamente raggiungibili. Queste misure non sostituiscono la patch, ma servono a limitare la probabilità di exploit nella finestra di vulnerabilità. La documentazione diventa essenziale perché consente di spiegare perché una correzione non è stata applicata entro la finestra richiesta e quali controlli compensativi sono stati adottati. Il CERT-In chiede anche verifiche periodiche dell’efficacia delle mitigazioni, perché una misura temporanea non validata può generare falsa sicurezza. Questo approccio evita che le organizzazioni usino l’assenza di una patch come giustificazione per l’inazione. Anche senza correzione definitiva, il rischio può essere ridotto attraverso contenimento, segmentazione, controllo dell’accesso e monitoraggio mirato. In un contesto di attacchi AI-assisted, la capacità di applicare rapidamente mitigazioni compensative diventa parte integrante della resilienza operativa.

Impatto sulle organizzazioni indiane e sulla governance cyber globale

Il mandato del CERT-In segna un’evoluzione rilevante per la cybersecurity indiana e può influenzare anche organizzazioni globali che operano nel Paese o mantengono infrastrutture collegate a entità indiane. Le aziende devono rivedere processi di vulnerability management, finestre di manutenzione, capacità di inventario, procedure di escalation e accordi con fornitori esterni. Il patching entro 12 ore per vulnerabilità sfruttate su sistemi internet-facing richiede automazione, asset management accurato, team operativi disponibili, test rapidi e capacità di rollback. Il blueprint promuove anche una cultura di miglioramento continuo, in cui i controlli baseline non vengono considerati adempimenti statici ma elementi da validare regolarmente. Per gli enti pubblici, la misura rafforza la resilienza dei servizi digitali e riduce il rischio di compromissioni su larga scala. Per il settore privato, introduce una pressione operativa significativa ma coerente con un contesto di minacce più rapide. Le organizzazioni che dipendono da cloud, API, supply chain software e piattaforme AI devono inoltre costruire governance più chiara sull’uso dell’intelligenza artificiale e sui dati trattati dai modelli. Il CERT-In manda un messaggio che va oltre l’India: nell’era degli exploit automatizzati e dell’AI offensiva, la velocità della difesa diventa una metrica critica quanto la qualità tecnica dei controlli.

La nuova baseline della sicurezza è la risposta immediata

Le linee guida del CERT-In mostrano come la cybersecurity stia entrando in una fase in cui patching, mitigazione e validazione devono avvicinarsi ai ritmi degli attaccanti. La finestra di 12 ore per le vulnerabilità note sfruttate sui sistemi esposti su internet indica una nuova baseline operativa, pensata per impedire che exploit automatizzati trasformino rapidamente una falla pubblica in compromissione reale. Il documento non si limita a prescrivere tempi più stretti, ma costruisce un modello complessivo basato su gestione continua delle vulnerabilità, Zero Trust, defense-in-depth, secure-by-design, governance AI, protezione dei dati e controllo della supply chain. Le organizzazioni che continueranno a trattare il patching come processo lento, manuale e separato dal rischio reale resteranno più esposte a campagne automatizzate. Al contrario, chi integra inventory, intelligence, scanning, remediation e mitigazioni compensative potrà ridurre sensibilmente la superficie d’attacco. Il messaggio operativo è netto: l’IA accelera la scoperta e lo sfruttamento delle vulnerabilità, quindi anche la difesa deve comprimere tempi, automatizzare priorità e assumere che ogni sistema internet-facing non corretto sia un bersaglio immediato.