PRT.4 - Monitoramento de Containers e Cloud-Native

Nota do grupo PRT (Defesa em Profundidade) do Framework CTH, derivada do capítulo 7, seção 7.4 (PRT.4.1 a PRT.4.5), do PDF de referência.
Ambientes containerizados e em nuvem têm superfície de ataque própria, que ferramentas tradicionais de endpoint não alcançam.
A nota cobre runtime security com Falco e eBPF, audit logs do Kubernetes, prevenção com admission controllers, CSPM e CWPP, telemetria de cloud para hunting e os desafios de correlação de identidade.

1. Contexto e Posicionamento no Framework CTH

O grupo PRT estende aqui a defesa em profundidade para ambientes em que as premissas do endpoint clássico deixam de valer. Cada container é um ambiente de execução efêmero, com sistema de arquivos, rede e processos próprios, e o orquestrador adiciona uma camada de API de controle que é, ao mesmo tempo, o maior ativo a proteger e a melhor fonte de telemetria. Ataques a esses ambientes exploram má configuração do cluster, imagens comprometidas, escapes de container e movimentação lateral entre pods, padrões que um EDR tradicional instalado no nó raramente interpreta corretamente.

No programa integrado, PRT.4 cumpre o papel de traduzir a visibilidade cloud-native para o mesmo ciclo de CTI, detecção e hunting dos demais controles. As detecções de runtime alimentam o DAT.4 e a triagem do IR.2, os audit logs sustentam hipóteses de hunting específicas de nuvem e as políticas de prevenção reduzem o volume de ruído que chega à detecção. O mapeamento para o MITRE ATT&CK é direto, com técnicas como criação de pods maliciosos (T1610), escape de container para o host (T1611) e abuso de credenciais da API do Kubernetes (T1078.004).

2. Particularidades de Ambientes Efêmeros

A efemeridade muda a mecânica da resposta e da investigação. Um pod comprometido pode viver minutos e ser reagendado em outro nó, destruindo toda a evidência em disco no momento em que o incidente é aberto. A consequência operacional é que a evidência precisa ser coletada de forma centralizada e contínua, e não sob demanda, pois não existirá máquina para examinar depois. Logs de runtime e de auditoria devem sair do cluster em tempo quase real, com retenção definida no DAT.5.

A escala reforça a mesma exigência. Centenas de pods com vidas curtas geram um volume de eventos que inviabiliza revisão manual e exige detecção automatizada com regras por comportamento. A identidade, por sua vez, deixa de ser um host com nome estável e passa a ser um serviço: service accounts, roles do Kubernetes, identidades gerenciadas e tokens de curta duração. Cada detecção precisa responder três perguntas para ser acionável: qual workload executou, com qual identidade e a partir de qual imagem.

Essas três particularidades definem o desenho do controle. Telemetria persistida fora da carga, detecção por comportamento em vez de artefato e correlação por identidade de workload são os três pilares que as seções seguintes detalham.

3. Runtime Security com Falco e eBPF

A segurança de runtime observa o que os containers realmente fazem, independentemente do que a imagem prometia. O Falco é o motor de referência open-source para esse fim, apoiado em eBPF ou em módulo de kernel para capturar chamadas de sistema em tempo real, e aplica regras legíveis que descrevem comportamentos proibidos. O eBPF tornou-se o mecanismo preferido de mercado porque observa syscalls com sobrecarga baixa, sem depender de módulos de kernel frágeis em versões modernas de Linux.

Regras típicas e de alto valor incluem os padrões abaixo, exigidos de forma genérica por PRT.4.2.

• Execução de shell interativo dentro de container, padrão quase sempre associado a exploração e não a operação legítima.
• Leitura de arquivos sensíveis, como credenciais de service account, chaves privadas e arquivos de segredos montados.
• Montagem ou acesso a paths do host, incluindo /proc, /sys e diretórios de sockets do Docker, sinais clássicos de escape de container (T1611).
• Comunicação de rede inesperada para o perfil do container, incluindo reverse shells e downloads por utilitários improváveis.
• Modificação de binários do sistema e escrita em diretórios que deveriam ser somente leitura.

