A segurança de software envolve muitas atividades e preocupações diferentes. Sem uma estratégia clara, você pode estar gastando muito esforço para aumentar a segurança, enquanto na verdade seus esforços podem ser desalinhados, desproporcionais ou até contraproducentes. O objetivo da prática de Estratégia e Métricas (SM) é criar um plano eficiente e eficaz para atingir seus objetivos de segurança de software em sua organização.
Você pode ouvir também a versão em áudio deste artigo:
Como diz o nosso slogan na Conviso, segurança de software precisa acontecer na velocidade do seu negócio. Uma abordagem que apenas acrescenta pontos de verificação e controles burocráticos impacta diretamente a entrega de software e consequentemente impacta o negócio.
A prática de SM trabalha na construção do plano, manutenção e disseminação. Ao mesmo tempo, você deseja acompanhar sua postura de segurança de aplicações e implementar melhorias no programa. Uma abordagem orientada a métricas também deve ser implementada para que seja possível avaliar a eficácia do programa e estabelecer metas para aumentar a maturidade.
Por onde Começar?
O desenvolvimento da prática segue uma sequência lógica que envolve os seguintes passos:
- Construir
- Promover
- Avaliar
- Melhorar
Ou seja, como qualquer modelo de qualidade, eu sigo o já consagrado modelo PDCA.
Conforme citado no primeiro artigo dessa série que apresenta o OWASP SAMM, todas as práticas são estruturadas para que seja adquirido maturidade ao longo do tempo, após implementação, avaliação e melhoria.
Construindo o Programa
Segundo o NIST SP 800-39 Managing Information Security Risk, toda estratégia de segurança deve ser orientada à estratégia de gestão de risco da organização, conforme representado na imagem a seguir:
Integração dos requisitos de segurança da informação
O SAMM orienta a desenvolver a iniciativa a partir do apetite de risco da organização. Conhecendo o programa de gestão de riscos da organização, podemos conhecer o apetite, que segundo a ISO 31.000 Risk Management é a quantidade e tipo de risco que uma organização está preparada para tomar, manter e assumir.
A partir do apetite de risco construímos o programa de segurança de aplicações desenvolvendo as seguintes práticas:
Defina um escopo: estabeleça um objetivo que pode ser iniciar o processo por uma aplicação, um time, um projeto piloto que irá possibilitar exercitar o modelo e ganhar experiência para levar a iniciativa para outros escopos.
Catálogo de aplicações: uma documentação completa de todos os ativos de software e suas características chaves como criticidade para o negócio, responsáveis, ciclo de vida do desenvolvimento e criticidade das informações que a aplicação trata.
Conheça o processo de desenvolvimento: realize entrevistas com os times de desenvolvimento e conheça, documente as ações de segurança que podem ser inseridas no processo possibilitando que a empresa continue crescendo com segurança como sua aliada. Essa prática é conhecida como Gap Analysis e você pode usar o modelo do SAMM como baseline de controles.
Construa sua política de gestão dos riscos: com base no apetite e conhecimento dos riscos da organização desenvolva um modelo onde seja possível classificar e gerenciar todos os riscos associados a cada aplicação. informações críticas como critérios de aceitação de risco e prazos para tratamento de cada vulnerabilidade devem estar claramente estabelecidos e documentados. Uma plataforma de gestão de riscos e vulnerabilidades irá ajudar muito no processo.. Um modelo recomendado que pode ser adaptado a sua realidade é o OWASP Risk Rating Methodology.
Defina um roadmap: construa um plano que contenha os esforços envolvidos, orçamento e principais resultados esperados do programa. Esse plano deve pensar em marcos mensuráveis para uma iniciativa de no mínimo um ano, podendo se estender por mais tempo dependendo da complexidade do escopo e dos riscos associados a organização. O modelo de maturidade do SAMM que considera 3 níveis pode ser usado como marco de entrega. A partir do nível identificado no Gap Analysis, estabeleça seu critério de desenvolvimento de maturidade.
Monitoramento: as atividades do plano devem ser acompanhadas, e reuniões de status report devem ser realizadas com todos os patrocinadores do projeto. Importante passar visibilidade sobre os desafios encontrados e os resultados alcançados ao longo do roadmap.
Promovendo o Programa
Após a construção do programa com patrocínio da alta gestão e envolvendo os times de desenvolvimento, promova as iniciativas dentro da organização desenvolvendo as seguintes práticas:
Estabeleça um canal de comunicação: deixe claro qual a plataforma de comunicação onde os times podem envolver segurança no processo e como podem contar com os responsáveis de segurança.
Catálogo de serviços: antes de implementar qualquer ferramenta nas esteiras de desenvolvimento, apresente as opções de análise que o time de segurança pode executar, os treinamentos de capacitação que a equipe pode fornecer. Implementar uma ferramenta na esteira antes de desenvolver a cultura pode causar um desgaste entre os times e descredibilizar a iniciativa. Nos próximos artigos iremos falar sobre a adoção de ferramentas para escala do processo.
Promova o engajamento dos times: quanto mais pessoas envolvidas com o processo, maior a chance de sucesso e desenvolvimento de maturidade. Promova eventos, construa programas de Security Champions transformando os profissionais de desenvolvimento em aliados, pois segurança geralmente atrasa o processo e nunca terá o volume de profissionais especialistas em appsec para lidar com todas as demandas de desenvolvimento.
Avaliando o Programa
William Deming, que apesar de não ser o criador é considerado o pai do PDCA, proferiu a seguinte frase: “Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, e não há sucesso no que não se gerencia”.
Essa máxima se aplica a qualquer programa que se implemente em uma organização, para segurança de aplicações não deve ser diferente. Devemos estabelecer metas e acompanhar para que possamos conhecer o modelo, apresentar resultados e principalmente melhorar.
Devemos estabelecer pelo menos três tipos de métricas:
- Esforço: essas métricas medem o esforço despendido em segurança. Por exemplo, horas de treinamento, tempo gasto realizando revisões de código e número de aplicações que foram realizadas análises de segurança.
- Resultados: já as métricas de resultados medem os resultados dos esforços de segurança. Os exemplos incluem o número de vulnerabilidades de segurança não corrigidos e o número de incidentes de segurança que envolvem vulnerabilidades em aplicações.
- Ambientes: medem a complexidade de análises nos projetos, considerando volume de linhas de código e complexidade.
Muitas outras métricas podem ser desenvolvidas de acordo com a necessidade e características da organização. O maior drive das métricas é conseguir avaliar se você está ganhando maturidade no processo.
Melhorando o Programa
A partir das métricas coletadas e das experiências com os times, devem ser estabelecidos planos de ações para que o programa seja melhorado. O próprio SAMM fornece um modelo de assessment que permite avaliar cada uma das práticas do programa e estabelecer planos para alcançar o próximo nível de maturidade. Outra fonte de referência para benchmark do seu processo com o processo de empresas globais de diversos setores é o Building Security In Maturity Model (BSIMM).
Conclusões
Com esse primeiro artigo da série que irá tratar a implementação e gestão de um programa de segurança de aplicações, podemos verificar que um modelo bem estruturado e que traga resultados envolve uma série de práticas que vão muito além do simples processo de verificação de segurança de código ou testes de invasão (pentest) em aplicações.
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
