Evidência versus atestação

Um fornecedor de plataforma em nuvem recebeu um questionário de TPRM perguntando sobre a criptografia em repouso dos dados dos clientes. Seu CISO preencheu o questionário com confiança: todos os dados dos clientes são criptografados em repouso com AES-256. Esse era o padrão da organização e vinha sendo aplicado de forma consistente em toda a infraestrutura. O que o CISO não sabia era que, seis meses antes, um banco de dados havia sido provisionado por um novo engenheiro de infraestrutura para uma carga de trabalho de analytics específica de um cliente. O engenheiro havia selecionado as configurações padrão no console da nuvem, que habilitavam a criptografia, mas usavam a gestão de chaves padrão do provedor de nuvem em vez da configuração de chaves gerenciadas pelo cliente (CMK) que o padrão da organização exigia. A diferença não era AES-256 versus outra cifra: o padrão da nuvem também era AES-256. A diferença estava na gestão de chaves: a configuração com CMK dava à organização controle sobre a rotação e o acesso às chaves; a configuração padrão deixava a gestão de chaves com o provedor de nuvem. A declaração (“todos os dados são criptografados em repouso com AES-256”) era precisa. A implicação, de que toda a criptografia estava implementada conforme o padrão da organização com chaves gerenciadas pelo cliente, não era precisa para um banco de dados. A declaração do CISO refletia sua crença genuína. Não refletia a configuração real de todos os sistemas relevantes.

O que é, de fato, o problema das evidências versus declarações?

Uma declaração é uma afirmação feita por uma pessoa autorizada de que uma condição é verdadeira, normalmente com base em seu conhecimento, crença ou entendimento das políticas, padrões e práticas da organização. Evidências são a documentação, os registros de configuração, as saídas de sistemas e os artefatos que demonstram, independentemente da crença de quem declara, que uma condição é verdadeira. A diferença entre as duas é a diferença entre o que alguém acredita ser verdade sobre sua organização e o que é comprovadamente verdadeiro sobre sistemas, configurações e práticas específicos.

As declarações são precisas quando quem declara tem conhecimento completo e atualizado de todos os sistemas e configurações relevantes. Em organizações simples e pequenas, as declarações podem ser muito precisas. Em organizações complexas e distribuídas, com várias equipes de infraestrutura, implantações frequentes e gestão descentralizada de configurações, as declarações são precisas dentro do domínio de conhecimento de quem declara, mas podem não refletir a realidade da configuração de sistemas fora desse domínio ou provisionados recentemente por outras equipes. A declaração do CISO de que todos os dados são criptografados conforme o padrão reflete seu conhecimento do padrão da organização e sua crença de que todos os sistemas o cumprem, e não os registros reais de configuração de cada sistema.

O problema do desvio de configuração é a fonte mais comum de lacunas entre declaração e realidade. Os padrões são estabelecidos e comunicados. O provisionamento de cada sistema segue, ou deixa de seguir, esses padrões no momento do provisionamento. À medida que as equipes crescem, a velocidade de provisionamento aumenta e os ambientes de nuvem se expandem, cresce a lacuna entre o padrão declarado e as configurações individuais efetivamente implantadas. Uma declaração feita quando a organização tinha vinte bancos de dados e três engenheiros de infraestrutura descrevia com precisão a configuração conhecida. A mesma declaração feita dois anos depois, com sessenta bancos de dados e quinze engenheiros (alguns contratados depois que o padrão foi estabelecido e que talvez não tenham recebido treinamento adequado sobre seus detalhes), pode descrever com precisão o padrão, mas não o panorama completo das configurações.

• Declaração que reflete o padrão pretendido, e não a configuração real: o CISO confirma o padrão de criptografia da organização, e não a configuração de criptografia real de cada sistema
• Desvio de configuração entre o padrão e a implementação de cada sistema: provisionamentos recentes que não seguem o padrão por causa de configurações padrão, lacunas de treinamento ou descuido
• Lacuna de conhecimento de quem declara: a declaração de membros seniores da equipe não reflete configurações gerenciadas por outras equipes
• Nenhuma verificação independente da configuração: aceitar declarações sem validação técnica das configurações reais dos sistemas
• Ambiguidade no escopo da declaração: se a declaração cobre todos os sistemas relevantes ou apenas os sistemas conhecidos por quem declara

