A segurança da informação não se limita a prevenir ataques; é fundamental também detectá-los e responder rapidamente. Logs são registros de eventos que ocorrem em sistemas, aplicações e redes, e quando bem gerenciados, tornam-se uma fonte rica de evidências para investigações e para a identificação de comportamentos suspeitos. Monitorar esses logs de forma contínua permite que uma organização perceba atividades anômalas antes que causem danos significativos.

Nesta aula, vamos explorar os pilares de uma estratégia eficaz de segurança de logs: centralização, retenção, alertas e detecção de anomalias. Cada um desses componentes desempenha um papel crucial para transformar dados brutos em inteligência acionável. Ao final, você terá uma visão clara de como construir um sistema de monitoramento que fortaleça a postura de segurança da sua infraestrutura.

Centralização

Centralizar logs significa consolidar os registros de todas as fontes (servidores, firewalls, aplicações, bancos de dados, etc.) em um único local. Isso é essencial porque, em um incidente, a correlação de eventos de diferentes sistemas é necessária para reconstruir a cronologia do ataque. Sem centralização, cada sistema possui seus próprios logs, dificultando a análise e atrasando a resposta.

Ferramentas como ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Graylog ou serviços gerenciados (AWS CloudWatch, Azure Monitor) facilitam a coleta e indexação de logs. A centralização também permite a aplicação de políticas uniformes de acesso e segurança sobre os logs, garantindo que apenas pessoas autorizadas possam visualizá-los ou modificá-los.

Um exemplo típico de configuração é o uso do syslog para enviar logs de diversos dispositivos para um servidor central. No Linux, isso pode ser feito configurando o rsyslog:

# No servidor central (ex.: /etc/rsyslog.conf)
module(load="imudp")
input(type="imudp" port="514")

# Nos clientes (ex.: /etc/rsyslog.d/50-default.conf)
*.* @central-server:514

Essa configuração envia todos os logs do cliente para o servidor central via UDP. Para maior confiabilidade, pode-se usar TCP ou TLS. Além disso, é importante garantir que os logs sejam enviados de forma contínua e que haja mecanismos de buffer para evitar perdas em caso de falha de rede.

Retenção

Retenção de logs refere-se ao período de tempo que os logs são mantidos armazenados. Esse período deve ser definido com base em requisitos legais, regulatórios e de negócio. Por exemplo, normas como a PCI-DSS exigem retenção mínima de um ano para logs de auditoria. Além disso, em investigações de incidentes, logs históricos podem ser cruciais para entender a extensão de um ataque.

No entanto, armazenar logs por muito tempo gera custos e complexidade. Portanto, é comum adotar uma política de retenção em camadas: logs quentes (acessados frequentemente) podem ser mantidos por alguns dias ou semanas em armazenamento rápido; logs mornos por alguns meses em armazenamento intermediário; e logs frios por anos em arquivamento de baixo custo. Ferramentas de gerenciamento de logs oferecem funcionalidades de lifecycle para automatizar essa transição.

Um exemplo prático de configuração de retenção no Elasticsearch é definir um índice com política de lifecycle:

PUT _ilm/policy/logs-retention-policy
{
  "policy": {
    "phases": {
      "hot": { "min_age": "0ms", "actions": {} },
      "delete": { "min_age": "30d", "actions": { "delete": {} } }
    }
  }
}

Nesse exemplo, os logs são mantidos por 30 dias e depois excluídos automaticamente. Ajuste conforme sua necessidade. Lembre-se de que a retenção deve ser documentada e revisada periodicamente.

Alertas

Alertas são notificações automáticas disparadas quando determinadas condições são detectadas nos logs. Eles permitem que a equipe de segurança seja acionada imediatamente diante de eventos críticos, como múltiplas tentativas de login falhas, acesso a arquivos sensíveis, ou execução de comandos suspeitos. Alertas eficazes reduzem o tempo de resposta e minimizam o impacto de possíveis incidentes.

Para configurar alertas, é necessário definir regras baseadas em padrões ou thresholds. Ferramentas como Wazuh, Suricata ou o Elastic Alerting permitem criar regras customizadas. Por exemplo, no Elasticsearch, podemos criar uma regra que alerta quando houver mais de 10 falhas de autenticação em 5 minutos:

