Compartilhar via

Registro de atividades e detecção de ameaças

O registro em log e a detecção de ameaças permitem que as organizações identifiquem, investiguem e respondam a incidentes de segurança antes de se transformarem em violações em larga escala. Ao contrário das revisões de log periódicas tradicionais, os ambientes de nuvem modernos exigem monitoramento contínuo, análise comportamental e correlação centralizada entre camadas de identidade, rede, dados e aplicativos para detectar ataques de vários estágios que exploram provisionamento rápido, recursos efêmeros e arquiteturas distribuídas. As organizações que implementam recursos abrangentes de registro de logs e detecção de ameaças alcançam resposta rápida a incidentes e preparação forense, enquanto aquelas que negligenciam esses controles enfrentam tempo de permanência do adversário prolongado, escalonamento de privilégios não detectado e incapacidade de reconstruir linhas do tempo de violação.

Sem recursos abrangentes de registro em log e detecção de ameaças, as organizações enfrentam ameaças não detectadas operando por longos períodos, evidências forenses incompletas que impedem a reconstrução de incidentes e lacunas de conformidade regulatória.

Aqui estão os três pilares principais do domínio de Log e Detecção de Ameaças em segurança.

Habilitar recursos de detecção: Antes de responder a ameaças, primeiro você deve implantar sistemas de detecção inteligentes que monitoram continuamente padrões de ataque conhecidos, comportamentos anômalos e indicadores de comprometimento. Os serviços nativos de detecção de ameaças aproveitam a análise comportamental e a inteligência contra ameaças para identificar atividades suspeitas que os controles de acesso tradicionais não podem impedir, desde tentativas de injeção de SQL e uploads de malware até abuso de credenciais e exfiltração de dados. Implemente a detecção em todos os tipos de recursos críticos (computação, dados, identidade, rede) para garantir que nenhuma superfície de ataque permaneça não monitorada.

Controles relacionados:

Habilite o registro em log abrangente: Implemente o registro em log de auditoria sistemática em todas as camadas de nuvem — logs de recursos (operações do plano de dados), logs de atividades (alterações no plano de gerenciamento), logs de identidade (eventos de autenticação e autorização) e logs de rede (fluxos de tráfego e decisões de firewall). O registro em log abrangente fornece as evidências forenses necessárias para reconstruir cronologias de ataque, determinar o raio de impacto de incidentes e apoiar os requisitos de conformidade. Sem trilhas de auditoria completas que abrangem a identidade, a rede e o acesso a dados, os respondentes de incidentes não têm a visibilidade para determinar o que foi acessado, por quem, quando e de onde , prolongando o tempo de vida da violação e aumentando a exposição regulatória.

Controles relacionados:

Centralizar e analisar: Agregar logs de todas as fontes em uma plataforma centralizada de SIEM (Gerenciamento de Eventos e Informações de Segurança) para habilitar a correlação, a análise avançada e a resposta automatizada. A centralização transforma fluxos de log isolados em inteligência contra ameaças acionável correlacionando eventos entre planos de identidade, rede e dados para revelar cadeias de ataque de vários estágios que o monitoramento de fonte única não pode detectar. Estabeleça políticas de retenção disciplinadas alinhadas aos requisitos de conformidade e às necessidades de negócios e garanta a sincronização precisa de tempo em todos os sistemas para manter a integridade forense e habilitar a reconstrução precisa de incidentes.

Controles relacionados:

LT-1: habilitar recursos de detecção de ameaças

Azure Policy: Confira as definições de política internas do Azure: LT-1.

Princípio de segurança

Habilite os recursos de detecção de ameaças em serviços de computação, armazenamento, banco de dados e identidade para identificar padrões de ataque conhecidos, comportamentos anômalos e atividades suspeitas. Use a análise comportamental e a inteligência contra ameaças para detectar ameaças que os controles de acesso tradicionais não podem impedir.

Risco a mitigar

Os adversários exploram ambientes sem detecção de ameaças nativas para realizar ataques que permanecem invisíveis aos controles de segurança tradicionais. Sem análise comportamental e monitoramento baseado em inteligência contra ameaças:

  • Malware e explorações não detectadas: Arquivos mal-intencionados carregados no armazenamento ou tentativas de exploração contra bancos de dados passam despercebidos porque as defesas baseadas em assinatura ou camada de rede não detectam cargas sofisticadas.
  • Exfiltração de dados silenciosos: Extração de dados em larga escala, padrões de consulta incomuns ou volumes de acesso anômalos evitam a detecção devido a linhas de base comportamentais ausentes e detecção de anomalias de volume.
  • Cegueira de movimento lateral: Os invasores pivotam entre recursos (de armazenamento para computação a banco de dados) sem disparar alertas porque a correlação entre serviços diferentes e os feeds de inteligência de ameaças não estão integrados.
  • Injeção de SQL e ataques de aplicativo: As tentativas de exploração de banco de dados por meio de consultas mal-intencionadas ou ataques de camada de aplicativo não são monitoradas sem análise de consulta em tempo real e correspondência de padrões de ameaça.
  • Tempo de vida prolongado: Os invasores mantêm o acesso persistente por longos períodos (dias a meses) porque as fases de reconhecimento, preparo e execução não geram alertas, atrasando a resposta a incidentes e aumentando o impacto da violação.
  • Opacidade de ameaças internas: Atividades internas mal-intencionadas ou negligentes combinam-se com padrões de tráfego legítimos sem análise de comportamento do usuário (UBA) e detecção de anomalias específicas para acesso privilegiado.

A falha na implantação de detecção abrangente de ameaças aumenta o tempo médio para detectar (MTTD) de horas a semanas, amplifica os custos de violação e permite que os adversários estabeleçam uma persistência profunda em sua infraestrutura de nuvem.

MITRE ATT&CK

  • Acesso Inicial (TA0001): explore o aplicativo voltado para o público (T1190) aproveitando vulnerabilidades não detectadas em aplicativos Web ou APIs para obter a base inicial.
  • Execução (TA0002): interpretador de comando e script (T1059) executando código mal-intencionado em recursos de computação ou sem servidor sem disparar alertas comportamentais.
  • Persistência (TA0003): manipulação de conta (T1098) modificando principais de serviço ou criando identidades de acesso remoto não autorizadas não detectadas devido à ausência de monitoramento de anomalias.
  • Evasão de Defesa (TA0005): prejudica as defesas (T1562) desabilitando o registro em log, agentes de monitoramento ou serviços de segurança para operar em pontos cegos.
  • Coleção (TA0009): dados do armazenamento em nuvem (T1530) coletando silenciosamente contêineres de blob ou armazenamento de objetos sem detecção baseada em volume ou padrão.
  • Exfiltração (TA0010): exfiltração por meio de serviço web (T1567) transmitindo dados através de pontos de extremidade de API legítimos em volumes ou momentos que a análise comportamental sinalizaria.
  • Impacto (TA0040): sequestro de recursos (T1496) implantando criptominadores ou abuso computacional não detectado pela detecção de anomalias de consumo de recursos.

LT-1.1: habilitar a detecção de ameaças para serviços de nuvem

Implante funcionalidades de detecção de ameaças nativas em todos os serviços de nuvem críticos para identificar atividades mal-intencionadas, comportamentos anômalos e padrões de ataque conhecidos por meio de análise comportamental e inteligência contra ameaças. Essa camada fundamental fornece a primeira linha de defesa contra ameaças direcionadas a serviços de computação, armazenamento, banco de dados e gerenciamento de chaves. Implemente as seguintes etapas para estabelecer uma cobertura abrangente de detecção de ameaças:

  • Use a detecção de ameaças nativas da nuvem: Implante os recursos de detecção de ameaças da sua plataforma de gerenciamento de postura de segurança de nuvem para serviços de computação, armazenamento, banco de dados e identidade, fornecendo análise comportamental e monitoramento controlado por inteligência contra ameaças.

  • Habilite a cobertura de serviço abrangente: Ative a detecção de ameaças para todos os serviços críticos do Azure usando o Microsoft Defender para Nuvem, abrangendo máquinas virtuais, contas de armazenamento, bancos de dados, contêineres e instâncias do Key Vault.

  • Examine os recursos de detecção: Familiarize as equipes de segurança com os recursos de detecção disponíveis usando o guia de referência de alertas de segurança do Microsoft Defender para Nuvem para entender os tipos de alerta, os níveis de severidade e os requisitos de resposta.

  • Lacunas de detecção de endereço: Para serviços sem a capacidade de detecção de ameaças nativas, colete logs do plano de dados e encaminhe para o Microsoft Sentinel para obter regras de análise personalizadas e detecção comportamental.

  • Otimizar a qualidade do alerta: Configure as regras de filtragem e análise de alertas para reduzir falsos positivos e extrair alertas de alta qualidade dos dados de log, ajustando a sensibilidade à detecção com base na criticidade da carga de trabalho e na tolerância a riscos.

LT-1.2: habilitar a detecção e análise avançadas de ameaças

