Uma abordagem sobre gestão de vulnerabilidades

Vazamentos e violações de informação são (e serão) um assunto cada vez mais recorrente. Existe uma frase (já bem clichê) que diz: a informação é o novo petróleo. Dados e informação são ativos cada vez mais valiosos, tanto para empresas que ofertam bens e serviços, quanto para criminosos.

O fato é que muitos, ou se não todos os comprometimentos ocorrem através da exploração de uma vulnerabilidade, por vezes desconhecida, por outras não gerenciadas. Por isso, um programa de gestão de vulnerabilidades sólido deve ser uma das fundações de um programa de segurança da informação.

Um programa de gestão de vulnerabilidades vai além do scan com relatório (muitas vezes num excel ou em um pdf). Vulnerabilidades geram riscos, e novas vulnerabilidades reaparecem diariamente, mudando completamente a fotografia do risco atual.

Porquê é tão importante?

Poderia citar uma série de justificativas ou motivos para ter um programa de gestão de vulnerabilidades, mas vou falar de duas que considero bastante relevantes.

Primeiro bom motivo: Uma boa prática, e due-diligence

Frameworks podem ter por vezes um viés mais de compliance do que de segurança da informação. Mas o fato é que podem ajudar a dar alguns passos, além de existirem frameworks muito bons para ajudar a construir e medir um programa de cibersegurança.

O CIS controls é um framework formado por um conjunto de controles para ajudar organizações na implementação e governança de segurança da informação.

Ele é dividido em três grupos de controles: Basic, Foundation e Organization, sendo sua implementação relacionada com níveis de maturidade de segurança, sensibilidade das informações, tipo de negócio entre outros. Mais informações podem ser encontradas em https://www.cisecurity.org/white-papers/cis-controls-v-7-1-implementation-groups/

O ponto é que pegando o CIS controls como exemplo, gestão contínua de vulnerabilidades está entre os itens mais básicos em um programa de segurança da informação.

Eu diria que a primeira torre, Foundational, está fortemente ligada a visibilidade e controle. Não se protege o que não se conhece, ou o que não se tem visibilidade.

Mas se ainda assim esse não parece um bom motivo, vamos falar sobre o segundo.

Segundo bom motivo: O exemplo do caso Equifax

Resumindo muito a história, em 2017 a Equifax sofreu um vazamento massivo de dados de aproximadamente 143 milhões de clientes. Este vazamento aconteceu através de uma falha no Struts, um velho conhecido framework de desenvolvimento Java.

A correção saiu em março de 2017 e três dias depois já estava sendo explorada massivamente. Aproximadamente dois meses depois a Equifax foi comprometida.

O ponto é que poderia ter sido evitado através de um patch. No video abaixo, o CEO da Equifax é sabatinado. A companhia não sabia que tinha a falha ou sabia e não tomou nenhuma ação? Veja o vídeo para descobrir...

Em outras palavras, ter um programa de gestão de vulnerabilidades em funcionamento, é uma maneira de dizer que o trabalho está sendo feito. É um dos indicadores de due-diligence.

E porquê não recebe a devida importância?

Costumo comparar este tipo de iniciativa à comprar um carro.

É tão gratificante a sensação de comprar um carro novo, mas as contas com manutenção preventiva e seguro não são nada animadoras.

Assim é gerenciar vulnerabilidades. Um trabalho contínuo, custoso e que não arrenda troféus como o projeto do ano. Mas é necessário e evita que problemas aconteçam.

O grande desafio então é, como apresentar o valor de um programa de gestão de vulnerabilidades, fazendo com que os times responsáveis em remediar as vulnerabilidades saibam que realmente estão trabalhando nos problemas certos e reduzindo risco de fato, ao invés de simplesmente estarem aplicando patches infinitamente?

A resposta é:

Priorização

Ao fazer um assessment de vulnerabilidades, qualquer ambiente irá apresentar um número consideravelmente alto, por mais maduro que seja. A quantidade de novas vulnerabilidades publicadas geralmente é absurdamente alta. Imaginar que todas serão corrigidas será frustrante, além de um forte direcionador do programa rumo ao fracasso. O que fazer então?

