Bom dia pessoal, tudo bem?
Recentemente estou realizando um trabalho sobre gerenciamento de patching em uma estrutura convergente, onde temos camada de storage, virtualização, network, enfim, tudo dentro de uma caixa. Mais para frente em um novo post vou abordar essa parte de infraestrutura convergente.
Percebi o quanto muitas organizações não têm um processo bem definido quanto a isso, ou muitas vezes não possuem este processo desenhado, implementado e acabam tendo que resolver algum problema com alguma atualização para correção quando um ambiente foi invadido, danificado por algum bug e em sua maioria gerando um estresse que poderia ser evitado.
Pesquisando um pouco e tentando adequar a organização, elaborei um pequeno guia que pode servir para você implementar na sua companhia ou nos seus clientes.
Vamos primeiro colocar uma definição para: "O que é patch?"
- É uma correção a ser feita em um componente seja ele de hardware ou software com a instrução do fabricante/fornecedor.
Abaixo temos os tipos de patching:
Funcionalidade: Corrigi um problema funcional, bug fix.
Recursos: Introduz um novo recurso dentro de um software ou hardware.
Segurança: Correção para vulnerabilidades identificadas.
Existe no mercado duas normas quanto ao controle de patching que vale a pena reservar um tempo e dar uma lida.
Normas de controle de patching:
- ISO/IEC 27002
- NIST SP 800-40 v. 2.0
Como parte do processo para o gerenciamento de patching, separei estes em 8 fases:
Vamos agora ver um pouco de cada fase.
1 - Coleta de informações
- Inventário dos hosts / ativos;
- Pesquisa de patches e vulnerabilidades;
- Pesquisa de exploits* e ameaças;
* É um pedaço de software, maça de dados ou sequência de comandos que ganham vantagem de uma falha, defeito ou vulnerabilidade de um recurso de software ou hardware, fazendo com que esse trabalhe de forma imprevista, seja dando o controle para tal exploit, elevando permissões e funções que não são as designadas para que o software/hardware não funcione corretamente.
2 - Análise de risco
- Patch e ameaças de segurança;
- Patch e impactos de segurança;
- Análise de risco;
3 - Estratégia para implementação
- Definir agendamento de patches;
- Minimizar mudanças;
4 - Testes (caso seja necessário)
- Espelhar ambiente de produção em ambiente de teste;
- Validar se um patch é autentico, dependência ou requisitos, se a vulnerabilidade será contornada/corrigida, conflitos com outras aplicações;
- Testes de instalação do patch;
- Testes de desinstalação do patch;
5 - Planejamento de mudança
- Proposta da mudança;
- Planos de contingência e desinstalação; (Rotinas de backup e backups pontuais).
- Mitigação dos riscos;
- Monitoramento dos patches;
6 - Implementação de patches e instalação
- Nos casos que for possível, fazer a automatização da aplicação do patch;
- Mecanismo seguro para distribuição do patch;
7 - Relatórios
- Verificar se os patches foram instalados;
- Seguir um plano de contingência caso o patch tenha apresentado problemas;
- Gerar métricas;
- Documentar o progresso;
8 - Manutenção
- Analisar a políticas e aperfeiçoar o processo;
- Treinamento de equipes quanto a ferramenta e processo;
Falando agora de uma forma um pouco mais abrangente de um processo como o todo. Inicialmente é importa que exista uma ferramenta interna ou uma empresa terceira que possa e consiga fazer um scan na sua rede para poder gerar um relatório dos hosts que possuem algum componente que precisa ser corrigido, medir o grau de serveridade dessa vulnerabilidade e junto determinar o tempo que este tem para ser corrigido.
Como um exemplo de ferramenta que faz isso hoje, posso citar o Qualys. Você cadastra uma rede, ou uma VLAN ou mesmo Ips dos seus hosts tendo a possibilidade de criar um POOL e executar um scan onde um relatório será emitido em PDF com a informação do host, o grau de serveridade da vulnerabilidade, qual a vulnerabilidade e o patch necessário para corrigir.
Depois disso, cabe a quem administra fazer o processo de correção através de uma ferramenta para aplicar os patchs como WSUS para Microsoft e Satellite para Red Hat.
Podendo definir a severidade da vulnerabilidade entre 1, 2, 3, 4 e 5, podemos definir o prazo da seguinte forma:
1 - Baixa
2 - Média
3 - Alta
4 - Crítica
5 - Urgente
- 1 correção em 90 dias;
- 2-3 correção em 60 dias;
- 4-5 correção em 30 dias;
É importande entender que durante todo este processo, os patches que devem ser aplicados devem ser os oficiais liberados por cada fabricante. Este por sua vez já vai estar homologado, testado e confiável para o ambiente sem gerar maiores problemas.
Existe os mais conservadores que ainda preferem testar estes patches em laboratórios, porém isso requer um estrutura montada e nem sempre sendo fiél ao ambiente real produtivo que irá receber, então caso você não disponha de recursos para ter um lab com esse porte, vale algumas dicas:
- Se o ambiente a ser corrigido for um cluster de 2 nós, deixar um nó como ativo e fazer no nó de stand-by;
- Se o ambiente for um servidor Linux com Apache, verificar se tal patch não impacta em determinada versão do SO ou do Apache. Neste caso pode ser necessário fazer um upgrade de versão para compatibilidade;
- Executar os upgrades em números reduzidos de recursos, separando por exemplo, como patches para SO, depois patches para Apache, etc. Seprar por camadas.
Muito mais importante que tudo isso, garantir um backup integro e completo do ambiente. Incluir backup de SO e de aplicações.
Para quem utiliza recursos virtualizados, pode ser utilizado snapshot. Para os testes do patch pode ser feito até um clone de uma máquina para teste, conforme falamos um pouco àcima.
A quem goste de fazer todo esse controle por planilhas, colocando diversas informações dos hosts, versão atual de patch, controle, etc. Na minha opinião é válido sim você ter uma planilha de controle, mas não com essa profundidade de informações, primeiro por que é um trabalho muito manual e que pode causar confusões e erros de preenchimento (para não falar arcaico) e podemos pensar em ferramentas para fazer isso. Que seja o próprio controle dos relatórios em um sistema controlando isto por data, versão e transformá-lo em um portal.
Quero lembrar de que tudo foi dito não é a via de regra, e isso pode ser alterado de acordo com o que atende a sua organização, sua regra de negócio, seu cliente específico, etc.
Espero ter ajudado um pouco no quisito processo da parte de patch e como podemos implementá-lo no ambiente que está sob nossa responsabilidade.
Abraço e bom dia à todos!
Recentemente estou realizando um trabalho sobre gerenciamento de patching em uma estrutura convergente, onde temos camada de storage, virtualização, network, enfim, tudo dentro de uma caixa. Mais para frente em um novo post vou abordar essa parte de infraestrutura convergente.
Percebi o quanto muitas organizações não têm um processo bem definido quanto a isso, ou muitas vezes não possuem este processo desenhado, implementado e acabam tendo que resolver algum problema com alguma atualização para correção quando um ambiente foi invadido, danificado por algum bug e em sua maioria gerando um estresse que poderia ser evitado.
Pesquisando um pouco e tentando adequar a organização, elaborei um pequeno guia que pode servir para você implementar na sua companhia ou nos seus clientes.
Vamos primeiro colocar uma definição para: "O que é patch?"
- É uma correção a ser feita em um componente seja ele de hardware ou software com a instrução do fabricante/fornecedor.
Abaixo temos os tipos de patching:
Funcionalidade: Corrigi um problema funcional, bug fix.
Recursos: Introduz um novo recurso dentro de um software ou hardware.
Segurança: Correção para vulnerabilidades identificadas.
Existe no mercado duas normas quanto ao controle de patching que vale a pena reservar um tempo e dar uma lida.
Normas de controle de patching:
- ISO/IEC 27002
- NIST SP 800-40 v. 2.0
Como parte do processo para o gerenciamento de patching, separei estes em 8 fases:
- Coleta de informações;
- Análise de risco;
- Agendamento e estratégia de implementação;
- Testes;
- Planejamento e gerência de mudanças;
- Implementação de patches e instalação;
- Verificação de relatórios;
- Manutenção;
Vamos agora ver um pouco de cada fase.
1 - Coleta de informações
- Inventário dos hosts / ativos;
- Pesquisa de patches e vulnerabilidades;
- Pesquisa de exploits* e ameaças;
* É um pedaço de software, maça de dados ou sequência de comandos que ganham vantagem de uma falha, defeito ou vulnerabilidade de um recurso de software ou hardware, fazendo com que esse trabalhe de forma imprevista, seja dando o controle para tal exploit, elevando permissões e funções que não são as designadas para que o software/hardware não funcione corretamente.
2 - Análise de risco
- Patch e ameaças de segurança;
- Patch e impactos de segurança;
- Análise de risco;
3 - Estratégia para implementação
- Definir agendamento de patches;
- Minimizar mudanças;
4 - Testes (caso seja necessário)
- Espelhar ambiente de produção em ambiente de teste;
- Validar se um patch é autentico, dependência ou requisitos, se a vulnerabilidade será contornada/corrigida, conflitos com outras aplicações;
- Testes de instalação do patch;
- Testes de desinstalação do patch;
5 - Planejamento de mudança
- Proposta da mudança;
- Planos de contingência e desinstalação; (Rotinas de backup e backups pontuais).
- Mitigação dos riscos;
- Monitoramento dos patches;
6 - Implementação de patches e instalação
- Nos casos que for possível, fazer a automatização da aplicação do patch;
- Mecanismo seguro para distribuição do patch;
7 - Relatórios
- Verificar se os patches foram instalados;
- Seguir um plano de contingência caso o patch tenha apresentado problemas;
- Gerar métricas;
- Documentar o progresso;
8 - Manutenção
- Analisar a políticas e aperfeiçoar o processo;
- Treinamento de equipes quanto a ferramenta e processo;
Falando agora de uma forma um pouco mais abrangente de um processo como o todo. Inicialmente é importa que exista uma ferramenta interna ou uma empresa terceira que possa e consiga fazer um scan na sua rede para poder gerar um relatório dos hosts que possuem algum componente que precisa ser corrigido, medir o grau de serveridade dessa vulnerabilidade e junto determinar o tempo que este tem para ser corrigido.
Como um exemplo de ferramenta que faz isso hoje, posso citar o Qualys. Você cadastra uma rede, ou uma VLAN ou mesmo Ips dos seus hosts tendo a possibilidade de criar um POOL e executar um scan onde um relatório será emitido em PDF com a informação do host, o grau de serveridade da vulnerabilidade, qual a vulnerabilidade e o patch necessário para corrigir.
Depois disso, cabe a quem administra fazer o processo de correção através de uma ferramenta para aplicar os patchs como WSUS para Microsoft e Satellite para Red Hat.
Podendo definir a severidade da vulnerabilidade entre 1, 2, 3, 4 e 5, podemos definir o prazo da seguinte forma:
1 - Baixa
2 - Média
3 - Alta
4 - Crítica
5 - Urgente
- 1 correção em 90 dias;
- 2-3 correção em 60 dias;
- 4-5 correção em 30 dias;
É importande entender que durante todo este processo, os patches que devem ser aplicados devem ser os oficiais liberados por cada fabricante. Este por sua vez já vai estar homologado, testado e confiável para o ambiente sem gerar maiores problemas.
Existe os mais conservadores que ainda preferem testar estes patches em laboratórios, porém isso requer um estrutura montada e nem sempre sendo fiél ao ambiente real produtivo que irá receber, então caso você não disponha de recursos para ter um lab com esse porte, vale algumas dicas:
- Se o ambiente a ser corrigido for um cluster de 2 nós, deixar um nó como ativo e fazer no nó de stand-by;
- Se o ambiente for um servidor Linux com Apache, verificar se tal patch não impacta em determinada versão do SO ou do Apache. Neste caso pode ser necessário fazer um upgrade de versão para compatibilidade;
- Executar os upgrades em números reduzidos de recursos, separando por exemplo, como patches para SO, depois patches para Apache, etc. Seprar por camadas.
Muito mais importante que tudo isso, garantir um backup integro e completo do ambiente. Incluir backup de SO e de aplicações.
Para quem utiliza recursos virtualizados, pode ser utilizado snapshot. Para os testes do patch pode ser feito até um clone de uma máquina para teste, conforme falamos um pouco àcima.
A quem goste de fazer todo esse controle por planilhas, colocando diversas informações dos hosts, versão atual de patch, controle, etc. Na minha opinião é válido sim você ter uma planilha de controle, mas não com essa profundidade de informações, primeiro por que é um trabalho muito manual e que pode causar confusões e erros de preenchimento (para não falar arcaico) e podemos pensar em ferramentas para fazer isso. Que seja o próprio controle dos relatórios em um sistema controlando isto por data, versão e transformá-lo em um portal.
Quero lembrar de que tudo foi dito não é a via de regra, e isso pode ser alterado de acordo com o que atende a sua organização, sua regra de negócio, seu cliente específico, etc.
Espero ter ajudado um pouco no quisito processo da parte de patch e como podemos implementá-lo no ambiente que está sob nossa responsabilidade.
Abraço e bom dia à todos!
Nenhum comentário:
Postar um comentário