Registrar planos de retenção no Microsoft Sentinel

Há dois aspetos concorrentes da coleta e retenção de logs que são essenciais para um programa de deteção de ameaças bem-sucedido. Por um lado, você deseja maximizar o número de fontes de log coletadas, para que tenha a cobertura de segurança mais abrangente possível. Por outro lado, você precisa minimizar os custos incorridos pela ingestão de todos esses dados.

Essas necessidades concorrentes exigem uma estratégia de gerenciamento de logs que equilibre a acessibilidade dos dados, o desempenho da consulta e os custos de armazenamento.

Este artigo discute as categorias de dados e os estados de retenção usados para armazenar e acessar seus dados. Ele também descreve os planos de log que o Microsoft Sentinel oferece para criar uma estratégia de gerenciamento e retenção de logs.

Categorias de dados ingeridos

A Microsoft recomenda classificar os dados ingeridos no Microsoft Sentinel em duas categorias gerais:

• Os principais dados de segurança são dados que contêm valor crítico de segurança. Esses dados são usados para monitoramento proativo em tempo real, alertas agendados e análises para detetar ameaças à segurança. Os dados precisam estar prontamente disponíveis para todas as experiências do Microsoft Sentinel quase em tempo real.

• Os dados de segurança secundários são dados suplementares, geralmente em logs detalhados de alto volume. Esses dados têm um valor de segurança limitado, mas podem fornecer riqueza e contexto adicionais para deteções e investigações, ajudando a desenhar a imagem completa de um incidente de segurança. Não precisa estar prontamente disponível, mas deve ser acessível sob demanda, conforme necessário e em doses adequadas.

Dados de segurança primários

Esta categoria consiste em logs que contêm valor de segurança crítico para sua organização. Os principais dados de segurança podem ser descritos pelos seguintes casos de uso para operações de segurança:

• Monitorização frequente. As regras de deteção de ameaças (análises) são executadas nesses dados em intervalos frequentes ou quase em tempo real.

• Caça sob demanda. Consultas complexas são executadas nesses dados para executar buscas interativas e de alto desempenho para ameaças à segurança.

• Correlação. Os dados dessas fontes são correlacionados com dados de outras fontes de dados de segurança primárias para detetar ameaças e criar histórias de ataque.

• Apresentação regular de relatórios. Os dados dessas fontes estão prontamente disponíveis para serem compilados em relatórios regulares da integridade da segurança da organização, tanto para os tomadores de decisão de segurança quanto para os tomadores de decisão em geral.

• Análise de comportamento. Os dados dessas fontes são usados para criar perfis de comportamento de linha de base para seus usuários e dispositivos, permitindo que você identifique comportamentos periféricos como suspeitos.

Alguns exemplos de fontes de dados primárias incluem logs de antivírus ou sistemas de deteção e resposta empresariais (EDR), logs de autenticação, trilhas de auditoria de plataformas de nuvem, feeds de inteligência de ameaças e alertas de sistemas externos.

Os logs que contêm dados de segurança primários devem ser armazenados usando o plano de logs do Google Analytics descrito posteriormente neste artigo.

Dados de segurança secundários

Esta categoria abrange logs cujo valor de segurança individual é limitado, mas são essenciais para fornecer uma visão abrangente de um incidente ou violação de segurança. Normalmente, esses logs são de alto volume e podem ser detalhados. Os casos de uso de operações de segurança para esses dados incluem o seguinte:

• Informações sobre ameaças. Os dados primários podem ser verificados em relação a listas de Indicadores de Compromisso (IoC) ou Indicadores de Ataque (IoA) para detetar ameaças de forma rápida e fácil.

• Caça/investigações ad hoc. Os dados podem ser consultados interativamente durante 30 dias, facilitando análises cruciais para a caça a ameaças e investigações.

• Pesquisas em larga escala. Os dados podem ser ingeridos e pesquisados em segundo plano em escala de petabytes, enquanto são armazenados de forma eficiente com processamento mínimo.

• Sumarização através de regras sumárias. Resuma logs de alto volume em informações agregadas e armazene os resultados como dados de segurança primários. Para saber mais sobre regras de resumo, consulte Agregar dados do Microsoft Sentinel com regras de resumo.

Alguns exemplos de fontes de log de dados secundárias são logs de acesso ao armazenamento em nuvem, logs do NetFlow, logs de certificado TLS/SSL, logs de firewall, logs de proxy e logs de IoT. Para saber mais sobre como cada uma dessas fontes agrega valor às deteções de segurança sem ser necessária o tempo todo, consulte Fontes de log a serem usadas para ingestão de logs auxiliares.

