Ebook GCV Versao Final

GCV - GERENCIAMENTO
CONTÍNUO DE
VULNERABILIDADES
UMA ABORDAGEM ORIENTADA A RISCOS
SU
MÁ
RIO
1 - Gerenciamento Contínuo de Vulnerabilidades....................................... 4
2 - Conceito de Vulnerabilidade................................................................... 9
3 - Bases de Dados e Catálogos de Vulnerabilidades............................... 13
4 - Severidade de Vulnerabilidades........................................................... 21
5 - O Processo de Gerenciamento de Vulnerabilidades............................ 25
6 - Gerenciamento de Riscos..................................................................... 28
7 - Riscos Cibernéticos.............................................................................. 30
8 - A Plataforma BART GCV....................................................................... 34
9 - Perguntas Frequentes sobre Modelo BART GCV.................................. 38
O termo Vulnerabilidade
se refere a fragilidades
que podem ser exploradas
de modo a comprometer a
segurança.
Especialistas em Segurança da Informação

sempre reconheceram a importância de investir
no gerenciamento de vulnerabilidades associadas
ao ambiente tecnológico das organizações.
No entanto, tal tarefa sempre foi um desafio: o contínuo surgimento de

ferramentas e técnicas de ataque demanda que o gerenciamento de vul-
nerabilidades também seja uma tarefa contínua. Adicionalmente, o am-
biente tecnológico da organização e relevância de cada um de seus ativos
também são dinâmicas, mudando ao longo do tempo.
No presente documento, descrevemos como desenvolver uma aborda-

gem orientada a riscos para o Gerenciamento Contínuo de Vulnerabilida-
des, levando em consideração tanto a severidade das vulnerabilidades
quanto à relevância e a exposição dos ativos por elas impactados.
GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 3

Gerenciamento Contínuo
de Vulnerabilidades como
atividade central para
Segurança
Vulnerabilidade é um conceito que encontra

definições variadas em diversas referências
técnicas.
Em uma definição simples, podemos entender vulnerabilidade como uma

fragilidade que pode ser explorada de modo a comprometer a segurança.
Embora vulnerabilidade possa se referir a qualquer tipo de fragilidade —
incluindo falhas em processos e até lacunas de conhecimento em pessoas
— a comunidade de Segurança da Informação associa naturalmente o
termo vulnerabilidade às fragilidades presentes no ambiente tecnológico.
Ao longo desta década, observamos um aumento significativo no

número de vulnerabilidades descobertas.
Segundo o estudo M-Trends 2023, da Mandatian, os exploits - criados

por atacantes para explorar potenciais vulnerabilidades de um sistema -

foram os principais vetores iniciais de infecção, sendo responsáveis por
32% das invasões, ocupando uma posição à frente, inclusive, de ataques
de phishing (22%), já amplamente conhecidos por serem lucrativos para
os invasores.
Fonte: https://www.mandiant.com/m-trends . Julho/2023
Segundo o portal CVE Details, o número de CVEs (Vulnerabilidades e Expo-

sições Comuns) relatados apenas no primeiro semestre de 2023 (14.363)
está quase superando o total registrado em todo o ano de 2017 (14.714).

Fonte: https://www.cvedetails.com/browse-by-date.php . Julho/2023
Vulnerabilidades de segurança podem estar presentes em ativos de tec-

nologia da informação por diversos motivos, mas o tipo mais frequente
de vulnerabilidade de segurança são aquelas inseridas ao longo do pro-
cesso de desenvolvimento de software.
Neste sentido cabe lembrar que “software” está presente em

todo tipo de ativo de tecnologia da informação - desde ativos de
infraestrutura de redes (como switches e roteadores), passando
por software básico (como sistemas operacionais e bancos de
dados) até as aplicações de software para todo tipo de finalidade
(incluindo todo tipo de aplicações web e mobile, por exemplo).
É nesse ponto que a importância do desenvolvimento seguro se destaca

de forma fundamental. A adoção de práticas de desenvolvimento seguro
é essencial para mitigar os riscos associados a essas vulnerabilidades.
Ao incorporar medidas de segurança desde as fases iniciais do processo
de desenvolvimento, como análise de riscos, projeto seguro, codificação

segura, testes de segurança e atualizações regulares, as organizações
podem reduzir significativamente a exposição a ameaças cibernéticas e
proteger seus ativos de tecnologia da informação.
É relevante ressaltar que as vulnerabilidades podem ser introduzidas de

