PCI DSS Controls Implementation

Overview

Este documento detalla cómo Fintrixs implementa los 12 requisitos de PCI DSS v4.0 para la protección de datos de tarjetas de pago.

---

Requirement 1: Install and Maintain Network Security Controls

1.1 Network Security Controls Defined and Understood

Implementación:

# infra/kong/kong.yaml
API Gateway:
  - IP Restriction plugin
  - Rate limiting
  - Request size limiting

# Kubernetes Network Policies
Network Policies:
  - Deny all by default
  - Allow specific service-to-service
  - Isolate PCI scope

1.2 Network Security Controls Configured and Maintained

Control	Ubicación	Responsable
Firewall rules	Kong + K8s NetworkPolicy	DevOps
DMZ configuration	Kubernetes namespaces	DevOps
Ingress rules	Kong routes	DevOps

1.3 Network Access to CDE Restricted

┌─────────────────────────────────────────────────────────────┐
│                 Cardholder Data Environment                  │
└─────────────────────────────────────────────────────────────┘

  External Network          DMZ              CDE
       │                     │                │
       │                     │                │
  [Internet] ─────> [Kong Gateway] ─────> [Tokenization]
                         │                    │
                    [WAF Rules]          [Vault Schema]
                    [Rate Limit]         [Encrypted]

Servicios en PCI Scope:

• tokenization-service - Procesa PANs
• payments_vault schema - Almacena datos tokenizados

---

Requirement 2: Apply Secure Configurations

2.1 Secure Configuration Standards

Base Images:

# apps/tokenization-service/Dockerfile
FROM node:20-alpine

# No root user
USER node

# Minimal attack surface
RUN apk --no-cache add dumb-init

2.2 Vendor Default Passwords Changed

Checklist:
  ✅ PostgreSQL: Custom passwords via secrets
  ✅ Redis: Password required
  ✅ Kong: Admin API secured
  ✅ Kafka: SASL authentication

2.3 Wireless Security

N/A - Cloud-based infrastructure

---

Requirement 3: Protect Stored Account Data

3.1 Account Data Storage Minimized

// apps/tokenization-service/src/tokenization.service.ts

// PANs are NEVER stored in clear text
// Only tokens are stored in payment records
async tokenize(pan: string): Promise<string> {
  const token = this.generateToken();
  const encrypted = this.encrypt(pan);
  await this.vaultRepository.store(token, encrypted);
  return token; // Only return token, never the PAN
}

3.2 SAD Not Stored After Authorization

Sensitive Authentication Data (SAD):
  - CVV/CVC: NEVER stored
  - Full magnetic stripe: NEVER stored
  - PIN/PIN block: NEVER stored
  
Implementation:
  - Input validation rejects storage attempts
  - No database fields for SAD
  - Audit triggers would catch any attempt

3.3 Stored Data Protected

Encriptación:

-- db/payments_db/vault/migrations/002_create_tokenized_data.sql

CREATE TABLE payments_vault.tokenized_data (
    token VARCHAR(100) PRIMARY KEY,
    encrypted_data BYTEA NOT NULL,  -- AES-256-GCM encrypted
    hmac_hash BYTEA NOT NULL,       -- Integrity verification
    data_type VARCHAR(50),
    ...
);

3.4 Access to Stored PAN Restricted

-- db/payments_db/vault/migrations/003_create_vault_rls.sql

-- RLS Policy: Only vault_user can access
ALTER TABLE payments_vault.tokenized_data ENABLE ROW LEVEL SECURITY;

CREATE POLICY vault_user_policy ON payments_vault.tokenized_data
    FOR ALL
    TO vault_user
    USING (true);

-- Other users cannot access at all

3.5 Primary Account Number Masked

// Display format: **** **** **** 1234
function maskPan(pan: string): string {
  return `**** **** **** ${pan.slice(-4)}`;
}

// API responses NEVER return full PAN

3.6 Cryptographic Keys Secured

Key Type	Storage	Rotation
Master Encryption Key	HashiCorp Vault / K8s Secret	Annual
Data Encryption Key	Derived from Master	Per-transaction
HMAC Key	HashiCorp Vault	Monthly

3.7 Encryption Key Management

Key Lifecycle:
  Generation: Cryptographically secure RNG
  Distribution: Kubernetes secrets / Vault
  Storage: Encrypted at rest
  Rotation: Automated via CronJob
  Destruction: Secure wipe + audit log

---

Requirement 4: Protect Cardholder Data During Transmission

4.1 Strong Cryptography During Transmission

# Kong TLS Configuration
TLS Settings:
  Minimum Version: TLS 1.2
  Cipher Suites:
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_GCM_SHA256

4.2 PAN Secured During Transmission

