10 ‐ Segurança - BktechBrazil/elastic-eck GitHub Wiki

O Elastic Security é a solução de segurança da Elastic, construída sobre o Elastic Stack. Ela centraliza dados de segurança de diversas fontes — logs de sistemas, eventos de rede, dados de endpoints, feeds de threat intelligence — e oferece uma plataforma unificada para detectar, investigar e responder a ameaças.

O Elastic Security é classificado como uma plataforma SIEM (Security Information and Event Management) + XDR (Extended Detection and Response), o que significa que vai além da simples correlação de logs: ele também protege endpoints, automatiza respostas e usa inteligência artificial para priorizar alertas.

Na versão 9.4, a Elastic consolidou o Elastic Security como uma plataforma de SecOps agêntica — com automação nativa (Workflows), inteligência artificial integrada (Attack Discovery, AI Assistant) e capacidades de resposta a endpoints, eliminando a necessidade de ferramentas SOAR externas.

• Sem silos: logs, métricas, eventos de endpoint e dados de APM estão no mesmo cluster — correlacionar um alerta de SIEM com dados de observabilidade é nativo, não uma integração
• Regras baseadas em padrões conhecidos: o Elastic Security vem com centenas de regras de detecção prontas, mapeadas para o framework MITRE ATT&CK
• Escalabilidade: o mesmo Elasticsearch que indexa bilhões de logs por dia é o motor de busca do SIEM
• IA integrada: Attack Discovery e AI Assistant reduzem o tempo de triagem e investigação sem precisar de ferramentas externas

E no ECK? O Elastic Security é uma aplicação do Kibana e funciona igual em qualquer instalação. O que muda no ECK é a segurança do próprio cluster — TLS, usuários e credenciais —, gerenciada pelo operator e tratada na seção 10.4.

O SIEM do Elastic Security é a camada de coleta, correlação e visualização de eventos de segurança. Diferentemente de SIEMs tradicionais que exigem normalizações manuais pesadas, o Elastic Security usa o ECS (Elastic Common Schema) — um schema padronizado que normaliza campos de diferentes fontes automaticamente.

O que o SIEM faz:

• Coleta de dados: recebe eventos de qualquer fonte via Beats, Elastic Agent, Logstash ou qualquer sistema que envie dados no formato ECS. Exemplos: firewall logs, Active Directory, DNS, proxy, endpoint events.
• Correlação de eventos: o mecanismo de detecção aplica regras sobre os dados indexados em tempo real ou em janelas de tempo configuráveis.
• Timelines: ferramenta de investigação que permite ao analista construir uma linha do tempo de eventos relacionados a um incidente — arrastando alertas, queries e anotações para uma narrativa coerente.
• Dashboards de segurança: painéis prontos para monitoramento de autenticações, eventos de rede, atividade de usuários, entre outros.

Caminho: Menu → Security → Overview

O Elastic Agent com a integração de Elastic Defend transforma o agente de coleta de dados em um agente de proteção de endpoints — com capacidades de prevenção, detecção e resposta (EDR).

O que o Elastic Defend oferece:

• Prevenção de malware: bloqueia executáveis maliciosos com base em assinaturas e análise comportamental, mesmo offline
• Detecção comportamental: identifica técnicas de ataque (process injection, credential dumping, lateral movement) com base em comportamento, não apenas assinaturas
• Response actions: a partir do Kibana, é possível executar ações remotas no endpoint sem precisar de acesso direto à máquina:
  • Isolar o host da rede (preservando a conexão com o Elastic)
  • Listar e finalizar processos
  • Executar comandos via shell remoto
  • Capturar arquivos suspeitos para análise
  • Memory dump: capturar memória de processos para análise forense — na 9.4, passou a estar disponível também em Linux

Elastic Defend e Kubernetes: a integração Elastic Defend ainda não é suportada em ambientes de containers, como o Kubernetes. É uma limitação da própria integração, não do ECK: o Kibana e o Fleet Server podem rodar no ECK e distribuir políticas com o Elastic Defend para agentes instalados em servidores e estações fora de containers.

Caminho: Menu → Security → Endpoints

