Para atualizar ou não atualizar?

Question

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

É claro que concordo totalmente que qualquer atualização (seja firmware, SO ou aplicativo) não deve ser aplicada de forma descuidada assim que for lançada, mas também acredito firmemente que deve haver pelo menos algum razão, se o fornecedor liberou; e o motivo mais comum é geralmente consertar algum bug ... o que talvez você não esteja experimentando agora, mas poderia estar experimentando em breve se você não acompanhar .

Isso é especialmente verdadeiro para correções de segurança; como um exame, se alguém tivesse simplesmente aplicado um patch que já estava disponível por meses , o verme SQL Slammer infame teria sido inofensivo.

Eu sou todo para testar e avaliar as atualizações antes de implantá-las; mas eu discordo strongmente da abordagem "se não estiver quebrada, então não a toque" ao gerenciamento de sistemas, e isso realmente me magoa quando encontro sistemas de produção Windows 2003 SP1 ou ESX 3.5 Update 2, e a única resposta que posso obter é "está funcionando, não queremos quebrá-lo".

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

E as atualizações de firmware (BIOS, armazenamento, etc.)?
E os principais O.S. atualizações (service packs)?
E quanto menor O.S. atualizações?
E quanto às atualizações de aplicativos?

Meu principal interesse é, claro, atualizar servidores, já que o gerenciamento de patches do cliente é geralmente mais simples e há ferramentas e práticas recomendadas para lidar com isso.

    

Answer 1

A segurança e a agilidade devem ser equilibradas em relação à estabilidade e ao tempo de atividade ao determinar sua estratégia de correção. Sua abordagem de push-back para isso deve ser na linha de 'Ok, mas você precisa saber que agora estamos em risco de esses servidores ficarem comprometidos e ter nossos dados roubados, ou ter os servidores tornados não funcionais' e 'Tudo bem, mas você precisa saber que isso afeta o suporte de nossos fornecedores para este sistema e a capacidade futura de ter este sistema interagindo com novos sistemas'.

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

• A migração de um sistema legado não corrigido que está muito atrasado para um sistema moderno é um processo muito mais caro e doloroso do que a atualização gradual do sistema ao longo do tempo.
• Profissionais de TI experientes e qualificados buscam ativamente novas tecnologias e empresas que estão constantemente evoluindo seus sistemas de TI. Há um custo muito real em termos de faturamento, perda de oportunidade e perda de conhecimento quando uma empresa perde sua equipe de TI altamente engajada e criativa, devido a seus sistemas se estagnarem e se tornarem desagradáveis de se trabalhar. Então tudo o que resta são os 'lifers'.

Espero que isso lhe dê alguma vantagem e boa sorte para convencer as pessoas a levar as coisas a sério. Como sempre, estabeleça um documento que comprove que você já informou sobre o gerenciamento dos riscos que está assumindo.

    

Answer 2

Este é um debate interminável e pessoas razoáveis discordarão. Se você está falando sobre PCs de usuários, eu concordo que eles precisam ser atualizados. Se você está falando sobre servidores, considere uma política separada para servidores que enfrentam a Internet e aqueles que não o fazem. Eu não sei sobre seus servidores, mas no meu ambiente, talvez 10% dos nossos servidores tenham portas abertas para a internet. Esses servidores voltados para a Internet têm 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 argumentarão que essa abordagem é problemática porque, se um hacker entrar na sua rede, os servidores não corrigidos permitirão que exploits percam a rede como um incêndio, e esse é um argumento razoável. Ainda assim, se você mantiver esses servidores voltados para a internet travados e configurar corretamente o seu firewall para abrir apenas as portas absolutamente necessárias, acho que essa abordagem funciona e pode ser usada para apaziguar gerentes que têm medo de patches.

Se você está confiando apenas no Windows Update para patches (você não mencionou qual SO está executando, mas eu sou principalmente um cara do Windows, então esta é a minha referência), dê uma olhada nos hotfixes reais que recebem lançado todos os meses. Eu tenho alguns servidores que se eu executar o Windows Update neles eu serei avisado que eu preciso de 50 + patches mas se eu rolar através desses patches e pesquisar cada um deles, eu vou descobrir que 90% dos itens sendo patches não são segurança relacionado, mas corrija erros que afetam os serviços que não são executados nessa caixa. Em ambientes maiores, nos quais você usa um sistema de gerenciamento de patches, é comum revisar tudo o que é lançado e apenas se preocupar com o absolutamente necessário, o que geralmente equivale a cerca de 10% do que a Microsoft lança.

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

    

Answer 3

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

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

    

Answer 4

Eu trabalhei em diferentes empresas que tinham políticas em todo o continuum de "aplicar correções o mais rápido possível, nós não nos importamos se eles quebram algo que temos trabalhando - vamos recapitá-los então" para "nada é aplicado sem duas semanas de testes ". Ambos os extremos (e pontos intermediários) são bons desde que a Empresa compreenda as compensações .

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

    

Answer 5

Minha opinião é que o melhor caminho é bem no meio de seus dois extremos. por exemplo. Por que você quer desesperadamente atualizar o ESX se não houver nenhuma razão demonstrável para isso, possivelmente quebrando os sistemas operacionais no processo? Claro que pode ser vulnerável se estiver voltado para o público, mas não deve ser acessado diretamente de fora da sua rede, então onde está o risco? Há algum bug ou falta de recursos que estão realmente apresentando a você uma razão para atualizar?

Atualizando para o efeito, que é realmente o que você está propondo ("mas você poderia estar experimentando em breve"), mesmo quando alegando que você não está é um caminho absurdo e perigoso para viajar. A menos que você possa apresentar uma razão real , ao contrário de alguma razão teoricamente possível, você nunca convencerá os outros se eles se opuserem à atualização.

Se você acredita que há uma razão real para realizar uma atualização, você deve documentar os prós e os contras, e há sempre contras, e apresentar isso para aqueles que estão na parte superior da árvore. Devidamente documentado, deve haver pouca resistência. Se você não puder fornecer um argumento convincente, então sente-se e dê a esse fato algum pensamento sério.

Editar

Pensei que deveria deixar claro que vejo uma grande diferença entre a aplicação dos patches de segurança e estabilidade exigidos em comparação à execução de softwares ou atualizações de sistema operacional. O primeiro eu implemento após o teste adequado. O último eu faço somente se houver um benefício real.

    

Answer 6

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

    

Answer 7

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