Da análise à evidência: ISO 27001:2022, NIS2, DORA
São 08:16 de uma segunda-feira. Uma vulnerabilidade crítica de execução remota de código acaba de surgir no painel de gestão de um servidor aplicacional exposto à Internet. A equipa de infraestrutura afirma que o patch do fornecedor está disponível. O proprietário da aplicação alerta que o servidor suporta um fluxo de trabalho de clientes crítico para a receita. O departamento Jurídico pergunta se a exploração pode desencadear obrigações de reporte ao abrigo da NIS2, DORA ou GDPR da UE. A CISO, Maria, abre o calendário de auditoria e identifica o verdadeiro problema: a auditoria de acompanhamento ISO 27001:2022 começa na próxima semana, uma revisão de preparação para a NIS2 já está em curso e um grande cliente fintech solicitou evidência DORA.
A ferramenta de análise apresenta vermelho. O quadro de tickets mostra atividade. A folha de cálculo mostra esforço. Mas nada disso, por si só, prova controlo.
Esta é a lacuna que muitas organizações descobrem tarde demais. A análise de vulnerabilidades não é o mesmo que preparação para auditoria da gestão de vulnerabilidades. Uma análise indica que algo pode estar errado. A evidência de auditoria prova que a organização sabia o que tinha, avaliou o risco, atribuiu titularidade, atuou dentro da política, controlou a alteração, documentou exceções, verificou resultados e reviu o desfecho.
Para ISO/IEC 27001:2022, NIS2 e DORA, essa cadeia de evidência é tão importante como a correção técnica. A ferramenta de análise inicia a história. O inventário de ativos, o registo de vulnerabilidades, o ticket, a decisão de risco, o registo de alteração, o registo de patches, a evidência de validação, a aprovação da exceção e a revisão pela gestão completam-na.
A abordagem da Clarysec é simples: não trate a gestão de vulnerabilidades como um ritual técnico mensal. Trate-a como um fluxo de trabalho de evidência sujeito a governação.
Porque é que os relatórios de análise falham como evidência de auditoria
Uma análise de vulnerabilidades é uma observação técnica num momento específico. Pode identificar uma CVE, um patch em falta, uma biblioteca sem suporte, um serviço exposto ou uma configuração fraca. Isso é útil, mas incompleto.
Um auditor fará perguntas diferentes:
- O ativo afetado estava dentro do âmbito?
- Quem é o proprietário do ativo e do serviço de negócio?
- A vulnerabilidade foi avaliada com base na exposição, explorabilidade, impacto no negócio e sensibilidade dos dados?
- A remediação foi concluída dentro do prazo definido?
- Se a remediação foi adiada, quem aceitou o risco residual?
- O patch foi implementado através de gestão de alterações controlada?
- A correção foi verificada por nova análise ou validação técnica?
- A evidência foi retida e revista pela gestão?
Uma pasta com exportações da ferramenta de análise raramente responde a estas perguntas. Numa auditoria ISO 27001:2022, o auditor verifica se o SGSI funciona conforme desenhado. Ao abrigo da NIS2, os órgãos de gestão devem aprovar e supervisionar as medidas de gestão de riscos de cibersegurança. Ao abrigo da DORA, as entidades financeiras precisam de um quadro documentado de gestão do risco das TIC, ciclo de vida de incidentes, testes de resiliência e controlos de risco de terceiros de TIC. Ao abrigo do GDPR da UE, a questão passa a ser se medidas técnicas e organizativas adequadas protegeram os dados pessoais e se a responsabilização pode ser demonstrada.
As cláusulas 4.1 a 4.4 da ISO/IEC 27001:2022 exigem que a organização compreenda o seu contexto, partes interessadas, requisitos e âmbito do SGSI. A gestão de vulnerabilidades e patches não pode ser desenhada de forma isolada. Deve refletir contratos com clientes, reguladores, dependências de nuvem, serviços de TIC externalizados, obrigações de proteção de dados e serviços críticos.
As cláusulas 6.1.1 a 6.1.3 da ISO/IEC 27001:2022 exigem avaliação de riscos, tratamento de riscos, seleção de controlos, uma Declaração de Aplicabilidade e aprovação do risco residual pelo proprietário do risco. Isto significa que a evidência de vulnerabilidades deve ligar-se ao Registo de Riscos, ao plano de tratamento de riscos e à SoA.
A ISO/IEC 27005:2022 reforça este modelo ao incentivar as organizações a consolidar requisitos do Anexo A, obrigações setoriais, regulamentos, contratos, regras internas e controlos existentes na linha de base da avaliação de riscos. Também enfatiza critérios de probabilidade, consequência, obrigações legais, relações com fornecedores, impacto na privacidade e impacto de terceiros. Em termos práticos, uma vulnerabilidade não é apenas um número CVSS. É um evento de risco ligado a ativos, obrigações, partes interessadas e consequências para o negócio.
A pressão regulamentar por detrás da evidência de patches
A regulamentação moderna de cibersegurança tolera cada vez menos a aplicação informal de patches.
A NIS2 aplica-se a muitas entidades médias e grandes em setores de elevada criticidade e em outros setores críticos, e também pode abranger determinadas entidades independentemente da dimensão. O seu âmbito inclui fornecedores de infraestrutura digital, como serviços de computação em nuvem, serviços de centro de dados, redes de distribuição de conteúdos, fornecedores de comunicações eletrónicas públicas, serviços de confiança, serviços DNS e TLD, bem como prestadores de gestão de serviços de TIC, como prestadores de serviços geridos e prestadores de serviços de segurança geridos. Abrange igualmente fornecedores digitais importantes, como mercados em linha, motores de pesquisa em linha e plataformas de redes sociais.
O Artigo 20 da NIS2 torna a cibersegurança uma responsabilidade do órgão de gestão. O Artigo 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade do negócio, segurança da cadeia de fornecimento, aquisição segura, desenvolvimento seguro, manutenção segura, tratamento e divulgação de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, controlo de acesso, gestão de ativos e autenticação. O Artigo 23 cria um processo faseado de notificação de incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e relatório final no prazo de um mês, quando aplicável.
A DORA cria, a partir de 17 de janeiro de 2025, um conjunto de regras de resiliência operacional digital diretamente aplicável às entidades financeiras. Abrange gestão do risco das TIC, reporte de incidentes graves relacionados com TIC, testes de resiliência operacional, partilha de informações sobre ameaças, gestão do risco de terceiros de TIC e supervisão de prestadores terceiros críticos de serviços de TIC. Os Artigos 5 e 6 colocam a governação do risco das TIC sob responsabilidade do órgão de gestão e exigem um quadro de gestão do risco das TIC documentado, integrado e revisto regularmente. O Artigo 8 reforça a necessidade de identificar funções de negócio suportadas por TIC, ativos de informação, ativos de TIC e dependências. Os Artigos 17 a 20 exigem deteção, registo, classificação, escalonamento, reporte, comunicação, remediação e aprendizagem para incidentes relacionados com TIC. Os Artigos 28 a 30 exigem que o risco de terceiros de TIC seja controlado através de registos, diligência prévia, salvaguardas contratuais, direitos de auditoria, planeamento de saída e supervisão.
Para entidades financeiras abrangidas pela DORA, a DORA geralmente prevalece sobre obrigações equivalentes de gestão de riscos e reporte da NIS2. Mas a NIS2 continua a ser relevante para a coordenação do ecossistema e para entidades fora do âmbito da DORA. Para fornecedores SaaS, MSP e MSSP que servem clientes financeiros, a realidade prática é direta: os clientes podem exigir a sua evidência de gestão de vulnerabilidades para cumprir as respetivas obrigações DORA.
O GDPR da UE acrescenta outra camada. Os Artigos 2 e 3 podem aplicar-se a organizações estabelecidas na UE e a organizações fora da UE que ofereçam bens ou serviços a pessoas na UE ou monitorizem o seu comportamento. O Artigo 5 exige a proteção de dados pessoais e a responsabilização pelo cumprimento. O Artigo 4 define uma violação de dados pessoais como um incidente de segurança que conduz à perda, destruição, alteração, divulgação não autorizada ou acesso acidental ou ilícito a dados pessoais. Um patch adiado numa base de dados, plataforma de identidade ou portal de clientes pode tornar-se uma questão de responsabilização em privacidade.
Da política à prova
O primeiro passo é definir as regras. Uma política sólida de gestão de vulnerabilidades e patches não é apenas um documento de auditoria. É a constituição operacional do controlo.
Para ambientes empresariais, a Política de Gestão de Vulnerabilidades e Patches liga explicitamente a aplicação técnica de patches à conformidade transversal:
Esta política apoia a conformidade com o Controlo 8.8 do Anexo A da ISO/IEC 27001 e com as orientações da ISO/IEC 27002, e aborda requisitos regulamentares ao abrigo do Artigo 8 da DORA, do Artigo 21 da NIS2, do Artigo 32 do GDPR da UE e dos domínios DSS e APO do COBIT 2019.
Da secção “Finalidade”.
A mesma política estabelece a expectativa de governação para o artefacto central de evidência:
Deve ser mantido um Registo de Gestão de Vulnerabilidades centralizado pela equipa de Operações de Segurança e revisto mensalmente pelo CISO ou por autoridade delegada.
Da secção “Requisitos de governação”, cláusula 5.1 da política.
Também define a cadência de análise:
Todos os sistemas devem ser analisados pelo menos mensalmente; ativos de alto risco ou expostos externamente devem ser analisados semanalmente.
Da secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.
E impede que a aplicação urgente de patches se transforme em atividade técnica não controlada:
Todas as atividades de remediação devem ser coordenadas através do processo de gestão de alterações (conforme P5 - Política de Gestão de Alterações) para assegurar a estabilidade e a preservação do rasto de auditoria.
Da secção “Requisitos de governação”, cláusula 5.5 da política.
Para PME, os mesmos princípios de evidência podem ser implementados de forma mais simples. A Política de Gestão de Vulnerabilidades e Patches para PME estabelece:
Manter registos precisos de patches aplicados, questões pendentes e exceções para assegurar a preparação para auditoria
Da secção “Objetivos”, cláusula 3.4 da política.
Em seguida, define o registo de patches como evidência de auditoria:
Deve ser mantido um registo de patches e revisto durante auditorias e atividades de resposta a incidentes
Da secção “Requisitos de governação”, cláusula 5.4.1 da política.
E especifica o conteúdo mínimo:
Os registos devem incluir o nome do dispositivo, a atualização aplicada, a data de aplicação do patch e o motivo de qualquer atraso
Da secção “Requisitos de governação”, cláusula 5.4.2 da política.
Para exposição urgente à Internet, a política para PME estabelece um requisito mensurável:
Patches críticos devem ser aplicados no prazo de 3 dias após o lançamento, especialmente em sistemas expostos à Internet
Da Política de Gestão de Vulnerabilidades e Patches para PME, secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.
Estas cláusulas transformam trabalho técnico em evidência. A política define expectativas. O registo documenta constatações. O ticket atribui trabalho. O registo de alteração controla a implementação. O registo de patches prova a ação. O Registo de Riscos captura exceções. As atas de revisão provam supervisão.
O modelo da Clarysec orientado à evidência
O modelo da Clarysec orientado à evidência assenta num princípio: cada constatação de vulnerabilidade deve ser rastreável desde a descoberta até à decisão.
No Zenith Blueprint: roteiro de 30 passos para auditores, a fase Controlos em ação, Passo 19: Controlos tecnológicos I, trata a gestão de vulnerabilidades como um controlo repetível e não como um requisito teórico:
A gestão de vulnerabilidades é uma das áreas mais críticas da higiene de cibersegurança moderna. Embora firewalls e ferramentas antivírus forneçam proteção, podem ser comprometidas se sistemas sem patches ou serviços mal configurados ficarem expostos.
O mesmo passo explica que as organizações devem utilizar calendários regulares de aplicação de patches, ferramentas de análise de vulnerabilidades, triagem, atribuição, acompanhamento da remediação, controlos compensatórios e aceitação do risco residual. Mais importante ainda, enquadra corretamente a perspetiva de auditoria:
O controlo não visa a perfeição; visa a existência de um processo organizado, transparente e responsabilizável.
Para os auditores, esta distinção é importante. Uma organização madura pode ter vulnerabilidades em aberto e, ainda assim, demonstrar controlo, desde que exista priorização baseada no risco, titularidade documentada, exceções aprovadas, controlos compensatórios e remediação verificada.
O Zenith Blueprint também alerta que os auditores irão analisar esta área em detalhe:
Este é um controlo de alta prioridade para auditores, e normalmente será analisado em profundidade. Espere que lhe perguntem com que frequência os sistemas são corrigidos, que processo segue quando é anunciado um zero-day e quais são os sistemas mais difíceis de corrigir.
É por isso que um CISO não deve entrar numa auditoria apenas com um painel da ferramenta de análise. O pacote de evidência deve mostrar governação, processo, execução, verificação e melhoria.
Mapeamento de controlos ISO 27002 para evidência de auditoria
O Zenith Controls: guia de conformidade transversal atua como uma bússola de conformidade transversal ao mapear controlos da ISO/IEC 27002:2022 e mostrar como se relacionam com as expectativas de auditoria. Para a gestão de vulnerabilidades e patches, três controlos da ISO/IEC 27002:2022 formam o triângulo operacional.
O controlo 8.8 da ISO/IEC 27002:2022, Gestão de vulnerabilidades técnicas, é o controlo central. É preventivo, apoia confidencialidade, integridade e disponibilidade, alinha-se com os conceitos de cibersegurança Identificar e Proteger e liga-se à gestão de ameaças e vulnerabilidades.
O controlo 8.32 da ISO/IEC 27002:2022, Gestão de alterações, também é preventivo. Liga a aplicação de patches à implementação controlada, testes, aprovação, reversão e auditabilidade.
O controlo 5.36 da ISO/IEC 27002:2022, Conformidade com políticas, regras e normas de segurança da informação, assegura que o processo não é opcional nem dependente de esforços individuais. Liga a gestão de vulnerabilidades ao cumprimento da política, garantia e supervisão.
| Controlo ISO/IEC 27002:2022 mapeado no Zenith Controls | Relevância para auditoria | Evidência prática |
|---|---|---|
| 8.8 Gestão de vulnerabilidades técnicas | Mostra que as vulnerabilidades são identificadas, avaliadas e tratadas | Relatórios de análise, registo de vulnerabilidades, notas de triagem, tickets de remediação, validação de encerramento |
| 8.32 Gestão de alterações | Mostra que a remediação é controlada e auditável | Pedidos de alteração, aprovações, planos de reversão, resultados dos testes, registos de implementação |
| 5.36 Conformidade com políticas, regras e normas de segurança da informação | Mostra que as obrigações das políticas são monitorizadas | Atestados de conformidade, revisões de conformidade, registos de exceções, resultados de auditoria interna |
Este mapeamento evita uma falha comum de auditoria. A Segurança diz: “Aplicámos o patch.” As Operações dizem: “Implementámos.” A Conformidade diz: “Não conseguimos provar a sequência.” Uma cadeia de evidência mapeada dá às três equipas a mesma narrativa.
A cadeia de evidência que os auditores esperam
Uma cadeia de evidência defensável para a gestão de vulnerabilidades tem sete fases.
| Fase | O que acontece | Evidência criada |
|---|---|---|
| Descoberta | Ferramenta de análise, aviso do fornecedor, reporte de bug bounty, inteligência sobre ameaças ou teste interno identifica uma vulnerabilidade | Exportação da análise, aviso, alerta, carimbo temporal de deteção |
| Âmbito e titularidade | Ativo, proprietário, serviço, tipo de dados e exposição são confirmados | Ligação ao inventário de ativos, atribuição de proprietário, mapeamento do serviço de negócio |
| Triagem de risco | A severidade é avaliada com base em explorabilidade, exposição, criticidade do ativo, sensibilidade dos dados e impacto no negócio | Classificação de risco, notas de triagem, seleção de SLA, ligação ao Registo de Riscos |
| Planeamento da remediação | Patch, correção de configuração, controlo compensatório ou caminho de atualização é selecionado | Ticket de remediação, plano técnico, notas de dependências |
| Controlo de alterações | A remediação é aprovada, agendada, testada e implementada | Pedido de alteração, aprovação, evidência de testes, registo de implementação |
| Verificação | Nova análise ou validação confirma que a questão foi corrigida ou mitigada | Resultado sem constatações, prova de versão, captura de ecrã da configuração, nota de validação |
| Revisão de governação | Exceções, atrasos, riscos residuais e tendências são revistos | Registo de patches, aprovação de exceção, atas de revisão pelo CISO, relatório de KPI |
A diferença prática entre “fazemos análises” e “estamos preparados para auditoria” é a continuidade. Se uma vulnerabilidade não puder ser rastreada desde a descoberta até ao encerramento, o controlo é fraco. Se existirem exceções sem aprovação, o processo é fraco. Se os patches contornarem a gestão de alterações, o rasto de auditoria é fraco. Se vulnerabilidades críticas permanecerem em aberto sem controlos compensatórios, a governação é fraca.
A Política de Auditoria e Monitorização da Conformidade apoia a automatização como parte deste modelo:
Devem ser implementadas ferramentas automatizadas para monitorizar a conformidade da configuração, a gestão de vulnerabilidades, o estado dos patches e o acesso privilegiado.
Da secção “Requisitos de implementação da política”, cláusula 6.4.1 da política.
Para PME, a Política de Auditoria e Monitorização da Conformidade para PME define a verificação de controlos técnicos em termos práticos:
Verificação de controlos técnicos (por exemplo, estado das cópias de segurança, configuração de controlo de acesso, registos de patches)
Da secção “Requisitos de implementação da política”, cláusula 6.1.1.2 da política.
Pequenas organizações não precisam de ferramentas de nível empresarial para ficarem preparadas para auditoria. Precisam de evidência consistente. Um registo simplificado, um quadro de tickets, um registo de patches e uma revisão mensal podem ser suficientes se forem completos, atuais e ligados ao risco.
Exemplo: uma constatação crítica totalmente pronta para auditoria
A análise externa semanal da Maria identifica a CVE-2026-12345 num gateway de API de pagamentos exposto à Internet. A ferramenta de análise classifica-a como crítica. O serviço trata metadados de identidade de clientes e transações, pelo que podem existir implicações de GDPR da UE e DORA. O gateway é propriedade da Engenharia de Plataforma, mas o patch exige uma indisponibilidade breve.
Este é o fluxo de trabalho pronto para auditoria.
1. Criar a entrada no registo de vulnerabilidades
A equipa de segurança regista a constatação no registo central:
- Identificador da constatação: VULN-2026-0142
- Fonte: análise externa semanal
- Data e hora de descoberta
- Ativo: api-gw-prod-01
- Proprietário: Engenharia de Plataforma
- Exposição: exposto à Internet
- Contexto dos dados: metadados de identidade de clientes e transações
- Severidade: crítica
- SLA: 72 horas ou mais restrito com base na política
- Ticket: SEC-4821
- Registo de alteração: CHG-10988
- Estado: remediação planeada
2. Fazer a triagem com base no contexto de negócio e regulamentar
A equipa verifica a disponibilidade de exploração, a superfície de ataque, os requisitos de autenticação, o impacto no negócio e a sensibilidade dos dados. Como o sistema está exposto à Internet e suporta fluxos de trabalho de clientes, a vulnerabilidade permanece crítica. O proprietário do risco é o responsável de Plataforma, e o CISO é notificado devido a possíveis implicações de NIS2, DORA e GDPR da UE.
As cláusulas 7.1 a 7.4 da ISO/IEC 27005:2022 apoiam a identificação de riscos, titularidade, consequência, probabilidade e priorização. As cláusulas 8.2 a 8.6 apoiam a seleção de tratamento, determinação de controlos, ligação à SoA, planeamento de tratamento e aprovação do risco residual.
3. Abrir uma alteração de emergência controlada
O patch é agendado para a mesma noite. O registo de alteração inclui a referência do fornecedor, serviços afetados, plano de testes, plano de reversão, janela de manutenção, decisão de comunicação ao cliente, aprovações e requisito de validação pós-implementação.
Isto apoia diretamente o controlo 8.32 da ISO/IEC 27002:2022 e o requisito da política empresarial de coordenar a remediação através da gestão de alterações.
4. Aplicar o patch e atualizar o registo de patches
O registo de patches documenta o nome do dispositivo, a atualização aplicada, a data de aplicação do patch e o motivo de atraso, se existir. Se a aplicação do patch tivesse sido adiada, a equipa documentaria controlos compensatórios, como regras de firewall de aplicações web, restrições temporárias de acesso, aumento do registo de eventos, isolamento ou monitorização reforçada.
5. Verificar e encerrar
A Segurança volta a analisar o gateway de API. A vulnerabilidade já não aparece. O ticket é atualizado com evidência de análise sem constatações, versão do patch, carimbo temporal de implementação e ligação ao registo de alteração. O estado no registo de vulnerabilidades muda para “Encerrado, verificado.”
6. Rever o impacto de reporte
Se não houve exploração nem interrupção de serviços, o reporte de incidentes ao abrigo da NIS2 ou DORA pode não ser desencadeado. Se forem encontrados indicadores de compromisso (IOC), o processo de incidentes deve classificar o impacto e o escalonamento. Ao abrigo da NIS2, um incidente significativo pode exigir alerta precoce e reporte faseado. Ao abrigo da DORA, um incidente grave relacionado com TIC exige classificação e reporte através do processo aplicável da autoridade competente.
7. Integrar as lições na revisão pela gestão
No final do mês, a revisão pelo CISO regista que a vulnerabilidade foi detetada pela análise externa semanal, remediada dentro do SLA, verificada por nova análise e encerrada sem incidente. Se questões semelhantes se repetirem, o plano de tratamento pode incluir referenciais de configuração segura, implementação automatizada de patches, escalonamento de fornecedores ou modernização da aplicação.
Quando um auditor pergunta sobre a CVE-2026-12345, Maria pode apresentar um pacote organizado em vez de mensagens de correio eletrónico e capturas de ecrã.
| Tipo de evidência | Documento ou registo | Finalidade |
|---|---|---|
| Governação | Política de Gestão de Vulnerabilidades e Patches | Mostra âmbito, papéis, cadência de análise, SLA de patches e regras de exceção |
| Processo | Registo de Gestão de Vulnerabilidades | Demonstra identificação, titularidade, priorização e acompanhamento |
| Execução | Ticket de gestão de alterações | Mostra testes, aprovação, implementação e planeamento de reversão |
| Verificação | Evidência de análise antes e depois | Prova que a vulnerabilidade existia e foi remediada |
| Supervisão | Ata de revisão pelo CISO | Mostra conhecimento pela gestão, revisão de tendências e ações de acompanhamento |
Isto é estar pronto para auditoria. Não porque a organização não tivesse vulnerabilidades, mas porque tinha controlo.
Um conjunto de evidência, múltiplas obrigações
Um programa bem desenhado de gestão de vulnerabilidades e patches pode satisfazer múltiplos referenciais sem duplicar trabalho.
Para ISO 27001:2022, a evidência apoia o SGSI baseado no risco, a implementação de controlos do Anexo A, a Declaração de Aplicabilidade, planos de tratamento de riscos, auditoria interna e melhoria contínua. Se o controlo 8.8 da ISO/IEC 27002:2022 for aplicável na SoA, a organização deve conseguir demonstrar a justificação legal, regulamentar, de risco ou de negócio. Essa justificação inclui frequentemente o Artigo 21 da NIS2, obrigações de risco das TIC da DORA, responsabilização do GDPR da UE, contratos com clientes e necessidades de resiliência operacional.
Para NIS2, a mesma evidência ajuda a demonstrar as medidas do Artigo 21, incluindo análise de riscos, tratamento de vulnerabilidades, tratamento de incidentes, continuidade do negócio, segurança da cadeia de fornecimento, higiene de cibersegurança, controlo de acesso e avaliação da eficácia. O Artigo 20 é demonstrado através da revisão pelo CISO, reporte ao órgão de administração, aprovação pela gestão e formação em cibersegurança. O Artigo 23 torna-se relevante se a exploração causar ou puder causar perturbação operacional grave, perda financeira ou dano a terceiros.
Para DORA, a evidência de vulnerabilidades e patches apoia o quadro de gestão do risco das TIC, a supervisão pelo órgão de gestão, a estratégia de resiliência, a deteção e classificação de incidentes, os testes de resiliência e a supervisão de terceiros de TIC. Quando um prestador de TIC aloja ou gere o sistema afetado, os Artigos 28 a 30 exigem diligência prévia, proteções contratuais, direitos de auditoria, assistência em incidentes e considerações de saída.
Para GDPR da UE, a mesma evidência apoia a responsabilização do Artigo 5 e a postura de segurança esperada ao abrigo do Artigo 32. Se uma vulnerabilidade conduzir a acesso, alteração, perda ou divulgação não autorizados de dados pessoais, a cronologia da vulnerabilidade, registos de patches, registos de monitorização e notas de avaliação de violação tornam-se essenciais.
Para COBIT 2019 e garantia ao estilo ISACA, a gestão de vulnerabilidades é avaliada através da segurança operacional, monitorização de controlos, habilitação de alterações e responsabilização de governação. As referências de conformidade transversal do Zenith Blueprint destacam COBIT 2019 DSS05.04 e BAI09.02, além das expectativas de garantia ITAF sobre gestão de vulnerabilidades, aplicação de patches e gestão segura de alterações.
Normas ISO de suporte reforçam o modelo operacional. A ISO/IEC 27005:2022 apoia a avaliação de riscos e o tratamento de riscos. A ISO/IEC 27035:2023 apoia a resposta a incidentes quando vulnerabilidades são exploradas. A ISO/IEC 30111 apoia processos de tratamento de vulnerabilidades. A ISO/IEC 29147 apoia divulgação de vulnerabilidades e avisos. A ISO/IEC 27017 apoia a gestão de vulnerabilidades na nuvem. A ISO 22301 apoia o planeamento de continuidade quando vulnerabilidades técnicas podem interromper serviços de negócio.
Como diferentes auditores testam o mesmo processo
Diferentes avaliadores usam diferentes perspetivas. A evidência pode ser a mesma, mas as perguntas mudam.
| Perfil do auditor | Foco provável da auditoria | Evidência que satisfaz a pergunta |
|---|---|---|
| Auditor ISO 27001:2022 | A gestão de vulnerabilidades faz parte do SGSI, do tratamento de riscos e da SoA? | Mapeamento da SoA, Registo de Riscos, registo de vulnerabilidades, plano de tratamento, resultados de auditoria interna, revisão pela gestão |
| Avaliador orientado para NIS2 | Existem medidas adequadas e proporcionadas implementadas e supervisionadas pela gestão? | Mapeamento do Artigo 21, revisão pelo órgão de administração ou CISO, processo de tratamento de vulnerabilidades, fluxo de trabalho de incidentes, evidência de fornecedores |
| Avaliador DORA | A gestão de vulnerabilidades está integrada na gestão do risco das TIC e na resiliência operacional? | Quadro de risco das TIC, mapeamento de serviços críticos, SLA de patches, evidência de testes de resiliência, registo de terceiros de TIC |
| Revisor GDPR da UE | A organização protegeu os dados pessoais e demonstrou responsabilização? | Mapeamento de ativos de dados, cronologia da vulnerabilidade, registos de acesso, registos de patches, notas de avaliação de violação |
| Auditor COBIT 2019 ou ISACA | As operações, a governação e os controlos de alterações são eficazes e monitorizados? | Relatórios de monitorização de controlos, registos de alterações, KPI de remediação, aprovações de exceções, testes de garantia |
| Revisor de garantia orientado para NIST | As atividades Identify e Protect operam de forma consistente? | Inventário de ativos, análises de vulnerabilidades, lógica de priorização, fluxo de trabalho de remediação, evidência de monitorização |
A política diz o que deve acontecer. A evidência operacional mostra o que aconteceu. Os registos de revisão mostram que a gestão sabia, questionou e atuou.
Razões comuns para a gestão de patches falhar uma auditoria
A maioria das constatações não resulta da ausência de uma ferramenta de análise. Resulta de falhas de rastreabilidade.
O inventário de ativos está incompleto.
Se uma ferramenta de análise encontra ativos que estão em falta na CMDB ou no registo de ativos, a titularidade e o impacto no negócio não podem ser avaliados de forma fiável. Isto compromete o âmbito, a avaliação de riscos e o tratamento de riscos da ISO 27001:2022.
As vulnerabilidades são acompanhadas apenas na ferramenta de análise.
Painéis de ferramentas de análise não são registos de governação. Frequentemente não incluem aprovação pelo proprietário do risco, justificação de exceção, referências de alterações e contexto de negócio.
Constatações críticas não têm evidência de SLA.
Uma política pode dizer que vulnerabilidades críticas são corrigidas no prazo de três dias. A pergunta de auditoria é se os registos provam que isso aconteceu.
As exceções são informais.
Sistemas legados, restrições de indisponibilidade e atrasos de fornecedores acontecem. Mas “não conseguimos aplicar o patch” deve tornar-se uma exceção documentada com controlos compensatórios, data de expiração e aprovação do risco residual.
A aplicação de patches de emergência contorna a gestão de alterações.
Alterações de emergência continuam a ser alterações. Se não existir evidência de aprovação, testes ou reversão, os auditores podem concluir que a remediação criou risco operacional.
Os sistemas de terceiros são invisíveis.
Ao abrigo da NIS2 e da DORA, o risco de fornecedores e de terceiros de TIC é central. Se um prestador aplica patches na plataforma, continua a precisar de evidência, direitos contratuais, reporte de serviço e vias de escalonamento.
Ninguém revê tendências.
Vulnerabilidades recorrentes podem indicar gestão da configuração fraca, práticas de desenvolvimento seguro insuficientes, ativos sem suporte ou falha de fornecedor. A revisão mensal transforma dados técnicos em ação de governação.
O pacote de auditoria de vulnerabilidades da Clarysec
Para uma revisão de preparação próxima de ISO 27001:2022, NIS2 ou DORA, a Clarysec ajuda as organizações a reunir um pacote de auditoria de gestão de vulnerabilidades e patches com os seguintes elementos:
- Política de Gestão de Vulnerabilidades e Patches, incluindo âmbito, papéis, cadência de análise, SLA de patches e regras de exceção
- Extrato do inventário de ativos que mostre sistemas dentro do âmbito, proprietários, criticidade e exposição
- Relatórios mais recentes de análises internas e externas de vulnerabilidades
- Registo central de Gestão de Vulnerabilidades com itens em aberto, encerrados e em exceção
- Registos de patches que mostrem dispositivo, atualização, data do patch e motivos de atraso
- Registos de alterações para amostras de vulnerabilidades críticas e altas
- Evidência de novas análises ou validação após remediação
- Aprovações de exceções e de risco residual para sistemas com patches adiados ou não aplicáveis
- Processo de monitorização de avisos de segurança para fornecedores, bibliotecas e serviços na nuvem
- Atas mensais de revisão pelo CISO ou pela gestão
- Correspondência com obrigações de ISO 27001:2022, NIS2, DORA, GDPR da UE e COBIT 2019
- Resultados de auditoria interna ou de verificação de controlos técnicos
No Zenith Blueprint, fase Auditoria, revisão e melhoria, Passo 24, a Clarysec sublinha a rastreabilidade entre a Declaração de Aplicabilidade, o Registo de Riscos e o plano de tratamento:
A sua SoA deve ser consistente com o Registo de Riscos e o Plano de Tratamento de Riscos. Confirme novamente que cada controlo escolhido como tratamento de risco está marcado como “Aplicável” na SoA.
Isto é especialmente importante para a gestão de vulnerabilidades. Se o controlo 8.8 for aplicável, o pacote de auditoria deve provar não apenas que existem análises, mas que as constatações são governadas através do tratamento de riscos e da melhoria contínua.
Sprint de preparação de 30 dias
Se a auditoria está próxima, não comece por reescrever tudo. Comece por construir evidência rapidamente.
| Semana | Foco | Resultado |
|---|---|---|
| Semana 1 | Confirmar o âmbito do SGSI, serviços críticos, ativos externos, serviços na nuvem, fornecedores e sistemas com dados pessoais | Inventário de referência, exportações de análises atuais, comparação entre ferramenta de análise e ativos |
| Semana 2 | Limpar o Registo de Gestão de Vulnerabilidades, atribuir proprietários, classificar constatações críticas e altas | Registo priorizado, atribuições de proprietários, tickets de remediação em aberto |
| Semana 3 | Aplicar patches ao que puder ser corrigido, encaminhar a remediação pela gestão de alterações, documentar exceções | Registos de patches atualizados, registos de alterações, controlos compensatórios, aprovações de risco residual |
| Semana 4 | Executar nova análise, encerrar itens verificados, preparar reporte à gestão e mapeamento de conformidade | Evidência de encerramento, pacote de revisão pelo CISO, correspondência ISO 27001:2022, NIS2, DORA, GDPR da UE e COBIT 2019 |
Este sprint não eliminará toda a dívida técnica. Alterará a conversa de auditoria. Em vez de defender uma exportação confusa da ferramenta de análise, poderá mostrar um processo governado com proprietários, prazos, ações, decisões e supervisão.
Passe de análises para evidência defensável
A preparação para auditoria da gestão de vulnerabilidades e patches não consiste em provar que não existem vulnerabilidades. Consiste em provar que consegue encontrá-las, compreendê-las, priorizá-las, corrigi-las, controlar exceções e demonstrar supervisão.
O Zenith Blueprint, o Zenith Controls, a Política de Gestão de Vulnerabilidades e Patches, a Política de Gestão de Vulnerabilidades e Patches para PME, a Política de Auditoria e Monitorização da Conformidade e a Política de Auditoria e Monitorização da Conformidade para PME da Clarysec fornecem a estrutura para criar esse fluxo de trabalho de evidência.
Se a sua organização está a preparar-se para certificação ISO 27001:2022, preparação para NIS2, resiliência operacional digital DORA, diligência prévia de clientes ou auditoria interna, comece com uma pergunta:
Cada vulnerabilidade crítica pode ser rastreada desde a análise até ao encerramento?
Se a resposta for não, a Clarysec pode ajudá-lo a construir o registo, o conjunto de políticas, o mapeamento de conformidade transversal, o pacote de revisão pela gestão e o fluxo de trabalho de evidência pronto para auditoria que transforma a análise técnica em governação defensável.
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
