Atualizar ou não atualizar?

Desde que comecei a trabalhar onde estou trabalhando agora, estou em uma luta sem fim com meu chefe e colegas de trabalho em relação à atualização de sistemas.

É claro que concordo totalmente que qualquer atualização (seja firmware, sistema operacional ou aplicativo) não deve ser aplicada descuidadamente assim que for lançada , mas também acredito firmemente que deve haver pelo menos algum motivo se o fornecedor a liberar; e o motivo mais comum é geralmente consertar algum bug ... que talvez você não esteja enfrentando agora, mas poderá ocorrer em breve se não acompanhar.

Isto é especialmente verdade para correções de segurança; como exemplo, se alguém tivesse simplesmente aplicado um adesivo que já estava disponível há meses , o SQL Slammerverme infame teria sido inofensivo.

Sou a favor de testar e avaliar atualizações antes de implantá-las; mas eu discordo totalmente da abordagem "se não estiver quebrada, mas não a toque" no gerenciamento de sistemas, e isso realmente me machuca quando encontro os sistemas Windows 2003 SP1 ou ESX 3.5 Update 2 em produção, e a única resposta que posso obter é "está funcionando, não queremos quebrá-lo".

O que você pensa sobre isso?
Qual é a sua política?
E qual é a política da sua empresa , se não corresponder à sua?

E as atualizações de firmware (BIOS, armazenamento etc.)?
E as principais atualizações do SO (service packs)?
E as pequenas atualizações do sistema operacional?
E as atualizações de aplicativos?

É claro que meu principal interesse é atualizar servidores, pois o gerenciamento de patches do cliente geralmente é mais direto e existem ferramentas e práticas recomendadas conhecidas para lidar com isso.

Segurança e agilidade devem ser equilibradas em relação à estabilidade e ao tempo de atividade ao determinar sua estratégia de correção. Sua abordagem de retrocesso deve ser semelhante à de 'Ok, mas você precisa saber que agora corremos o risco de esses servidores ficarem comprometidos e terem nossos dados roubados ou os servidores ficarem inoperantes' e 'Ok, mas você precisa saber que isso afeta o suporte do fornecedor a esse sistema e a capacidade futura de interagir com novos sistemas'.

Contra a mentalidade de longo prazo 'não quebrou, não atualize', você deve deixar claro que:

• Migrar um sistema legado não corrigido que está muito atrasado para um sistema moderno é um processo muito mais caro e doloroso do que atualizar gradualmente esse sistema ao longo do tempo.
• Equipe de TI experiente e qualificada busca ativamente novas tecnologias e empresas que estão constantemente evoluindo seus sistemas de TI. Há um custo real em volume de negócios, perda de oportunidades e perda de conhecimento quando uma empresa perde sua equipe de TI criativa e altamente envolvida devido ao seu sistema estagnar e tornar-se desagradável de se trabalhar. Então tudo o que resta são os 'levantadores'.

Espero que isso dê a você alguma vantagem e boa sorte em convencer os outros a levar as coisas a sério. Como sempre, estabeleça uma trilha de papel que comprove que você avaliou o gerenciamento dos riscos que estão assumindo.

Este é um debate sem fim e pessoas razoáveis ​​discordarão. Se você está falando de PCs de usuários, concordo que eles precisam ser atualizados. Se você está falando de servidores, considere uma política separada para servidores que enfrentam a Internet e aqueles que não. Não conheço seus servidores, mas no meu ambiente, talvez 10% dos nossos servidores possuam portas abertas para a Internet. Esses servidores voltados para a Internet têm a maior prioridade quando se trata de patches de segurança. Servidores que não enfrentam a Internet são de menor prioridade.

Os gurus da segurança argumentam que essa abordagem é problemática porque, se um hacker entrar na sua rede, os servidores sem patches permitirão que as explorações se espalhem pela rede como um incêndio, e esse é um argumento razoável. Ainda assim, se você mantiver os servidores da Internet trancados com firmeza e configurar corretamente o firewall para abrir apenas as portas absolutamente necessárias, acho que essa abordagem funcionará e poderá ser usada com frequência para apaziguar os gerentes que têm medo de patches.

Se você está apenas confiando no Windows Update para correções (você não mencionou qual sistema operacional está executando, mas eu sou principalmente um cara do Windows, então esta é minha referência), dê uma olhada nos hotfixes reais lançados todos os meses . Eu tenho alguns servidores que, se eu executar o Windows Update neles, será informado que preciso de mais de 50 patches, mas se percorrer esses patches e pesquisar cada um deles, descobrirei que 90% dos itens que estão sendo patches não são de segurança relacionados, mas corrigem bugs que afetam os serviços que eu não corro nessa caixa. Em ambientes maiores em que você usa um sistema de gerenciamento de patches, é comum revisar tudo o que é lançado e se preocupar apenas com o que é absolutamente necessário e que geralmente equivale a cerca de 10% do que a Microsoft libera.

