A importância das métricas em Segurança de Aplicações

Certa vez o escritor Peter Drucker disse: “Aquilo que não é medido, não é melhorado”. Ele tem razão – o que não conseguimos entender, não conseguimos melhorar ou mesmo saber se está ou não funcionando.

Quando aplicamos este mesmo pensamento aos processos de desenvolvimento seguro, percebemos que poucas empresas entendem realmente o que está se passando em seu processo. Quando muito, elas têm uma noção do número de vulnerabilidades em seus códigos, mas isso é o sintoma, e não a causa.

Então, é inevitável que dentro de todo este cenário não nos depararmos com a pergunta: “Então, como medir as coisas em um processo de desenvolvimento seguro?”

Neste artigo, vamos tentar colocar alguns pontos que entendemos que podem ser de grande importância para nos mostrar possíveis causas para nossos pontos de falha dentro do processo. No entanto, este artigo não tem como pretensão se tornar uma lista dos pontos que devem ser usados –  queremos apenas iniciar uma discussão, mostrar que precisamos falar sobre esse tema.

Qual a importância das métricas em Segurança de Aplicações?

É natural que, ao vermos um processo ou uma atividade sendo executada e funcionando, não nos preocuparmos muito com dados e ou mesmo seus números. 

Mas, se pararmos para refletir um pouco, vamos perceber que são estes números que nos proporcionarão uma oportunidade para melhorar. Vamos perceber também que o que imaginávamos como sendo uma atividade positiva para o processo está, na verdade, sendo feita sem efeito algum no processo como um todo.

Para a área de desenvolvimento seguro temos tanto o OWASP SAMM quanto BSIMM como dois modelos de maturidade que olham para este ponto e deixam claro a importância de se medir os processos e seus resultados para buscar entender se eles tem ou não sido eficientes dentro do todo.

As métricas podem nos ajudar a entender melhor o que está acontecendo com nosso processo, como podemos entender o seu funcionamento e se temos ou não um processo evoluindo. 

O uso de métricas que mostram claramente o que tem acontecido com o processo e seus produtos pode ajudar diretamente na tomada de decisão em diversos aspectos. 

As métricas em Segurança de Aplicações nas tomadas de decisão

As métricas também podem ajudar os profissionais de segurança a informar e influenciar a tomada de decisões na empresa, fornecendo valores de referência tangíveis que podem auxiliar em pontos de discussão.

Também, quando apoiamos as justificativas de novas alocações ou investimentos em números que realmente mostrem a situação do processo, estes argumentos se tornam muito mais fortes.

Mesmo que você esteja convencido de que é importante e que já até faça algumas medições no seu processo, medir por medir, sem ter um objetivo para cada métrica também não ajuda. Pelo contrário, pode levar à tomada de decisões que não tem efetividade.

Precisamos construir dentro de nosso processo um conjunto de métricas em segurança de aplicações que façam sentido para o nosso objetivo, e que efetivamente possam trazer as informações que vão ser importantes para as nossas decisões.

Mas então, como e quais seriam estas métricas em AppSec? Bem não há uma lista rígida, e nem deve existir, visto que os processos adotam muitas características das empresas que os usam  e não seria prudente termos um modelo fixo de métricas. No entanto, podemos trabalhar sobre conceitos e também olhando as etapas de um processo de desenvolvimento seguro.

Onde observar estas métricas? 

Primeiramente, antes mesmo de entendermos quais são as métricas que vamos trabalhar em nosso processo, precisamos entender qual seria um fluxo básico para trabalharmos com as métricas.

Como mostrado na imagem acima, temos que primeiro entender, descobrir e definir quais serão as nossas métricas. Afinal, isso é importante para termos o objetivo alcançado, pois de nada adianta termos as métricas que não nos darão a resposta correta.

Uma segunda fase, e uma das mais importantes, é a aquisição desses dados. Uma boa métrica só é realmente boa quanto a qualidade de seus dados. Ou seja: se temos dados errados ou pobres, teremos uma métrica pobre e que não será tão efetiva.

Por último, podemos dizer que após a identificação, escolha e aquisição de bons dados, precisamos entender e analisar estes dados, gerando assim uma informação que possa ser usada de forma clara e positiva para o processo.

