Questa è una domanda sullo stile di valutazione dei rischi e di modellazione delle minacce, piuttosto che un duro sì o no.
Vuoi accettare il rischio di non applicare patch al servizio, che potrebbe essere sfruttato in futuro - potrebbe essere qualcuno che lo eseguirà in seguito. O non accetti il rischio di aggiornare il tuo sistema operativo / software che potrebbe causare effetti negativi sui servizi in esecuzione.
Solo la tua situazione individuale sarà in grado di rispondere a queste e spesso ci saranno risposte diverse a seconda del panorama delle minacce e dell'importanza del server / dell'applicazione in cui stai valutando.
La risposta breve è "sì" per la maggior parte delle persone!
Questo perché è spesso difficile isolare le funzionalità oi servizi come si vorrebbe o è necessario, e richiede anche tempo per registrare e gestire codice o servizi non protetti che potrebbero essere usato in uno scenario futuro. Il patching di funzionalità o servizi inutilizzati evita il rischio di "dimenticare" o gestire in modo errato patch e aggiornamenti nell'architettura futura o nelle modifiche del caso d'uso.
Tuttavia, come sottolineato da ISMSDEV, la risposta più accurata è che dipende dalla valutazione del rischio. Tutti i lavori di riparazione come patch e aggiornamento devono essere gestiti come parte di un processo di gestione del rischio e questo è l'unico modo efficace per vincere nell'equazione rischio / costo / beneficio (a meno che non si disponga di risorse sec non ridotte!) Se si decide di non aggiornare patch quindi il minimo che dovresti fare è registrare la decisione, comprendere i rischi che ne derivano (come gestire le variazioni dei casi d'uso in futuro, ecc.) e rivalutare in base ai nuovi rischi introdotti dal non applicare patch e aggiornamenti.
Quindi, in breve, il processo di valutazione del rischio in corso dovrebbe rispondere a questa domanda per ciascun caso.
Entrambe le risposte elencate sono corrette. Di norma, anche se non viene utilizzato un servizio, l'applicazione di patch è comunque una buona idea in quanto aiuta a ridurre o eliminare una vulnerabilità. A meno che non ci si trovi in un ambiente strettamente regolamentato, è difficile affermare che "non usiamo quel servizio e non lo faremo mai". Le cose cambiano, e dovendo investigare se aggiornare o meno quel servizio, anche se dovrebbe essere parte di quel lancio, richiede tempo e potrebbe non essere fatto. Applicando automaticamente le patch, si evita di perdere quel passaggio e lo si aggiusta anche in caso accidentalmente o maliziosamente attivato.
Detto questo, la risposta di ISMSDEV è anche valida. Devo ancora lavorare per un'azienda che ha risorse illimitate. Siamo tutti occupati e mantenere i servizi inutilizzati richiede tempo lontano dal lavoro di produzione reale. Se ti trovi in un ambiente in cui è necessario mantenere stretti controlli sulle modifiche, l'applicazione di patch a un servizio non utilizzato richiederà uno sforzo per verificare che la modifica non influisca su qualcos'altro. Ciò causa costi e ritardi nella convalida di qualcosa che non viene utilizzato, che potrebbe essere considerato uno spreco di denaro a meno che non sia possibile dimostrare un ritorno su tali spese.
Da dove viene questa risposta? La domanda non ha affrontato questa domanda più ampia: che tipo di ambiente? Se si tratta di un mucchio di desktop aziendali, la risposta è molto probabilmente "sì". Se si tratta di server, dispositivi di produzione o altri dispositivi in cui le condizioni e l'affidabilità sono critiche, potrebbe essere più sensato gestirle di più.
Leggi altre domande sui tag vulnerability patching known-vulnerabilities incident-response vulnerability-management