Definição de vulnerabilidades de segurança
Vulnerabilidades de segurança — no contexto de Segurança da Informação — referem-se a fragilidades que podem representar riscos cibernéticos, ou seja, podem dar origem a falhas ou ataques. Algumas diferentes definições nos ajudam a ter uma noção mais rigorosa do contexto de vulnerabilidade de software.
Definição da ISO/IEC 27005
“A weakness of an asset or group of assets that can be exploited by one or more threats”.
Uma fraqueza em um ativo ou grupo de ativos que pode ser explorada por uma ou mais ameaças.
Definição da RCF 4949
“A flaw or weakness in a system’s design, implementation, or operation and management could be exploited to violate the system’s security policy”.
Uma falha ou fraqueza no projeto, implementação ou operação e gerenciamento de um sistema que pode ser explorada para violar a política de segurança do sistema.
Definição da NIST SP 800-30
“A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy”.
Falha ou fraqueza em procedimentos, projeto, implementação ou controles internos de sistemas de segurança, a qual pode ser exercitada (acidentalmente disparada ou intencionalmente explorada), e resulta numa quebra de segurança ou violação da política de segurança.
Sutilezas a serem observadas na definição de vulnerabilidade
Uma dessas sutilezas é a diferença entre “explorar” a vulnerabilidade e “exercitar” a vulnerabilidade. A palavra exploração remete a uma ação intencional, com o objetivo deliberado de causar dano. Já a palavra “exercício”, como a própria definição da SP 800-30 esclarece, contempla tanto a exploração intencional quanto o “disparo acidental”.
Esta definição mais abrangente de vulnerabilidade parece ser mais consistente com a definição mais abrangente de “ameaça cibernética”, como a presente na RFC 4949, que contempla tanto ameaças intencionais (ou seja, ataques realizados por agentes inteligentes) quanto ameaças acidentais (seja, aquelas causadas por falhas, sejam aquelas decorrentes de eventos imprevisíveis, tais como catástrofes naturais).
Outra sutileza é o uso das palavras “falhas” e “fragilidades”. A palavra “falha” remete a um erro concreto que, a princípio, deveria ser evitado. Já a palavra “fragilidade” parece ser mais abrangente, remetendo a escolhas associadas ao projeto do sistema e à política de segurança que trazem riscos, mas que não podem ser necessariamente caracterizadas como um erro.
Ou seja, um erro de programação que viabilize um buffer overflow ou injeção de SQL é claramente uma “falha”, mas uma regra de negócio que flexibilize o processo de recuperação de senha para melhorar a experiência do usuário — ao custo de redução de segurança — poderia ser encarada como uma “fragilidade” mas, mesmo sendo uma prática não-recomendada, dificilmente poderia ser caracterizada como uma “falha”.
A definição da RFC 4949, inclusive, descreve explicitamente que a vulnerabilidade pode surgir em diversos momentos do “ciclo de vida” do software — desde o design (projeto/concepção), passando pela implementação até a operação e gerenciamento.
Em geral, vulnerabilidades associadas a implementação, operação e gerenciamento são caracterizadas como erros a serem evitadas, mas vulnerabilidades associadas ao design de um sistema tendem a ser escolhas de projeto cujo impacto em segurança são muito mais sutis — e difíceis de serem caracterizadas como erro.
De todo modo, o efeito final de uma vulnerabilidade, quando explorada (ou exercitada), é uma violação da política de segurança, que se concretiza com um acesso indevido a um recurso. O diagrama a seguir dá uma visão geral da nomenclatura associada a vulnerabilidades.
Bases de dados de vulnerabilidades de segurança
Dada a importância da questão das vulnerabilidades de segurança, um grande esforço é feito pela comunidade de segurança no sentido de catalogar e organizar tais vulnerabilidades. De fato, são conhecidos esforços no sentido de catalogar vulnerabilidades desde os primórdios do desenvolvimento de software — por exemplo, em 1973, quando Saltzer, pesquisador envolvido no projeto do Multics, compila uma lista de formas nas quais um usuário pode contornar os mecanismos de proteção.
Atualmente, o profissional de Tecnologia da Informação tem à sua disposição formidáveis bases de dados de vulnerabilidades — abrangentes e consistentes — que pode consultar com diferentes objetivos. Listamos, a seguir, as principais bases de dados destinadas a catalogar e organizar vulnerabilidades de segurança.
CVE
As letras CVE originalmente representavam as iniciais de “Common Vulnerabilities and Exposures”. No entanto, a sigla ganhou um significado próprio tão forte que passou a ser utilizada de forma “autônoma”, de modo que a descrição completa do significado original de CVE já não é encontrada na descrição do “CVE Program” na página oficial.
CVE é um catálogo de ocorrências de vulnerabilidades nas aplicações de software que fazem parte do escopo do programa. Toda vez que um pesquisador de segurança identifica uma vulnerabilidade em uma aplicação de software que esteja no escopo do programa, ele pode entrar em contato com uma CVE Numbering Authority (CNA) que será responsável por avaliar aquela descoberta e, caso seja, de fato, uma vulnerabilidade, irá atribuir uma numeração única a ela associada.
Cada CNA possui um escopo de aplicações de software, portanto, a CNA contactada irá depender da aplicação a que se refere a vulnerabilidade. A maior parte das organizações cadastradas como CNA são autorizadas a catalogar vulnerabilidades associadas às suas próprias aplicações de software. Exemplos de CNA autorizadas a operar no programa CVE cadastrando vulnerabilidade em suas próprias aplicações são:
- Adobe Systems Incorporated;
- Apache Software Foundation;
- Apple Inc.;
- Facebook, Inc.;
- FreeBSD;
- Microsoft Corporation;
- Netflix, Inc;
- Samsung Mobile.
Alguns CNA têm a possibilidade de cadastrar vulnerabilidades em qualquer software que não esteja no escopo de outro CNA, como é o caso de: AppCheck Ltd., Check Point Software Ltd. Kaspersky e Symantec – A Division of Broadcom, Synopsys.
CWE
CWE é a sigla para Common Weakness Enumeration, um sistema de categorização de fragilidades de segurança. O CWE estabelece uma linguagem comum para referência a fragilidades de segurança, não apenas, nomeando e categorizando fragilidades, mas estabelecendo relações entre elas.
Ao contrário do CVE, que enumera ocorrências de vulnerabilidades, o CWE estabelece categorias nas quais se enquadram as diversas vulnerabilidades identificadas em aplicações de software. Por exemplo, os CVEs CVE-2022-28116, CVE-2020-13118 e CVE-2016-10379 referem-se, respectivamente, a injeções de SQL nas aplicações de um sistema bancário, de gerenciamento de um roteador e de um sistema de gerenciamento de conteúdo, estando, portanto, todos mapeados para a mesma categoria de fragilidade identificada pelo CWE-89.
No site do CWE, cada categoria de fragilidade é detalhada com informações tais como “Descrição”, “Modos de Instrução”, “Plataformas Aplicáveis”, “Consequências”, “Exemplos”, “Mitigações” e “Detecção”. Adicionalmente, são apresentados relacionamentos entre as categorias, estabelecendo uma estrutura hierárquica na qual é possível compreender como determinadas categorias generalizam outros conjuntos de categorias.
Por exemplo, nosso exemplo anterior do CWE-89, Injeção de SQL, é um caso especial de “Improper Neutralization of Special Elements in Data Query Logic” (CWE-943), que também tem outros casos especiais tais como “LDAP Injection” (CWE-90), “XPath Injection” (CWE-643) e “XQuery Injection” (CWE-652).
A referência estabelecida pelo CWE é fundamental para a correta operação de uma série de outras bases de dados de vulnerabilidades que nela se baseiam.
NVD
NVD é a sigla para National Vulnerability Database, uma base de dados mantida pelo NIST, órgão do Departamento de Comércio dos Estados Unidos. O NVD é “alimentado” pelo CVE, mas os registros de vulnerabilidades são complementados com informações valiosas. Em particular, cada CVE é associado a um CWE (estabelecendo uma “categoria de fragilidade” à qual está associada aquela vulnerabilidade) e são estabelecidas métricas de severidade, com a avaliação de índices de “explorabilidade” e “impacto” conforme a metodologia CVSS.
A associação entre vulnerabilidade (CVE), categoria de fragilidade (CWE) e índice de severidade (CVSS) estabelecida no âmbito do NVD é a base para muitas análises de vulnerabilidades realizadas pela comunidade de segurança.
CVSS
CVSS é a sigla para Common Vulnerability Scoring System. Não se trata de uma base de vulnerabilidades, mas de uma sistemática para a definição de métricas de severidade para vulnerabilidades tão importante que não poderia deixar de ser mencionada.
O CVSS avalia a severidade de uma vulnerabilidade em termos de “explorabilidade” e “impacto”. A metodologia de cálculo de severidade é divulgada publicamente e uma “calculadora de severidade” é mantida no site do CVSS, de modo que qualquer desenvolvedor pode usá-la para avaliar os riscos associados às vulnerabilidades descobertas em seu próprio projeto de software.
CWE Top 25
O “Top 25” do CWE é uma metodologia para selecionar as 25 mais relevantes categorias de fragilidades de software. Esta seleção é feita de maneira objetiva e totalmente orientada a dados: a cada ano, o conjunto de CVEs associados a cada CWE é avaliado, tanto em quantidade quanto em índices de severidade. A lista Top 25 contém os 25 CWEs com maior ocorrência de CVEs e com maiores índices de severidade, conforme uma fórmula matemática objetiva.
OWASP Top 10
O “Top 10” da OWASP é metodologia para selecionar as 10 mais relevantes categorias de fragilidades de software. Ao contrário do CWE Top 25, o Top 10 da OWASP é bem mais subjetivo: embora seja fortemente baseado em dados (obtidos de consultorias de segurança especializadas em análise de aplicações de software).
A lista também considera o resultado de um survey conduzido junto à comunidade de especialistas. Além disso, a composição das categorias segue critérios atualizados a cada versão da lista, que costuma ser publicada a cada três ou quatro anos.
Importância das bases de dados de vulnerabilidades
A base de dados CWE estabelece uma linguagem comum para categorizar vulnerabilidades de segurança, permitindo referenciá-las de forma objetiva e não-ambígua. A base CVE, complementada por informações adicionais de categorização (CWE) e severidade (CVSS) fornecidas pela NVD, permitem uma visão concreta da ocorrência de vulnerabilidades em importantes aplicações de software, incluindo sua frequência e severidade.
A lista CWE Top 25 oferece uma sistemática automatizada para a determinação dos CWEs mais relevantes a partir de uma lista de CVEs. A lista OWASP Top 10 oferece uma análise mais “manual” das vulnerabilidades ao longo de um período (tipicamente três ou quatro anos), agrupando CWEs em categorias de risco e permitindo uma visão do estado de riscos de software por parte da comunidade técnica suportado por dados oferecidos por consultorias.





