Il problema non è più “quando” applicare le patch, ma “quanto” siamo esposti

Per anni la gestione delle patch nelle infrastrutture IT ha seguito una logica prudente: rilasciare l’aggiornamento, aspettare qualche giorno o settimana per verificare che non rompa nulla in produzione, poi distribuirlo in ondate controllate. Questo modello, ragionevole quando gli attaccanti impiegavano settimane a sviluppare un exploit funzionante, sta diventando insostenibile di fronte a una realtà cambiata radicalmente: gli attori malevoli usano oggi strumenti di intelligenza artificiale per identificare e sfruttare le vulnerabilità in tempi drasticamente più brevi rispetto ai cicli di patching tradizionali.

Il punto non è più teorico. Il volume di vulnerabilità pubblicate mensilmente ha raggiunto livelli che nessun team può gestire con processi manuali: nel Patch Tuesday di giugno 2026 Microsoft ha corretto 208 vulnerabilità, salite a 621 in luglio, di cui 63 classificate come critiche e almeno 2 già sfruttate attivamente al momento del rilascio. Nessun tecnico può ragionevolmente assorbire quel volume come uno dei tanti task settimanali, e infatti le linee guida Microsoft più recenti raccomandano finestre di differimento inferiori a tre giorni per gli aggiornamenti qualitativi, con deadline di installazione a zero o un giorno e non più di due giorni di margine.

Da “patch dei computer” a “gestione del ciclo di vita di tutto ciò che è connesso”

Il cambio di paradigma proposto non è semplicemente “patchare più in fretta”, ma ripensare cosa significhi effettivamente gestire il rischio di un parco IT. Il modello classico, incentrato sull’endpoint patching, lascia scoperta una superficie di attacco enorme e in crescita: stampanti di rete, telecamere IP, sistemi HVAC, telefoni VoIP, PLC industriali. Sono tutti dispositivi connessi alla rete aziendale, spesso raggiungibili da Internet, quasi mai coperti dai sistemi di patch management tradizionali e, in molti casi, privi di un meccanismo di aggiornamento comodo o di supporto attivo del vendor.

Il risultato è una classe intera di apparati “connessi, esposti e ignorati” — per usare la formula più efficace del problema — che rappresentano oggi un vettore di compromissione tanto concreto quanto un server Windows non aggiornato, ma con una probabilità molto più bassa di rientrare in un audit di sicurezza periodico.

Un caso reale: PLC industriali sotto attacco

Non è uno scenario ipotetico. Nel corso del 2026 un avviso del governo statunitense ha documentato attori legati all’Iran nell’atto di sfruttare controllori logici programmabili (PLC) esposti direttamente su Internet in infrastrutture critiche di settori governativo, idrico, delle acque reflue ed energetico. Gli attaccanti hanno manipolato i file di progetto dei PLC e alterato le visualizzazioni SCADA, causando interruzioni operative e perdite economiche dirette.

Le raccomandazioni pubblicate da CISA in seguito a questi incidenti non riguardavano tecniche sofisticate di difesa, ma fondamentali di sicurezza rimasti clamorosamente disattesi: rimuovere l’esposizione diretta a Internet dei dispositivi, cambiare le credenziali di default, usare password complesse, applicare le patch fornite dai vendor quando disponibili. È la controprova di quanto il problema non sia (solo) tecnologico, ma di processo e visibilità.

Cosa cambia in pratica per un team infrastrutturale

Tradurre questo cambio di prospettiva in azioni concrete significa lavorare su più fronti contemporaneamente, senza aspettare che sia un incidente a imporre le priorità.

1. Automazione del patching Windows guidata da policy

Il primo passo è tecnicamente il più semplice: abbandonare il rollout scaglionato basato solo sulla prudenza a favore di processi automatizzati e guidati da policy documentate, con eccezioni esplicite e motivate anziché ritardi impliciti “per abitudine”. Strumenti come Windows Update for Business, Intune o WSUS permettono già oggi di configurare deadline aggressive con anelli di sicurezza (rollback automatico, Known Issue Rollback) per i casi in cui un aggiornamento causi regressioni.

2. Inventario di tutto ciò che è connesso, non solo degli endpoint gestiti

Serve un censimento che vada oltre l’inventario classico di Active Directory o dell’MDM: switch, access point, stampanti di rete, telecamere, sistemi di building automation, dispositivi OT. Molti di questi asset sono scoperti solo tramite scansione attiva della rete o strumenti di asset discovery dedicati, perché non compaiono mai in un dominio Windows.

3. Segmentazione di rete per i sistemi non aggiornabili

Per i dispositivi privi di un percorso di patching realistico — firmware non più supportato, hardware embedded, sistemi legacy critici che non possono essere sostituiti a breve — la mitigazione primaria diventa il contenimento: segmentazione di rete dedicata, accesso solo tramite gateway controllati, credenziali univoche e non condivise, monitoraggio del traffico in ingresso/uscita da quei segmenti.

4. Pianificazione della sostituzione, non solo della protezione

Per gli apparati che restano permanentemente non aggiornabili, la sola segmentazione è un palliativo, non una soluzione. Va costruito un piano di sostituzione con priorità basata su esposizione e criticità, invece di lasciare che questi dispositivi restino operativi a tempo indeterminato “perché funzionano ancora”.

Il messaggio di fondo per chi gestisce infrastrutture nel 2026

La sintesi più utile di questo cambiamento è che la vecchia domanda — “possiamo aspettare qualche giorno prima di installare questa patch?” — va sostituita da una diversa: “quanto tempo restiamo esposti se aspettiamo, e chi altro nella rete è esposto insieme a noi anche se non lo stiamo patchando direttamente?”. In un contesto in cui gli attaccanti automatizzano la ricognizione e lo sfruttamento delle vulnerabilità con strumenti AI, il differimento smette di essere una misura prudente di default e diventa esso stesso un rischio da giustificare, caso per caso, con un’eccezione documentata.

Per i team più piccoli, senza le risorse di un SOC dedicato, il punto di partenza realistico resta comunque il più efficace: un inventario onesto di tutto ciò che è connesso alla rete, anche (soprattutto) ciò che nessuno ha mai pensato di considerare un “endpoint” da patchare.

Fonte: 4sysops – The patch window is collapsing: why security needs a new control plane e Petri IT Knowledgebase – The Patch Window Is Collapsing. Your Service Model Has to Change, di Amy Babinchak.