Chapter 26: Security and Compliance

26.1 Overview

This chapter covers security architecture, PCI-DSS compliance requirements, data protection strategies, and security audit procedures for the POS Platform.

26.2 Security Architecture

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                              SECURITY LAYERS                                         │
└─────────────────────────────────────────────────────────────────────────────────────┘

                              INTERNET
                                 │
                    ┌────────────┴────────────┐
                    │      WAF / DDoS         │  Layer 1: Edge Security
                    │    (Cloudflare/AWS)     │  - Rate limiting
                    └────────────┬────────────┘  - Bot protection
                                 │               - Geo-blocking
                    ┌────────────┴────────────┐
                    │     Load Balancer       │  Layer 2: TLS Termination
                    │   (TLS 1.3 only)        │  - Certificate management
                    └────────────┬────────────┘  - HSTS enforcement
                                 │
         ┌───────────────────────┼───────────────────────┐
         │                       │                       │
┌────────┴────────┐    ┌────────┴────────┐    ┌────────┴────────┐
│   POS API       │    │   POS API       │    │   POS API       │
│   (Container)   │    │   (Container)   │    │   (Container)   │
│                 │    │                 │    │                 │
│ Layer 3:        │    │ - JWT Auth      │    │ - Input Valid.  │
│ Application     │    │ - RBAC          │    │ - Output Encod. │
└────────┬────────┘    └────────┬────────┘    └────────┬────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                    ┌────────────┴────────────┐
                    │    Network Firewall     │  Layer 4: Network
                    │   (Docker Network)      │  - Microsegmentation
                    └────────────┬────────────┘  - No direct DB access
                                 │
         ┌───────────────────────┼───────────────────────┐
         │                       │                       │
┌────────┴────────┐    ┌────────┴────────┐    ┌────────┴────────┐
│   PostgreSQL    │    │     Redis       │    │   RabbitMQ      │
│                 │    │                 │    │                 │
│ Layer 5:        │    │ - Encrypted     │    │ - TLS enabled   │
│ Data Layer      │    │ - Auth required │    │ - Auth required │
│                 │    │                 │    │                 │
│ - Encryption    │    │                 │    │                 │
│ - Row-level sec │    │                 │    │                 │
└─────────────────┘    └─────────────────┘    └─────────────────┘

26.3 PCI-DSS Compliance Checklist

Complete 12 Requirements

# PCI-DSS v4.0 Compliance Checklist for POS Platform

## 26.4 REQUIREMENT 1: Install and Maintain Network Security Controls

### 1.1 Network Security Policies
- [x] Firewall rules documented
- [x] Network diagram maintained
- [x] All connections reviewed quarterly
- [x] Traffic restrictions enforced

### 1.2 Network Configuration Standards
- [x] Default passwords changed on all devices
- [x] Unnecessary services disabled
- [x] Security patches applied within 30 days
- [x] Anti-spoofing measures implemented

