Security updates need to become a part of daily IT. Waiting for batches of updates amplifies the chance of an issue when getting applied. Set yourself up for success by creating an environment where you know exactly how to quickly roll back from an update. Don't think only of we have backups, think about having a good continuity of operations plan, of which backups are a part. Running VMs, snapshot before the update window, verify success, consolidate snapshots. Dealing with workstations, deploy in waves, using no more than 1/2 a department in any wave. Have a machine that is 100% critical & needs 100% uptime - rethink why that even exists. Updates should not be a stumbling block for anyone if we prep our environments and selves.

Na minha experiência com GRC Gestão de segurança e Privacidade tenho percebido que apesar da necessidade de estar sempre com as atualizações em dia, um Delay de uns poucos dias dificilmente irá te afetar (Salvo alguns temas esporádicos). É imprescindível que as atualizações não sejam automáticas para toda a organização. É extremamente necessário atualizar primeiramente um pequeno parque de testes de uma semana ao menos, antes de disparar para os demais ativos da empresa. Diferente do que o "Medeiros acha", é primordial realizar testes exaustivos e programar bem a mudança com aprovação em comitê (Tema, riscos, impacto, áreas, data e hora....) com as áreas envolvidas antes de atualizar o parque geral para impactar positivamente as operações.

Dentro de um trabalho de Gestão de Vulnerabilidades, a sinergia entre TI e SI é essencial. O time de SI, através do processo e solução de GV, deve classificar os ativos e as vulnerabilidades por criticidade e extrair o relatório a ser enviado para TI, que por sua vez deve ter um processo de mitigação definido, avaliando o relatório, e dentro da prática de gestão de mudanças, planejar o ciclo de mitigação das vulnerabilidades.

Automation is always wonderful, but a key people tend to forget is testing within a Development environment! When pushing patches out, a plethora of things could go wrong. Testing them is always key so when you do push to Production, everything is smoother and downtime is a low as possible. Hitting the smaller patches will always help out metrics as there tends to be more of them, but when aiming to lower a risk score: push to remediate the bigger hitters. Analyse which assets are priority and have more sever vulnerabilities.

Automation and redundancy are key here! If its so essential that it cannot be down for updates, then some form of cluster is a must with your redundancy getting a test when updates are done. Automation will deal with everything else out of hours to keep them up to date.