Exploited in-the-wild

Em tempos onde recursos humanos e financeiros precisam ser cada vez mais otimizados, porquê colocar tanto esforço em distribuir patches para um parque inteiro de estações com objetivo de mitigar uma vulnerabilidade com criticidade média e sem exploit disponível?

O termo exploited in-the-wild refere-se a existência um exploit disponível, maduro e em plena atividade, para uma vulnerabilidade geralmente crítica e recente. Esse é o caso que deve realmente ser priorizado.

Um conceito muito comumente usado de pontuação e priorização é o do CVSS Score, que trás algumas métricas como criticidade, impacto e se a vulnerabilidade é amplamente conhecida.
Porém ainda não é tão contextualizado. Mas algumas ferramentas modernas de vulnerability assessment já trazem algumas métricas mais contextuais de risco real, por exemplo:

• Como está a atividade de exploração de uma determinada vulnerabilidade?
• Qual tendência pode virar um problema maior em um futuro próximo?
• Ativos tem peso: dois ativos com importâncias diferentes para o negócio. Onde priorizar?

Preparando o programa de gestão de vulnerabilidades

Toda esta introdução foi para estarmos na mesma página sobre a importância de um programa de gestão de vulnerabilidade. E o porquê dele poder dar errado.

Porém, para estabelecer um programa de gestão de vulnerabilidades, são necessários alguns passos fundamentais para entendimento da importância do programa propriamente dito, e consequentemente sua viabilização.

Falarei a seguir de alguns fatores importantes, como:

• Sign-off e acreditação do programa
• Métrica, SLA's e KPI's
• Processo e politica de gestão de vulnerabilidades
• Inventário de ativos
• Ferramentas
• Medição do programa

Sign-Off

Aqui tudo começa e é um passo fundamental para que o programa não vire um relatório que ninguém lê. Estamos falando de um entendimento geral da importância deste programa e do cumprimento dos passos posteriores, para que seja o mais próximo de ser bem sucedido. E quando falamos de sign-off, estamos falando de acreditação no programa.

Como será a acreditação no programa não é o mais importante, podendo variar de acordo com processos, tamanho, maturidade ou cultura. Pode ser uma política assinada pela alta gestão, ou um alinhamento formalizado entre os envolvidos. O mais importante é que o sucesso do programa seja entendido como parte vital dentro de um programa mais abrangente de gestão de risco e continuidade dos negócios.

Projeto x Programa

Outro ponto importante a ser entendido é que trata-se de um programa e não um projeto. Um projeto tem inicio, meio e fim. Já um programa é contínuo, medido, avaliado e reajustado quando necessário. Implementar uma ferramenta de gestão de vulnerabilidades é um projeto. Monitorar, comunicar e gerenciar continuamente os resultados, é um programa.

Definindo métricas — SLA’s e KPI’s

Uma vez que o programa tenha o suporte necessário, será necessário definir o que se espera dele.
Importante mencionar que quando falamos em gerenciar vulnerabilidades, estamos falando em gerenciar riscos também. E cada companhia tem seu próprio apetite ao risco. Correções demandam tempo e investimento em recursos financeiros e humanos, e cabe ao negócio avaliar seu apetite ao risco em conviver com vulnerabilidades mais ou menos críticas em mais ou menos tempo.

Apesar de uma das funções do CISO ser a de recomendar o tempo que acha mais apropriado, simplesmente "empurrar" SLA's incompatíveis com o apetite ao risco da companhia, é o primeiro passo para o insucesso do programa. O recomendado nestes casos é que, assim como outros riscos, um tempo demasiadamente alto de remediação possa ter seu registro de risco a ser aceito.

Por fim, mas não menos importantes são os KPI's, onde o sucesso do programa pode ser medido. O KPI deverá medir em que nível os SLA definidos estão sendo atendidos.

Exemplos de métricas

As métricas são importantes para definir se o programa está alcançando seus objetivos. E aqui vamos falar de:

