VERIS (Vocabulário para Registro de Incidentes)

Nota do capítulo 04 (Modelos e Frameworks para CTI).
Apresenta o VERIS (Vocabulary for Event Recording and Incident Sharing): um vocabulário comum para registrar incidentes, suas categorias e o uso interno como taxonomia de comparação.
Dialoga com o Diamond Model e a Cyber Kill Chain deste capítulo, com o ciclo de inteligência do capítulo 01 e com os controles de resposta a incidentes da seção 15.

1. Contexto e Posicionamento na Biblioteca

O ATT&CK nomeia o comportamento do adversário, o Diamond Model estrutura cada evento em quatro vértices e a Kill Chain organiza a intrusão em fases; falta ao conjunto um instrumento para registrar o incidente consolidado de forma que equipes diferentes, em anos diferentes, produzam registros comparáveis. Esse é o papel do VERIS (Vocabulary for Event Recording and Incident Sharing), um framework aberto, publicado em formato de esquema JSON, que define o vocabulário comum para descrever quem fez o quê, contra qual ativo, com qual atributo afetado, como foi descoberto, em que linha do tempo e com qual impacto. O framework nasceu por volta de 2011, conduzido pela Verizon com contribuições da comunidade, exatamente para resolver o problema que a própria Verizon enfrentava ao consolidar milhares de casos: sem vocabulário comum, estatística é impossível.

Na biblioteca, esta nota segue o Diamond Model e herda explicitamente a separação entre ator, ação, ativo e resultado, elevando-a do evento para o incidente fechado. O registro VERIS é o elo entre a resposta a incidentes e a produção de inteligência: os controles IR.2 e IR.4 da seção 15 classificam e encerram casos, o CTI.9 fecha o ciclo com feedback, e este vocabulário é o formato que transforma aqueles casos em matéria-prima comparável para os requisitos de inteligência do capítulo 01. O leitor deve sair daqui sabendo descrever um incidente nas categorias do VERIS, entender o que o DBIR demonstra em escala e decidir quais incidentes internos alimentam a produção de inteligência.

2. O Problema do Registro Ad Hoc e a Proposta do VERIS

O registro ad hoc de incidentes tem sempre o mesmo destino: cada analista escreve na forma que aprendeu, campos obrigatórios mudam de significado entre equipes, e a base acumulada não suporta nenhuma pergunta que exija comparação. Perguntas simples, como qual proporção de incidentes começou por credencial roubada ou quanto tempo separa o comprometimento da descoberta, tornam-se inviáveis sem padronização, porque a resposta depende de reconstruir caso a caso o que cada registro quis dizer. Em escala de indústria, com milhares de casos por ano, o problema é ordens de magnitude maior, e foi nesse contexto que o VERIS foi concebido como vocabulário aberto em vez de ferramenta: o framework define campos, valores controlados e regras de preenchimento, e cada organização escolhe onde armazenar e como processar.

A proposta tem três decisões de desenho que explicam sua longevidade. A primeira é o formato: o esquema em JSON é legível por máquina, versionável e naturalmente integrável a pipelines e a plataformas como MISP e OpenCTI. A segunda são os valores controlados: a maior parte dos campos usa enumeradores fechados, o que força a disciplina de comparação, mesmo quando a precisão individual é menor. A terceira é a honestidade da incerteza: campos de confiança, de valores desconhecidos e de incidentes não confirmados fazem parte do desenho, porque um vocabulário que obrigaria a chutar produziria estatística bonita e falsa.

3. As Categorias do Vocabulário

O VERIS organiza o registro em categorias fixas, e cada uma responde a uma pergunta do incidente. A tabela abaixo resume as categorias centrais com exemplos de valores típicos, e a leitura por linha mostra que o conjunto cobre o ciclo completo: de quem agiu até quanto custou.

Duas categorias costumam gerar dúvida e merecem precisão. O attribute é a pergunta de CIA em linguagem de incidente: a confidencialidade registra se houve disclosure e que tipo de dado, a integridade registra o que foi alterado e a disponibilidade registra o que parou e por quanto tempo. A timeline registra intervalos estimados, e não certezas forenses: o campo de comprometimento aceita unidades como minutos ou semanas precisamente porque o ponto exato raramente é conhecido, e estimar honestamente dentro de uma faixa vale mais que deixar o campo vazio.

O vocabulário conversa com os outros modelos do capítulo, e essa correspondência é o que permite converter registros em análise sem retrabalho. A tabela abaixo mapeia as categorias do VERIS para os componentes do Diamond Model e para o vocabulário do ATT&CK, e mostra que o registro consolidado nada mais é que a soma estruturada dos eventos que o Diamond modela individualmente.

4. Exemplo de Registro Simplificado

O registro abaixo descreve em VERIS um incidente realista de phishing com roubo de credenciais, com valores abreviados para caber na nota. Na prática, o esquema oficial impõe enumeradores completos e validação automatizada, mas a estrutura de raciocínio é exatamente esta.

