Gestione patch per evitare problemi come EternalBlue [chiuso]

Come con le patch per le vulnerabilità utilizzate dal ransomware, non c'è stato alcun impatto negativo descritto da Microsoft.

In un'utopia, gli amministratori di sistema rattoppano i sistemi su base giornaliera. Tuttavia, nel mondo reale, è l'esatto contrario.

Alcuni aggiornamenti potrebbero dover essere rivisti, in modo da non avere un impatto negativo sulla produttività di un'azienda. Sebbene rari, alcune istituzioni considerano i tempi morti e la potenziale perdita di lavoro per essere molto significativa.

I sistemi potrebbero non essere connessi alla rete o non essere collegati a un server aziendale che richiede la distribuzione di determinati aggiornamenti. I computer portatili sono notoriamente noti per essere dietro alle toppe a causa della loro natura portatile e non connessa.

Inoltre, alcune istituzioni potrebbero avere cicli di patch, tali che una patch potrebbe essere pubblica, ma non distribuita per un mese o più.

Non c'era alcuna scusa valida per l'impatto del ransomware, in quanto la patch e l'avviso erano pubblici il 17 marzo, ma le vulnerabilità erano state sfruttate quasi 2 mesi dopo (12 maggio) .

È possibile leggere il bollettino sulla sicurezza di Microsoft qui: link

La risposta è semplice, applica patch (sicurezza e qualità critica) non appena disponibili dal venditore, il che implica che usi solo piattaforme supportate dai fornitori (questo potrebbe non essere sempre facile da controllare, ad esempio Ubuntu LTS fornisce patch di sicurezza solo per un sottoinsieme molto limitato di pacchetti.

Per gli aggiornamenti non critici, dipende se vuoi tenere il passo o pianificare di ripristinare i sistemi ogni 3 anni.

Sasser è stato il gold standard per i racconti di ammonimento sulle patch. Si ritiene che sia stato ideato in reverse dalla patch mensile di aprile e rilasciato entro una settimana.

Sarebbe aprile 2004. Il concetto di generazione automatica di exploit di patch ( link ) è il peggiore caso di scenario per un exploit armato rilasciato. Gli exploit worm sui servizi abilitati per default hanno una lunga storia su Windows, e le organizzazioni hanno avuto 13 anni per mettere insieme le loro azioni in termini di patch tempestive.

Il tempo necessario per raggruppare un exploit già armato è in realtà piuttosto lungo. (circa 2 mesi) Ancora non ci sono scuse in molti casi.

Microsoft verifica anche le patch tutte insieme (senza eccezioni per le patch non opzionali) le organizzazioni utilizzano i filtri WSUS (in genere) per limitare solo le patch alle patch critiche / di sicurezza. Questa è un'altra pratica che sconsiglio molto, questo significa che stai utilizzando una serie di patch che rendono i tuoi sistemi vulnerabili in modo univoco allo sfruttare il concatenamento ( link ) oltre a ridurre la difficoltà che un utente malintenzionato deve elevare i privilegi dopo che inevitabilmente sono entrati in un sistema.

Se stavo progettando un criterio di patching, sarebbe applicato a tutti gli endpoint entro 72 ore dal rilascio (cancello che si collega ai dispositivi endpoint dell'utente fino a quando non si è applicato un script di accesso / avvio). Inoltre, sarebbe un strategia di "tutto" patch che corrisponde ai processi di controllo qualità di Microsoft, quindi non sono soggetto a problemi dovuti a patch incomplete.

Non direttamente correlato, ma qui è una storia che potrebbe spiegare quali patch potrebbero dover essere riviste prima di essere applicate negli ambienti di produzione. Lavoravo in un'organizzazione di dimensioni medio-grandi che utilizzava attività di produzione automatizzate basate su Microsoft Excel e un gran numero di macchine erano coinvolte in quel sistema di produzione. Niente di male fino a lì. Siccome avevamo amministratori della sicurezza, ogni macchina eseguiva un antivirus e le firme antivirus venivano aggiornate ogni giorno, durante la notte.

Una notte, il file della firma dell'antivirus conteneva un falso rilevamento che metteva in quarantena una DLL richiesta da Microsoft Office ... Nulla poteva essere prodotto durante tutta la mattinata e la produzione è stata riavviata solo nel pomeriggio perché ci voleva meno di mezz'ora per diagnosticare il problema, ma mezza giornata per il team di supporto per ripristinare la DLL su tutte le macchine. Potrebbe sembrare non molto importante, ma poiché i prodotti contenevano le previsioni del tempo, i clienti non erano particolarmente contenti di non trovarli all'inizio della giornata di lavoro ...

Ma questo non è un motivo per non applicare una patch di sicurezza almeno un mese dopo che è stata resa pubblica.