Per aggiornare o non aggiornare?

Da quando ho iniziato a lavorare dove sto lavorando ora, ho avuto una lotta infinita con il mio capo e i miei colleghi per quanto riguarda l'aggiornamento dei sistemi.

Ovviamente sono pienamente d'accordo sul fatto che qualsiasi aggiornamento (sia esso firmware, sistema operativo o applicazione) non dovrebbe essere applicato con noncuranza non appena viene pubblicato, ma credo fermamente che ci dovrebbe essere almeno qualche motivo se il fornitore lo ha rilasciato; e il motivo più comune è di solito fissa alcuni bug ... che forse non stai vivendo ora, ma si potrebbe essere verificato presto se non tenere il passo con.

Ciò è particolarmente vero per le correzioni di sicurezza; come esempio, se qualcuno avesse semplicemente applicato una patch che era già disponibile da mesi , il famigerato SQL Slammerworm sarebbe stato innocuo.

Sono tutto per testare e valutare gli aggiornamenti prima di distribuirli; ma non sono assolutamente d'accordo con l'approccio "se non è rotto, allora non toccarlo" per la gestione dei sistemi, e mi fa davvero male quando trovo sistemi di produzione Windows 2003 SP1 o ESX 3.5 Update 2 e l'unica risposta che posso ottenere è "funziona, non vogliamo romperlo".

Cosa ne pensi di questo?
Qual è la tua politica?
E qual è la vostra politica aziendale , se non corrisponde alla vostra?

Che dire degli aggiornamenti del firmware (BIOS, archiviazione, ecc.)?
Che dire degli aggiornamenti principali del sistema operativo (service pack)?
Che dire degli aggiornamenti minori del sistema operativo?
Che dire degli aggiornamenti delle applicazioni?

Il mio interesse principale è ovviamente quello di aggiornare i server, poiché la gestione delle patch dei client è generalmente più semplice e ci sono strumenti e best practice ben noti per gestirli.

Sicurezza e agilità dovrebbero essere bilanciate rispetto a stabilità e uptime nel determinare la strategia di patching. Il tuo approccio push-back per questo dovrebbe essere sulla falsariga di "Okay, ma devi sapere che ora siamo a rischio che questi server vengano compromessi e che i nostri dati vengano rubati o che i server vengano resi non funzionali" e "Va bene, ma è necessario sapere che ciò influisce sul supporto del fornitore per questo sistema e sulla capacità futura di far interagire questo sistema con i nuovi sistemi".

Contro la mentalità a lungo termine "non rotto, non aggiornare", dovresti chiarire che:

• La migrazione di un sistema legacy senza patch che è rimasto indietro rispetto a un sistema moderno è un processo molto più costoso e doloroso rispetto all'aggiornamento graduale del sistema nel tempo.
• Il personale IT esperto e competente cerca attivamente nuove tecnologie e aziende in costante evoluzione dei loro sistemi IT. Il fatturato, le opportunità perse e la perdita di conoscenza comportano un costo in dollari molto reale quando un'azienda perde il proprio personale IT altamente coinvolto e creativo a causa della stagnazione dei sistemi con cui diventa poco attraente lavorare. Quindi tutto ciò che ti rimane sono i 'lifers'.

Spero che questo ti dia un po 'di leva e buona fortuna nel convincere gli abissi a prendere le cose sul serio. Come sempre, stabilire una traccia cartacea che dimostri di aver informato la gestione dei rischi che stanno correndo.

Questo è un dibattito senza fine e le persone ragionevoli non saranno d'accordo. Se stai parlando di PC utente, sono d'accordo che devono essere aggiornati. Se stai parlando di server, considera una politica separata per i server che si affacciano su Internet e quelli che non lo fanno. Non conosco i tuoi server ma nel mio ambiente, forse il 10% dei nostri server ha porte aperte su Internet. Questi server rivolti a Internet hanno la massima priorità quando si tratta di patch di sicurezza. I server che non affrontano Internet hanno una priorità inferiore.

I guru della sicurezza sosterranno che questo approccio è problematico perché se un hacker entra nella tua rete, i server senza patch consentiranno agli exploit di attraversare la rete come un incendio e questo è un argomento ragionevole. Tuttavia, se si tengono ben chiusi i server con connessione a Internet e si configura correttamente il firewall in modo da aprire solo le porte che sono assolutamente necessarie, penso che questo approccio funzioni e possa spesso essere utilizzato per placare i gestori che hanno paura delle patch.

Se fai affidamento solo su Windows Update per le patch (non hai menzionato il sistema operativo in esecuzione ma sono principalmente un ragazzo di Windows, quindi questo è il mio riferimento), dai un'occhiata agli aggiornamenti rapidi che vengono rilasciati ogni mese . Ho alcuni server che se eseguo Windows Update su di loro mi verrà detto che ho bisogno di oltre 50 patch ma se scorro quelle patch e cerco ognuna di esse, scoprirò che il 90% degli elementi che sono patch non sono di sicurezza bug correlati ma corretti che incidono sui servizi che non eseguo su quella scatola. In ambienti più grandi in cui si utilizza un sistema di gestione delle patch, è comune rivedere tutto ciò che viene rilasciato e preoccuparsi solo di ciò che è assolutamente necessario e che di solito equivale a circa il 10% di ciò che Microsoft rilascia.