As regras de detecção são o coração do SIEM. Cada regra define uma condição que, quando atendida, gera um alerta para investigação.

Tipos de regras disponíveis:

A janela de tempo de uma regra é definida pelo agendamento: cada execução analisa o intervalo da regra (Runs every) mais o tempo extra de Additional look-back time. Uma regra que roda a cada 5 minutos com 1 minuto de look-back analisa sempre os últimos 6 minutos.

Regras prontas: o Elastic Security vem com centenas de regras de detecção prontas, mantidas pela equipe da Elastic e mapeadas para o framework MITRE ATT&CK. Elas são atualizadas com frequência e podem ser instaladas em Detection Rules → Add Elastic rules.

Caminho: Menu → Security → Rules → Detection Rules

O Attack Discovery é um recurso de IA que analisa os alertas disparados nas últimas horas e os correlaciona automaticamente em narrativas de ataque — agrupando alertas isolados em uma cadeia de eventos coerente.

Por que isso importa:

Um analista de SOC em um ambiente real pode receber dezenas ou centenas de alertas por hora. A maioria é ruído ou alertas relacionados ao mesmo ataque visto de múltiplos ângulos. O Attack Discovery usa um LLM para analisar o conjunto de alertas e identificar quais parecem fazer parte de uma mesma campanha — reduzindo o tempo de triagem de horas para minutos.

O que o Attack Discovery entrega:

• Agrupamento de alertas relacionados em um único "ataque"
• Narrativa em linguagem natural explicando o que está acontecendo
• Mapeamento para táticas e técnicas do MITRE ATT&CK
• Recomendação de próximos passos para o analista

O Attack Discovery precisa de pelo menos um conector de LLM configurado no Kibana.

Caminho: Menu → Security → Attack Discovery

O Elastic Security permite integrar feeds externos de Threat Intelligence — listas de IPs maliciosos, hashes de malware, domínios de C2, URLs de phishing — e correlacioná-los automaticamente com os eventos do SIEM.

Fontes de threat intelligence suportadas:

• Integração nativa com feeds gratuitos via Elastic Agent integrations: MISP, Abuse.ch, AlienVault OTX, Anomali, entre outros
• Ingestão manual de IOCs no formato STIX/TAXII
• Qualquer feed que possa ser ingerido via Logstash ou Elastic Agent

A página Indicators, que reúne os IOCs dos feeds, exige licença Enterprise (disponível na trial).

Como funciona a correlação:

As regras do tipo Indicator Match verificam continuamente se eventos recentes do SIEM contêm campos que correspondem a IOCs indexados. Por exemplo: se um endpoint se conectar a um IP que está na lista de C2 conhecidos, a regra gera um alerta automaticamente.

Caminho: Menu → Security → Intelligence → Indicators

GA na 9.4 para clientes Enterprise, o Workflows é o mecanismo de automação nativo do Elastic — eliminando a necessidade de uma ferramenta SOAR externa.

O que os Workflows permitem:

• Criar fluxos de automação visuais que respondem a alertas, casos ou eventos
• Executar ações em sequência: enriquecer um alerta com dados de threat intelligence, criar um case, notificar o time no Slack, isolar o endpoint, atribuir para um analista
• Integrar com sistemas externos via webhook — Jira, ServiceNow, PagerDuty, qualquer API REST
• Combinar automação determinística (passos fixos) com IA (o AI Agent decide o próximo passo com base no contexto)

Diferença em relação aos playbooks SOAR tradicionais:

Em um SOAR tradicional, o playbook define todos os passos antecipadamente. No Elastic Workflows com AI Agent integrado, parte do fluxo pode ser delegada ao agente de IA — que analisa o contexto e decide quais ações tomar, sem necessidade de mapear cada cenário possível.

Caminho: Menu → Security → Workflows (Enterprise)

O módulo de Cases do Elastic Security funciona como o sistema de gestão de incidentes integrado ao SIEM. Permite documentar a investigação, colaborar com o time e manter o histórico completo de cada incidente.

Funcionalidades:

• Criar casos manualmente ou automaticamente a partir de alertas (via regras ou Workflows)
• Adicionar alertas, evidências, comentários e anexos ao caso
• Definir severidade, status e responsável
• Integrar com sistemas externos: Jira, ServiceNow, Swimlane
• Auditar todas as ações tomadas no caso