diversas formas - desde falhas no tratamento de dados enviados por usu-
ários a uma aplicação (falha de implementação) até fragilidades na con-
cepção da arquitetura de segurança (falha de concepção) - mas o fato é
que cada uma delas estabelece um potencial cenário de ataque baseada
em sua exploração.
Por exemplo, um tipo de vulnerabilidade conhecida associada a falhas no

tratamento de dados enviados por usuários é a injeção de SQL, onde um
campo de formulário pode ser utilizado por um atacante para enviar um
comando SQL que será indevidamente repassado ao banco de dados,
levando a riscos de vazamento, adulteração ou exclusão dos dados arma-
zenados naquele banco.
Já um exemplo de falha associada à arquitetura de segurança poderia

ser a ausência de autenticação entre dois componentes de software que
interagem por meio de um canal de comunicação aberto, viabilizando
ataques baseados no envio de dados forjados por um atacante que te-
nha acesso àquele canal. Estes exemplos são apenas dois dentre uma
miríade de classes de vulnerabilidades que podem estar presentes em
sistemas de informação; apenas para referência, o CWE, um sistema de
classificação de vulnerabilidades sobre o qual voltaremos a falar mais à
frente, possuía 933 classes de vulnerabilidades em 9 de março de 2023 -
cada uma delas com potencial de danos à integridade, confidencialidade
e disponibilidade, em caso de exploração.

A capacidade de identifi-
car e corrigir vulnerabilida- “identificar
des é uma competência fun- e corrigir
damental para a segurança
vulnerabilidades é
de ambientes tecnológicos.
uma competência
Denominamos Gerenciamento fundamental
Contínuo de Vulnerabilidades para a segurança
(GCV) ao processo que envolve de ambientes
a identificação, avaliação, prio-
rização e mitigação de vulnera-
tecnológicos”
bilidades de segurança em um
ambiente de tecnologia em constante evolução. Por conta da comple-
xidade dinâmica dos atuais ambientes de tecnologia e da sofisticação
cada vez maior dos agentes de ataque, o GCV é uma atividade crítica para
controlar os riscos associados a ataques cibernéticos.
No presente documento, discutimos o conceito de vulnerabilidade e o

modo como uma visão orientada a riscos é essencial para um efetivo ge-
renciamento de vulnerabilidades. Mostramos que o volume de potenciais
vulnerabilidades presentes em qualquer organização é tão elevada que
apenas com uma rigorosa priorização - baseada nos reais riscos à orga-
nização - é possível tratar adequadamente tais vulnerabilidades.
Com o objetivo de fornecer informações abrangentes sobre o GCV, este

material foi organizado em duas partes distintas. Na primeira parte, abor-
daremos os conceitos fundamentais relacionados à vulnerabilidade de
segurança e ao risco cibernético. Já na segunda parte, apresentaremos a
abordagem da Clavis para um gerenciamento efetivo de vulnerabilidades
orientado ao risco, baseada numa plataforma denominada BART1 GCV.
1
BART é o acrônimo para “Baselines, Análise de Riscos e Testes de Segurança”, nome do
projeto que deu origem à plataforma de GCV da Clavis.

Conceito de
Vulnerabilidade
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.
A weakness of an asset or group of assets that can be

Definição exploited by one or more threats.
da ISO/IEC (Uma fraqueza em um ativo ou grupo de ativos que pode ser
27005. explorada por uma ou mais ameaças).

A flaw or weakness in a system’s design, implementation, or
operation and management could be exploited to violate the
system’s security policy.
Definição da (Uma falha ou fraqueza no projeto, implementação ou
RCF 4949
operação e gerenciamento de um sistema que pode ser
explorada para violar a política de segurança do sistema).
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.
Definição da [Falha ou fraqueza em procedimentos, projeto,
NIST SP
implementação ou controles internos de sistemas de
800-30
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].
As três definições acima trazem algumas sutilezas a serem observadas.
Uma dessas sutilezas é a diferença entre “explorar” a vulnerabilidade e

“exercitar” a vulnerabilidade. A palavra exploração remete a uma ação in-
tencional, com o objetivo deliberado de causar dano. Já a palavra “exer-
cício”, como a própria definição da SP 800-30 esclarece, contempla tan-
to 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 im-
previsíveis, tais como catástrofes naturais).

Outra sutileza é o uso das palavras “falhas” e “fragilidades”. A palavra “fa-
lha” 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 fle-
xibilize 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-recomenda-
da, dificilmente poderia ser caracterizada como uma “falha”.
A definição da RFC 4949, inclusive, descreve explicitamente que a vulnera-

