Exceções criptográficas na ISO 27001: guia de evidência e CER

A conversa de auditoria que David mais receava chegou três semanas antes do previsto. A InnovatePay tinha acabado de adquirir uma empresa mais pequena, a QuickAcquire. A operação foi uma vitória estratégica, mas, escondido na pilha tecnológica, existia um módulo legado de transferência de dados que usava uma biblioteca criptográfica não conforme com as normas aprovadas da InnovatePay. Substituí-lo era um projeto de seis meses. O auditor externo chegaria na semana seguinte.

Na cabeça de David, o cenário era dolorosamente claro. O auditor, calmo e metódico, identificaria o desvio e faria a pergunta que transforma sabemos que isto é arriscado numa não conformidade: mostre-me a evidência da exceção criptográfica e explique como decidiram que era aceitável.

Nesse momento, a intenção não conta; o controlo conta. Sem um processo de exceção documentado, aceitação do risco pela gestão, controlos compensatórios, logs de gestão de chaves e um plano de remediação limitado no tempo, é provável que um auditor trate a situação como falha de controlo ou como governação fraca do SGSI. Este guia de referência mostra como transformar esse momento numa demonstração de maturidade, usando os kits de ferramentas e políticas da Clarysec, o controlo A.8.24 Utilização da criptografia da ISO/IEC 27001:2022 e uma perspetiva de conformidade transversal que abrange NIS2, DORA, RGPD da UE, NIST e COBIT 2019.

Porque as exceções criptográficas são inevitáveis e como os auditores as avaliam

As exceções criptográficas existem por razões previsíveis. Nos trabalhos da Clarysec, observamos padrões recorrentes:

• Restrições de tecnologia legada, por exemplo algoritmos, conjuntos de cifras ou comprimentos de chave não suportados.
• Dependência de fornecedores e atrasos de certificação que impedem atualizações atempadas para criptografia aprovada.
• Realidades operacionais na resposta a incidentes ou em análise forense que exigem desvios temporários para recolher evidência ou manter a continuidade do serviço.
• Períodos de migração, em que a interoperabilidade transitória obriga a definições mais fracas por tempo limitado.
• Restrições de parceiros ou clientes que impedem a aplicação da configuração de referência preferida.

Os auditores de ISO/IEC 27001:2022 não exigem perfeição; exigem controlo. Avaliam se a cifragem é apropriada e consistente, se a gestão de chaves é governada e registada, e se a organização identifica e gere ativamente algoritmos obsoletos no seu ambiente. O primeiro passo é alinhar a forma como gere exceções com aquilo que os auditores esperam ver.

Ancorar a exceção na política e na governação do risco

Um SGSI maduro trata exceções como decisões de tratamento do risco, não como dívida técnica. O mecanismo formal é um Pedido de Exceção Criptográfica (CER), e a cláusula da política que o exige é o ponto de ligação entre uma exceção gerida e uma constatação.

A Política de Controlos Criptográficos empresarial da Clarysec exige: A utilização de algoritmos criptográficos não normalizados ou o desvio temporário face a práticas de ciclo de vida aprovadas requer um Pedido de Exceção Criptográfica documentado. Esta família de políticas liga-se diretamente ao tratamento do risco. A Política de Gestão do Risco complementar apoia a avaliação do risco de controlos criptográficos e documenta a estratégia de tratamento do risco para exceções, obsolescência algorítmica ou cenários de comprometimento de chaves.

Assim que o requisito existe na política, cada exceção deve ser rastreável a um CER com aceitação do risco pela gestão, uma entrada associada no registo de riscos, controlos compensatórios e um plano de saída. Apresente estes artefactos antes de alguém os pedir, conduzindo o auditor pela governação e, depois, pelo estado técnico, usando a abordagem de entrevista e amostragem definida no Zenith Blueprint.

Estruturar o CER como um registo de controlo preparado para auditoria

Comentários em tickets não são registos de exceção. Um CER deve ser estruturado, sujeito a controlo de versões e amostrado como qualquer outro controlo. Quer seja implementado numa ferramenta GRC ou num modelo controlado, um CER robusto inclui:

• Resumo da exceção, o que não está conforme e onde.
• Âmbito, tipos de dados e se a exceção afeta dados em repouso, dados em trânsito ou ambos.
• Justificação de negócio, o motivo associado a restrições de serviço ou de negócio.
• Avaliação do impacto na segurança, cenários de ameaça realistas, como risco de downgrade, MITM, funções de hash fracas ou comprometimento de chaves.
• Controlos compensatórios, por exemplo segmentação, certificados de cliente, duração curta de sessão, regras WAF, autenticação adicional e monitorização reforçada.
• Classificação do risco antes e depois dos controlos compensatórios, alinhada com a matriz de riscos.
• Proprietário, um proprietário do risco responsável na área de negócio.
• Aprovações, segurança, proprietário do sistema e aceitação do risco pela gestão.
• Data de expiração e frequência de revisão, sem prazo indefinido.
• Plano de saída, roteiro, dependências, marcos e datas limite.
• Referências de evidência, ligações para configurações, logs, resultados dos testes, declarações de fornecedores e aprovações de alterações.

