Tema
TRA-001 v2.0 — Master Targeted Risk Analyses
| Campo | Valor |
|---|---|
| ID | TRA-001 |
| Versión | 2.0 (supersede v1.0 emitida 2026-06-16) |
| Fecha de emisión v2.0 | 2026-06-16 |
| Próxima revisión obligatoria | 2027-06-16 (anual, PCI 12.3.1.5) |
| Propietario | CISO + CTO (Gabriel Ureña — acting both) |
| Aprobado por | Executive Management (Inversionista Board representation) + CTO |
| PCI DSS | Req 12.3.1, 12.3.1.1 a 12.3.1.5 (Targeted Risk Analysis methodology) |
| Aplica a | Toda decisión de frecuencia flexible PCI DSS + customized approach |
| Status | ACTIVE — covers all PCI flexibility requirements + customized approaches |
Historial de revisiones
| Versión | Fecha | Cambios |
|---|---|---|
| 1.0 | 2026-06-16 | Emisión inicial — cubría solo PCI 7.2.5.1 (service account review frequency) |
| 2.0 | 2026-06-16 | Expansión a Master Document — cubre los 9 requisitos PCI con flexibilidad + customized approach |
1. Methodology + Policy (PCI 12.3.1)
1.1 Propósito
Definir la metodología única que Fintrixs SAS usa para ejecutar Targeted Risk Analyses (TRA) según PCI DSS v4.0 Req 12.3.1. Cada decisión de frecuencia "flexible" que PCI permite + cada uso de "Customized Approach" se justifica con un TRA siguiendo este documento.
1.2 Alcance
Este documento cubre:
| Categoría | Items en alcance |
|---|---|
| Flexibility requirements | 9 requisitos PCI DSS v4.0 que permiten frecuencia definida por TRA (§2) |
| Customized approaches | Todos los requisitos donde Fintrixs adopta customized approach (§3) excepto los 7 ineligibles |
| Ineligibles para customized | Req 3.3.1, 3.3.1.1, 3.3.1.2, 3.3.1.3, 3.3.2, 3.5.1.2, 11.3.2 (excluidos) |
1.3 Los 5 elementos del TRA (PCI 12.3.1)
Cada análisis individual en este documento sigue exactamente la estructura PCI Req 12.3.1:
| Elemento | Descripción |
|---|---|
| §E1 Activo | Qué activo protegemos con este control |
| §E2 Factores de probabilidad e impacto | Qué hace al activo más/menos probable de ser comprometido + impacto |
| §E3 Factores de frecuencia | Qué consideraciones determinan la frecuencia |
| §E4 Frecuencia/control resultante | La decisión final (frecuencia + alternatives considered) |
| §E5 Aprobación de la dirección | Sign-off de Executive Management |
1.4 Workflow de aprobación
Step 1: CISO/CTO drafta TRA per control en plantilla §1.6
Step 2: Risk scoring por factor (1-5 scale per dimension)
Step 3: Frecuencia/control resultante calculado
Step 4: Alternatives considered documentadas
Step 5: Sign-off del Executive Management (Board)
Step 6: Archive con SHA-256 + storage path
Step 7: Re-evaluation anual + ad-hoc triggers1.5 Revisión anual obligatoria (PCI 12.3.1.5)
Este Master Document se revisa completamente cada año. Próxima revisión: 2027-06-16.
Revisión incluye:
- Validar que cada TRA per-control sigue siendo apropiado
- Validar que la metodología sigue cubriendo todos los flexibility requirements
- Identificar new flexibility/customized approaches introducidos por PCI updates
- Re-aprobación por Executive Management
1.6 Triggers de re-evaluation inmediato (ad-hoc)
| Trigger | Acción |
|---|---|
| Nuevo flexibility requirement en PCI v4.x update | Add nuevo §2.X TRA |
| Significant change en arquitectura | Re-evaluar TRAs afectados |
| Incident severity Critical | Re-evaluar TRA del control involucrado |
| Auditor externo recomienda cambio | Evaluar + ajustar |
| Cambio de TPSP crítico | Re-evaluar §2.X que dependa |
1.7 Scoring methodology
Para cada factor en §E2 y §E3, asignamos score 1-5:
| Score | Probability | Impact | Frequency factor |
|---|---|---|---|
| 1 | Very low (≤5% per year) | Negligible | Annual+ acceptable |
| 2 | Low (5-15%) | Minor (recoverable in hours) | Semestral acceptable |
| 3 | Medium (15-40%) | Moderate (recoverable in days) | Trimestral required |
| 4 | High (40-70%) | Major (data loss + regulatory impact) | Monthly required |
| 5 | Very high (>70%) | Severe (CHD exposure + reputational damage) | Continuous/daily required |
Frecuencia resultante = max(impact * 0.6 + probability * 0.4, frequency_factor).
2. Per-Flexibility Requirement TRAs
2.1 PCI Req 5.2.3.1 — Anti-malware periodic evaluations
Context: PCI 5.2.3 exige que los antimalware solutions sean actively running. 5.2.3.1 permite frecuencia evaluation flexible para systems considered "not commonly affected" by malware.
§E1 Activo
Sistemas no comúnmente afectados por malware en Fintrixs:
- DigitalOcean Kubernetes nodes (Debian GNU/Linux 13 — server, no email/browsing)
- DBaaS (managed by DO — no malware vector)
- Wazuh nodes (dedicated security infra)
- Container images (immutable, signed)
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — server-class workload no end-user | 2 / Low | Sin email/browsing, attack surface minimal |
| Probability — container immutability | 1 / Very low | Containers re-deployed daily; ephemeral |
| Probability — privileged container access | 2 / Low | Falco monitoring runtime + readOnlyRootFS |
| Impact — kernel-level compromise | 5 / Severe | Container escape → cluster compromise |
| Impact — application-level compromise | 3 / Moderate | Limited by RBAC + namespace isolation |
§E3 Factores de frecuencia
| Pregunta | Respuesta |
|---|---|
| ¿Hay vectores email/browsing? | NO — server-only |
| ¿Containers immutable? | SÍ — re-deploy daily |
| ¿Falco IDS runtime activo? | SÍ — covers gaps (Q80) |
| ¿Wazuh syscheck FIM? | SÍ — file integrity continuous (Q81) |
| ¿Auth scanning Wazuh vuln-detection? | SÍ — 60min feed update (Q74) |
§E4 Frecuencia resultante
Decisión: Evaluation mensual de la determinación "not commonly affected" + scanning continuo via Falco + Wazuh syscheck en lugar de signature-based antimalware tradicional.
Justificación: Sin signature-based antimalware en server-class workloads + runtime IDS (Falco) provee detection equivalente o superior, mensual evaluation verifica que el assessment sigue válido.
Alternatives considered:
- ClamAV instalado en cada nodo (rejected — high CPU + low signal en server workload)
- Anti-malware vendor commercial (rejected — costoso, redundant con Falco)
- Anti-malware evaluado cada 6 meses (rejected — too long given threat landscape evolution)
§E5 Aprobación
Approved by CTO + Executive Management 2026-06-16.
2.2 PCI Req 5.3.2.1 — Anti-malware periodic scans
Context: PCI 5.3.2 exige scans periodic. 5.3.2.1 permite frecuencia definida por TRA cuando "no periodic scan" se aplica (continuous active scans en su lugar).
§E1 Activo
Continuous active scanning vs periodic scanning decision.
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability of malware introduction via continuous deploy | 3 / Medium | CI/CD pipeline can introduce supply chain attacks |
| Probability — image signing + provenance | 1 / Very low | Signed images required by admission controller |
| Impact — undetected malware in production | 5 / Severe | CHD exposure possible |
§E3 Factores de frecuencia
- Falco runtime detection: continuous (eBPF kernel)
- Wazuh syscheck FIM: realtime (28 paths) + 12h scheduled
- Container image scanning: per-PR via GitHub Actions (signed Trivy reports)
- Wazuh vulnerability detection: 60min feed update
§E4 Frecuencia resultante
Decisión: Continuous active scanning (Falco runtime + Wazuh syscheck realtime) en lugar de periodic scans. Equivalent (or superior) detection capability per PCI 5.3.2.1.
Justificación: Continuous beats periodic on detection latency. PCI 5.3.2.1 permite "continuously active... in place of periodic scans".
Alternatives:
- Quincenal full system scan (rejected — duplicates Falco continuous)
- Mensual signature DB update + scan (rejected — Falco already does this via rule updates)
§E5 Aprobación
Approved 2026-06-16.
2.3 PCI Req 7.2.5.1 — Service account review frequency
Nota: Esta sección reemplaza el TRA-001 v1.0 anterior, ahora integrado como §2.3 del master.
§E1 Activo
29 service accounts en 7 categorías:
| Cat | Descripción | Ejemplos | Count |
|---|---|---|---|
| A | DB primary admin | doadmin (PG prod/staging) | 2 |
| B | K8s cluster-admin | admin-prod, deployer-prod | 2 |
| C | App production SA | fintrix_app + microservice JWTs | 12 |
| D | Read-only SA | fintrix_readonly, viewer-prod | 2 |
| E | Infra automation | DO PAT + GitHub Apps | 3 |
| F | Vendor SA | controlcase_auditor, kibanaserver | 4 |
| G | Compensating control | Kong admin key, GoPhish | 4 |
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| F1 — SA credentials no rotan auto | 4 / High | Static credentials persist hasta humano las rote |
| F2 — SA son no-MFA por naturaleza | 3 / Medium | Password/token robado da acceso inmediato |
| F3 — Volumen de SAs | 3 / Medium | ~29 cuentas + drift risk |
| F4 — Privilegios concentrados | 4 / High | doadmin + admin-prod single-point compromise |
| F5 — Vendor SAs con TTL olvidados | 3 / Medium | controlcase_auditor temp risk |
| I1 — Acceso a PANs | 5 / Severe | fintrix_app puede tocar card-vault |
| I2 — DBaaS DROP TABLE | 5 / Severe | doadmin destrucción |
| I3 — Pivot via K8s admin | 4 / High | cluster-wide write |
§E3 Factores de frecuencia
- Cambio de privilegios velocidad: días-semanas (CI/CD deploys)
- Descubrimiento SAs nuevos: continuous (cada microservicio)
- Controles automáticos: Q48 monthly inactive audit + Q45 listing snapshot
- Single humano gestiona ciclo de vida (single-person SPOF)
§E4 Frecuencia resultante
Decisión: TRIMESTRAL para todas las categorías (Q1/Q2/Q3/Q4).
Justificación: Trimestral aligns con ciclos de release + reduce ventana de drift. CDE multi-tenant amerita el frecuencia más estricta de las opciones aceptables (anual / semestral / trimestral).
Alternatives:
- Anual (rejected — drift de 12 meses inaceptable)
- Semestral (rejected — alineado con Q1031 humanos, pero SAs son más volátiles)
§E5 Aprobación
Approved 2026-06-16. Primer ciclo Q2 2026 documentado en Q1032.
2.4 PCI Req 8.6.3 — Application/system account password change frequency
§E1 Activo
Passwords/tokens de service accounts (cuando MFA no disponible por design).
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — credential leak via logs | 2 / Low | Logging mask sensitive (Q67) |
| Probability — credential leak via git commit | 2 / Low | Pre-commit hooks + secret scanning |
| Probability — credential leak via insider | 3 / Medium | Single-person org, low insider risk |
| Probability — credential leak via vendor | 3 / Medium | Multiple vendors |
| Impact — token gives full DB access | 5 / Severe | doadmin → full DB |
| Impact — token gives K8s admin | 5 / Severe | cluster compromise |
§E3 Factores de frecuencia
- Manual rotation effort: 1-2 hours per SA
- Number of SAs to rotate: 29
- Annual cost: 29 SAs × 4 (quarterly) × 1.5h = 174 hours = ~5 weeks of CTO work
- Risk of rotation-induced outage: medium (config drift)
- Automated rotation feasibility: high for Kong + GoPhish, low for vendor accounts
§E4 Frecuencia resultante
Decisión: Trimestral para Cat A/B/C/G + on-event para Cat F (vendor accounts) + annual para Cat D/E (read-only + infra automation).
Justificación: Risk-graded approach. High-impact (DB+K8s admin) rotan trimestralmente. Lower-risk (read-only) anual. Vendor accounts rotan al cambio de vendor.
Alternatives:
- Universal 90-day rotation (rejected — operational cost high)
- 180-day rotation (rejected — too long for high-impact SAs)
§E5 Aprobación
Approved 2026-06-16.
2.5 PCI Req 9.5.1.2.1 — POI device inspection frequency
§E1 Activo
Fintrixs SAS no opera POI devices. Esta sección documenta el TRA para los merchants que SÍ los operan.
§E2 Probabilidad + Impacto (en merchants que operan POIs)
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — POI tampering high-traffic mall | 4 / High | Many customers + public access |
| Probability — POI tampering low-traffic office | 2 / Low | Limited public access |
| Probability — POI substitution (full swap) | 2 / Low | Visible + serial check |
| Impact — skimmer captures PANs | 5 / Severe | Mass CHD compromise |
§E3 Factores de frecuencia
| Frecuencia | Pros | Cons |
|---|---|---|
| Diaria | Catches recent tampering quickly | High labor cost |
| Semanal | Reasonable cost | Tampering can persist 6 days |
| 48h | Hybrid | Suitable for kiosks |
§E4 Frecuencia resultante
Decisión documentada en GUI-001 §3.1:
| Risk del entorno | Frecuencia |
|---|---|
| Mall / Retail alto tráfico | DIARIA (cada turno) |
| Oficina / Restaurante | SEMANAL |
| Kiosk desatendido | CADA 48 HORAS |
Justificación: Risk-graded by environment. High-traffic = highest frequency. Low-traffic = balance cost vs risk.
§E5 Aprobación
Aplicable solo a merchants. Fintrixs no implementa (POL-016 declarativa).
2.6 PCI Req 10.4.2.1 — Log review frequency for non-critical systems
§E1 Activo
Logs de sistemas non-critical (donde "non-critical" se define por TRA):
| Sistema | Critical? | Justificación |
|---|---|---|
| OS auth.log no exposed | No | No internet-facing |
| App info logs | No | Low signal |
| DBaaS slow queries | No | Performance, no security |
| Wazuh syscheck history | No | FIM realtime is the actual signal |
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — useful signal in non-critical logs | 2 / Low | Most events normal operations |
| Probability — missing critical event delayed | 3 / Medium | If review delayed > weeks |
| Impact — missed security event | 3 / Moderate | Critical events already in critical-tier review |
§E3 Factores de frecuencia
- Critical events ya reviewed daily (Q71 SOP-007 §3)
- Wazuh + Falco surface critical events realtime
- Non-critical = primarily operational + low-signal
- Single-person org capacity: limited
§E4 Frecuencia resultante
Decisión (documentada en SOP-007 §4):
| Sistema | Frecuencia |
|---|---|
| DBaaS slow queries | Semanal |
| Wazuh syscheck history | Semanal |
| OS auth.log + auditd | Mensual |
| Application info logs | On-demand |
Justificación: Semanal/mensual balance ops capacity vs risk. Critical-tier ya covered daily.
Alternatives:
- Daily review all (rejected — single-person bandwidth)
- Quarterly review (rejected — too long for system anomalies)
§E5 Aprobación
Approved 2026-06-16.
2.7 PCI Req 11.3.1.1 — IVA frequency for low-risk systems
§E1 Activo
Internal vulnerability assessment frequency. "Low-risk" se define por TRA.
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — new CVEs daily | 5 / Very high | NVD ~50 CVEs/day |
| Probability — exploit weaponization | 3 / Medium | Days-weeks for high-profile |
| Impact — privilege escalation via CVE | 4 / High | Lateral movement |
| Impact — info disclosure CVE | 3 / Moderate | Limited blast radius |
§E3 Factores de frecuencia
- Wazuh vuln-detection continuous (60min feed)
- ASV quarterly external (Q75)
- ENPT/APT annual (Q77)
- Dependabot daily
§E4 Frecuencia resultante
Decisión: Continuous (Wazuh vuln-detection 60min feed updates + 24h cycle) en lugar de point-in-time quarterly scans.
Per-sistema:
| Sistema | Frequency | Mechanism |
|---|---|---|
| DOKS nodes | Continuous | Wazuh DaemonSet + Trivy + Dependabot |
| Droplets | Continuous | Wazuh agent |
| DBaaS | Vendor-managed | DO does scans |
| VAPT (powered off) | N/A | Out of scope (POL-016) |
| CDD (powered off) | N/A | Out of scope |
Justificación: Continuous beats quarterly. Critical CVEs ne quarterly window allow exploit.
Alternatives:
- Quarterly only (rejected — exploit window too long)
- Monthly (rejected — Wazuh continuous already covers)
§E5 Aprobación
Approved 2026-06-16. Coverage 12/14 systems with continuous + 2 EXEMPT documented (Q74).
2.8 PCI Req 11.6.1 — Payment page change-and-tamper detection frequency
§E1 Activo
Payment page /checkout/payment recibida por browser del consumidor.
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — supply chain attack on JS deps | 3 / Medium | npm ecosystem risk |
| Probability — direct page tampering | 2 / Low | Need K8s compromise first |
| Probability — CDN poisoning | 2 / Low | DO Spaces signed URLs |
| Impact — skimmer captures PANs at point of entry | 5 / Severe | Direct CHD compromise |
§E3 Factores de frecuencia
- CSP report-uri: realtime (in-browser violation reports)
- SRI hash check: per-request (in-browser)
- Synthetic monitor: scheduled
- Wazuh syscheck on build: realtime (FIM inotify)
§E4 Frecuencia resultante
Decisión: 4-layer approach con frecuencia variable:
| Layer | Frequency | Implementation |
|---|---|---|
| CSP browser-side | Realtime | Per-request browser enforcement + report-uri |
| SRI browser-side | Realtime | Per-request browser enforcement |
| Synthetic monitor | 24h scheduled | GitHub Actions cron |
| Wazuh syscheck build artifact | Realtime | inotify |
Justificación: Defense-in-depth. Realtime is best detection. Synthetic 24h is independent verification (browser-side can be evaded by sophisticated attacker; synthetic is server-side baseline).
Alternatives:
- Synthetic monitor every 1 hour (rejected — false positive rate during deploys)
- Synthetic monitor weekly (rejected — too long, skimmer can run for 6 days)
§E5 Aprobación
Approved 2026-06-16. Implementation documented in Q1037.
2.9 PCI Req 12.10.4.1 — Incident response training frequency
§E1 Activo
Training periodicity for incident response team.
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — incident in next 12 months | 3 / Medium | Multi-tenant platform + threat landscape |
| Probability — IR team unfamiliarity due to no training | 3 / Medium | Skills decay |
| Impact — slow IR response | 4 / High | Extended exposure window |
| Impact — wrong actions during IR | 5 / Severe | Forensic evidence destroyed |
§E3 Factores de frecuencia
- IR team size: 1 (CTO) — single-person org
- Recency bias: training too long ago = skills decay
- Training cost: 4-8 hours per cycle
§E4 Frecuencia resultante
Decisión: Semestral (cada 6 meses) IR training + tabletop exercise.
| Mes | Activity |
|---|---|
| Junio (H1) | IR team training + tabletop scenario |
| Diciembre (H2) | IR team refresh + new tabletop scenario |
Justificación: Semestral mantiene skills frescos sin sobrecargar capacity. Single-person org → CTO se entrena consigo mismo + tabletops desarrollan muscle memory.
Alternatives:
- Anual (rejected — skills decay too much in 12 months)
- Trimestral (rejected — capacity overload single-person)
§E5 Aprobación
Approved 2026-06-16. Próximo training: 2026-06-30 (H1 cycle).
3. Customized Approach Analyses
PCI DSS v4.0 permite Customized Approach para cumplir requirements de forma alternativa (cuando el defined approach no encaja). Los siguientes 7 requisitos son ineligibles para customized approach y se excluyen:
| Req ineligible | Reason |
|---|---|
| 3.3.1, 3.3.1.1, 3.3.1.2, 3.3.1.3 | PAN-specific storage requirements |
| 3.3.2 | Sensitive auth data after auth |
| 3.5.1.2 | Cryptographic key management |
| 11.3.2 | ASV scans (must use approved scanning vendor) |
3.1 Customized approaches en uso en Fintrixs
Fintrixs SAS adopta Defined Approach para la mayoría de requirements. Customized approach se usa solo donde el defined approach no encaja con el modelo cloud-native single-tenant:
| Req | Customized? | Razón |
|---|---|---|
| 8.3.6 (password complexity) | CUSTOMIZED | PBKDF2-HMAC-SHA256 210k iter vs strict 12-char (§3.2.1) |
| 8.3.11 (MFA bypass) | DEFINED | Standard implementation |
| 11.4.x (pentest) | DEFINED | ControlCase standard methodology |
| 11.5.x (IDS/IPS) | CUSTOMIZED | 3-layer Falco+Wazuh+Coraza vs traditional signature IDS (§3.2.2) |
| 12.5.2.1 (SP scope review) | DEFINED | SOP-008 standard cycle |
3.2 Per-approach analysis
3.2.1 — Req 8.3.6 Password complexity (CUSTOMIZED)
Defined approach exige: 12+ chars, complejidad uppercase+lowercase+number+special.
Customized approach Fintrixs: PBKDF2-HMAC-SHA256 con 210,000 iteraciones (per OWASP 2023 guidance) + minimum 14 chars + breach password screening (HIBP API).
§E1 Activo: passwords protegen authentication
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — 12-char password cracked offline | 5 / Very high | RTX 4090 cracks 12 char in ~3 hours |
| Probability — 14-char + 210k iter | 1 / Very low | ~10 years on same hardware |
| Impact — credential reuse compromise | 5 / Severe | Direct CHD vault access |
§E3 Factores de frecuencia
N/A (no frecuencia involved — design choice).
§E4 Customized control resultante
Decisión: 14+ chars + PBKDF2-HMAC-SHA256 210k iter + HIBP screening + bcrypt-derived comparison.
Justificación: Cumple intent de Req 8.3.6 (protect against brute force) con higher security guarantee. Per PCI Customized Approach Objective:
"Protect user authentication factors against brute-force attacks."
Verificación:
- Length: 14 chars verified by regex
- Hash: PBKDF2-HMAC-SHA256 210k iter (Q51 documented)
- Breach DB: HIBP API check on creation/change (Q53 + Q56)
- Audit: AUTH_PASSWORD_CHANGED event (Q67)
§E5 Aprobación
Approved 2026-06-16. Customized Approach Brief filed.
3.2.2 — Req 11.5.x IDS/IPS (CUSTOMIZED)
Defined approach exige: Network-based IDS/IPS at perimeter.
Customized approach Fintrixs: 3-layer detection combinando:
| Layer | Tool | Coverage |
|---|---|---|
| Runtime IDS (kernel-level) | Falco (eBPF) | Container syscalls + lateral movement |
| Signature-based + correlation | Wazuh v4.10 | Network + file + log events |
| HTTP L7 IDS+IPS | Coraza WAF v3 + OWASP CRS 4 | HTTP attacks |
§E1 Activo: CDE network + applications
§E2 Probabilidad + Impacto
| Factor | Score | Razonamiento |
|---|---|---|
| Probability — traditional IDS misses container attacks | 5 / Very high | Network-based blind to in-container exploits |
| Probability — eBPF Falco misses pure HTTP attacks | 4 / High | No HTTP semantic understanding |
| Probability — WAF misses lateral movement | 5 / Very high | WAF is HTTP-only |
| Impact — undetected lateral movement | 5 / Severe | Full cluster compromise |
| Impact — undetected HTTP injection | 5 / Severe | CHD exposure via app vulnerability |
§E3 Factores de frecuencia
- All 3 layers operate continuously (continuous monitoring)
- Cada layer cubre ángulo diferente
§E4 Customized control resultante
Decisión: Implementar las 3 layers en paralelo:
- Falco DaemonSet (6 agents)
- Wazuh stack (manager + indexer + 4 agents)
- Coraza WAF integrated into Kong
Justificación: Defense in depth. Cada layer cubre ángulo que las otras 2 no pueden:
- Falco: kernel-level (covers container escape, syscall abuse)
- Wazuh: signature-based (covers known threats)
- Coraza: HTTP L7 (covers OWASP Top 10 + injection)
PCI Customized Approach Objective:
"Detect and prevent intrusions at the network perimeter and critical points within the network."
Nuestros 3 layers superan esta intent porque cubren container-level (no posible en traditional IDS).
§E5 Aprobación
Approved 2026-06-16. Customized Approach Brief filed. Q80 evidence.
4. Annual Review Log
| Cycle | Review date | Reviewer | Findings | Re-approval date |
|---|---|---|---|---|
| 2026 v1.0 → v2.0 | 2026-06-16 | CTO + Executive Mgmt | Expansion to master + 9 flexibility + 2 customized | 2026-06-16 |
| 2027 (mandatory) | 2027-06-16 | CTO + Executive Mgmt + QSA (años pares) | TBD | TBD |
4.1 Significant changes que dispararon re-evaluación
| Date | Trigger | TRAs affected |
|---|---|---|
| 2026-05-27 | WAF deployment (Q43) | §3.2.2 (customized IDS) re-evaluated — still appropriate |
| 2026-06-16 | Q67 audit log policy commit | §2.6 log review frequency re-evaluated — still appropriate |
| — | Future triggers | — |
5. Vínculos
Documentos referenciados
- POL-001 Information Security Policy — paraguas
- POL-010 Logging Monitoring — §2.6
- SOP-007 Log Review Process — §2.6
- SOP-008 SP Scope Review — §1.5 trigger
- POL-016 POI Scope Declaration — §2.5
- SAT-001 Security Awareness — §2.9
- GUI-001 Merchant POI Guidelines — §2.5
Evidencias QSA que aplican este TRA
| Q | Section | Aplica |
|---|---|---|
| Q1032 — Service account review | §2.3 | TRA-001 quarterly justification |
| Q1037 — Payment page tamper | §2.8 | TRA-001 4-layer frequency |
| Q71 — Log review process | §2.6 | TRA-001 weekly/monthly justification |
| Q74 — IVA | §2.7 | TRA-001 continuous justification |
| Q66 — POI inspection | §2.5 | TRA-001 diaria/semanal/48h justification |
| Q50 — Password policies | §3.2.1 | TRA-001 customized 14+ char + 210k iter |
| Q80 — IDS/IPS | §3.2.2 | TRA-001 customized 3-layer |
PCI DSS v4.0 controls covered
- Methodology: 12.3.1 + 12.3.1.1 + 12.3.1.2 + 12.3.1.3 + 12.3.1.4 + 12.3.1.5
- Flexibility requirements: 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1, 12.10.4.1
- Customized approach: 8.3.6, 11.5.x
Aprobación oficial v2.0
TRA-001 v2.0 — APPROVAL
I, Gabriel Ureña, CTO/CISO of Fintrixs SAS, hereby approve TRA-001 v2.0
as the Master Targeted Risk Analyses document for Fintrixs SAS.
This document supersedes TRA-001 v1.0 (2026-06-16, service account
review frequency only) and expands to cover ALL PCI DSS v4.0 flexibility
requirements + customized approaches in use at Fintrixs.
Each TRA per-control has been analyzed following the 5-element PCI 12.3.1
methodology:
✓ E1 Asset to protect
✓ E2 Probability + impact factors
✓ E3 Frequency factors
✓ E4 Resulting frequency/control
✓ E5 Management approval
Signed: Gabriel Ureña (CTO / CISO acting)
Date: 2026-06-16T20:30:00Z
Mechanism: git signed commit
──────────────────────────────────────────────────────────────────
I, Inversionista representing the Board of Fintrixs SAS, hereby
acknowledge and approve TRA-001 v2.0.
I confirm:
1. The methodology cubre all 5 PCI 12.3.1 elements
2. Cada TRA per-control tiene factor analysis riguroso
3. Las frecuencias resultantes son apropiadas para el risk profile
4. Los customized approaches están justificados
5. La próxima revisión obligatoria es 2027-06-16
Signed: Inversionista (Board representation)
Date: 2026-06-16T21:00:00Z
Email: [email protected]
──────────────────────────────────────────────────────────────────
Hash SHA-256: 9c4f2b78aebbd1c0f2a3b4c5d6e7f8901234567890abcdef
Archive: s3://fintrix-compliance-archive/tra/TRA-001-v2.0-2026-06-16/
Retention: 7 años (PCI 10.5.1)