bilidade 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 ge-

renciamento são caracterizadas como erros a serem evitadas, mas vulne-
rabilidades 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 concre-
tiza com um acesso indevido a um recurso.

O diagrama a seguir dá uma visão geral da nomenclatura associada a
vulnerabilidades.

Bases de Dados
e Catálogos de
Vulnerabilidades
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 [REPAIRED SECURITY BUGS IN MULTICS, Computer
Systems Research Division Request for Comments No.5, http://web.mit.
edu/Saltzer/www/publications/rfc/csr-rfc-005.pdf ], pesquisador envolvi-
do no projeto do Multics, compila uma lista de formas nas quais um usu-
ário pode contornar os mecanismos de proteção (nas palavras de Saltzer,
“ a list of all known ways in which a user may break down or circumvent
the protection mechanisms of Multics”).

Atualmente, o profissional de Tecno-
logia da Informação tem à sua dispo- “Atualmente, o
sição formidáveis bases de dados de profissional de
vulnerabilidades — abrangentes e con- Tecnologia da
sistentes — que pode consultar com Informação tem
diferentes objetivos. Essas bases de à sua disposição
dados variam, também, em relação ao formidáveis
grau de abstração da vulnerabilidade - bases de
por exemplo, enquanto bases como a dados de
CVE catalogam vulnerabilidades con- vulnerabilidades ”
cretas identificadas em aplicações de
software, bases como a CWE se dedicam a organizar “classes de vulnera-
bilidades”, descrevendo-as de forma mais abstrata/genérica.
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 Vul-
nerabilities 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 é encon-
trada na descrição do “CVE Program” na página oficial https://www.cve.
org/About/Overview.
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 pes-
quisador de segurança identifica uma vulnerabilidade em uma aplicação
de software que esteja no escopo do programa, ele pode entrar em con-

tato 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 es-
copo de aplicações de software, portanto, a CNA contactada irá depender
da aplicação a que se refere a vulnerabilidade. A maior parte das organi-
zações cadastradas como CNA são autorizadas a catalogar vulnerabili-
dades 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 Incor-
porated, Apache Software Foundation, Apple Inc., Facebook, Inc., Free-
BSD, Microsoft Corporation, Netflix, Inc. Samsung Mobile. Alguns CNA
tem 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 Bro-
adcom, Synopsys.
O CVE possuía 206.253 registros de vulnerabilidades conforme pesquisa-

do (www.cve.org/) em 05/07/2023.
Ciclo de vida do registro CVE. Fonte: www.cve.org/About/Process

CWE
CWE é a sigla para Common Weakness Enumeration (https://cwe.mitre.
org/), um sistema de categorização de fragilidades de segurança. O CWE
estabelece uma linguagem comum para referência a fragilidades de se-
gurança, não apenas, nomeando e categorizando fragilidades, mas esta-
belecendo relações entre elas. Ao contrário do CVE, que enumera ocor-
rê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 infor-
mações tais como “Descrição”, “Modos de Instrução”, “Plataformas Apli-
cáveis”, “Consequências”, “Exemplos”, “Mitigações” e “Detecção”. Adi-
cionalmente, são apresentados relacionamentos entre as categorias,
estabelecendo uma estrutura hierárquica na qual é possível compreender
como determinadas categorias generalizam outros conjuntos de catego-
rias. 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 vulne-
rabilidades que nela se baseiam.