Se conseguirmos entender e executar estas três fases, poderemos dar início ao processo de geração de métricas de nosso processo.

Documentação auxiliar

Podemos ainda buscar uma ajuda em um documento da OWASP, que mesmo tendo sido lançado em 2013, ainda traz bons pontos de questionamento e auxílio para nos ajudar a identificar quais e onde estas métricas podem ser levantadas.

Neste documento, podemos ver que pelo entendimento da OWASP, são pontos importantes a serem observados os processos de Application Security, Application Security Risk e no próprio SDLC. 

Como podemos ver, são vários os pontos que devemos observar. No entanto, neste artigo, o foco são as métricas do processo de SDLC. Mesmo que focando em um processo de desenvolvimento de software, temos que nos lembrar que este processo é formado por um conjunto de estruturas que o dão suporte, a infraestrutura, o próprio software e as etapas que compõem esse processo de desenvolvimento – e precisamos pensar em todos estes pontos.

Mas do ponto de vista de métricas, como elas podem nos ajudar? oras, podemos elencar vários pontos onde as métrica tem importância. Assim, podemos colocar como exemplos as métricas sendo usadas para as tomadas de decisão, ou mesmo em processos de Quality Assurance, buscando melhorar a qualidade do código ou mesmo em questões mais técnicas, onde elas podem nos ajudar em processo de monitoramento.

LEIA TAMBÉM: Gerenciando o processo de desenvolvimento seguro

Métricas no processo de SDLC

A seguir vamos listar alguns controles que podem ser colocadas para cada uma das etapas de um SDLC, mas precisamos lembrar que estas métricas devem ser alinhadas com seus objetivo. Por isso, as que estamos sugerindo podem ou não se encaixar no seu modelo.

Treinamentos

A fase de treinamentos, introduzida pelo processo de desenvolvimento criado pela Microsoft, tem como objetivo inicial a construção de uma equipe constantemente atualizada e capaz de desenvolver suas habilidades para manter suas aplicações sempre com as melhores práticas.

Então não é nada estranho imaginarmos métricas relacionadas ao conhecimento e a aquisição dele.

Se colocarmos como base, podemos ter métricas com o objetivo de entender e mapear as necessidade de entendimento dos participantes do processo em seus mais diversos domínios.

Em um processo de desenvolvimento, sempre que falamos em treinamento, um dos primeiros pensamentos é com relação ao desenvolvedor. No entanto, temos que lembrar que o processo de desenvolvimento envolve muito mais profissionais que somente os desenvolvedores. Então, a construção de um mapa de habilidade pode ser um bom início, e a partir dele podemos derivar alguns pontos.

Desta forma, dentro deste primeiro ponto temos no mínimo que pensar em treinamentos relacionados ao desenvolvedor, ao arquiteto, à equipe de testes e de resposta a incidentes.

Então, podem sugerir como métricas em AppSec:

1. Identificar o percentual de pessoas do processo treinadas.
2. Identificar o tempo entre uma capacitação e outra.
3. Identificar a quantidade de treinamentos por ano.

Lembrando que métricas devem ser usadas para ajudar na tomada de decisão. Então, caso você tenha uma estrutura baseada em análise de dados, podemos depois cruzar, por exemplo, a quantidade de pessoas treinadas com a quantidade de vulnerabilidades. Podemos também saber se um profissional capacitado produz menos vulnerabilidades do que um que ainda não o foi. Enfim, são muitas as possibilidades quando pensamos em analisar conjunto de dados.

O que temos que ter em mente é que precisamos definir um objetivo para estas e outras métricas, e elas devem nos trazer algo realmente relevante para o processo. Se ela não for bem elaborada e não fizer sentido, se torna apenas mais um dado que vai tomar seu tempo. 

Requisitos

Dentro do processo de requisitos, precisamos ter definidos todos os requisitos que serão necessários para a aplicação. Dentre eles, os requisitos de segurança.

Sabemos que mesmo em estruturas mais maduras, a cobertura de 100% de requisitos de segurança é um ponto bem complicado, mas temos que buscar ter o máximo possível de nossas aplicações cobertos por eles.

Desta forma, podemos ter uma visão melhor sobre o que temos como cobertura de segurança e o que temos que continuar trabalhando no processo de conscientização de metodologias seguras em processos de desenvolvimento.