Por que isso importa

Evidências versus declarações são importantes para TPRM porque o risco de segurança criado por uma relação com fornecedor é determinado pela configuração real dos sistemas que tratam dados de clientes, e não pelo padrão da organização ou pela crença do CISO sobre o cumprimento desse padrão. Um fornecedor cujo padrão exige AES-256 com CMK, mas que tem um banco de dados usando a gestão de chaves padrão do provedor, apresenta um risco diferente do de um fornecedor com o mesmo padrão e conformidade total. A declaração confirma o padrão. As evidências revelam a taxa de conformidade.

A dimensão regulatória é explícita. O princípio da responsabilização do GDPR exige que a proteção de dados seja demonstrável, e não declarada. Uma organização que consegue declarar seu padrão de criptografia, mas não consegue demonstrar que cada sistema relevante implementa esse padrão, cumpriu o requisito de declaração, e não o requisito de evidência. Reguladores que examinam evidências em vez de aceitar declarações encontrarão o banco de dados configurado com a gestão de chaves padrão, e a declaração que era precisa para dois terços dos sistemas não satisfará o exame para o terço que era diferente.

Onde a maioria das equipes erra

A falha mais recorrente é aceitar declarações de membros seniores das equipes de segurança ou conformidade como evidência da configuração dos sistemas, em vez de tratá-las como afirmações sobre os padrões e as crenças da organização. As declarações do CISO são valiosas como confirmações de políticas e padrões. Não são evidências técnicas da configuração dos sistemas. As duas exigem tipos diferentes de documentação para serem verificadas.

• Aceitar a declaração de membros seniores da equipe como evidência de configuração
• Nenhuma solicitação de evidências técnicas: registros de configuração não solicitados para sistemas específicos
• Escopo da declaração não esclarecido: se ela cobre todos os sistemas relevantes ou apenas o conhecimento de quem declara
• Desvio de configuração não avaliado: se os sistemas provisionados recentemente cumprem o padrão declarado
• Lacuna na verificação de evidências: aceitar declarações sem verificação independente

Como é uma boa prática

Programas maduros de evidências solicitam evidências técnicas de configuração para os sistemas específicos relevantes para a relação com o cliente: não declarações de membros seniores da equipe, mas registros de configuração, saídas de ferramentas e verificação no nível de cada sistema que trata dados de clientes.

• Evidências de configuração específicas de cada sistema: configuração de criptografia de cada banco de dados ou sistema de armazenamento que contém dados de clientes
• Saída de ferramentas técnicas: resultados de varreduras do CSPM, registros de gestão de configuração ou saída do monitoramento de conformidade, em vez de declarações da equipe
• Verificação da cobertura: confirmação de quais sistemas específicos foram avaliados na declaração
• Revisão de provisionamentos recentes: se os sistemas provisionados nos últimos seis a doze meses foram verificados em relação ao padrão declarado
• Documentação de exceções: quaisquer sistemas que sejam exceções ao padrão declarado e o motivo

Ferramentas

Evidências de configuração: AWS Config, Azure Policy, GCP Security Command Center

As ferramentas de gestão de configuração em nuvem produzem evidências técnicas da configuração dos recursos (configurações de criptografia, configurações de gestão de chaves e conformidade com políticas de segurança) que servem como evidências de configuração independentes das declarações da equipe. Para profissionais de TPRM, perguntar se os fornecedores podem apresentar relatórios de conformidade da configuração em nuvem gerados pelo seu CSPM ou por ferramentas de gestão de configuração em nuvem é uma solicitação de evidências técnicas, e não de declarações.

Conformidade automatizada: Drata, Vanta

As plataformas de conformidade automatizada coletam evidências de configuração continuamente e podem produzir relatórios de conformidade no nível de cada sistema, mostrando quais sistemas específicos cumprem os controles definidos e quais não cumprem, revelando diretamente o desvio de configuração que torna as declarações imprecisas. Para profissionais de TPRM, solicitar um relatório de conformidade automatizado em vez de uma resposta a questionário fornece as evidências técnicas que a declaração não consegue fornecer.

Desafios de governança