Caminho: Menu → Security → Cases

O MITRE ATT&CK é um framework público que cataloga táticas e técnicas usadas por atacantes reais em ataques documentados. É o padrão de referência da indústria de segurança.

Estrutura do MITRE ATT&CK:

• Táticas: o objetivo do atacante em uma fase do ataque (ex: Initial Access, Execution, Persistence, Privilege Escalation, Lateral Movement, Exfiltration)
• Técnicas: como o atacante atinge o objetivo (ex: T1059 - Command and Scripting Interpreter, T1078 - Valid Accounts)
• Sub-técnicas: variações específicas de uma técnica (ex: T1059.001 - PowerShell)

Como o Elastic Security usa o MITRE ATT&CK:

Cada regra de detecção é mapeada para uma ou mais técnicas do MITRE ATT&CK. No Kibana, é possível visualizar a cobertura do seu ambiente através de uma matriz que mostra quais técnicas estão sendo detectadas — e identificar lacunas onde não há cobertura.

Caminho: Menu → Security → Rules → Coverage Overview

Antes de proteger os dados monitorados, o Elastic Stack precisa estar protegido. No ECK, a segurança do cluster já vem ligada e é mantida pelo operator:

As credenciais geradas pelo operator são guardadas em Secrets com o label eck.k8s.elastic.co/credentials=true.

Rotação de credenciais: para trocar uma credencial gerada pelo operator, basta apagar o Secret: o operator cria outro com um valor novo. Apagar o Secret lab-es-es-elastic-user, por exemplo, gera uma nova senha para o elastic. Aplicações que usam essa senha deixam de se conectar até receberem a nova — por isso a documentação recomenda não usar o elastic em aplicações e criar usuários próprios com permissões restritas.

Desativar o usuário elastic: em ambientes que autenticam apenas por SSO (SAML, OpenID Connect), o campo spec.auth.disableElasticUser: true do manifesto do Elasticsearch desativa o superusuário padrão.

Usuários e roles próprios: podem ser criados de três formas:

• Native realm, pela interface do Kibana (Stack Management → Security) ou pela API de segurança do Elasticsearch — como em qualquer instalação;
• File realm, de forma declarativa, com Secrets referenciados no manifesto do Elasticsearch em spec.auth.fileRealm. O ECK junta o conteúdo dos Secrets e o distribui para todos os nodes, sem reinício;
• Realms externos, como LDAP, SAML e OpenID Connect, configurados no config do Elasticsearch e do Kibana.

Exemplo de usuário declarativo com um Secret do tipo kubernetes.io/basic-auth, referenciado no manifesto do Elasticsearch:

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: analista-soc
  password: <senha>
  roles: viewer
---
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: lab-es
spec:
  auth:
    fileRealm:
      - secretName: secret-basic-auth
  # ... restante do manifesto

Roles próprias também podem ser declaradas em Secrets, com a chave roles.yml, referenciados em spec.auth.roles.

Os laboratórios usam o cluster lab-es com um node e o Kibana lab-kb.

cd ~/eck-lab
kubectl -n elastic get elasticsearch,kibana

Resultado esperado: lab-es e lab-kb com HEALTH green.

PASSWORD=$(kubectl -n elastic get secret lab-es-es-elastic-user \
  -o go-template='{{.data.elastic | base64decode}}')
echo "Senha do elastic: $PASSWORD"

pkill -f "port-forward.*5601" || true
nohup kubectl -n elastic port-forward --address 0.0.0.0 service/lab-kb-kb-http 5601 > /tmp/pf-kibana.log 2>&1 &
sleep 2
cat /tmp/pf-kibana.log

Resultado esperado: a senha do usuário elastic e a mensagem Forwarding from 0.0.0.0:5601 -> 5601.

O túnel fica ligado ao pod do Kibana que estava rodando quando ele foi aberto. Se esse pod for reiniciado ou recriado, o túnel cai e o Kibana deixa de responder no navegador: execute este bloco novamente.

No navegador, abra https://<IP_DA_VM>:5601 e faça login com o usuário elastic.