Aprimore a detecção básica de ameaças centralizando a telemetria de segurança, implantando plataformas de XDR (detecção e resposta estendida unificadas) e enriquecendo alertas com inteligência contra ameaças. Essa camada avançada permite a correlação de ameaças em vários domínios, detecção personalizada para padrões de ataque específicos da organização e alertas avançados de contexto que aceleram a investigação e a resposta. Crie essa funcionalidade de detecção avançada por meio das seguintes etapas:

  • Centralizar a telemetria de segurança: Agregar alertas e dados de log de plataformas de segurança de nuvem, proteção de ponto de extremidade, sistemas de identidade e serviços de aplicativos no Azure Monitor ou microsoft Sentinel para análise e correlação unificadas.

  • Implantar a plataforma XDR unificada: Habilite o Microsoft Defender XDR para correlacionar a detecção de ameaças por meio do Microsoft 365 Defender (pontos de extremidade, email, colaboração), Microsoft Defender for Cloud (infraestrutura do Azure) e Microsoft Entra ID (identidade) com agrupamento de incidentes multidomínio e fluxos de trabalho de investigação automatizados.

  • Criar regras de detecção personalizadas: Crie regras de análise personalizadas que correspondam a padrões de ameaça específicos da organização, indicadores de ataque e violações de lógica de negócios que as detecções pré-criadas não podem resolver.

  • Enriquecer com inteligência contra ameaças: Integre o Microsoft Defender Threat Intelligence para enriquecer alertas com atribuição a atores de ameaça, reputação de infraestrutura, inteligência de exploração de vulnerabilidades e correlação de indicadores comprometidos.

  • Aproveite os indicadores de ameaça: Implemente indicadores de inteligência contra ameaças no Microsoft Sentinel para correspondência automatizada de observáveis (endereços IP, domínios, hashes de arquivo, URLs) contra campanhas conhecidas de infraestrutura mal-intencionada e atores de ameaças.

Exemplo de implementação

Uma organização de fabricação global habilitou a detecção abrangente de ameaças em mais de 300 recursos do Azure que abrangem contas de armazenamento, bancos de dados SQL, instâncias do Cosmos DB e sistemas de produção de IoT para reduzir o tempo médio para detectar ataques sofisticados (MTTD).

Desafio: O monitoramento de segurança tradicional dependia de alertas isolados específicos do serviço sem correlação entre sistemas de armazenamento, bancos de dados, identidade e email. A equipe de segurança não tinha visibilidade unificada para detectar ataques em vários estágios que abrangem campanhas de phishing, comprometimento de credenciais e exfiltração de dados. O tempo médio para detectar ameaças sofisticadas excedeu 30 dias.

Abordagem da solução:

  • Detecção abrangente de ameaças à nuvem: Habilitamos os serviços do Microsoft Defender para Nuvem em mais de 150 contas de armazenamento, 40 instâncias de Banco de Dados SQL, 12 contas de Cosmos DB e bancos de dados PostgreSQL, fornecendo análise comportamental e detecção impulsionada por inteligência de ameaças para operações no plano de dados.
  • Plataforma XDR unificada: Microsoft Defender XDR implementado, correlacionando a detecção de ameaças no Microsoft 365 Defender (endpoints, email, colaboração), Microsoft Defender for Cloud (infraestrutura do Azure) e Microsoft Entra ID (identidade), com correlação automatizada de incidentes entre domínios.
  • Regras de análise personalizadas: Regras de análise do Sentinel criadas detectando ataques em vários estágios, incluindo anomalias de acesso ao armazenamento coincidindo com enumeração de esquema de banco de dados SQL, padrões de extração em massa do Cosmos DB e campanhas de pulverização de credenciais entre serviços.
  • Enriquecimento de inteligência contra ameaças: Inteligência integrada contra ameaças do Microsoft Defender para enriquecer alertas com atribuição de ator de ameaça, infraestrutura de ataque conhecida e contexto de exploração de vulnerabilidades.

Resultado: O Defender XDR detectou e conteve uma cadeia de ataque de phishing para exfiltração logo após a implantação, com a Inteligência de Ameaças identificando a infraestrutura que corresponde a um APT conhecido que visa a propriedade intelectual de fabricação. A correlação automatizada de incidentes entre domínios permitiu que as equipes de segurança investigassem e respondessem rapidamente a ataques de vários estágios que anteriormente permaneceram indetectados por longos períodos.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: SI-4(1), SI-4(2), SI-4(5), SI-4(12), SI-4(23), AU-6(1), AU-6(3)
  • PCI-DSS v4: 10.6.1, 10.6.2, 10.6.3, 10.8.1, 11.5.1
  • Controles CIS v8.1: 8.11, 13.1, 13.2
  • NIST CSF v2.0: DE. CM-1, DE. CM-4, DE. CM-7
  • ISO 27001:2022: A.8.16, A.5.24
  • SOC 2: CC7.2, CC7.3

LT-2: habilitar a detecção de ameaças para gerenciamento de identidade e acesso

Azure Policy: Confira as definições de política internas do Azure: LT-2.

Princípio de segurança

Monitore eventos de autenticação e autorização para detectar credenciais comprometidas, padrões de entrada anômalos e abuso de conta. Identifique anomalias comportamentais, incluindo falhas de autenticação excessivas, viagens impossíveis, uso preterido da conta e escalonamentos de privilégios não autorizados.

Risco a mitigar

Os ataques baseados em identidade continuam sendo o principal vetor de acesso inicial para violações de nuvem, mas muitas organizações não têm monitoramento comportamental para detectar o abuso de credenciais e padrões de acesso anômalos. Sem a detecção de ameaças focada na identidade:

  • Cegueira de comprometimento de credencial: Credenciais roubadas, vazadas ou forçadas por força bruta são usadas por longos períodos (semanas a meses) sem detecção porque estão ausentes anomalias de login e pontuação de risco.
  • Viagem impossível não monitorada: Autenticações bem-sucedidas de locais geograficamente distantes dentro de intervalos de tempo impossíveis indicam compartilhamento ou comprometimento de credenciais, mas ocorrem sem monitoramento e sem uma análise de referência.
  • Exploração de conta preterida: Contas órfãs, ex-funcionários ou entidades de serviço não utilizadas fornecem base de persistência que os invasores aproveitam para evitar o escrutínio do comportamento do usuário.
  • Silêncio na escalada de privilégios: Os invasores se adicionam a funções administrativas, criam novas identidades privilegiadas ou modificam associações de grupo sem acionar alertas de auditoria ou detecção de anomalias.
  • Êxito na pulverização de senha: Ataques de adivinhação de senha baixo e lento evitam limites de bloqueio de conta e evitam a detecção sem análise de falha de autenticação agregada em todo o locatário.
  • Técnicas de bypass de MFA: Os adversários exploram protocolos de autenticação herdados, repetição de sessão ou ataques de fadiga de MFA que têm êxito porque comportamentos de entrada arriscados não são sinalizados ou bloqueados.
  • Opacidade de ameaças internas: Insiders mal-intencionados com credenciais legítimas exfiltram dados ou abusam do acesso privilegiado enquanto se misturam com padrões de atividade normais sem análise de comportamento do usuário (UBA).

A falha ao monitorar anomalias de identidade e acesso permite que os invasores operem usando credenciais válidas, ignorando controles de rede e endpoints, dificultando a detecção.

MITRE ATT&CK

  • Acesso Inicial (TA0001): contas válidas (T1078) utilizando credenciais comprometidas para obter a entrada inicial, parecendo uma autenticação legítima.
  • Acesso à Credencial (TA0006): força bruta (T1110) realizando ataques de pulverização de senha ou preenchimento de credenciais contra contas de usuário e serviço.
  • Acesso à Credencial (TA0006): credenciais não confiáveis (T1552) colhendo credenciais vazadas de bancos de dados de violação pública ou fontes da Web escuras.
  • Persistência (TA0003): manipulação de conta (T1098) criando contas de backdoor, adicionando a grupos privilegiados ou modificando métodos de autenticação.
  • Escalonamento de Privilégios (TA0004): contas válidas (T1078.004) abusando de contas de nuvem para escalonar permissões ou assumir funções com privilégios mais altos.
  • Evasão de Defesa (TA0005): utilizar material de autenticação alternativo (T1550) aproveitando tokens, cookies ou artefatos de sessão para ignorar os requisitos de MFA.
  • Movimento Lateral (TA0008): utilizar material de autenticação alternativo (T1550.001), passando tokens ou credenciais de sessão para acessar recursos adicionais na nuvem.

LT-2.1: Habilitar a detecção e o monitoramento de ameaças da ID do Microsoft Entra