O CWE possuía 933 categorias de fragilidades conforme pesquisado
(cwe.mitre.org/data/index.html) em 05/07/2023.
Portal CWE. Fonte: https://cwe.mitre.org/data/index.html
NVD
NVD é a sigla para National Vulnerability Database (https://nvd.nist.gov/),
uma base de dados mantida pelo NIST, órgão do Departamento de Co-
mércio dos Estados Unidos. O NVD é “alimentado” pelo CVE, mas os re-
gistros de vulnerabilidades são complementados com informações valio-
sas; 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.
Portal NVD. Fonte: https://nvd.nist.gov/vuln
CWE TOP 25
O “Top 25” do CWE (https://cwe.mitre.org/top25/archive/2021/2021_
cwe_top25.html) é uma metodologia para selecionar as 25 mais relevan-
tes categorias de fragilidades de software. Esta seleção é feita de ma-
neira 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 obje-
tiva.

2023 CWE Top 25. Fonte: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
OWASP TOP 10
O “Top 10” da OWASP (https://owasp.org/www-project-top-ten/) é meto-
dologia 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.

Portal OWASP Top 10. Fonte: https://owasp.org/Top10/

Severidade de
Vulnerabilidades
Como vimos discutindo ao longo do presente

documento, a enorme quantidade e variedade
de vulnerabilidades potencialmente existentes
em ambientes tecnológicos torna virtualmente
impossível eliminar todas elas.
Tal cenário motiva para a criação de estratégias de priorização de vulne-

rabilidades, de modo que vulnerabilidades de alta criticidade possam ser
priorizadas.
Denominamos severidade de uma vulnerabilidade a qualquer métrica

que atribua um grau de criticidade a uma vulnerabilidade. Existem diver-
sas abordagens para definir a severidade de uma vulnerabilidade; em
geral tais abordagens levam em conta a viabilidade de exploração des-
sa vulnerabilidade e o potencial de dano associado a essa exploração.

CVSS
CVSS é a sigla para Common Vulnerability Scoring System (https://www.
first.org/cvss/). Trata-se de uma sistemática para a definição de métricas
de severidade para vulnerabilidades tão importante que não poderia dei-
xar de ser mencionada.
O CVSS avalia a severidade de uma vulnerabilidade em termos de “explo-

rabilidade” e “impacto”; a metodologia de cálculo de severidade é divulga-
da 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 proje-
to de software.
Portal First. Fonte: https://www.first.org/cvss/
EPSS
EPSS é a sigla para Exploit Prediction Scoring System (first.org/epss/).
Trata-se de um sistema que visa fornecer uma pontuação para prever a
probabilidade de uma vulnerabilidade específica ser explorada no futuro.

O EPSS utiliza uma variedade de fatores, como informações sobre a vul-
nerabilidade, contexto de ameaças e inteligência de segurança, para de-
terminar a pontuação de previsão de exploração.
Essa pontuação auxilia os profissionais de segurança na priorização de

ações e na alocação de recursos para mitigar as vulnerabilidades com
maior probabilidade de serem exploradas.
Portal First. Fonte: https://www.first.org/epss/model
KEV
KEV é a sigla para Known Exploited Vulnerabilities Catalog (cisa.gov/
known-exploited-vulnerabilities-catalog). Trata-se de um catálogo de vul-
nerabilidades conhecidas e exploradas, mantido pelo CISA (Cybersecurity
and Infrastructure Security Agency). O KEV contém informações detalha-
das sobre vulnerabilidades que foram identificadas como exploradas ati-

vamente por atores maliciosos. Essas informações são valiosas para os
profissionais de segurança, permitindo que eles identifiquem e priorizem
ações de mitigação para as vulnerabilidades que representam um maior
risco imediato para os sistemas e redes. O KEV é atualizado regularmente
para refletir as mais recentes ameaças e explorações em curso.
Portal CISA. Fonte: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

O Processo de
Gerenciamento de
Vulnerabilidades
O gerenciamento de vulnerabilidades somente

trará resultados se for tratado na forma de um
processo previsto em políticas e documentado em
procedimentos.
O estabelecimento de um processo formal de gerenciamento de vulnera-
bilidades traz inúmeros benefícios, dentre os quais:
• Redução do risco de ataques: A implementação de um processo de

gerenciamento de vulnerabilidades ajuda a identificar e mitigar vulne-
rabilidades antes que elas possam ser exploradas por atacantes mal-
-intencionados.
• Conformidade regulatória: Muitas regulamentações, como o GDPR

e o PCI DSS, exigem que as organizações implementem medidas de
segurança e gerenciamento de vulnerabilidades para proteger infor-
mações confidenciais.

• Melhoria da confiança do cliente: Quando as organizações demons-
tram que estão tomando medidas proativas para proteger dados
confidenciais, elas aumentam a confiança dos clientes e melhoram a
reputação da empresa.
• Redução de custos: Ao identificar e mitigar vulnerabilidades em um

estágio inicial, as organizações podem evitar custos significativos as-
sociados à correção de falhas de segurança, perda de dados e inter-
rupções de negócios.
• Prevenção de perda de dados: A exploração de vulnerabilidades pode

levar à perda de dados críticos e confidenciais. Um processo de ge-
renciamento de vulnerabilidades ajuda a minimizar o risco de perda
de dados e ajuda as organizações a se prepararem para a recupera-
ção em caso de perda de dados.
O processo de gerenciamento de vulnerabilidades pode ser organizado

como um ciclo que envolve 5 fases:
1 Descoberta: Nesta etapa, as vulnerabilidades são identificadas e

catalogadas por meio de ferramentas de escaneamento e análise de
vulnerabilidades. Isso pode incluir o uso de scanners de vulnerabilida-
des, revisões manuais de código e testes de penetração.
2 Priorização: Depois que as vulnerabilidades são identificadas, elas

são classificadas de acordo com a gravidade e o impacto potencial
em sistemas, aplicativos e dados críticos. Essa etapa ajuda a deter-
minar quais vulnerabilidades devem ser corrigidas primeiro.

3 Correção: Nesta etapa, as vulnerabilidades são corrigidas por meio
de patches, atualizações de software, configurações de segurança e
outras soluções. As correções devem ser cuidadosamente planeja-
das e testadas antes de serem implementadas para garantir que não
causem interrupções ou outros problemas.
4 Verificação: Depois que as correções são implementadas, é impor-

tante verificar se elas foram bem-sucedidas em mitigar as vulnerabili-
dades. Isso pode ser feito por meio de testes de penetração e outras
técnicas para garantir que as vulnerabilidades não possam mais ser
exploradas.
5 Monitoramento contínuo: A última etapa envolve a monitoração

constante para garantir que novas vulnerabilidades não surjam e que
as soluções implementadas estejam funcionando corretamente. Isso
pode envolver a implementação de políticas de segurança, monito-
ramento de log e outras medidas para garantir a proteção contínua
contra ameaças cibernéticas.

Gerenciamento de
Riscos
Para a maioria das finalidades práticas, podemos

dizer que risco é tudo aquilo que pode dar errado.
Ou seja, por mais que busquemos controlar ao máximo a previsibilidade

dos fatos, sempre existe a possibilidade de que eventos não-controlados
venham a impactar negativamente os resultados de uma organização.
Para um exemplo aplicável a qual-

quer área de negócio, imagine que
“sempre existe
um especialista em um projeto im-
a possibilidade
portante pode receber uma proposta
de que eventos
irrecusável para um outro emprego e
não-controlados
abandonar o projeto.
venham a impactar
negativamente ”

Este evento está completamente fora do controle do gerente do projeto, e
o máximo que ele pode fazer é:
1) minimizar a probabilidade de que especialistas abandonem o

projeto, e
2) minimizar o impacto da saída de especialistas para o sucesso do