As regras de detecção usadas nos laboratórios funcionam na licença Basic. Recursos como Attack Discovery e regras de Machine Learning exigem licença paga (disponível na trial). A instalação das regras prontas da Elastic baixa um pacote do Elastic Package Registry: o pod do Kibana precisa de acesso à internet.

Neste laboratório você vai ver as credenciais que o operator criou para o lab-es e o lab-kb e, opcionalmente, trocar a senha do usuário elastic.

kubectl -n elastic get secret -l eck.k8s.elastic.co/credentials=true

Resultado esperado: os Secrets de credenciais do namespace, entre eles o lab-es-es-elastic-user (senha do elastic) e os usuários que o operator criou para o Kibana.

Veja também todos os Secrets do cluster lab-es, incluindo os de certificados:

kubectl -n elastic get secret | grep lab-es

Resultado esperado: uma lista parecida com esta (os nomes seguem o padrão <nome do cluster>-es-...):

lab-es-es-elastic-user                 Opaque   1
lab-es-es-http-ca-internal             Opaque   2
lab-es-es-http-certs-internal          Opaque   3
lab-es-es-http-certs-public            Opaque   2
lab-es-es-internal-users               Opaque   5
lab-es-es-transport-ca-internal        Opaque   2
lab-es-es-transport-certs-public       Opaque   1
lab-es-es-xpack-file-realm             Opaque   4
...

No Console do Kibana:

GET /_security/_authenticate

A resposta mostra o usuário elastic, a role superuser e o realm de autenticação.

Apague o Secret com a senha: o operator gera uma nova em seguida.

kubectl -n elastic delete secret lab-es-es-elastic-user
sleep 10
PASSWORD=$(kubectl -n elastic get secret lab-es-es-elastic-user \
  -o go-template='{{.data.elastic | base64decode}}')
echo "Nova senha do elastic: $PASSWORD"

Resultado esperado: secret "lab-es-es-elastic-user" deleted e, depois de alguns segundos, uma senha diferente da anterior.

Saia do Kibana e entre de novo com a nova senha. O Kibana continua funcionando durante a troca, porque se conecta ao Elasticsearch com o seu próprio usuário interno, e não com o elastic.

Neste laboratório vamos criar uma regra de detecção personalizada e verificar o fluxo completo de um alerta — da geração à investigação.

1. Acesse Menu → Security → Rules → Detection Rules
2. Clique em Add Elastic rules
3. Filtre por categoria Linux ou Credential Access
4. Instale algumas regras com Install and enable (em vez de Install all, que instala todas sem habilitar)
5. Confira na lista de Detection Rules que as regras aparecem como habilitadas

O laboratório precisa de eventos de autenticação SSH. Em produção, eles viriam do Elastic Agent ou do Filebeat lendo os logs de autenticação dos servidores. Aqui, vamos gerá-los no Console, em um data stream de logs com campos no padrão ECS.

Primeiro, um ingest pipeline que marca cada evento com o horário da indexação, para que os eventos caiam sempre dentro da janela da regra:

PUT /_ingest/pipeline/lab-auth-agora
{
  "description": "Define o @timestamp dos eventos do laboratório como o momento da indexação",
  "processors": [
    {
      "set": {
        "field": "@timestamp",
        "copy_from": "_ingest.timestamp"
      }
    }
  ]
}

Vamos criar uma regra que detecta múltiplas falhas de autenticação SSH em curto período — um indicador clássico de brute force.

1. Acesse Menu → Security → Rules → Detection Rules → Create new rule
2. Selecione o tipo Threshold
3. Em Index patterns, deixe apenas logs-lab.auth-*
4. Configure a query:

event.category: "authentication" and event.outcome: "failure" and process.name: "sshd"

5. Configure o threshold:

   • Group by: source.ip
   • Threshold: 5

6. Em About rule, configure:

   • Name: SSH Brute Force - Múltiplas Falhas de Autenticação
   • Description: Detecta 5 ou mais falhas de autenticação SSH do mesmo IP
   • Severity: Medium
   • Risk score: 47
   • MITRE ATT&CK: Tática Credential Access, Técnica T1110 - Brute Force

