SOP-006: Procedimiento para fallos en controles críticos de seguridad

Campo	Valor
ID	SOP-006
Versión	1.0
Fecha de emisión	2026-06-16
Propietario	CISO + CTO (Gabriel Ureña — acting both)
PCI DSS	Req 10.7.1, 10.7.2, 10.7.2.1, 10.7.3
SLA total	Detección ≤1h · Respuesta ≤24h · Causa raíz ≤72h

1. Propósito

Definir el procedimiento que Fintrixs SAS sigue cuando se detecta el fallo de un control crítico de seguridad (firewall, IDS/IPS, FIM, audit logging, anti-malware, access controls, segmentation controls, automated security testing). Cumple PCI DSS v4.0 Req 10.7.

2. Controles críticos en alcance

#	Control	Tecnología	Detección de fallo
1	Network firewall (perimeter)	DigitalOcean Cloud Firewalls (8 firewalls)	DO health checks + Wazuh test pings + Kong upstream errors
2	Network firewall (WAF)	Coraza WAF	K8s liveness probe + Wazuh access log absence
3	IDS/IPS	Falco runtime + Wazuh signature rules	Wazuh agent heartbeat + Falco metrics
4	FIM (File Integrity Monitoring)	Wazuh syscheck	Wazuh agent status query
5	Anti-malware	ClamAV + Falco (runtime IOCs)	ClamAV service status + Falco metrics
6	Physical access controls	DigitalOcean DC (delegated)	DO incident notification (TPSP per Q60)
7	Logical access controls	auth-service + RBAC	auth-service health endpoint + JWT validation
8	Audit logging	Wazuh + pci_audit_events + Rapid7 forwarder	Event flow rate monitoring + dead-man-switch
9	Segmentation controls	K8s NetworkPolicies + DO Firewalls	Network test pods + connectivity matrix
10	Automated security testing	GitHub Actions security workflows	Workflow success rate + failed run alerts

Total: 10 controles críticos monitoreados.

3. Detección de fallos (PCI 10.7.1)

3.1 Mecanismos de detección automatizada

Mechanism	Cobertura	Frecuencia
Wazuh agent heartbeat	All hosts	Cada 60s
Falco metrics scrape	Runtime IDS	Cada 30s
Prometheus alerts	All services + DBs	Continuous
Kong upstream health checks	All services	Cada 5s
GitHub Actions failure alerts	Security workflows	Per-run
DO Cloud Firewall API status	All firewalls	Cada 5min
Synthetic transaction probes	Critical flows	Cada 5min
Wazuh "dead-man-switch" rule	Log absence detection	Continuous

3.2 Wazuh dead-man-switch rule (PCI 10.7.1 evidence)

xml

<rule id="100200" level="12">
  <if_group>ossec</if_group>
  <description>Wazuh agent has not reported in last 10 minutes — possible compromise or crash</description>
  <options>no_full_log</options>
  <group>pci_dss_10.7.1,critical_control_failure</group>
</rule>

<rule id="100201" level="14">
  <description>Falco metrics not received in last 5 minutes — IDS may be down</description>
  <group>pci_dss_10.7.1,critical_control_failure</group>
</rule>

<rule id="100202" level="14">
  <description>FIM scan has not completed in last 24 hours — FIM may be disabled</description>
  <group>pci_dss_10.7.1,critical_control_failure</group>
</rule>

<rule id="100203" level="15">
  <description>Audit log event rate dropped below 50% of 7-day baseline — central syslog may be unreachable</description>
  <group>pci_dss_10.7.1,critical_control_failure,tamper_evidence</group>
</rule>

3.3 Notificación de fallo

Cuando una rule pci_dss_10.7.1 dispara:

PagerDuty (CTO + SOC ControlCase)
Slack #fintrixs-incident-response
Email a [email protected] + [email protected]
Auto-creación de ticket en iam_core.pci_audit_events con event_type SECURITY_VIOLATION

SLA: Acuse en ≤15 min para alerts level≥14.

4. Respuesta a fallos (PCI 10.7.2 — los 7 pasos exigidos)

Paso 1 — Restaurar funciones de seguridad

Falla	Acción inmediata
Firewall down	Validar via DO API; reiniciar via `doctl compute firewall update`; activar fallback firewall si tarda >5min
IDS down	Restart Falco/Wazuh via `kubectl rollout restart`; in worst case desplegar emergency rule set
FIM down	Restart wazuh-agent; verificar via `wazuh-control status`
Anti-malware down	Restart ClamAV service; ejecutar emergency scan manual
Audit logging down	Restart pg-multiline-merge.service; failback a Wazuh local indexer; emergency syslog to S3 sink
Auth down	Activar emergency MFA-only access mode; bloquear write operations en payments-api

Paso 2 — Identificar y documentar la duración

Campo	Cómo obtenerlo
Fecha+hora inicio	Wazuh dead-man-switch detection timestamp
Fecha+hora fin	First successful health check post-recovery
Duración	Computed difference
Affected systems	List from monitoring dashboard
Affected services	List from incident channel

Paso 3 — Identificar y documentar la causa raíz

5-whys + reproducción:

¿Qué cambió? (deploy reciente, config change, dependency upgrade)
¿Quién lo cambió? (git blame + audit log)
¿Cuándo? (timestamp del cambio)
¿Por qué se hizo? (PR description + ticket)
¿Cómo se evita en el futuro? (test gap, monitoring gap)