• SLA (Service Level Agreement): Nível de serviço estabelecido. O que se espera de atendimento de um serviço. Apenas como um exemplo, uma vulnerabilidade crítica deve ser corrigida em 30 dias, mas caso haja uma campanha severa de exploração em curso, a remediação deve acontecer em 72 horas, por exemplo.
• KPI (Key Performance Indicator): Medição da eficiência de processo, ou seja, em que nível os processo e serviços estabelecidos estão sendo atendidos dentro do critério estabelecido. Por exemplo, 95% dos SLA’s estão sendo atendidos dentro do tempo estabelecido, quando o esperado é 98%.

Para um programa de gestão de vulnerabilidades, é importante que os SLA’s sejam definidos baseados na criticidade da vulnerabilidade ou risco, por exemplo:

• Criticas: 1 mês
• Altas: 3 mês
• Médias: 6 meses
• Baixas: follow-up

Alguns KPI’s interessantes para medir a eficiência do programa podem ser:

• Em quanto tempo as vulnerabilidades vêm sendo corrigidas, baseadas em sua criticidade? Está dentro do esperado?
• Que tipos de ativos levam mais tempo para correção?
• Qual era o nível de exposição no inicio do programa e como está sua evolução? A evolução do programa está dentro do esperado?
• Qual tipo de vulnerabilidade é mais recorrente (patches, configuração, código e etc)? Estamos priorizando os problemas certos?
• Existem vulnerabilidades antigas aparecendo em sistemas novos? O baseline nestes casos está sendo seguido?

Novamente: estes são exemplos teóricos, os níveis esperados devem sempre ser aqueles acordados com áreas de negócio e sustentação, e entendido como razoáveis e compatíveis com o apetite ao risco.

Definir as métricas é um dos passos mais importantes do programa, visto que é onde as expectativas estarão acordadas. Boas métricas ajudarão a medir o sucesso do programa.

Norma (ou política) de gestão de vulnerabilidades

Uma vez que os passos anteriores estejam definidos, é hora de documentar as regras. Alguns tópicos importantes que devem figurar em uma norma de gestão de vulnerabilidades:

• Objetivo
• Papéis e responsabilidades
• Matriz RACI
• Critérios de classificação
• Métricas esperadas
• Sign-Off

É importante envolver areas de negócio, desenvolvimento e sustentação de sistemas na criação da política. Isso irá garantir (ou pelo menos ajudar) que todos estão cientes sobre o que é esperado, e que suas responsabilidades no programa foram entendidas e tudo está de acordo com o combinado.

Outro ponto importante é que a norma é a formalização dos objetivos do programa. Assim ela deve ser aprovada e assinada pela alta gestão, que irá acompanhar os resultados e evolução do programa.

Inventário

Para proteger é preciso conhecer

Um programa de segurança da informação trata-se de proteger ativos e informações. Direcionamento e priorização (incluindo orçamento) dos esforços estarão fortemente relacionados com o impacto de um comprometimento, conforme já falamos. Ativos críticos para o negócio, ou com informações sensíveis são os que devem ter investimentos em proteção priorizados, e um inventário tem importância fundamental nesta priorização.

Não se trata apenas de inventário de hardware, ou de versão de aplicativos. Mas de sistemas, dados e informação. Com a LGPD, o assunto governança de dados nunca esteve tão na pauta. Saber quais dados são, onde estão, sua classificação e seus donos, será cada vez mais relevante. Na verdade, acredito que será fundamental.

Um programa de gestão de vulnerabilidades será uma das bases para tomar decisões de gestão de risco, e o inventário de sistemas e dados será um dos balizador destas decisões. Veremos adiante que uma ferramenta de gestão de vulnerabilidades será capaz de identificar e classificar vulnerabilidades baseadas em sua facilidade de exploração e possível impacto. Mas o impacto real estará relacionada com sua materialização e a criticidade do ativo e da informação nele.

Gestão de inventário será fundamental para priorizar investimentos (tempo e dinheiro) em correções.

Ferramenta