No caso de David, a exceção da QuickAcquire passou de uma responsabilidade oculta para uma decisão auditável quando ele apresentou o CER na reunião de abertura, disponibilizou o pacote de evidência e convidou o auditor a realizar amostragem.

O pacote mínimo viável de evidência para uma exceção criptográfica

Os auditores esperam mais do que uma fotografia técnica. Para exceções, procuram prova de governação e de funcionamento operacional. Um pacote prático de evidência inclui:

1. O CER preenchido, com aprovações e data de expiração.
2. A avaliação do risco associada e a decisão de tratamento.
3. Procedimentos de gestão de chaves para o sistema afetado, com logs de geração, distribuição, rotação, acesso e destruição de chaves.
4. Registos de alterações das definições criptográficas e evidência de testes que demonstre que as alterações foram validadas ou que as restrições foram verificadas.
5. Evidência de monitorização e deteção dos controlos compensatórios, incluindo regras SIEM e testes de alertas.
6. Registos de comunicações que demonstrem que o pessoal impactado foi informado e formado sobre o desvio e as expectativas de monitorização.
7. Um plano de saída limitado no tempo, com marcos, datas, orçamento quando aplicável e responsáveis.
8. Histórico de revisão da política que demonstre a manutenção da configuração de referência criptográfica e a gestão do ciclo de vida dos algoritmos.

Estes tipos de evidência alinham-se com a orientação da ISO/IEC 27002:2022 sobre criptografia e gestão de alterações.

Usar o Zenith Blueprint para recolher e apresentar evidência

O método de evidência no Zenith Blueprint é direto e adequado a auditoria: entrevistar, rever, observar e amostrar. Aplique-o às exceções:

• Entrevistar o proprietário do sistema e o responsável pela segurança. Porque é que a exceção é necessária, o que mudou desde a última revisão e qual é o próximo passo no plano de saída.
• Rever o CER, o registo de risco, a cláusula da política e as restrições de fornecedor ou parceiro. Confirmar as datas de expiração e de revisão.
• Observar o estado técnico, isto é, a configuração exata, onde a exceção é aplicada e onde os controlos compensatórios estão implementados.
• Amostrar várias exceções, normalmente três a cinco, para demonstrar consistência na estrutura, aprovações, revisões, registo em logs e gestão de expiração.

Exemplo prático: tornar auditável uma exceção TLS legada

Cenário: Uma integração B2B crítica para a receita exige um conjunto de cifras TLS mais antigo porque o endpoint do parceiro não consegue negociar as definições aprovadas. Interromper a ligação não é viável.

Torne-a auditável em quatro passos:

1. Criar o CER e ligá-lo ao risco. Defina uma expiração de 90 dias, com revisões a cada 30 dias, anexe a correspondência com o parceiro e associe-o a uma entrada do registo de riscos com proprietário no negócio.
2. Escolher controlos compensatórios que gerem evidência. Restrinja IPs de origem aos intervalos do parceiro com registos de alterações de firewall. Aplique TLS mútuo, se possível, e retenha registos de emissão de certificados. Aumente a monitorização de anomalias no handshake e retenha as definições das regras SIEM e os testes de alertas.
3. Demonstrar disciplina na gestão de chaves. Apresente logs de acesso ao KMS, atribuições RBAC, registos de acesso de emergência e atas de revisões periódicas de acessos. Para programas de menor dimensão, o requisito de referência está explícito na Política de Controlos Criptográficos para PME: Todos os acessos a chaves criptográficas devem ser registados em logs e retidos para revisão de auditoria, com revisão regular dos acessos.
4. Preparar o pacote da exceção. Monte uma única pasta de evidência ou PDF que inclua o CER, o registo de risco, a fotografia da configuração do gateway, tickets de alteração de firewall, logs do KMS, amostras de regras e eventos SIEM, registos de testes e comunicações à equipa de operações.

Agilidade criptográfica: demonstrar que as exceções são temporárias por conceção

A ISO/IEC 27002:2022 incentiva a agilidade criptográfica, ou seja, a capacidade de atualizar algoritmos e conjuntos de cifras sem reconstruir sistemas inteiros. Os auditores procuram evidência de agilidade, não promessas:

• Cadência de revisão da política que atualiza algoritmos e práticas aceitáveis, com registos de alterações sujeitos a controlo de versões.
• Registos de testes de atualização criptográfica que demonstrem caminhos de implementação segura.
• Comunicações que notifiquem o pessoal sobre alterações criptográficas e impactos operacionais.
• Itens da lista de pendências com progresso de entrega associado às datas de expiração das exceções.