### Implementation
```bash
# Docker network isolation
docker network create --driver bridge \
  --subnet=172.28.0.0/16 \
  --opt com.docker.network.bridge.enable_ip_masquerade=true \
  pos-secure-network

# Firewall rules (iptables)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -j DROP

26.5 REQUIREMENT 2: Apply Secure Configurations

2.1 System Configuration Standards

• Hardened container images (Alpine-based)
• Non-root container execution
• Minimal installed packages
• Security benchmarks applied (CIS)

2.2 Secure Defaults

• Default accounts disabled/removed
• Vendor defaults changed
• Unnecessary functionality removed

Implementation

# Secure Dockerfile practices
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine

# Remove unnecessary packages
RUN apk del --purge wget curl || true

# Non-root user
RUN addgroup -S posgroup && adduser -S posuser -G posgroup
USER posuser

# Read-only filesystem where possible
RUN chmod -R 555 /app

26.6 REQUIREMENT 3: Protect Stored Account Data

3.1 Data Retention Policy

• Card data retention minimized
• PAN stored only when necessary (we don’t store)
• Quarterly purge of unnecessary data
• Documented retention periods

3.2 Sensitive Authentication Data

• Full track data NOT stored ✓
• CVV/CVC NOT stored ✓
• PIN/PIN block NOT stored ✓

3.3 PAN Display Masking

• PAN masked on display (show last 4 only)
• Full PAN not logged

3.4 PAN Rendering Unreadable

• We use tokenization (no PAN stored)
• Stripe tokens reference only

What We Store vs. Don’t Store

26.7 REQUIREMENT 4: Protect Data in Transit

4.1 Encryption Standards

• TLS 1.2+ for all transmissions
• TLS 1.3 preferred
• Strong cipher suites only
• Certificate validation enforced

4.2 Wireless Security

• WPA3 for wireless POS terminals
• No open wireless networks
• Wireless IDS monitoring

Implementation

# Nginx TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

# HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

26.8 REQUIREMENT 5: Protect from Malicious Software

5.1 Anti-Malware Deployment

• Container scanning in CI/CD
• Runtime malware detection
• Automatic signature updates

5.2 Anti-Phishing

• Email filtering enabled
• User awareness training
• SPF/DKIM/DMARC configured

Implementation

# CI/CD container scanning (GitHub Actions)
- name: Container Security Scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: pos-api:${{ github.sha }}
    severity: 'CRITICAL,HIGH'
    exit-code: '1'

26.9 REQUIREMENT 6: Develop and Maintain Secure Systems

6.1 Secure Development Lifecycle

• Security requirements in design phase
• Code review mandatory
• SAST (Static Analysis) in CI
• DAST (Dynamic Analysis) pre-release

6.2 Change Control

• All changes documented
• Security impact assessment
• Rollback procedures defined
• Separation of dev/test/prod

6.3 Vulnerability Management

• Known vulnerabilities addressed
• Security patches within 30 days (critical)
• Dependency scanning automated

26.10 REQUIREMENT 7: Restrict Access to System Components

7.1 Access Control Model

• Role-based access control (RBAC)
• Least privilege principle
• Access reviews quarterly
• Default deny policy

7.2 Access Control System

• Unique user IDs
• MFA for admin access
• Session timeout enforced

Access Control Matrix

26.11 REQUIREMENT 8: Identify Users and Authenticate Access

8.1 User Identification

• Unique user IDs for all users
• Shared accounts prohibited
• User ID policy documented

8.2 Authentication Management

• Password complexity enforced
• Password history (12 passwords)
• Account lockout (5 failures)
• Session timeout (15 minutes inactive)

8.3 Multi-Factor Authentication

• MFA for remote access
• MFA for admin consoles
• MFA for cardholder data access

Implementation

// Password policy configuration
services.Configure<IdentityOptions>(options =>
{
    options.Password.RequiredLength = 12;
    options.Password.RequireDigit = true;
    options.Password.RequireLowercase = true;
    options.Password.RequireUppercase = true;
    options.Password.RequireNonAlphanumeric = true;
    options.Password.RequiredUniqueChars = 4;

    options.Lockout.DefaultLockoutTimeSpan = TimeSpan.FromMinutes(30);
    options.Lockout.MaxFailedAccessAttempts = 5;
    options.Lockout.AllowedForNewUsers = true;
});

26.12 REQUIREMENT 9: Restrict Physical Access

9.1 Physical Security

• Data center access controlled
• Visitor logs maintained
• Badge access for sensitive areas

9.2 Media Protection

• Media inventory maintained
• Secure media destruction
• Media transport security

9.3 POS Device Security

• Device inventory maintained
• Tamper-evident labels
• Regular device inspection

26.13 REQUIREMENT 10: Log and Monitor All Access

10.1 Audit Logging

• All access logged
• Log integrity protected
• Logs retained 1 year (3 months online)

10.2 Log Content

• User identification
• Event type
• Date/time
• Success/failure
• Affected resource

10.3 Log Review

• Daily log review
• Automated anomaly detection
• Incident correlation

Implementation

// Audit logging configuration
public class AuditLogEntry
{
    public Guid Id { get; set; }
    public DateTime Timestamp { get; set; }
    public string UserId { get; set; }
    public string UserName { get; set; }
    public string EventType { get; set; }  // Login, Access, Modify, Delete
    public string Resource { get; set; }
    public string ResourceId { get; set; }
    public bool Success { get; set; }
    public string IpAddress { get; set; }
    public string UserAgent { get; set; }
    public string Details { get; set; }  // JSON of changes
}

26.14 REQUIREMENT 11: Test Security Regularly

11.1 Vulnerability Scanning

• Internal scans quarterly
• External scans quarterly
• Rescans after changes

11.2 Penetration Testing

• Annual penetration test
• Test after significant changes
• Remediation verified

11.3 Change Detection

• File integrity monitoring
• Configuration drift detection
• Unauthorized change alerts

Vulnerability Scanning Schedule

26.15 REQUIREMENT 12: Support Security with Policies

12.1 Security Policy

• Information security policy documented
• Annual policy review
• Policy accessible to all staff

12.2 Risk Assessment

• Annual risk assessment
• Risk register maintained
• Risk treatment plans

12.3 Security Awareness

• Security training for all staff
• Annual refresher training
• Role-specific training

12.4 Incident Response

• Incident response plan
• Annual plan testing
• Breach notification procedures

---

## 26.16 Tokenization Flow

┌─────────────────────────────────────────────────────────────────────────────────────┐ │ PAYMENT TOKENIZATION FLOW │ └─────────────────────────────────────────────────────────────────────────────────────┘

STEP 1: Customer Enters Card ┌───────────────┐ │ POS Client │ Customer swipes/taps/enters card │ │ Card data NEVER touches our servers └───────┬───────┘ │ Card data (encrypted) ▼ ┌───────────────┐ │ Stripe.js │ Client-side SDK handles card data │ (Browser) │ Tokenization happens in secure iframe └───────┬───────┘ │ HTTPS (TLS 1.3) ▼ ┌───────────────┐ │ Stripe │ PCI Level 1 certified │ Servers │ Card data stored securely └───────┬───────┘ │ Payment Token (tok_xxx) ▼ ┌───────────────┐ │ POS Client │ Receives token, NOT card data │ │ └───────┬───────┘ │ Token + amount ▼ ┌───────────────┐ │ POS API │ Our server sees ONLY token │ Server │ Never handles raw card data └───────┬───────┘ │ Charge request with token ▼ ┌───────────────┐ │ Stripe │ Processes payment │ Servers │ Returns charge ID └───────┬───────┘ │ Charge result ▼ ┌───────────────┐ │ POS API │ Stores transaction record │ Server │ Stores: token, last4, amount └───────────────┘ Does NOT store: full PAN, CVV

WHAT WE STORE: ┌─────────────────────────────────────────────────────┐ │ Transaction Record │ ├─────────────────────────────────────────────────────┤ │ transaction_id: “txn_abc123” │ │ stripe_charge_id: “ch_xyz789” │ │ stripe_token: “tok_xxx” (reference only) │ │ card_last4: “4242” (masked) │ │ card_brand: “Visa” │ │ amount: 99.99 │ │ status: “completed” │ │ created_at: “2025-12-29T10:30:00Z” │ └─────────────────────────────────────────────────────┘

WHAT WE NEVER STORE: ┌─────────────────────────────────────────────────────┐ │ ❌ Full card number (PAN) │ │ ❌ CVV/CVC │ │ ❌ PIN │ │ ❌ Track data │ │ ❌ Expiration date (optional, encrypted if stored) │ └─────────────────────────────────────────────────────┘

---

## 26.17 Network Segmentation

┌─────────────────────────────────────────────────────────────────────────────────────┐ │ NETWORK SEGMENTATION │ └─────────────────────────────────────────────────────────────────────────────────────┘

                     ┌─────────────────────────────┐
                     │      INTERNET (Untrusted)   │
                     └──────────────┬──────────────┘
                                    │
                     ┌──────────────┴──────────────┐
                     │         DMZ ZONE            │
                     │    (172.28.1.0/24)          │
                     │                             │
                     │  ┌──────────┐ ┌──────────┐  │
                     │  │  Nginx   │ │   WAF    │  │
                     │  │  (LB)    │ │          │  │
                     │  └────┬─────┘ └────┬─────┘  │
                     └───────┼────────────┼────────┘
                             │            │

══════════════════════════════════════════════════════════ Firewall │ │ ┌───────┴────────────┴────────┐ │ APPLICATION ZONE │ │ (172.28.2.0/24) │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ POS-API │ │ POS-API │ │ │ │ 1 │ │ 2 │ │ │ └────┬─────┘ └────┬─────┘ │ └───────┼────────────┼────────┘ │ │ ══════════════════════════════════════════════════════════ Firewall │ │ ┌───────┴────────────┴────────┐ │ DATA ZONE │ │ (172.28.3.0/24) │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Postgres │ │ Redis │ │ │ │ │ │ │ │ │ └──────────┘ └──────────┘ │ │ │ │ ┌──────────┐ │ │ │ RabbitMQ │ │ │ │ │ │ │ └──────────┘ │ └─────────────────────────────┘ │ ══════════════════════════════════════════════════════════ Firewall │ ┌──────────────┴──────────────┐ │ MANAGEMENT ZONE │ │ (172.28.4.0/24) │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Grafana │ │Prometheus│ │ │ │ │ │ │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────┘

FIREWALL RULES:

DMZ → Application: ALLOW: TCP 8080 (API) from Nginx only DENY: All other traffic

Application → Data: ALLOW: TCP 5432 (Postgres) from API containers ALLOW: TCP 6379 (Redis) from API containers ALLOW: TCP 5672 (RabbitMQ) from API containers DENY: All other traffic

Data → External: DENY: All outbound traffic

Management → All: ALLOW: TCP 9090 (metrics scrape) ALLOW: SSH from jump host only

---

## 26.18 Breach Response Procedures

### Incident Response Plan

```markdown
# Security Incident Response Plan

