A equipe de segurança de um fornecedor de pesquisa clínica se orgulhava de seus controles de proteção de dados: dados de ensaios clínicos de pacientes criptografados em repouso e em trânsito, controles de acesso rigorosamente gerenciados, registro de auditoria abrangente. Um pesquisador de segurança que conduzia um teste de intrusão autorizado encontrou uma vulnerabilidade significativa de divulgação de informações que nada tinha a ver com os dados protegidos em si: as respostas da API do fornecedor continham cabeçalhos HTTP detalhados que revelavam a versão do mecanismo de banco de dados, o framework de ORM em uso, o sistema operacional do servidor e a arquitetura interna de serviços. Seu armazenamento de arquivos acessível publicamente continha documentos de protocolo de ensaios clínicos cujos metadados (nomes dos autores, organização, classificação interna do documento e histórico de versões) revelavam a identidade do patrocinador do ensaio e detalhes do protocolo que não haviam sido divulgados publicamente. As mensagens de erro retornadas pela aplicação incluíam nomes completos de tabelas do banco de dados, estruturas de colunas e, em alguns casos, parâmetros de consulta. Os dados dos ensaios clínicos estavam bem protegidos. Os metadados ao redor deles revelavam o patrocinador do ensaio, a estrutura do protocolo, a infraestrutura técnica e detalhes suficientes da superfície de ataque para reduzir drasticamente o esforço necessário para explorar qualquer vulnerabilidade existente no ambiente.
Qual é, de fato, o problema do risco de exposição de metadados?
Metadados são dados sobre dados: as informações contextuais, estruturais e técnicas que descrevem, situam e sustentam os dados principais sem serem os próprios dados principais. Em contextos de segurança da informação, os metadados abrangem os cabeçalhos de resposta HTTP que descrevem características do servidor e das aplicações, as propriedades de documentos que registram a autoria e a origem organizacional, os metadados do sistema de arquivos que registram o histórico de acesso e o contexto de criação, as estruturas de resposta da API que revelam esquemas de bancos de dados e arquiteturas de serviços, as mensagens de erro que expõem a estrutura das consultas e os componentes internos do sistema e toda a gama de informações contextuais que aplicações e sistemas geram junto com seus dados principais.
A importância dos metadados para a segurança decorre de sua densidade de informação em relação à sua prioridade de governança. Os metadados frequentemente contêm informações operacionalmente mais valiosas para um atacante do que os próprios dados principais, não porque os dados principais sejam pouco importantes, mas porque os metadados costumam fornecer a inteligência de reconhecimento que torna viável o ataque aos dados principais. A versão de um mecanismo de banco de dados divulgada em um cabeçalho HTTP indica ao atacante quais CVEs pesquisar. A versão de um framework em uma mensagem de erro indica ao atacante quais vulnerabilidades de injeção e de desserialização testar. Uma classificação interna de documento em uma propriedade de arquivo revela o que a organização considera sensível e quais documentos priorizar em um cenário de exfiltração. Nenhuma dessas informações são os dados principais que os programas de segurança foram concebidos para proteger, mas elas permitem um acesso mais eficiente a esses dados.
A dimensão de privacidade dos metadados é igualmente significativa e cada vez mais reconhecida nas orientações regulatórias. O momento e a frequência das visitas de um paciente a um portal de saúde revelam padrões comportamentais que podem indicar condições de saúde sem expor registros clínicos específicos. Os metadados de comunicações criptografadas (quem se comunicou com quem, quando, com que frequência e por quanto tempo) podem revelar padrões de relacionamento, estruturas organizacionais e informações comportamentais que a criptografia do conteúdo pretendia proteger. Registros de data e hora de acesso a arquivos, dados de localização incorporados em fotografias e identificadores de dispositivos em logs de aplicações são categorias de metadados com implicações de privacidade independentes dos dados que descrevem.
Os riscos de exposição de metadados se concentram em cinco categorias específicas de exposição nos ambientes de fornecedores:
- Divulgação nos cabeçalhos de resposta HTTP: metadados do servidor e das aplicações retornados nos cabeçalhos de resposta HTTP que revelam o mecanismo de banco de dados, o framework, o sistema operacional e a arquitetura interna de serviços a qualquer parte que inspecione as respostas
- Metadados de documentos e arquivos: identidade do autor, organização, classificação interna e histórico de versões incorporados nas propriedades do documento, distribuídos junto com o conteúdo do documento
- Mensagens de erro detalhadas: respostas de erro da aplicação que incluem a estrutura das consultas ao banco de dados, nomes de tabelas, rastreamentos de pilha e detalhes internos do sistema visíveis aos usuários que provocam condições de erro
- Divulgação pela estrutura das respostas da API: respostas da API que revelam o esquema do banco de dados, a estrutura de relacionamentos e modelos internos de objetos por meio de padrões consistentes de nomenclatura de campos e de respostas
- Exposição de metadados em logs: logs de aplicações que contêm informações contextuais sensíveis (identificadores de usuários, tokens de sessão, parâmetros de consulta e detalhes internos de roteamento) expostas por configurações incorretas da infraestrutura de logs
Por que isso importa
A exposição de metadados importa para a TPRM porque representa uma categoria de divulgação de informações em grande parte invisível para avaliações concentradas na proteção dos dados principais. Uma avaliação que confirma a criptografia de dados, os controles de acesso e o registro de auditoria cobre os controles de proteção dos dados principais. Normalmente, ela não avalia se os cabeçalhos HTTP revelam a infraestrutura técnica, se as propriedades dos documentos revelam a classificação interna ou se as mensagens de erro expõem a estrutura do banco de dados. Os metadados que um atacante usa para planejar um ataque contra o ambiente do fornecedor são os metadados que a avaliação de segurança do fornecedor pode nunca ter examinado.
A dimensão do reconhecimento técnico é o risco mais diretamente relevante para o atacante. Um atacante que identifica a pilha tecnológica de um fornecedor-alvo por meio da inspeção de cabeçalhos HTTP, da análise de mensagens de erro e do exame da estrutura das respostas da API reduz significativamente seu esforço de desenvolvimento do ataque. Em vez de testar às cegas contra um ambiente desconhecido, ele pode pesquisar CVEs conhecidas para as versões específicas divulgadas, desenvolver abordagens de exploração calibradas às versões específicas de framework identificadas e priorizar as vulnerabilidades com maior probabilidade de serem exploráveis dada a arquitetura divulgada. Os controles dos dados principais continuam em vigor. O ataque ficou mais eficiente por meio dos metadados.
Para profissionais de TPRM, a avaliação da exposição de metadados acrescenta uma dimensão que poucas avaliações padrão cobrem: perguntar não apenas se os dados estão protegidos, mas se as informações que cercam os dados no ambiente do fornecedor são controladas adequadamente. Isso é particularmente relevante para fornecedores que expõem APIs externas, distribuem documentos a clientes e operam interfaces web em que os cabeçalhos HTTP e as mensagens de erro são visíveis a qualquer pessoa com um navegador e ferramentas de desenvolvedor.
Onde a maioria das equipes erra
A falha mais recorrente é tratar a governança de metadados como consideração secundária em relação à proteção dos dados principais. Organizações que investem significativamente em criptografar os dados, controlar o acesso a eles e monitorar esse acesso podem nunca ter examinado o que seus sistemas revelam sobre si mesmos por meio dos metadados que cercam os dados. Os cabeçalhos HTTP são visíveis para qualquer navegador. As propriedades dos documentos são acessíveis a qualquer usuário que abra um arquivo. As mensagens de erro são visíveis para qualquer usuário que provoque um erro. Essas são as divulgações de informações que os programas padrão de proteção de dados deixam passar.
A segunda falha é não incluir a divulgação de metadados no escopo do teste de intrusão. Um teste de intrusão que avalia controles de acesso, vulnerabilidades de injeção e mecanismos de autenticação pode não examinar especificamente quais informações são divulgadas por meio de cabeçalhos HTTP, mensagens de erro e metadados de documentos. A divulgação de metadados é um risco que viabiliza o reconhecimento, e não um risco de exploração direta, e objetivos de teste voltados ao reconhecimento exigem inclusão explícita no escopo do teste.
- Tratar a governança de metadados como secundária em relação à proteção dos dados principais: os metadados frequentemente contêm inteligência operacionalmente mais útil para o atacante do que os próprios dados protegidos
- Cabeçalhos HTTP não avaliados: divulgação das versões do servidor e do framework fora do escopo da avaliação de segurança
- Metadados de documentos sem governança: identidade do autor e classificação interna nas propriedades dos documentos não removidas antes da distribuição
- Mensagens de erro não avaliadas: respostas de erro detalhadas fora do escopo dos testes de segurança
- Divulgação de metadados fora do escopo do teste de intrusão: a coleta de inteligência de reconhecimento por meio de metadados não é um objetivo de teste definido
Como é uma boa prática
Programas maduros de governança de metadados tratam a divulgação de informações por meio de metadados com a mesma intencionalidade que a divulgação por meio de dados: removem ou suprimem os cabeçalhos HTTP que identificam o servidor, implementam mensagens de erro genéricas que não expõem os componentes internos do sistema, removem os metadados dos documentos antes da distribuição e incluem a avaliação da divulgação de metadados nos programas de testes de segurança.
- Proteção dos cabeçalhos HTTP: identificadores da versão do servidor, da versão do framework e da pilha tecnológica removidos dos cabeçalhos de resposta HTTP
- Tratamento genérico de erros: erros de aplicação retornados aos usuários como mensagens genéricas, sem estrutura do banco de dados, detalhes de consultas ou rastreamentos de pilha
- Remoção de metadados de documentos: autor, organização, classificação interna e histórico de versões removidos dos documentos antes da distribuição externa
- Minimização da estrutura das respostas da API: respostas da API concebidas para divulgar o mínimo necessário de informações, e não modelos de objetos completos
- Divulgação de metadados no escopo do teste de intrusão: inspeção de cabeçalhos HTTP, análise de mensagens de erro e avaliação de metadados de documentos como objetivos de teste definidos
Ferramentas
Governar a exposição de metadados exige tanto os controles técnicos para remover ou suprimir metadados identificadores quanto as ferramentas de teste para avaliar o que está sendo divulgado atualmente.
Cabeçalhos de segurança HTTP: OWASP Secure Headers Project, SecurityHeaders.com
O OWASP Secure Headers Project oferece orientações sobre quais cabeçalhos HTTP devem ser removidos ou protegidos para impedir a identificação do servidor e a divulgação de informações. O SecurityHeaders.com oferece uma avaliação gratuita da configuração dos cabeçalhos HTTP de qualquer site acessível publicamente. Para profissionais de TPRM, executar uma verificação no SecurityHeaders.com contra as aplicações expostas externamente de um fornecedor oferece uma avaliação imediata, sem necessidade de acesso, da divulgação de informações pelos cabeçalhos HTTP, informações visíveis para qualquer cliente HTTP sem nenhuma autenticação.
Gestão de metadados de documentos: Microsoft Purview, ferramentas de metadados do Adobe Acrobat
As ferramentas de remoção de metadados de documentos removem ou ocultam autor, organização, classificação interna e histórico de versões dos documentos antes da distribuição. Os aplicativos do Microsoft Office oferecem recursos nativos de inspeção e remoção de metadados. O recurso de sanitização do Adobe Acrobat remove metadados e conteúdo oculto de PDFs. Para profissionais de TPRM, perguntar se o fornecedor remove os metadados dos documentos distribuídos a clientes ou a terceiros é uma pergunta específica sobre a governança de metadados de documentos.
Testes de segurança de API: 42Crunch, Burp Suite, OWASP ZAP
As ferramentas de testes de segurança de API avaliam a divulgação de informações por meio das respostas da API, verificando se as respostas revelam o esquema do banco de dados, modelos internos de objetos ou detalhes de implementação por meio de padrões consistentes de nomenclatura de campos e de estrutura das respostas. Para profissionais de TPRM, perguntar se os testes de segurança de API incluem a avaliação da divulgação de informações por meio da estrutura das respostas e da análise de cabeçalhos é a pergunta específica sobre objetivos de teste que levam em conta os metadados.
Desafios de governança
O desafio de governança dos metadados é o problema da onipresença. Os metadados são gerados por todo sistema, aplicação e documento de um ambiente como efeito colateral da operação normal: não são criados intencionalmente como risco de divulgação, mas se acumulam continuamente por meio de atividades rotineiras. Suprimi-los exige a configuração deliberada de cada sistema que os gera: servidores HTTP configurados para suprimir cabeçalhos de versão, rotinas de tratamento de erros configuradas para retornar mensagens genéricas, ferramentas de criação de documentos configuradas para remover metadados, frameworks de API configurados para minimizar o nível de detalhe das respostas. Essas configurações precisam ser aplicadas e mantidas em um ambiente diversificado de sistemas e aplicações.
Para programas de TPRM, a abordagem prática de governança é incluir a avaliação da divulgação de metadados nos requisitos de testes de segurança de fornecedores, perguntando especificamente se os cabeçalhos HTTP, as mensagens de erro e os metadados de documentos são avaliados como parte do programa de testes de segurança do fornecedor. A disponibilidade de ferramentas gratuitas como o SecurityHeaders.com também permite que profissionais de TPRM façam uma avaliação rápida, sem necessidade de acesso, da configuração dos cabeçalhos HTTP expostos externamente por um fornecedor, antes ou junto de qualquer avaliação formal.
- Executar o SecurityHeaders.com contra URLs externas do fornecedor: avaliação gratuita, imediata e sem necessidade de acesso da divulgação nos cabeçalhos HTTP
- Perguntar se a divulgação de metadados está no escopo do teste de intrusão: cabeçalhos HTTP, mensagens de erro e metadados de documentos como objetivos de teste definidos
- Perguntar sobre a gestão de metadados de documentos: se os documentos distribuídos aos clientes têm os metadados removidos
- Perguntar sobre o nível de detalhe das mensagens de erro: se os erros da aplicação retornam mensagens genéricas ou detalhes que expõem o sistema
- Incluir a divulgação de metadados na avaliação de segurança de fornecedores como dimensão padrão, ao lado da proteção dos dados principais
Se você faz parte de uma equipe pequena
Execute o SecurityHeaders.com contra a principal URL exposta externamente pelo fornecedor antes da sua próxima reunião de avaliação. A verificação leva trinta segundos e revela a configuração dos cabeçalhos HTTP, especificamente quais cabeçalhos que identificam o servidor e o framework estão presentes na resposta. Essa informação indica imediatamente se o fornecedor tratou a divulgação de metadados nos cabeçalhos HTTP ou se sua API externa e sua aplicação web estão anunciando sua pilha tecnológica a qualquer pessoa que execute a mesma verificação. Em seguida, pergunte se a gestão de metadados de documentos e o nível de detalhe das mensagens de erro estão no escopo do teste de intrusão. Três perguntas, uma verificação gratuita, um sinal imediato e significativo.
- Executar o SecurityHeaders.com contra as principais URLs externas do fornecedor antes da avaliação
- Perguntar se os metadados dos documentos são removidos antes da distribuição externa
- Perguntar se as mensagens de erro retornam respostas genéricas ou detalhes que expõem o sistema
- Perguntar se a divulgação de metadados está incluída no escopo do teste de intrusão
O que exigir
Pergunte diretamente:
"Vocês avaliaram as informações divulgadas pelos cabeçalhos de resposta HTTP das suas aplicações expostas externamente? Especificamente, os cabeçalhos do servidor e das aplicações revelam o mecanismo de banco de dados, a versão do framework ou o sistema operacional do servidor a qualquer cliente HTTP?"
"As mensagens de erro das suas aplicações retornam respostas de erro genéricas aos usuários ou incluem estrutura do banco de dados, detalhes de consultas ou rastreamentos de pilha que expõem os componentes internos do sistema?"
"Vocês removem os metadados (autor, organização, classificação interna e histórico de versões) dos documentos distribuídos aos clientes, e a gestão de metadados de documentos faz parte do seu programa de segurança da informação?"
O que esperar como evidência
- Revisão da configuração dos cabeçalhos HTTP: cabeçalhos que identificam o servidor suprimidos
- Configuração do tratamento de erros: mensagens de erro genéricas, sem detalhes do sistema
- Processo de gestão de metadados de documentos: remoção antes da distribuição externa
- Inclusão da divulgação de metadados no escopo do teste de intrusão
Execute o SecurityHeaders.com contra a principal URL do fornecedor ao mesmo tempo em que faz essas perguntas. O resultado da verificação oferece uma evidência independente da configuração dos cabeçalhos HTTP que nenhuma resposta a questionário pode substituir. Um fornecedor cujos cabeçalhos revelam a versão do servidor e o framework no resultado da verificação respondeu à primeira pergunta com uma evidência mais confiável do que qualquer autodeclaração.
Como comprovar
A exposição de metadados é tratada no Guia de Testes do OWASP para divulgação de informações, no CWE-200 (exposição de informações sensíveis a um agente não autorizado) e nas orientações gerais de configuração segura da NIST SP 800-53. Demonstrar a devida diligência exige evidências de que a divulgação de metadados foi avaliada como uma dimensão de segurança distinta.
- Resultados das verificações do SecurityHeaders.com para as aplicações do fornecedor expostas externamente
- Evidência da configuração dos cabeçalhos HTTP: cabeçalhos que identificam o servidor suprimidos
- Avaliação do tratamento de erros que confirma respostas de erro genéricas
- Evidências da gestão de metadados de documentos
- Confirmação do escopo do teste de intrusão, incluindo a avaliação da divulgação de metadados
Principal conclusão
Os dados estavam protegidos. Os metadados contaram a história que a criptografia pretendia impedir. A versão do servidor, pelo cabeçalho HTTP. O framework, pela mensagem de erro. O esquema do banco de dados, pela estrutura das respostas da API. A classificação interna, pela propriedade do documento. Nada disso eram os dados protegidos. Tudo isso foi o reconhecimento que tornou o ataque aos dados protegidos significativamente mais eficiente. A governança de metadados é a disciplina que fecha a lacuna entre proteger a informação e proteger o contexto da informação. Os controles dos dados principais cobrem os dados. Os controles de metadados cobrem tudo o que os cerca. Avaliar apenas os controles principais deixa o contexto ao redor sem governança, e o contexto é o que os atacantes leem primeiro.