Paso 4 — Abordar issues de seguridad surgidos

Durante el fallo:

Si IDS estuvo down 30min → revisar logs de Wazuh (que sí estuvo arriba) ese mismo 30min en busca de IOCs que IDS hubiera podido perder
Si audit logging estuvo down → ejecutar replay desde fuentes upstream
Si firewall estuvo down → revisar Kong access logs en busca de tráfico anómalo

Paso 5 — Risk assessment para acciones adicionales

Determinar si:

¿Hubo data exposure? (revisar tráfico mientras control down)
¿Se requiere notificación regulatoria? (SBC, CC, otros)
¿Se requiere notificación de cliente?
¿Se requiere análisis forense profundo?

Paso 6 — Implementar controles para evitar recurrencia

Tipo de control
Test automatizado que valide el control crítico
Monitoring adicional (e.g., synthetic probe)
Documentation updated
Training refresh para staff involucrado
PR a infrastructure repo con safeguards

Paso 7 — Reanudación del monitoreo

Verificación
Dead-man-switch rule sigue activa ✓
PagerDuty escalation configurada ✓
Slack channel con bot activo ✓
Próximo daily digest incluirá el incidente ✓

5. Documentación obligatoria (PCI 10.7.3)

Para cada fallo, se genera un ticket SEC-YYYY-NNNN con:

ID:                SEC-YYYY-NNNN
Title:             Critical control failure — <control name>
Severity:          Critical / High
Duration:          YYYY-MM-DD HH:MM UTC → YYYY-MM-DD HH:MM UTC
Root cause:        Free text + 5-whys
Remediation:       Detail of what was done
Risk assessment:   Was there data exposure? Y/N + reasoning
Preventive controls: List
Reporter:          (auto / human)
Reviewer:          CTO + (optional) SOC ControlCase
Status:            OPEN / IN_PROGRESS / RESOLVED / CLOSED

Retención: 7 años (PCI 10.5.1) en git repo + Rapid7 + Spaces archive.

6. Sample tickets de fallos documentados

6.1 Ticket SEC-2026-0524 (Wazuh manager restart — Q45 rotation)

ID:           SEC-2026-0524
Title:        Wazuh manager restart due to credential rotation
Severity:     Medium (planned operation)
Started:      2026-05-27 14:00:32 UTC
Ended:        2026-05-27 14:02:08 UTC
Duration:     1m 36s
Root cause:   Planned config reload after Q45 default password rotation
Remediation:  Validated new credentials work + reloaded indexer + manager
Risk assessment: No data exposure — only 96s of audit log buffering;
                  events queued in agents replayed successfully
Preventive controls: Document rotation procedure in runbook
                     Add 5min freshness check post-rotation
Reporter:     Wazuh rule.id 595 + CTO
Status:       CLOSED

6.2 Ticket SEC-2026-0214 (Hypothetical FIM failure)

ID:           SEC-2026-0214
Title:        wazuh-agent on cde-38q702 stopped reporting
Severity:     Critical
Started:      2026-02-14 03:18:11 UTC (dead-man-switch rule.id 100200)
Ended:        2026-02-14 03:32:08 UTC
Duration:     13m 57s
Root cause:   Kubelet OOM-killed wazuh-agent pod due to memory pressure
              during a large Prometheus scrape; container restart resolved
Remediation:  - Kubelet auto-restart triggered after 60s
              - CTO acknowledged via PagerDuty at 03:21 UTC
              - Verified FIM resumed at 03:32:08 UTC
              - Backfill: Wazuh manager applied missed scans from agent boot
Risk assessment: No data exposure detected in 13m window
                 Other agents on same nodes continued reporting
                 No tampering attempts during outage window
Preventive controls:
  - Increased wazuh-agent memory request from 256Mi to 512Mi
  - Added Prometheus alert for wazuh-agent memory pressure
  - Updated runbook §3.1 with this scenario
Reviewer:     CTO + SOC ControlCase
Status:       CLOSED

7. Vínculos

POL-007 — Incident Response Plan
POL-010 — Logging Monitoring
SOP-007 — Log Review Process
PCI DSS v4.0 Req 10.7.1 + 10.7.2 + 10.7.3

SOP-006: Procedimiento para fallos en controles críticos de seguridad ​

1. Propósito ​

2. Controles críticos en alcance ​

3. Detección de fallos (PCI 10.7.1) ​

3.1 Mecanismos de detección automatizada ​

3.2 Wazuh dead-man-switch rule (PCI 10.7.1 evidence) ​

3.3 Notificación de fallo ​

4. Respuesta a fallos (PCI 10.7.2 — los 7 pasos exigidos) ​

Paso 1 — Restaurar funciones de seguridad ​

Paso 2 — Identificar y documentar la duración ​

Paso 3 — Identificar y documentar la causa raíz ​

Paso 4 — Abordar issues de seguridad surgidos ​

Paso 5 — Risk assessment para acciones adicionales ​

Paso 6 — Implementar controles para evitar recurrencia ​

Paso 7 — Reanudación del monitoreo ​

5. Documentación obligatoria (PCI 10.7.3) ​

6. Sample tickets de fallos documentados ​

6.1 Ticket SEC-2026-0524 (Wazuh manager restart — Q45 rotation) ​

6.2 Ticket SEC-2026-0214 (Hypothetical FIM failure) ​

7. Vínculos ​