7. Em Schedule rule, configure:

   • Runs every: 1 minute
   • Additional look-back time: 5 minutes

   A regra analisa os últimos 6 minutos a cada execução. Em produção, o comum é rodar a cada 5 minutos; aqui usamos 1 minuto para ver o alerta rapidamente.

8. Clique em Create & enable rule

Com a regra habilitada, indexe no Console seis falhas de SSH do IP 203.0.113.10, duas do IP 198.51.100.7 (abaixo do limite) e, por fim, um login bem-sucedido do mesmo IP atacante:

POST /logs-lab.auth-default/_bulk?pipeline=lab-auth-agora&refresh=true
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "203.0.113.10" }, "user": { "name": "root" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for root from 203.0.113.10 port 52211 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "203.0.113.10" }, "user": { "name": "root" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for root from 203.0.113.10 port 52212 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "203.0.113.10" }, "user": { "name": "admin" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for admin from 203.0.113.10 port 52213 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "203.0.113.10" }, "user": { "name": "admin" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for admin from 203.0.113.10 port 52214 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "203.0.113.10" }, "user": { "name": "oracle" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for oracle from 203.0.113.10 port 52215 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "203.0.113.10" }, "user": { "name": "admin" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for admin from 203.0.113.10 port 52216 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "198.51.100.7" }, "user": { "name": "joao" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for joao from 198.51.100.7 port 40111 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "failure" }, "process": { "name": "sshd" }, "source": { "ip": "198.51.100.7" }, "user": { "name": "joao" }, "host": { "name": "srv-lab-01" }, "message": "Failed password for joao from 198.51.100.7 port 40112 ssh2" }
{ "create": {} }
{ "event": { "kind": "event", "category": ["authentication"], "outcome": "success" }, "process": { "name": "sshd" }, "source": { "ip": "203.0.113.10" }, "user": { "name": "admin" }, "host": { "name": "srv-lab-01" }, "message": "Accepted password for admin from 203.0.113.10 port 52217 ssh2" }

• O nome logs-lab.auth-default segue o padrão logs-<dataset>-<namespace>: o data stream é criado pelo template interno de logs, e os campos no padrão ECS recebem os tipos corretos (por exemplo, source.ip como ip);
• o _bulk usa create, a única operação aceita em data streams;
• o parâmetro pipeline=lab-auth-agora coloca o horário atual no @timestamp de cada evento.

A resposta deve trazer "errors": false. Se o data stream ficar yellow (o lab-es tem um único node), ajuste as réplicas:

PUT /logs-lab.auth-default/_settings
{
  "index.number_of_replicas": 0
}

Os IPs 203.0.113.10 e 198.51.100.7 pertencem a faixas reservadas para documentação: não são endereços reais.

Em até um ou dois minutos, a regra executa e gera um alerta para o IP 203.0.113.10, que teve 6 falhas. O IP 198.51.100.7, com 2 falhas, não gera alerta. Os alertas aparecem em:

Menu → Security → Alerts

Para cada alerta você pode:

• Ver os detalhes do evento que disparou a regra
• Navegar para o host ou usuário relacionado
• Adicionar a uma Timeline para investigação
• Criar um Case para acompanhamento
• Alterar o status do alerta: Open → Acknowledged → Closed

Na página da regra (Detection Rules → SSH Brute Force...), a aba de execuções mostra se cada execução terminou com sucesso. Se nenhum alerta aparecer, confira ali se a regra encontrou erros e se os eventos foram indexados há menos de 6 minutos; se já passaram, repita o _bulk.

A Timeline é a ferramenta de investigação do Elastic Security. Ela permite construir uma narrativa cronológica de eventos relacionados a um incidente.

1. Acesse Menu → Security → Alerts
2. Clique no ícone de investigação ao lado do alerta de brute force
3. Selecione Investigate in Timeline

A Timeline será criada automaticamente com o alerta e os eventos relacionados.

• Query bar: adicione filtros para incluir ou excluir eventos — por exemplo, filtre por host.name para ver todos os eventos do host afetado no período
• Adicionar eventos: arraste eventos da lista de resultados para a Timeline para incluí-los na narrativa
• Anotações: adicione comentários a eventos específicos para documentar suas observações
• Field browser: selecione quais campos exibir na tabela para facilitar a análise

