From faos-ciso
<!-- AUTO-GENERATED by export-plugins.py — DO NOT EDIT -->
npx claudepluginhub frank-luongt/faos-skills-marketplace --plugin faos-cisoThis skill uses the workspace's default tool permissions.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
The Payment Card Industry Data Security Standard (PCI-DSS) version 4.0 is a set of security requirements designed to protect cardholder data and sensitive authentication data wherever it is processed, stored, or transmitted. Released in March 2022 by the PCI Security Standards Council (PCI SSC), v4.0 replaces v3.2.1 with a transition deadline of March 31, 2025 for mandatory adoption.
PCI-DSS v4.0 introduces significant changes:
The standard applies to all entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), and to entities that can affect the security of the cardholder data environment (CDE).
Identify all system components, people, and processes that are in scope:
Choose the appropriate Self-Assessment Questionnaire based on your processing method:
| SAQ Type | Description | Applicability |
|---|---|---|
| SAQ A | Card-not-present, fully outsourced | E-commerce with redirect (Stripe Checkout, PayPal) |
| SAQ A-EP | E-commerce with partial outsourcing | Website controls payment page elements |
| SAQ B | Imprint machines or standalone terminals | No electronic CHD storage |
| SAQ B-IP | Standalone PTS terminals with IP connection | PIN entry devices, no CHD storage |
| SAQ C | Payment application systems | Internet-connected payment applications |
| SAQ C-VT | Virtual terminal, manual entry | Web-based virtual terminal, one transaction at a time |
| SAQ D | All others | Merchants/service providers not qualifying for other SAQs |
| SAQ P2PE | Hardware P2PE terminal | Validated P2PE solution, no electronic CHD storage |
For each of the 12 PCI-DSS requirements, map your existing controls and identify gaps. Use either the Defined Approach (prescriptive controls) or Customized Approach (objective-based).
Deploy technical and operational controls to meet each requirement:
Execute the assessment process:
Requirement 1: Install and Maintain Network Security Controls
Requirement 2: Apply Secure Configurations to All System Components
Requirement 3: Protect Stored Account Data
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission
Requirement 5: Protect All Systems and Networks from Malicious Software
Requirement 6: Develop and Maintain Secure Systems and Software
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Requirement 8: Identify Users and Authenticate Access to System Components
Requirement 9: Restrict Physical Access to Cardholder Data
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Requirement 11: Test Security of Systems and Networks Regularly
Requirement 12: Support Information Security with Organizational Policies and Programs
| Area | v3.2.1 | v4.0 |
|---|---|---|
| Approach | Defined Approach only | Defined Approach + Customized Approach |
| MFA scope | Remote access only | All access into the CDE |
| Password length | 7 characters minimum | 12 characters minimum |
| Disk encryption | Acceptable for PAN | No longer sole mechanism |
| Log review | Daily manual review | Automated mechanisms required |
| Risk analysis | Limited use | Targeted risk analysis for flexible frequencies |
| WAF | Required for web apps | WAF or automated vulnerability solution |
| Phishing | Not explicitly addressed | Anti-phishing mechanisms required |
| Service accounts | Limited coverage | Full inventory and management required |
cde_segmentation:
description: "Network segmentation controls isolating the CDE"
last_validated: "2026-02-15"
validation_method: "Penetration test + firewall rule review"
cde_network:
subnet: "10.100.0.0/24"
vlan: 100
components:
- name: "payment-api"
ip: "10.100.0.10"
function: "Processes card transactions via Stripe API"
stores_chd: false
transmits_chd: true
- name: "tokenization-service"
ip: "10.100.0.20"
function: "Tokenizes PAN before storage"
stores_chd: false # Only tokens stored
transmits_chd: true
segmentation_controls:
- control: "Firewall between CDE (VLAN 100) and corporate (VLAN 200)"
type: "network_security_control"
rules:
- direction: inbound
source: "10.200.0.0/24"
destination: "10.100.0.0/24"
action: deny_all
exceptions:
- port: 443
source: "10.200.0.50" # Admin jump box only
protocol: tcp
justification: "Administrative access with MFA"
- direction: outbound
source: "10.100.0.0/24"
destination: "0.0.0.0/0"
action: deny_all
exceptions:
- port: 443
destination: "api.stripe.com"
protocol: tcp
justification: "Payment processor API"
- port: 443
destination: "10.200.0.30" # Log collector
protocol: tcp
justification: "Centralized audit logging"
- control: "Cloud security groups (AWS)"
type: "network_security_control"
rules:
- sg_name: "cde-payment-api-sg"
inbound:
- port: 443
source: "sg-alb-internal"
justification: "Internal ALB for payment traffic"
outbound:
- port: 443
destination: "pl-stripe-api" # AWS prefix list
justification: "Stripe API calls"
validation_results:
penetration_test_date: "2026-02-10"
assessor: "External QSA firm"
findings:
- severity: "pass"
description: "No unauthorized connectivity from corporate to CDE"
- severity: "pass"
description: "CDE egress restricted to documented destinations only"
- severity: "info"
description: "Recommend adding network flow logging for CDE subnets"
encryption_requirements:
standard: "PCI-DSS v4.0"
last_reviewed: "2026-02-20"
data_at_rest:
requirement: "Req 3.5 -- PAN rendered unreadable anywhere stored"
current_implementation:
method: "Application-level encryption"
algorithm: "AES-256-GCM"
key_management:
kms: "AWS KMS"
key_type: "Customer-managed CMK"
rotation: "Annual automatic rotation"
split_knowledge: true
dual_control: true
note: >
Disk-level encryption (e.g., EBS encryption) is used as defense-in-depth
but is NOT the sole mechanism per PCI-DSS v4.0 Req 3.5.1.2.
tokenization:
provider: "Stripe"
method: "Payment method tokenization"
pan_stored: false
token_format: "tok_xxxxxxxxxxxx"
note: "PAN never enters our systems; only tokens stored in application DB"
data_in_transit:
requirement: "Req 4.2 -- Strong cryptography during transmission"
current_implementation:
external:
protocol: "TLS 1.3"
cipher_suites:
- "TLS_AES_256_GCM_SHA384"
- "TLS_CHACHA20_POLY1305_SHA256"
certificate_provider: "AWS ACM"
hsts: true
hsts_max_age: 31536000
internal:
protocol: "mTLS (mutual TLS 1.3)"
service_mesh: "Istio"
certificate_authority: "Internal CA (cert-manager)"
rotation: "Every 24 hours (automatic)"
key_management:
requirement: "Req 3.6 and 3.7 -- Key management procedures"
procedures:
- process: "Key generation"
method: "AWS KMS hardware security module (FIPS 140-2 Level 3)"
- process: "Key distribution"
method: "KMS grants and key policies; keys never leave HSM boundary"
- process: "Key storage"
method: "AWS KMS (HSM-backed); no plaintext keys stored anywhere"
- process: "Key rotation"
method: "Annual automatic rotation; old key versions retained for decryption"
- process: "Key destruction"
method: "KMS key deletion with 30-day waiting period; logged and audited"
- process: "Split knowledge / dual control"
method: "Key policy requires 2 IAM principals from different teams to modify"
Scoping:
Network and Systems (Req 1-2):
Data Protection (Req 3-4):
Vulnerability Management (Req 5-6):
Access Control (Req 7-9):
Monitoring and Testing (Req 10-11):
Policy and Program (Req 12):