Os logs que contêm dados de segurança secundários devem ser armazenados usando o plano de logs auxiliares (agora em Visualização) descrito posteriormente neste artigo.

Para uma opção que não seja de visualização, você pode usar logs básicos .

Planos de gestão de registos

O Microsoft Sentinel fornece dois planos ou tipos diferentes de armazenamento de log para acomodar essas categorias de dados ingeridos.

• O plano de logs do Google Analytics foi projetado para armazenar dados de segurança primários e torná-los acessíveis de forma fácil e constante com alto desempenho.

• O plano de logs auxiliares foi projetado para armazenar dados de segurança secundários a um custo muito baixo por longos períodos de tempo, enquanto ainda permite acessibilidade limitada.

• Um terceiro plano, Logs básicos, é o antecessor do plano de logs auxiliares e pode ser usado como um substituto para ele enquanto o plano de logs auxiliares permanece em visualização.

Cada um desses planos preserva dados em dois estados diferentes:

• O estado de retenção interativo é o estado inicial no qual os dados são ingeridos. Este estado permite diferentes níveis de acesso aos dados, dependendo do plano, e os custos para este estado variam muito, dependendo do plano.

• O estado de retenção de longo prazo preserva os dados mais antigos em suas tabelas originais por até 12 anos, a um custo extremamente baixo, independentemente do plano.

Para saber mais sobre estados de retenção, consulte Gerenciar retenção de dados em um espaço de trabalho do Log Analytics.

O diagrama a seguir resume e compara esses dois planos de gerenciamento de log.

Plano de logs do Google Analytics

O plano de logs do Google Analytics mantém os dados no estado de retenção interativo por padrão por 90 dias , extensível por até dois anos. Este estado interativo, embora caro, permite que você consulte seus dados de forma ilimitada, com alto desempenho, sem nenhum custo por consulta.

Quando o período de retenção interativo termina, os dados entram no estado de retenção de longo prazo, permanecendo em sua tabela original. O período de retenção de longo prazo não é definido por padrão, mas você pode defini-lo para durar até 12 anos. Este estado de retenção preserva os seus dados a um custo extremamente baixo, para fins de conformidade regulamentar ou política interna. Você pode acessar os dados nesse estado somente usando um trabalho de pesquisa ou restauração para extrair conjuntos limitados de dados em uma nova tabela na retenção interativa, onde você pode usar todos os recursos de consulta para isso.

Plano de logs auxiliares

O plano de logs auxiliares mantém os dados no estado de retenção interativo por 30 dias. No plano Auxiliar, esse estado tem custos de retenção muito baixos em comparação com o plano do Google Analytics. No entanto, os recursos de consulta são limitados: as consultas são cobradas por gigabyte de dados digitalizados e são limitadas a uma única tabela, e o desempenho é significativamente menor. Enquanto esses dados permanecem no estado de retenção interativo, você pode executar regras de resumo nesses dados para criar tabelas de dados agregados e resumidos no plano de logs do Google Analytics, para que você tenha todos os recursos de consulta nesses dados agregados.

Quando o período de retenção interativo termina, os dados entram no estado de retenção de longo prazo, permanecendo em sua tabela original. A retenção de longo prazo no plano de logs auxiliares é semelhante à retenção de longo prazo no plano de logs de análise, exceto que a única opção para acessar os dados é com um trabalho de pesquisa. A restauração não é suportada para o plano de logs auxiliares.

Plano básico de logs

Um terceiro plano, conhecido como logs básicos, fornece funcionalidade semelhante ao plano de logs auxiliares, mas com um custo de retenção interativo mais alto (embora não tão alto quanto o plano de logs de análise). Embora o plano de logs auxiliares permaneça em visualização, os logs básicos podem ser uma opção para retenção de longo prazo e de baixo custo se sua organização não usar recursos de visualização. Para saber mais sobre o plano de logs básico, consulte Planos de tabela na documentação do Azure Monitor.

Conteúdos relacionados

• Para obter uma comparação mais aprofundada de planos de dados de log e informações mais gerais sobre tipos de log, consulte Visão geral de logs do Azure Monitor | Planos de mesa.

• Para configurar uma tabela no plano Logs auxiliares, consulte Configurar uma tabela com o plano Auxiliar no espaço de trabalho do Log Analytics (Visualização).

• Para entender mais sobre os períodos de retenção, que existem em todos os planos, consulte Gerenciar a retenção de dados em um espaço de trabalho do Log Analytics.