{
  "incident_id": "INC-2025-0417",
  "security_incident": "Yes",
  "confidence": "High",
  "summary": "Phishing com roubo de credenciais e acesso a caixa corporativa",
  "victim": {"industry": "52", "country": "BR", "employee_count": "Large"},
  "actor": [
    {"external": {"variety": ["Organized crime"], "motive": ["Financial"]}}
  ],
  "action": [
    {"social": {"variety": ["Phishing"], "vector": ["Email"]}},
    {"hacking": {"variety": ["Use of stolen creds", "C2"],
                 "vector": ["Web application"]}}
  ],
  "asset": [
    {"assets": [{"variety": "P.personnel"}, {"variety": "N.server", "cloud": "Yes"}]}
  ],
  "attribute": {
    "confidentiality": {
      "data_disclosure": "Yes",
      "data": [{"variety": "Credentials", "amount": 120}]
    },
    "availability": {
      "variety": ["Loss of productivity"],
      "duration": {"unit": "Hours", "value": 8}
    }
  },
  "discovery_method": {"external": {"variety": ["Customer"]}},
  "timeline": {
    "compromise": {"unit": "Minutes"},
    "exfiltration": {"unit": "Hours", "value": 3},
    "discovery": {"unit": "Days", "value": 12},
    "containment": {"unit": "Hours", "value": 6}
  },
  "impact": {"overall_rating": "Minor", "iso_currency_code": "BRL",
             "cost_corrective_action": 48000},
  "targeted": "Opportunistic"
}

A leitura do registro mostra a força do vocabulário: sem ler o relatório narrativo, qualquer ferramenta já sabe que o vetor foi e-mail, que o motivo é financeiro, que a descoberta veio de fora, que levaram doze dias entre comprometimento e descoberta e que o incidente foi oportunista. Esses campos são os que, agregados, respondem as perguntas de gestão que nenhum relatório isolado responde.

5. O DBIR como Aplicação em Escala

O DBIR (Data Breach Investigations Report), publicado anualmente pela Verizon, é a demonstração de escala do VERIS: o relatório consolida milhares de incidentes e dezenas de milhares de eventos de segurança por edição, todos descritos no vocabulário, e é justamente a comparabilidade que permite extrair padrões intitulados, como ataques básicos a aplicações web, intrusão de sistema, engenharia social e erro diverso. Os números do DBIR, como a dominância persistente do uso de credencial roubada, do phishing e do erro humano em grande parte dos casos, só são possíveis porque milhares de organizações descreveram incidentes nos mesmos termos.

A lição metodológica para a organização é direta e independe de contribuir com dados ao relatório. O que o DBIR prova é que registro padronizado acumulado vira conhecimento estatístico, e essa prova vale na escala interna tanto quanto na escala setorial: três anos de incidentes registrados em VERIS permitem responder qual vetor domina, qual tempo médio de descoberta e qual atributo mais custou, com números próprios que valem mais que benchmarks genéricos. As edições do DBIR continuam úteis como referência setorial para os requisitos de inteligência do capítulo 01, e a comparação entre o padrão público e o padrão interno, setor contra própria base, é um dos exercícios analíticos mais produtivos que um programa de CTI pode executar.

6. Uso Interno: Taxonomia de Incidentes e Comparabilidade

Adotar o VERIS internamente é um projeto de taxonomia, e não de software, e começa por três decisões de governança. A primeira é o momento do registro: o vocabulário entra na triagem do IR.2 como campos estruturados do ticket, e não como formulário retrospectivo no encerramento, porque a timeline estimada só é confiável quando registrada durante a investigação. A segunda é o dono do esquema: cada organização define quais campos são obrigatórios na sua realidade, e o mínimo viável razoável inclui actor, action, asset, attribute, discovery_method, timeline e impact. A terceira é a revisão: um comitê leve revisa trimestralmente os enumeradores locais, resolve casos ambíguos e documenta decisões, porque a taxonomia que não evolui com o ambiente vira formalidade ignorada.

Os retornos aparecem em três frentes mensuráveis. Na métrica, o MET.3 passa a calcular tempo de descoberta e de contenção a partir dos campos de timeline, com série histórica consistente, e o MET.1 mede a distribuição de ações e atores ao longo do ano. Na gestão de risco, a distribuição interna de action e attribute mostra onde a organização realmente perde, o que raramente coincide com a percepção de quem só vê os casos famosos. Na comunicação, o registro estruturado permite que o CTI.7 produza relatórios com números comparáveis entre trimestres, e que a diretoria acompanhe tendência, e não apenas episódios.

O caminho de adoção que funciona é incremental, e vale registrá-lo como sequência de passos, porque a tentativa de implantar o esquema completo de uma vez é o motivo mais comum de abandono.

• Mapear os campos que o ticket de IR hoje preenche para o enumerador VERIS mais próximo, documentando cada decisão de mapeamento com exemplo real.
• Definir um mínimo obrigatório enxuto, tipicamente actor, action, asset, attribute, discovery_method, timeline e impact, e deixar o restante opcional com incentivo de preenchimento.
• Treinar o time de resposta com três casos históricos reais do próprio ambiente, comparando os registros produzidos por analistas diferentes e resolvendo divergências.
• Automatizar a validação contra o esquema, com rejeição de valores fora dos enumeradores e campo de texto livre separado para nuance.
• Revisar trimestralmente com comitê leve, atualizando mapeamentos e documentando decisões que viram precedente.