O desafio de governança das evidências versus declarações é a disparidade de esforço. Declarações são fáceis de produzir: um membro sênior da equipe confirma sua crença. Evidências técnicas de configuração exigem consultar sistemas, gerar relatórios e revisar registros reais de configuração. A diferença de esforço cria pressão para aceitar declarações por serem mais eficientes. A diferença de risco faz da aceitação de declarações sem evidências técnicas uma lacuna de governança.

• Solicite evidências técnicas de configuração em vez de aceitar declarações da equipe
• Especifique os sistemas nas solicitações de evidências: quais bancos de dados, contas de armazenamento e sistemas contêm dados de clientes
• Solicite a verificação de provisionamentos recentes: os sistemas provisionados no último ano foram verificados em relação ao padrão declarado?
• Pergunte sobre exceções: quaisquer sistemas que não cumpram o padrão declarado
• Solicite a saída do CSPM ou de ferramentas de conformidade em vez de documentação manual de configuração

Se você faz parte de uma equipe pequena

Para cada declaração nas avaliações dos seus fornecedores de maior risco, acrescente uma pergunta de acompanhamento que converta a declaração em uma solicitação de evidências: “Quanto à afirmação de que todos os dados dos clientes são criptografados em repouso com AES-256, vocês podem fornecer os registros de configuração ou a saída do CSPM que confirmem que cada sistema específico que contém nossos dados implementa essa configuração e, especificamente, se algum sistema provisionado nos últimos doze meses foi verificado?” Essa pergunta de acompanhamento converte a declaração de uma afirmação sobre o padrão em uma afirmação sobre a implementação.

• Acompanhe todas as declarações de alto risco com solicitações de evidências de configuração específicas de cada sistema
• Pergunte especificamente sobre sistemas provisionados recentemente, onde o desvio de configuração é mais comum
• Solicite a saída do CSPM ou de ferramentas de conformidade em vez de declarações manuais
• Pergunte sobre exceções: sistemas que não cumprem o padrão declarado

O que exigir

Pergunte diretamente:

“Quanto à afirmação de que todos os dados dos clientes são criptografados em repouso com AES-256 usando chaves gerenciadas pelo cliente, vocês podem fornecer registros de configuração ou a saída do CSPM para cada banco de dados ou sistema de armazenamento específico que contém nossos dados, confirmando a configuração de criptografia de cada um?”

“Algum sistema de armazenamento ou banco de dados que contém nossos dados foi provisionado nos últimos doze meses? E esses sistemas foram verificados especificamente em relação ao seu padrão de criptografia, em vez de depender das configurações padrão da nuvem?”

O que esperar como evidência

• Registros de configuração de criptografia no nível do sistema ou saída do CSPM
• Lista de todos os sistemas que contêm dados de clientes, com sua configuração de criptografia
• Confirmação da verificação de provisionamentos recentes
• Documentação de exceções: quaisquer sistemas que não correspondam ao padrão declarado

Um fornecedor cujo CISO declara criptografia AES-256 para todos os dados dos clientes deve ser solicitado a fornecer o registro de configuração de cada banco de dados específico que contém os dados do cliente. A declaração reflete o padrão. Os registros de configuração refletem a realidade. Quando divergem em um sistema, as evidências revelam o que a declaração não consegue revelar.

Como comprovar

• Registros de evidências técnicas de configuração para os principais controles do fornecedor
• Evidências específicas de cada sistema em vez de declarações de membros seniores da equipe
• Registros da verificação de provisionamentos recentes
• Registros de saída do CSPM para controles técnicos

Principal conclusão

A declaração descreve aquilo em que quem declara acredita. As evidências descrevem o que é. A crença do CISO de que todos os sistemas são criptografados conforme o padrão é um reflexo do padrão e do conhecimento do CISO. A configuração real de um banco de dados provisionado seis meses atrás por outro engenheiro usando as configurações padrão é um fato sobre aquele sistema específico. Crença e fato divergem quando a complexidade, a velocidade e a responsabilidade distribuída fazem com que nem todo provisionamento seja verificado em relação ao padrão por alguém que saiba o que o padrão exige. Solicite evidências para sistemas específicos. Aceite a declaração como uma afirmação sobre o padrão, e não como prova de conformidade universal. O único sistema que é diferente dos outros dois é o sistema que revela a lacuna entre o padrão declarado e a configuração real.