Gerenciamento de correções e SLAs

A priorização informa o que deve ser corrigido; o gerenciamento de correções é o processo disciplinado que efetivamente conduz essas correções até a conclusão, no prazo e em todo o ambiente.

SLAs (acordos de nível de serviço) definem em quanto tempo diferentes níveis de gravidade devem ser corrigidos. Sem eles, as correções urgentes atrasam e a responsabilidade desaparece.

Um ciclo repetível mantém os sistemas atualizados:

• Identifique as correções disponíveis (avisos de fornecedores, resultados de varreduras).
• Avalie a relevância e o risco da aplicação.
• Teste em um ambiente que não seja de produção.
• Implante em ondas controladas.
• Verifique se a correção foi aplicada e se o sistema está íntegro.

Cada etapa tem responsáveis e evidências, refletindo o ciclo de vida mais amplo de VM.

Um SLA transforma uma intenção em um prazo. Ele define o tempo máximo permitido entre a descoberta e a correção, de acordo com a gravidade. Exemplos de metas:

• Crítica / KEV: 7 a 15 dias (ou menos para ativos expostos à internet).
• Alta: 30 dias.
• Média: 90 dias.
• Baixa: melhor esforço / próximo ciclo.

Os SLAs tornam mensurável o tempo em aberto e criam pressão para concluir as correções, não apenas reconhecê-las.

Vincule o prazo ao risco real, não apenas ao CVSS. Uma vulnerabilidade crítica listada no KEV ou exposta à internet deve ter um SLA mais rigoroso que uma vulnerabilidade média em um ambiente interno.

Estruturas de referência ajudam: a CISA exige que itens do KEV sejam corrigidos dentro de prazos definidos para órgãos federais, e muitas empresas adotam prazos acelerados semelhantes para vulnerabilidades exploradas ativamente, independentemente do CVSS.

As correções podem causar problemas. Os testes em homologação identificam regressões antes que elas atinjam a produção:

• Aplique primeiro a um grupo de teste representativo.
• Valide as funcionalidades críticas e o desempenho.
• Confirme que não há conflitos com os softwares existentes.

Equilibre velocidade e segurança: para uma vulnerabilidade do KEV explorada no mundo real, aceite mais riscos e aplique a correção mais rapidamente do que em uma atualização rotineira.

Implante em ondas (implantação em anéis): grupo piloto, depois anéis mais amplos e, por fim, todo o ambiente. Monitore a integridade em cada anel antes de avançar.

Tenha sempre um plano de reversão: instantâneos, rebaixamento do pacote ou restauração da configuração. Se uma correção causar uma interrupção, você deverá conseguir revertê-la rapidamente enquanto investiga.

A aplicação manual de correções não é escalável. Use ferramentas centralizadas:

• WSUS / SCCM / Intune para Windows.
• Gerenciamento de configuração (Ansible, Puppet, Chef) para parques Linux.
• Imagens de referência reconstruídas com correções para a nuvem e os contêineres.

A automação impõe consistência e reduz o intervalo entre o lançamento de uma correção e sua implantação.

Às vezes, não é possível aplicar uma correção imediatamente: pode haver atraso do fornecedor, um sistema legado frágil ou necessidade de disponibilidade contínua. Aplique controles compensatórios para reduzir o risco nesse meio-tempo:

• Segmentação de rede / regras de filtragem de tráfego.
• Aplicação virtual de correções por meio de assinaturas do WAF ou IPS.
• Desativação do recurso ou serviço vulnerável.

Essas medidas ganham tempo, mas não substituem permanentemente a correção real.

Sistemas no fim da vida útil podem não ter nenhuma correção disponível. Opções:

• Isóle-os em um segmento de rede restrito.
• Proteja-os com controles de acesso rigorosos e monitoramento.
• Planeje a migração ou desativação com um prazo definido.
• Aceite formalmente o risco residual com uma data de expiração.

Documente tudo; um sistema sem possibilidade de correção e não documentado representa um risco de auditoria e de violação.

Acompanhe se o programa realmente cumpre seus compromissos:

• MTTR por gravidade em comparação com a meta do SLA.
• Taxa de conformidade com o SLA (percentual encerrado dentro do prazo).
• Achados vencidos / por tempo em aberto por equipe e ativo.
• Cobertura de correções (percentual do parque atualizado).

Apresente os dados por equipe responsável para que a responsabilidade seja visível e as áreas mais lentas recebam atenção.

Após a implantação, verifique: faça uma nova varredura para confirmar que a CVE não está mais presente e que o sistema está íntegro; depois, encerre o achado com evidências. Encaminhe problemas recorrentes (uma biblioteca que continua reaparecendo, uma equipe cronicamente atrasada) para a melhoria do processo.

Um gerenciamento de correções bem executado transforma o risco priorizado em redução de risco mensurável e dentro do prazo.

Confirme a função dos SLAs de correção.

O gerenciamento de correções conduz os achados priorizados até a conclusão por meio de identificação, avaliação, teste, implantação em etapas e verificação, apoiados por planos de reversão e automação. Os SLAs definem prazos classificados por gravidade e risco (mais rigorosos para KEV e ativos expostos à internet) para que as correções sejam aplicadas no prazo.

Quando a aplicação de correções é impossível, use controles compensatórios e aceite de risco documentado e com prazo definido. Meça o MTTR, a conformidade com os SLAs e a cobertura, e incorpore as lições ao ciclo de vida.