No artigo anterior falamos sobre o estabelecimento do programa, sua divulgação, definição de métricas e monitoramento para que seja evoluído o programa. Nesse artigo iremos falar sobre a importância da definição de diretrizes e acompanhamento.
Você pode também ouvir a versão em áudio deste artigo:
Antes de entrarmos na prática sobre a implementação, vamos entender a diferença entre políticas e padrões:
- Políticas: Políticas são declarações formais produzidas e apoiadas pela gerência sênior. Eles podem ser de toda a organização, específicos de problemas ou específicos de sistema.
- Padrões: Padrões são ações ou regras obrigatórias que dão suporte e orientação às políticas formais.
Ou seja, o conjunto de políticas atribui diretrizes que devem ser seguidos pelos envolvidos no escopo de cada política, e os padrões são o que deve ser feito para atender essas diretrizes. Podemos usar o conjunto de normas da ISO 27000 que certificam um sistema de gestão de segurança da informação como exemplo. A ISO 27.001 apresenta as diretrizes já a ISO 27.002 apresenta os detalhes do que são cada diretriz estabelecida na anterior.
Entendidos os conceitos, é importante não cometer um erro comum em iniciativas nas organizações, que é definir um conjunto de políticas extremamente agressivas no primeiro momento. Isso irá criar uma barreira entre os times e pode perder o patrocínio, pois o objetivo de segurança é possibilitar que os times entreguem softwares seguros, e não ser um impeditivo a produtividade. Estabeleça diretrizes simples inicialmente e vá melhorando após a avaliação do programa.
- Políticas
Antes do desenvolvimento de qualquer política específica para segurança de aplicações, é importante que a prática já esteja sendo endereçada em uma política de segurança da informação corporativa. Uma diretriz definindo a importância e compromisso da organização com a prática irá ajudar o envolvimento e comprometimento dos times com a iniciativa.
A partir do compromisso da alta gestão com a prática, devemos desenvolver um conjunto de políticas que estabelecem diretrizes claras para cada escopo de atuação. Materiais da Open Web Application Security Project (OWASP) são aliados importantes nessa iniciativa. Um bom programa possui pelo menos as seguintes políticas:
- Política de gestão de vulnerabilidades: estabelece as diretrizes que irão determinar o tratamento de cada vulnerabilidade na organização considerando no mínimo o tempo aceito para correção de acordo com a criticidade e os critérios de aceite de risco.
- Política de validação de software de terceiros: qualquer aplicação contratada deve atender às regulamentações que a organização está sujeita além de ter nível de segurança e processos de gestão de segurança compatíveis com o apetite de risco da contratante.
- Políticas de testes e verificações: estabeleça quais aplicações devem ser testadas e porque. Como critério pode ser usado o guia de requisitos Application Security Verification Standard (ASVS) da OWASP que estabelece um nível de criticidade para aplicação de acordo com o tipo de dado e importância para organização. Defina claramente cada tipo de teste e os resultados esperados de cada um deles. No artigo sobre as práticas de verificação da série SAMM que estamos desenvolvendo iremos abordar os diferentes tipos de teste e como cada um deles se encaixa no ciclo de vida da aplicação.
Cada política desenvolvida deve considerar o apetite de risco da organização e atender as regulamentações e critérios aos quais ela está sujeita. Uma regulamentação que devemos estar atentos no Brasil é a Lei Geral de Proteção de Dados (LGPD). Outra importante diretrizes para empresas que transacionam altos volumes de cartões de crédito é o PCI-DSS, padrão inclusive que possui desde o seu lançamento um requisito focado em segurança de aplicações e recentemente lançou um programa para certificação de aplicações e processos.
Nesse conteúdo abordamos apenas as políticas focadas em segurança de aplicações uma série de outras políticas como classificação de dados, controle de acesso, resposta a incidentes fazem parte da iniciativa de segurança de uma organização.
- Padrões
Para que as políticas sejam seguidas e os envolvidos consigam atender às suas diretrizes, é importante que sejam desenvolvidos padrões para facilitar o entendimento. Os padrões devem ser claros e específicos de acordo com os comportamentos dos usuários e tecnologias envolvidas.
Utilizando as políticas básicas estabelecidas no tópico anterior podemos utilizar alguns modelos da OWASP e SAFECode como padrões para atender as seguintes políticas:
- Gestão de Vulnerabilidades: a metodologia de rating de risco da OWASP ajuda a estabelecer quais os critérios para classificar e priorizar o tratamento das vulnerabilidades de acordo com as seguintes características:
- Fatores de Agentes de Ameaças
- Fatores de Vulnerabilidades
- Impacto Técnico
- Impacto de Negócio
- Validação de Software de Terceiros: o framework Framework for Software Supply Chain Integrity da SAFECode ajuda a estabelecer os critérios chaves para a prática:
- Cadeia de Custódia
- Acesso com Mínimo de Privilégios
- Separação de Deveres
- Resistência a Alteração e Evidências
- Proteções Persistentes
- Gestão de Conformidade
- Testes de Código e Verificações
- Testes e Verificações: para essa prática a OWASP fornece alguns modelos maduros e interessantes:
- Software Component Verification Standard (SCVS) aborda toda a gestão de Software Bill-of-Materials (SBOM)
- OWASP Code Review Guide aborda toda prática de revisão manual de segurança de código fonte
- OWASP Testing Guide aborda o penetration testing de aplicações web
- OWASP Mobile Security Testing Guide aborda o penetration testing de aplicações mobile
Abordamos alguns exemplos de padrões, mas é necessário – assim como as políticas – materiais específicos de acordo com as características de cada organização.
Além do desenvolvimento dos padrões, um programa maduro implementa ferramentas que possibilitem orientar e gerenciar cada um dos padrões gerando evidências para auditorias e indicadores para amadurecer a prática. Um modelo conhecido em empresas de tecnologia são os playbooks.
- Gestão de Conformidade
Após toda definição de controles, é importante que seja monitorado o atendimento das políticas pelo público interno e externo da organização.
Estabelece um canal claro para que os times internos e qualquer fornecedor possa conhecer todos os padrões e apresente o atendimento a cada um dos requisitos.
Para fornecedores é importante se atentar aos contratos vigentes e aos novos que serão firmados. A OWASP fornece um modelo de anexo de contrato para que os fornecedores estejam cientes das obrigações relacionadas a segurança de software.
- Conclusões
Nesse artigo, pudemos observar a importância das políticas e padrões alinhados com os públicos internos e externos, além do monitoramento para atendimento as obrigações legais e melhoria do processo.
Além dos padrões abordados, nos próximos artigos iremos abordar a modelagem de ameaças e definição de requisitos que irão orientar e avaliar as ações dos times envolvidos com o desenvolvimento de software.
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