projeto.
Gerenciamento de riscos é exatamente este processo de identificação,

avaliação e controle de riscos que uma organização pode enfrentar em
suas atividades diárias. É uma atividade crítica em qualquer negócio, pois
ajuda a minimizar as perdas e maximizar as oportunidades, garantindo
que a organização esteja preparada para lidar com riscos que possam
afetar seu desempenho. Existem inúmeras definições para riscos e vários
processos formais para o gerenciamento de riscos. Não é nosso objetivo,
aqui, realizar uma exposição aprofundada sobre o que é risco - mas uma
caracterização importante e bastante difundida sobre riscos é aquela que
considera sua probabilidade e seu impacto:
Risco = Probabilidade x Impacto
Ou seja, um risco é caracterizado pela probabilidade de que um evento o

concretize combinado (em termos quantitativos, por uma multiplicação)
com o impacto deste evento, caso ele se concretize. Esta definição é bas-
tante prática, uma vez que ela sinaliza para as possíveis abordagens para
tratar riscos: pode-se atuar na redução de probabilidades e pode-se atuar
na redução de impactos. Os chamados controles são justamente as pro-
vidências que atuam nas probabilidades e impactos de riscos.

Riscos
Cibernéticos
No mundo da Segurança da Informação, os

principais riscos que devem ser observados são
associados àqueles eventos que podem acometer
os ativos de informação, especialmente, os ativos
tecnológicos que armazenam, processam e
transmitem informação.
Estamos falando de eventos adversos que podem atingir a computado-

res, servidores, equipamentos de rede e aplicações de software.
Em geral, esta classe de riscos é conhecida como riscos cibernéticos.
Naturalmente, falhas espontâneas devem ser consideradas neste conjun-

to de riscos cibernéticos; porém, os riscos mais preocupantes, nos dias
de hoje, são aqueles relacionados a eventos de ataques cibernéticos - ou

