Monitoramento de Superfície de Terceiros

Nota 01 da subseção 02 do capítulo 21, que estende o EASM para além da fronteira organizacional.
O objeto de estudo aqui é a exposição de fornecedores, parceiros e prestadores de serviço vista como parte da superfície de ataque da própria organização.
Dialoga com a nota de IOE do capítulo 03, com o controle INT.3 da seção 15 e com a nota de Attack Graph Modeling desta mesma subseção.

1. Contexto e Posicionamento na Biblioteca

As notas anteriores de EASM trataram da superfície que a organização controla diretamente: domínios próprios, endereços IP contratados, contas em nuvem governadas pelo time de segurança. Esta nota desloca o ponto de observação para a fronteira estendida, em que a exposição relevante pertence juridicamente a outra organização, mas compromete operacionalmente a sua. A diferença é essencial para o EASM maduro, porque o adversário raramente respeita a fronteira contratual: ele entra pelo fornecedor mais frágil que detém acesso ao alvo mais valioso. O caso SolarWinds, com o comprometimento da cadeia de build e distribuição de atualizações, e o caso Kaseya, com exploração de VSA para atingir centenas de provedores de serviço gerenciado ao mesmo tempo, demonstram que a superfície de terceiros é vetora primária e não exceção estatística.

Dentro do mapa da biblioteca, esta nota responde à pergunta de escopo do CTEM: quem, além de nós, pode nos expor? Ela produz a lista de terceiros monitorados e os dados de exposição associados que alimentam a priorização por grafo de ataque descrita na nota seguinte, e conecta-se ao controle INT.3 da seção 15, que cruza inteligência de ameaças com exposição. O objetivo prático é que o leitor saia daqui capaz de montar um inventário de terceiros com dependência crítica, escolher métodos de monitoramento proporcionais à criticidade e formalizar o tratamento de achados por contrato, sem depender da boa vontade ou do portal de rating do fornecedor.

2. Terceiros como Extensão da Superfície de Ataque

A dependência de terceiros cria três classes de exposição que o EASM interno não enxerga. A primeira é a exposição do próprio fornecedor: servidores de acesso remoto, portais de clientes e consoles de administração do parceiro que, se comprometidos, entregam acesso direto ao ambiente da organização. A segunda é a exposição conjunta: subdomínios hospedados no provedor, integrações por API, contas de serviço compartilhadas e credenciais de conexão que existem exatamente na fronteira entre as duas organizações. A terceira é a exposição em cascata via provedores de provedor, típica do mercado de MSSP, em que um único fornecedor de nível 2 concentra acesso a dezenas de organizações de nível 1, ampliando o raio de impacto de qualquer falha sua.

O mapeamento correto começa por inventariar as dependências reais, e não as que constam no cadastro de compras. Sistemas que recebem dados do fornecedor, contas federadas ao seu IdP, chaves de API emitidas para o parceiro e integrações de rede documentadas no firewall são o inventário de confiança. Sobre esse inventário aplicam-se as perguntas clássicas de EASM, só que apontadas para o ambiente alheio: o que do fornecedor é alcançável da internet, o que dele se conecta a nós, e o que aconteceria se aquela máquina fosse dominada hoje. A resposta a essa última pergunta define a criticidade do monitoramento, e não o tamanho do contrato.

A leitura pelo lado do adversário ajuda a ordenar o esforço. Um grupo de ransomware moderno não começa pela organização alvo; começa pela oferta de acesso em mercado clandestino, e o corretor que vende esse acesso quase sempre o obteve de um fornecedor de nível inferior. Isso significa que a superfície de terceiros é explorada de forma industrial e prévia ao incidente, o que muda o papel do monitoramento: ele não é exercício de due diligence anual, é telemetria contínua de risco, com cadência e alarmes, exatamente como a observação da superfície própria.

3. Métodos de Monitoramento da Exposição de Terceiros

O monitoramento de terceiros combina fontes passivas, que não exigem autorização, com fontes ativas, que exigem contrato formal. A regra de ouro é usar o máximo de passividade possível e reservar a varredura ativa para os fornecedores de maior criticidade, sempre com autorização documentada. A tabela a seguir resume os métodos disponíveis e suas limitações operacionais.

Os métodos passivos de certificado e DNS operam da mesma forma que na nota de IOE do capítulo 03, apenas com a marca do fornecedor no lugar da marca própria. Uma consulta semanal aos logs de Certificate Transparency com o domínio do parceiro crítico revela quando ele sobe um novo portal de acesso para clientes, e esse portal pode ser justamente a porta que o seu pessoal interno usa, tornando-o parte efetiva da sua superfície. A resolução dos subdomínios descobertos mostra se há apontamentos para recursos desativados, candidatos a takeover, e o histórico de resolução expõe migrações de hospedagem que alteram o risco de concentração.