Estabeleça uma visibilidade abrangente das atividades de identidade e autenticação, habilitando o registro de auditoria e o monitoramento de login para todos os recursos de identidade. Essa telemetria fundamental permite a detecção de padrões de autenticação suspeitos, alterações não autorizadas na configuração de identidade e possíveis indicadores de comprometimento da conta. Configure os seguintes recursos de monitoramento:

  • Habilite o log de auditoria abrangente: Ative os logs de auditoria do Microsoft Entra para fornecer rastreabilidade completa para todas as alterações feitas nos recursos de identidade, incluindo gerenciamento de usuário e grupo, atribuições de função, registros de aplicativo e modificações de política.

  • Monitorar atividades de autenticação: Acompanhe os relatórios de entrada para capturar todos os eventos de autenticação para aplicativos gerenciados e contas de usuário, estabelecendo linhas de base para padrões de acesso normais e identificando anomalias.

  • Detectar padrões de entrada arriscados: Habilite o monitoramento de entradas arriscadas para sinalizar tentativas de autenticação de fontes suspeitas, cenários de viagem impossíveis, locais desconhecidos ou uso de credenciais vazadas indicando potencial comprometimento da conta.

  • Identificar contas comprometidas: Monitore usuários sinalizados por risco para detectar contas mostrando vários indicadores de risco que exigem investigação e correção imediatas por meio de fluxos de trabalho automatizados ou de revisão manual.

  • Integrar com plataformas SIEM: Rotear logs de ID do Microsoft Entra para o Azure Monitor, Microsoft Sentinel ou plataformas SIEM de terceiros para correlação avançada, retenção de longo prazo e análise de detecção de ameaças entre domínios.

LT-2.2: Implementar proteção de identidade e controles baseados em risco

Aprimore o monitoramento de identidade com detecção de risco avançada, controles de acesso adaptável e recursos de investigação alimentados por IA. Essa camada avançada aplica o aprendizado de máquina para detectar ataques de identidade sofisticados, automatiza a imposição de autenticação baseada em risco e estende a proteção a ambientes híbridos que conectam a nuvem e a infraestrutura local. Implemente estes recursos avançados:

  • Implantar a detecção de risco de identidade: Habilite a Proteção contra IDs do Microsoft Entra para detectar e corrigir riscos de identidade, incluindo credenciais vazadas, entradas de endereços IP anônimos, fontes vinculadas a malware e ataques de pulverização de senha usando aprendizado de máquina e inteligência contra ameaças.

  • Implementar controles de acesso baseados em risco: Configure políticas de Proteção de Identidade para impor requisitos de autenticação adaptável por meio do Acesso Condicional do Microsoft Entra, exigindo MFA para entradas de risco médio e bloqueando tentativas de autenticação de alto risco até a correção.

  • Monitorar ameaças de identidade de infraestrutura de nuvem: Habilite a proteção de carga de trabalho do Microsoft Defender para Nuvem para detectar atividades suspeitas de identidade, incluindo uso de conta obsoleta, tentativas de autenticação mal-sucedidas em excesso e comportamentos anômalos de principais de serviço.

Estender para ambientes híbridos: Para organizações com o Active Directory local, implante o Microsoft Defender para Identidade para monitorar controladores de domínio, detectar ameaças avançadas, identificar identidades comprometidas e investigar ações internas mal-intencionadas que abrangem a infraestrutura híbrida.

Acelere as investigações com IA: Aproveite o Microsoft Security Copilot para reduzir o tempo de investigação por meio de consultas de linguagem natural, análise automatizada de ameaças, fluxos de trabalho de correção guiados e correlação de sinais de identidade alimentados por IA no Microsoft Defender XDR, Sentinel e Entra ID Protection.

Exemplo de implementação

Uma organização de serviços financeiros com 8.000 funcionários implementou uma detecção abrangente de ameaças de identidade para combater ataques baseados em credenciais direcionados a aplicativos bancários de nuvem e repositórios de dados do cliente.

Desafio: O monitoramento de autenticação tradicional não tinha análise comportamental para detectar ataques baseados em credenciais, incluindo viagens impossíveis, campanhas de pulverização de senha e exploração de conta inativa. A equipe de segurança dependia de revisões manuais de logs, descobrindo comprometimentos apenas após incidentes de fraude ou reclamações de clientes. O tempo médio para detectar ataques baseados em identidade excedeu 30 dias.

Abordagem da solução:

  • Detecção e proteção de risco de identidade: Implantado o Microsoft Entra ID Protection com políticas de Acesso Condicional baseadas em risco bloqueando entradas de alto risco, exigindo MFA para tentativas de autenticação de risco médio e forçando automaticamente redefinições de senha para detecção de credenciais vazadas.
  • Análise avançada do SIEM: Regras de análise do Sentinel criadas detectando padrões de viagem impossíveis, ataques de pulverização de senha (mais de 50 falhas em mais de 10 contas de origem única), escalonamento de privilégios fora das janelas de alterações e reativação de conta inativa.
  • Monitoramento de ambiente híbrido: Implantou o Defender para Identidade em 12 controladores de domínio locais para monitorar sinais do Active Directory e correlacionar-se com padrões de autenticação de nuvem para visibilidade completa.
  • Investigação controlada por IA: O Microsoft Security Copilot integrado que habilita consultas de incidentes em linguagem natural, enriquecimento automatizado de contexto de ameaças, fluxos de trabalho de correção guiados e correlação entre domínios entre o comprometimento de identidade e o acesso a recursos.

Resultado: A Proteção de Identidade sinalizou contas comprometidas logo após a implantação, o Sentinel detectou e continha ataques de recheio de credenciais em poucos minutos, e o Security Copilot permitiu que as equipes de segurança investigassem rapidamente ameaças baseadas em identidade usando consultas de linguagem natural. A organização obteve uma detecção e resposta substancialmente mais rápidas a ataques baseados em identidade que anteriormente permaneceram não detectados por longos períodos.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AU-2(1), AU-6(1), AU-6(3), IA-4(4), SI-4(1), SI-4(12)
  • PCI-DSS v4: 8.2.8, 10.2.1, 10.2.2, 10.6.1
  • Controles CIS v8.1: 6.2, 8.5, 8.11
  • NIST CSF v2.0: DE. CM-1, PR. AC-4, PR. IP-8
  • ISO 27001:2022: A.5.16, A.8.15, A.8.16
  • SOC 2: CC6.1, CC7.2, CC7.3

LT-3: habilitar o registro em log para investigação de segurança

Azure Policy: Confira as definições de política internas do Azure: LT-3.

Princípio de segurança

Habilite o registro em log de auditoria em operações de plano de dados, atividades de plano de controle e eventos de identidade para dar suporte à investigação de incidentes, análise forense e validação de conformidade. O registro em log abrangente fornece a trilha de evidências necessária para reconstruir incidentes de segurança e determinar o escopo da violação.

Risco a mitigar

O log de auditoria abrangente em todas as camadas de nuvem fornece a base forense para investigação de incidentes, reconstrução de violação e validação de conformidade. Sem registro sistemático de eventos de recurso, atividade e identidade:

  • Pontos cegos forenses: Os respondentes a incidentes não podem determinar o que foi acessado, modificado ou excluído durante uma violação porque as operações no plano de dados em nível de recurso (acesso ao cofre de chaves, consultas de banco de dados, leituras de armazenamento) não são registradas.
  • Opacidade do plano de gerenciamento: As alterações de infraestrutura (atribuições de função, modificações de regra de firewall, exclusões de recursos) continuam sem trilhas de auditoria, impedindo a atribuição de ações administrativas mal-intencionadas ou negligentes.
  • Atribuição impossível: As equipes de segurança não conseguem identificar qual identidade realizou ações suspeitas, de qual endereço IP, em que momento ou usando qual método de autenticação, na ausência de logs abrangentes do Microsoft Entra ID.
  • Invisibilidade de movimento lateral: Os invasores transitam entre recursos (VM para armazenamento para banco de dados) sem deixar rastros investigáveis devido à falta de dados de auditoria na correlação de atividades entre serviços.
  • Falha de conformidade: As estruturas regulatórias (PCI-DSS, HIPAA, SOC 2) exigem trilhas de auditoria detalhadas para todo o acesso a dados e ações administrativas, sem registro em log, cria lacunas de conformidade demonstradas e descobertas de auditoria.
  • Tempo de vida estendido: Sem logs abrangentes, as equipes de segurança descobrem violações somente após a notificação externa (reclamações do cliente, divulgação regulatória) em vez de por meio do monitoramento interno , aumentando o tempo médio de espera de dias para meses.
  • Ambiguidade da causa raiz: As revisões pós-incidente não podem determinar o vetor de acesso inicial, o caminho de escalonamento de privilégios ou a sequência de movimentação lateral sem trilhas de auditoria completas que abrangem a identidade, a rede e os planos de dados.

O registro em log inadequado transforma todos os incidentes de segurança em uma investigação prolongada e de alto custo com evidências forenses incompletas e escopo incerto.