A governação de exceções encontra a análise forense

As exceções podem complicar investigações, sobretudo quando a cifragem ou dispositivos não suportados bloqueiam a recolha de evidência. A Política de Recolha de Evidência e Análise Forense da Clarysec trata esta situação com considerações explícitas para a evidência exigida a partir de dispositivos não suportados ou cifrados. A versão para PME, a Política de Recolha de Evidência e Análise Forense para PME, antecipa modos de falha práticos, por exemplo quando a evidência não pode ser recolhida conforme a política devido a falha do sistema ou suportes corrompidos.

Planeie este cenário nos seus CERs. Inclua o potencial impacto forense, deposite em custódia as chaves necessárias e defina requisitos de acesso de emergência e de registo em logs.

Mapeamento de conformidade transversal: uma exceção, várias perspetivas

Em ambientes regulados ou com múltiplos referenciais, a mesma exceção será examinada através de perspetivas diferentes. Use o guia Zenith Controls para manter coerente o seu pacote de evidência.

Como diferentes auditores irão questionar e como responder

Mesmo numa única auditoria, os estilos variam. Prepare-se para cada estilo e conduza a narrativa:

• O auditor ISO/IEC 27001:2022 perguntará onde está a política de criptografia, onde está definido o processo de exceções, com que frequência as exceções são revistas e quererá realizar amostragem. Comece pelos CERs e por um registo controlado.
• O auditor orientado por NIST procurará configurações de referência de conjuntos de cifras, proteções contra downgrade, procedimentos de geração e destruição de chaves, e logs com alertas. Traga logs do KMS, regras SIEM e testes de validação.
• O auditor COBIT ou ISACA concentrar-se-á em quem é proprietário do risco, quem o aceitou, qual é a cadência de revisão e que métricas demonstram a redução gradual das exceções. Traga atas do comité de direção e relatórios de antiguidade das exceções.
• O revisor com foco regulatório perguntará como a exceção afeta a disponibilidade e a integridade de serviços críticos, e se aumentou o risco de exposição de dados pessoais. Disponibilize artefactos de planeamento de resiliência e um calendário de remediação firme.

Armadilhas comuns que geram não conformidades

• Exceções sem datas de expiração, interpretadas como risco não gerido.
• Ausência de aceitação do risco pela gestão, quando um engenheiro aprovou num ticket sem propriedade responsável.
• Controlos compensatórios descritos, mas sem evidência, por exemplo declarações de monitorização sem regras SIEM.
• Logs de gestão de chaves em falta ou inacessíveis.
• A política diz uma coisa e a prática faz outra, por exemplo CERs são obrigatórios mas não são usados.

Lista de verificação para o dia da auditoria sobre exceções criptográficas

• Um registo atual lista todas as exceções criptográficas com IDs de CER, proprietários, aprovações, datas de revisão e expirações.
• Cada exceção está associada a um registo de risco e a uma decisão de tratamento documentada.
• Existem pelo menos dois controlos compensatórios por exceção, com evidência robusta.
• O acesso a chaves é registado em logs, os logs são retidos e são realizadas revisões de acessos.
• O histórico de revisão da política criptográfica está disponível, com alterações sujeitas a controlo de versões.
• É possível amostrar três ou mais exceções e apresentar uma narrativa consistente.
• Um roteiro demonstra a redução das exceções ao longo do tempo.

Restrições de fornecedores e parceiros

Muitas exceções têm origem fora do seu controlo direto. Parceiros impõem conjuntos de cifras, fornecedores atrasam roteiros ou sistemas adquiridos trazem dívida técnica. Trate restrições externas como parte da sua governação, não como desculpas. Exija declarações de fornecedores sobre roteiros criptográficos, inclua cláusulas contratuais que definam configurações de referência criptográficas e coloque dependências externas no seu registo de riscos.

Próximos passos: construir o seu programa de exceções num sprint

1. Inventariar todas as exceções criptográficas, incluindo as ocultas em serviços de perímetro.
2. Criar ou adaptar CERs para cada exceção, com aprovações, expiração e planos de saída.
3. Associar cada CER a uma entrada do registo de riscos com um proprietário responsável.
4. Montar um modelo normalizado de pacote de evidência de exceção e ensaiar a amostragem de auditoria.
5. Validar a preparação de conformidade transversal com o guia Zenith Controls.

Transforme a ansiedade sobre exceções criptográficas em confiança na auditoria. Marque uma sessão de trabalho com a Clarysec. Num único trabalho, implementamos um fluxo de trabalho de CER, um registo de exceções e uma estrutura de pacote de evidência preparada para auditoria. O resultado são auditorias mais rápidas, menos constatações recorrentes e exceções criptográficas que demonstram governação em vez de improvisação.