Ativos, ameaças, vulnerabilidades e riscos

Risco começa pelo que pode ser afetado

Em Segurança da Informação, risco não é sinônimo de ameaça, vulnerabilidade, falha ou incidente. Risco descreve uma situação de incerteza: algo pode acontecer, atingir um ativo e produzir consequências para pessoas ou objetivos da organização.

Uma forma inicial de organizar o raciocínio é perguntar:

1. o que possui valor e precisa ser preservado?
2. quem ou o que pode iniciar uma situação adversa?
3. qual evento pode ocorrer?
4. qual fraqueza ou condição favorece esse evento?
5. quais consequências podem surgir e quão plausíveis são?

Na aula sobre confidencialidade, integridade e disponibilidade, vimos quais propriedades podem ser prejudicadas. Agora o foco é construir o cenário que explica como essa perda pode acontecer e por que ela importa.

Ativo: algo de valor para um objetivo

Ativo é algo que possui valor para uma pessoa ou organização. Pode ser tangível, como um servidor ou edifício, ou intangível, como informação, conhecimento, reputação, capacidade, serviço e confiança.

Em uma plataforma de aprendizagem, são exemplos de ativos:

• dados de estudantes e docentes;
• contas e credenciais de acesso;
• conteúdo didático e registros acadêmicos;
• aplicações, equipamentos e conexões;
• profissionais e conhecimento operacional;
• disponibilidade das aulas e confiança na instituição.

Uma lista de equipamentos, portanto, não representa todo o universo de ativos. O servidor tem importância porque sustenta dados, serviços e resultados. A conta administrativa importa porque permite executar ações de grande alcance. O valor nasce da relação com aquilo que precisa continuar funcionando ou sendo protegido.

O conteúdo sobre conceitos fundamentais de Gestão de TI apresenta ativo no contexto mais amplo de recursos, produtos e serviços. Nesta aula, ativo é o ponto de referência para entender perdas de segurança.

Fonte de ameaça e evento de ameaça não são a mesma coisa

Uma fonte de ameaça é quem ou o que pode iniciar ou causar um evento adverso. Ela não precisa ser uma pessoa mal-intencionada. O NIST organiza fontes que incluem ações hostis, erros humanos, falhas estruturais e acontecimentos naturais ou acidentais.

Exemplos de fontes:

• uma pessoa externa tentando obter acesso indevido;
• um profissional que comete um erro sem intenção;
• uma falha de hardware ou software;
• interrupção de energia ou de fornecedor;
• incêndio, alagamento ou outro evento ambiental.

O evento de ameaça é a situação que essa fonte pode iniciar ou causar e que possui potencial de gerar consequências indesejadas. “Pessoa mal-intencionada” descreve uma fonte; “usar uma credencial obtida por fraude para entrar na conta administrativa” descreve um evento.

Essa distinção melhora a análise. Fontes diferentes podem causar o mesmo evento: um serviço pode ficar indisponível devido a ataque, erro de configuração, defeito de equipamento ou falha elétrica. Da mesma forma, uma fonte pode iniciar vários eventos.

Vulnerabilidade: uma fraqueza que pode ser explorada ou acionada

Vulnerabilidade é uma fraqueza em sistema, procedimento, controle ou implementação que pode ser explorada ou acionada por uma fonte de ameaça. Embora o termo apareça muito em notícias sobre software, seu alcance é maior.

Uma vulnerabilidade pode estar em:

• tecnologia: componente desatualizado, configuração inadequada ou validação insuficiente;
• processo: aprovação sem verificação independente ou mudança sem revisão;
• pessoas e organização: privilégios incompatíveis, responsabilidades indefinidas ou treinamento insuficiente;
• ambiente físico: equipamento sensível exposto ou acesso físico sem proteção adequada;
• relações externas: dependência sem alternativas ou responsabilidades contratuais ambíguas.

No exemplo desta aula, a conta administrativa aceita somente senha. Isso não causa automaticamente um comprometimento, mas amplia a possibilidade de que uma senha obtida por fraude seja suficiente para acessar a plataforma.