## 26.19 Phase 1: Detection & Identification (0-15 minutes)

### Indicators of Compromise
- Unusual database queries
- Spike in failed authentication
- Unexpected outbound traffic
- Data exfiltration alerts
- Customer reports of fraud

### Initial Assessment
1. Confirm incident is real (not false positive)
2. Classify severity:
   - P1: Active breach, data exfiltration
   - P2: Attempted breach, no data loss
   - P3: Vulnerability discovered, no exploitation

### Notification Matrix

| Severity | Notify Immediately |
|----------|-------------------|
| P1 | CISO, CTO, Legal, CEO, Payment Processor |
| P2 | CISO, Security Team Lead, Engineering Lead |
| P3 | Security Team Lead |

---

## 26.20 Phase 2: Containment (15-60 minutes)

### Immediate Actions (P1)
1. **Isolate affected systems**
   ```bash
   # Block external traffic
   iptables -I INPUT -j DROP

   # Preserve evidence
   docker pause <container>

2. Revoke compromised credentials

   -- Revoke all API keys
   UPDATE api_keys SET revoked = true WHERE tenant_id = <affected>;
   
   -- Force password reset
   UPDATE users SET must_reset_password = true WHERE tenant_id = <affected>;
   

3. Notify payment processor

   • Call Stripe incident hotline
   • Provide transaction date range
   • Request card replacement if needed

26.21 Phase 3: Eradication (1-24 hours)

Evidence Collection

1. Capture memory dump
2. Export all logs (past 90 days)
3. Capture network traffic
4. Preserve container images

Root Cause Analysis

1. How did attacker gain access?
2. What systems were accessed?
3. What data was accessed/exfiltrated?
4. How long was attacker present?

Remediation

1. Patch vulnerability
2. Remove backdoors
3. Reset all credentials
4. Update security controls

26.22 Phase 4: Recovery (24-72 hours)

System Restoration

1. Deploy from known-good images
2. Restore data from clean backup
3. Implement additional monitoring
4. Gradual traffic restoration

Verification

1. Security scan of restored systems
2. Penetration test of fixed vulnerability
3. Log analysis for lingering threats

26.23 Phase 5: Lessons Learned (1-2 weeks)

Post-Incident Review

• Timeline of events
• What worked well
• What needs improvement
• Action items with owners

Regulatory Notifications

Communication Templates

Customer Notification (Email)

Subject: Important Security Notice

Dear [Customer Name],

We are writing to inform you of a security incident that may have
affected your information...

[Describe incident without technical details]

What We Are Doing:
- [Actions taken]

What You Should Do:
- Monitor your accounts
- Report suspicious activity

[Contact information]
[Credit monitoring offer if applicable]

---

## 26.24 Security Audit Checklist

```markdown
# Quarterly Security Audit Checklist

## 26.25 Access Control Review

### User Accounts
- [ ] Review all user accounts for necessity
- [ ] Verify MFA enabled for all admin accounts
- [ ] Check for dormant accounts (no login > 90 days)
- [ ] Verify terminated employee access removed
- [ ] Review service account permissions

### API Keys & Tokens
- [ ] Rotate API keys > 90 days old
- [ ] Review API key permissions
- [ ] Check for exposed keys in code/logs
- [ ] Verify webhook secrets rotated

## 26.26 System Configuration

### Containers
- [ ] Scan all images for vulnerabilities
- [ ] Verify base images up to date
- [ ] Check for containers running as root
- [ ] Review exposed ports

### Database
- [ ] Verify encryption at rest enabled
- [ ] Check backup encryption
- [ ] Review database user permissions
- [ ] Test backup restoration

### Network
- [ ] Review firewall rules
- [ ] Check for unnecessary open ports
- [ ] Verify TLS configuration (SSL Labs A+)
- [ ] Test network segmentation

## 26.27 Logging & Monitoring

### Audit Logs
- [ ] Verify all security events logged
- [ ] Check log integrity (no gaps)
- [ ] Test log alerting
- [ ] Verify log retention (1 year)

### Monitoring
- [ ] Review alert thresholds
- [ ] Test incident response workflow
- [ ] Verify on-call rotation
- [ ] Check monitoring coverage

## 26.28 Vulnerability Management

### Scanning
- [ ] Review latest vulnerability scan results
- [ ] Verify critical findings remediated
- [ ] Check dependency vulnerabilities
- [ ] Review code analysis findings

### Patching
- [ ] Verify OS patches current
- [ ] Check application dependencies
- [ ] Review security advisories
- [ ] Test patch deployment process

## 26.29 Compliance

### PCI-DSS
- [ ] Review SAQ completion
- [ ] Verify ASV scan passing
- [ ] Check penetration test findings
- [ ] Update network diagram

### Data Protection
- [ ] Review data retention
- [ ] Verify data classification
- [ ] Check encryption standards
- [ ] Test data deletion process

## 26.30 Sign-off

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Security Lead | | | |
| CTO | | | |
| Compliance Officer | | | |

26.31 Supply Chain Security (SCA)

Overview

Modern software relies heavily on third-party dependencies. Supply Chain Security (SCA) protects against malicious packages, vulnerable dependencies, and license compliance issues.

Threat Landscape