Pode ser considerada como uma métrica relevante para esta fase:

1. Percentual de aplicação com requisitos de segurança definidos.

Da mesma forma, podemos usar estes valores para correlacionar os dados com outros pontos, como por exemplo, se aplicações fortemente baseadas em requisitos de segurança possuem mais ou menos vulnerabilidades identificadas. Isso pode nos mostrar a importância de se ter mais visão da fase de requisitos.

O correlacionamento de dados vai ser muito importante em várias fases do processo, mas notadamente pode ser um forte aliado para demonstrar a importância de fases que normalmente são mais encaradas como figurantes dentro do processo.

Design

A fase de design tem maior foco nos processos e atividades que estão diretamente relacionadas à forma como a Organização cria e estabelece metas para a criação de software. De forma mais abrangente, isso inclui a coleta de requisitos , assim como especificar como será a arquitetura e um design mais detalhado sobre a solução.

Assim, o design refere-se aos processos e atividades relacionados à forma como uma organização define metas e cria software nos projetos de desenvolvimento. Em geral, isso inclui coleta de requisitos, especificação de arquitetura de alto nível e design detalhado.

Dentro da fase de design, precisamos entender e criar quais serão as funções macro que o software deverá resolver. Além disso, também precisamos definir quais serão os requisitos de segurança que serão utilizados na solução.

Esta é uma fase muito importante, pois é nela que começamos a pensar em nossa estrutura de segurança, e como podemos proteger nosso software. É importante que durante o desenvolvimento da fase de design a solução seja confrontada com uma Modelagem de Ameaças, para que assim possam ser devidamente identificadas e endereçadas as possíveis ameaças que possam vir a colocar a aplicação em risco.

Podem ser consideradas métricas desta fase:

1. Quantas aplicações possuem um perfil de risco definidos
2. Quantas aplicações possuem Modelagem de Ameaças realizadas.
3. Quantas aplicações tem seu mapeamento de segurança para requisitos funcionais.
4. Quantas aplicações foram validadas no design baseados em um modelo de boas práticas.

Como falamos algumas vezes neste artigo, estas métricas não são definitivas e estão aqui muito mais para estimular o pensamento na necessidade de métricas e acreditamos que muitas destas podem e serão adequadas às necessidades de cada realidade.

Implementação

A fase de implementação é focada na forma como as atividades relacionadas à criação e implantação de componentes de software, e como podemos observar o que pode acontecer de problema com estes componentes.

As atividades desenvolvidas nesta fase são as que mais têm impacto nas atividades diárias das equipes de desenvolvimento, e o principal objetivo desta fase é entregar software com o menor número de defeitos possíveis.

Em um primeiro momento, parte desta fase se concentra na busca da automação completa. No pipeline, a construção automatizada pode incluir verificações de segurança realizadas automaticamente usando ferramentas como SAST e DAST.

No segundo momento, há uma grande quantidade de dependências de software em aplicativos modernos. Então nosso objetivo neste momento é identificar estas dependências e rastrear seu status de segurança. 

Ainda, é importante que nesta fase tenhamos o controle sobre como este código será entregue, e nada melhor do que buscar automatizar todo o processo, evitando assim que erros humanos possa prejudicá-lo. Isso ainda ajuda na separação das tarefas das equipes presentes nestes processos. 

Assim, podemos dizer ainda que na fase de implementação buscamos identificar, registrar e analisar os defeitos que tenham surgido nos códigos entregues. 

Então, se entendermos todos estes passos, podemos sugerir algumas métricas em AppSec a serem pensadas para esta fase:

1. Qual o percentual de automação dos seus projetos.
2. Qual o percentual de vulnerabilidades encontradas pela ferramenta por cada 1000 linhas de código
3. Qual o percentual de falsos positivos identificados nos reports de ferramentas.
4. Percentual de falhas que são reincidentes

Desta forma, acreditamos que se teria uma boa visualização do que pode estar acontecendo durante o processo de desenvolvimento de uma aplicação. Além disso, quando cruzamos estes dados com os dados de treinamento, podemos verificar se estão ou não sendo eficazes os treinamentos que estão sendo realizados.

Verificação

