Política de Testes de Segurança de Informação
1. Objetivo
Esta Política estabelece as diretrizes e fases do processo de testes de segurança da informação de produtos de software e serviços, com base na abordagem da OWASP Software Assurance Maturity Model (SAMM). O foco é garantir a resiliência do software e projetos, incorporando testes de segurança, gestão eficiente e medição por meio de um processo bem definido.
Vale ressaltar que a adoção de metodologias de referência direciona e organiza as atividades de verificação da segurança de informação, visando garantir a resiliência do software e projetos, serviços relacionados não apenas por testes de segurança executados por terceiros, mas também a partir da gestão e medição de um processo de testes de segurança bem definido e planejado.
2. Abrangência
Aplica-se à área INFRA, TECH e SEC da MTM.
3. Responsabilidades
Papel
Responsabilidade
Domínio de Assunto/ Tecnologia
Líder Direto
Comitê de Segurança da Informação
Validação de resultados de testes de segurança, medindo o número de vulnerabilidades exploráveis descobertas em cada categoria de segurança.
Identificação de NC a serem tratadas, bem como verificação da eficácia dos planos de ação do tratamento.
Segurança da Informação
CEO
Líder de Tech, Infra e Sec
Arquitetura tecnológica, infraestrutura e segurança dos componentes da plataforma mobileX
Ambiente em nuvem da plataforma mobileX
COO
Especialista de SI
Papel responsável por zelar pela segurança de produto, projetos, serviços e ambientes operacionais gerenciados pela empresa
Práticas de SI.
Normas e modelos de referência.
Ambiente em nuvem da plataforma mobileX.
Líder de Tech, Infra e Sec
Líder de Projetos
Gestão do projeto em termos de escopo, prazo, qualidade e expectativas do cliente.
Plataforma mobileX
Gerente de Operações
Devs mobileX
Desenvolvimento de código-fonte padronizado, testado, revisado e inspecionado com relação a boas práticas de programação com segurança da informação.
Plataforma mobileX
Líder de Projeto
Líder de P&D
Definição de diretrizes para boas práticas de programação, controle de versão e segurança da informação
Ambiente e linguagens da Plataforma mobileX
COO
Especialista de P&D
Compilação, configuração e publicação dos Apps mobile.
Definição de boas práticas de programação segura para cada um dos componentes da plataforma mobileX.
Lojas Google/Apple
Plataforma mobileX
Líder de P&D
4. Diretrizes
Vulnerabilidade é uma falha de segurança explorável por atores mal-intencionados para causar danos aos recursos ou dados do sistema.
Explorabilidade é uma vulnerabilidade comprovadamente explorável, com caminho definido para realizar um ataque, demonstrando impacto de segurança.
Segurança é a comprovação da resiliência de um produto ou serviço sob pressão adversária. Medição para ajustar as ações de segurança com foco em requisitos funcionais.
Categorias de Segurança representam as vias de ataque e são essenciais para guiar testes de segurança, abrangendo a proteção de credenciais, ativos, validação de inputs, controle de acesso, atualização e compreensão dos adversários. São elas:
Principais Categorias de Segurança
Descrição
Manter o confidencial protegido
Evitar a exposição de credenciais de autenticação digital, incluindo senhas, chaves, APIs e tokens.
Proteger ativos
Estabelecer definições, configurações e registros dos ativos.
Validar os inputs
Restringir o código ou comando que pode ser inserido para evitar comportamentos não planejados.
Questões de acesso
Implementar controles eficazes de gerenciamento de identidade e autenticação para ajudar a garantir o acesso apropriado aos recursos por função ou sistema.
Atualizar e Corrigir dependências
Manter produtos atualizados com atualizações de segurança e realizar manutenção contínua.
Conhecer seus adversários
Compreender os motivos específicos e os pontos de vista de vários adversários ajuda a implementar contramedidas adequadas.
5. Tipos de Testes de Segurança (Pentests)
Teste de Penetração de Aplicações: Avaliação da segurança de aplicações, identificando vulnerabilidades exploráveis.
Teste de Penetração de Infraestrutura: Avaliação da segurança da infraestrutura, incluindo redes, servidores e dispositivos.
Teste de Penetração de API: Avaliação da segurança de APIs, garantindo a integridade e proteção dos dados transmitidos.
6. Metodologias de Referência
A principal metodologia de referência adotada é a OWASP Software Assurance Maturity Model (SAMM). Esta abordagem abrangente e repetível visa avaliar a segurança desde o desenvolvimento até a implantação.
Esta metodologia fornece um método abrangente e destinado a oferecer aos clientes uma maneira padronizada de avaliar a segurança dos produtos e serviços adquiridos com base no risco calculável e objetivo.
SAMM pode ser usada para orientar os testes em todos os estágios do ciclo de vida de desenvolvimento de software, desde o início até a implantação em produção. O objetivo final de medir a segurança é entender e ajustar a segurança como todos os outros requisitos funcionais.
Um dos objetivos desta metodologia é permitir uma mudança da dependência exclusiva de pen-tests de terceiros para a medição de segurança a partir de um processo de testes planejado, incluindo a dimensão segurança no escopo das responsabilidades dos times de produto e projetos.
A seguir as etapas da metodologia envolvendo ações de segurança prescritivas:
1. Identificar requisitos de segurança:
Definir uma lista de requisitos de segurança para cada componente do produto, projeto ou serviço com base nas políticas, processos e padrões de segurança definidos e documentados pela MTM.
2. Reunir casos de uso de segurança:
Definir alguns casos de uso para cada requisito de segurança. Esses casos de uso oferecem orientação personalizada aos times de produto e projeto para ajudá-los a implementar requisitos de segurança para funcionalidades específicas. Por exemplo, um caso de uso típico para desenvolvimento de APIs envolve informações sobre possíveis meios de exploração de APIs deste tipo e seus típicos métodos de ataque.
3. Enumerar soluções de segurança:
Para cada categoria de segurança, fornecer prontamente aos times de produto e projetos as soluções de segurança recomendadas ou preferenciais para atender a cada caso de uso de segurança.
4. Executar casos de teste:
Executar casos de teste e recursos integrados para testar o produto e serviço desenvolvido para cada caso de uso de segurança respectivo e demonstrar a sua resiliência. Os casos de teste são baseados em vetores de ataque adversários conhecidos e em pesquisas sobre o tema segurança de informação.
5. Medir efetividade:
Medir o número de vulnerabilidades exploráveis descobertas no produto em cada categoria de segurança.
6. Validar resultados do teste de segurança:
O resultado do teste de segurança da informação deve ser analisado criticamente por um comitê com autoridade e responsabilidades estabelecidas. A partir desta avaliação, Não Conformidades (NC) são identificadas e encaminhadas para tratamento sempre que produzirem um efeito sistêmico ou provocarem riscos pessoais e ou danos materiais.
Resultados de testes de segurança enviados por terceiros contratados por clientes da empresa também são avaliados pelo comitê mas com relação à sua aderência aos requisitos de segurança definidos como prioritários para a empresa. Quando aplicável, NCs podem ser identificadas e encaminhadas para tratamento.
Como resultado da análise crítica de NCs encontradas a partir de seus com efeitos concretos e visíveis ou potenciais, o especialista de SI deve planejar as ações corretivas ou preventivas, observando sempre adequar a ação à proporção do problema ou risco identificado. Ações corretivas devem ser propostas em tempo hábil, após a identificação da NC. Quando for necessária uma ação imediata, essa deve ser proposta assim que a NC for identificada, para que esta cause o mínimo de impacto possível.
Os responsáveis pelos itens do plano de ação devem registrar as evidências relativas à implantação de cada ação do plano, sendo que os resultados das ações executadas devem ser monitorados e medidos pelos envolvidos na ocorrência. As ações deverão ser verificadas de acordo com o prazo estabelecido, quanto a sua eficácia planejada. Após encerramento da NC, o resultado das ações e sua eficácia devem estar disponíveis para todas as partes interessadas.
7. Dar suporte a respostas de segurança:
Fornecer orientação e suporte aos times de produto e projeto para ajudá-los a corrigir as lacunas encontradas nos casos de teste para melhorar a resiliência do produto e reforçar a sua segurança. Após a correção da vulnerabilidade explorável, os casos de teste devem ser repetidos para verificar se a vulnerabilidade explorável foi de fato corrigida.
7. Insumos necessários
Checklists de definição a partir do modelo Security Knowledge Framework.
8. Referências
OWASP – Open Web Application Security Project. Disponível em: https://owasp.org/
Last updated