PUT _watcher/watch/failed-logins
{
  "trigger": {
    "schedule": { "interval": "5m" }
  },
  "input": {
    "search": {
      "request": {
        "indices": ["logs-*"],
        "body": {
          "query": {
            "bool": {
              "filter": [
                { "term": { "event.type": "authentication_failure" } }
              ]
            }
          }
        }
      }
    }
  },
  "condition": {
    "compare": { "ctx.payload.hits.total": { "gt": 10 } }
  },
  "actions": {
    "email": {
      "email": {
        "to": "security@example.com",
        "subject": "Múltiplas falhas de login",
        "body": "Detectadas {{ctx.payload.hits.total}} falhas de autenticação nos últimos 5 minutos."
      }
    }
  }
}

Além de alertas reativos, é importante criar alertas proativos, como monitoramento de disponibilidade de serviços críticos ou detecção de tráfego incomum. A definição de alertas deve ser iterativa: comece com os casos mais óbvios e refine com base em incidentes reais e feedback da equipe.

Anomalias

Anomalias são padrões que se desviam do comportamento esperado do sistema. Elas podem ser tão simples quanto um pico de tráfego em horário incomum ou tão complexas quanto a exfiltração de dados em pequenos pacotes ao longo do tempo. A detecção de anomalias é uma técnica avançada que complementa os alertas baseados em regras, pois consegue identificar ataques desconhecidos ou variações sutis.

Existem duas abordagens principais: detecção baseada em estatísticas (como média e desvio padrão) e técnicas de aprendizado de máquina (como clustering ou redes neurais). Ferramentas como o Elastic ML (Machine Learning) ou o Prelude podem ser usadas para criar modelos de comportamento normal e alertar quando houver desvios significativos.

Um exemplo simples de análise estatística em Python para detectar anomalias em uma série temporal de requisições:

import numpy as np
import pandas as pd

def detect_anomalies(data, threshold=3):
    mean = np.mean(data)
    std = np.std(data)
    anomalies = []
    for i, value in enumerate(data):
        z_score = (value - mean) / std
        if abs(z_score) > threshold:
            anomalies.append((i, value))
    return anomalies

# Exemplo de uso
requests = [100, 120, 110, 130, 115, 125, 140, 500, 105, 118]
anomalies = detect_anomalies(requests)
print("Anomalias detectadas:", anomalies)  # Saída: [(7, 500)]

Na prática, a detecção de anomalias deve ser calibrada para reduzir falsos positivos, que podem sobrecarregar a equipe. É recomendável combinar várias técnicas e manter um processo de revisão contínua dos modelos.

Boas Práticas e Observações Finais

Para implementar uma estratégia robusta de segurança de logs, considere as seguintes boas práticas:

  • Proteja os logs: os logs podem conter informações sensíveis e devem ser criptografados tanto em trânsito quanto em repouso. Controle o acesso com base no princípio do menor privilégio.
  • Use formatos padronizados: adote formatos como JSON ou CEF para facilitar o parsing e a correlação.
  • Monitore a integridade: implemente mecanismos para detectar alterações ou exclusões não autorizadas nos logs (ex.: WORM storage, assinaturas digitais).
  • Documente tudo: mantenha documentação clara sobre fontes de logs, políticas de retenção, regras de alerta e procedimentos de resposta.
  • Revise regularmente: a segurança é dinâmica; revise e atualize suas regras e modelos periodicamente.

Em resumo, a segurança de logs e monitoramento é uma disciplina contínua que exige planejamento, ferramentas adequadas e uma equipe preparada para agir. Os pilares apresentados — centralização, retenção, alertas e anomalias — formam a base para uma observabilidade eficaz, permitindo que sua organização detecte e responda a ameaças com agilidade.

Referências