O exemplo abaixo ilustra uma regra Falco comentada no formato do motor, observando execução de shell em qualquer container.

# Regra Falco ilustrativa: shell executado dentro de container
- rule: Shell interativo em container
  desc: Detecta execucao de shell em container, padrao comum em comprometimento
  condition: spawned_process and container and proc.name in (bash, sh, zsh, dash)
  output: "Shell em container (user=%user.name pod=%k8s.pod.name ns=%k8s.ns.name
           imagem=%container.image.repository cmd=%proc.cmdline)"
  priority: WARNING
  tags: [container, runtime, T1059]

O caminho de saída do Falco é essencial para o controle funcionar: eventos devem ser encaminhados ao SIEM com os metadados do orquestrador, como pod, namespace, imagem e nó, para que o analista enxergue contexto imediato. Regras próprias derivadas de CTI seguem o mesmo repositório e disciplina do PRT.5, com versionamento e teste antes da produção.

4. Kubernetes Audit Logs como Fonte Crítica

Os audit logs do Kubernetes registram cada requisição ao API server, incluindo quem fez, o que pediu, de onde veio e qual foi o resultado. Trata-se da fonte mais crítica para detectar abuso do plano de controle, e o PRT.4.1 a estabelece como salvaguarda básica: nível RequestResponse para operações sensíveis, como criação e deleção de pods, configuração de RBAC e acesso a secrets, e nível Metadata para operações regulares. Sem esse log habilitado, a organização não tem como saber se alguém executou um pod privilegiado, criou um role permissivo ou leu um secret.

Eventos de maior valor para alerta e hunting incluem os padrões abaixo.

• create ou update em pods/exec, que indica sessão interativa iniciada em um container.
• Criação de pods com privileged igual a true, hostNetwork, hostPath ou capacidades perigosas.
• Criação ou modificação de roles, clusterroles, rolebindings e clusterrolebindings, sobretudo quando concedem wildcard de recursos.
• Leitura de secrets fora do caminho normal da aplicação, especialmente em massa.
• Criação de tokens de service account e vinculação de contas de serviço inesperadas.

A consulta abaixo ilustra a detecção desses padrões no SIEM a partir dos audit logs encaminhados, com foco nas ações mais sensíveis em uma janela de 24 horas.

// KQL ilustrativo sobre Kubernetes audit logs no SIEM
KubeAuditLogs
| where TimeGenerated > ago(24h) and Verb in ("create","update","patch")
| where ObjectRef_Resource == "pods/exec"
   or (ObjectRef_Resource == "pods" and RequestObject contains "privileged: true")
   or ObjectRef_Resource in ("roles","clusterroles","rolebindings","clusterrolebindings")
   or (ObjectRef_Resource == "secrets" and Verb in ("get","list"))
| project TimeGenerated, Verb, User_username, SourceIPs, ObjectRef_Resource, ObjectRef_Name
| order by TimeGenerated desc

O campo de usuário de origem merece atenção especial: requisições feitas por usuários humanos fora do processo de deploy, ou por service accounts que nunca executaram aquela ação, são hipóteses imediatas de comprometimento de credencial (T1078.004). A correlação com o IP de origem e com o horário operacional do time de plataforma reduz falsos positivos e prioriza a fila.

5. Admission Controllers e Políticas como Prevenção

A detecção de runtime chega depois que o comportamento indesejado já começou, e a camada de prevenção deve reduzir o número de casos que chegam lá. Admission controllers interceptam cada criação ou modificação de recurso e aplicam políticas antes de o objeto ser aceito no cluster. As Pod Security Standards nos perfis baseline e restricted, exigidas no nível de namespace por PRT.4.3, fornecem a baseline de mercado, bloqueando execução como root, capacidades Linux desnecessárias, volumes hostPath e privilégios de escalonamento.