La mia tesi è che questo dibattito su "rattoppare o non rattoppare" suggerisce che devi essere da una parte o dall'altra quando, in realtà, questa è una grande area grigia.

Posso solo parlare di server ma abbiamo un regime di "aggiornamento trimestrale", su quattro date predeterminate e annunciate all'anno che raggruppiamo le richieste di aggiornamento, le applichiamo al nostro ambiente di riferimento, le eseguiamo per un mese per testare la stabilità e, se funzionante, implementare durante i seguenti n giorni / settimane. Inoltre, applichiamo una politica di aggiornamento di emergenza in cui abbiamo la possibilità di implementare come riferimento, testare e implementare aggiornamenti urgenti entro uno o due giorni se la gravità è tale, sebbene sia stata utilizzata solo 2/3 volte negli ultimi 4 anni circa.

Questo duplice approccio garantisce che i nostri server siano ragionevolmente, ma non stupidamente aggiornati, che gli aggiornamenti siano guidati da esperti in materia (ovvero firmware, driver, sistema operativo, personale dell'app) non fornitori, ma che consenta anche soluzioni rapide se necessario. Ovviamente siamo fortunati ad avere pochissimi modelli hardware diversi in tutta l'azienda (<10 server vari) e piattaforme di riferimento considerevoli e aggiornate per testare.

Ho lavorato in diverse aziende che avevano politiche in tutto il continuum da "applicare patch al più presto, non ci importa se rompono qualcosa che stiamo lavorando - le faremo indietro" "a" nulla "verrà applicato senza due settimane di test ". Entrambi gli estremi (e i punti intermedi) vanno bene purché la Società comprenda i compromessi .

Questo è il punto importante: non esiste una risposta particolare giusta o sbagliata a questa domanda; è una questione di bilanciamento tra stabilità e sicurezza o caratteristiche nel tuo particolare ambiente . Se la tua catena di gestione comprende che ritardare le patch per i test potrebbe renderle più vulnerabili al malware, va bene. Allo stesso modo, se comprendono che l'applicazione di patch non appena sono disponibili potrebbe non funzionare o addirittura interrompere la configurazione del proprio sistema, va bene. Esistono problemi quando questi compromessi non sono compresi.

La mia opinione è che il corso migliore sia praticamente nel bel mezzo dei tuoi due estremi. ad esempio, perché desideri disperatamente aggiornare ESX se non ci sono ragioni dimostrabili per farlo, probabilmente rompendo i sistemi di lavoro nel processo? Sicuramente potrebbe essere vulnerabile se fosse di fronte al pubblico, ma non dovrebbe esserci modo di accedervi direttamente dall'esterno della tua rete, quindi dov'è il rischio? Ci sono bug o mancanza di funzionalità che ti stanno effettivamente presentando un motivo per l'aggiornamento?

Aggiornamento per il gusto di farlo, che è davvero quello che si sta proponendo ( "ma si potrebbe sperimentare presto"), anche con la pretesa non sei, è una strada assurdo e pericoloso viaggiare. A meno che tu non possa presentare un motivo reale , al contrario di un motivo teoricamente possibile, non convincerai mai gli altri se si oppongono all'aggiornamento.

Se ritieni che ci sia una vera ragione per eseguire un aggiornamento, dovresti documentare sia i pro che i contro, e ci sono sempre dei contro e presentarli a quelli più in alto nella struttura. Documentato correttamente dovrebbe esserci poca resistenza. Se non riesci a fornire un argomento convincente, siediti e rifletti sul fatto.

modificare

Ho pensato di chiarire che vedo una grande differenza tra l'applicazione delle patch di sicurezza e stabilità richieste rispetto all'esecuzione di aggiornamenti del software o del sistema operativo. Il primo che implemento dopo test adeguati. Quest'ultimo lo faccio solo se c'è un vero vantaggio.

Gli aggiornamenti di sicurezza vengono inviati a un server di gestione temporanea, quindi produzione dopo aver dimostrato di non far saltare in aria le cose. A meno che non ci sia un vero e proprio segnale acustico di emergenza ING (che ho colpito un paio di volte :(), nel qual caso PRODUZIONE ORA. Altri aggiornamenti solo come richiesto, dopo aver trascorso il tempo di messa in scena.

Penso che la prima cosa da fare sia "classificare" gli aggiornamenti in base alla gravità e disporre di una pianificazione delle patch basata sulla classificazione. Non c'è dubbio che le correzioni di sicurezza zero-day debbano essere applicate immediatamente; mentre il Service Pack può attendere dopo attente valutazioni.