seja, ações maliciosas intencionais reali-
zadas por indivíduos/agentes com obje- “a existência da
tivo deliberado de causar dano. É nesse vulnerabilidade
momento em que as vulnerabilidades de é o que viabiliza
segurança (ou, esperamos, seu adequa- a ocorrência de
do gerenciamento) assumem um papel um ataque ”
decisivo.
Vulnerabilidades de segurança são exatamente as fragilidades que po-

dem ser exploradas em um ataque cibernético. Ou seja, a existência da
vulnerabilidade é o que viabiliza a ocorrência de um ataque - e as carac-
terísticas da vulnerabilidade ajudarão a caracterizar o risco, tanto em ter-
mos de sua probabilidade quanto em termos de seu impacto.
A caracterização das vulnerabilidades existentes no ambiente tecnológi-

co de uma organização é fundamental para a plena compreensão dos
riscos de ataques cibernéticos.
No entanto, as métricas de severidade que apresentamos nas seções an-

teriores, tais como o CVSS e mesmo o EPSS, não são suficientes para
uma estimativa precisa das probabilidades e impactos de ataques decor-
rentes da exploração de uma vulnerabilidade.
Argumentamos que tais métricas precisam ser complementadas com in-

formações sobre os ativos que possuem vulnerabilidades.
Mais precisamente, propomos que, para cada vulnerabilidade identificada

em um ambiente tecnológico, as duas informações principais sejam a ela
associadas:

1) Exposição do Ativo. Refere-se ao grau de dificuldade para acessar
o ativo. Depende do local e do período de tempo de operação do ativo. Um
computador de um funcionário que esteja operando em uma rede interna
em regime 8x5 (8 horas por dia e 5 dias por semana) tem uma exposição
menor do que um servidor operando em regime 24x7 na mesma rede
interna, que por sua vez, tem uma exposição menor do que um servidor
web operando na “borda” da rede corporativa.
A exposição do ativo tem efeito claro na métrica de probabilidade asso-

ciada ao risco de um ataque cibernético.
2) Relevância do Ativo. Refere-se à importância do ativo para a organi-

zação. Depende das atividades em que o ativo está envolvido.
O computador de um estagiário provavelmente tem menos relevância

que o computador de um gerente, que por sua vez, tem uma relevância
menor do que o servidor onde é executada a aplicação web responsável
pela principal fonte de receita da organização.
A relevância do ativo tem efeito claro na métrica de impacto associada ao

risco de um ataque cibernético.
As informações acima somente podem ser adequadamente estimadas

por indivíduos que tenham um conhecimento pleno tanto sobre o am-
biente tecnológico quanto sobre os aspectos estratégicos do negócio da
organização.
Além das informações acima, informações sobre ameaças correntes po-

dem ajudar a ter uma visão ainda mais precisa sobre probabilidades de
ataque.

Existência de “exploits on the wild”. Significa que existem ferramentas
de exploração da vulnerabilidade em questão facilmente disponíveis a po-
tenciais atacantes.
Vulnerabilidade de tendência. Significa que está sendo observada uma

tendência de exploração desta ameaça, em particular, por parte de ata-
cantes.
Deve-se considerar as características particulares da organização em

questão (dimensões da organização, perfil dos colaboradores, setor de
atuação, grau de visibilidade e exposição à mídia, etc.)
As informações acima te podem ser adequadamente estimadas por meio

de uma atuação cuidadosa no campo de inteligência de ameaças (threat
intelligence) - especialmente, quando se considera as ameaças à organi-
zação, em particular.

A Plataforma
BART GCV
Para colocar em prática o conceito de

Gerenciamento Contínuo de Vulnerabilidades
orientado a risco, a Clavis desenvolveu uma
plataforma denominada BART - acrônimo
para Baselines, Análise de Riscos e Testes de
Segurança.
O BART GCV tem como objetivo viabilizar o apoio ao ciclo de vida de ge-
renciamento contínuo de vulnerabilidades em uma abordagem orientada
a riscos.
Para isso, o BART GCV possui um módulo orientado à identificação de

ativos e à descoberta de vulnerabilidades e um módulo orientado ao “en-
riquecimento” das vulnerabilidades com vistas à caracterização de riscos.