MITRE ATT&CK

  • Evasão de Defesa (TA0005): prejudicar defesas (T1562.008) desabilitando ou modificando configurações de log para operar em pontos cegos de monitoramento.
  • Evasão de Defesa (TA0005): remoção de indicador (T1070) excluindo ou manipulando logs para remover evidências de atividade mal-intencionada.
  • Descoberta (TA0007): descoberta de infraestrutura de nuvem (T1580) enumerando recursos, permissões e configurações para mapear o ambiente.
  • Coleção (TA0009): dados do armazenamento em nuvem (T1530) acessando dados confidenciais sem registro em log do plano de dados para acompanhar leituras, downloads ou transferências.
  • Exfiltração (TA0010): exfiltração pelo serviço Web (T1567) extraindo dados por meio de APIs de nuvem em que o registro em log de transações está desabilitado ou incompleto.

LT-3.1: Ativar a infraestrutura e o registro em log de identidades

Estabeleça a trilha de auditoria fundamental capturando todas as operações do plano de gerenciamento e eventos de identidade em seu ambiente de nuvem. Essa camada fornece visibilidade de quem está fazendo alterações na infraestrutura, quando essas alterações ocorrem e como as identidades estão sendo usadas — essencial para detectar modificações não autorizadas, abuso de privilégios e violações de conformidade. Habilite esses principais recursos de registro em log:

  • Habilitar logs de atividades para operações do plano de gerenciamento: Ative os Logs de Atividades do Azure para todas as assinaturas de modo a capturar operações do plano de gerenciamento, incluindo criação, modificação, exclusão de recursos (operações PUT, POST, DELETE), atribuições de função, alterações de política e ações administrativas.

  • Centralizar a coleta de logs de atividades: Configure as configurações de diagnóstico no nível do grupo de gerenciamento ou da assinatura para rotear logs de atividades para um espaço de trabalho centralizado do Log Analytics, visando a retenção de longo prazo, análise de correlação e geração de relatórios de conformidade.

  • Impor cobertura de log consistente: Implante o Azure Policy para impor as configurações de diagnóstico em todas as assinaturas, garantindo a coleta consistente do Log de Atividades e evitando o descompasso de configuração à medida que novas assinaturas são criadas.

  • Capturar eventos de autenticação: Habilite os logs de entrada do Microsoft Entra para registrar todos os eventos de autenticação de usuários e entidades de serviço, incluindo logons interativos, não interativos, de entidade de serviço e autenticações de identidade gerenciada.

  • Controlar alterações de identidade: Habilite os logs de auditoria do Microsoft Entra para controlar todas as alterações feitas na ID do Microsoft Entra, incluindo gerenciamento de usuário/grupo, atribuições de função, registros de aplicativo, modificações de política de acesso condicional e alterações de unidade administrativa.

  • Estender a retenção de logs de identidade: Configure as definições de diagnóstico do Microsoft Entra para rotear logs de entrada e auditoria para a Área de Trabalho do Log Analytics ou o Hub de Eventos, visando uma retenção estendida além do período padrão de 30 dias oferecido pelo Microsoft Entra.

  • Monitorar a infraestrutura de identidade híbrida: Para ambientes híbridos, integre os logs do Microsoft Entra Connect Health para monitorar eventos de sincronização, falhas de autenticação e integridade de integração do Active Directory local.

  • Correlacionar-se com eventos de rede: Habilite os logs de infraestrutura de rede conforme abordado no LT-4 (logs de fluxo do NSG, logs do Firewall do Azure, diagnóstico do Gateway de VPN, logs do Gateway de Aplicativo) para fornecer contexto de rede para investigações de segurança correlacionando eventos de identidade e plano de controle com padrões de tráfego de rede.

LT-3.2: Habilitar o registro em log de plataforma e serviço de dados

Estenda a cobertura de auditoria para operações do plano de dados em que os dados comerciais confidenciais residem e são acessados. Os logs de serviço de plataforma capturam os detalhes "o que foi acessado" e "por quem", que são essenciais para a investigação de violações de dados, ameaças internas e violações de conformidade, abrangendo armazenamento, bancos de dados, gerenciamento de segredos, contêineres e plataformas NoSQL. Configure o seguinte registro em log do plano de dados:

  • Habilitar logs do plano de dados no nível do recurso: Ative os logs de recursos do Azure para operações de plano de dados realizadas nos serviços do Azure, incluindo operações de leitura, gravação e exclusão sobre dados e configurações em todos os serviços de plataforma.

  • Operações de armazenagem de registros: Habilite os logs de diagnóstico do Armazenamento do Azure para capturar todas as operações de armazenamento de blobs, arquivos, filas e tabelas, incluindo eventos de StorageRead, StorageWrite, StorageDelete, com a identidade do chamador, IP de origem e latência da operação para investigações forenses.

  • Auditar atividades do banco de dados: Configure a auditoria do Banco de Dados SQL do Azure para registrar todas as consultas de banco de dados, alterações de esquema, concessões de permissão, tentativas de autenticação e operações administrativas — roteie os logs de auditoria para o workspace do Log Analytics ou conta de armazenamento para monitorar a conformidade e a segurança.

  • Monitorar o acesso a segredos: Habilite os logs de diagnóstico do Azure Key Vault para capturar todas as operações de acesso a chave, segredo e certificado, incluindo recuperação, rotação, exclusão e mudanças de permissão, com contexto completo de auditoria para acompanhamento de ativos confidenciais.

  • Acompanhe as operações NoSQL: Configure logs de diagnóstico do Azure Cosmos DB para capturar operações do plano de dados, desempenho das consultas, padrões de acesso às chaves de partição e eventos de throttling para investigações de segurança e desempenho.

  • Abranger plataformas de dados adicionais: Habilite o log de diagnóstico para outros serviços de dados, incluindo o Azure Data Lake Storage, o Azure Synapse Analytics, o Banco de Dados do Azure para PostgreSQL/MySQL e o Cache do Azure para Redis capturando o acesso a dados e operações administrativas.

0- Logs do plano de controle do Kubernetes: habilite o diagnóstico do Serviço de Kubernetes do Azure (AKS) para capturar logs do plano de controle, incluindo kube-apiserver (todas as solicitações de API), kube-audit (trilha de auditoria de segurança), kube-controller-manager, kube-scheduler e logs do cluster-autoscaler.

  • Monitorar o runtime do contêiner: Configure o Container Insights para coletar métricas de nível de contêiner, logs e dados de desempenho de clusters do AKS, Instâncias de Contêiner do Azure e clusters do Kubernetes habilitados pelo Azure Arc, incluindo eventos de ciclo de vida de pod e utilização de recursos.

  • Acompanhar imagens de contêiner: Habilite o diagnóstico do Registro de Contêiner do Azure para registrar operações de push/pull de imagem, acesso ao repositório, eventos de autenticação, invocações de webhook e resultados de verificação de vulnerabilidade.

  • Automatizar a habilitação de registro em log da plataforma: Use o Microsoft Defender para Nuvem para ativar e configurar automaticamente logs de recursos para serviços com suporte do Azure em todas as assinaturas, reduzindo a sobrecarga de configuração manual.

  • Impor cobertura consistente: Implante o Azure Policy para impor as configurações de diagnóstico para os serviços de dados, garantindo a coleta de log consistente, evitando descompasso de configuração e corrigindo recursos não compatíveis automaticamente.

LT-3.3: habilitar o registro em log de aplicativos e cargas de trabalho