A varredura ativa autorizada é o único método que produz evidência técnica completa, com serviço, versão e configuração, e por isso fica reservada ao topo da pirâmide de criticidade. O contrato deve definir escopo de endereços e domínios, janela de execução, técnica permitida, tratamento de dados coletados e prazo de correção. Ratings externos complementam o quadro com visão longitudinal e comparação de mercado, mas o analista precisa tratá-los como hipótese a validar: uma nota baixa indica onde olhar, e a evidência técnica, quando acessível, é o que entra no ticket.

A combinação dos métodos deve seguir níveis de criticidade, porque monitorar todos os terceiros com a mesma intensidade é inviável e dilui o esforço. O modelo de três níveis abaixo é um ponto de partida calibrável, e a regra de promoção de nível é a mudança de dependência: um fornecedor de nível 3 que passa a ter integração de rede sobe imediatamente para tratamento de nível 1.

O custo de manter essa pirâmide é baixo porque os métodos passivos são automatizáveis e os ativos se concentram em poucos fornecedores. Uma base realista de mil fornecedores cadastrados produz dezenas de nível 1 e algumas centenas de nível 2, o que cabe em automação simples com revisão humana semanal. O erro de dimensionar o programa como projeto de consultoria anual, em vez de telemetria, é o que separa bibliotecas de gestão de risco documentadas de programas que efetivamente encurtam a janela de exposição.

4. Contratos, Transparência e Diferenciação de Responsabilidade

O monitoramento sem lastro contratual produz conflito: o achado existe, mas ninguém é obrigado a corrigi-lo. O instrumento que resolve isso é a cláusula de segurança do contrato ou do acordo de nível de serviço, que deve prever, no mínimo, o direito de monitoramento da superfície relevante, a obrigação de notificação de incidentes em prazo definido, o prazo de correção por severidade de achado, o acesso a relatórios de auditoria e o direito de auditoria técnica em caso de achado grave. Sem essas cláusulas, o time de segurança descobre a exposição e assiste passivamente à negociação comercial decidir o destino do risco.

A diferenciação de responsabilidade precisa ser explícita, porque a zona cinzenta é onde os achados apodrecem. A matriz abaixo é o modelo recomendado para constar do contrato e do registro interno de monitoramento, deixando claro quem detecta, quem corrige e quem valida em cada tipo de ativo.

A transparência deve funcionar nos dois sentidos e com cadência definida. No sentido de saída, a organização entrega ao fornecedor crítico a lista de achados com evidência, severidade proposta e prazo; no sentido de entrada, recebe o plano de correção e o status. A governança recomendada é uma reunião periódica de revisão de postura para os fornecedores de nível 1, com métrica de tempo médio de correção como indicador de maturidade, e a escada de sanções prevista em contrato para reincidência.

5. Exemplo de Fluxo de Monitoramento de Fornecedor Crítico

O exemplo a seguir modela o monitoramento de um fornecedor de nível 1, um provedor de portal de parceiros com integração de rede e credencial de API, usando um perfil declarativo que orienta a automação e as cadências humanas.

fornecedor:
  id: FORN-0142
  nome: PortalParceiros S.A.
  nivel: 1                      # acesso de rede, federacao de identidade e dados compartilhados
  dependencias:
    - portal.fornecedor.com.br  # usado por 340 usuarios internos
    - api.fornecedor.com.br     # integracao diaria de dados
    - vpn_fornecedor_para_rede_interna: 10.20.0.0/22
  monitoramento_passivo:
    certificado_transparencia:
      dominio: fornecedor.com.br
      cadencia: diaria
      alerta: emissao para subdominio novo
    dns_passivo:
      cadencia: semanal
      alerta: mudanca de hospedagem ou apontamento para recurso inexistente
    monitor_vazamento:
      escopo: dominios de e-mail do fornecedor e credenciais de nossa integracao
      cadencia: continua
  monitoramento_ativo:
    varredura_externa:
      escopo: portal.fornecedor.com.br, api.fornecedor.com.br
      janela: quarta-feira, 02:00-04:00, autorizada em contrato
      cadencia: mensal
    exigencia_contratual:
      relatorio_postura: trimestral
      notificacao_incidente: 24 horas
      prazo_correcao_critico: 72 horas
  rotina_de_achado:
    - descoberta pelo metodo correspondente
    - registro do achado com evidencia, data e severidade proposta
    - notificacao ao dono da relacao comercial com prazo
    - acompanhamento do plano de correcao do fornecedor
    - revalidacao tecnica na data acordada
    - escalacao para patrocinio executivo em caso de prazo vencido