Exercícios

  1. Explique por que a centralização de logs é importante para a segurança da informação. Dê um exemplo de um cenário em que a ausência de centralização dificultaria a investigação de um incidente.

    ✓ Resposta: A centralização permite correlacionar eventos de diferentes fontes, reconstruir a cronologia de um ataque e aplicar políticas uniformes de acesso e retenção. Sem ela, a análise de um incidente que envolve múltiplos sistemas (ex.: um ataque que começa em um servidor web e depois se move para um banco de dados) exigiria acesso manual a cada sistema, atrasando a resposta e aumentando o risco de perder evidências. Por exemplo, se um invasor explora uma vulnerabilidade em um servidor web, depois usa credenciais roubadas para acessar um servidor de banco de dados, sem logs centralizados você precisaria acessar ambos os servidores separadamente e manualmente correlacionar os horários, o que é lento e propenso a erros.

  2. Quais são os fatores a considerar ao definir uma política de retenção de logs? Descreva uma política de retenção em camadas e justifique sua necessidade.

    ✓ Resposta: Fatores: requisitos legais/regulatórios (ex.: PCI-DSS exige 1 ano), necessidades de investigação, custos de armazenamento, e disponibilidade de acesso. Uma política em camadas envolve: logs quentes (armazenamento rápido, acesso frequente, retidos por dias/semanas), logs mornos (armazenamento intermediário, acesso ocasional, retidos por meses), e logs frios (arquivamento barato, acesso raro, retidos por anos). Isso equilibra custo e desempenho, garantindo que logs recentes sejam rapidamente consultáveis e logs antigos ainda estejam disponíveis para conformidade ou investigações históricas.

  3. Escreva uma regra de alerta (em texto ou em uma ferramenta que você conheça) que detecte mais de 5 tentativas de login falhas em um período de 1 minuto. Explique como você configuraria isso em uma ferramenta de sua escolha.

    ✓ Resposta: Exemplo com Elastic Watcher (JSON): 
    PUT _watcher/watch/failed-logins-1min
{
  "trigger": {
    "schedule": { "interval": "1m" }
  },
  "input": {
    "search": {
      "request": {
        "indices": ["logs-*"],
        "body": {
          "query": {
            "bool": {
              "filter": [
                { "term": { "event.type": "authentication_failure" } }
              ]
            }
          }
        }
      }
    }
  },
  "condition": {
    "compare": { "ctx.payload.hits.total": { "gt": 5 } }
  },
  "actions": {
    "email": {
      "email": {
        "to": "security@example.com",
        "subject": "Múltiplas falhas de login em 1 minuto",
        "body": "Foram detectadas {{ctx.payload.hits.total}} falhas de autenticação no último minuto."
      }
    }
  }
}
    Essa regra verifica a cada minuto se o número de eventos de falha de autenticação nos índices de logs é maior que 5; se sim, envia um e-mail. Em outras ferramentas, como Splunk, você usaria uma pesquisa programada com condição de alerta.

  4. Diferencie detecção de anomalias baseada em estatísticas da baseada em aprendizado de máquina. Cite uma vantagem e uma desvantagem de cada abordagem.

    ✓ Resposta: A detecção estatística usa métricas como média, desvio padrão, ou z-score para identificar desvios do comportamento histórico. Vantagem: simples de implementar e interpretar. Desvantagem: pode gerar muitos falsos positivos se o comportamento normal variar muito. A detecção por aprendizado de máquina treina modelos em dados históricos para reconhecer padrões normais e detectar outliers. Vantagem: pode capturar padrões complexos e não lineares, adaptando-se a mudanças. Desvantagem: requer grandes volumes de dados e expertise para treinar e ajustar, além de ser mais difícil de interpretar.

  5. Considere a seguinte sequência de requisições por minuto a um servidor web: [120, 130, 125, 128, 135, 132, 140, 300, 128, 130]. Calcule o z-score do valor 300 e determine se ele é uma anomalia com um limiar de 2. Mostre os cálculos.

    ✓ Resposta: Média = (120+130+125+128+135+132+140+300+128+130) / 10 = 1468/10 = 146.8 Desvio padrão (populacional) = sqrt( (Σ(x_i - média)²) / N ) Calculando as diferenças: (-26.8, -16.8, -21.8, -18.8, -11.8, -14.8, -6.8, 153.2, -18.8, -16.8) Quadrado: (718.24, 282.24, 475.24, 353.44, 139.24, 219.04, 46.24, 23470.24, 353.44, 282.24) = soma = 26379.6 Variância = 26379.6 / 10 = 2637.96 Desvio padrão ≈ sqrt(2637.96) ≈ 51.36 Z-score de 300 = (300 - 146.8) / 51.36 ≈ 153.2 / 51.36 ≈ 2.98 Como 2.98 > 2, consideramos 300 uma anomalia.