Conclua sua cobertura de auditoria capturando atividades de camada de aplicativo, operações de carga de trabalho personalizadas e execução de lógica de negócios. Os logs de aplicativos fornecem a visibilidade mais profunda de como os usuários interagem com seus sistemas, quais dados corporativos eles acessam e quais ataques de camada de aplicativo são tentados , essenciais para detectar ameaças internas, abuso de aplicativo e ataques sofisticados que ignoram controles de infraestrutura. Implementar log abrangente de aplicativos:

  • Registrar atividades do aplicativo web: Habilite o diagnóstico do Serviço de Aplicativo do Azure para capturar logs de aplicativos, logs de servidor web (logs do IIS/HTTP.sys), mensagens de erro detalhadas, rastreamento de solicitações com falha e logs de implantação para aplicativos web e APIs.

  • Monitorar operações do gateway de API: Configure o diagnóstico do Azure API Management para logar solicitações de API, respostas, falhas de autenticação, violações de limites de requisição, detalhes da execução de políticas, erros de serviço de backend e eventos de gerenciamento de assinaturas.

  • Acompanhar a execução de função sem servidor: Habilite o monitoramento do Azure Functions com a integração do Application Insights para capturar execuções de função, dependências, exceções, métricas de desempenho e eventos de segurança personalizados, incluindo decisões de autorização e auditorias de operações confidenciais.

  • Registrar fluxos de trabalho do processo de negócios: Para o Azure Logic Apps, habilite o diagnóstico para registrar execuções de fluxo de trabalho, eventos de disparo, resultados de ação e falhas de integração que dão suporte a investigações de segurança do processo empresarial.

  • Implantar agentes de monitoramento de VM: Implante o Agente do Azure Monitor em máquinas virtuais windows e Linux para coletar logs de eventos de segurança, Syslog, contadores de desempenho e arquivos de log personalizados.

  • Coletar eventos de segurança do Windows: Configure a coleção de Logs de Eventos do Windows para eventos relevantes à segurança, incluindo tentativas de autenticação (ID do evento 4624, 4625), escalonamento de privilégios (4672, 4673), gerenciamento de contas (4720, 4726, 4738) e alterações de política de auditoria (4719).

  • Reunir logs do sistema Linux: Configure a coleção Syslog do Linux para logs de autenticação (/var/log/auth.log, /var/log/secure), logs do sistema (/var/log/syslog, /var/log/messages) e logs de segurança específicos do aplicativo.

  • Monitorar a proteção de endpoint: Ative o monitoramento antimalware em máquinas virtuais Windows para registrar eventos de detecção de malware, resultados de verificação, atualizações de assinatura e violações de política.

  • Implementar o registro em log estruturado: Implemente o registro em log do aplicativo estruturado com contexto de segurança, incluindo identidade do usuário, endereço IP de origem, ID da solicitação, tipo de operação, rótulos de classificação de dados, decisões de autorização e identificadores de transação de negócios para dar suporte à correlação e análise forense.

  • Habilitar a telemetria do APM: Habilite o Application Insights ou soluções de APM (monitoramento de desempenho de aplicativos equivalentes) para coletar telemetria, exceções, eventos de segurança personalizados, rastreamento distribuído para microsserviços e acompanhamento de dependência.

  • Registrar eventos de segurança do aplicativo: Configure o registro de eventos de segurança da camada de aplicação, incluindo tentativas de autenticação, falhas de autorização, falhas na validação de entradas, escalamentos de privilégio, acesso a dados confidenciais e violações de segurança da lógica de negócios.

  • Monitorar ataques de aplicativo Web: Para aplicativos Web e APIs, registre cabeçalhos de segurança HTTP, violações de política de segurança de conteúdo, imposição de política CORS e eventos de gerenciamento de sessão para detectar ataques na camada de aplicativo.

  • Capturar tentativas de ataque da Camada 7: Habilite o registro em log para gateways de API e firewalls de aplicativo Web para capturar ataques de Camada 7, incluindo tentativas de injeção de SQL, cross-site scripting (XSS), tentativas de execução de código remoto, inclusão de arquivo local, ataques de XXE (entidade externa XML) e padrões de abuso de lógica de negócios.

  • Acompanhe o abuso de API: Configure os registros em log para impor limitações de taxa, falhas de autenticação, detecção de bots e padrões de abuso de API que apoiam a detecção de ameaças e a resposta a incidentes.

Exemplo de implementação

Um provedor de SaaS na área da saúde habilitou um sistema de log abrangente em três camadas (infraestrutura/identidade, serviços de plataforma/dados, aplicativo/carga de trabalho) para atender aos requisitos de auditoria da HIPAA e dar suporte a investigações de segurança para sistemas de prontuário eletrônico de saúde (EHR) que atendem a mais de 200 hospitais clientes.

Desafio: O registro em log fragmentado entre serviços isolados impediu a correlação de ataques de vários estágios. A equipe de segurança não tinha trilhas de auditoria completas para conformidade com HIPAA e não conseguia reconstruir linhas do tempo de incidente que abrangem alterações de infraestrutura, acesso a dados e abuso de aplicativos. O tempo médio para investigar incidentes excedeu 2 semanas devido à agregação manual de log em mais de 120 serviços.

Abordagem da solução:

  • Log de infraestrutura e identidade: Logs de atividade centralizados configurados e logs de ID do Microsoft Entra (entradas, auditoria) no nível do grupo de gerenciamento abrangendo cinco assinaturas, capturando 1,5M de eventos de autenticação diários e 50 mil operações de gerenciamento com retenção de 2 anos para conformidade.
  • Registro de plataforma e serviço de dados: Logs de diagnóstico habilitados para mais de 120 contas de armazenamento, 12 bancos de dados SQL, 15 Cofres de Chaves, instâncias do Cosmos DB e clusters do AKS (kube-audit, Insights de Contêiner) capturando operações no plano de dados, desempenho de consultas e eventos de segurança de contêineres, gerando mais de 2 milhões de eventos de auditoria diários.
  • Registro em log de aplicativo e carga de trabalho: Agente do Azure Monitor foi implantado em 150 VMs, diagnóstico do Serviço de Aplicativos foi habilitado para 8 aplicativos Web, registro em log do Gerenciamento de API foi configurado para 3 APIs de integração de saúde, e o Application Insights foi implementado para rastreamento distribuído com registro em log de contexto de segurança estruturado.
  • Correlação centralizada: As regras de análise do Microsoft Sentinel implantadas correlacionam eventos em todas as três camadas com políticas de retenção em camadas (2 anos regulamentadas pela HIPAA, 1 ano operacional, 90 dias de desempenho) e controles de acesso RBAC do Azure.

Resultado: A correlação de log entre camadas habilitou a detecção rápida de ataques sofisticados de vários estágios que abrangem atribuições de função, acesso ao Key Vault e exfiltração de armazenamento. A organização alcançou a conformidade completa do registro de auditoria HIPAA e reduziu substancialmente o tempo de investigação de incidentes por meio da análise centralizada de logs nas camadas de infraestrutura, plataforma e aplicação.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AU-2(1), AU-3(1), AU-6(1), AU-6(3), AU-12(1), SI-4(2)
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.1, 10.3.2, 10.3.3
  • Controles CIS v8.1: 8.2, 8.3, 8.5, 8.12
  • NIST CSF v2.0: DE. AE-3, DE. CM-1, DE. CM-6, PR. PT-1
  • ISO 27001:2022: A.8.15, A.8.16, A.8.17
  • SOC 2: CC4.1, CC7.2, CC7.3

LT-4: Habilitar o registro em log de rede para investigação de segurança

Azure Policy: Confira as definições de política internas do Azure: LT-4.

Princípio de segurança

Habilite o log de tráfego de rede, incluindo logs de fluxo, logs de decisão de firewall, eventos de firewall de aplicativo Web e consultas DNS para dar suporte à investigação de incidentes e à detecção de ameaças. Os logs de rede fornecem evidências forenses para movimentação lateral, comunicações de comando e controle, exfiltração de dados e violações de política.

Risco a mitigar

Os logs de tráfego de rede fornecem evidências forenses críticas para investigar movimentação lateral, exfiltração de dados, comunicações de comando e controle e ataques de camada de aplicativo. Sem registro de rede abrangente:

  • Cegueira do movimento lateral: Os invasores movem-se estrategicamente através de sub-redes, entre VMs ou de serviços de computação para serviços de dados sem deixar evidências de fluxo de rede, dificultando a identificação de anomalias no tráfego leste-oeste.
  • Opacidade do caminho de exfiltração: Transferências de dados em larga escala para destinos externos, padrões de saída incomuns ou o túnel DNS prosseguem sem serem detectados na ausência de logs de fluxo e da análise de tráfego de firewall.
  • Ataques de camada de aplicativo invisíveis: Tentativas de injeção de SQL, uploads de web shell, abuso de API ou manipulação de protocolo que evita a detecção quando os logs do WAF, os logs do gateway de aplicativo e a inspeção da camada 7 estão desabilitados.
  • Comunicações C2 não detectadas: A beaconização de comando e controle, padrões de retorno de chamada ou protocolos em túnel passam despercebidos sem os logs de consulta DNS e linhas de base de conexão de rede.
  • Invisibilidade de violação de política: O tráfego que viola a segmentação de rede, acessa portas/protocolos não autorizados ou ignora as regras de firewall, permanecendo não monitorado, corroendo limites de zero trust.
  • Lacunas de conformidade: Os padrões regulatórios (PCI-DSS 10.8, NIST AU-12) exigem o registro e o monitoramento de atividades de rede— os logs ausentes criam descobertas de auditoria e riscos de certificação.
  • Falha na reconstrução de incidentes: A perícia pós-violação não pode determinar o IP de origem do invasor, caminhos de movimentação lateral ou rotas de exfiltração de dados sem fluxo de rede abrangente e logs de decisão de firewall.

MITRE ATT&CK

  • Comando &controle (TA0011): protocolo de camada de aplicativo (T1071) usando HTTP/HTTPS ou outros protocolos padrão para misturar o tráfego C2 com comunicações legítimas.
  • Comando & Controle (TA0011): DNS (T1071.004) utilizando consultas DNS para canais C2 ou túneis de exfiltração de dados.
  • Movimento Lateral (TA0008): serviços remotos (T1021) movendo-se entre sistemas usando PROTOCOLOS RDP, SSH ou protocolos de gerenciamento de nuvem.
  • Exfiltração (TA0010): exfiltração por canal C2 (T1041) transmitindo dados roubados através de conexões de comando e controle já estabelecidas.
  • Exfiltração (TA0010): exfiltração por protocolo alternativo (T1048) usando portas ou protocolos não padrão para evitar o monitoramento de saída.
  • Evasão de Defesa (TA0005): tunelamento de protocolo (T1572) encapsulando tráfego malicioso dentro de protocolos legítimos (DNS, HTTPS) para evitar a inspeção.