O fluxo de achado merece atenção na etapa de revalidação, porque ela é a única que transforma promessa em correção real. A revarredura ou a consulta passiva repetida na data acordada fecha o ciclo com evidência, e o histórico de cumprimento de prazos por fornecedor se torna insumo objetivo para renegociação de contrato e para a decisão de continuidade da relação comercial. Fornecedores que corrigem rápido e comunicam cedo permanecem no nível 1 com confiança; os que acumulam prazo vencido descem para tratamento reforçado, com auditoria técnica e restrição de integração.

Há ainda o cenário inverso, em que a descoberta não é um achado de configuração, mas um incidente declarado pelo fornecedor ou um vazamento público. Nesse caso o monitoramento vira contenção: enquanto o parceiro investiga, a organização deve restringir a integração afetada, rotacionar credenciais compartilhadas, colocar os ativos de fronteira em watchlist no SIEM e elevar a prioridade de qualquer telemetria envolvendo a conexão com o fornecedor. A regra prática é simétrica à da nota de IOE: enquanto a porta está sob risco, o defensor precisa estar olhando para ela, e a janela entre o anúncio do incidente do parceiro e a confirmação de ausência de impacto é o período de maior densidade de atenção do programa.

6. Erros Comuns e Pontos de Atenção

• Monitorar apenas fornecedores tecnológicos: fornecedores de logística, folha e facilities também mantêm acessos remotos e integrações, e os incidentes públicos mostram que a porta de entrada costuma ser o fornecedor menos óbvio.
• Tratar nota de rating como diagnóstico: a nota orienta onde olhar, mas a correção só se abre com evidência técnica verificável; usar a nota como título de ticket gera discussão estéril com o parceiro.
• Varrer sem autorização documentada: varredura de ambiente de terceiro sem contrato pode configurar ilícito e destruir a relação comercial; a autorização precisa constar de documento assinado antes da primeira varredura.
• Ignorar a cadeia de nível 2: o MSSP que gerencia o seu fornecedor concentra acesso a dezenas de organizações, e essa concentração deve pesar na criticidade e no escopo de questionamento contratual.
• Deixar a responsabilidade na zona cinzenta: achado na fronteira de DNS, de API ou de federação apodrece sem matriz de responsabilidade explícita; definir dono por tipo de ativo antes do primeiro achado.
• Encerrar o ciclo no ticket fechado pelo fornecedor: sem revalidação técnica independente, o fechamento é autodeclarado e não confiável.
• Esquecer de revisar o inventário de dependências: contratos novos, aquisições e desligamentos de sistema mudam o mapa de terceiros, e a revisão do inventário deve acompanhar o ciclo de compras, não o calendário do programa de segurança.
• Tratar notificação de incidente do parceiro como novidade que zera o plano: a resposta a incidente de terceiros deve estar desenhada antes, com restrição de integração, rotação de credenciais e watchlist prontos para execução.

7. Integração com o Restante da Biblioteca

As conexões estruturais desta nota com o restante da biblioteca seguem quatro caminhos:

• Capítulo 03: os métodos de CT logs, DNS passivo e monitoramento de marca descritos na nota de IOE são reaplicados aqui com o domínio do fornecedor como alvo.
• Capítulo 21: a nota de Attack Graph Modeling desta mesma subseção usa as dependências de terceiros como nós do grafo para calcular impacto em cadeia.
• Seção 15: o controle INT.3 correlaciona inteligência de ameaças com exposição de terceiros, e o grupo GOV governa a inclusão de cláusulas de segurança em contratos.
• Capítulo 22: achados consolidados sobre fornecedores podem ser estruturados em STIX e compartilhados com setores e consórcios, quando o contrato e o TLP permitirem.

A regra que fecha o raciocínio é a simetria de observação: tudo que o EASM interno observa sobre a própria superfície, com método e cadência, deve existir também para a superfície dos fornecedores que detêm acesso relevante, com intensidade proporcional à criticidade. A proporção de achados de terceiros corrigidos dentro do prazo contratual é a métrica que resume a saúde do programa, e sua evolução negativa é um dos poucos sinais que justificam alterar a arquitetura de dependência em vez de apenas pressionar o fornecedor.