Resumo: cobertura CTEM do lado do cliente
- O CTEM esquece o navegador: Os programas CTEM são vendidos como contínuos, mas a maioria cobre a infraestrutura do lado do servidor e CVEs a um ritmo mensal, enquanto o JavaScript que corre nos browsers dos utilizadores é tratado como código estático que nunca muda entre versões do fornecedor.
- Descoberta contínua de scripts: A cside descobre continuamente cada script que corre numa propriedade web, sinaliza quando um script acede a elementos sensíveis do DOM ou envia dados para um novo endpoint e gera os alertas e a evidência de que as equipas de Mobilization precisam sem investigação manual.
- No âmbito ou uma constatação? Os Requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 são obrigatórios desde 31 de março de 2025, por isso a pergunta é se o seu programa CTEM trata o JavaScript do lado do cliente como estando no âmbito ou como uma linha de exposição que o auditor irá descobrir por si.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
A gestão contínua de exposição a ameaças (CTEM, do inglês Continuous Threat Exposure Management) é um framework de segurança para gerir o risco como um programa permanente, em vez de uma auditoria periódica. A Gartner introduziu o termo para descrever um ciclo repetido que descobre exposições, ordena-as por explorabilidade real e valida que as correções fecham efetivamente o caminho de ataque.
A premissa é simples. A sua superfície de ataque muda todos os dias. São integrados novos fornecedores, novos scripts chegam às suas propriedades web e são publicadas novas vulnerabilidades, por isso uma avaliação trimestral ou anual já está desatualizada quando o relatório é escrito. Os programas de CTEM são executados de forma contínua, priorizam as exposições consoante o quão exploráveis são no seu ambiente real e acompanham a remediação até ao encerramento verificado.
As cinco fases do CTEM
Os programas de CTEM assentam em cinco fases que se repetem como um ciclo contínuo, e não como um projeto linear.
| Fase | Tarefa CTEM | Evidência do lado do cliente |
|---|---|---|
| Definição de âmbito | Definir os ativos e as superfícies de ataque do ciclo atual | Propriedades web, fluxos de autenticação, páginas de pagamento e scripts de terceiros |
| Descoberta | Identificar as exposições dentro do âmbito definido | Inventário completo de scripts, injeção dinâmica, endpoints e acesso ao DOM |
| Priorização | Ordenar as exposições por explorabilidade e impacto no negócio | Acesso a dados sensíveis, novos destinos e padrões de skimming |
| Validação | Testar a exposição e confirmar a correção | Histórico de comportamento real, evidência de alterações e verificação após a correção |
| Mobilização | Atribuir responsáveis e acompanhar cada constatação até ao encerramento | Alertas, registos de eventos e evidência para as equipas de segurança e aplicações |
Fase 1: Definição de âmbito
O programa define que ativos e superfícies de ataque estão dentro do âmbito do ciclo atual. A definição de âmbito não é permanente. Expande-se à medida que o programa amadurece. Os programas de CTEM em fase inicial começam normalmente por definir o âmbito com base nos ativos mais críticos para o negócio: aplicações web em produção, fluxos de autenticação e infraestrutura de pagamentos. Os ciclos seguintes incorporam sistemas internos, integrações de terceiros e a cadeia de fornecimento. A definição de âmbito responde a uma pergunta simples: o que estamos a proteger e contra que ameaça nos estamos a defender?
Fase 2: Descoberta
A descoberta identifica todas as exposições dentro do âmbito definido e vai muito além dos CVEs conhecidos e das vulnerabilidades instaladas. Num contexto de CTEM, a descoberta abrange que componentes de terceiros estão presentes, que scripts são executados numa aplicação web, que serviços são alcançáveis a partir do exterior, que identidades podem tocar em recursos sensíveis e onde os dados cruzam as fronteiras dos sistemas. Revela a superfície de ataque tal como existe neste momento, incluindo exposições que a equipa de segurança desconhecia.
Fase 3: Priorização
Nem todas as exposições podem ser corrigidas ao mesmo tempo. A priorização ordena-as por risco real, a combinação de gravidade, explorabilidade no ambiente atual e impacto no negócio caso sejam exploradas. O CTEM desprioriza deliberadamente as vulnerabilidades teóricas que não são alcançáveis nem exploráveis na prática, e destaca aquelas que os atacantes estão a visar ativamente. Esta é a fase que distingue o CTEM da simples análise de vulnerabilidades. O resultado é uma lista ordenada do que corrigir primeiro, e não uma lista plana de todas as deteções.
Fase 4: Validação
A validação testa se as exposições identificadas são realmente exploráveis e se os controlos existentes aguentam. Recorre a testes de intrusão, exercícios de red team e simulação de violações e ataques para confirmar que uma exposição priorizada representa um risco real. A validação confirma também que a remediação fechou a exposição, ou seja, que o caminho de ataque já não funciona, e não apenas que um patch foi aplicado. Responde a uma pergunta direta: a nossa defesa funciona mesmo?
Fase 5: Mobilização
A mobilização transforma as deteções validadas em ações de remediação nas equipas que são responsáveis pelos sistemas afetados. As equipas de segurança raramente são donas dos ativos que defendem. As equipas de aplicações, as equipas de infraestrutura e os fornecedores externos têm todos um papel a desempenhar. A mobilização traduz as deteções em tarefas concretas para essas equipas e acompanha cada uma delas até à conclusão verificada.
Porque é que o JavaScript do lado do cliente é um ponto cego do CTEM
A maioria dos programas de CTEM analisa bem a infraestrutura do lado do servidor, os CVEs conhecidos e as exposições ao nível da rede. A camada do lado do cliente, o JavaScript que é executado no navegador de um utilizador quando este interage com a sua aplicação web, está consistentemente sub-representada.
Algumas características tornam a superfície de ataque do lado do cliente difícil de cobrir com as ferramentas tradicionais de CTEM.
Muda sem aviso. Os scripts de terceiros (ferramentas de analítica, widgets de chat, gestores de tags, bibliotecas carregadas por CDN) atualizam o seu conteúdo sempre que o fornecedor assim o decide. Um script avaliado como seguro no mês passado pode ter sido modificado entretanto, comprometido por um atacante ou dotado de um novo comportamento. Essa mudança constante é invisível para as avaliações num único momento.
Os scripts autorizados podem ser transformados em armas. Os ataques Magecart deixam isto bem claro. O risco não se limita aos scripts não autorizados. Os scripts autorizados que alteram aquilo que fazem são o problema mais difícil. Uma página de pagamento que carrega um script de analítica aprovado fica exposta se esse script for comprometido e começar a ler os campos do cartão. O script estava dentro do âmbito. O seu comportamento não estava a ser monitorizado.
Os scanners de CVE não o detetam. Os scanners baseados em CVE procuram vulnerabilidades de software conhecidas. Não detetam alterações de comportamento no JavaScript, a adição de novos scripts de terceiros nem caminhos de exfiltração de dados do lado do cliente.
Os reguladores passaram a exigi-lo. Os Requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1, obrigatórios desde 31 de março de 2025, exigem o inventário de scripts das páginas de pagamento, controlos de autorização e deteção de alterações em tempo de execução. Esses requisitos existem precisamente porque a superfície de ataque do lado do cliente não estava a ser gerida.
Como o cside se enquadra nos programas de CTEM
O cside cobre a camada de exposição do lado do cliente que a maioria dos programas de CTEM nunca alcança. Mapeado para as fases do CTEM:
- Descoberta: o cside descobre continuamente todos os scripts que são executados numa propriedade web, incluindo scripts adicionados através de gestores de tags, dependências de CDN e código injetado dinamicamente, o que lhe dá o inventário completo de que a fase de Descoberta precisa.
- Priorização: a monitorização de comportamento do cside sinaliza quando os scripts acedem a elementos sensíveis do DOM, enviam dados para endpoints externos ou correspondem a padrões associados a ataques de skimming, os sinais que distinguem as exposições exploráveis do lado do cliente das exposições teóricas.
- Validação: o cside produz evidências em tempo real das alterações de comportamento dos scripts, confirmando se uma exposição está ativa e a que dados está a aceder.
- Mobilização: o cside gera os alertas, os registos de eventos e a documentação de evidências que permitem às equipas de segurança e de aplicações agir sobre as deteções do lado do cliente sem investigação manual.
Para as páginas de pagamento em concreto, é também assim que o cside cumpre os requisitos 6.4.3 e 11.6.1 do PCI DSS numa única implementação: um inventário contínuo de scripts com controlos de autorização, mais deteção automatizada de adulteração.