LT-4.1: habilitar o registro e o monitoramento de segurança de rede

Capture uma telemetria de tráfego de rede abrangente para detectar movimentação lateral, exfiltração de dados, comunicações de comando e controle e ataques de camada de aplicativo. Os logs de rede fornecem a trilha de evidências de como os invasores se movem entre sistemas, quais destinos externos eles entram em contato e quais técnicas de ataque empregam, essenciais para investigar violações sofisticadas de vários estágios. Habilite os seguintes recursos de log de rede:

  • Capturar logs de fluxo de rede: Habilite os logs de fluxo do NSG (grupo de segurança de rede) para capturar informações sobre o tráfego IP que flui por meio de NSGs, incluindo IPs de origem/destino, portas, protocolos e decisões de permissão/negação para detecção de movimento lateral.

  • Monitorar atividades do firewall: Habilite logs e métricas do Azure Firewall para observar a atividade do firewall, o processamento de regras, as ocorrências de inteligência de ameaças e os logs de proxy DNS, possibilitando um monitoramento centralizado de saída e detecção de ameaças.

  • Registrar ataques na camada de aplicação: Habilite os logs do WAF (Firewall de Aplicações Web) para capturar tentativas de ataque na camada de aplicação, incluindo injeção de SQL, cross-site scripting e violações do OWASP Top 10, juntamente com detalhes da solicitação e decisões de bloqueio.

  • Coletar dados de consulta DNS: Colete logs de consulta DNS para ajudar a correlacionar dados de rede e detectar ataques baseados em DNS, incluindo túnel, domínios DGA e comunicações de comando e controle.

  • Implantar monitoramento abrangente: Use soluções de monitoramento de rede do Azure no Azure Monitor para visibilidade de rede abrangente e correlação de log centralizada.

  • Habilite a análise de tráfego: Envie logs de fluxo para o workspace do Log Analytics do Azure Monitor e use a Análise de Tráfego para fornecer insights sobre padrões de tráfego de rede, ameaças à segurança, consumo de largura de banda e violações de política.

Exemplo de implementação

Desafio: Uma plataforma global de comércio eletrônico necessária para detectar movimentação lateral, exfiltração de dados e ataques de camada de aplicativo em toda a infraestrutura de várias regiões que protege o processamento de pagamentos e os sistemas de dados do cliente.

Abordagem da solução: Habilitou o registro em log de rede abrangente implantando logs de fluxo NSG com Análise de Tráfego em mais de 200 grupos de segurança de rede, configurou logs de diagnóstico de Firewall do Azure e WAF em pontos de saída centralizados e gateways de aplicativo, implementou a análise de DNS para detecção de C2 e integrou todos os logs de rede com SIEM para correlação com sinais de atividade de identidade e recurso.

Resultado: A análise de tráfego identificou violações de política (portas de gerenciamento expostas), os logs de WAF detectaram e bloquearam campanhas de injeção de SQL, e a análise de DNS sinalizou padrões de DGA, permitindo o rápido isolamento das máquinas virtuais. O registro em log de rede possibilita a detecção de padrões de movimentação lateral e tentativas de exfiltração de dados que teriam permanecido invisíveis sem uma análise abrangente de log de fluxo e firewall.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AU-2(1), AU-3(1), AU-6(1), AU-12(1), SI-4(2), SI-4(4), SI-4(5), SI-4(12)
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.1, 10.3.2, 11.4.1, 11.4.2
  • Controles CIS v8.1: 8.2, 8.5, 8.6, 8.11, 13.6
  • NIST CSF v2.0: DE. AE-3, DE. CM-1, DE. CM-4, DE. CM-6, DE. CM-7
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2

LT-5: centralizar o gerenciamento e a análise de logs de segurança

Azure Policy: Confira as definições de política internas do Azure: LT-5.

Princípio de segurança

Centralize logs de segurança de todos os serviços de nuvem, sistemas de identidade e infraestrutura de rede em uma plataforma unificada para correlação e análise. A agregação centralizada permite a detecção de ataques de vários estágios que abrangem vários serviços que fontes de log isoladas não podem revelar.

Risco a mitigar

Os logs distribuídos armazenados em diferentes serviços e regiões impedem a correlação de ataques em vários estágios e atrasam a detecção de incidentes. Sem a agregação de log centralizada e os recursos SIEM:

  • Invisibilidade de ataque em vários estágios: Cadeias de eliminação sofisticadas abrangendo identidade (ID do Microsoft Entra), rede (fluxos NSG) e dados (acesso ao armazenamento) permanecem não detectados porque silos de log isolados impedem a correlação entre serviços e a reconstrução da linha do tempo.
  • Fadiga e ruído de alerta: As equipes de segurança que se afogam em alertas não correlacionados de dezenas de serviços individuais perdem padrões críticos— incidentes de alta prioridade enterrados em milhares de falsos positivos sem contexto e priorização.
  • Detecção atrasada: A agregação e análise manual de logs estendem o tempo médio para detecção (MTTD) de minutos para dias—os invasores concluem ciclos de ataque completos (reconhecimento → execução → exfiltração) antes que os defensores consigam correlacionar as evidências.
  • Busca incompleta de ameaças: Os analistas de segurança não podem executar consultas proativas de busca de ameaças que abrangem vários serviços, intervalos de tempo e indicadores de ataque quando os logs permanecem espalhados entre interfaces específicas do serviço.
  • Falhas de auditoria de conformidade: Os requisitos regulatórios exigem o monitoramento e os relatórios de segurança centralizados— os logs distribuídos criam lacunas demonstradas na maturidade das operações de segurança e na preparação da auditoria.
  • Resposta a incidentes ineficiente: As equipes de IR gastam horas críticas alternando manualmente entre o Portal do Azure, o Log Analytics, logs específicos de serviços e ferramentas de terceiros em vez de fluxos de trabalho de investigação unificados.
  • Retenção e governança ineficazes: Políticas de retenção inconsistentes entre serviços resultam em evidências forenses críticas expirando antes da conclusão das investigações, e a falta de controles de acesso centralizados expõe logs confidenciais à exibição não autorizada.

Sem SIEM/SOAR centralizado, as organizações operam reativamente com visibilidade fragmentada, tempos de resposta prolongados e incapacidade de detectar ataques coordenados.

MITRE ATT&CK

  • Evasão de Defesa (TA0005): compromete as defesas (T1562) explorando a fragmentação de log para evitar a detecção baseada em correlação através de limites de serviço.
  • Descoberta (TA0007): descoberta de infraestrutura de nuvem (T1580) enumerando sistematicamente recursos em vários serviços — padrões visíveis somente por meio de análise centralizada.
  • Movimento Lateral (TA0008): uso de material de autenticação alternativa (T1550) para deslocamento entre serviços usando tokens ou credenciais — movimentação rastreável somente por meio da correlação de logs entre serviços.
  • Coleção (TA0009): dados em estágio (T1074.002) agregando dados de várias fontes antes da exfiltração — padrões de estágio detectáveis por meio da análise de anomalias de vários serviços.
  • Exfiltração (TA0010): exfiltração automatizada (T1020) usando extração distribuída em vários serviços para evitar limites de volume de serviço individuais— detectáveis somente por meio de análise agregada.

LT-5.1: Implementar agregação de log centralizada

Transforme logs fragmentados espalhados pelos serviços em visibilidade unificada roteando toda a telemetria de segurança para uma plataforma central. A agregação de log fornece a base para correlação entre serviços, permitindo a detecção de padrões de ataque que abrangem limites de infraestrutura, desde o comprometimento inicial até a movimentação lateral até a exfiltração de dados. Estabeleça uma coleção de logs centralizada:

  • Agregar registros centralmente: Integre os registros de atividades do Azure a um workspace centralizado do Log Analytics juntamente com registros de diagnóstico de recursos de todos os serviços para habilitar a correlação entre diferentes recursos e fluxos de trabalho de investigação unificados.

  • Consultar logs agregados: Use o Azure Monitor com consultas KQL para executar análises em logs agregados de serviços do Azure, dispositivos de endpoint, recursos de rede e outros sistemas de segurança para a detecção e investigação de padrões.

  • Configurar alertas: Crie regras de alerta usando os logs agregados de várias fontes para detectar ameaças de segurança e problemas operacionais por meio da lógica de correlação que abrange várias fontes de log.

  • Estabelecer governança de dados: Defina a propriedade de dados, implemente controles de acesso baseados em função em logs, especifique locais de armazenamento para requisitos de conformidade e defina políticas de retenção que equilibram as necessidades de investigação com obrigações de custo e regulamentação.

LT-5.2: implantar recursos SIEM e SOAR

