Engenharia de Segurança · Mergulho Técnico Profundo
Os frameworks de conformidade de segurança existem para responder a uma pergunta desconfortável: Você consegue provar que seus sistemas são seguros? Não apenas afirmar isso — provar com logs, alertas e trilhas de auditoria que resistem ao escrutínio de terceiros.
| Tool | Role | License |
|---|---|---|
 | Identity Layer (0) — SSO, SAML, OIDC, MFA, and a full audit log of every auth event | ✓ Open Source · Apache 2.0 |
 | SIEM & Compliance Engine — log ingestion, threat correlation, SOC 2 / HIPAA / PCI dashboards | ✓ Open Source · GPL |
 | Query & Inventory Layer — osquery across all endpoints, queryable compliance record | ✓ Open Source · MIT |
🔬 OpenEDR | Behavioral Detection Layer — process trees, credential access, lateral movement via MITRE ATT&CK | ✓ Open Source · Apache 2.0 |
🚫 Fail2ban | Active Response Layer — bans offending IPs via firewall rules, immutable response audit trail | ✓ Open Source · GPL |
📧 MXToolbox | Email & Domain Security — continuous SPF, DKIM, DMARC, and blacklist monitoring | ✓ Free monitoring tier |
 | Runtime Detection Layer — eBPF syscall interception on Linux servers and containers | ✓ Open Source · Apache 2.0 |
 | SOAR & Automation Layer — connects Wazuh, Fleet, Keycloak, Fail2ban, and Rocket.Chat into response workflows | ✓ Open Source · Apache 2.0 |