Para nós, techies, aqui é onde a emoção começa. É a parte que envolve tecnologia e onde conseguimos ver resultados mais palpáveis. Não vou entrar no detalhe de qual ferramenta escolher, pois é uma decisão baseada em orçamento, funcionalidades, suporte do vendor e etc, mas irei recomendar o que esperar de uma ferramenta de gestão contínua de vulnerabilidades.

Vulnerability Assessment Tool

De modo bem geral, existem dois tipos de ferramentas:

• Stand-alone/professional: Geralmente usada por profissionais que estão realizando um risk assessment com viés de consultoria, auditoria ou pen-test. É instalada em um computador pessoal, os scans são executados, o consultor entrega os relatórios, vai embora e é isso. Não existe uma continuidade do processo.
• Enterprise/Continuous monitoring: Funcionam como serviço, de maneira contínua. Geralmente são client-server, com scanners executando scans e enviando relatórios para uma console. O diferencial em relação a uma versão stand-alone é que é possível ter scans contínuos e agendados, analisar tendências, ter indicadores de evolução e priorização.

Para um programa contínuo de gestão de vulnerabilidades, minha recomendação é usar uma ferramenta do tipo Enterprise, que permitirá uma monitoração contínua as a service.

Entre algumas funcionalidades a se esperar de uma ferramenta deste tipo, é recomendado que sejam capaz de:

• Executar scans de maneira recorrente, automática e programada.
• Monitorar tendências e comparar resultados ao longo da evolução do programa.
• Classificar resultados automaticamente ou através de regras pre-definidas, geralmente baseado em labels ou tags.
• Criar visões de remediação ou dashboards evolutivos baseados em um tipo de ativos, vulnerabilidade ou versão.
• Monitorar SLA’s e KPI’s definidos.
• Prover relatórios bons e customizáveis.
• Suportar os tipos de sistemas existentes em seu ambiente.

Testes SAST e DAST - vulnerabilidades no código

Os testes SAST e DAST já existem há algum tempo, mas ganharam força recentemente, principalmente com o advento de modelos ágeis como DevOps.

Basicamente, um teste SAST, também chamado de teste estático, é feito em tempo de deploy, com o objetivo de buscar erros (que podem criar vulnerabilidades) diretamente no código e recomendar correções ao desenvolvedor. Já os testes DAST, também chamados de dinâmicos, realizam testes com a aplicação em produção, fazendo testes com entradas de dados, lógica fuzzy e etc.

A boa notícia é que é possível, integrar em esteiras CI/CD através de softwares de automação, como o Jenkins, para realizar testes automaticamente após cada novo release, por exemplo.

Monitorando o programa

Um programa de qualquer origem ou tipo precisa ser monitorado e gerenciado para que seja possível identificar se os seus objetivos estão sendo cumpridos. Com um programa de gestão de vulnerabilidades não é diferente. É preciso saber se o objetivo principal de reduzir a superfície de exposição e risco está sendo alcançado. As métricas ajudam na identificação, mas por vezes será necessário tomar algumas ações para corrigir alguns desvios, ou rever algumas estratégias no gerenciamento do programa.

Um programa de gestão de vulnerabilidades é como um PDCA. Sempre haverá busca por novas vulnerabilidades, priorização do que precisa ser remediado primeiro, remediar, verificar e começar tudo de novo.

E por fim, alguns pontos importantes dentro da monitoração do programa:

• Estabelecer um ciclo PDCA para identificar pontos de melhoria.
• Priorizar remediações baseando-se em risco.
• Prover visibilidade para os envolvidos.
• Reportar aos stakeholder se o programa está sendo eficiente em reduzir risco.

Para saber mais

SP 800–37 Rev. 2 Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy:
https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final

SP 800-40 Rev. 3 Guide to Enterprise Patch Management Technologies:
https://csrc.nist.gov/publications/detail/sp/800-40/rev-3/final

Implementing a Vulnerability Management Process:
https://www.sans.org/reading-room/whitepapers/threats/paper/34180

Building a Vulnerability Management Program - A project management approach:
https://www.sans.org/reading-room/whitepapers/projectmanagement/paper/35932