Eleve a agregação de log em operações de segurança proativas implantando o SIEM (gerenciamento de eventos e informações de segurança) com recursos de resposta automatizados. O SIEM transforma logs brutos em inteligência acionável por meio de regras de correlação, análise de ameaças e fluxos de trabalho de incidentes automatizados, permitindo que as equipes de segurança detectem e respondam a ameaças na velocidade do computador, em vez de ritmo de investigação manual. Crie sua plataforma SIEM/SOAR:

  • Implantar a plataforma SIEM:Integrar o Microsoft Sentinel para fornecer recursos de SIEM (gerenciamento de eventos de informações de segurança) e SOAR (resposta automatizada de orquestração de segurança) para análise de segurança centralizada e resposta a incidentes.

  • Conectar fontes de dados: Conecte fontes de dados ao Microsoft Sentinel, incluindo serviços do Azure, Microsoft 365, soluções de segurança de terceiros e sistemas locais para estabelecer visibilidade de segurança abrangente.

  • Configurar regras de análise: Crie regras de detecção no Sentinel para identificar ameaças e criar incidentes automaticamente com base em eventos de segurança correlacionados que abrangem várias fontes de log e períodos de tempo.

  • Automatizar ações de resposta: Implemente guias estratégicos de resposta automatizados usando Aplicativos Lógicos para orquestrar ações de resposta a incidentes, incluindo fluxos de trabalho de contenção, notificação e correção.

  • Habilitar painéis de monitoramento: Implante pastas de trabalho e painéis do Sentinel para monitoramento de segurança, busca de ameaças, relatórios de conformidade e visibilidade da postura de segurança em nível executivo.

  • Integre a análise de IA: Habilite a integração do Microsoft Security Copilot ao Sentinel para fornecer recomendações de investigação de incidentes, busca de ameaças e resposta guiada por IA usando consultas de linguagem natural em logs de segurança centralizados.

Exemplo de implementação

Desafio: Uma seguradora multinacional precisava de recursos unificados de detecção e investigação de ameaças em 12 assinaturas do Azure, mais de 500 recursos e 4 regiões geográficas processando dados pessoais e declarações do segurado.

Abordagem da solução: Implantado o workspace centralizado do Log Analytics com configurações de diagnóstico no nível do grupo de gerenciamento roteando todos os logs de atividades do Azure, telemetria de identidade e logs de recursos críticos (Armazenamento, SQL, Key Vault, Firewall). Habilitado o Microsoft Sentinel SIEM com conectores de dados para Defender para Nuvem, Proteção contra IDs do Entra, Microsoft 365 Defender e Defender Inteligência contra Ameaças. Regras de análises configuradas para ameaças específicas de seguro (exportação de declarações em massa, anomalias de acesso privilegiado, ataques em vários estágios), playbooks de resposta automatizados para fluxos de trabalho de contenção e Security Copilot integrado para capacidades de investigação em linguagem natural. Cadernos de conformidade estabelecidos mapeando os requisitos HIPAA, PCI-DSS e SOC 2 para a telemetria do Sentinel.

Resultado: O Sentinel detectou campanhas de recheio de credenciais por meio de correlação entre assinaturas e identificou o movimento lateral entre regiões geográficas em poucos minutos. O Security Copilot permitiu que analistas de camada 1 conduzissem investigações sofisticadas usando consultas de linguagem natural sem a necessidade de experiência avançada em linguagem de consulta. O SIEM centralizado reduziu substancialmente o tempo médio para detectar e investigar incidentes de segurança em toda a infraestrutura global.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AU-2(1), AU-3(1), AU-6(1), AU-6(3), AU-6(5), AU-7(1), AU-12(1), SI-4(1), SI-4(2), SI-4(5), SI-4(12)
  • PCI-DSS v4: 10.4.1, 10.4.2, 10.4.3, 10.7.1, 10.7.2, 10.7.3
  • Controles CIS v8.1: 8.9, 8.11, 13.1, 13.3, 13.4, 17.1
  • NIST CSF v2.0: DE.AE-2, DE.AE-3, DE.CM-1, DE.CM-4, DE.CM-6, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16, A.5.25
  • SOC 2: CC7.2, CC7.3

LT-6: Configurar a retenção de armazenamento de log

Azure Policy: Confira as definições de política internas do Azure: LT-6.

Princípio de segurança

Configure os períodos de retenção de log alinhados aos requisitos regulatórios, aos mandatos de conformidade e aos prazos de investigação. Balancee os requisitos de preservação de evidências forenses em relação aos custos de armazenamento por meio de estratégias de retenção em camadas.

Risco a mitigar

Políticas de retenção de log insuficientes ou inconsistentes destroem evidências forenses antes que as investigações concluam e criem lacunas de conformidade. Sem retenção disciplinada alinhada com requisitos regulatórios e operacionais:

  • Expiração da evidência: Dados forenses críticos (logs de autenticação, padrões de acesso, fluxos de rede) expiram antes que as equipes de segurança descubram violações — o tempo médio de espera de mais de 200 dias significa que os logs devem persistir tempo suficiente para investigar o comprometimento histórico.
  • Violações de conformidade: Os mandatos regulatórios (PCI-DSS 10,7: 1 ano, RGPD: varia de acordo com a jurisdição, HIPAA: 6 anos) exigem períodos de retenção específicos– a retenção inadequada cria descobertas de auditoria, falhas de certificação e penalidades regulatórias.
  • Reconstrução de incidente incompleta: A correlação histórica de indicadores ao longo de linhas do tempo estendidas de violação torna-se impossível quando os logs expiram prematuramente, impedindo a análise completa da cadeia de ataque e a determinação da causa raiz.
  • Lacunas na descoberta legal: Litígios, investigações regulatórias e auditorias internas exigem a produção de logs de segurança históricos — a ausência desses logs cria risco legal e impossibilidade de defender as práticas organizacionais.
  • Cegueira de análise de padrão: Modelos de machine learning e linhas de base comportamentais necessitam de dados de treinamento históricos—uma retenção curta dificulta a identificação de ataques lentos, padrões sazonais ou análise de tendência de longo prazo.
  • Excedentes de custos: A falta de estratégia de hierarquização de retenção (armazenamento quente e frio) leva à retenção cara do Log Analytics para necessidades de arquivamento de longo prazo melhor atendidas pelo Armazenamento do Azure—inflando os custos operacionais, desnecessariamente.
  • Desvio da política de retenção: A retenção inconsistente entre serviços (90 dias para Logs de Atividades, 30 dias para Logs de Recursos, indefinida para alguns serviços) cria pontos cegos investigativos e cobertura forense imprevisível.

A retenção inadequada transforma violações de longa duração em incidentes impossíveis de investigar ao criar exposição regulatória e legal.

MITRE ATT&CK

  • Evasão de Defesa (TA0005): remoção de indicadores (T1070) por atacantes aproveitando janelas de retenção curtas para garantir que as evidências expirem naturalmente sem a necessidade de exclusão ativa dos logs.
  • Persistência (TA0003): manipulação de conta (T1098) estabelecendo acesso persistente via backdoor com confiança de que as evidências de comprometimento iniciais envelhecerão antes da detecção.

LT-6.1: implementar a estratégia de retenção de log

Balancee as necessidades de preservação forense com os custos de armazenamento implementando estratégias de retenção em camadas alinhadas a mandatos regulatórios e linhas do tempo de investigação. Diferentes tipos de log exigem diferentes períodos de retenção — armazenamento frequente para investigações ativas, armazenamento quente para histórico recente e arquivamento a frio para conformidade de longo prazo — otimizando a capacidade de investigação e os custos operacionais. Configure a seguinte estratégia de retenção:

  • Rotear logs para o armazenamento apropriado: Crie configurações de diagnóstico para rotear logs de atividade do Azure e outros logs de recursos para locais de armazenamento adequados com base em requisitos de retenção, mandatos de conformidade e cronogramas de investigação, equilibrando os custos de armazenamento quente versus frio.

  • Configurar a retenção de curto a médio prazo: Use a Área de trabalho do Azure Monitor Log Analytics para retenção de logs de até 1 a 2 anos para investigação ativa, caça a ameaças e análise operacional, com funcionalidades de consulta KQL.

  • Implementar o armazenamento arquivístico de longo prazo: Use o Armazenamento do Azure, o Data Explorer ou o Data Lake para armazenamento de longo prazo e arquivamento além de 1 a 2 anos, para atender aos requisitos de conformidade (PCI-DSS, SEC 17a-4, HIPAA) com redução significativa de custos por meio de camadas frias/arquivos.

  • Encaminhar logs externamente: Use os Hubs de Eventos do Azure para encaminhar logs para SIEM externos, data lake ou sistemas de segurança de terceiros fora do Azure, quando necessário para garantir visibilidade em múltiplas nuvens ou para integrações legadas.

  • Configurar a retenção da conta de armazenamento: Configure políticas de retenção para logs de conta do Armazenamento do Azure com base nos requisitos de conformidade, implementando o gerenciamento do ciclo de vida para transições e exclusões automáticas de camada.

  • Retenção dos logs do Microsoft Sentinel: Implemente uma estratégia de armazenamento de longo prazo para logs do Microsoft Sentinel, pois o Sentinel utiliza o espaço de trabalho do Log Analytics como sua plataforma de apoio, exigindo uma configuração explícita de arquivamento para retenção estendida além dos limites do espaço de trabalho.

  • Arquivar alertas de segurança: Configure a exportação contínua para alertas e recomendações do Microsoft Defender para Nuvem para atender aos requisitos de retenção, já que os dados do Defender para Nuvem têm retenção limitada no portal nativo.