Com o alerta de brute force na Timeline, adicione uma query para ver o que aconteceu depois das falhas — especificamente, se algum login foi bem-sucedido:

event.category: "authentication" and event.outcome: "success" and host.name: "srv-lab-01"

A Timeline mostra o login bem-sucedido do usuário admin a partir do IP 203.0.113.10, logo depois das falhas: um indício de que o ataque de brute force foi efetivo.

1. Clique em Save para salvar a Timeline com um nome descritivo
2. Clique em Attach to new case para criar um Case vinculado à investigação
3. Preencha o título, descrição e severidade do Case
4. Clique em Create case

1. Acesse Menu → Security → Rules → Coverage Overview
2. A matriz MITRE ATT&CK será exibida: quanto mais regras cobrem uma técnica, mais escura fica a célula (veja a legenda no topo). Ao expandir uma célula, aparecem as contagens de regras habilitadas e desabilitadas
3. Passe o mouse sobre cada célula para ver quais regras cobrem aquela técnica
4. Clique em uma célula para abrir as regras correspondentes e habilitá-las diretamente
5. Localize a técnica T1110 - Brute Force, na tática Credential Access: ela aparece coberta pela regra criada no laboratório anterior

Esse mapa é uma ferramenta valiosa para comunicar a postura de segurança para gestores e para identificar lacunas prioritárias de detecção.

1. Em Security → Rules → Detection Rules, desabilite ou apague a regra SSH Brute Force - Múltiplas Falhas de Autenticação e as regras prontas habilitadas no laboratório, para que não fiquem executando.
2. No Console, apague o data stream e o pipeline do laboratório:

DELETE /_data_stream/logs-lab.auth-default

DELETE /_ingest/pipeline/lab-auth-agora

Os alertas, a Timeline e o Case criados continuam no Kibana como registro da investigação.

• O Elastic Security é uma plataforma SIEM + XDR sobre o Elastic Stack, com dados normalizados no ECS, regras de detecção, Timelines, Cases, threat intelligence, IA (Attack Discovery) e automação (Workflows).
• As regras de detecção têm vários tipos (Query, Threshold, EQL, New Terms, Indicator Match, ML) e são mapeadas para o MITRE ATT&CK; a janela de uma regra é o intervalo de execução mais o look-back.
• O Elastic Defend protege endpoints, mas não é suportado em containers; o ECK pode hospedar o Kibana e o Fleet Server que gerenciam agentes fora do Kubernetes.
• No ECK, a segurança do cluster vem ligada: TLS nas camadas HTTP e de transporte, usuário elastic e usuários internos criados pelo operator, com as credenciais em Secrets marcados com eck.k8s.elastic.co/credentials=true.
• Apagar o Secret de uma credencial faz o operator gerar outra (rotação). Usuários e roles próprios podem ser criados no native realm ou, de forma declarativa, em Secrets referenciados em spec.auth.
• A Timeline reconstrói a sequência de eventos de um incidente e pode ser anexada a um Case.

10.1 a 10.3 - Elastic Security, componentes e MITRE ATT&CK

• Elastic Security
• Elastic Defend
• Response actions
• Known limitations: Elastic Defend em containers (ECK)
• Detection rules
• Threshold rules (janela = intervalo + look-back)
• Attack Discovery (requer conector de LLM)
• Indicators of compromise (Enterprise)
• Elastic 9.4: Workflows GA e memory dump em Linux
• Cases (Security)
• MITRE ATT&CK coverage

10.4 e 10.6 - Segurança do cluster no ECK

• ECK managed credentials (credenciais, rotação, disableElasticUser)
• File-based user authentication (ECK: spec.auth.fileRealm e Secrets basic-auth)
• Defining roles (roles em Secrets no ECK)
• Secure cluster communications (TLS)
• Authenticate API

10.7 a 10.10 - Laboratórios de detecção e investigação

• Create a detection rule
• Install Elastic prebuilt rules
• Timeline
• Elastic Common Schema (ECS)
• Data stream naming scheme
• Set processor (copy_from)
• Bulk API