bmad-plus 0.4.4 → 0.6.0

package/src/bmad-plus/packs/pack-shield/references/soc2/vendor.md

@@ -0,0 +1,276 @@
+# SOC 2 Vendor Risk Reference
+
+## Table of Contents
+1. [Vendor Risk Program Overview](#vendor-risk-program-overview)
+2. [Vendor Inventory Template](#vendor-inventory-template)
+3. [Vendor Risk Questionnaire](#vendor-risk-questionnaire)
+4. [Reviewing a Vendor's SOC 2 Report](#reviewing-a-vendors-soc-2-report)
+5. [CUEC Management](#cuec-management)
+6. [Vendor Onboarding Checklist](#vendor-onboarding-checklist)
+
+---
+
+## Vendor Risk Program Overview
+
+SOC 2 CC9.2 requires organizations to assess and manage risks arising from vendors and business
+partners who have access to systems or data, or on whom the organization depends for critical
+services.
+
+### What auditors look for:
+1. A **vendor inventory** exists and is maintained
+2. Vendors are **tiered by risk** and assessed accordingly
+3. **Due diligence** was performed before critical vendors were onboarded
+4. Vendor assessments are **reviewed at least annually**
+5. **Contracts** include appropriate security and data protection requirements
+6. **CUECs** from vendor SOC 2 reports are identified and addressed
+
+---
+
+## Vendor Inventory Template
+
+Maintain a spreadsheet or GRC tool record for each vendor:
+
+| Field | Description |
+|---|---|
+| Vendor Name | Legal entity name |
+| Service Provided | What they do for you |
+| Risk Tier | Critical / High / Medium / Low |
+| Data Access | Types of data they can access (PII, Confidential, none) |
+| System Access | Production / Staging / None |
+| SOC 2 Available? | Yes / No / In progress |
+| Last Assessment Date | Date of most recent due diligence |
+| Next Review Due | Based on tier cadence |
+| Contract Expiry | Date |
+| DPA Signed? | Yes / No / N/A |
+| Security Addendum? | Yes / No / N/A |
+| Primary Contact | Vendor security/legal contact |
+| Owner | Internal stakeholder who owns the relationship |
+
+### Risk Tier Definitions
+
+**Critical:** Vendor has access to production systems or processes/stores customer PII.
+Examples: AWS, Azure, GCP, Salesforce, Snowflake, Stripe, database vendors.
+- Requires: SOC 2 report review OR full questionnaire + annual re-assessment
+- Contract must include: DPA, security addendum, breach notification <72hr, right to audit
+
+**High:** Vendor processes sensitive business data or is operationally critical.
+Examples: HR systems (Workday, Rippling), GitHub, Slack, identity providers.
+- Requires: SOC 2 report or questionnaire annually
+- Contract must include: DPA (if any personal data), security requirements
+
+**Medium:** Limited data exposure, some operational dependency.
+Examples: Project management tools, design tools, analytics platforms.
+- Requires: Security questionnaire or SOC 2 review at onboarding + biennial review
+- Contract should include: acceptable use and data handling clauses
+
+**Low:** No meaningful data access, low operational risk.
+Examples: Office supplies vendors, most SaaS point solutions without data access.
+- Requires: Lightweight onboarding check (do they have a security program?)
+- Standard contract terms sufficient
+
+---
+
+## Vendor Risk Questionnaire
+
+Use this questionnaire for High/Critical vendors that don't have a SOC 2 report, or to
+supplement a SOC 2 report. Customize based on the vendor's service type.
+
+---
+
+### Section 1: Company and Security Program
+
+1. Does your organization have a documented Information Security Policy? If yes, when was it last reviewed?
+
+2. Do you have a dedicated security function (e.g., CISO, security team)? Please describe its structure.
+
+3. Has your organization undergone any third-party security assessments in the past 12 months? (SOC 2, ISO 27001, pen test, etc.) If yes, please provide the most recent report or executive summary.
+
+4. Does your organization carry cybersecurity insurance? Please provide coverage amount.
+
+5. Have you experienced a security incident or data breach in the past 24 months that affected customers? If yes, please describe.
+
+---
+
+### Section 2: Access Controls
+
+6. Do you enforce multi-factor authentication (MFA) for access to systems that process our data? Which systems require MFA?
+
+7. How do you manage privileged/admin access? Do you use a Privileged Access Management (PAM) solution?
+
+8. How quickly are accounts for terminated employees deprovisioned? What is your offboarding process?
+
+9. Do you perform periodic access reviews? How frequently?
+
+10. Is access to customer data restricted to personnel who require it for their role (least privilege)?
+
+---
+
+### Section 3: Data Protection
+
+11. What data do you collect, process, or store on our behalf? Please provide a data inventory or data flow diagram.
+
+12. Is data encrypted at rest? If yes, what encryption standard is used?
+
+13. Is data encrypted in transit? What TLS version is enforced?
+
+14. How is our data logically separated from data belonging to other customers (multi-tenancy)?
+
+15. What is your data retention policy? How and when is our data deleted at contract end?
+
+16. Do you have a sub-processor/sub-vendor list? Will you notify us before engaging new sub-processors?
+
+---
+
+### Section 4: Incident Response
+
+17. Do you have a documented Incident Response Plan? When was it last tested?
+
+18. What is your process and timeline for notifying customers of a security incident that affects their data?
+
+19. Do you maintain security logs? For how long are logs retained?
+
+20. Do you have a SIEM or security monitoring solution in place?
+
+---
+
+### Section 5: Vulnerability Management
+
+21. How frequently do you perform vulnerability scanning on systems that process our data?
+
+22. What is your SLA for remediating critical and high vulnerabilities?
+
+23. How frequently do you perform penetration testing? Who performs it (internal or third-party)?
+
+24. Do you have a patch management program? What is your patching cadence?
+
+---
+
+### Section 6: Business Continuity
+
+25. Do you have a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP)?
+
+26. What are your RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for the systems we depend on?
+
+27. How frequently do you test your DR plan? When was the last test performed?
+
+28. Do you have redundant infrastructure (e.g., multi-region, HA setup)?
+
+---
+
+### Section 7: Compliance and Legal
+
+29. Are you subject to any industry-specific compliance requirements (HIPAA, PCI-DSS, GDPR, etc.)? Are you currently compliant?
+
+30. Are you willing to sign a Data Processing Agreement (DPA) with our organization?
+
+31. Will you notify us within 72 hours of becoming aware of a breach involving our data?
+
+32. Do you have a process for responding to Data Subject Requests (DSRs) that require action on data you process on our behalf?
+
+---
+
+### Scoring Guidance
+
+For each question, score:
+- **2** — Fully in place with evidence available
+- **1** — Partially in place or controls exist but not fully documented/tested
+- **0** — Not in place
+
+| Score Range | Risk Level | Recommendation |
+|---|---|---|
+| 45–64 | Low risk | Proceed; standard contract terms |
+| 30–44 | Medium risk | Proceed with DPA; annual re-review |
+| 15–29 | High risk | Requires security addendum; risk acceptance from CISO |
+| 0–14 | Critical risk | Escalate to leadership; consider alternative vendor |
+
+---
+
+## Reviewing a Vendor's SOC 2 Report
+
+When a vendor provides their SOC 2 report, review the following:
+
+### 1. Report Basics
+- **Report type:** Is it Type 1 (design only) or Type 2 (operating effectiveness)? Prefer Type 2.
+- **Audit period:** Does it cover a recent period? Reports older than 12 months are stale.
+- **Criteria in scope:** Does the report include the criteria relevant to your use case? (e.g., if you care about availability, is Availability in scope?)
+- **Auditor:** Is the CPA firm reputable? (Larger firms: Deloitte, KPMG, EY, PwC, Grant Thornton, etc.)
+
+### 2. Auditor's Opinion
+- **Unqualified (clean) opinion:** No material exceptions. 
+- **Qualified opinion:** One or more criteria not met — flag for review.
+- **Adverse opinion:** Multiple failures — escalate, this is a significant red flag.
+
+### 3. Exceptions and Deviations
+- Read the "results of tests of controls" section carefully.
+- Any **exceptions** (control failures during the audit period) must be evaluated:
+  - Is the control we depend on the one that had exceptions?
+  - What was the vendor's remediation plan?
+  - Has it been addressed (look for management response)?
+
+### 4. Complementary User Entity Controls (CUECs)
+- Look for a section titled "Complementary User Entity Controls" or similar.
+- These are controls the vendor *requires you to operate* for their controls to be effective.
+- You must address every applicable CUEC (see [CUEC Management](#cuec-management) below).
+
+### 5. System Description
+- Does the description match the services you actually use?
+- Are the systems and infrastructure you depend on included in scope?
+
+### Review Log Entry
+
+Document each vendor SOC 2 review:
+```
+Vendor:             [Name]
+Report Type:        Type 1 / Type 2
+Audit Period:       [From] – [To]
+Date Reviewed:      [Date]
+Reviewed By:        [Name / Role]
+Opinion:            Unqualified / Qualified / Adverse
+Notable Exceptions: [None / Description]
+CUECs Identified:   [None / List]
+CUECs Addressed:    [Yes / Partial / No — with details]
+Risk Rating:        Low / Medium / High
+Action Items:       [Any follow-up required]
+```
+
+---
+
+## CUEC Management
+
+CUECs (Complementary User Entity Controls) are controls a vendor assumes *you* have in place.
+If you don't have them, the vendor's controls may not fully protect your environment.
+
+### Common CUECs and Typical Responses
+
+| Common CUEC | Typical Vendor (Example) | Your Corresponding Control |
+|---|---|---|
+| "User entities restrict access to the service using the vendor's access control features" | AWS, Salesforce | Access control policy; MFA enforcement; role-based access |
+| "User entities are responsible for monitoring for unauthorized access using access logs" | AWS CloudTrail, Okta | SIEM ingesting vendor logs; alerting on suspicious logins |
+| "User entities configure data encryption using the features provided" | AWS S3, RDS | Encryption enabled at rest; documented in system configuration |
+| "User entities are responsible for their users' credentials" | Any SaaS | Password policy; MFA policy; offboarding process |
+| "User entities notify the vendor of any personnel changes" | Managed service providers | Offboarding SOP includes notifying critical vendors |
+| "User entities perform their own risk assessments" | Most vendors | Annual risk assessment process (CC3) |
+
+### CUEC Tracking Spreadsheet Fields
+
+| CUEC # | Vendor | CUEC Description | Applicable? | Corresponding Control | Evidence | Owner | Status |
+|---|---|---|---|---|---|---|---|
+| 1 | AWS | Users restrict access via IAM | Yes | Access Control Policy + IAM review | Quarterly IAM review records | DevOps | Met |
+| 2 | Salesforce | Users monitor login activity | Yes | SIEM ingests Salesforce logs | SIEM screenshots | Security | Met |
+
+---
+
+## Vendor Onboarding Checklist
+
+Before onboarding a new Critical or High-tier vendor:
+
+- [ ] Risk tier assigned based on data access and operational dependency
+- [ ] Security questionnaire sent (or SOC 2 report requested)
+- [ ] Questionnaire/report reviewed and scored
+- [ ] Risk acceptance documented if score is medium/high
+- [ ] Data Processing Agreement (DPA) executed (if PII involved)
+- [ ] Security addendum signed (for Critical vendors)
+- [ ] Contract includes: breach notification <72hr, data deletion on termination, right to audit
+- [ ] CUECs identified and mapped to internal controls
+- [ ] Vendor added to inventory with next review date
+- [ ] Onboarding approved by CISO or security owner

package/src/bmad-plus/packs/pack-shield/references/swift-csp/swift-assessment.md

@@ -0,0 +1,202 @@
+# SWIFT CSCF — Assessment Process, Attestation, and Cross-Framework Mapping
+
+---
+
+## KYC-SA Attestation Process
+
+### Overview
+All SWIFT users must submit an annual **KYC Security Attestation (KYC-SA)** confirming compliance with the CSCF mandatory controls. The attestation is submitted through the SWIFT portal at swift.com/myswift and is visible to your counterparties.
+
+### Attestation Workflow
+
+1. **Prepare evidence** — Gather implementation evidence for all 23 mandatory controls applicable to your architecture type
+2. **Engage independent assessor** — Community-standard users must have an independent assessor validate compliance (see below)
+3. **Complete KYC-SA form** — For each mandatory control, attest: Implemented / Partially Implemented / Not Implemented
+4. **Submit by July 31** — Annual deadline; late submission triggers counterparty notifications
+5. **Address counterparty queries** — Counterparties can view your attestation and may request clarification
+
+### Independent Assessment Requirements
+
+Since CSCF v2020, an **independent assessment** is required for all users (previously self-attestation was permitted for smaller institutions):
+
+| Assessment Standard | Applies To |
+|--------------------|-----------|
+| Community Standard Assessment (CSA) | All SWIFT users not subject to Enhanced Standard |
+| Enhanced Standard | Users on enhanced programmes or at regulator request |
+
+**Who can act as an independent assessor:**
+- Internal audit team (if sufficiently independent from the SWIFT operations team)
+- External audit firm with SWIFT CSP assessment competency
+- SWIFT-certified assessors (listed on SWIFT's KYC Registry)
+- The assessor must not have operational responsibility for the SWIFT environment assessed
+
+**Assessment scope:** All 23 mandatory controls applicable to the architecture type; advisory controls optionally included.
+
+---
+
+## CSCF v2024 → v2025 Key Changes
+
+| Change Area | v2024 | v2025 |
+|-------------|-------|-------|
+| Control count | 31 (23 mandatory, 8 advisory) | 31 (no change) |
+| 2.2 Patching SLAs | Critical: 7 days | Critical: 3 days (tightened) |
+| 4.2 MFA | Hardware token strongly recommended | Hardware token explicitly required; clarified app-based OTP insufficient for most types |
+| 6.4 Log retention | 1 year minimum | Clarified: 1 year online, 3 years total |
+| 7.1 SWIFT notification | 24-hour notification | Unchanged; emphasis on 30-day full report |
+| A4 (Cloud) | Introduced in v2023 | Further clarified; cloud-specific guidance expanded |
+| Assessment guidance | Community standard | Updated assessor qualification criteria |
+
+---
+
+## SWIFT Incident Notification Obligations
+
+SWIFT requires notification when a cyber incident affects SWIFT infrastructure or transactions:
+
+| Milestone | Deadline |
+|-----------|----------|
+| Initial notification to SWIFT (via CISO mailbox or KYC-SA portal) | 24 hours from confirmed cyber incident |
+| Full incident report to SWIFT | 30 days |
+| Internal escalation to senior management | Immediately upon detection |
+| Law enforcement / regulatory notification | Per local requirements (varies by jurisdiction) |
+
+**What constitutes a notifiable incident:**
+- Unauthorised access to SWIFT systems or software
+- Compromise of SWIFT credentials (operator tokens, passwords)
+- Fraudulent or anomalous SWIFT transactions suspected to be cyber-related
+- Malware found on SWIFT-connected systems
+- Ransomware affecting the SWIFT zone
+
+**SWIFT contact for incidents:** security@swift.com (SWIFT CISO office) and your SWIFT relationship manager.
+
+---
+
+## Service Bureau (Type B) Responsibilities
+
+When using a service bureau (Type B architecture), responsibilities are split:
+
+| Control Area | Service Bureau Responsibility | Customer Responsibility |
+|-------------|-------------------------------|------------------------|
+| SWIFT infrastructure security (1.1, 2.2, 2.3, 6.1, 6.2, 6.3) | Bureau attests on their KYC-SA | Customer must obtain and review bureau's KYC-SA |
+| Operator access (4.2, 5.1) | Bureau provides access mechanism | Customer responsible for own operators' access |
+| Log monitoring (6.4) | Bureau provides logs; may operate SIEM | Customer should receive relevant logs; review access |
+| Incident response (7.1) | Bureau has own IRP | Customer must have SWIFT-specific addendum |
+| Training (7.2) | Bureau trains its own staff | Customer trains own SWIFT users |
+
+**Key obligation:** Customers using a service bureau must review their bureau's KYC-SA attestation annually and obtain assurance of compliance (Control 2.8). If the bureau is non-compliant, the customer may face counterparty notifications.
+
+---
+
+## Cross-Framework Mapping
+
+### SWIFT CSCF ↔ ISO/IEC 27001:2022
+
+| CSCF Control | ISO 27001:2022 Annex A Controls |
+|-------------|--------------------------------|
+| 1.1 SWIFT Environment Protection | A.8.22 (Segregation of networks), A.8.20 (Network security) |
+| 1.2 OS Privileged Account Control | A.8.2 (Privileged access rights), A.8.18 (Use of privileged utility programs) |
+| 1.4 Internet Restriction | A.8.20 (Network security), A.8.22 (Segregation) |
+| 2.1 Internal Data Flow Security | A.8.24 (Cryptography), A.8.20 (Network security) |
+| 2.2 Security Updates | A.8.8 (Management of technical vulnerabilities) |
+| 2.3 System Hardening | A.8.8 (Technical vulnerability management), A.8.9 (Configuration management) |
+| 2.6 Operator Session Security | A.8.24 (Cryptography), A.8.20 (Network security) |
+| 2.7 Vulnerability Scanning | A.8.8 (Technical vulnerability management) |
+| 2.8 Critical Activity Outsourcing | A.5.19 (Supplier relationships), A.5.20 (Addressing security in supplier agreements) |
+| 3.1 Physical Security | A.7.1 (Physical security perimeters), A.7.2 (Physical entry) |
+| 4.1 Password Policy | A.8.5 (Secure authentication) |
+| 4.2 Multi-Factor Authentication | A.8.5 (Secure authentication) |
+| 5.1 Logical Access Controls | A.8.3 (Information access restriction), A.8.2 (Privileged access rights) |
+| 5.2 Token Management | A.8.5 (Secure authentication), A.8.2 (Privileged access rights) |
+| 6.1 Malware Protection | A.8.7 (Protection against malware) |
+| 6.2 Software Integrity | A.8.19 (Installation of software on operational systems), A.8.29 (Security testing in development) |
+| 6.3 Database Integrity | A.8.3 (Information access restriction) |
+| 6.4 Log and Monitoring | A.8.15 (Logging), A.8.16 (Monitoring activities) |
+| 7.1 Incident Response | A.5.24 (Planning and preparation), A.5.26 (Response to incidents) |
+| 7.2 Security Training | A.6.3 (Information security awareness) |
+
+**Synergy note:** An ISO 27001-certified organisation will have satisfied many CSCF controls through their ISMS. However, SWIFT CSP adds SWIFT-specific requirements (e.g., hardware MFA tokens, SWIFT log sources, KYC-SA submission) that are not automatically covered by ISO 27001.
+
+---
+
+### SWIFT CSCF ↔ PCI DSS v4.0.1
+
+| CSCF Control | PCI DSS Requirement |
+|-------------|---------------------|
+| 1.1 SWIFT Environment Protection | Req 1 (Network security controls), Req 1.2 (Firewall rules) |
+| 1.4 Internet Restriction | Req 1.3 (Restrict inbound/outbound traffic) |
+| 2.2 Security Updates | Req 6.3 (Security vulnerabilities addressed) |
+| 2.3 System Hardening | Req 2.2 (System components configured securely) |
+| 4.1 Password Policy | Req 8.3 (Strong authentication) |
+| 4.2 Multi-Factor Authentication | Req 8.4 (MFA for non-console admin access and remote access) |
+| 5.1 Logical Access Controls | Req 7 (Restrict access to system components and cardholder data) |
+| 6.1 Malware Protection | Req 5 (Protect against malicious software) |
+| 6.4 Log and Monitoring | Req 10 (Log and monitor all access) |
+| 7.1 Incident Response | Req 12.10 (Incident response plan) |
+
+**Key difference:** PCI DSS focuses on cardholder data environments; SWIFT CSP focuses on the SWIFT messaging infrastructure. A PCI-compliant organisation will have a strong security foundation but will need SWIFT-specific additions (e.g., hardware MFA, SWIFT log sources, 1-year log retention, KYC-SA submission).
+
+---
+
+### SWIFT CSCF ↔ NIST CSF 2.0
+
+| CSCF Control | NIST CSF 2.0 Function/Category |
+|-------------|-------------------------------|
+| 1.1 SWIFT Environment Protection | PR.IR (Infrastructure Resilience) |
+| 2.2 Security Updates | PR.PS-2 (Software, firmware patched) |
+| 2.3 System Hardening | PR.PS-1 (Configuration management) |
+| 4.2 MFA | PR.AA-3 (Authentication) |
+| 5.1 Logical Access Controls | PR.AA-1 (Identity management) |
+| 6.1 Malware Protection | PR.PS-3 (Malware protection) |
+| 6.4 Log and Monitoring | DE.CM (Continuous monitoring) |
+| 7.1 Incident Response | RS.MA (Incident management) |
+| 7.2 Security Training | PR.AT (Awareness and training) |
+
+---
+
+## Regulatory Context
+
+SWIFT CSP compliance is increasingly referenced in financial sector regulation:
+
+| Jurisdiction | Regulatory Reference |
+|-------------|---------------------|
+| **EU** | ECB TIBER-EU framework; EBA ICT guidelines under DORA reference SWIFT CSP for financial messaging |
+| **US** | FFIEC Cybersecurity Assessment Tool references correspondent banking controls; NY DFS 23 NYCRR 500 aligns to SWIFT CSP |
+| **UK** | Bank of England / PRA supervisory expectations for payment systems include SWIFT CSP |
+| **Singapore** | MAS TRM (Technology Risk Management) guidelines align to SWIFT CSP for banks |
+| **Hong Kong** | HKMA Cybersecurity Fortification Initiative (CFI) references SWIFT CSP for Tier 1 and 2 banks |
+| **Australia** | APRA CPS 234 includes SWIFT CSP controls under critical third-party system security |
+
+---
+
+## Gap Assessment Checklist Template
+
+For each mandatory control, assess against these criteria:
+
+| Column | Description |
+|--------|-------------|
+| Control ID | e.g., 4.2 |
+| Status | 🔴 Not Implemented / 🟡 Partially Implemented / 🟢 Implemented |
+| Evidence Available | Yes / No / Partial |
+| Evidence Type | Policy / Configuration / Logs / Test result / Screenshot |
+| Gap Description | Specific gap narrative |
+| Remediation Action | Concrete step to close the gap |
+| Owner | Team/individual responsible |
+| Target Date | When gap will be closed |
+| Attestation Impact | If 🔴: Attest as Not Implemented; if 🟡: Partially; if 🟢: Implemented |
+
+---
+
+## Most Common CSCF Non-Compliance Patterns
+
+1. **Software-based OTP for MFA (Control 4.2):** Many organisations use authenticator apps rather than hardware tokens. SWIFT CSP requires hardware tokens for most architecture types.
+
+2. **Shared operator accounts (Control 5.1):** Named individual accounts not enforced; multiple operators sharing one account ID — makes non-repudiation impossible.
+
+3. **Log retention gaps (Control 6.4):** Logs collected but not retained for 1+ years; SWIFT-specific log sources (Alliance Access/Gateway) not included in SIEM scope.
+
+4. **Patch exceptions undocumented (Control 2.2):** Critical patches overdue beyond 3-day SLA with no documented exception/compensating control.
+
+5. **SWIFT zone not documented (Control 1.1):** Secure Zone exists technically but no network diagram; or servers are dual-homed to both SWIFT zone and corporate network.
+
+6. **No SWIFT-specific IRP (Control 7.1):** General incident response plan exists but no SWIFT-specific section covering SWIFT notification obligations and fraud scenarios.
+
+7. **Token inventory not maintained (Control 5.2):** Hardware tokens issued but no central inventory; deprovisioning process for leavers undocumented.