┌─────────────────────────────────────────────────────────────┐
│              Transmission Security Layers                    │
└─────────────────────────────────────────────────────────────┘

  Client ──[TLS 1.2+]──> Kong ──[mTLS]──> Tokenization ──[TLS]──> Vault
     │                     │                    │                   │
     │                     │                    │                   │
   HTTPS              Internal            Encrypted           Encrypted
   Only               Network             Channel             at Rest

---

Requirement 5: Protect Systems from Malicious Software

5.1 Anti-Malware Solutions Deployed

Container Security:
  - Trivy scanning on CI/CD
  - Runtime protection (Falco)
  - Read-only file systems
  - No shell access in production

5.2 Malicious Software Prevented

# CI/CD Pipeline Checks
pipeline:
  - name: vulnerability-scan
    image: aquasec/trivy
    args: ["image", "--severity", "HIGH,CRITICAL"]
    
  - name: dependency-check
    tool: npm audit / snyk

---

Requirement 6: Develop and Maintain Secure Systems

6.1 Security Vulnerabilities Identified

Tools:
  - Snyk: Dependency scanning
  - SonarQube: SAST
  - OWASP ZAP: DAST
  - npm audit: Node.js vulnerabilities

6.2 Bespoke Software Developed Securely

Secure Development:
  - Code review required
  - Input validation (DTOs)
  - Output encoding
  - Parameterized queries
  - No eval() or dynamic code

Input Validation Example:

// apps/tokenization-service/src/dto/tokenize.dto.ts
export class TokenizeDto {
  @IsString()
  @Matches(/^\d{13,19}$/, { message: 'Invalid card number format' })
  data: string;

  @IsEnum(TokenDataType)
  dataType: TokenDataType;
}

6.3 Security Vulnerabilities Identified and Addressed

Severity	Response Time	Process
Critical	24 hours	Emergency patch
High	7 days	Priority fix
Medium	30 days	Scheduled fix
Low	90 days	Backlog

6.4 Public-Facing Web Applications Protected

# Kong WAF Rules (infra/kong/kong.yaml)
Security Headers:
  - X-Content-Type-Options: nosniff
  - X-Frame-Options: DENY
  - X-XSS-Protection: 1; mode=block
  - Strict-Transport-Security: max-age=31536000
  - Content-Security-Policy: default-src 'self'

---

Requirement 7: Restrict Access to System Components

7.1 Access Limited to Need-to-Know

-- Role-Based Access
api_user    → SELECT, INSERT on payments_api
core_user   → FULL on payments_core
vault_user  → tokenize/detokenize only

-- No user has full database access

7.2 Access Appropriately Defined and Assigned

Service Access Matrix:
  
  payment-service:
    - payments_core: READ/WRITE
    - payments_vault: NONE
    - payments_api: READ
    
  tokenization-service:
    - payments_core: NONE
    - payments_vault: READ/WRITE
    - payments_api: NONE

7.3 Access Managed via Access Control System

# Kubernetes RBAC
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tokenization-service-role
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["vault-credentials"]
    verbs: ["get"]

---

Requirement 8: Identify Users and Authenticate Access

8.1 User Identification Management

User ID Types:
  - merchant_id: UUID for merchants
  - user_id: UUID for dashboard users
  - service_id: Unique per microservice
  - api_key: Unique per integration

8.2 User Identification for System Components

// Every service identifies itself
// packages/logging/src/types/log-context.types.ts
interface LogContext {
  serviceName: string;  // e.g., 'tokenization-service'
  requestId: string;    // UUID per request
  userId?: string;      // User making request
  merchantId?: string;  // Merchant context
}

8.3 Strong Authentication

# JWT Configuration (infra/kong/jwt-auth.yaml)
JWT:
  Algorithm: RS256
  Expiration: 1 hour max
  Claims Required:
    - iss (issuer)
    - exp (expiration)
    - sub (subject)
    - merchant_id

8.4 MFA Implementation

Dashboard Access:
  - TOTP (Google Authenticator)
  - SMS backup (optional)
  - Hardware key (WebAuthn)
  
API Access:
  - IP whitelist + API Key
  - mTLS for internal services

8.5 Credential Management

Passwords:
  - Minimum 12 characters
  - Complexity requirements
  - Hashed with Argon2id
  - Never logged or displayed

API Keys:
  - 256-bit entropy
  - Hashed with SHA-256
  - Rotatable
  - Scoped permissions

---

Requirement 9: Restrict Physical Access

9.1-9.5 Physical Access Controls

Cloud Provider Responsibility:

• AWS/GCP/Azure data centers
• SOC 2 Type II certified
• Physical access logs
• Video surveillance
• Access badges

---

Requirement 10: Log and Monitor All Access

10.1 Audit Logs Implemented

-- db/payments_db/core/migrations/006_create_audit_triggers.sql

