Inteligência sobre ameaças na ISO 27001 para NIS2 e DORA
Às 07:42 de uma terça-feira, o CISO de uma fintech europeia recebe quatro mensagens antes do café.
A primeira é um alerta de um CERT nacional a avisar que uma vulnerabilidade de acesso remoto está a ser explorada ativamente. A segunda é um boletim de fornecedor a confirmar que o componente afetado é utilizado num serviço gerido de transferência de ficheiros. A terceira é uma notificação de Deteção e Resposta Geridas (MDR) a assinalar tráfego de saída incomum a partir de uma sub-rede de não produção. A quarta é do Diretor Financeiro: “Isto afeta o nosso pacote de preparação para DORA e temos de notificar alguém ao abrigo da NIS2?”
Este é o problema da inteligência sobre ameaças em 2026. Não se trata de recolher mais fontes de dados. Trata-se de demonstrar que informação relevante sobre ciberameaças é recebida, validada, encaminhada, tratada e convertida em evidência de risco, deteção, vulnerabilidades, incidentes, fornecedores e supervisão pelo conselho de administração.
Muitas organizações já subscrevem avisos de fornecedores, alertas da CISA, atualizações da ENISA, notificações de CERT nacionais, boletins de ISAC, notificações de segurança de prestadores de serviços de nuvem, fontes CVE, relatórios de MDR, bases de dados de explorabilidade e monitorização da dark web. Ainda assim, quando chega um aviso real, as equipas continuam a reagir em modo de urgência. O SOC cria uma regra de deteção. A equipa de infraestrutura procura em inventários de ativos que podem não estar atualizados. A conformidade pergunta se o evento afeta a NIS2 ou a DORA. A gestão quer uma resposta clara antes de a organização saber sequer se o componente vulnerável está em produção.
O problema não é a falta de dados. É a falta de um modelo operacional auditável.
Uma fonte de dados de ameaças que ninguém utiliza não é um controlo. Um aviso de vulnerabilidade que não altera a prioridade de aplicação de patches não é evidência. Uma notificação de fornecedor que nunca chega ao Registo de Riscos não é segurança da cadeia de fornecimento. Um alerta do CSIRT que não atualiza a monitorização, a triagem de incidentes ou o reporte à gestão é apenas ruído na caixa de entrada.
A abordagem da Clarysec é simples: a inteligência sobre ameaças deve tornar-se um sistema operativo para decisões de risco. Deve estar integrada no âmbito do SGSI, na Avaliação de Riscos, na Declaração de Aplicabilidade, nos procedimentos de atuação para incidentes, na triagem de vulnerabilidades, no registo e monitorização, na governação de fornecedores, no reporte à gestão e no pacote de evidência de auditoria.
Porque a inteligência sobre ameaças é agora um controlo ao nível do conselho de administração
A NIS2 alterou o tom da governação da cibersegurança. Coloca muitos fornecedores SaaS, prestadores de serviços de nuvem, prestadores de serviços geridos, prestadores de serviços de segurança geridos, organizações de infraestrutura digital e prestadores de serviços digitais no âmbito, como entidades essenciais ou importantes, consoante o setor, a dimensão e a designação pelo Estado-Membro.
O NIS2 Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas para gerir riscos. Estas incluem análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, segurança na aquisição, desenvolvimento e manutenção, incluindo tratamento e divulgação de vulnerabilidades, avaliação da eficácia, ciber-higiene básica e formação, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos e autenticação multifator ou autenticação contínua quando adequado.
O NIS2 Article 20 também exige que os órgãos de gestão aprovem as medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e recebam formação. Para entidades essenciais, a coima administrativa máxima pode atingir pelo menos 10 milhões de EUR ou 2% do volume de negócios anual mundial, consoante o montante mais elevado. Para entidades importantes, pode atingir pelo menos 7 milhões de EUR ou 1,4%.
Para a inteligência sobre ameaças, a pergunta ao nível do conselho de administração passa a ser: como sabemos que as ameaças emergentes estão a alterar os nossos controlos antes de se tornarem incidentes?
A DORA acrescenta outra camada para entidades financeiras e prestadores terceiros de TIC relevantes. Aplica-se a partir de 17 de janeiro de 2025 e exige um quadro de gestão do risco das TIC sólido, abrangente e bem documentado, integrado no sistema global de gestão de riscos. O quadro da DORA espera que as organizações identifiquem e classifiquem funções de negócio e ativos suportados por TIC, protejam e previnam, detetem atividade anómala, respondam e recuperem, façam a gestão de cópias de segurança e restauro, aprendam com incidentes de TIC, comuniquem durante crises e façam a gestão do risco das TIC de terceiros.
A DORA também exige gestão, classificação e reporte de incidentes relacionados com as TIC. Os Articles 17, 18 e 19 cobrem processos de gestão de incidentes, classificação de incidentes relacionados com as TIC e ciberameaças, e reporte de incidentes graves relacionados com as TIC. O Article 10 centra-se na deteção de atividades anómalas. Os Articles 6 a 11 descrevem o quadro de gestão do risco das TIC e as expectativas de identificação, proteção, prevenção, deteção, resposta e recuperação.
Em termos simples, a DORA exige resiliência informada por ameaças. Não resiliência estática. Não resiliência baseada em políticas anuais. Resiliência informada por ameaças.
A ISO/IEC 27001:2022 fornece o motor do sistema de gestão que liga estas expectativas. As cláusulas 4.1 a 4.4 exigem que a organização compreenda o seu contexto interno e externo, as partes interessadas, as obrigações legais e regulamentares, o âmbito do SGSI, as dependências e os processos em interação. As cláusulas 6.1.1 a 6.1.3 exigem um processo repetível de Avaliação de Riscos e Tratamento de Riscos, seleção de controlos, comparação com o Anexo A, Declaração de Aplicabilidade, planeamento do tratamento e aprovação do risco residual pelo Proprietário do Risco.
A inteligência sobre ameaças pertence a esse processo, não como um painel de gestão paralelo, mas como entrada para contexto, risco, seleção de controlos, tratamento, monitorização, Revisão pela Gestão e Melhoria Contínua.
A armadilha da conformidade: fontes de dados de ameaças sem rastreabilidade das decisões
O padrão de falha mais comum é enganadoramente simples: a organização recebe inteligência sobre ameaças, mas não consegue demonstrar como esta altera decisões.
Uma cadeia de evidência fraca costuma ter este aspeto:
| Sinal recebido | Resposta fraca | Preocupação do auditor |
|---|---|---|
| Alerta de CERT sobre exploração ativa | Encaminhado para a caixa de correio de TI | Sem evidência de Avaliação de Riscos, propriedade ou ação |
| Boletim de fornecedor sobre patch crítico | Adicionado à lista de pendências de tickets | Sem priorização baseada na criticidade do ativo ou na atividade de exploração |
| Deteção MDR de linha de comando suspeita | Encerrada como falso positivo | Sem critérios de triagem documentados ou ciclo de aprendizagem |
| Notificação de fornecedor sobre dependência comprometida | Arquivada na pasta de compras | Sem atualização do risco de fornecedor ou revisão de controlos compensatórios |
| Aviso de ISAC sobre campanha setorial | Mencionado em reunião do SOC | Sem atualização de monitorização, sensibilização ou procedimento de atuação para incidentes |
É aqui que o método de implementação da Clarysec ajuda as organizações a passar de “recebemos informação” para “operacionalizamos informação”.
Em Zenith Blueprint: Roteiro de 30 passos para auditores Zenith Blueprint, a fase Controls in Action transforma explicitamente a inteligência sobre ameaças numa prática auditável. O Passo 22, Controlos organizacionais, estabelece:
Estabeleça uma lista documentada de fontes de inteligência sobre ameaças (5.7), provenientes de fornecedores, ISAC ou fontes abertas, e determine como a informação é validada e integrada na tomada de decisão. Defina quem recebe atualizações sobre ameaças e como são aplicadas (por exemplo, priorização de patches, formação de sensibilização). Crie uma breve nota informativa trimestral sobre tendências de ameaças para distribuir às principais partes interessadas.
Esta instrução é a ponte entre os dados de ameaças e a evidência de conformidade. Um registo de inteligência sobre ameaças não é apenas uma lista de fontes. Demonstra relevância, propriedade, validação, encaminhamento, integração e utilização pelo negócio.
Lógica de controlos ISO 27001: a cadeia de inteligência sobre ameaças
O controlo 5.7 da ISO/IEC 27002:2022, Inteligência sobre ameaças, exige que as organizações recolham e analisem informação relativa a ameaças à segurança da informação e a utilizem para produzir inteligência sobre ameaças. Em Zenith Controls: O guia de conformidade cruzada Zenith Controls, o controlo 5.7 é classificado como preventivo, de deteção e corretivo. Suporta a Confidencialidade, Integridade e Disponibilidade, alinha-se com os conceitos de cibersegurança Identify, Detect e Respond, e integra a gestão de ameaças e vulnerabilidades como capacidade operacional.
Esta classificação é importante. A inteligência sobre ameaças previne ao informar o endurecimento, a aplicação de patches, a formação e os controlos de fornecedores. Deteta ao moldar a monitorização, as regras SIEM e as tarefas de caça a ameaças. Corrige ao melhorar a resposta a incidentes, as lições aprendidas e o Tratamento de Riscos.
Zenith Controls também mapeia o controlo 5.7 da ISO/IEC 27002:2022 para controlos de suporte:
| Relação de controlos ISO/IEC 27002:2022 | Porque é importante na prática |
|---|---|
| 5.6 Contacto com grupos de interesse especial | ISAC, CERT, fóruns profissionais e comunidades setoriais são fontes de informação, não extras de networking |
| 8.7 Proteção contra malware | Indicadores de compromisso, URLs maliciosos, hashes, infraestrutura de comando e controlo e padrões de ataque atualizam as defesas de endpoint e correio eletrónico |
| 8.8 Gestão de vulnerabilidades técnicas | Informação sobre exploração em ambiente real altera a prioridade das vulnerabilidades e a urgência dos patches |
| 8.15 Registo | Os logs fornecem o registo factual necessário para procurar indicadores e reconstruir atividade |
| 8.16 Atividades de monitorização | A inteligência sobre ameaças diz ao SOC o que deve monitorizar, enquanto a monitorização produz informação interna |
| 5.25 Avaliação e decisão sobre eventos de segurança da informação | A triagem apoiada por inteligência ajuda a decidir se um evento é um incidente de segurança |
A ligação às vulnerabilidades é especialmente importante. Zenith Controls trata o controlo 8.8, Gestão de vulnerabilidades técnicas, como preventivo e diretamente ligado ao controlo 5.7, porque a inteligência sobre ameaças do mundo real indica quais as vulnerabilidades exploradas ativamente. Também liga o 8.8 ao 8.16, Atividades de monitorização, porque tentativas de exploração observadas devem escalar a urgência de aplicação de patches.
Isto cria uma cadeia prática de inteligência sobre ameaças:
- Chega informação externa ou interna.
- A relevância é validada face a ativos, fornecedores, geografia, setor, serviços de negócio e dados.
- O risco é atualizado.
- As prioridades de patches e configuração mudam.
- A lógica de deteção é ajustada.
- Os procedimentos de atuação para incidentes e os limiares de classificação são revistos.
- As dependências de fornecedores e de nuvem são verificadas.
- A gestão recebe reporte de tendências.
- A evidência é retida para auditores, reguladores e clientes.
Políticas que transformam informação em comportamento responsabilizável
As políticas são onde a lógica de controlos se transforma em responsabilização baseada em funções. Os conjuntos de políticas da Clarysec para PME e empresas incluem pontos de integração da inteligência sobre ameaças em gestão de riscos, proteção de endpoint, gestão de vulnerabilidades, registo de eventos, monitorização e evidência de auditoria.
Para PME, a Política de proteção de endpoints contra malware Política de proteção de endpoints contra malware - PME estabelece uma expectativa direta na cláusula 5.4.1 de Requisitos de governação:
O Prestador de Suporte de TI deve monitorizar fontes credíveis de inteligência sobre ameaças (por exemplo, CISA, ENISA, principais fornecedores de antivírus) e garantir que as assinaturas de deteção permanecem atualizadas
O valor desta cláusula é a atribuição. A inteligência sobre ameaças não é “alguém em TI deve verificar alertas”. É uma obrigação explícita do prestador.
A Política de Gestão de Vulnerabilidades e Patches Política de Gestão de Vulnerabilidades e Patches - PME reforça o mesmo modelo na cláusula 4.2.1 de Papéis e responsabilidades:
Monitoriza sistemas quanto a vulnerabilidades e patches disponíveis utilizando alertas de fornecedores, avisos de inteligência sobre ameaças e notificações do sistema operativo
Também identifica, na cláusula 6.2.1.3 de Requisitos de implementação da política, o tipo de fonte que deve desencadear ação:
Avisos de inteligência sobre ameaças provenientes de fontes de confiança (por exemplo, CISA, ENISA, alertas de CERT nacionais)
Para empresas, a Política de Gestão de Vulnerabilidades e Patches Política de Gestão de Vulnerabilidades e Patches declara, na cláusula 4.5.1 de Papéis e responsabilidades:
Monitorizar avisos de ameaças (por exemplo, CVE, CISA KEV, boletins de fornecedores) e escalar vulnerabilidades críticas.
O requisito de escalonamento é crucial. Uma vulnerabilidade torna-se urgente quando convergem explorabilidade, exposição, criticidade do negócio, sensibilidade dos dados e atividade de ameaça.
A Política de Gestão de Riscos Política de Gestão de Riscos integra a inteligência sobre ameaças na análise. A cláusula 6.2.2 de Requisitos de implementação da política estabelece:
A análise deve considerar a eficácia dos controlos existentes, inteligência sobre ameaças relevante, criticidade dos ativos e severidade das vulnerabilidades.
Esta cláusula é o centro da inteligência sobre ameaças preparada para auditoria. Demonstra que a análise de riscos não é teórica.
A Política de registo e monitorização Política de registo e monitorização transforma informação em deteção. A sua cláusula 1.2 de Finalidade estabelece:
O registo para trilho de auditoria, a monitorização e a deteção de ameaças são críticos para a deteção de anomalias, resposta a ameaças, revisão forense, preparação para auditoria e cumprimento legal. Esta política garante que todos os eventos gerados pelos sistemas são devidamente registados, retidos e correlacionados com exatidão sincronizada no tempo.
Por fim, a Política de Auditoria e Monitorização da Conformidade Política de Auditoria e Monitorização da Conformidade explica porque a disciplina de evidência é importante. A cláusula 3.4 de Objetivos exige que a organização gere evidência:
Gerar evidência defensável e um trilho de auditoria em apoio a pedidos de esclarecimento regulamentar, processos legais ou pedidos de garantia por parte de clientes.
Quando a NIS2, a DORA, um cliente ou um auditor ISO pergunta o que sabia, quando soube, quem decidiu e o que mudou, este trilho de evidência é a diferença entre garantia madura e uma reação defensiva em modo de urgência.
Construir o Registo de inteligência sobre ameaças
Um registo maduro tem duas camadas: governação de fontes e acompanhamento de eventos. A governação de fontes define em que é que a organização confia, quem é responsável, como é validado e que ação pode desencadear.
| Nome da fonte | Tipo | Processo de validação | Ponto de integração | Responsável |
|---|---|---|---|---|
| Catálogo CISA KEV | Operacional | Cruzamento com o inventário de ativos e a exposição | Desencadear priorização de patches de emergência | Gestão de vulnerabilidades |
| Avisos da ENISA | Estratégico | Revisão pelo Proprietário do Risco ou comité de risco | Atualizar cenários de risco e nota informativa à gestão | CISO |
| ISAC setorial | Tático | Analisar IOC quanto à relevância para a pilha tecnológica | Atualizar SIEM, EDR e tarefas de caça a ameaças | Responsável do SOC |
| Boletins de prestadores de serviços de nuvem | Operacional | Verificar serviços e regiões afetados | Escalar para engenharia de nuvem | Responsável de DevOps |
| Notificações de patches de fornecedores | Operacional | Confirmar produto, versão e âmbito de implementação | Adicionar ao ciclo de patches ou a alteração de emergência | Operações de TI |
| Notificações MDR | Tático e operacional | Triagem face a logs, ativos e referenciais conhecidos | Abrir caso de deteção, investigação ou incidente | Operações de segurança |
| Notificações de segurança de fornecedores | Operacional | Mapear para serviços contratados e fluxos de dados | Atualizar risco de fornecedor e controlos compensatórios | Proprietário do fornecedor |
O acompanhamento de eventos capta como um aviso específico se tornou evidência. Voltando ao cenário de terça-feira de manhã da transferência de ficheiros, a entrada no registo deve captar informação suficiente para suportar decisões de risco, resposta e conformidade.
| Campo | Exemplo de entrada |
|---|---|
| Data e hora de receção | 2026-05-26 07:42 UTC |
| Fonte | Alerta de CERT nacional, boletim de fornecedor, notificação MDR |
| Tipo de fonte | Aviso governamental, aviso de fornecedor, deteção interna |
| Tecnologia afetada | Serviço gerido de transferência de ficheiros, intervalo de versões, bibliotecas dependentes |
| Proprietário do negócio | Diretor de Operações de Plataforma |
| Proprietário do risco | CISO |
| Ligação a ativos | Gateway externa de transferência de ficheiros, fluxo de reporte a clientes |
| Severidade inicial | Alta, pendente de validação de exposição |
| Ações exigidas | Verificação de exposição, estado dos patches, revisão de deteção, confirmação do fornecedor |
| Relevância para conformidade | NIS2 Article 21, NIS2 Article 23 se forem cumpridos os critérios de incidente significativo, ciclo de vida de risco das TIC e incidentes DORA se aplicável |
| Localização da evidência | Ticket, atualização do Registo de Riscos, alteração SIEM, nota à gestão |
Isto não é burocracia. É o registo factual que demonstra que a organização tem um processo definido de admissão, validação, triagem, escalonamento e evidência.
Do aviso à evidência de auditoria: um fluxo de trabalho prático
Um fluxo de trabalho de inteligência sobre ameaças deve responder rapidamente a seis perguntas: estamos expostos, quão grave é, o que deve mudar, quem é responsável, temos de reportar e que evidência deve ser retida?
1. Validar a exposição e o impacto no negócio
As cláusulas 4.1 a 4.4 da ISO/IEC 27001:2022 exigem que o SGSI reflita o contexto, as obrigações e as dependências reais da organização. A primeira tarefa não é aplicar patches às cegas. É validar a exposição.
Pergunte:
- Executamos a tecnologia afetada?
- Está exposta à Internet?
- É utilizada por um serviço de negócio crítico?
- Trata dados pessoais?
- É operada por um fornecedor ou prestador de serviços geridos?
- É relevante para uma função crítica ou importante no âmbito da DORA?
- É relevante para serviços no âmbito da NIS2?
- Existem obrigações contratuais de notificação a clientes?
- Os logs estão disponíveis, completos e sincronizados no tempo?
Se dados pessoais puderem ser afetados, a responsabilização do RGPD da UE também entra na análise. O RGPD da UE exige segurança adequada do tratamento e responsabilização demonstrável, incluindo a capacidade de avaliar se ocorreu uma violação de dados pessoais e se é exigida notificação.
2. Atualizar o Registo de Riscos
A Política de Gestão de Riscos Política de Gestão de Riscos - PME fornece uma regra temporal simples na cláusula 5.1.3 de Requisitos de governação:
Os riscos devem ser revistos trimestralmente e atualizados quando ocorrerem eventos significativos.
Um aviso credível de exploração ativa é um evento significativo. A atualização não deve esperar pela próxima revisão trimestral.
| Elemento de risco | Avaliação atualizada |
|---|---|
| Ameaça | Exploração ativa de vulnerabilidade em transferência gerida de ficheiros |
| Vulnerabilidade | Versão afetada, interface exposta, configuração fraca, patch em falta |
| Ativo | Plataforma de intercâmbio de dados com clientes |
| Consequência | Interrupção de serviços, acesso não autorizado a dados, reporte regulamentar, impacto na confiança dos clientes |
| Probabilidade | Aumentada devido a exploração ativa em ambiente real |
| Controlos existentes | MFA, WAF, proteção de endpoint, monitorização SIEM, cópia de segurança, SLA de fornecedor |
| Lacunas de controlo | Patch não confirmado, deteção não ajustada, evidência do fornecedor pendente |
| Tratamento | Patch de emergência, restrição temporária de rede, caça a IOC, atestado do fornecedor, avaliação de impacto no cliente |
| Proprietário do risco residual | CISO e proprietário de Operações de Plataforma |
Isto liga diretamente às cláusulas 6.1.1-6.1.3 da ISO/IEC 27001:2022. A organização identifica o risco, analisa probabilidade e consequências, prioriza o tratamento, seleciona controlos, mantém a Declaração de Aplicabilidade, cria um plano de tratamento e obtém aprovação do risco residual.
3. Priorizar o tratamento de vulnerabilidades com base em informação de exploração
O Zenith Blueprint, fase Controls in Action, Passo 19, Controlos tecnológicos I, explica porque a gestão de vulnerabilidades é essencial para a ciber-higiene:
Gerir vulnerabilidades é uma das áreas mais críticas da ciber-higiene moderna. Embora firewalls e ferramentas antivírus forneçam proteção, podem ser contornadas se sistemas sem patches ou serviços mal configurados ficarem expostos. Para cumprir este controlo, as organizações devem implementar um processo estruturado e repetível para identificar, avaliar e tratar vulnerabilidades.
O CVSS, por si só, não é suficiente. Uma vulnerabilidade com pontuação média sob exploração ativa num sistema exposto à Internet pode ser mais urgente do que uma vulnerabilidade com pontuação alta isolada num laboratório segmentado.
| Fator | Pergunta | Evidência |
|---|---|---|
| Atividade de exploração | A exploração foi observada ou reportada por fontes de confiança? | Alerta de CERT, referência CISA KEV, boletim de fornecedor, relatório MDR |
| Exposição | O ativo está exposto à Internet ou acessível por fornecedores? | Inventário de ativos, postura de segurança de nuvem, varrimento de rede |
| Criticidade do negócio | Suporta serviços essenciais ou funções críticas? | Análise de impacto no negócio, mapeamento de funções DORA |
| Sensibilidade dos dados | Trata dados pessoais, dados financeiros regulados ou dados confidenciais de clientes? | Inventário de dados, AIPD, registos de tratamento |
| Controlos compensatórios | WAF, regras de firewall, segmentação, EDR ou desativação de funcionalidades podem reduzir o risco? | Ticket de alteração, regra de firewall, política EDR |
| Risco operacional | A aplicação de patches de emergência pode perturbar a prestação de serviços críticos? | Avaliação da alteração, plano de reversão, plano de continuidade |
Isto produz uma decisão defensável. Também suporta o NIS2 Article 21(2)(e) para tratamento de vulnerabilidades, o NIS2 Article 21(2)(g) para ciber-higiene e as expectativas de gestão do risco das TIC da DORA.
4. Converter informação em monitorização e deteção
A inteligência sobre ameaças deve chegar ao registo e monitorização. A Política de registo e monitorização Política de registo e monitorização - PME estabelece na cláusula 6.2.1 de Requisitos de implementação da política:
As ferramentas de segurança (por exemplo, antivírus, firewalls, VPN) devem ser configuradas para gerar alertas para cenários de ameaça definidos, incluindo:
O excerto define claramente a intenção do controlo: cenários de ameaça definidos devem orientar a geração de alertas.
O Zenith Blueprint, fase Controls in Action, Passo 19, descreve as atividades de monitorização desta forma:
Se o registo em logs é o ato de registar o que acontece no seu ambiente, a monitorização é o ato de observar, compreender e responder a esses eventos. Este controlo consiste em observar ativamente redes, sistemas e aplicações para detetar atividade incomum, não apenas após o facto, mas em tempo real ou quase em tempo real, sempre que possível.
No cenário de transferência de ficheiros, o SOC ou prestador de TI deve:
- Adicionar ou validar IOC provenientes do CERT e do aviso do fornecedor.
- Pesquisar logs por caminhos de exploração conhecidos, uploads suspeitos, indicadores de web shell, execução incomum de processos e ligações de saída inesperadas.
- Confirmar que os logs de autenticação, atividade administrativa, acesso a ficheiros, API e rede são retidos.
- Ajustar alertas SIEM para o padrão de exploração.
- Criar uma nota de caso que explique o que foi pesquisado, o que foi encontrado e quem reviu.
- Escalar para classificação de incidente se os indicadores mostrarem compromisso, exposição de dados ou impacto no serviço.
É aqui que a notificação de incidentes se torna prática. O NIS2 Article 23 exige reporte faseado de incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas, atualizações intermédias a pedido e relatório final, o mais tardar, um mês após a notificação. A DORA exige que as entidades financeiras detetem, giram, classifiquem e reportem incidentes graves relacionados com as TIC através do processo faseado definido pelo regulamento e pelas normas técnicas relacionadas.
A inteligência sobre ameaças ajuda a determinar se a organização ainda está em resposta a vulnerabilidades, avaliação de evento de segurança ou reporte regulamentar de incidente.
Um fluxo de trabalho, múltiplas obrigações de conformidade
A inteligência sobre ameaças é um fluxo de trabalho de conformidade integrado ideal, porque a mesma evidência suporta vários regimes.
| Referencial ou regulamento | O que exige | Evidência de inteligência sobre ameaças |
|---|---|---|
| ISO/IEC 27001:2022 | SGSI consciente do contexto, Avaliação de Riscos, seleção de controlos, planeamento do tratamento, Melhoria Contínua | Âmbito do SGSI, Registo de Riscos, Declaração de Aplicabilidade, plano de tratamento, entradas para Revisão pela Gestão |
| ISO/IEC 27002:2022 | Inteligência sobre ameaças, gestão de vulnerabilidades, registo, monitorização, avaliação de incidentes, proteção contra malware | Registo de inteligência sobre ameaças, atualizações de IOC, regras SIEM, tickets de patches, notas de triagem de incidentes |
| NIS2 | Gestão de riscos, tratamento de incidentes, ciber-higiene, tratamento de vulnerabilidades, segurança da cadeia de fornecimento, supervisão da governação | Evidência dos Articles 20 e 21, notas informativas à gestão, fluxo de trabalho CSIRT, acompanhamento de avisos de fornecedores |
| DORA | Quadro de risco das TIC, deteção, continuidade, ciclo de vida de incidentes, testes de resiliência, risco das TIC de terceiros | Classificação de ativos de TIC, casos de deteção, registos de classificação de incidentes, entradas para testes de resiliência, registos de fornecedores de TIC |
| RGPD da UE | Segurança do tratamento, responsabilização, suporte à deteção e notificação de violações | Avaliação de impacto nos dados, logs de acesso, evidência de monitorização, registo de avaliação de violação |
| NIST CSF 2.0 | Resultados Govern, Identify, Protect, Detect, Respond, Recover | Current Profile, Target Profile, plano de ação priorizado, comunicações de risco |
| Perspetiva de auditoria COBIT 2019 | Governação sobre risco, controlos, desempenho, garantia e responsabilização | Propriedade de controlos, métricas de gestão, evidência de garantia, acompanhamento de remediação de problemas |
O NIST CSF 2.0 é especialmente útil para comunicação executiva. As suas Core Functions, Govern, Identify, Protect, Detect, Respond e Recover, transformam informação técnica numa narrativa legível pelo conselho de administração:
- Govern: fontes de inteligência sobre ameaças, responsáveis e linhas de reporte estão definidos.
- Identify: ativos, fornecedores, serviços de negócio e dados afetados estão mapeados.
- Protect: aplicação de patches, endurecimento, segmentação e assinaturas de endpoint são atualizados.
- Detect: regras de monitorização, IOC e tarefas de caça a ameaças são implementados.
- Respond: procedimentos de atuação para incidentes, regras de triagem e limiares de notificação são revistos.
- Recover: cópias de segurança, prioridades de restauro e lições aprendidas são validadas.
Isto transforma informação bruta sobre ciberameaças em governação de risco.
A perspetiva do auditor: o que será solicitado
Um processo robusto de inteligência sobre ameaças deve resistir a diferentes estilos de auditoria. Um auditor ISO, revisor NIS2, autoridade competente DORA, avaliador NIST CSF, auditor orientado por COBIT 2019, profissional ISACA ou revisor de privacidade pode usar linguagem diferente, mas todos convergem na evidência.
| Perspetiva do auditor | Pergunta provável de auditoria | Evidência que responde |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Como é que o contexto externo e interno influencia os riscos e controlos do SGSI? | Registo de inteligência sobre ameaças, metodologia de risco, Registo de Riscos atualizado, racional da Declaração de Aplicabilidade |
| Revisor de controlos ISO/IEC 27002:2022 | Como estão ligados os controlos 5.7, 8.8, 8.16, 8.15, 8.7 e 5.25? | Lista de fontes, triagem de vulnerabilidades, ajuste SIEM, atualizações de assinaturas de malware, registos de avaliação de eventos |
| Revisor NIS2 | Como cumprem a supervisão pela gestão, a ciber-higiene, o tratamento de vulnerabilidades, o tratamento de incidentes e a segurança da cadeia de fornecimento? | Mapeamento dos Articles 20 e 21, notas informativas à gestão, procedimento de reporte CSIRT, fluxo de trabalho de avisos de fornecedores |
| Autoridade competente DORA | Como é que a inteligência sobre ameaças atualiza o risco das TIC, a deteção, os testes de resiliência e a classificação de incidentes? | Quadro de risco das TIC, mapeamento de funções críticas, casos de deteção, registos de classificação de incidentes, âmbito de testes de resiliência |
| Avaliador NIST CSF | Qual é o vosso Current Profile, Target Profile e plano de ação priorizado? | Perfil CSF, avaliação de lacunas, plano de ação, log de atualização contínua |
| Auditor COBIT 2019 ou ISACA | Quem é proprietário do controlo, como é medido o desempenho e como são remediadas as exceções? | RACI, KPI, KRI, Registo de Exceções, tickets de remediação, aprovação formal da gestão |
| Auditor RGPD da UE ou revisor de privacidade | Como é que a monitorização e a gestão de vulnerabilidades protegeram dados pessoais e suportaram a avaliação de violação? | Mapa de tratamento de dados, logs, avaliação de violação, evidência de medidas técnicas e organizativas |
Zenith Controls fornece a interpretação de conformidade cruzada para estas discussões. Para o controlo 8.16, Atividades de monitorização, o guia liga a monitorização à segurança e responsabilização por violações no âmbito do RGPD da UE, ao tratamento e reporte de incidentes NIS2 e às expectativas de deteção e resposta da DORA. Para o controlo 8.8, Gestão de vulnerabilidades técnicas, liga o tratamento de vulnerabilidades à Segurança do tratamento do RGPD da UE, ao NIS2 Article 21(2)(e) e à gestão proativa do risco das TIC da DORA.
Esta é a convergência de evidência que os auditores querem ver.
Reporte à gestão: a nota informativa trimestral sobre tendências de ameaças
O registo de inteligência sobre ameaças não deve ficar esquecido no SOC. O Zenith Blueprint recomenda uma breve nota informativa trimestral sobre tendências de ameaças para as principais partes interessadas. A Clarysec recomenda um relatório de gestão de uma página com cinco secções:
- As três principais tendências de ameaça relevantes por impacto no negócio.
- Tecnologias ou fornecedores mais expostos.
- Vulnerabilidades críticas corrigidas, mitigadas ou aceites.
- Melhorias efetuadas em deteção e resposta.
- Decisões exigidas à gestão.
Uma nota informativa de gestão robusta não lista 400 CVE. Explica a evolução do risco. Por exemplo:
- Ransomware direcionado a prestadores de serviços geridos aumentou a prioridade da revisão de fornecedores.
- A exploração de plataformas de transferência de ficheiros desencadeou aplicação de patches de emergência e uma regra compensatória de firewall.
- Ataques a identidades de nuvem levaram à revisão de exceções MFA e ao endurecimento do acesso condicional.
- Informação de ISAC setorial levou a novas simulações de phishing para as equipas financeira e de suporte.
- O mapeamento de funções críticas DORA revelou uma lacuna de monitorização num fluxo de trabalho de terceiros.
Esta nota informativa suporta a responsabilização da gestão NIS2, a governação do risco das TIC DORA, a Revisão pela Gestão ISO/IEC 27001:2022 e a garantia para clientes.
Padrões comuns de falha
Os programas de inteligência sobre ameaças parecem frequentemente maduros em apresentações, mas revelam-se frágeis em auditoria. Os padrões de falha mais comuns são:
- Demasiadas fontes de dados e ausência de critérios de validação.
- Ausência de ligação entre inteligência e inventário de ativos.
- Ausência de atualização documentada de risco após avisos relevantes.
- Prioridade de patches baseada apenas na severidade da ferramenta de varrimento.
- Avisos de fornecedores tratados fora do SGSI.
- Regras do SOC atualizadas sem registos de alteração.
- Limiares de incidente não alinhados com fluxos de reporte NIS2 ou DORA.
- Reporte ao conselho de administração focado no volume de alertas em vez do risco de negócio.
- Ausência de evidência de que as lições aprendidas alteraram controlos.
- Ausência de responsável pela manutenção do registo de inteligência sobre ameaças.
A solução não é comprar mais uma fonte de dados. A solução é integrar controlos.
Lista de verificação de preparação em 10 pontos para 2026
Utilize esta lista de verificação como revisão interna prática.
| Pergunta de preparação | Sim ou não |
|---|---|
| Mantemos um registo de inteligência sobre ameaças aprovado, com proprietários das fontes e regras de validação? | |
| Os avisos de CERT, CSIRT, ISAC, fornecedores, nuvem, MDR e prestadores são encaminhados para funções nomeadas? | |
| Avisos significativos desencadeiam revisão do Registo de Riscos fora do ciclo trimestral? | |
| A priorização de vulnerabilidades inclui atividade de exploração, criticidade dos ativos, sensibilidade dos dados e exposição? | |
| Os IOC e cenários de ameaça são convertidos em regras de monitorização ou tarefas de caça a ameaças? | |
| As assinaturas de endpoint, deteções de nuvem e fontes dinâmicas de inteligência sobre ameaças são verificadas quanto à atualização tempestiva? | |
| As notificações de fornecedores são avaliadas face ao risco da cadeia de fornecimento e às obrigações contratuais? | |
| Os critérios de classificação de incidentes estão alinhados com os fluxos de reporte NIS2 e DORA, quando aplicável? | |
| A gestão recebe uma nota informativa trimestral sobre tendências de ameaças? | |
| Conseguimos produzir um pacote de evidência para um auditor, regulador ou cliente no prazo de um dia útil? |
Se a resposta a qualquer uma destas perguntas for “não”, a organização não tem apenas um problema de inteligência sobre ameaças. Tem um problema de integração do SGSI.
Como a Clarysec ajuda a transformar inteligência sobre ameaças em evidência
O método da Clarysec foi concebido para organizações que precisam de segurança prática e conformidade credível em simultâneo.
O Zenith Blueprint fornece a rota de implementação em 30 passos, incluindo o Passo 22 para o registo de inteligência sobre ameaças e o Passo 19 para gestão de vulnerabilidades e atividades de monitorização. As políticas empresariais e para PME da Clarysec transformam essas expectativas em procedimentos baseados em funções para gestão de riscos, tratamento de vulnerabilidades, proteção de endpoint, registo, monitorização e evidência de auditoria. O Zenith Controls fornece depois a interpretação de conformidade cruzada, mostrando como os controlos ISO/IEC 27002:2022 se ligam à NIS2, DORA, RGPD da UE, NIST CSF 2.0, COBIT 2019 e evidência de auditoria.
Para o CISO da terça-feira de manhã, a resposta ao Diretor Financeiro torna-se clara:
“Recebemos o aviso, validámos a exposição, atualizámos o Registo de Riscos, priorizámos a aplicação de patches com base em exploração ativa, ajustámos a monitorização, verificámos a dependência de fornecedor, avaliámos os limiares de reporte de incidentes, informámos a gestão e retivemos evidência. Não estamos a adivinhar. Estamos a seguir o nosso SGSI.”
É assim que a inteligência sobre ameaças ISO 27001 para ciber-higiene NIS2 e evidência de risco das TIC DORA deve funcionar em 2026.
Próximos passos
Se a sua organização recebe inteligência sobre ameaças, mas não consegue demonstrar como esta altera decisões de risco, controlos, deteção, resposta a incidentes, gestão de fornecedores e evidência regulamentar, comece com três ações esta semana:
- Crie ou atualize o seu Registo de inteligência sobre ameaças utilizando o Zenith Blueprint, fase Controls in Action, Passo 22.
- Mapeie o seu processo atual face aos controlos 5.7, 8.8, 8.15, 8.16, 8.7 e 5.25 da ISO/IEC 27002:2022 utilizando o Zenith Controls.
- Alinhe as suas políticas, especialmente a Política de Gestão de Riscos, a Política de Gestão de Vulnerabilidades e Patches, a Política de registo e monitorização e a Política de Auditoria e Monitorização da Conformidade, para que cada aviso possa tornar-se evidência defensável.
A Clarysec pode ajudar a transformar fontes de dados de ameaças, avisos, notificações de fornecedores, informação sobre vulnerabilidades e sinais de deteção num modelo operacional alinhado com a ISO/IEC 27001:2022, preparado para NIS2 e consciente da DORA.
Descarregue os toolkits da Clarysec, solicite uma demonstração guiada ou marque uma avaliação de preparação para ver como o seu processo atual de inteligência sobre ameaças resistiria a um auditor ISO, revisor NIS2, autoridade competente DORA ou pedido de garantia por parte de clientes.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