Exemplo de implementação

Desafio: Uma organização de serviços financeiros regulamentada precisava atender a vários requisitos de retenção (PCI-DSS: 1 ano, SEC 17a-4: 7 anos) enquanto gerenciava 80 TB de dados de log de segurança anuais de forma econômica.

Abordagem da solução: Estratégia de retenção de log em camadas implementada configurando o espaço de trabalho do Log Analytics com retenção padrão de 1 ano e sobrescrições no nível da tabela (logs de identidade: 2 anos, fluxos de rede: 90 dias), exportação de todos os logs para contas de Armazenamento do Azure com políticas de gerenciamento de ciclo de vida (hot→frio em 90 dias, frio→arquivo em 1 ano) e configurando armazenamento imutável (WORM) em contas de armazenamento críticas para conformidade. O Azure Policy implantado impôs a consistência nas configurações de diagnóstico e retenção, foram criados pacotes de consulta do Log Analytics para relatórios automatizados de conformidade, e estabeleceu-se um processo de retenção legal para a preservação de dados forenses durante incidentes ativos.

Resultado: Atingiu a conformidade completa da trilha de auditoria para requisitos de PCI-DSS e SEC 17a-4, reduzindo substancialmente os custos de armazenamento de log por meio da estratégia de armazenamento em camadas. Investigar com êxito incidentes de segurança históricos usando logs arquivados além das capacidades de retenção anteriores e simplificar as auditorias de conformidade trimestrais através de consultas automatizadas para coleta de evidências e verificação de retenção.

Nível de criticidade

Deveria ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AU-11(1), SI-12
  • PCI-DSS v4: 10.5.1, 10.7.1, 10.7.2, 10.7.3
  • Controles CIS v8.1: 8.3, 8.10
  • NIST CSF v2.0: PR. PT-1, DE. CM-1
  • ISO 27001:2022: A.8.15
  • SOC 2: CC7.2

LT-7: Usar fontes de sincronização de tempo aprovadas

Princípio de segurança

Sincronize todos os sistemas com fontes de tempo autoritativas para manter carimbos de data/hora precisos nos logs de segurança. A sincronização de tempo consistente permite correlação de log confiável, reconstrução da linha do tempo de incidentes e análise forense.

Risco a mitigar

O tempo preciso e sincronizado em todos os sistemas é fundamental para a correlação de log, análise forense e reconstrução da linha do tempo do incidente. Sem sincronização de tempo consistente:

  • Corrupção da linha do tempo forense: A reconstrução de incidentes torna-se impossível quando logs de fontes diferentes mostram carimbos de data/hora conflitantes— os investigadores não podem determinar a sequência de ataques ou correlacionar eventos entre sistemas (logs de VM mostrando ataque às 10h00, logs de firewall mostrando o mesmo evento às 9h45).
  • Falha de correlação do SIEM: A análise de segurança e as regras de correlação falham quando o descompasso de tempo faz com que os eventos cheguem fora de ordem, resultando em detecções perdidas, já que a lógica das regras espera sequências cronológicas dos eventos.
  • Oportunidades de bypass de autenticação: Mecanismos de autenticação baseados em tempo (tíquetes Kerberos, tokens JWT, códigos OTP) tornam-se exploráveis quando a distorção do relógio permite ataques de reprodução ou estende janelas de validade do token.
  • Falhas de auditoria de conformidade: Estruturas regulatórias (PCI-DSS 10.4, SOC 2, HIPAA) exigem sincronização precisa de tempo para integridade da trilha de auditoria — o descompasso de tempo cria descobertas de auditoria e questiona a confiabilidade das evidências.
  • Alertas falsos positivos/negativos: A detecção de anomalias e a análise comportamental geram alertas incorretos quando a descompasso de tempo faz com que atividades normais apareçam fora das janelas de tempo esperadas ou padrões suspeitos pareçam benignos.
  • Erros de validação de certificado: As verificações de validade do certificado SSL/TLS falham ou são bem-sucedidas incorretamente quando os relógios do sistema se descompassam fora das janelas NotBefore/NotAfter do certificado, causando interrupções no serviço ou permitindo a violação das medidas de segurança.
  • Erros de retenção de log: As políticas de retenção baseadas na avaliação do carimbo de data/hora (excluir logs com mais de 365 dias) são executadas incorretamente com desvio temporal, excluindo evidências prematuramente ou retendo logs por mais tempo do que o permitido pelos limites da política.

Falhas de sincronização de tempo minam a integridade probatória de todo o registro em log e monitoramento de segurança, tornando a análise forense inconclusiva e não confiável.

MITRE ATT&CK

  • Evasão de Defesa (TA0005): remoção de indicador (T1070) manipulando timestamps para ocultar atividades maliciosas dentro de janelas de tempo legítimas ou fazer com que as evidências apareçam fora do escopo da investigação.

LT-7.1: Configurar a sincronização de tempo seguro

Garanta timestamps precisos e consistentes em todos os sistemas para permitir a correlação confiável de logs e a reconstrução do cronograma de incidentes. A sincronização de relógio é fundamental para a integridade forense– até mesmo um pequeno desvio de relógio pode corromper as linhas do tempo de investigação, causar falhas na correlação do SIEM e criar problemas em auditorias de conformidade. Configure todos os sistemas para usar fontes de tempo confiáveis e monitorar a deriva continuamente. Implemente estas práticas de sincronização de tempo:

  • Configurar a sincronização de tempo do Windows: Use servidores NTP padrão da Microsoft para sincronização de tempo em recursos de computação do Windows do Azure aproveitando fontes de tempo de host do Azure por meio de serviços de integração de virtualização, a menos que requisitos específicos determinem o contrário.

  • Configurar a sincronização de tempo do Linux: Configure a sincronização de tempo para recursos de computação do Azure Linux usando chrony ou ntpd com fontes NTP fornecidas pelo Azure ou servidores NTP externos apropriados.

  • Proteger servidores NTP personalizados: Se estiver implantando servidores NTP (protocolo de tempo de rede) personalizados, proteja a porta de serviço UDP 123 e implemente controles de acesso restringindo consultas de serviço de tempo somente para clientes autorizados.

  • Validar formatos de carimbo de data/hora: Verifique se todos os logs gerados pelos recursos do Azure incluem carimbos de data/hora com informações de fuso horário (preferencialmente UTC) por padrão para habilitar a reconstrução de linha do tempo inequívoca entre implantações globais.

  • Monitorar o descompasso de tempo: Implemente o monitoramento contínuo de descompasso de tempo entre sistemas e configure alertas para problemas significativos de sincronização (>5 segundos) que podem afetar a correlação de log, a análise forense e os mecanismos de autenticação baseados em tempo.

Exemplo de implementação

Desafio: Uma organização de varejo global precisava de integridade forense da linha do tempo em toda a infraestrutura híbrida, abrangendo 2.500 lojas (sistemas locais de ponto de venda, back-end de POS na nuvem do Azure, processamento de pagamento) para conformidade com PCI-DSS e investigação de fraude.

Abordagem da solução: Configuração da sincronização abrangente de tempo, verificando a sincronização automática via NTP dos serviços PaaS do Azure, configurando VMs do Azure (Windows/Linux) para usar fontes de tempo dos hosts do Azure e implementando alertas do Azure Monitor para desvios de tempo superiores a >5 segundos. Consultas implantadas do Log Analytics detectando anomalias de carimbo de data/hora entre fontes de log correlacionadas e runbooks de correção automatizados forçando a ressincronização do tempo em VMs afetadas. Auditorias trimestrais de sincronização de tempo estabelecidas validando a configuração do NTP e a consistência dos carimbos de data/hora entre logs de rede, identidade e aplicativo.

Resultado: Atingiu à conformidade com os requisitos de sincronização de tempo do PCI-DSS e correlacionou com sucesso as investigações de fraude em fontes de log híbridas, com precisão consistente de carimbo de data/hora, permitindo a reconstrução precisa dos incidentes. O monitoramento e a correção automatizados de descompasso de tempo eliminaram alertas de segurança falsos positivos causados por eventos fora de ordem e garantiram a integridade da linha do tempo forense em toda a infraestrutura distribuída globalmente.

Nível de criticidade

Deveria ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AU-8(1), AU-8(2)
  • PCI-DSS v4: 10.6.1, 10.6.2, 10.6.3
  • Controles CIS v8.1: 8.4
  • NIST CSF v2.0: DE. CM-1, PR. PT-1
  • ISO 27001:2022: A.8.15
  • SOC 2: CC7.2
  • Last updated on