Uma condição predisponente é uma característica do contexto que pode aumentar ou diminuir a chance de um evento resultar em impacto. Dependência de uma única conta administrativa, equipe reduzida em um horário crítico ou arquitetura muito concentrada são exemplos. Nem toda condição é uma falha corrigível; às vezes ela precisa ser considerada nas decisões e compensada por outras medidas.

Como os elementos formam um cenário de risco

Os conceitos ganham utilidade quando são conectados. A cadeia abaixo não é uma fórmula rígida nem significa que todo evento seguirá uma sequência linear. Ela serve para verificar se a descrição possui causa, exposição e consequência compreensíveis.

Considere este cenário:

Devido à possibilidade de uma tentativa de phishing obter a senha de uma conta administrativa sem autenticação multifator, uma pessoa não autorizada pode acessar a plataforma de aprendizagem, alterar configurações e expor registros, causando interrupção das aulas, trabalho de recuperação e perda de confiança.

Nessa descrição:

• ativos: plataforma, registros, continuidade das aulas e confiança;
• fonte de ameaça: pessoa que conduz a tentativa de fraude;
• evento inicial: envio de uma solicitação enganosa e obtenção da senha;
• vulnerabilidade: acesso administrativo dependente apenas da senha;
• evento com efeito: uso indevido da conta e alteração ou consulta de recursos;
• impactos: indisponibilidade, exposição, retrabalho e dano à confiança.

O cenário não afirma que o evento ocorrerá. Ele torna explícita a possibilidade que precisa ser compreendida e decidida.

Um mapa para não confundir os termos

Cada termo responde a uma pergunta diferente. Se a resposta de um campo apenas repete outro, a análise provavelmente está incompleta.

Uma vulnerabilidade sem cenário e ativo associados é apenas uma informação técnica incompleta para a decisão. Uma ameaça sem consequência definida também não informa prioridade. O risco aparece na relação entre os elementos.

Probabilidade, impacto e incerteza

O NIST descreve risco como uma medida da extensão em que uma entidade está ameaçada por uma circunstância ou evento, normalmente em função de duas dimensões: impactos adversos e probabilidade de ocorrência.

Probabilidade procura estimar quão plausível é o evento dentro de um período e contexto. Ela pode considerar:

• exposição e frequência das situações relevantes;
• capacidade, intenção e direcionamento de fontes humanas adversas;
• ocorrência de erros, falhas e eventos ambientais;
• vulnerabilidades e condições predisponentes;
• presença e efetividade das medidas existentes;
• histórico útil, mudanças recentes e qualidade das evidências.

Impacto representa a magnitude do dano caso o evento produza consequências. Pode envolver pessoas, missão, operações, finanças, obrigações, reputação, outros parceiros e a sociedade. O mesmo evento técnico gera impactos diferentes conforme o ativo, o momento e as dependências.

Probabilidade e impacto não precisam ser multiplicados numericamente. Métodos qualitativos, semiquantitativos e quantitativos podem ser válidos quando possuem critérios consistentes e são adequados à decisão. Rótulos como “baixo”, “médio” e “alto” só ajudam se a organização definir o que significam.

Toda estimativa contém incerteza. Dados podem ser incompletos, controles podem não ter sido testados e o ambiente pode mudar. Registrar suposições e grau de confiança é mais honesto do que apresentar precisão inexistente.

Risco inerente e risco residual

Risco inerente é o risco considerado na ausência de ações diretas ou focadas da gestão para alterar sua severidade. Ele ajuda a compreender a exposição original do cenário conforme a definição e o método adotados.

Risco residual é o que permanece depois que essas ações são aplicadas e avaliadas. No exemplo, autenticação multifator, redução de privilégios, verificação de solicitações e monitoramento podem diminuir a probabilidade ou limitar consequências. Ainda assim, erros, falhas, novas formas de fraude e limitações dos controles permanecem possíveis.

Os termos dependem de uma linha de base clara. Se equipes diferentes incluem medidas distintas ao estimar “risco inerente”, os resultados deixam de ser comparáveis. Por isso, método, momento da avaliação, controles considerados e responsável precisam ser registrados.

Um registro de risco para apoiar decisões

Um registro de risco organiza informações suficientes para que responsáveis priorizem, acompanhem e revisem um cenário. Não é apenas uma lista de vulnerabilidades nem um arquivo mantido exclusivamente pela equipe de segurança.

