Chapter 31: Security and Compliance
Overview
This chapter covers security architecture, PCI-DSS compliance requirements, data protection strategies, and security audit procedures for the POS Platform.
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 │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
PCI-DSS Compliance Checklist
Complete 12 Requirements
# PCI-DSS v4.0 Compliance Checklist for POS Platform
## 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
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
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
| Data Type | Stored? | Method | Location |
|---|---|---|---|
| Full PAN | NO | Tokenized | Stripe |
| Last 4 digits | YES | Masked | Local DB |
| CVV/CVC | NO | Never captured | N/A |
| Expiry Date | YES | Encrypted | Local DB |
| Cardholder Name | YES | Encrypted | Local DB |
| Track Data | NO | Never captured | N/A |
| PIN | NO | Never captured | N/A |
| Payment Token | YES | As-is | Local DB |
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;
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'
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
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
| Role | Transactions | Inventory | Reports | Users | Settings |
|---|---|---|---|---|---|
| Cashier | Create | View | None | None | None |
| Supervisor | All | All | Store | None | Store |
| Store Manager | All | All | Store | Store | Store |
| Regional Manager | View | View | Region | View | View |
| Admin | All | All | All | All | All |
| System | API Only | API Only | None | None | None |
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;
});
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
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
}
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
| Scan Type | Frequency | Tool | Remediation SLA |
|---|---|---|---|
| Container scan | Every build | Trivy | Block if Critical |
| Dependency scan | Daily | Dependabot | 7 days |
| SAST | Every PR | SonarQube | Block if High |
| DAST | Weekly | OWASP ZAP | 14 days |
| External ASV | Quarterly | Qualys | 30 days |
| Internal Network | Quarterly | Nessus | 30 days |
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
---
## 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) │ └─────────────────────────────────────────────────────┘
---
## 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
---
## Breach Response Procedures
### Incident Response Plan
```markdown
# Security Incident Response Plan
## 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 |
---
## 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>
-
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>; -
Notify payment processor
- Call Stripe incident hotline
- Provide transaction date range
- Request card replacement if needed
Phase 3: Eradication (1-24 hours)
Evidence Collection
- Capture memory dump
- Export all logs (past 90 days)
- Capture network traffic
- Preserve container images
Root Cause Analysis
- How did attacker gain access?
- What systems were accessed?
- What data was accessed/exfiltrated?
- How long was attacker present?
Remediation
- Patch vulnerability
- Remove backdoors
- Reset all credentials
- Update security controls
Phase 4: Recovery (24-72 hours)
System Restoration
- Deploy from known-good images
- Restore data from clean backup
- Implement additional monitoring
- Gradual traffic restoration
Verification
- Security scan of restored systems
- Penetration test of fixed vulnerability
- Log analysis for lingering threats
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
| Regulation | Notification Period | Authority |
|---|---|---|
| PCI-DSS | Immediately | Payment brands, acquiring bank |
| GDPR | 72 hours | Supervisory authority |
| State Laws | Varies (30-90 days) | State AG, affected individuals |
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]
---
## Security Audit Checklist
```markdown
# Quarterly Security Audit Checklist
## 1. 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
## 2. 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
## 3. 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
## 4. 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
## 5. 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
## Sign-off
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Security Lead | | | |
| CTO | | | |
| Compliance Officer | | | |
Summary
This chapter provides comprehensive security coverage:
- Security Architecture: Defense-in-depth layers
- PCI-DSS Compliance: Complete 12-requirement checklist
- Tokenization: Payment data flow and storage policies
- Network Segmentation: Zone-based security architecture
- Breach Response: Step-by-step incident procedures
- Audit Checklist: Quarterly security review process
Next Chapter: Chapter 32: Disaster Recovery
“Security is not a product, but a process.”