Este artigo faz parte de uma série de publicações feitas com base no projeto SAMM da OWASP, caso tenha interesse em entender melhor, recomendo a leitura do artigo neste link. Dentro do domínio Operations, há a prática gestão de ambiente (Environment Management), onde temos dois fluxos que estão diretamente relacionados, Configuration Hardening e Patching and Updating. De acordo com o SAMM, a gestão de ambiente não termina quando a aplicação está em funcionamento, ou seja, está no “ar”. A gestão deve ser feita de forma contínua, e para que isso seja possível, deve-se ter atenção a patches, configurações e novos recursos, que são lançados regularmente.
Você também pode ouvir esse conteúdo:
Na construção de um ambiente seguro que suporte uma aplicação, há inúmeros recursos envolvidos, como: sistema operacional, serviços, frameworks, bibliotecas, etc., sem contar que o ambiente pode ser on-premises ou cloud. Isso acaba possibilitando uma variedade de combinações de tecnologias, que por sua vez geram ambientes ricos e distintos entre as diferentes empresas. Essa gama de ambientes, que são frutos de combinações de diferentes softwares, geram atualmente dificuldades quando o tema segurança vem à tona. Há uma necessidade de maior controle de atualizações, configurações mais robustas que garantam uma segurança efetiva, e consequentemente adoção de boas práticas.
Quando se pensa em gestão de ambientes, não se pode esquecer que as aplicações geralmente trabalham com uma determinada pilha (stack), ou seja, um conjunto de softwares/componentes utilizados pela aplicação, um exemplo de uma stack bastante comum é o LAMP (Linux, Apache, MySQL e PHP). É válido lembrar que embora esteja falando de aplicação, a infraestrutura onde a aplicação está hospedada também merece atenção em questões referentes à segurança. Para isso, o OWASP SAMM nos traz em gestão de ambientes, dois fluxos (Streams A e B), que falam respectivamente de Configuration Hardening e Patching and Updating. Em seguida é mencionado cada um dos fluxos e o que se espera em relação a sua maturidade dividido em três níveis, de forma gradativa. A partir dos níveis de maturidade é possível avaliar se o comportamento da equipe expressa maturidade na realização das atividades no setor.
Configuration Hardening (Fluxo A)
Hardening é o processo de reforçar a segurança dos sistemas, para isso é feito o mapeamento de possíveis ameaças para que a proteção dos sistemas possa ser aprimorada. Esta prática consiste em seguir recomendações com intuito de reduzir ou até eliminar as vulnerabilidades em softwares, hardwares, sistemas e infraestrutura em geral. Basicamente, através das boas práticas de configurações é possível deixar os sistemas mais robustos e resistentes a ataques, não deixando todo o sistema instalado “by default”. De acordo com o SAMM, estas são as atividades esperadas pelo seu respectivo nível de maturidade:
- Nível de maturidade 1: É importante proteger as stacks de tecnologia, com base nas orientações disponíveis, seja através de documentações de fornecedores ou até projetos de código aberto. Outra prática importante é o compartilhamento de conhecimento e experiência dentro das equipes, e a partir disso estabelecer padrões de configuração para as stacks utilizadas.
- Nível de maturidade 2: Estabelecer uma proteção base de configuração para todos os componentes em cada stack de tecnologia. É importante desenvolver guias de configuração para os componentes. E exigir que as equipes de produto apliquem configurações base a todos os novos sistemas e aos sistemas existentes. É importante ter um responsável pelos guias de configurações, deixando-os atualizados de acordo com a evolução das melhores práticas ou alterações de componentes.
- Nível de maturidade 3: É recomendado monitorar ativamente as configurações de segurança das stacks de tecnologias implantadas , realizando verificações regulares em relação às configurações bases estabelecidas. Garanta que os resultados das verificações de configuração estejam disponíveis por meio de relatórios. Ao detectar configurações não conformes, trate cada ocorrência como uma descoberta de segurança e gerencie ações corretivas. É importante revisar os processos de forma periódica, além de revisar as configurações base e os seus guias correspondentes. Através de medidas automatizadas, como configurações de “autocorreção” e informações de segurança e alertas de gerenciamento de eventos (SIEM) é possível ter ganhos adicionais.
Patching and Updating (Fluxo B)
O Patching é uma implementação de um programa de computador criado com intuito de corrigir falhas, também é possível atualizar e resolver problemas relacionados à segurança. Updating embora esteja relacionado a Patching, as atualizações não são necessariamente as falhas ligadas ao software, mas tudo que ele poderá ter dependência, além de estar relacionado às atualizações dos serviços utilizados no ambiente da aplicação. De acordo com o SAMM, estas são as atividades esperadas pelo seu respectivo nível de maturidade:
- Nível de maturidade 1: Identificar aplicativos e componentes de terceiros que precisam ser atualizados ou corrigidos, incluindo sistemas operacionais subjacentes, servidores de aplicações e bibliotecas de código de terceiros. É importante que as equipes compartilhem seu conhecimento sobre as atualizações disponíveis e suas experiências com patches. As equipes também devem ter ciência das versões de todos os componentes em uso, para avaliar se seus produtos são afetados por vulnerabilidades de segurança.
- Nível de maturidade 2: Desenvolver e seguir um processo bem definido para gerenciar patches para componentes das stacks das aplicações, e demais serviços de tecnologia. Certifique-se de que os processos incluam cronogramas regulares para a aplicação de atualizações do fornecedor. Crie orientações para priorizar a correção de componentes, refletindo sua tolerância a riscos e objetivos de gerenciamento. Considere os fatores operacionais ao determinar as prioridades para testar e aplicar os patches. No caso de receber um alerta de uma vulnerabilidade crítica em um componente, enquanto nenhum patch ainda estiver disponível, faça a triagem e trate a situação como um problema de gerenciamento de risco.
- Nível de maturidade 3: Desenvolva e use painéis ou relatórios de gerenciamento para rastrear a conformidade com processos de aplicação de patches e SLAs. Certifique-se de que o gerenciamento de dependências e os processos de empacotamento de aplicativos possam dar suporte à aplicação de patches em nível de componente a qualquer momento, atendendo os SLAs necessários. Utilize alertas e notificações de fornecedores para aprender sobre vulnerabilidades e patches associados, aproveite e monitore uma variedade de fontes externas de inteligência de ameaças para aprender sobre vulnerabilidades de zero day.
Conclusão
A segurança não se faz apenas com implementações dentro da própria aplicação, o ambiente pode ser um grande ponto vulnerável para atacantes, ainda mais se não for bem gerido. É válido lembrar que grande parte das tecnologias utilizadas na stack das aplicações às vezes não seguem boas práticas de segurança por padrão. Então é sempre válido procurar por guias de boas práticas de configuração, ou até validar com os fornecedores se possuem tal material. Há casos também onde alguns componentes possuem dependência de compatibilidade com versões anteriores, o que pode consequentemente impedir de atualizar determinados softwares ou até mesmo dependências dentro da aplicação.
Pode-se concluir que para garantir a operação, é necessário ter maior controle de atualizações, realizar configurações mais robustas que garantam a segurança, além de utilizar as experiências dos times para conseguir adotar boas práticas dentro do ambiente. Também é importante lembrar que as vulnerabilidades são descobertas ao longo dos ciclos de vida das tecnologias das quais sua organização depende, por isso torna-se essencial monitorar os relatórios de vulnerabilidade e executar correções de forma ordenada e oportuna em todo o sistema. Não devemos nos limitar a isso, conforme foi visto de acordo com o nível de maturidade de cada um dos fluxos, há muitos outros processos que precisam ser feitos, e que colaboram com a evolução da segurança do ambiente.
Série artigos SAMM
- Governança segundo SAMM: Estratégias e Métricas em Segurança de Aplicações
- Governança segundo SAMM: Políticas e Conformidades em Segurança de Aplicações
- Governança segundo SAMM: Educação e Orientação em Segurança de Aplicações
- Design segundo SAMM: Modelagem de Ameaças em Segurança de Aplicações
- Design segundo SAMM: Requisitos de Segurança em Segurança de Aplicações
- Design segundo SAMM: Arquitetura Segura em Segurança de Aplicações
- Implementação segundo SAMM: Build Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Deploy Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Gestão de Defeitos em Segurança de Aplicações
- Verificação segundo SAMM: Análise de Arquitetura em Segurança de Aplicações
- Verificação segundo SAMM: Testes Orientados a Requisitos em Segurança de Aplicações
- Verificação segundo SAMM: Testes de Segurança em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Incidentes em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Ambientes em Segurança de Aplicações
- Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações
