Quando le patch di sicurezza di un singolo mese triplicano il record precedente, ciò segnala un deterioramento della qualità del codice, una divulgazione più aggressiva delle vulnerabilità o entrambe le cose. L'ultimo Patch Tuesday di Microsoft, che Sono state individuate 622 vulnerabilità CVE., rappresenta la release più grande nella storia dell'azienda e due di queste correzioni chiudono vulnerabilità che gli aggressori stanno già sfruttando.
La scala del problema
Un aumento vertiginoso delle vulnerabilità, passate da circa 200 a giugno a 622 nel ciclo attuale, non è una variazione tipica. Riflette piuttosto la vastità dell'ecosistema di prodotti Microsoft: Windows, Azure, Office, Exchange e decine di servizi aziendali, tutti in esecuzione su miliardi di dispositivi e milioni di implementazioni infrastrutturali. Ogni componente accumula vulnerabilità a velocità diverse; una singola release mensile può includere il lavoro di più team, svolto nell'arco di mesi di sviluppo.
Per gli operatori di infrastrutture che utilizzano Windows Server, ambienti Azure o Exchange Server, questo volume crea un'immediata pressione in termini di priorità. Non tutte le patch sono critiche per ogni implementazione, ma distinguere tra le due richiede una conoscenza di base dei sistemi effettivamente in uso e delle loro funzioni.
Zero-Days in fase di sfruttamento attivo
Le due vulnerabilità zero-day richiedono un trattamento prioritario perché gli autori delle minacce le stanno già sfruttando a proprio vantaggio. Entrambe le vulnerabilità sono state segnalate attraverso canali di divulgazione responsabile da parte dei team di risposta agli incidenti, ovvero coloro che le hanno riscontrate sul campo durante le indagini sulle violazioni. Ciò significa che le tecniche per sfruttare queste falle esistono nel codice di attacco reale, non solo nelle prove di concetto teoriche.
Le vulnerabilità zero-day oggetto di sfruttamento attivo seguono in genere una tempistica prevedibile. Una volta rilasciata una patch, il codice di exploit emerge spesso entro poche ore o giorni. La finestra temporale tra il rilascio della patch e la sua diffusione su larga scala è ristretta, soprattutto per i servizi esposti a Internet. Se gestite infrastrutture basate su Windows esposte a reti non attendibili (server web, gateway di posta elettronica, servizi di accesso remoto), queste due CVE dovrebbero essere testate e implementate nel ciclo di aggiornamento più breve possibile, non con la cadenza mensile standard.
Prioritizzazione delle patch nelle release ad alto volume
Con 622 vulnerabilità da valutare, applicare immediatamente tutte le patch non è né pratico né necessario. I team infrastrutturali hanno bisogno di una strategia di filtraggio. Iniziate con le valutazioni di gravità fornite dai fornitori, ma confrontatele con l'esposizione effettiva: questa vulnerabilità interessa un servizio che gestite? Tale servizio è esposto a input o reti non attendibili? Esiste una soluzione temporanea o una modifica alla configurazione disponibile durante il test della patch?
La gestione delle patch aziendali in genere prevede aggiornamenti a fasi: prima le vulnerabilità di sicurezza critiche, poi quelle importanti e infine i problemi a priorità media e bassa. Le due vulnerabilità zero-day appartengono chiaramente al primo gruppo. Dopodiché, è opportuno concentrarsi sulla correzione delle vulnerabilità dei servizi effettivamente in esecuzione nell'ambiente. La correzione delle vulnerabilità di Microsoft Paint è meno rilevante per una server farm senza interfaccia grafica rispetto alle vulnerabilità di Exchange o SQL Server.
Test dell'infrastruttura prima della distribuzione
Le patch di grandi dimensioni spesso introducono regressioni, ovvero correzioni che compromettono funzionalità legittime in configurazioni specifiche. Con 622 modifiche rilasciate simultaneamente, la probabilità di interazioni impreviste aumenta. Prima di implementare qualsiasi patch sui sistemi di produzione, soprattutto su infrastrutture critiche, testatela in un ambiente di staging che rispecchi il più fedelmente possibile la configurazione di produzione.
Prima di applicare le patch, documentate la configurazione di base: versioni del kernel, servizi in esecuzione, software di terze parti e problemi di compatibilità noti. Se una patch causa un'interruzione del servizio, sarà necessario ripristinare la versione precedente, e ciò richiede una comprensione precisa delle modifiche apportate. Per le organizzazioni che gestiscono infrastrutture offshore o server farm distribuite in diverse giurisdizioni, il costo di coordinamento derivante da una patch errata può essere considerevole.
Pensiero finale
Il volume record di patch da rilasciare è preoccupante, ma non senza precedenti; riflette la complessità del software moderno su larga scala. Le due vulnerabilità zero-day richiedono un'attenzione immediata, ma le restanti 620 meritano un'analisi metodica piuttosto che il panico. È fondamentale creare un flusso di lavoro di applicazione delle patch ripetibile, classificare i sistemi in base alla criticità e allocare le risorse di test in modo da individuare le vulnerabilità più gravi e i servizi ampiamente distribuiti. Questa disciplina si rivelerà utile sia che Microsoft rilasci 100 patch, sia che ne rilasci 1,000.