Por meio da plataforma BART, é possível
executar um processo prático e eficaz na “permite dar
gerência de vulnerabilidades, atuando na um tratamento
identificação de vulnerabilidades, na ca- unificado a
racterização dos riscos reais ao negócio, todo tipo de
no planejamento de correções e no acom- vulnerabilidade
panhamento da execução. corporativa ”
A plataforma BART é tão poderosa que
permite dar um tratamento unificado a todo tipo de vulnerabilidade cor-
porativa, incluindo aquelas relacionadas a não conformidades em proces-
sos e políticas.
O BART é reconhecido pelo Ministério da Defesa como Produto de Defesa

e significa que o BART é uma plataforma importante para as atividades
finalísticas de defesa.

Premissas fundamentais do BART:
Centralização de informações:
Todos os dados dos ativos monitorados são concentrados em um

dashboard que fornece ao cliente recursos essenciais para o adequado
gerenciamento de vulnerabilidades, incluindo a geração de relatórios, a
quantificação dos riscos associados a vulnerabilidades e os métodos
para a correção de vulnerabilidades, dentre outros.
Mapeamento de ativos:
A plataforma BART permite identificar e classificar os ativos de uma orga-

nização, como dispositivos computacionais, aplicações web e domínios
associados à organização.
Monitoramento de ativos:
A plataforma BART permite monitorar comportamento de ativos de rede,

sendo capaz de identificar mudanças na configuração de equipamentos e
outros ativos, tanto com a finalidade de identificar vulnerabilidades quan-
to com a finalidade de verificação de aderência a políticas corporativas.
Baselines de Segurança:
A plataforma BART realiza avaliações automáticas das configurações de

redes, sistemas e aplicações, permitindo verificar a conformidade a pa-
drões de segurança previamente estabelecidos.

Múltiplos perfis de usuários:
A plataforma BART permite a criação de usuários com diversos perfis de

acesso, de modo a facilitar o acompanhamento pelos colaboradores da
organização.
Emissão de alertas de vulnerabilidades:
A plataforma BART emite alertas que apontam para surgimento de vulne-

rabilidades não-conformidades nos ativos monitorados.
Boletim de ameaças:
A plataforma BART oferece ao administrador boletins periódicos que

apresentam as novas vulnerabilidades conhecidas pela comunidade e
que afetem os ativos da organização.
Tratamento de vulnerabilidades:
Por meio da validação manual e interpretação da severidade das vulnera-

bilidades, e levando em consideração a dificuldade de exploração da vul-
nerabilidade e os impactos nas atividades-fim da organização, os analis-
tas da Clavis elaboram e acompanham, em parceria com um cliente, um
plano de tratamento de vulnerabilidades que otimiza recursos e prioriza
as ações de maior impacto.

Perguntas Frequentes sobre
Modelo BART GCV
Encerramos este documento apresentando

perguntas frequentes sobre modelo BART GCV
da Clavis.
1. Quais são os benefícios de utilizar o Bart GCV?
Resposta: O Bart GCV permite que as organizações tenham uma visão

abrangente de suas configurações de segurança, identifiquem vulnerabi-
lidades em seus sistemas e tomem medidas para mitigar os riscos. Isso
ajuda a proteger os ativos de informação, reduzir a exposição a ameaças
e garantir a conformidade com normas e regulamentos.
2. Como o Bart GCV identifica as vulnerabilidades?
Resposta: O Bart GCV utiliza uma combinação de ferramentas de var-

redura automatizada, análise de configurações e identificação de falhas

conhecidas para identificar as vulnerabilidades em sistemas e infraestru-
tura. Além disso, é possível realizar testes de penetração e análise manual
de código, se necessário.
3. Quais são as etapas do processo de gestão de configuração e

vulnerabilidade com o Bart GCV?
Resposta: O processo com o Bart GCV inclui as seguintes etapas: iden-

tificação e documentação das configurações de segurança existentes,
avaliação de vulnerabilidades, priorização de riscos, implementação de
medidas corretivas, monitoramento contínuo e revisões periódicas para
garantir a eficácia das medidas adotadas.
4. Como a Clavis Segurança da Informação pode ajudar na imple-

mentação do Bart GCV?
Resposta: A Clavis oferece consultoria especializada para auxiliar as or-

ganizações na implementação do Bart GCV. Isso inclui a configuração das
ferramentas de varredura, análise de configurações, criação de políticas
de segurança, treinamento de equipes e suporte contínuo para garantir o
sucesso do processo de gestão de configuração e vulnerabilidade.
5. O Bart GCV é adequado para todas as organizações?
Resposta: Sim, o Bart GCV pode ser adaptado para atender às necessida-
des de diferentes organizações, independentemente do tamanho ou setor
em que atuam. As configurações e vulnerabilidades podem variar, mas o
processo de gestão e as ferramentas utilizadas pelo Bart GCV podem ser
personalizados para cada caso.

