A Ciência da Criação de Patches de Segurança

Uma das melhores coisas do meu trabalho é que eu estou constantemente trabalhando com clientes. Nadamelhor do que estar com gente que usa os nossos produtos no dia a dia para aprender e obter feedback sobre como a Microsoft deveria agir e como poderíamos fazer melhor o nosso trabalho. Mais especificamente sobre o nosso processo de divulgação de correções de segurança, este feedback que eu recebo de clientes invariavelmente é:

1. "O patch não pode afetar negativamente as minhas aplicações e os meus serviços."

2. "Quanto menos patches melhor. Especialmente menos patches que precisem de reboot."

3. "Quero saber quando vocês vão divulgar patches de segurança. Eu preciso estar preparado."

Mas "Não quero que os meus sistemas estejam desprotegidos contra uma vulnerabilidade conhecida".

O problema é que estes são requisitos intrinsicamente conflitantes entre si. Por exemplo, a única forma de evitar que uma correção cause problemas em outras aplicações é testar exaustivamente o patch. Em uma correção no Windows como a MS07-017 a Microsoft testa não só todas as suas próprias aplicações como também as outras principais aplicações no mercado, inclusive as de código aberto. Caso um problema seja encontrado o patch tem que ser alterado para contornar este problema, ou uma correção adicional tem que ser preparada, ou o fabricante é contactado para fazer uma alteração no seu produto. E o teste recomeça de novo, do zero. Em um certo ponto o patch MS07-017 tinha 80 potenciais problemas identificados.

Para diminuir o número de patches a Microsoft procura agregar se possível a correção de diversas vulnerabilidades em um único patch. Distribuir um patch custa dinheiro não só para a Microsoft mas principalmente para os clientes. O CSO de uma grande indústria automobilística uma vez nos disse que cada patch do Windows custava para ele 200 mil dólares em pessoal, softwares de distribuição e teste e em downtime. O patch MS07-017 corrige 6 outras vulnerabilidades além do problema nos cursores animados, e das correções estarem agregadas provavelmente economizou um milhão de dólares só neste cliente.

Ao corrigir uma vulnerabilidade a Microsoft também verifica se o mesmo problema aparece em outras partes do código do produto, e mesmo em outras partes do código de outros produtos. Nada pior do que um patch não corrigir totalmente o problema e um novo outro patch ter que ser instalado.

Por fim, um feedback praticamente unânime foi tornar o processo previsível. Ao fixar a data de divulgação na segunda terça-feira de cada mês, a Microsoft permite que as empresas aloquem recursos, preparem laboratório para testes, estabeleçam janelas de manutenção, etc. para otimizar o seu próprio processo de gerência de patches. Na verdade eu não conheço um único cliente que queira voltar para a situação anterior, onde o patch era divulgado no dia e horário em que ficava pronto.

Testar exaustivamente um patch, agregá-los várias vulnerabilidades em uma única correção, esperar o dia certo para a divulgação, tudo isto demora tempo e joga contra o desejo de ter a correção o mais rápido possível. A Microsoft tem que achar um ponto de equilíbrio entre prioridades que conflitam entre si, e tomar decisões que nem sempre vão agradar a todos. O MSRC procura adotar as seguintes diretivas:

¦ Nenhum patch vai ser divulgado sem passar pelo conjunto de testes de qualidade.

¦ O patch vai ser divulgado fora do seu ciclo normal se clientes estiverem em risco imediato de um ataque.

No caso da vulnerabilidade de cursores animados, ela foi reportada para a Microsoft no final de Dezembro, e a correção em si do problema é normalmente a coisa mais rápida de todo o processo. Em seguida a correção foi empacotado em um patch com outras vulnerabilidades que afetavam a win32k.sys e user32.dll, testado exaustivamente, e estava pronto para ser lançado no próximo dia 10 de Abril. Como a vulnerabilidade foi descoberta de forma independente e estava sendo ativamente explorada, a divulgação foi antecipada para o ontem (3/4).

A falha da Microsoft, é claro, foi deixar que a vulnerabilidade existisse no seu produto. Aqui no nosso processo SDL falhou, e é uma oportunidade para aprender e melhorar o processo. Mas no processo de lançamento de patches acho que a empresa agiu corretamente. Algumas pessoas acham um absurdo um problema reportado em Dezembro ser corrigido somente em Abril - mais eu acho que mais importante do que isso é ter um patch de qualidade, e se a vulnerabilidade não está sendo explorada publicamente existe tempo para tentar garantir isso. A EEye por exemplo fez um patch em tempo recorde, mas o depois se confirmou que ele não resolvia o problema (havia um vetor de ataque que não fora corrigido). A Microsoft não pode correr o risco de divulgar uma correção que não resolva o problema ou que destrua uma aplicação popular, e para isso é necessário tempo.