O programa de segurança de uma empresa de serviços financeiros havia evoluído ao longo de doze anos por meio de uma combinação de crescimento orgânico, aquisições e acréscimos motivados por exigências regulatórias. Um exercício de racionalização de controles constatou que a organização mantinha três programas separados de varredura de vulnerabilidades: um operado pela equipe de infraestrutura com o Qualys, outro operado pela equipe de segurança em nuvem com o AWS Inspector e outro operado pela equipe de segurança de aplicações com o Tenable.io. Os três faziam a varredura de populações de sistemas sobrepostas. Nenhuma das três equipes sabia que as outras duas tinham programas com escopo semelhante. A organização pagava três conjuntos de licenças, despendia três conjuntos de esforço operacional e gerava três conjuntos de relatórios de constatações, acompanhados em três fluxos de correção separados. As mesmas vulnerabilidades apareciam nos três programas com convenções de nomenclatura, classificações de severidade e responsáveis pela correção diferentes, gerando sobrecarga de coordenação e confusão em vez da cobertura abrangente que cada equipe acreditava que seu programa oferecia.
O que é, de fato, a duplicação de controles?
A duplicação de controles é a manutenção de várias instâncias da mesma função de controle de segurança em uma organização: ferramentas, processos ou programas separados que desempenham funções de segurança equivalentes com escopos sobrepostos ou idênticos. Ela surge da evolução natural dos programas de segurança por meio de uma combinação de crescimento orgânico entre unidades de negócio, aquisições que trazem suas próprias ferramentas de segurança, requisitos regulatórios interpretados de forma independente por diferentes equipes de conformidade e o acréscimo incremental de capacidades de segurança sem uma visão abrangente da cobertura existente.
O problema da falsa garantia é a principal consequência de segurança da duplicação de controles. As equipes que operam controles duplicados muitas vezes acreditam que seu controle oferece uma cobertura mais abrangente do que de fato oferece, porque não sabem da duplicação. A equipe de infraestrutura acredita que seu programa com o Qualys cobre todos os sistemas de produção de forma abrangente. A equipe de segurança em nuvem acredita que seu programa com o AWS Inspector oferece a cobertura de vulnerabilidades da nuvem. A equipe de segurança de aplicações acredita que seu programa com o Tenable.io oferece a varredura completa das aplicações. Cada crença é parcialmente correta, e a cada uma falta o contexto de que os programas das outras duas equipes existem, se sobrepõem e produzem resultados inconsistentes.
O problema da inconsistência agrava a questão da falsa garantia. Controles duplicados que cobrem os mesmos sistemas com ferramentas, configurações e calibrações de severidade diferentes produzem constatações diferentes para as mesmas vulnerabilidades. A mesma vulnerabilidade crítica pode aparecer como crítica em um programa, alta em um segundo e média em um terceiro, devido a diferentes configurações de CVSS e políticas de substituição de severidade. Responsáveis diferentes pela correção da mesma vulnerabilidade geram confusão sobre a responsabilização. Fluxos de acompanhamento diferentes criam a possibilidade de que uma vulnerabilidade seja corrigida em um fluxo e permaneça aberta em outro, sem uma visão unificada do real status da correção.
O problema da alocação de recursos é a consequência operacional. Três programas de varredura de vulnerabilidades exigem três conjuntos de licenças, três conjuntos de tempo da equipe operacional para configuração, triagem e relatórios e três conjuntos de gestão de fluxos de correção. Os recursos investidos na manutenção de três programas sobrepostos poderiam ser investidos na melhoria da profundidade e da cobertura de um único programa abrangente, na extensão da varredura a sistemas que hoje estão fora do escopo de qualquer programa ou nas capacidades de segurança que a organização ainda não tem.
A dimensão da avaliação de fornecedores é diretamente relevante. Um fornecedor que mantém controles duplicados, parecendo abrangente porque várias ferramentas cobrem funções semelhantes, pode estar investindo mais na aparência de uma cobertura abrangente do que em uma cobertura de fato abrangente. Três programas de varredura de vulnerabilidades com escopos sobrepostos oferecem menos valor de segurança por dólar gasto do que um único programa abrangente com escopo completo e acompanhamento consistente das correções.
- Programas de varredura de vulnerabilidades sobrepostos: várias ferramentas cobrindo as mesmas populações de sistemas de forma independente
- Processos duplicados de revisão de acessos: equipes separadas realizando revisões de acesso para as mesmas populações de usuários
- Monitoramento de segurança redundante: várias ferramentas de SIEM ou de gestão de logs coletando os mesmos dados de eventos
- Programas de conformidade paralelos: o mesmo framework avaliado de forma independente por equipes diferentes
- Constatações inconsistentes de controles duplicados: a mesma vulnerabilidade classificada de forma diferente em cada programa
Por que isso importa
A duplicação de controles é importante para TPRM porque os fornecedores que mantêm controles duplicados podem ter uma postura de conformidade que parece abrangente (várias ferramentas, vários programas, defesa em profundidade), enquanto a cobertura real é menos completa do que parece e a sobrecarga operacional é significativamente maior do que um programa racionalizado exigiria. Os recursos investidos na manutenção de controles duplicados são recursos que deixam de ser investidos na extensão da cobertura a sistemas fora do escopo de qualquer programa ou no aprofundamento de capacidades em áreas onde a cobertura é de fato insuficiente.
A dimensão da precisão dos questionários também é relevante. Um fornecedor cuja resposta ao questionário confirma a varredura de vulnerabilidades, a varredura de segurança em nuvem e a varredura de segurança de aplicações está confirmando que existem vários programas de varredura. Se esses programas oferecem uma cobertura abrangente e sem sobreposições de todos os sistemas de produção, ou se são três programas sobrepostos do mesmo subconjunto, não é revelado pela confirmação da existência dos programas.
Onde a maioria das equipes erra
A falha mais recorrente é interpretar a duplicação de controles como defesa em profundidade. A defesa em profundidade aplica controles diferentes em camadas diferentes para tratar vetores de ataque diferentes. A duplicação de controles aplica a mesma função de controle várias vezes ao mesmo escopo, sem oferecer nem a cobertura em camadas de uma verdadeira defesa em profundidade, nem o escopo abrangente de um único controle bem projetado.
- Interpretar a duplicação de controles como defesa em profundidade
- Nenhum inventário de controles para identificar funções sobrepostas
- Controles duplicados não visíveis para a governança central
- Alocação de recursos não avaliada em relação ao valor de cobertura dos controles
- Constatações inconsistentes não identificadas como indicador de duplicação
Como é uma boa prática
Programas de controles maduros mantêm um inventário de controles que identifica a função de cada controle, o escopo que ele cobre e as ferramentas ou processos que o implementam, permitindo identificar a duplicação e racionalizar em direção a uma cobertura abrangente e sem sobreposições.
- Inventário de controles: todos os controles documentados com função, escopo e ferramentas de implementação
- Identificação de sobreposições: controles que cobrem funções equivalentes com escopos sobrepostos identificados
- Racionalização: controles duplicados consolidados em programas unificados e abrangentes
- Identificação de lacunas de cobertura: sistemas e vetores de ataque não cobertos por nenhum controle após a racionalização
- Realocação de recursos: recursos das duplicações racionalizadas direcionados às lacunas de cobertura
Ferramentas
Mapeamento de controles: bibliotecas de controles do NIST CSF e do ISO 27001
As bibliotecas de frameworks de controles fornecem a taxonomia para identificar quando várias ferramentas ou processos desempenham funções de controle equivalentes. Mapear todas as ferramentas e processos de segurança para as categorias de controle do NIST CSF ou do ISO 27001 revela onde várias implementações cobrem a mesma categoria de controle e onde existem lacunas de cobertura. Para profissionais de TPRM, perguntar se os fornecedores realizaram um exercício de racionalização de controles é uma pergunta específica sobre a consciência da duplicação.
Revisão da arquitetura de segurança: arquitetura de segurança TOGAF, metodologias de racionalização de controles
As metodologias de arquitetura de segurança oferecem abordagens estruturadas para o inventário e a racionalização dos controles, identificando as funções lógicas de controle necessárias, as ferramentas que implementam cada função e a cobertura de escopo de cada implementação. Para profissionais de TPRM, perguntar se a arquitetura de controles do fornecedor foi revisada quanto à duplicação e à racionalização é uma pergunta específica sobre a maturidade dos controles.
Desafios de governança
O desafio de governança da duplicação de controles é a gestão da mudança organizacional necessária para racionalizar programas duplicados. Cada programa tem um responsável que investiu em construí-lo, uma equipe que o opera e partes interessadas que passaram a depender dos seus resultados. Racionalizar três programas em um exige uma gestão da mudança que afeta várias equipes ao mesmo tempo e gera resistência mesmo quando os benefícios da racionalização são claros.
- Realize um inventário de controles: mapeie todas as ferramentas e processos de segurança para as funções de controle
- Identifique escopos sobrepostos: controles que cobrem os mesmos sistemas e vetores de ataque
- Quantifique o custo da duplicação: sobrecarga de licenciamento, operacional e de coordenação das correções
- Avalie o inventário de controles do fornecedor: pergunte se foi realizada uma racionalização dos controles
- Pergunte sobre o acompanhamento unificado das correções: se os programas duplicados produzem constatações consistentes
Se você faz parte de uma equipe pequena
Faça aos seus fornecedores de maior risco uma pergunta que revela a duplicação de imediato: especificamente para a varredura de vulnerabilidades, quantos programas ou ferramentas de varredura separados vocês operam, e eles cobrem populações de sistemas sobrepostas? Se a resposta for mais de uma ferramenta com escopos sobrepostos e acompanhamento separado das correções, pergunte como as constatações dos diferentes programas são reconciliadas e quem é responsável pela correção quando a mesma vulnerabilidade aparece nas constatações de vários programas. A inconsistência da resposta revelará se a duplicação é gerenciada ou desconhecida.
- Pergunte quantos programas separados de varredura de vulnerabilidades operam com escopos sobrepostos
- Pergunte como as constatações dos diferentes programas são reconciliadas
- Pergunte quem é responsável pela correção quando a mesma constatação aparece em vários programas
- Inclua o status da racionalização de controles na avaliação da maturidade de segurança dos fornecedores
O que exigir
Quantos programas separados de varredura de vulnerabilidades vocês operam, e, nos programas que cobrem populações de sistemas sobrepostas, como as constatações são reconciliadas e como a correção é acompanhada quando a mesma vulnerabilidade aparece em vários programas?
Um fornecedor que confirma vários programas de varredura deve ser questionado se esses programas cobrem escopos sobrepostos e como as constatações sobrepostas são gerenciadas. Vários programas que cobrem o mesmo escopo são duplicação. Vários programas que cobrem, cada um, um escopo exclusivo são cobertura abrangente. A pergunta distingue os dois casos.
- Inventário de controles com a documentação do escopo de cada programa
- Processo de identificação de sobreposições e reconciliação de constatações duplicadas entre programas
- Acompanhamento unificado das correções entre programas com escopos sobrepostos
- Histórico de racionalização dos controles
Como comprovar
- Documentação do inventário de controles
- Registros de identificação da duplicação e de racionalização
- Implementação do acompanhamento unificado das correções
- Análise de lacunas de cobertura após a racionalização
Principal conclusão
Três programas de varredura de vulnerabilidades que cobrem populações de sistemas sobrepostas representam três vezes o custo e a sobrecarga de coordenação de um único programa abrangente, e não três vezes a cobertura. A duplicação de controles produz a aparência de uma cobertura abrangente enquanto investe na manutenção da redundância os recursos que produziriam uma cobertura de fato abrangente. Um inventário de controles identifica a duplicação. A racionalização direciona esses recursos para as lacunas de cobertura que a duplicação ocultava. A defesa em profundidade aplica controles diferentes em camadas diferentes. A duplicação de controles aplica o mesmo controle várias vezes na mesma camada. Não são a mesma coisa.