A primeira pergunta agregada que a base habilita é também a mais cobrada por gestão: quanto tempo separa o comprometimento da descoberta, por vetor. A consulta abaixo responde a partir de uma tabela interna derivada dos registros.

SELECT action_variety,
       AVG(datediff(day, data_comprometimento, data_descoberta)) AS dias_para_descobrir,
       AVG(datediff(hour, data_descoberta, data_contencao)) AS horas_para_conter,
       COUNT(*) AS incidentes
FROM incidentes_veris
WHERE ano >= 2024
GROUP BY action_variety
ORDER BY dias_para_descobrir DESC;

O resultado dessa consulta, repetido trimestralmente, é o que transforma a taxonomia em instrumento de gestão: o vetor com maior tempo de descoberta é o candidato natural a novo analytics de detecção, e a queda do número ao longo dos trimestres é a evidência de que a detecção produziu efeito.

7. VERIS e CTI: Quais Incidentes Alimentam a Produção

O registro padronizado é o que permite fechar o ciclo entre resposta a incidentes e inteligência com critério, e não com volume. Nem todo incidente merece virar inteligência, e o critério de seleção fica objetivo quando os casos estão descritos no vocabulário: alimentam a produção de inteligência os incidentes com ações pouco comuns na base interna, os que conectam a campanhas ou atores conhecidos, os que afetam setores monitorados pelos PIRs e os que revelam infraestrutura ou ferramentas novas. O incidente oportuniste de commodity, já coberto por detecção madura, entra na estatística e não no fluxo analítico, e essa triagem é o que impede o ciclo de feedback do CTI.9 de afogar a equipe em repetição.

O produto da seleção segue dois caminhos complementares. Para dentro, cada incidente selecionado gera requisitos de detecção: as ações registradas mapeiam para técnicas ATT&CK, as sequências viram hipóteses de hunting no formato do TH.6, e as características do ator alimentam o perfil de ameaças do capítulo 01. Para fora, o registro higienizado, sem dados da vítima e classificado sob TLP 2.0, compartilha-se com ISACs e parceiros pelos canais do capítulo 02, e é essa contribuição, descrita no mesmo vocabulário usado pelo DBIR, que mantém a estatística setorial viva e útil para a própria organização no ano seguinte.

O critério de seleção cabe em uma tabela de decisão, e vale fixá-la como política do ciclo de feedback, para que a escolha de o que alimentar a produção deixe de depender do entusiasmo do analista pelo caso.

8. Erros Comuns e Pontos de Atenção

• Tratar o VERIS como ferramenta e procurar o sistema oficial: o framework é vocabulário e esquema, e a implementação é do ambiente, tipicamente nos campos do ticket de IR e do data lake.
• Preencher os campos no encerramento do caso: a timeline reconstruída semanas depois é ficção; correção: registrar estimativas durante a investigação e revisar no encerramento.
• Usar valores livres onde o esquema pede enumeradores: a liberdade destrói comparabilidade, que é a única razão de ser do vocabulário; correção: enumerador fechado e campo de texto separado para nuance.
• Obrigar precisão que não existe: chutar data exata de comprometimento fabrica evidência; correção: usar unidades de estimativa e registrar confiança.
• Copiar o conjunto completo de campos do esquema antes de conseguir preencher o mínimo: o resultado é base vaziada; correção: mínimo obrigatório enxuto, expansão gradual com revisão.
• Deixar a taxonomia sem dono: ambiguidades acumuladas retornam como base incomparável; correção: comitê leve com cadência trimestral e registro de decisões.
• Confundir incidente com vazamento: o VERIS separa os conceitos, e o registro deve marcar claramente o que é incidente confirmado, o que é evento e o que tem disclosure confirmado.

9. Integração com o Restante da Biblioteca

O VERIS é o modelo que consolida: herda do Diamond Model a separação entre ator, ação e ativo, recebe do ATT&CK o vocabulário técnico das ações e entrega à Kill Chain a linha do tempo em fases, e por isso fecha o conjunto de modelos do capítulo. Na seção 15, o IR.2 classifica com o vocabulário, o IR.4 encerra e registra, o MET.3 mede a partir dos campos de timeline, o CTI.9 usa a seleção de incidentes como feedback e o PLT.3 carrega registros higienizados em STIX quando o compartilhamento for formal. Com o capítulo 01, o registro alimenta os PIRs com evidência própria, e com o capítulo 02 sustenta o compartilhamento com ISACs no formato que a indústria já consome.

A decisão operacional que separa adoção real de palestra sobre VERIS é o compromisso de comparabilidade temporal: o valor do vocabulário só aparece no segundo ano, quando a base acumulada permite afirmar, com números próprios, qual vetor domina e onde o tempo de descoberta melhorou ou piorou. Organizações que desistem no primeiro trimestre, por acharem os enumeradores incômodos, perdem justamente o retorno que o esforço existe para produzir, e voltam à planilha de casos que nenhuma pergunta agregada consegue responder.