CREATE TABLE payments_core.audit_log (
    id UUID PRIMARY KEY,
    event_id VARCHAR(50) UNIQUE,
    event_type VARCHAR(20),     -- INSERT, UPDATE, DELETE, SELECT, LOGIN
    schema_name VARCHAR(100),
    table_name VARCHAR(100),
    record_id VARCHAR(255),
    old_values JSONB,           -- Masked sensitive data
    new_values JSONB,           -- Masked sensitive data
    user_id VARCHAR(255),
    client_ip INET,
    created_at TIMESTAMPTZ,
    sensitivity_level VARCHAR(20)
);

10.2 Audit Logs Include Required Details

Field	PCI Requirement	Implementation
User ID	10.3.1	user_id, database_user
Event Type	10.3.2	event_type
Date/Time	10.3.3	created_at (with timezone)
Success/Failure	10.3.4	Event recorded = success
Origin	10.3.5	client_ip, service_name
Resource	10.3.6	schema_name, table_name, record_id

10.3 Audit Logs Protected

-- Immutable audit logs
-- No DELETE or UPDATE permissions
GRANT SELECT ON payments_core.audit_log TO api_user;
GRANT SELECT, INSERT ON payments_core.audit_log TO core_user;
-- No GRANT DELETE or UPDATE

10.4 Audit Log Review

Automated Alerts:
  - Failed login > 5 attempts
  - Access to vault outside business hours
  - Bulk data access
  - New admin user created
  - Permission changes

10.5 Time Synchronization

# All servers use NTP
NTP:
  Servers:
    - time.google.com
    - time.aws.com
  Accuracy: < 1 second
  Logging: UTC timezone

10.6 Security Event Monitoring

SIEM Integration:
  - Prometheus: Metrics
  - Grafana: Dashboards
  - AlertManager: Alerts
  - ELK Stack: Log aggregation
  
Critical Alerts:
  - P1: Immediate (PagerDuty)
  - P2: 5 minutes (Slack + Email)

10.7 Audit Log Retention

Retention Policy:
  - Standard logs: 90 days online
  - Security logs: 1 year online
  - PCI audit logs: 1 year online, 10 years archive
  - Backup verification: Monthly

---

Requirement 11: Test Security Regularly

11.1 Wireless Access Points Identified

N/A - Cloud-based infrastructure

11.2 Unauthorized Wireless Detected

N/A - Cloud-based infrastructure

11.3 Vulnerability Scans

Internal Scans:
  - Frequency: Weekly
  - Tool: Trivy, Snyk
  - Scope: All containers and dependencies
  
External Scans:
  - Frequency: Quarterly
  - ASV: Approved Scanning Vendor
  - Scope: Public-facing IPs

11.4 Penetration Testing

Penetration Testing:
  - Frequency: Annual
  - Scope: Full CDE
  - Type: Black box + Gray box
  - Remediation: 30 days for critical

11.5 IDS/IPS

Intrusion Detection:
  - Network: Cloud provider IDS
  - Application: Falco (runtime)
  - Log: Suspicious pattern detection

11.6 Change Detection

File Integrity Monitoring:
  - Tool: OSSEC / Falco
  - Scope: Critical binaries, configs
  - Alert: Immediate on change

---

Requirement 12: Support Information Security

12.1 Security Policy

This Documentation:

• README.md - Security overview
• PCI_DSS_CONTROLS.md - This document
• TOKENIZATION_FLOW.md - Data flow

12.2 Acceptable Use Policy

Covered in company policies:
  - Data handling procedures
  - Access request process
  - Incident reporting
  - Acceptable use

12.3 Risks Formally Identified

Risk Assessment:
  - Frequency: Annual
  - Methodology: NIST RMF
  - Documentation: Risk register
  - Review: Quarterly

12.4 PCI DSS Responsibilities Defined

Role	Responsibility
CISO	Overall PCI compliance
DevOps	Infrastructure security
Developers	Secure coding
QA	Security testing
DBA	Database security

12.5 Security Awareness Program

Training:
  - New hire: Security onboarding
  - Annual: PCI DSS refresher
  - Quarterly: Security updates
  - Ad-hoc: Threat briefings

---

Compliance Evidence

Documentation

Document	Location	Last Updated
Security Architecture	docs/security/README.md	Current
PCI Controls	docs/security/PCI_DSS_CONTROLS.md	Current
Tokenization Flow	docs/security/TOKENIZATION_FLOW.md	Current
Network Diagram	docs/architecture/	Current

Technical Evidence

Control	Evidence	Location
Encryption	TLS configs, Vault schema	infra/, db/
Access Control	RLS policies, Kong auth	db/, infra/kong/
Logging	Audit triggers, Logger	db/, packages/logging/
Monitoring	Prometheus configs	infra/monitoring/

---

Annual Review Checklist

• [ ] Review all access rights
• [ ] Rotate all encryption keys
• [ ] Update security documentation
• [ ] Conduct penetration test
• [ ] Review vendor compliance
• [ ] Update risk assessment
• [ ] Security awareness training
• [ ] Incident response drill
• [ ] Backup restoration test
• [ ] Third-party risk review