Campos introdutórios úteis incluem:

• identificador e descrição clara do cenário;
• ativos, objetivos e partes afetadas;
• fontes, eventos, vulnerabilidades e condições relevantes;
• probabilidade, impacto, nível de risco e incerteza;
• medidas existentes e evidências de efetividade;
• resposta planejada, responsável e prazo;
• risco residual, decisão e data de revisão.

No cenário da plataforma, a avaliação inerente pode indicar probabilidade e impacto elevados. Após controles adequadamente implementados e testados, a probabilidade pode cair, enquanto o impacto potencial de um acesso administrativo continua relevante. O risco residual precisa ser revisto porque contas, processos, ameaças e dependências mudam.

O NIST CSF 2.0 trata a identificação de ativos, ameaças, vulnerabilidades, probabilidades e impactos como resultados que sustentam a compreensão, priorização e comunicação do risco. O framework não obriga uma fórmula única; a organização adapta práticas ao próprio contexto.

Como escrever uma descrição útil de risco

Uma frase estruturada facilita revisão sem virar modelo obrigatório:

Devido a [fonte ou condição], pode ocorrer [evento], afetando [ativo ou objetivo] e causando [consequências].

Depois, registre vulnerabilidades, controles, probabilidade, impacto e incertezas em campos próprios. Separar esses elementos evita frases circulares como “há risco de um risco de segurança acontecer”.

Antes de aceitar a descrição, verifique:

1. existe algo de valor claramente identificado?
2. o evento está escrito como uma possibilidade concreta?
3. fonte, evento e vulnerabilidade estão separados?
4. as consequências explicam efeitos sobre objetivos ou pessoas?
5. probabilidade e impacto usam critérios conhecidos?
6. controles existentes possuem evidências, não apenas intenção?
7. há responsável e momento para nova avaliação?

Esse roteiro não substitui um método formal. Ele melhora a qualidade da informação que alimentará a avaliação e a decisão.

Erros comuns ao analisar riscos

• chamar a vulnerabilidade de risco: a fraqueza é um componente; falta explicar evento, ativo e consequência;
• tratar ameaça como pessoa mal-intencionada apenas: erros, falhas e eventos ambientais também podem iniciar cenários;
• confundir risco com incidente: risco é possibilidade sob incerteza; incidente é uma ocorrência analisada e respondida;
• atribuir valor somente ao equipamento: dados, pessoas, serviços, reputação e capacidades também são ativos;
• usar números sem critérios: uma nota transmite falsa precisão quando escala e evidências não são compreendidas;
• ignorar controles existentes: a avaliação pode exagerar exposição se não considerar medidas efetivas;
• considerar controle como garantia: controles podem falhar, ser contornados ou introduzir novos efeitos;
• buscar risco zero: decisões reais procuram níveis compatíveis com objetivos, limites e recursos.

O que você deve guardar

Ativo é algo de valor. Fonte de ameaça é quem ou o que pode causar uma situação adversa. Evento de ameaça é aquilo que pode acontecer. Vulnerabilidade é uma fraqueza explorável ou acionável. Probabilidade estima a plausibilidade do cenário; impacto representa a magnitude das consequências; risco reúne essas dimensões sob incerteza para apoiar uma decisão.

Risco inerente observa o cenário antes de ações focadas para alterar sua severidade. Risco residual é o que permanece depois delas. A próxima aula mostrará como controles administrativos, técnicos e físicos podem atuar em diferentes pontos do cenário e formar defesa em profundidade.

Referências

• NIST — SP 800-30 Rev. 1: Guide for Conducting Risk Assessments. Acesso em 28 ago. 2026.
• NIST — IR 8286 Rev. 1: Integrating Cybersecurity and Enterprise Risk Management. Acesso em 28 ago. 2026.
• NIST — IR 8286A Rev. 1: Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management. Acesso em 28 ago. 2026.
• NIST — Cybersecurity Framework 2.0. Acesso em 28 ago. 2026.
• NIST CSRC Glossary — Asset, Threat Source, Threat Event, Vulnerability, Predisposing Condition e Risk. Acesso em 28 ago. 2026.