A Stack de Aplicações
Keycloak — Camada de Identidade (Camada 0)
- Centraliza a autenticação em todos os dispositivos e servidores via SSO, SAML e OIDC
- Produz um log de auditoria completo de cada login, emissão de token e ação administrativa
Para um deploy do Keycloak totalmente gerenciado no PikaPods, veja Hospedagem Sem Dor de Cabeça: Rode WordPress, Ghost & Keycloak no PikaPods.
▶ show code▼ hide code
# Setup Steps
1. Deploy via Docker or dedicated 2 vCPU / 4 GB host
2. Create a dedicated realm — never use master for app logins
3. Create OIDC clients for Wazuh, Shuffle, Fleet, and Rocket.Chat
4. Enforce TOTP MFA via Required Actions
5. Set password policy: 12+ chars, special char, digit, history 5
6. Enable full event logging with 90+ day expiration
7. Wire Wazuh Dashboard SAML/OIDC via roles_mapping.yml
▶ show code▼ hide code
// Enable full event logging (realm settings)
// Keycloak realm settings — enable full event logging
{
"eventsEnabled": true,
"eventsExpiration": 7776000,
"adminEventsEnabled": true,
"adminEventsDetailsEnabled": true,
"enabledEventTypes": [
"LOGIN", "LOGIN_ERROR", "LOGOUT",
"REGISTER", "REGISTER_ERROR",
"UPDATE_PASSWORD", "UPDATE_PASSWORD_ERROR",
"CLIENT_LOGIN", "CLIENT_LOGIN_ERROR"
]
}
<!-- Wazuh agent — read Keycloak log output -->
<!-- ossec.conf — on Keycloak host -->
<ossec_config>
<localfile>
<log_format>json</log_format>
<location>/opt/keycloak/data/log/keycloak.log</location>
<label key="source">keycloak</label>
</localfile>
</ossec_config>
<!-- Wazuh rules — login failures and admin privilege changes -->
<!-- keycloak_rules.xml -->
<group name="keycloak,authentication,">
<rule id="92001" level="8">
<decoded_as>json</decoded_as>
<field name="source">keycloak</field>
<field name="type">LOGIN_ERROR</field>
<description>Keycloak: Authentication failure</description>
<group>pci_dss_10.2.4,hipaa_164.312.b,soc2_cc6.1,</group>
</rule>
<rule id="92002" level="12" frequency="5" timeframe="60">
<if_matched_sid>92001</if_matched_sid>
<description>Keycloak: Brute force attack — 5+ failures in 60 seconds</description>
<group>pci_dss_10.6.1,hipaa_164.312.b,</group>
</rule>
<rule id="92003" level="10">
<decoded_as>json</decoded_as>
<field name="source">keycloak</field>
<field name="operationType">CREATE|UPDATE|DELETE</field>
<field name="resourceType">USER|ROLE_MAPPING|CLIENT_ROLE_MAPPING</field>
<description>Keycloak: Admin privilege change detected</description>
<group>pci_dss_8.5,soc2_cc6.1,</group>
</rule>
</group>
Wazuh — Motor de SIEM e Conformidade
- Ingere logs de praticamente qualquer fonte e aplica regras de correlação para detectar ameaças e violações de política
- Dashboards de conformidade mapeiam cada evento a requisitos de controle específicos — prontos para auditoria sem semanas de trabalho manual
▶ show code▼ hide code
# Setup Steps
# Deploy Wazuh Manager + Indexer + Dashboard
1. Provision 4 vCPU, 8 GB RAM, 50+ GB SSD
2. Set hostname and configure /etc/hosts for local FQDN
3. Run the Wazuh all-in-one installer script
4. Confirm all three services are running
5. Log in and immediately change the default admin password
6. Lock firewall to ports 1514, 1515, and 443 only
# Install Wazuh Agents on all endpoints + Keycloak host
1. Linux: dpkg install with WAZUH_MANAGER env set
2. macOS: .pkg install + launchctl load
3. Windows: msiexec silent install
4. Verify each agent appears in dashboard within 60 seconds
5. Enable FIM on Keycloak config and log directories
6. Tag agents by group for policy segmentation
# Enable Wazuh Compliance Modules
1. Enable compliance dashboards in Wazuh → Modules
2. Verify ruleset includes compliance tags
3. Download and deploy NIST/CIS SCA policy files to agent groups
4. Run initial SCA scan and review compliance %
5. Document failing controls as tracked exceptions
# Configure Alert Routing
1. Email: configure SMTP in ossec.conf, set alert level >= 10
2. Phone/SMS: bridge via PagerDuty, OpsGenie, or Shuffle → Twilio
3. Rocket.Chat: configure incoming webhook in Wazuh or Shuffle
4. Test all channels with ossec-logtest
# Set ILM Retention Policies
1. Identify longest requirement (HIPAA = 6 years)
2. Create ILM policy: hot 7d → warm 30d → cold → delete at limit
3. Apply to wazuh-alerts-* and wazuh-archives-* templates
4. Size storage at ~1 GB/day per 100 agents
5. Configure S3 or NFS snapshot repo for cold storage
6. Document policy for audit evidence
Fleet — Camada de Consulta e Inventário
- Gerencia o osquery em todos os endpoints — servidores, estações de trabalho e instâncias em nuvem
- Dá aos auditores um registro consultável do estado do sistema ao longo do tempo, não um retrato pontual
- Add-on WireGuard — combine o Fleet com o WireGuard para impor a presença do túnel VPN como uma política do Fleet; o osquery consegue verificar se a interface WireGuard está ativa em cada dispositivo registrado antes de conceder acesso a recursos internos
▶ show code▼ hide code
# Setup Steps
# Stand up Fleet + osquery
1. Deploy Fleet with MySQL + Redis backend (or Docker preview)
2. Configure TLS with Let's Encrypt or internal CA
3. Generate and distribute enroll secret via MDM
4. Confirm all hosts appear in Fleet UI within 5 minutes
5. Set agent update channel to stable with auto-update enabled
# Configure Fleet → Filebeat → Wazuh pipeline
1. Install Filebeat on the Fleet host (not the Wazuh server)
2. Point Filebeat input at Fleet's log output directory
3. Enable and configure the Wazuh Filebeat module
4. Test output: filebeat test output
5. Verify Fleet events appear in Wazuh Discover
# Schedule Fleet Compliance Queries
1. SELECT * FROM disk_encryption; — every 24h
2. SELECT username, uid, shell FROM users WHERE uid >= 1000; — every 12h
3. SELECT name, version, source FROM software; — every 24h
4. SELECT * FROM authorized_keys; — every 6h on servers
5. Create pass/fail Fleet Policies for FileVault/BitLocker status
6. Route query results through Fleet log pipeline → Filebeat → Wazuh
▶ show code▼ hide code
# Fleet result log configuration
# fleet.yml — result log configuration
logging:
result:
plugin: filesystem
config:
result_log_file: /var/log/fleet/osquery_results.log
status:
plugin: filesystem
config:
status_log_file: /var/log/fleet/osquery_status.log
# Filebeat — forward Fleet logs to Wazuh
# filebeat.yml
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/fleet/osquery_results.log
fields:
source: fleet-osquery
compliance: true
output.logstash:
hosts: ["wazuh-manager:5044"]
ssl.certificate_authorities: ["/etc/filebeat/wazuh-ca.pem"]
OpenEDR — Camada de Detecção Comportamental
- Monitoramento comportamental contínuo de árvores de processos, padrões de acesso a credenciais, movimento lateral e anomalias no sistema de arquivos
- Telemetria modelada com base no framework MITRE ATT&CK
Implante o agente Wazuh junto com o OpenEDR em cada endpoint. Configure o agente para ler a telemetria JSON do OpenEDR diretamente, depois mapeie as categorias do MITRE ATT&CK para os grupos de controle de conformidade.
▶ show code▼ hide code
<!-- Wazuh agent — read OpenEDR telemetry and Windows Security Event Log -->
<!-- ossec.conf — on each endpoint -->
<ossec_config>
<localfile>
<log_format>json</log_format>
<location>C:\ProgramData\OpenEDR\Logs\*.json</location>
<label key="source">openedr</label>
</localfile>
<!-- Windows Security Event Log for HIPAA audit trail -->
<localfile>
<log_format>eventchannel</log_format>
<location>Security</location>
</localfile>
</ossec_config>
<!-- Wazuh rules — MITRE ATT&CK credential access detection -->
<!-- openedr_rules.xml -->
<group name="openedr,mitre,">
<rule id="91001" level="12">
<decoded_as>json</decoded_as>
<field name="source">openedr</field>
<field name="threat.type">credential_access</field>
<description>OpenEDR: Credential access attempt detected</description>
<mitre><id>T1003</id></mitre>
<group>pci_dss_10.6.1,hipaa_164.312.b,</group>
</rule>
</group>
Fail2ban — Camada de Resposta Ativa
- Monitora arquivos de log em busca de falhas repetidas de autenticação e bane automaticamente os IPs infratores via regras de firewall
- Produz a trilha de auditoria imutável de resposta automatizada exigida pelo PCI DSS Req. 10 e pelo SOC 2 CC7
▶ show code▼ hide code
# Setup Steps
1. Install on all internet-facing servers
2. Copy jail.conf → jail.local; enable sshd and nginx-http-auth jails
3. Set bantime = 1h, findtime = 10m, maxretry = 5
4. Configure JSON log output for Wazuh ingestion
5. Add Wazuh FIM watch on /etc/fail2ban/
6. Add active-response block in ossec.conf on rule 30105
7. Test: 5 bad SSH attempts → confirm ban + Wazuh alert fires
O Wazuh aciona o Fail2ban (resposta ativa): O Wazuh detecta padrões de força bruta em SSH, RDP, aplicações web e falhas de login no Keycloak, e então chama o Fail2ban para banir o IP de origem:
▶ show code▼ hide code
<!-- Wazuh active response configuration -->
<!-- ossec.conf — on Wazuh Manager -->
<ossec_config>
<active-response>
<command>fail2ban</command>
<location>local</location>
<rules_id>5763,5764,92002</rules_id> <!-- SSH brute force + Keycloak brute force -->
<timeout>3600</timeout>
</active-response>
</ossec_config>
#!/bin/bash
# /var/ossec/active-response/bin/fail2ban.sh
ACTION=$1
USER=$2
IP=$3
if [ "$ACTION" = "add" ]; then
fail2ban-client set wazuh-response banip "$IP"
elif [ "$ACTION" = "delete" ]; then
fail2ban-client set wazuh-response unbanip "$IP"
fi
# /etc/fail2ban/jail.d/wazuh-response.conf
[wazuh-response]
enabled = true
banaction = iptables-multiport
port = all
filter =
logpath = /var/log/wazuh-response.log
maxretry = 1
bantime = 3600
Os logs do Fail2ban alimentam o Wazuh (trilha de auditoria): Cada ban e unban se torna um evento do Wazuh — criando um registro imutável das respostas automatizadas para o PCI DSS Req. 10.2 e o SOC 2 CC7:
▶ show code▼ hide code
<!-- Fail2ban log ingestion and audit rules -->
<!-- ossec.conf — Fail2ban log ingestion -->
<ossec_config>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/fail2ban.log</location>
<label key="source">fail2ban</label>
</localfile>
</ossec_config>
<!-- fail2ban_rules.xml -->
<group name="fail2ban,">
<rule id="93001" level="8">
<decoded_as>fail2ban</decoded_as>
<match>Ban</match>
<description>Fail2ban: IP banned after repeated failures</description>
<group>pci_dss_10.2.4,pci_dss_10.6.1,soc2_cc7.2,</group>
</rule>
<rule id="93002" level="6">
<decoded_as>fail2ban</decoded_as>
<match>Unban</match>
<description>Fail2ban: IP ban expired and lifted</description>
<group>pci_dss_10.2.4,</group>
</rule>
</group>
O resultado é um ciclo fechado: o Wazuh detecta → o Fail2ban bloqueia → o Fail2ban registra a ação → o Wazuh grava isso como um evento de conformidade com timestamp e IP completos.
MXToolbox — Segurança de Email e Domínio
- Monitoramento passivo da saúde do domínio de email — verifica continuamente registros SPF, DKIM e DMARC
- Um DMARC malconfigurado ou um IP em blacklist pode possibilitar spoofing de domínio ou causar falhas na notificação de violação de dados
▶ show code▼ hide code
# Setup Steps
1. Add blacklist monitors for all outbound mail server IPs
2. Add DNS monitors for SPF, DKIM, DMARC health on all sending domains
3. Add MX record monitors to detect tampering
4. Route MXToolbox webhooks into Shuffle → Wazuh for centralized logging
Falco — Camada de Detecção Comportamental em Tempo de Execução
- Interceptação de syscalls baseada em eBPF — detecta ameaças no nível do kernel sem que os agentes modifiquem o código do endpoint
- Preenche a lacuna que o OpenEDR deixa em servidores e containers Linux, onde os agentes de EDR do Windows não se aplicam
Implante o Falco em cada endpoint Linux para detecção comportamental em tempo de execução baseada em eBPF. O Falco intercepta chamadas de sistema e mapeia anomalias — shells originados de processos web, gravações em massa de arquivos, escaladas de privilégio — para técnicas do MITRE ATT&CK, enviando eventos JSON estruturados diretamente para o Wazuh.
▶ show code▼ hide code
# Setup Steps
1. Add the Falco apt repo and install: apt install -y falco
2. Select eBPF driver at install — do not use kernel module on production hosts
3. Install driver: falcoctl driver install --type ebpf
4. Enable service: systemctl enable --now falco
5. Set json_output: true in /etc/falco/falco.yaml
6. Configure file output to /var/log/falco/falco.json
7. Add custom rules to falco_rules.local.yaml (mass file writes, shells from web processes)
8. Add Wazuh <localfile> block to tail /var/log/falco/falco.json
9. Restart Wazuh agent and confirm Falco events appear in Wazuh Discover
10. Add custom Falco decoder and rules in local_rules.xml on the Wazuh manager
Shuffle — Camada de SOAR e Automação
- Conecta Wazuh, Fleet, Keycloak, Fail2ban e Rocket.Chat em fluxos de trabalho de resposta automatizados
- Cada ação automatizada é registrada como uma execução de workflow com timestamp — fornecendo a trilha de auditoria de resposta que os auditores exigem
Implante o Shuffle SOAR para automatizar triagem, enriquecimento e resposta em toda a stack. Os alertas do Wazuh disparam workflows do Shuffle que consultam o Fleet para obter contexto do host, chamam a resposta ativa do Wazuh para bloquear IPs e notificam o Rocket.Chat com detalhes enriquecidos do incidente.
▶ show code▼ hide code
# Setup Steps
1. Provision dedicated host: 2 vCPU / 4 GB RAM / 20 GB disk
2. Install Docker + Compose: curl -fsSL https://get.docker.com | sh
3. Clone Shuffle repo, set OUTER_HOSTNAME in docker-compose.yml, run docker compose up -d
4. Restrict login to Keycloak OIDC immediately after first launch
5. Install the Wazuh and HTTP apps from the Shuffle app library
6. Configure Wazuh app with manager URL and a least-privilege API user
7. Create a Webhook trigger in Shuffle and copy the hook URL
8. Add the Shuffle <integration> block to Wazuh ossec.conf with the webhook URL
9. Restart Wazuh manager and confirm test alerts arrive in Shuffle → Executions
10. Build triage playbook: parse alert level → if >= 12, call Wazuh active response → notify Rocket.Chat
11. Build Falco playbook: filter on falco rule group → enrich via Fleet/osquery → alert with host + process context
12. Build FIM rollback playbook: filter on rule 550/554 → SSH to agent → trigger restic/VSS restore → notify
13. Test each playbook end-to-end with ossec-logtest synthetic alerts
14. Set execution history retention to 30 days in Shuffle Settings
Configuração de Alertas
Roteie os alertas do Wazuh por severidade para garantir que a equipe certa seja notificada no momento certo:
| Severidade | Destino | Condições de Disparo |
|---|---|---|
| Nível 12+ (crítico) | Email + Telefone | Ameaças ativas, acesso a credenciais, violação de política |
| Nível 8–11 (alto) | Rocket.Chat #security | Novas contas de admin, rajadas de login falho, desvio de configuração |
| Resumo semanal | Taxas de aprovação/reprovação de conformidade e tendências de alertas | |
| Exportação pré-auditoria | Dashboards de conformidade do Wazuh exportados diretamente para pacotes de evidência SOC 2 / PCI |
Frameworks de Segurança Cobertos por Este Stack
- NIST Cinco Funções — Prioridade: Crítica. O framework estratégico usado para organizar todo o ciclo de vida de defesa de rede e servidores. Cada ferramenta neste stack mapeia diretamente para uma ou mais das cinco funções: Identificar (Fleet, Keycloak), Proteger (Fail2ban, WireGuard), Detectar (Wazuh, OpenEDR, Falco), Responder (Shuffle, Fail2ban), e Recuperar (playbooks do Wazuh, workflows do Shuffle).
- CWE — A cobertura da Common Weakness Enumeration é endereçada através da detecção comportamental do OpenEDR e da biblioteca de regras do Wazuh, que sinaliza padrões de fraqueza conhecidos (injeção, escalada de privilégio, autenticação inadequada) no nível de processo e log.
- CIS Docker Benchmarks — Prioridade: Alta. O padrão-ouro para o hardening dos ambientes de servidor em containers onde vivem as aplicações modernas. O Wazuh já vem com regras de auditoria do CIS Docker Benchmark prontas de fábrica; as políticas do osquery no Fleet podem verificar a conformidade com o benchmark continuamente em cada host que roda containers.
Respondendo Perguntas de Auditores
"Me mostre seu monitoramento de controle de acesso." Exporte o dashboard SOC 2 CC6 do Wazuh. O histórico de consultas do Fleet mostra o estado da conta de usuário de cada host durante todo o período de auditoria. Os logs de eventos administrativos do Keycloak mostram cada concessão e revogação de privilégio.
"Me mostre sua capacidade de detecção de incidentes." O mapa de cobertura do MITRE ATT&CK do OpenEDR combinado com as estatísticas de regras do Wazuh demonstra detecção ativa em toda a superfície de ataque. Os logs de ban do Fail2ban mostram a resposta automatizada a tentativas ativas de força bruta.
"Houve algum incidente de segurança durante o período de auditoria?" O histórico de alertas do Wazuh fornece um registro completo, com timestamp e imutável. A presença de incidentes significa que seu processo de detecção e resposta funcionou como projetado.
"Como vocês detectam alterações de software não autorizadas?" As consultas de inventário de software do Fleet e o File Integrity Monitoring (FIM) do Wazuh fornecem um registro contínuo do que foi instalado, quando, e em qual host.
"Como vocês aplicam MFA e gerenciam o acesso de usuários?" O Keycloak impõe MFA na camada de identidade para todos os serviços internos. Seus logs de auditoria, ingeridos pelo Wazuh, fornecem um registro com timestamp de cada evento de autenticação e alteração administrativa.
Essa arquitetura escala de uma startup com 50 endpoints buscando o SOC 2 Type I até uma empresa com 10.000 endpoints mantendo a certificação PCI DSS. A base open-source mantém os custos de licenciamento próximos de zero, e o design modular permite adicionar feeds comerciais de EDR, logs de segurança em nuvem ou monitoramento de rede sem substituir o pipeline central.