Ferramentas de política como OPA Gatekeeper ou Kyverno estendem esse modelo para requisitos organizacionais, como exigência de rótulos de propriedade, restrição de registros de imagem permitidos, verificação de assinatura de imagem e limite de recursos. Network Policies complementam a prevenção restringindo a comunicação entre pods, reduzindo a movimentação lateral dentro do namespace. A regra de composição é clara: o admission controller impede o objeto perigoso de nascer, e o runtime detecta o que escapou da política, quebrando o comportamento em camadas conforme o princípio do grupo PRT.

A efetividade dessa camada depende de governança de exceções idêntica à das exclusões de EDR descritas em PRT.1. Todo workload que precisa de privilégio legítimo, como operadores de banco e agentes de monitoramento, deve ter a exceção documentada, com namespace restrito, dono e revisão periódica, e não um cluster inteiro operando no perfil permissive.

6. CSPM e CWPP

As siglas CSPM e CWPP organizam as capacidades de segurança cloud-native em dois eixos complementares. O CSPM (Cloud Security Posture Management) avalia a configuração da plataforma em busca de desvios, como buckets públicos, grupos de segurança abertos para o mundo, criptografia ausente, contas de serviço com privilégio excessivo e exposição pública do API server. O CWPP (Cloud Workload Protection Platform) protege as cargas em si, com scanning de vulnerabilidades de imagem, monitoração de runtime e detecção de drift entre a imagem esperada e o processo em execução.

O scanning de imagens em tempo de build e no deploy, exigido por PRT.4.4 com ferramentas como Trivy ou Grype, conecta os dois eixos. A política de bloqueio de imagens com vulnerabilidades críticas ou altas não resolvidas, aplicada no admission controller, transforma o resultado do scanning em prevenção efetiva. A cobertura deve incluir também drift de runtime, comparando o processo observado com a assinatura da imagem, pois imagem comprometida em execução é uma das formas mais silenciosas de persistência em ambientes cloud-native.

7. Telemetria de Cloud e Hunting em Nuvem

Cada provedor produz logs de plano de controle equivalentes e complementares aos audit logs do Kubernetes: o CloudTrail na AWS, o Azure Activity Log e o GCP Audit Logs. Esses logs registram cada ação de API na conta, incluindo mudanças de IAM, alterações de rede, acesso a objetos e desligamento de serviços de log, e são a base do hunting em nuvem. A recomendação operacional é coletar tanto eventos de gestão quanto eventos de dados relevantes, como leitura em massa de objetos em buckets sensíveis, e encaminhar tudo ao SIEM central.

Hipóteses de hunting em nuvem de alto valor seguem o mesmo raciocínio comportamental dos demais domínios.

• Criação de chaves de acesso e políticas de permissão ampla fora de janelas de mudança aprovadas.
• Cadeias de assunção de roles em sequência incomum, possível caminho de escalonamento entre contas.
• Download massivo de objetos ou operações de listagem ampla sobre buckets com dados sensíveis, sinal de exfiltração.
• Desativação de logging, exclusão de trails ou alteração de retenção, técnica clássica de evasão.
• Execução de funções serverless por identidades que nunca as invocaram.

A consulta abaixo ilustra a detecção de ações sensíveis de IAM a partir de logs de CloudTrail no SIEM, padrão aplicável com pequenas variações ao Azure Activity e ao GCP Audit.

// KQL ilustrativo sobre CloudTrail no SIEM
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventName in ("CreateAccessKey","CreateRole","AttachRolePolicy",
                      "PutBucketPolicy","StopLogging","DeleteTrail")
| project TimeGenerated, UserIdentityUserName, EventName, SourceIpAddress, UserAgent
| order by TimeGenerated desc

O cruzamento dessas ações com mudanças de infraestrutura e com telemetria de rede de PRT.2 fecha a visibilidade da nuvem. Uma alteração de grupo de segurança seguida de conexão externa incomum para uma instância é o exemplo canônico de correlação que nenhum log isolado entrega.