Meu argumento é que esse debate sobre "remendar ou não remendar" sugere que você precisa estar de um lado ou de outro quando, na verdade, essa é uma enorme área cinzenta.

Só posso falar sobre servidores, mas temos um regime de 'Atualização trimestral', em quatro datas pré-determinadas e anunciadas por ano, reunimos solicitações de atualização, aplicamos no nosso ambiente de referência, executamos por um mês para testar a estabilidade e, se for bom, durante os seguintes n dias / semanas. Além disso, aplicamos uma política de atualização de emergência na qual temos a capacidade de implantar em referência, testar e lançar atualizações urgentes dentro de um dia ou dois, se a gravidade for tal - embora isso tenha sido usado apenas 2/3 vezes na última 4 anos ou mais.

Essa abordagem dupla garante que nossos servidores estejam razoavelmente, mas não estupidamente, atualizados, que as atualizações sejam conduzidas por especialistas no assunto (por exemplo, firmware, drivers, sistema operacional, equipe de aplicativos), não fornecedores, mas que também permita correções rápidas se requeridos. É claro que temos sorte de ter muito poucos modelos de hardware diferentes em toda a empresa (<10 variantes de servidor) e plataformas de referência consideráveis ​​e atualizadas para testar.

Eu trabalhei em diferentes empresas que tinham políticas em todo o continuum de "aplicar patches o mais rápido possível, não nos importamos se eles quebrarem algo que estamos trabalhando - nós os apoiaremos então" para "nada será aplicado sem duas semanas de teste ". Ambos os extremos (e os pontos intermediários) são bons , desde que a Companhia compreenda as compensações .

Esse é o ponto importante: não há resposta específica certa ou errada para essa pergunta; é uma questão de equilibrar estabilidade versus segurança ou recursos em seu ambiente específico . Se sua cadeia de gerenciamento entende que atrasar os patches para teste pode torná-los mais vulneráveis ​​a malware, tudo bem. Da mesma forma, se eles entenderem que a aplicação de patches assim que estiverem disponíveis pode não funcionar ou até interromper sua configuração específica do sistema, isso também é bom. Existem problemas quando essas compensações não são compreendidas.

Minha opinião é que o melhor caminho é bem no meio dos seus dois extremos. Por exemplo, por que você deseja desesperadamente atualizar o ESX se não há motivo demonstrável para fazê-lo, possivelmente interrompendo os sistemas de trabalho no processo? Claro que pode ser vulnerável se for público, mas não deve haver maneira de acessá-lo diretamente de fora da sua rede. Então, onde está o risco? Existem bugs ou falta de recursos que realmente estão apresentando um motivo para você atualizar?

Atualizar por causa disso, que é realmente o que você está propondo ("mas você poderá experimentar em breve"), mesmo que afirme que não é, é um caminho absurdo e perigoso para se viajar. A menos que você possa apresentar um motivo real , em oposição a algum motivo teoricamente possível, nunca convencerá outros se eles se opuserem à atualização.

Se você acredita que existe um motivo real para realizar uma atualização, você deve documentar os prós e os contras, e sempre há contras, e apresentar isso para aqueles que estão no alto da árvore. Devidamente documentado, deve haver pouca resistência. Se você não pode fornecer um argumento convincente, sente-se e pense seriamente nesse fato.

Editar

Pensei em deixar claro que vejo uma grande diferença entre a aplicação dos patches de segurança e estabilidade necessários, em comparação com a realização de atualizações de software ou SO. O primeiro eu implemento após testes adequados. O último eu faço apenas se houver um benefício real.

As atualizações de segurança são enviadas para um servidor intermediário e, em seguida, a produção depois que elas mostram que não explodem. A menos que haja uma emergência de bip real (que eu já atingi algumas vezes :(), nesse caso PRODUÇÃO AGORA. Outras atualizações somente conforme necessário, depois de passar algum tempo na preparação.

Acho que a primeira coisa a fazer é "classificar" as atualizações por gravidade e ter um cronograma de patches com base na classificação. Não há dúvida de que as correções de segurança de dia zero devem ser aplicadas imediatamente; enquanto o Service Pack pode esperar após avaliações cuidadosas.