Uma empresa de pesquisa farmacêutica avaliou dois fornecedores para um contrato de gestão de dados de ensaios clínicos, ambos com históricos sem violações nos últimos três anos. A avaliação tratou os históricos sem violações como indicadores positivos equivalentes. As avaliações de segurança então divergiram fortemente. O Fornecedor A tinha um programa de prevenção maduro: segurança de e-mail que bloqueava noventa e quatro por cento das tentativas de phishing, EDR que detectou e colocou em quarentena três amostras de malware antes da execução e um programa de gestão de vulnerabilidades que havia corrigido uma vulnerabilidade crítica em até quarenta e oito horas após sua publicação. Sua equipe de operações de segurança havia documentado três tentativas de ataque significativas evitadas nos dezoito meses anteriores. O fornecedor compartilhou esses registros de quase incidentes como evidência da eficácia do programa de segurança. O Fornecedor B tinha um histórico equivalente sem violações, alcançado por outros meios: uma abordagem mais conservadora, com menor exposição a ameaças, menos sistemas expostos externamente e uma superfície de ataque menor que simplesmente havia atraído menos atenção de atacantes. Quando a empresa farmacêutica investigou os históricos de detecção e prevenção dos dois fornecedores, a diferença ficou evidente: o Fornecedor A havia sido atacado ativamente e havia evitado os ataques com sucesso. O Fornecedor B havia sofrido menos atividade de ataque e tinha menos dados para demonstrar capacidade de prevenção. Os históricos sem violações eram idênticos. Os programas de segurança por trás deles não eram.
O que é, de fato, o problema do equilíbrio entre detecção e prevenção?
O problema do equilíbrio entre detecção e prevenção na avaliação de segurança de fornecedores é o desafio de entender se o histórico sem violações de um fornecedor reflete uma capacidade de prevenção eficaz ou simplesmente baixa exposição a ataques. Ambas produzem o mesmo histórico de violações. Somente a capacidade de prevenção dá garantia de que o programa de segurança do fornecedor terá um desempenho eficaz quando a pressão de ataques aumentar, o que acontecerá se os dados ou o acesso à plataforma do fornecedor fizerem dele um alvo de maior valor ao longo do tempo.
A lacuna de visibilidade dos quase incidentes é o problema estrutural de medição. O sucesso da prevenção é medido por eventos que não aconteceram: e-mails de phishing bloqueados antes de chegar aos usuários, malware colocado em quarentena antes da execução, vulnerabilidades corrigidas antes da exploração. Esses sucessos ficam registrados nos dados operacionais do programa de segurança (taxas de bloqueio da segurança de e-mail, logs de quarentena do EDR, prazos de correção de vulnerabilidades), mas normalmente não são divulgados nas avaliações de violações de fornecedores porque não são violações. O histórico de violações reflete apenas as falhas do programa de prevenção. O histórico de quase incidentes reflete seus sucessos.
O problema da calibração da pressão de ataques é a dimensão da cadeia de suprimentos. Fornecedores que detêm dados valiosos (propriedade intelectual, dados regulados de saúde ou financeiros, dados de pesquisa) atraem maior pressão de ataques do que fornecedores com ativos menos valiosos. Um fornecedor cujo programa de segurança foi testado sob pressão de ataques significativa e evitou violações com sucesso oferece uma qualidade de garantia diferente da de um fornecedor que atraiu atividade de ataque mínima. O histórico sem violações é idêntico. A qualidade da garantia é diferente.
- Histórico sem violações que não distingue prevenção eficaz de baixa exposição a ataques
- Dados de quase incidentes não divulgados ou não solicitados nas avaliações de fornecedores
- Capacidade de prevenção não demonstrada sem histórico de exposição a ataques
- Equivalência presumida entre históricos sem violações de origens diferentes
- Avaliação da pressão de ataques ausente: valor dos dados do fornecedor e sua atratividade para ataques não avaliados
Por que isso importa
O equilíbrio entre detecção e prevenção é importante para TPRM porque os alvos da cadeia de suprimentos são escolhidos especificamente pelo seu acesso a dados de alto valor, e fornecedores que detêm ou tratam dados de alto valor enfrentarão uma pressão de ataques crescente à medida que o valor de seus dados se tornar conhecido pelos agentes de ameaça. Um fornecedor cujo histórico sem violações se baseia em baixa exposição a ataques, e não em prevenção eficaz, pode não manter esse histórico à medida que a pressão de ataques aumentar. Entender a origem do histórico sem violações (capacidade de prevenção ou baixa exposição) orienta a avaliação de risco prospectiva que o TPRM exige.
Onde a maioria das equipes erra
A falha mais recorrente é tratar o histórico de violações como o principal indicador de eficácia da segurança sem avaliar a atividade de prevenção que o sustenta. O programa de prevenção é mais informativo do que seu histórico de falhas.
- Histórico de violações tratado como principal indicador de eficácia
- Histórico de quase incidentes não solicitado nas avaliações de segurança
- Dados operacionais do programa de prevenção não avaliados: taxas de bloqueio, taxas de quarentena, prazos de aplicação de patches
- Pressão de ataques não avaliada: valor dos dados do fornecedor e sua atratividade para agentes de ameaça
- Equivalência de históricos limpos presumida entre programas de segurança de origens diferentes
Como é uma boa prática
Programas maduros de avaliação de detecção e prevenção solicitam dados operacionais de quase incidentes junto com os históricos de violações (especificamente taxas de bloqueio da segurança de e-mail, taxas de prevenção de malware, prazos de correção de vulnerabilidades e quaisquer tentativas de ataque significativas evitadas e documentadas) para avaliar a capacidade de prevenção, e não apenas o histórico de prevenção.
- Histórico de quase incidentes solicitado: ataques significativos evitados nos últimos dois anos
- Métricas do programa de prevenção: taxas de bloqueio de e-mails, taxas de quarentena do EDR, prazos de aplicação de patches
- Avaliação da pressão de ataques: valor dos dados do fornecedor e histórico de ataques direcionados
- Capacidade de prevenção versus histórico de prevenção: distinguir a eficácia do programa do histórico de exposição
- Avaliação prospectiva: o programa manterá seu histórico sob pressão de ataques crescente?
Ferramentas
Segurança de e-mail: Proofpoint, Mimecast com relatórios de taxa de bloqueio
As plataformas de segurança de e-mail fornecem estatísticas de taxa de bloqueio que são um indicador direto da eficácia do programa de prevenção: a fração de e-mails maliciosos detectados e bloqueados antes de chegar aos usuários. Para profissionais de TPRM, pedir aos fornecedores sua taxa de bloqueio da segurança de e-mail e o volume de tentativas de phishing bloqueadas nos últimos doze meses fornece uma métrica específica de eficácia do programa de prevenção.
Desafios de governança
O desafio de governança da divulgação de quase incidentes é a sensibilidade dos fornecedores. Os fornecedores relutam em revelar que foram atacados, mesmo quando os ataques foram evitados com sucesso, porque a divulgação cria a impressão de que são alvos. A solução de governança é apresentar as solicitações de quase incidentes como evidência de capacidade de prevenção, e não como evidência de vulnerabilidade, o que exige explicar tanto à equipe de avaliação quanto ao fornecedor por que ataques evitados são indicadores positivos.
- Solicite o histórico de quase incidentes, apresentado como evidência de capacidade de prevenção
- Solicite as métricas do programa de prevenção: taxas de bloqueio, taxas de quarentena, prazos de aplicação de patches
- Avalie a pressão de ataques: valor dos dados do fornecedor e histórico de ataques direcionados ao setor
- Distinga as origens dos históricos limpos na avaliação de risco
- Pondere a capacidade de prevenção junto com o histórico de violações na avaliação da postura de segurança
Se você faz parte de uma equipe pequena
Em cada avaliação de fornecedor, faça duas perguntas além da pergunta sobre o histórico de violações. Primeira: nos últimos dois anos, vocês tiveram eventos de segurança significativos que foram detectados e evitados antes de se tornarem violações? Em caso afirmativo, quais foram os tipos de ataque e como foram detidos? Segunda: qual é a sua taxa de bloqueio de e-mails maliciosos na segurança de e-mail, e quantas amostras de malware o seu EDR colocou em quarentena antes da execução nos últimos doze meses? Essas duas perguntas revelam se o histórico sem violações se baseia em capacidade de prevenção ou em baixa exposição a ataques.
- Solicite o histórico de ataques significativos evitados junto com o histórico de violações
- Solicite a taxa de bloqueio da segurança de e-mail e as estatísticas de quarentena do EDR
- Avalie a pressão de ataques: valor dos dados do fornecedor e ataques direcionados ao setor
- Distinga a capacidade de prevenção do histórico de prevenção
O que exigir
Pergunte diretamente:
“Além do histórico de violações, vocês podem compartilhar quase incidentes em que ataques significativos foram detectados e evitados nos últimos dois anos, junto com sua taxa de bloqueio da segurança de e-mail e as estatísticas de quarentena do EDR? Consideramos a prevenção bem-sucedida um indicador positivo de capacidade.”
O que esperar como evidência
- Histórico de quase incidentes: ataques significativos evitados
- Taxa e volume de bloqueio da segurança de e-mail
- Estatísticas de quarentena do EDR
- Prazos de aplicação de patches para vulnerabilidades críticas
Um fornecedor que confirma um histórico sem violações deve ser solicitado a apresentar as métricas do programa de prevenção que o explicam. O histórico de violações mostra o que não foi detido. As métricas de prevenção mostram o que foi.
Como comprovar
- Registros da avaliação do histórico de quase incidentes
- Métricas do programa de prevenção
- Avaliação da pressão de ataques
- Avaliação do equilíbrio entre detecção e prevenção
Principal conclusão
Zero violações. Três ataques evitados. Cento e quarenta e sete mil e-mails de phishing bloqueados. Três amostras de malware em quarentena. Uma vulnerabilidade crítica corrigida em quarenta e oito horas. O histórico sem violações e o rico histórico de quase incidentes estão ambos presentes. A avaliação que pergunta apenas sobre violações vê o histórico de falhas, que está vazio, e deixa passar a evidência da capacidade de prevenção. O programa de prevenção é demonstrado pelo que ele deteve. O histórico de violações reflete apenas o que ele não deteve. Solicite o histórico de quase incidentes. Solicite as taxas de bloqueio. O histórico sem violações é o resultado. O programa de prevenção é a explicação.