A fase de verificação tem como foco os processos e atividades que estão diretamente relacionados a como são verificados os artefatos produzidos durante o processo de desenvolvimento. Nesta fase, estão naturalmente relacionados processo de testes de qualidade e também outras atividades de verificação de código.

Sendo assim, podemos entender que, neste momento, o processo de verificação pode ser a etapa de validação de muito do que foi identificado nas etapas anteriores. Como, por exemplo, os requisitos e o processo de validar se não há ameaças que tenham sido identificadas no processo de modelagem.

Quando tratamos de avaliação de arquitetura, temos que ter em mente que o que estamos avaliando é tanto a arquitetura da aplicação quanto da infraestrutura que serão serão avaliadas e testadas.

Então, podemos identificar possíveis falhas e ou problemas que tenham passado pelos testes anteriores.

A fase de verificação é uma fase crucial para a operacionalização de uma aplicação. Afinal, é nesta fase que podemos buscar identificar falhas que podem ter passado nas fases anteriores e que venham a trazer riscos para a aplicação. 

Assim, podemos sugerir algumas métricas:

1. Quantidade de controles validados por aplicação;
2. Qual o percentual coberto de casos de abuso da aplicação;
3. Quantas ameaças identificadas na Modelagem de Ameaças foram identificadas;
4. Qual o percentual do software está coberto por testes;
5. Quantidade de vulnerabilidades validadas em testes manuais de code review;
6. Número de vulnerabilidades identificadas em teste manual de testes de intrusão.

Operações

Na fase de operações, são abrangidas as atividades necessárias para garantir que a confidencialidade, a integridade e a disponibilidade sejam mantidas durante toda a vida útil operacional de uma aplicação e de todos os dados associados. 

Assim que há um aumento na maturidade destas atividades, a organização passa a ter uma maior garantia de que é resiliente diante de eventos que venham a interromper ou mesmo reduzir sua capacidade operacional.

Não é anormal que nesta fase sejam identificados incidentes relacionados à operação da aplicação. No entanto, estes incidentes muitas vezes poderiam ser evitados, pois em muitos casos há boas indicações em registros de logs de algo que não está de acordo com o comportamento normal da aplicação ou estrutura.

Para que, nesta fase, as operações sejam realizadas da melhor forma possível, alguns pontos devem ser observados. Por exemplo: a busca por reforçar as configurações de sistemas e de estruturas que dão suporte à aplicação, ou mesmo melhores práticas de como serão enfrentados os eventuais incidentes acontecidos em nossa estrutura.

Garantir a operação de uma aplicação é um processo complicado e cheio de detalhes que precisam ser facilmente mensuráveis. E as métricas ajudam neste processo de descobrir melhor o que é normal dentro da operação da aplicação.

Criar um perfil de normalidade ajuda a identificar pontos e ou eventos que não foram esperados para a aplicação. Para isso, podemos sugerir que sejam criados algumas métricas que nos ajudem neste ponto.

Podemos sugerir como métricas para esta fase:

1. Número de incidentes ocorridos em um período de 3 meses
2. Tempo decorrido entre a descoberta do incidente e sua solução.
3. Quantidade de aplicações cobertas por um plano de incidentes.
4. Número de sistemas desatualizados

Criar métricas em AppSec é um processo demorado e trabalhoso, mas que traz bons frutos. Mas como falamos no começo, as métricas aqui colocadas são boas para levar ao pensamento crítico e avaliação, para que você avalie se elas se encaixariam em suas realidades, pois não há uma receita de bolo.

Conclusão

Depois de colocarmos nossa visão sobre métricas dentro do processo de desenvolvimento de software, acreditamos que demos um pontapé inicial nesse tema dentro da sua estrutura.

Construir um programa de métricas não é uma questão trivial, precisa de muito empenho e de muito conhecimento sobre seus objetivos e processos sendo desenvolvidos. Mas os resultados alcançados podem trazer para a sua estrutura a segurança de que o caminho foi traçado, e agora há uma estrutura de métricas a serem avaliados para saber se o caminho está sendo seguido.

Dentro de um processo de gestão por métricas, o maior ganho é ter a visão do todo e com ela tomar melhores decisões.

Queremos ajudar neste processo e sempre queremos entender como e por onde nossos leitores começam com seus planejamentos. Por isso, sempre que for possível, compartilhe com a gente os seus pontos por meio dos comentários.