8. Desafios de Correlação de Identidade

A identidade é o elo mais difícil da cadeia em ambientes cloud-native, e a correlação exige decisões explícitas de desenho de telemetria. Um token de service account do Kubernetes, uma identidade gerenciada da nuvem e um usuário humano podem realizar a mesma ação, e a investigação precisa determinar qual workload estava por trás do token. Identidades federadas por workload, como associações entre service account e identidade gerenciada, reduzem a ambiguidade, mas só ajudam se a associação estiver registrada nos logs.

Práticas que resolvem a maior parte do problema incluem registrar o identity mapping como dado de referência no SIEM, padronizar o uso de identidades únicas por workload em vez de contas compartilhadas, e alertar sobre uso de credenciais humanas em automação e vice-versa. Tokens de curta duração, por sua vez, reduzem o impacto de roubo de credencial, mas exigem que os logs retenham o contexto da sessão de origem para que a ação permaneça atribuível depois da expiração. Sem essas práticas, a pergunta central de qualquer incidente cloud-native, quem fez, fica sem resposta confiável.

9. Salvaguardas por Nível de Maturidade

As salvaguardas de PRT.4 seguem os três níveis cumulativos do Framework, conforme a tabela consolidada abaixo.

A verificação deve incluir teste de ponta a ponta, executando um pod com shell em ambiente controlado e confirmando que a detecção chega ao SIEM com identidade, pod e imagem corretos. Métricas úteis são a porcentagem de clusters com audit log habilitado, o tempo entre ação sensível e alerta no SIEM, e a proporção de workloads cobertos por política de admission.

10. Erros Comuns e Pontos de Atenção

O erro mais grave é deixar os audit logs do Kubernetes desabilitados, situação ainda comum em clusters implantados sem padrão de plataforma. Sem esse log, a organização é cega para abuso do plano de controle e não consegue reconstruir nem a linha do tempo de um incidente. O segundo erro clássico é confiar no perímetro da VPC como se fosse controle de segurança suficiente, tratando tudo dentro da rede como confiável; a lateralidade cloud-native nasce exatamente dessa premissa quebrada.

Completam a lista de falhas recorrentes os itens abaixo.

• Depender apenas de scanning em build, sem admission nem runtime, deixando imagens antigas e drift invisíveis.
• Políticas de segurança desabilitadas por atrito inicial, sem processo de exceção que equilibre agilidade e controle.
• Alertas de runtime enviados a console separado do SOC, sem integração com SIEM nem com o fluxo de triagem.
• Falta de retenção de logs de workloads efêmeros, inviabilizando investigação após o encerramento do pod.
• Service accounts com permissões amplas reutilizadas por várias aplicações, tornando impossível atribuir o uso a um workload.
• Control plane do Kubernetes exposto publicamente sem restrição de origem, transformando a API em alvo de varredura constante.

11. Integração com Outros Controles do Framework CTH

PRT.4 alimenta o DAT.4 com as três famílias de telemetria descritas, runtime, auditoria do orquestrador e plano de controle da nuvem, e depende do DAT.5 para reter evidências que sobrevivem à efemeridade dos workloads. As hipóteses de hunting específicas de nuvem e containers se integram às metodologias de TH.x, e as detecções validadas retroalimentam a engenharia de detecção do DET.x. Na resposta a incidentes, as capacidades de contenção cloud-native, como quarentena de pod e revogação de token, sustentam o IR.x.

Na direção da inteligência, o CTI fornece TTPs de ataques a cloud-native que se tornam regras de runtime e hipóteses de hunting, e as regras personalizadas do PRT.5 são aplicadas sobre imagens e artefatos do pipeline. As simulações do SIM.x, executadas dentro de clusters de teste, validam se as políticas de admission e as detecções de runtime respondem como esperado, e as métricas de cobertura e tempo de detecção alimentam o MET.x e a governança do GOV.