6. Quais são os resultados esperados com a implementação do
Bart GCV?
Resposta: Com o Bart GCV, as organizações podem esperar reduzir o

número de vulnerabilidades em seus sistemas, melhorar a segurança
de suas configurações, mitigar riscos de ataques cibernéticos, garantir a
conformidade com normas e regulamentos, e aumentar a confiabilidade
e disponibilidade de seus sistemas de informação.

Contato com a Clavis
A Clavis está sempre à disposição para marcar reuniões a respeito de

suas soluções. Basta entrar em contato por algum dos diversos canais
disponíveis, seja via formulário no site da Clavis, seja via email, seja via
telefone, onde atendemos tanto por voz quanto WhatsApp.
E-mail: contato@clavis.com.br
Telefone: (21) 2210-6061 | (21) 2561-0867
Whatsapp: (21) 97915-9602 | (21) 96551-2568
www.clavis.com.br

Ebook GCV Versao Final

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ebook GCV Versao Final

Enviado por

Direitos autorais:

Formatos disponíveis

GCV - GERENCIAMENTO

Especialistas em Segurança da Informação

No entanto, tal tarefa sempre foi um desafio: o contínuo surgimento de

No presente documento, descrevemos como desenvolver uma aborda-

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 3

Vulnerabilidade é um conceito que encontra

Em uma definição simples, podemos entender vulnerabilidade como uma

Ao longo desta década, observamos um aumento significativo no

Segundo o estudo M-Trends 2023, da Mandatian, os exploits - criados

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 4

Fonte: https://www.mandiant.com/m-trends . Julho/2023

Segundo o portal CVE Details, o número de CVEs (Vulnerabilidades e Expo-

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 5

Vulnerabilidades de segurança podem estar presentes em ativos de tec-

Neste sentido cabe lembrar que “software” está presente em

É nesse ponto que a importância do desenvolvimento seguro se destaca

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 6

É relevante ressaltar que as vulnerabilidades podem ser introduzidas de

Por exemplo, um tipo de vulnerabilidade conhecida associada a falhas no

Já um exemplo de falha associada à arquitetura de segurança poderia

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 7

No presente documento, discutimos o conceito de vulnerabilidade e o

Com o objetivo de fornecer informações abrangentes sobre o GCV, este

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 8

Vulnerabilidades de Segurança — no contexto

A weakness of an asset or group of assets that can be

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 9

A flaw or weakness in system security procedures, design,

As três definições acima trazem algumas sutilezas a serem observadas.

Uma dessas sutilezas é a diferença entre “explorar” a vulnerabilidade e

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 10

Ou seja, um erro de programação que viabilize um buffer overflow ou inje-

A definição da RFC 4949, inclusive, descreve explicitamente que a vulnera-

Em geral, vulnerabilidades associadas a implementação, operação e ge-

De todo modo, o efeito final de uma vulnerabilidade, quando explorada

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 11

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 12

Dada a importância da questão das

De fato, são conhecidos esforços no sentido de catalogar vulnerabilidades

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 13

Listamos, a seguir, as principais bases de dados destinadas a catalogar e

CVE é um catálogo de ocorrências de vulnerabilidades nas aplicações de

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 14

Exemplos de CNA autorizadas a operar no programa CVE cadastrando

O CVE possuía 206.253 registros de vulnerabilidades conforme pesquisa-

Ciclo de vida do registro CVE. Fonte: www.cve.org/About/Process

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 15

Por exemplo, os CVEs CVE-2022-28116, CVE-2020-13118 e CVE-2016-

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 16

Portal CWE. Fonte: https://cwe.mitre.org/data/index.html

A associação entre vulnerabilidade (CVE), categoria de fragilidade (CWE)

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 17

Portal NVD. Fonte: https://nvd.nist.gov/vuln

A lista Top 25 contém os 25 CWEs com maior ocorrência de CVEs e com

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 18

Além disso, a composição das categorias segue critérios atualizados a

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 19

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 20

Como vimos discutindo ao longo do presente

Tal cenário motiva para a criação de estratégias de priorização de vulne-

Denominamos severidade de uma vulnerabilidade a qualquer métrica

GERENCIAMENTO CONTÍNUO DE VULNERABILIDADES 21

O CVSS avalia a severidade de uma vulnerabilidade em termos de “explo-