+------------------------------------------------------------------+
|                   SUPPLY CHAIN ATTACK VECTORS                      |
+------------------------------------------------------------------+
|                                                                   |
|  1. Typosquatting       lodash vs lodas (malicious)              |
|  2. Dependency Confusion  Private package name collision         |
|  3. Compromised Packages  Event-stream attack (2018)             |
|  4. Abandoned Packages    No security updates                    |
|  5. License Violations    GPL in commercial products             |
|                                                                   |
+------------------------------------------------------------------+

Snyk Configuration

# .snyk policy file
version: v1.25.0

# Ignore specific vulnerabilities (with justification)
ignore:
  SNYK-DOTNET-SYSTEMTEXTJSON-5951292:
    - '*':
        reason: 'Risk accepted - not reachable in our code paths'
        expires: 2026-03-01

# Package policies
policies:
  - package-policy:
      licenses:
        - severity: high
          license: GPL-3.0
        - severity: medium
          license: LGPL-3.0

# Block packages with critical vulnerabilities
fail-on:
  - severity: critical
  - severities: [critical, high]
    type: license

# Run Snyk scan in CI
snyk test --severity-threshold=high --fail-on=all

# Monitor for new vulnerabilities
snyk monitor

# Generate SBOM
snyk sbom --format=cyclonedx+json > sbom.json

OWASP Dependency-Check (Alternative)

<!-- pom.xml or as CLI tool -->
<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>8.4.0</version>
    <configuration>
        <failBuildOnCVSS>7</failBuildOnCVSS>
        <format>ALL</format>
    </configuration>
</plugin>

# .NET projects
dotnet tool install --global dotnet-dependency-check
dependency-check --project "POS Platform" --scan ./src --format HTML

Package Firewall (Proxy)

# Artifactory or Nexus configuration
remote-repositories:
  nuget-proxy:
    url: https://api.nuget.org/v3/index.json
    blocked-packages:
      - name: "malicious-package"
        reason: "Known malware"
    vulnerability-policy:
      max-severity: HIGH
      fail-build: true

SBOM (Software Bill of Materials)

// Example SBOM output (CycloneDX format)
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
    "component": {
      "name": "pos-platform",
      "version": "1.2.3",
      "type": "application"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "Newtonsoft.Json",
      "version": "13.0.3",
      "purl": "pkg:nuget/Newtonsoft.Json@13.0.3",
      "licenses": [{"license": {"id": "MIT"}}],
      "hashes": [{"alg": "SHA-256", "content": "abc123..."}]
    }
  ]
}

VEX (Vulnerability Exploitability eXchange)

VEX is the companion document to SBOM that communicates whether a vulnerability actually affects your product. While SBOM lists components, VEX explains exploitability status.

Why VEX Matters

+------------------------------------------------------------------+
|                    SBOM vs VEX RELATIONSHIP                        |
+------------------------------------------------------------------+
|                                                                   |
|  SBOM says: "We use library X version 2.1.0"                      |
|                                                                   |
|  CVE Database says: "Library X has CVE-2025-12345 (CRITICAL)"     |
|                                                                   |
|  VEX says: "CVE-2025-12345 is NOT AFFECTED because we don't       |
|            use the vulnerable deserialization function"           |
|                                                                   |
|  Result: Security team focuses on REAL threats, not false alarms  |
|                                                                   |
+------------------------------------------------------------------+

VEX Status Values

OpenVEX Document Example

// vex/pos-platform-vex.json
{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://posplatform.io/vex/2026-01-24",
  "author": "POS Platform Security Team",
  "timestamp": "2026-01-24T10:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": {
        "@id": "https://nvd.nist.gov/vuln/detail/CVE-2025-29384",
        "name": "CVE-2025-29384",
        "description": "Deserialization vulnerability in Newtonsoft.Json"
      },
      "products": [
        {
          "@id": "pkg:nuget/PosPlatform.Api@1.2.3",
          "identifiers": {
            "purl": "pkg:nuget/PosPlatform.Api@1.2.3"
          }
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "The vulnerable TypeNameHandling feature is explicitly disabled in our configuration. We use TypeNameHandling.None which prevents the deserialization attack vector."
    },
    {
      "vulnerability": {
        "@id": "https://nvd.nist.gov/vuln/detail/CVE-2025-31456",
        "name": "CVE-2025-31456"
      },
      "products": [
        {
          "@id": "pkg:nuget/PosPlatform.Api@1.2.3"
        }
      ],
      "status": "affected",
      "action_statement": "Upgrade to Npgsql 8.0.5 in next release",
      "action_statement_timestamp": "2026-02-01T00:00:00Z"
    }
  ]
}

VEX Generation Workflow

# .github/workflows/vex-generation.yml

name: Generate VEX

on:
  schedule:
    - cron: '0 6 * * 1'  # Weekly on Monday
  workflow_dispatch:

jobs:
  generate-vex:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        run: |
          dotnet tool install --global CycloneDX
          dotnet CycloneDX src/PosPlatform.Api/PosPlatform.Api.csproj -o sbom.json

      - name: Scan for vulnerabilities
        run: |
          snyk test --json > vulns.json

      - name: Generate VEX with analysis
        run: |
          # Use vexctl or custom script to generate VEX
          vexctl create --product pos-platform --version ${{ github.ref_name }} \
            --sbom sbom.json --vulns vulns.json --output vex.json

      - name: Upload VEX artifact
        uses: actions/upload-artifact@v4
        with:
          name: vex-document
          path: vex.json

      - name: Publish to VEX repository
        run: |
          # Store VEX documents for customer access
          aws s3 cp vex.json s3://security-docs/vex/pos-platform-${{ github.ref_name }}.json

Integration with Vulnerability Scanners

# Grype with VEX filtering
grype sbom:./sbom.json --vex ./vex.json

# Trivy with VEX
trivy sbom ./sbom.json --vex ./vex.json --ignore-unfixed

# Result: Only shows vulnerabilities NOT marked as "not_affected" in VEX

26.32 EU Cyber Resilience Act (CRA) Compliance

Overview

The EU Cyber Resilience Act (CRA) mandates cybersecurity requirements for products with digital elements sold in the EU market. For POS systems processing financial transactions, this is a mandatory compliance requirement.

Key Requirements

+------------------------------------------------------------------+
|                   EU CRA KEY OBLIGATIONS                           |
+------------------------------------------------------------------+
|                                                                   |
|  1. SECURE BY DESIGN                                              |
|     - Security from initial design phase                          |
|     - Threat modeling mandatory                                   |
|     - No known exploitable vulnerabilities at release             |
|                                                                   |
|  2. VULNERABILITY HANDLING                                        |
|     - Coordinated vulnerability disclosure process                |
|     - Security updates for 5+ years (or product lifetime)         |
|     - Notify ENISA within 24 hours of exploited vulnerabilities   |
|                                                                   |
|  3. TRANSPARENCY                                                  |
|     - SBOM required for all products                              |
|     - Clear security information to users                         |
|     - CE marking for compliant products                           |
|                                                                   |
|  4. DOCUMENTATION                                                 |
|     - Technical documentation                                     |
|     - Risk assessment                                             |
|     - Conformity assessment                                       |
|                                                                   |
+------------------------------------------------------------------+

Product Classification

POS Platform Classification: Class II (Important Product)

• Processes financial transactions
• Handles payment data
• Network-connected critical retail infrastructure

CRA Compliance Checklist

# EU Cyber Resilience Act Compliance Checklist

## 26.33 Design Phase Requirements
- [ ] Threat model documented for all components
- [ ] Security requirements in design specifications
- [ ] STRIDE analysis completed
- [ ] Attack surface documented

## 26.34 Development Requirements
- [ ] Secure coding guidelines followed
- [ ] SAST integrated in CI/CD pipeline
- [ ] Dependencies scanned (SCA)
- [ ] No known vulnerabilities at release

## 26.35 Vulnerability Management
- [ ] Coordinated disclosure policy published
- [ ] Security contact (security.txt) available
- [ ] Vulnerability tracking system in place
- [ ] Patch timeline: Critical (24h), High (7d), Medium (30d)

## 26.36 Documentation
- [ ] SBOM generated for each release
- [ ] VEX documents maintained
- [ ] Technical documentation complete
- [ ] User security instructions provided

## 26.37 Incident Response
- [ ] ENISA notification process defined
- [ ] 24-hour notification capability
- [ ] Incident classification criteria
- [ ] Communication templates ready

## 26.38 Conformity Assessment
- [ ] Third-party assessment scheduled
- [ ] CE marking documentation prepared
- [ ] EU Declaration of Conformity drafted

ENISA Notification Process

// Services/EnisaNotificationService.cs

public class EnisaNotificationService
{
    private readonly IHttpClientFactory _httpClientFactory;
    private readonly ILogger<EnisaNotificationService> _logger;
    private const string ENISA_ENDPOINT = "https://enisa.europa.eu/cra/notifications";

    public async Task NotifyExploitedVulnerabilityAsync(
        VulnerabilityNotification notification,
        CancellationToken ct = default)
    {
        // CRA requires notification within 24 hours of discovering
        // an actively exploited vulnerability

        var payload = new
        {
            manufacturerId = "POS-PLATFORM-EU-001",
            productIdentifier = notification.ProductId,
            vulnerabilityId = notification.CveId,
            discoveryTimestamp = notification.DiscoveredAt.ToString("O"),
            exploitationEvidence = notification.ExploitationDetails,
            affectedVersions = notification.AffectedVersions,
            mitigationStatus = notification.MitigationStatus,
            estimatedPatchDate = notification.EstimatedPatchDate?.ToString("O"),
            contactEmail = "security@posplatform.io"
        };

        var client = _httpClientFactory.CreateClient("ENISA");
        var response = await client.PostAsJsonAsync(ENISA_ENDPOINT, payload, ct);

        if (!response.IsSuccessStatusCode)
        {
            _logger.LogCritical(
                "ENISA notification failed for {CveId}. Status: {Status}. " +
                "MANUAL NOTIFICATION REQUIRED within 24 hours.",
                notification.CveId,
                response.StatusCode
            );

            // Trigger escalation to security team
            await TriggerEscalationAsync(notification);
        }

        _logger.LogInformation(
            "ENISA notified of {CveId}. Reference: {Reference}",
            notification.CveId,
            await response.Content.ReadAsStringAsync(ct)
        );
    }
}

public record VulnerabilityNotification(
    string ProductId,
    string CveId,
    DateTime DiscoveredAt,
    string ExploitationDetails,
    string[] AffectedVersions,
    string MitigationStatus,
    DateTime? EstimatedPatchDate
);

Security Support Period

Under CRA, manufacturers must provide security updates for:

• Minimum 5 years from product release, OR
• Expected product lifetime (whichever is longer)

# Product Lifecycle Policy (CRA Compliant)

products:
  pos-platform:
    current_version: "1.2.3"
    release_date: "2026-03-01"
    security_support_until: "2031-03-01"  # 5 years minimum

    support_tiers:
      - tier: "active"
        description: "Feature updates + security patches"
        duration: "3 years"

      - tier: "security"
        description: "Security patches only"
        duration: "2 years"

      - tier: "extended"
        description: "Critical security only (paid)"
        duration: "negotiable"

    patch_slas:
      critical: "24 hours"
      high: "7 days"
      medium: "30 days"
      low: "90 days"

CE Marking & Declaration

# EU Declaration of Conformity

**Manufacturer**: POS Platform Inc.
**Address**: [Company Address]
**Product**: POS Platform - Multi-tenant Retail Point of Sale System
**Model**: POS-2026-PRO
**Version**: 1.2.3

This declaration of conformity is issued under the sole responsibility
of the manufacturer.

**Object of Declaration**:
The product described above is in conformity with the essential
requirements of the EU Cyber Resilience Act (Regulation 2024/XXX).

**Harmonized Standards Applied**:
- EN ISO/IEC 27001:2022 - Information Security Management
- EN ISO/IEC 62443-4-1:2018 - Secure Product Development Lifecycle
- CycloneDX 1.5 - SBOM Standard

**Conformity Assessment**:
Third-party conformity assessment performed by [Notified Body Name]
Certificate Number: [Certificate ID]

**Signed**:
[Name, Title]
[Date]
[Place]

26.39 GenAI Governance

Overview

With AI-assisted code generation (GitHub Copilot, Claude Code), additional security controls are required to prevent AI-generated vulnerabilities from reaching production.

“Vibe Coding” Risks

+------------------------------------------------------------------+
|                   AI CODE GENERATION RISKS                         |
+------------------------------------------------------------------+
|                                                                   |
|  1. Hallucinated APIs     - Non-existent functions                |
|  2. Insecure Patterns     - SQL injection, hardcoded secrets      |
|  3. Outdated Libraries    - Training data from 2022               |
|  4. License Contamination - Copyleft code in proprietary         |
|  5. Logic Errors          - Subtle bugs that compile fine         |
|                                                                   |
+------------------------------------------------------------------+

Deep SAST Configuration (SonarQube)

# sonar-project.properties
sonar.projectKey=pos-platform
sonar.projectName=POS Platform
sonar.sources=src
sonar.tests=tests

# Quality Gates
sonar.qualitygate.wait=true

# Rules for AI-generated code
sonar.issue.ignore.multicriteria=e1
sonar.issue.ignore.multicriteria.e1.ruleKey=csharpsquid:S1135
sonar.issue.ignore.multicriteria.e1.resourceKey=**/*Generated*.cs

SonarQube Quality Gate Rules

CI Pipeline Integration

# .github/workflows/security.yml

name: Security Scan

on: [push, pull_request]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Full history for better analysis

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

      - name: Quality Gate Check
        uses: SonarSource/sonarqube-quality-gate-action@master
        timeout-minutes: 5
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

  codeql:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v2
        with:
          languages: csharp

      - name: Build
        run: dotnet build

      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v2

Claude Code CLI Integration

# Pre-commit hook for AI-generated code
#!/bin/bash
# .git/hooks/pre-commit

# Check if files were modified by Claude Code
if git diff --cached --name-only | grep -q "Generated by Claude"; then
    echo "AI-generated code detected. Running deep SAST..."

    # Run SonarScanner
    sonar-scanner -Dsonar.qualitygate.wait=true

    if [ $? -ne 0 ]; then
        echo "ERROR: AI-generated code failed security scan"
        exit 1
    fi
fi

AI Code Review Checklist

# AI-Generated Code Review Checklist

Before approving AI-generated code:

## 26.40 Security
- [ ] No hardcoded secrets or API keys
- [ ] No SQL injection vulnerabilities
- [ ] Input validation on all user inputs
- [ ] Output encoding for XSS prevention
- [ ] No insecure deserialization

## 26.41 Quality
- [ ] Logic matches intended behavior
- [ ] Edge cases handled
- [ ] Error handling is appropriate
- [ ] No deprecated APIs used

## 26.42 Compliance
- [ ] No copyleft licensed code copied
- [ ] SAST scan passed
- [ ] Unit tests included

26.43 File Integrity Monitoring (FIM)

Overview

File Integrity Monitoring is a PCI-DSS requirement (11.5) that detects unauthorized changes to critical system files, essential for detecting tampering and skimmer attacks on POS terminals.

Wazuh Architecture

+------------------------------------------------------------------+
|                       FIM ARCHITECTURE                             |
+------------------------------------------------------------------+
|                                                                   |
|  ┌─────────────────┐    ┌─────────────────┐    ┌───────────────┐ |
|  │  POS Terminal   │    │  API Server     │    │  DB Server    │ |
|  │  (Wazuh Agent)  │    │  (Wazuh Agent)  │    │ (Wazuh Agent) │ |
|  └────────┬────────┘    └────────┬────────┘    └───────┬───────┘ |
|           │                      │                      │         |
|           └──────────────────────┼──────────────────────┘         |
|                                  │                                 |
|                                  ▼                                 |
|                    ┌─────────────────────────┐                    |
|                    │     Wazuh Manager       │                    |
|                    │   (Central Analysis)    │                    |
|                    └────────────┬────────────┘                    |
|                                 │                                  |
|                    ┌────────────┴────────────┐                    |
|                    │                         │                    |
|                    ▼                         ▼                    |
|           ┌───────────────┐        ┌────────────────┐            |
|           │  Wazuh UI     │        │  Alerting      │            |
|           │  Dashboard    │        │  (Slack/Email) │            |
|           └───────────────┘        └────────────────┘            |
|                                                                   |
+------------------------------------------------------------------+

Wazuh Agent Configuration

<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <syscheck>
    <!-- Check every 12 hours -->
    <frequency>43200</frequency>

    <!-- Real-time monitoring for critical directories -->
    <directories realtime="yes" check_all="yes">/opt/pos/bin</directories>
    <directories realtime="yes" check_all="yes">/opt/pos/config</directories>
    <directories realtime="yes" check_all="yes">/etc/pos</directories>

    <!-- Payment module - highest priority -->
    <directories realtime="yes" check_all="yes" report_changes="yes">
      /opt/pos/payment
    </directories>

    <!-- Critical system files -->
    <directories check_all="yes">/etc/passwd</directories>
    <directories check_all="yes">/etc/shadow</directories>
    <directories check_all="yes">/etc/sudoers</directories>

    <!-- Ignore log files and temp -->
    <ignore>/var/log</ignore>
    <ignore>/tmp</ignore>
    <ignore type="sregex">.log$</ignore>
  </syscheck>
</ossec_config>

Docker Container Monitoring

# docker-compose.wazuh.yml
services:
  wazuh-manager:
    image: wazuh/wazuh-manager:4.7.0
    container_name: wazuh-manager
    ports:
      - "1514:1514"    # Agent registration
      - "1515:1515"    # Agent communication
      - "55000:55000"  # API
    volumes:
      - wazuh_data:/var/ossec/data
      - wazuh_etc:/var/ossec/etc
    environment:
      - INDEXER_URL=https://wazuh-indexer:9200

  wazuh-agent:
    image: wazuh/wazuh-agent:4.7.0
    container_name: wazuh-agent
    environment:
      - WAZUH_MANAGER=wazuh-manager
      - WAZUH_AGENT_NAME=pos-api-1
    volumes:
      # Mount host paths to monitor
      - /opt/pos:/opt/pos:ro
      - /etc:/host_etc:ro
    depends_on:
      - wazuh-manager

Custom FIM Rules for POS

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="pos_fim,">

  <!-- Payment module changes - CRITICAL -->
  <rule id="100001" level="15">
    <if_sid>550</if_sid>
    <match>/opt/pos/payment</match>
    <description>CRITICAL: Payment module file modified</description>
    <group>pci_dss_11.5,</group>
  </rule>

  <!-- Configuration changes - HIGH -->
  <rule id="100002" level="12">
    <if_sid>550</if_sid>
    <match>/opt/pos/config</match>
    <description>HIGH: POS configuration file modified</description>
    <group>pci_dss_11.5,</group>
  </rule>

  <!-- Executable changes - HIGH -->
  <rule id="100003" level="12">
    <if_sid>550</if_sid>
    <match>/opt/pos/bin</match>
    <description>HIGH: POS executable modified</description>
    <group>pci_dss_11.5,</group>
  </rule>

  <!-- Skimmer detection - patterns -->
  <rule id="100010" level="15">
    <if_sid>550</if_sid>
    <regex>\.dll$|\.so$|\.exe$</regex>
    <match>/opt/pos/payment</match>
    <description>ALERT: Possible skimmer injection detected</description>
    <group>pci_dss_11.5,attack,</group>
  </rule>

</group>

Alert Configuration

# Wazuh alert integration
integrations:
  - name: slack
    hook_url: https://hooks.slack.com/services/xxx/yyy/zzz
    level: 12  # High and Critical only
    alert_format: json
    rule_id:
      - 100001
      - 100010

  - name: pagerduty
    api_key: your-pagerduty-key
    level: 15  # Critical only

FIM Compliance Report

# Generate FIM compliance report for PCI audit
wazuh-reporting fim-report \
  --start "2026-01-01" \
  --end "2026-01-31" \
  --format pdf \
  --output /reports/fim-jan-2026.pdf

# Check current baseline
/var/ossec/bin/syscheck_control -l

# Force immediate scan
/var/ossec/bin/syscheck_control -u

26.44 PCI DSS v4.0.1 Container-Specific FIM

Overview

PCI DSS v4.0.1 introduces explicit requirements for containerized environments. Container FIM must monitor not just running containers but also:

• Container images
• Orchestrator configurations (Kubernetes)
• Container runtime configurations

Container FIM Architecture

+------------------------------------------------------------------+
|                CONTAINER FIM ARCHITECTURE                          |
+------------------------------------------------------------------+
|                                                                   |
|  ┌─────────────────┐    ┌─────────────────┐    ┌───────────────┐  |
|  │  Image Registry │    │   Kubernetes    │    │  Container    │  |
|  │  (Harbor/ACR)   │    │   API Server    │    │   Runtime     │  |
|  └────────┬────────┘    └────────┬────────┘    └───────┬───────┘  |
|           │                      │                      │          |
|           ▼                      ▼                      ▼          |
|  ┌─────────────────┐    ┌─────────────────┐    ┌───────────────┐  |
|  │  Trivy Scanner  │    │  Wazuh K8s      │    │    Falco      │  |
|  │  (Image FIM)    │    │  Agent          │    │  (Runtime)    │  |
|  │                 │    │                 │    │               │  |
|  │ - Layer changes │    │ - ConfigMap     │    │ - File access │  |
|  │ - Vuln scanning │    │ - Secrets       │    │ - Syscalls    │  |
|  │ - SBOM drift    │    │ - RBAC changes  │    │ - Network     │  |
|  └────────┬────────┘    └────────┬────────┘    └───────┬───────┘  |
|           │                      │                      │          |
|           └──────────────────────┼──────────────────────┘          |
|                                  ▼                                 |
|                    ┌─────────────────────────┐                     |
|                    │     Wazuh Manager       │                     |
|                    │   (Central Analysis)    │                     |
|                    └────────────┬────────────┘                     |
|                                 │                                  |
|                    ┌────────────┴────────────┐                     |
|                    │                         │                     |
|                    ▼                         ▼                     |
|           ┌───────────────┐        ┌────────────────┐              |
|           │  SIEM / Wazuh │        │    PCI DSS     │              |
|           │   Dashboard   │        │    Reports     │              |
|           └───────────────┘        └────────────────┘              |
|                                                                   |
+------------------------------------------------------------------+

Image FIM with Trivy

# .github/workflows/image-fim.yml

name: Container Image FIM

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 0 * * *'  # Daily baseline check

jobs:
  image-fim:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t pos-api:${{ github.sha }} .

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: pos-api:${{ github.sha }}
          output-file: sbom-${{ github.sha }}.json

      - name: Compare with baseline SBOM
        run: |
          # Download baseline SBOM
          aws s3 cp s3://security-baselines/pos-api/sbom-baseline.json baseline.json

          # Compare SBOMs for drift
          diff_result=$(diff <(jq -S . baseline.json) <(jq -S . sbom-${{ github.sha }}.json) || true)

          if [ -n "$diff_result" ]; then
            echo "SBOM DRIFT DETECTED"
            echo "$diff_result"

            # Log to Wazuh
            curl -X POST https://wazuh-manager:55000/events \
              -H "Authorization: Bearer $WAZUH_TOKEN" \
              -d '{
                "event": "container_image_drift",
                "image": "pos-api",
                "sha": "${{ github.sha }}",
                "changes": "'"$(echo $diff_result | jq -Rs .)"'"
              }'
          fi

      - name: Trivy vulnerability scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: pos-api:${{ github.sha }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'

      - name: Compare with baseline vulnerabilities
        run: |
          # Get current vulns
          trivy image --format json pos-api:${{ github.sha }} > current-vulns.json

          # Compare with baseline
          NEW_VULNS=$(jq -r '.Results[].Vulnerabilities[]?.VulnerabilityID' current-vulns.json | \
                      grep -v -f baseline-vulns.txt | wc -l)

          if [ "$NEW_VULNS" -gt 0 ]; then
            echo "NEW VULNERABILITIES DETECTED: $NEW_VULNS"
            # Alert through Wazuh
          fi

Kubernetes Configuration FIM

# k8s/wazuh-k8s-agent.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: wazuh-agent
  namespace: security
spec:
  selector:
    matchLabels:
      app: wazuh-agent
  template:
    metadata:
      labels:
        app: wazuh-agent
    spec:
      serviceAccountName: wazuh-agent
      containers:
        - name: wazuh-agent
          image: wazuh/wazuh-agent:4.7.0
          env:
            - name: WAZUH_MANAGER
              value: "wazuh-manager.security.svc"
          volumeMounts:
            # Monitor Kubernetes configs
            - name: k8s-manifests
              mountPath: /host/etc/kubernetes
              readOnly: true
            # Monitor container runtime
            - name: containerd
              mountPath: /host/run/containerd
              readOnly: true
            # Monitor host filesystem
            - name: host-root
              mountPath: /host
              readOnly: true
          securityContext:
            privileged: true  # Required for FIM
      volumes:
        - name: k8s-manifests
          hostPath:
            path: /etc/kubernetes
        - name: containerd
          hostPath:
            path: /run/containerd
        - name: host-root
          hostPath:
            path: /

<!-- Wazuh agent config for Kubernetes FIM -->
<ossec_config>
  <syscheck>
    <!-- Kubernetes manifests -->
    <directories realtime="yes" check_all="yes" report_changes="yes">
      /host/etc/kubernetes/manifests
    </directories>

    <!-- Kubernetes PKI -->
    <directories realtime="yes" check_all="yes">
      /host/etc/kubernetes/pki
    </directories>

    <!-- Container runtime config -->
    <directories realtime="yes" check_all="yes">
      /host/etc/containerd
    </directories>

    <!-- Kubelet config -->
    <directories check_all="yes">
      /host/var/lib/kubelet
    </directories>
  </syscheck>
</ossec_config>

Runtime FIM with Falco

# k8s/falco-daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: falco
  namespace: security
spec:
  selector:
    matchLabels:
      app: falco
  template:
    spec:
      containers:
        - name: falco
          image: falcosecurity/falco:0.37.0
          securityContext:
            privileged: true
          volumeMounts:
            - name: falco-rules
              mountPath: /etc/falco/rules.d
            - name: dev
              mountPath: /host/dev
            - name: proc
              mountPath: /host/proc
              readOnly: true
      volumes:
        - name: falco-rules
          configMap:
            name: falco-pos-rules
        - name: dev
          hostPath:
            path: /dev
        - name: proc
          hostPath:
            path: /proc
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: falco-pos-rules
  namespace: security
data:
  pos-rules.yaml: |
    # POS-specific Falco rules for container FIM

    - rule: POS Container File Modified
      desc: Detect file modifications in POS containers
      condition: >
        container.name startswith "pos-" and
        (evt.type = open or evt.type = openat) and
        evt.is_open_write = true and
        fd.name startswith "/app/"
      output: >
        File modified in POS container
        (user=%user.name container=%container.name file=%fd.name
         command=%proc.cmdline)
      priority: CRITICAL
      tags: [pci_dss, fim, container]

    - rule: POS Payment Module Access
      desc: Detect any access to payment processing code
      condition: >
        container.name startswith "pos-" and
        fd.name contains "payment" and
        (evt.type = open or evt.type = openat)
      output: >
        Payment module accessed
        (user=%user.name container=%container.name file=%fd.name
         command=%proc.cmdline)
      priority: WARNING
      tags: [pci_dss, payment, fim]

    - rule: Unexpected Process in POS Container
      desc: Detect unexpected processes in POS containers
      condition: >
        container.name startswith "pos-" and
        spawned_process and
        not proc.name in (dotnet, pos-api, bash, sh)
      output: >
        Unexpected process in POS container
        (user=%user.name container=%container.name proc=%proc.name
         parent=%proc.pname cmdline=%proc.cmdline)
      priority: CRITICAL
      tags: [pci_dss, runtime, malware]

    - rule: Container Configuration Modified
      desc: Detect changes to container configs
      condition: >
        (evt.type = open or evt.type = openat) and
        evt.is_open_write = true and
        (fd.name contains "/etc/kubernetes" or
         fd.name contains "/etc/containerd" or
         fd.name contains "/var/lib/kubelet")
      output: >
        Container infrastructure config modified
        (user=%user.name file=%fd.name command=%proc.cmdline)
      priority: CRITICAL
      tags: [pci_dss, k8s, fim]

Container FIM Alert Rules

<!-- /var/ossec/etc/rules/container_fim_rules.xml -->

<group name="container_fim,pci_dss_11.5,">

  <!-- Container image drift detected -->
  <rule id="100100" level="12">
    <decoded_as>json</decoded_as>
    <field name="event">container_image_drift</field>
    <description>CONTAINER FIM: Image SBOM drift detected for $(image)</description>
    <group>pci_dss_11.5.1.1,container_security,</group>
  </rule>

  <!-- New vulnerability in container image -->
  <rule id="100101" level="14">
    <decoded_as>json</decoded_as>
    <field name="event">new_vulnerability</field>
    <field name="severity">CRITICAL|HIGH</field>
    <description>CONTAINER FIM: New $(severity) vulnerability in $(image)</description>
    <group>pci_dss_11.5.1.1,vulnerability,</group>
  </rule>

  <!-- Kubernetes manifest changed -->
  <rule id="100102" level="13">
    <if_sid>550</if_sid>
    <match>/etc/kubernetes/manifests</match>
    <description>CONTAINER FIM: Kubernetes manifest modified</description>
    <group>pci_dss_11.5.1.1,k8s_config,</group>
  </rule>

  <!-- Container runtime config changed -->
  <rule id="100103" level="12">
    <if_sid>550</if_sid>
    <match>/etc/containerd</match>
    <description>CONTAINER FIM: Container runtime config modified</description>
    <group>pci_dss_11.5.1.1,runtime_config,</group>
  </rule>

  <!-- Falco: POS container file modified -->
  <rule id="100110" level="15">
    <decoded_as>json</decoded_as>
    <field name="rule">POS Container File Modified</field>
    <description>RUNTIME FIM: File modified in POS container - $(output)</description>
    <group>pci_dss_11.5.1.1,runtime_fim,critical,</group>
  </rule>

  <!-- Falco: Unexpected process in container -->
  <rule id="100111" level="15">
    <decoded_as>json</decoded_as>
    <field name="rule">Unexpected Process in POS Container</field>
    <description>RUNTIME FIM: Unexpected process detected - $(output)</description>
    <group>pci_dss_11.5.1.1,malware_detection,critical,</group>
  </rule>

</group>

PCI DSS v4.0.1 Container FIM Compliance Mapping

Reference

For complete security strategy and risk mitigations, see:

• Appendix K: Architecture Characteristics - Security characteristic justification
• Appendix L: Architecture Styles Analysis - DevSecOps pipeline details

26.45 Summary

This chapter provides comprehensive security coverage:

1. Security Architecture: Defense-in-depth layers
2. PCI-DSS Compliance: Complete 12-requirement checklist
3. Tokenization: Payment data flow and storage policies
4. Network Segmentation: Zone-based security architecture
5. Breach Response: Step-by-step incident procedures
6. Audit Checklist: Quarterly security review process
7. Supply Chain Security (NEW): SCA with Snyk, SBOM generation
8. GenAI Governance (NEW): Deep SAST gates for AI-generated code
9. File Integrity Monitoring (NEW): Wazuh FIM for PCI 11.5 compliance

Next Chapter: Chapter 27: Disaster Recovery

“Security is not a product, but a process.”

Document Information

This chapter is part of the POS Blueprint Book. All content is self-contained.