mirror of
https://github.com/BagelHole/DevOps-Security-Agent-Skills.git
synced 2026-08-22 12:49:53 +02:00
V2
This commit is contained in:
Toby
@@ -9,63 +9,421 @@ metadata:
|
||||
|
||||
# FedRAMP Compliance
|
||||
|
||||
Implement FedRAMP requirements for federal cloud services.
|
||||
Implement FedRAMP (Federal Risk and Authorization Management Program) requirements for cloud service providers serving US federal agencies.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Pursuing FedRAMP authorization for a cloud service offering
|
||||
- Implementing NIST 800-53 security controls for federal workloads
|
||||
- Establishing continuous monitoring (ConMon) processes
|
||||
- Managing Plan of Action and Milestones (POA&M) tracking
|
||||
- Preparing for a Third-Party Assessment Organization (3PAO) audit
|
||||
- Operating a FedRAMP-authorized system and maintaining authorization
|
||||
|
||||
## Impact Levels
|
||||
|
||||
```yaml
|
||||
levels:
|
||||
impact_levels:
|
||||
low:
|
||||
controls: ~125
|
||||
use_case: Public data
|
||||
|
||||
control_count: ~125
|
||||
use_case: "Publicly available federal information"
|
||||
examples:
|
||||
- Public-facing websites with no sensitive data
|
||||
- Open data portals
|
||||
- Marketing and informational systems
|
||||
data_types: "No PII, no CUI, publicly releasable only"
|
||||
authorization_path: "FedRAMP Tailored (Li-SaaS) or standard Low"
|
||||
|
||||
moderate:
|
||||
controls: ~325
|
||||
use_case: CUI, most federal systems
|
||||
|
||||
control_count: ~325
|
||||
use_case: "Most federal systems, including CUI"
|
||||
examples:
|
||||
- Email and collaboration platforms
|
||||
- Case management systems
|
||||
- Financial management systems
|
||||
- HR and personnel systems
|
||||
data_types: "CUI, PII, law enforcement sensitive (LES)"
|
||||
authorization_path: "Agency or JAB P-ATO"
|
||||
note: "~80% of FedRAMP authorizations are at Moderate"
|
||||
|
||||
high:
|
||||
controls: ~425
|
||||
use_case: Law enforcement, emergency services
|
||||
control_count: ~425
|
||||
use_case: "High-impact federal systems"
|
||||
examples:
|
||||
- Law enforcement and criminal justice systems
|
||||
- Emergency services and public safety
|
||||
- Financial systems with significant impact
|
||||
- Healthcare systems with PHI
|
||||
data_types: "Classified-adjacent, life-safety, critical infrastructure"
|
||||
authorization_path: "JAB P-ATO required"
|
||||
```
|
||||
|
||||
## NIST 800-53 Families
|
||||
## NIST 800-53 Control Families
|
||||
|
||||
```yaml
|
||||
control_families:
|
||||
AC: Access Control
|
||||
AU: Audit and Accountability
|
||||
AT: Awareness and Training
|
||||
CM: Configuration Management
|
||||
CP: Contingency Planning
|
||||
IA: Identification and Authentication
|
||||
IR: Incident Response
|
||||
MA: Maintenance
|
||||
MP: Media Protection
|
||||
PE: Physical Protection
|
||||
PL: Planning
|
||||
PS: Personnel Security
|
||||
RA: Risk Assessment
|
||||
CA: Assessment and Authorization
|
||||
SC: System and Communications Protection
|
||||
SI: System and Information Integrity
|
||||
SA: System and Services Acquisition
|
||||
PM: Program Management
|
||||
AC:
|
||||
name: "Access Control"
|
||||
key_controls:
|
||||
AC-2: "Account Management - manage system accounts lifecycle"
|
||||
AC-3: "Access Enforcement - enforce approved authorizations"
|
||||
AC-6: "Least Privilege - employ principle of least privilege"
|
||||
AC-17: "Remote Access - establish usage restrictions for remote access"
|
||||
implementation_notes: "Map to IAM policies, RBAC, MFA enforcement"
|
||||
|
||||
AU:
|
||||
name: "Audit and Accountability"
|
||||
key_controls:
|
||||
AU-2: "Audit Events - define auditable events"
|
||||
AU-3: "Content of Audit Records - ensure records contain required info"
|
||||
AU-6: "Audit Review, Analysis, and Reporting"
|
||||
AU-12: "Audit Generation - generate audit records"
|
||||
implementation_notes: "Map to CloudTrail, CloudWatch Logs, SIEM"
|
||||
|
||||
AT:
|
||||
name: "Awareness and Training"
|
||||
key_controls:
|
||||
AT-2: "Security Awareness Training - provide training to users"
|
||||
AT-3: "Role-Based Security Training - for personnel with security roles"
|
||||
implementation_notes: "Annual security training, role-specific training"
|
||||
|
||||
CM:
|
||||
name: "Configuration Management"
|
||||
key_controls:
|
||||
CM-2: "Baseline Configuration - develop and maintain baseline"
|
||||
CM-6: "Configuration Settings - establish mandatory settings"
|
||||
CM-7: "Least Functionality - restrict to essential capabilities"
|
||||
CM-8: "Information System Component Inventory"
|
||||
implementation_notes: "Map to AWS Config, SSM, hardened AMIs"
|
||||
|
||||
CP:
|
||||
name: "Contingency Planning"
|
||||
key_controls:
|
||||
CP-2: "Contingency Plan - develop and maintain plan"
|
||||
CP-4: "Contingency Plan Testing - test plan annually"
|
||||
CP-9: "Information System Backup"
|
||||
CP-10: "Information System Recovery and Reconstitution"
|
||||
implementation_notes: "Map to DR plan, backup strategy, failover testing"
|
||||
|
||||
IA:
|
||||
name: "Identification and Authentication"
|
||||
key_controls:
|
||||
IA-2: "Identification and Authentication (Org Users)"
|
||||
IA-5: "Authenticator Management"
|
||||
IA-8: "Identification and Authentication (Non-Org Users)"
|
||||
implementation_notes: "Map to SSO, MFA, certificate-based auth, PIV/CAC"
|
||||
|
||||
IR:
|
||||
name: "Incident Response"
|
||||
key_controls:
|
||||
IR-2: "Incident Response Training"
|
||||
IR-4: "Incident Handling - implement incident handling capability"
|
||||
IR-6: "Incident Reporting - report incidents to US-CERT"
|
||||
IR-8: "Incident Response Plan"
|
||||
implementation_notes: "US-CERT reporting within 1 hour for federal incidents"
|
||||
|
||||
MA:
|
||||
name: "Maintenance"
|
||||
key_controls:
|
||||
MA-2: "Controlled Maintenance"
|
||||
MA-4: "Nonlocal Maintenance - authorize nonlocal maintenance"
|
||||
implementation_notes: "Patching procedures, remote maintenance controls"
|
||||
|
||||
MP:
|
||||
name: "Media Protection"
|
||||
key_controls:
|
||||
MP-2: "Media Access - restrict access to media"
|
||||
MP-6: "Media Sanitization - sanitize media prior to disposal"
|
||||
implementation_notes: "Encryption at rest, secure disposal procedures"
|
||||
|
||||
PE:
|
||||
name: "Physical and Environmental Protection"
|
||||
key_controls:
|
||||
PE-2: "Physical Access Authorizations"
|
||||
PE-3: "Physical Access Control"
|
||||
PE-6: "Monitoring Physical Access"
|
||||
implementation_notes: "Inherit from CSP for IaaS/PaaS, document inheritance"
|
||||
|
||||
PL:
|
||||
name: "Planning"
|
||||
key_controls:
|
||||
PL-2: "System Security Plan (SSP)"
|
||||
implementation_notes: "SSP is the core FedRAMP deliverable"
|
||||
|
||||
PS:
|
||||
name: "Personnel Security"
|
||||
key_controls:
|
||||
PS-3: "Personnel Screening"
|
||||
PS-4: "Personnel Termination"
|
||||
PS-5: "Personnel Transfer"
|
||||
implementation_notes: "Background checks, access revocation on termination"
|
||||
|
||||
RA:
|
||||
name: "Risk Assessment"
|
||||
key_controls:
|
||||
RA-3: "Risk Assessment - conduct risk assessment"
|
||||
RA-5: "Vulnerability Scanning"
|
||||
implementation_notes: "Annual risk assessment, monthly vulnerability scans"
|
||||
|
||||
CA:
|
||||
name: "Security Assessment and Authorization"
|
||||
key_controls:
|
||||
CA-2: "Security Assessments"
|
||||
CA-6: "Security Authorization"
|
||||
CA-7: "Continuous Monitoring"
|
||||
implementation_notes: "Annual assessment by 3PAO, ConMon program"
|
||||
|
||||
SC:
|
||||
name: "System and Communications Protection"
|
||||
key_controls:
|
||||
SC-7: "Boundary Protection"
|
||||
SC-8: "Transmission Confidentiality and Integrity"
|
||||
SC-12: "Cryptographic Key Establishment and Management"
|
||||
SC-13: "Cryptographic Protection - FIPS 140-2 validated"
|
||||
SC-28: "Protection of Information at Rest"
|
||||
implementation_notes: "FIPS 140-2 validated modules required"
|
||||
|
||||
SI:
|
||||
name: "System and Information Integrity"
|
||||
key_controls:
|
||||
SI-2: "Flaw Remediation"
|
||||
SI-3: "Malicious Code Protection"
|
||||
SI-4: "Information System Monitoring"
|
||||
SI-5: "Security Alerts, Advisories, and Directives"
|
||||
implementation_notes: "Patching SLAs, antimalware, IDS/IPS, SIEM"
|
||||
|
||||
SA:
|
||||
name: "System and Services Acquisition"
|
||||
key_controls:
|
||||
SA-4: "Acquisition Process - security requirements in contracts"
|
||||
SA-9: "External Information System Services"
|
||||
SA-11: "Developer Security Testing"
|
||||
implementation_notes: "Supply chain risk management, SBOM"
|
||||
|
||||
PM:
|
||||
name: "Program Management"
|
||||
key_controls:
|
||||
PM-1: "Information Security Program Plan"
|
||||
PM-9: "Risk Management Strategy"
|
||||
implementation_notes: "Organization-wide security program"
|
||||
```
|
||||
|
||||
## Continuous Monitoring
|
||||
## System Security Plan (SSP) Outline
|
||||
|
||||
```yaml
|
||||
conmon:
|
||||
vulnerability_scans: Monthly
|
||||
penetration_tests: Annual
|
||||
poa_m_updates: Monthly
|
||||
security_assessment: Annual
|
||||
ssp_sections:
|
||||
section_1: "Information System Name and Title"
|
||||
section_2: "Information System Categorization (FIPS 199)"
|
||||
section_3: "Information System Owner"
|
||||
section_4: "Authorizing Official"
|
||||
section_5: "Other Designated Contacts"
|
||||
section_6: "Assignment of Security Responsibility"
|
||||
section_7: "Information System Operational Status"
|
||||
section_8: "Information System Type (cloud service model)"
|
||||
section_9: "General System Description"
|
||||
section_10: "System Environment and Special Considerations"
|
||||
section_11: "System Interconnections"
|
||||
section_12: "Laws, Regulations, Policies Applicable"
|
||||
section_13: "Minimum Security Controls"
|
||||
|
||||
key_attachments:
|
||||
- "Control Implementation Summary (CIS) workbook"
|
||||
- "Network architecture diagrams"
|
||||
- "Data flow diagrams"
|
||||
- "Interconnection security agreements (ISAs)"
|
||||
- "Incident response plan"
|
||||
- "Contingency plan"
|
||||
- "Configuration management plan"
|
||||
```
|
||||
|
||||
## POA&M (Plan of Action and Milestones) Tracking
|
||||
|
||||
```yaml
|
||||
# poam_template.yaml
|
||||
poam_entry:
|
||||
- id: "POAM-2025-001"
|
||||
weakness: "AC-2(3) - Automated account disable after 90 days inactivity not implemented"
|
||||
control: "AC-2"
|
||||
risk_level: "moderate"
|
||||
finding_source: "3PAO Annual Assessment - 2025"
|
||||
date_identified: "2025-03-15"
|
||||
scheduled_completion: "2025-06-15"
|
||||
milestone_1:
|
||||
description: "Configure IdP inactivity policy"
|
||||
target_date: "2025-04-15"
|
||||
status: "complete"
|
||||
milestone_2:
|
||||
description: "Test automated disable in staging"
|
||||
target_date: "2025-05-01"
|
||||
status: "in_progress"
|
||||
milestone_3:
|
||||
description: "Deploy to production and validate"
|
||||
target_date: "2025-06-15"
|
||||
status: "not_started"
|
||||
responsible_party: "IAM Team"
|
||||
status: "open"
|
||||
vendor_dependency: false
|
||||
|
||||
- id: "POAM-2025-002"
|
||||
weakness: "RA-5 - Vulnerability scan coverage does not include container images"
|
||||
control: "RA-5"
|
||||
risk_level: "high"
|
||||
finding_source: "3PAO Annual Assessment - 2025"
|
||||
date_identified: "2025-03-15"
|
||||
scheduled_completion: "2025-05-15"
|
||||
milestone_1:
|
||||
description: "Evaluate and select container scanning tool"
|
||||
target_date: "2025-04-01"
|
||||
status: "complete"
|
||||
milestone_2:
|
||||
description: "Integrate scanning into CI/CD pipeline"
|
||||
target_date: "2025-04-30"
|
||||
status: "in_progress"
|
||||
milestone_3:
|
||||
description: "Demonstrate full coverage to 3PAO"
|
||||
target_date: "2025-05-15"
|
||||
status: "not_started"
|
||||
responsible_party: "Security Engineering"
|
||||
status: "open"
|
||||
vendor_dependency: false
|
||||
|
||||
poam_aging_thresholds:
|
||||
high: "Must be resolved within 30 days"
|
||||
moderate: "Must be resolved within 90 days"
|
||||
low: "Must be resolved within 180 days"
|
||||
overdue_escalation: "Reported to authorizing official monthly"
|
||||
```
|
||||
|
||||
## Continuous Monitoring (ConMon) Procedures
|
||||
|
||||
```yaml
|
||||
continuous_monitoring:
|
||||
monthly:
|
||||
vulnerability_scanning:
|
||||
scope: "All operating systems, databases, web applications, and containers"
|
||||
tool: "Tenable.io, Qualys, or equivalent"
|
||||
deliverable: "Monthly scan report with remediation status"
|
||||
sla:
|
||||
critical_cvss_9_plus: "Remediate within 30 days"
|
||||
high_cvss_7_to_9: "Remediate within 30 days"
|
||||
moderate_cvss_4_to_7: "Remediate within 90 days"
|
||||
low_cvss_below_4: "Remediate within 180 days"
|
||||
|
||||
poam_updates:
|
||||
action: "Update all open POA&M items with current status"
|
||||
deliverable: "Updated POA&M spreadsheet submitted to agency"
|
||||
content:
|
||||
- "Milestone completion updates"
|
||||
- "New POA&M items from scans"
|
||||
- "Closed POA&M items with evidence"
|
||||
|
||||
inventory_updates:
|
||||
action: "Review and update system component inventory"
|
||||
deliverable: "Updated hardware and software inventory"
|
||||
|
||||
quarterly:
|
||||
- "Review and update SSP with any system changes"
|
||||
- "Submit ConMon deliverables package to agency"
|
||||
- "Review access control lists and user accounts"
|
||||
- "Update network diagrams if changes occurred"
|
||||
|
||||
annual:
|
||||
security_assessment:
|
||||
performed_by: "3PAO"
|
||||
scope: "Subset of controls (~1/3 each year, full coverage in 3 years)"
|
||||
deliverable: "Security Assessment Report (SAR)"
|
||||
|
||||
penetration_testing:
|
||||
performed_by: "3PAO or qualified third party"
|
||||
scope: "External and internal network, web applications"
|
||||
deliverable: "Penetration test report with findings"
|
||||
|
||||
contingency_plan_test:
|
||||
scope: "Full DR/BCP test including failover"
|
||||
deliverable: "Contingency plan test report"
|
||||
|
||||
incident_response_test:
|
||||
scope: "Tabletop exercise or functional exercise"
|
||||
deliverable: "IR test report with lessons learned"
|
||||
```
|
||||
|
||||
## FedRAMP FIPS 140-2 Cryptography Requirements
|
||||
|
||||
```bash
|
||||
# Verify FIPS mode is enabled on Linux systems
|
||||
cat /proc/sys/crypto/fips_enabled
|
||||
# Output should be: 1
|
||||
|
||||
# Check OpenSSL FIPS module
|
||||
openssl version
|
||||
openssl list -providers # Should show FIPS provider
|
||||
|
||||
# AWS: Use FIPS endpoints
|
||||
# Example: Use FIPS endpoint for S3
|
||||
aws s3 ls --endpoint-url https://s3-fips.us-east-1.amazonaws.com
|
||||
|
||||
# Configure AWS CLI for FIPS
|
||||
# ~/.aws/config
|
||||
# [default]
|
||||
# use_fips_endpoint = true
|
||||
|
||||
# Verify TLS configuration meets FedRAMP requirements
|
||||
openssl s_client -connect your-service.example.com:443 -tls1_2 < /dev/null 2>/dev/null | \
|
||||
grep -E "Protocol|Cipher"
|
||||
# Must be TLS 1.2 or higher with FIPS-approved cipher suites
|
||||
```
|
||||
|
||||
## FedRAMP Authorization Checklist
|
||||
|
||||
```yaml
|
||||
authorization_checklist:
|
||||
pre_authorization:
|
||||
- [ ] Determine impact level (Low, Moderate, High)
|
||||
- [ ] Choose authorization path (Agency ATO or JAB P-ATO)
|
||||
- [ ] Engage FedRAMP PMO for readiness assessment
|
||||
- [ ] Select 3PAO from FedRAMP marketplace
|
||||
- [ ] Complete SSP with all control implementations documented
|
||||
- [ ] Develop required policies and procedures
|
||||
- [ ] Implement all applicable NIST 800-53 controls
|
||||
- [ ] Ensure FIPS 140-2 validated cryptographic modules in use
|
||||
|
||||
assessment:
|
||||
- [ ] 3PAO conducts readiness assessment (optional but recommended)
|
||||
- [ ] 3PAO conducts full security assessment
|
||||
- [ ] 3PAO delivers Security Assessment Report (SAR)
|
||||
- [ ] Develop POA&M for all findings
|
||||
- [ ] Remediate critical and high findings before authorization
|
||||
|
||||
authorization_package:
|
||||
- [ ] System Security Plan (SSP)
|
||||
- [ ] Security Assessment Report (SAR)
|
||||
- [ ] Plan of Action and Milestones (POA&M)
|
||||
- [ ] Continuous Monitoring Plan
|
||||
- [ ] Incident Response Plan
|
||||
- [ ] Contingency Plan
|
||||
- [ ] Configuration Management Plan
|
||||
- [ ] Control Implementation Summary (CIS)
|
||||
- [ ] Interconnection Security Agreements
|
||||
|
||||
post_authorization:
|
||||
- [ ] Establish ConMon program with monthly deliverables
|
||||
- [ ] Monthly vulnerability scanning and POA&M updates
|
||||
- [ ] Annual 3PAO assessment of control subset
|
||||
- [ ] Annual penetration testing
|
||||
- [ ] Report significant changes to authorizing official
|
||||
- [ ] Report security incidents to US-CERT within 1 hour
|
||||
- [ ] Maintain authorization by meeting ConMon requirements
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- 3PAO assessment
|
||||
- SSP documentation
|
||||
- POA&M tracking
|
||||
- Continuous monitoring
|
||||
- Annual authorization
|
||||
- Start with a FedRAMP Readiness Assessment to identify gaps before the formal 3PAO assessment
|
||||
- Use the FedRAMP SSP template exactly as provided to avoid review delays
|
||||
- Inherit controls from your IaaS provider (AWS GovCloud, Azure Government) and document the inheritance clearly
|
||||
- Implement FIPS 140-2 validated cryptographic modules for all encryption (TLS, at-rest, key management)
|
||||
- Automate continuous monitoring deliverables to reduce manual effort and human error
|
||||
- Maintain POA&M items within aging thresholds; overdue items risk losing authorization
|
||||
- Report significant system changes to the authorizing official before implementation
|
||||
- Treat the SSP as a living document and update it with every change to the system boundary
|
||||
- Use US-CERT reporting procedures and maintain the 1-hour incident notification requirement
|
||||
- Engage the FedRAMP PMO early and often for guidance on the authorization process
|
||||
|
||||
@@ -9,56 +9,552 @@ metadata:
|
||||
|
||||
# GDPR Compliance
|
||||
|
||||
Implement GDPR requirements for EU data protection.
|
||||
Implement General Data Protection Regulation requirements for organizations that process personal data of EU/EEA residents, covering lawful processing, data subject rights, and technical safeguards.
|
||||
|
||||
## Key Principles
|
||||
## When to Use
|
||||
|
||||
- Processing personal data of EU/EEA residents in any capacity
|
||||
- Building consent management and preference centers
|
||||
- Implementing Data Subject Access Request (DSAR) workflows
|
||||
- Conducting Data Protection Impact Assessments (DPIAs)
|
||||
- Setting up data processing agreements with third-party processors
|
||||
- Designing systems with privacy by design and by default principles
|
||||
|
||||
## Key Principles and Legal Bases
|
||||
|
||||
```yaml
|
||||
principles:
|
||||
lawfulness: Legal basis for processing
|
||||
purpose_limitation: Specific, explicit purposes
|
||||
data_minimization: Adequate, relevant, limited
|
||||
accuracy: Accurate and up to date
|
||||
storage_limitation: No longer than necessary
|
||||
integrity: Secure processing
|
||||
accountability: Demonstrate compliance
|
||||
gdpr_principles:
|
||||
article_5:
|
||||
lawfulness_fairness_transparency:
|
||||
description: "Process data lawfully, fairly, and transparently"
|
||||
implementation:
|
||||
- Document legal basis for every processing activity
|
||||
- Provide clear privacy notices
|
||||
- No hidden or deceptive data collection
|
||||
|
||||
purpose_limitation:
|
||||
description: "Collect for specified, explicit, and legitimate purposes"
|
||||
implementation:
|
||||
- Define purpose before collection
|
||||
- Do not repurpose data without new legal basis
|
||||
- Document all processing purposes in ROPA
|
||||
|
||||
data_minimization:
|
||||
description: "Adequate, relevant, and limited to what is necessary"
|
||||
implementation:
|
||||
- Collect only required fields
|
||||
- Review data models for unnecessary fields
|
||||
- Remove optional fields that are not used
|
||||
|
||||
accuracy:
|
||||
description: "Accurate and kept up to date"
|
||||
implementation:
|
||||
- Provide self-service profile editing
|
||||
- Implement data validation at point of entry
|
||||
- Schedule regular data quality reviews
|
||||
|
||||
storage_limitation:
|
||||
description: "Kept no longer than necessary"
|
||||
implementation:
|
||||
- Define retention periods per data category
|
||||
- Automate deletion when retention expires
|
||||
- Document retention schedule
|
||||
|
||||
integrity_and_confidentiality:
|
||||
description: "Appropriate security measures"
|
||||
implementation:
|
||||
- Encryption at rest and in transit
|
||||
- Access controls and audit logging
|
||||
- Pseudonymization where appropriate
|
||||
|
||||
accountability:
|
||||
description: "Demonstrate compliance"
|
||||
implementation:
|
||||
- Maintain Records of Processing Activities
|
||||
- Conduct DPIAs for high-risk processing
|
||||
- Appoint DPO if required
|
||||
|
||||
legal_bases:
|
||||
article_6:
|
||||
consent: "Freely given, specific, informed, unambiguous"
|
||||
contract: "Necessary for performance of a contract"
|
||||
legal_obligation: "Required by EU or member state law"
|
||||
vital_interests: "Protect life of data subject or another person"
|
||||
public_interest: "Task carried out in public interest"
|
||||
legitimate_interest: "Legitimate interest not overridden by data subject rights"
|
||||
```
|
||||
|
||||
## Data Subject Rights
|
||||
## Data Mapping Template (Records of Processing Activities)
|
||||
|
||||
```yaml
|
||||
rights:
|
||||
- Right to access
|
||||
- Right to rectification
|
||||
- Right to erasure
|
||||
- Right to restrict processing
|
||||
- Right to data portability
|
||||
- Right to object
|
||||
- Rights related to automated decisions
|
||||
# Record of Processing Activities (ROPA) - Article 30
|
||||
processing_activity:
|
||||
name: "Customer Account Management"
|
||||
controller: "Example Corp, 123 Main St, Dublin, Ireland"
|
||||
dpo_contact: "dpo@example.com"
|
||||
purpose: "Manage customer accounts, provide services, handle billing"
|
||||
legal_basis: "Contract (Art. 6(1)(b))"
|
||||
categories_of_data_subjects:
|
||||
- Customers
|
||||
- Prospective customers
|
||||
categories_of_personal_data:
|
||||
- Name, email, phone number
|
||||
- Billing address
|
||||
- Payment information (tokenized)
|
||||
- Service usage data
|
||||
- Support ticket history
|
||||
special_categories: "None"
|
||||
recipients:
|
||||
- Payment processor (Stripe) - processor
|
||||
- Email service (SendGrid) - processor
|
||||
- Cloud hosting (AWS) - processor
|
||||
international_transfers:
|
||||
- Destination: United States
|
||||
Safeguard: "Standard Contractual Clauses (SCCs)"
|
||||
TIA_completed: true
|
||||
retention_period: "Account data retained for duration of contract + 7 years for legal obligations"
|
||||
security_measures:
|
||||
- AES-256 encryption at rest
|
||||
- TLS 1.3 in transit
|
||||
- Role-based access control
|
||||
- Audit logging of all access
|
||||
dpia_required: false
|
||||
last_reviewed: "2024-06-01"
|
||||
|
||||
# Template for each processing activity
|
||||
processing_activity_template:
|
||||
name: ""
|
||||
controller: ""
|
||||
joint_controller: "" # if applicable
|
||||
processor: "" # if acting as processor
|
||||
dpo_contact: ""
|
||||
purpose: ""
|
||||
legal_basis: "" # consent | contract | legal_obligation | vital_interests | public_interest | legitimate_interest
|
||||
legitimate_interest_assessment: "" # if legitimate interest
|
||||
categories_of_data_subjects: []
|
||||
categories_of_personal_data: []
|
||||
special_categories: "" # Art. 9 data
|
||||
recipients: []
|
||||
international_transfers: []
|
||||
retention_period: ""
|
||||
security_measures: []
|
||||
dpia_required: false
|
||||
date_added: ""
|
||||
last_reviewed: ""
|
||||
```
|
||||
|
||||
## Technical Implementation
|
||||
## Consent Management Implementation
|
||||
|
||||
```python
|
||||
# Data export for portability
|
||||
def export_user_data(user_id):
|
||||
return {
|
||||
"profile": get_profile(user_id),
|
||||
"activity": get_activity_log(user_id),
|
||||
"preferences": get_preferences(user_id)
|
||||
}
|
||||
"""
|
||||
Consent management system implementing GDPR Article 7 requirements.
|
||||
Consent must be freely given, specific, informed, and unambiguous.
|
||||
"""
|
||||
from datetime import datetime, timezone
|
||||
from enum import Enum
|
||||
import json
|
||||
import hashlib
|
||||
|
||||
# Right to erasure
|
||||
def delete_user_data(user_id):
|
||||
anonymize_profile(user_id)
|
||||
delete_activity_log(user_id)
|
||||
log_deletion(user_id)
|
||||
|
||||
class ConsentPurpose(Enum):
|
||||
MARKETING_EMAIL = "marketing_email"
|
||||
MARKETING_SMS = "marketing_sms"
|
||||
ANALYTICS = "analytics"
|
||||
PERSONALIZATION = "personalization"
|
||||
THIRD_PARTY_SHARING = "third_party_sharing"
|
||||
PROFILING = "profiling"
|
||||
|
||||
|
||||
class ConsentManager:
|
||||
def __init__(self, db):
|
||||
self.db = db
|
||||
|
||||
def record_consent(self, user_id, purpose, granted, source,
|
||||
privacy_policy_version, ip_address=None):
|
||||
"""Record a consent decision with full audit trail."""
|
||||
consent_record = {
|
||||
"user_id": user_id,
|
||||
"purpose": purpose.value,
|
||||
"granted": granted,
|
||||
"timestamp": datetime.now(timezone.utc).isoformat(),
|
||||
"source": source, # e.g., "web_signup", "preference_center", "cookie_banner"
|
||||
"privacy_policy_version": privacy_policy_version,
|
||||
"ip_address": ip_address,
|
||||
"withdrawal_timestamp": None,
|
||||
}
|
||||
# Store with immutable audit trail
|
||||
consent_record["record_hash"] = hashlib.sha256(
|
||||
json.dumps(consent_record, sort_keys=True).encode()
|
||||
).hexdigest()
|
||||
self.db.consent_records.insert(consent_record)
|
||||
return consent_record
|
||||
|
||||
def withdraw_consent(self, user_id, purpose):
|
||||
"""Process consent withdrawal - must be as easy as giving consent."""
|
||||
record = self.record_consent(
|
||||
user_id=user_id,
|
||||
purpose=purpose,
|
||||
granted=False,
|
||||
source="withdrawal",
|
||||
privacy_policy_version="N/A",
|
||||
)
|
||||
# Trigger downstream actions
|
||||
self._notify_processors(user_id, purpose, "withdrawn")
|
||||
self._stop_processing(user_id, purpose)
|
||||
return record
|
||||
|
||||
def get_consent_status(self, user_id, purpose):
|
||||
"""Get current consent status for a specific purpose."""
|
||||
latest = self.db.consent_records.find_one(
|
||||
{"user_id": user_id, "purpose": purpose.value},
|
||||
sort=[("timestamp", -1)]
|
||||
)
|
||||
return latest["granted"] if latest else False
|
||||
|
||||
def get_all_consents(self, user_id):
|
||||
"""Get all consent records for a user (for DSAR response)."""
|
||||
return list(self.db.consent_records.find(
|
||||
{"user_id": user_id},
|
||||
sort=[("timestamp", -1)]
|
||||
))
|
||||
|
||||
def export_consent_proof(self, user_id, purpose):
|
||||
"""Export verifiable consent proof for accountability."""
|
||||
records = list(self.db.consent_records.find(
|
||||
{"user_id": user_id, "purpose": purpose.value},
|
||||
sort=[("timestamp", 1)]
|
||||
))
|
||||
return {
|
||||
"user_id": user_id,
|
||||
"purpose": purpose.value,
|
||||
"consent_history": records,
|
||||
"current_status": self.get_consent_status(user_id, purpose),
|
||||
"exported_at": datetime.now(timezone.utc).isoformat(),
|
||||
}
|
||||
|
||||
def _notify_processors(self, user_id, purpose, action):
|
||||
"""Notify downstream processors of consent change."""
|
||||
pass # Implement webhook/API calls to processors
|
||||
|
||||
def _stop_processing(self, user_id, purpose):
|
||||
"""Immediately stop processing for withdrawn consent."""
|
||||
pass # Implement processing halt logic
|
||||
```
|
||||
|
||||
## Data Subject Access Request (DSAR) Procedures
|
||||
|
||||
```yaml
|
||||
dsar_workflow:
|
||||
step_1_receive:
|
||||
actions:
|
||||
- Log the request with timestamp and channel received
|
||||
- Assign unique tracking ID
|
||||
- Acknowledge receipt within 3 business days
|
||||
identity_verification:
|
||||
- Verify identity before providing any data
|
||||
- Use existing authentication where possible
|
||||
- Request additional proof if necessary (but not excessive)
|
||||
sla: "Must respond within 30 days (extendable to 90 days for complex requests)"
|
||||
|
||||
step_2_assess:
|
||||
actions:
|
||||
- Determine request type (access, rectification, erasure, portability, etc.)
|
||||
- Identify all systems containing the individual's data
|
||||
- Check for lawful grounds to refuse (legal obligations, etc.)
|
||||
- Assess if extension is needed (complex or numerous requests)
|
||||
|
||||
step_3_collect:
|
||||
systems_to_search:
|
||||
- Primary application database
|
||||
- CRM system
|
||||
- Email marketing platform
|
||||
- Analytics systems
|
||||
- Customer support tickets
|
||||
- Backup systems (if practically retrievable)
|
||||
- Log files containing PII
|
||||
- Third-party processors (request from each)
|
||||
|
||||
step_4_respond:
|
||||
access_request:
|
||||
- Provide copy of all personal data in commonly used electronic format
|
||||
- Include processing purposes, categories, recipients, retention periods
|
||||
- Include source of data if not collected from the individual
|
||||
- Include information about automated decision-making
|
||||
rectification_request:
|
||||
- Update data in all systems
|
||||
- Notify all recipients of the correction
|
||||
erasure_request:
|
||||
- Delete data from all active systems
|
||||
- Remove from backups where technically feasible
|
||||
- Notify all processors and recipients
|
||||
- Document what was deleted and any retained data with legal basis
|
||||
portability_request:
|
||||
- Provide data in structured, machine-readable format (JSON/CSV)
|
||||
- Include only data provided by the data subject
|
||||
- Transfer directly to another controller if requested and feasible
|
||||
|
||||
step_5_close:
|
||||
actions:
|
||||
- Send response to data subject
|
||||
- Document the entire handling process
|
||||
- Archive DSAR record for accountability
|
||||
- Update data mapping if new data stores discovered
|
||||
```
|
||||
|
||||
```python
|
||||
"""DSAR automation - data collection across systems."""
|
||||
import json
|
||||
from datetime import datetime, timezone
|
||||
|
||||
|
||||
class DSARProcessor:
|
||||
def __init__(self, data_sources):
|
||||
self.data_sources = data_sources # Dict of system_name: DataSource
|
||||
|
||||
def process_access_request(self, user_identifier):
|
||||
"""Collect all personal data across registered systems."""
|
||||
collected_data = {
|
||||
"request_id": f"DSAR-{datetime.now(timezone.utc).strftime('%Y%m%d%H%M%S')}",
|
||||
"generated_at": datetime.now(timezone.utc).isoformat(),
|
||||
"data_subject": user_identifier,
|
||||
"systems": {},
|
||||
}
|
||||
|
||||
for system_name, source in self.data_sources.items():
|
||||
try:
|
||||
data = source.extract_user_data(user_identifier)
|
||||
collected_data["systems"][system_name] = {
|
||||
"status": "collected",
|
||||
"record_count": len(data) if isinstance(data, list) else 1,
|
||||
"data": data,
|
||||
}
|
||||
except Exception as e:
|
||||
collected_data["systems"][system_name] = {
|
||||
"status": "error",
|
||||
"error": str(e),
|
||||
}
|
||||
|
||||
return collected_data
|
||||
|
||||
def process_erasure_request(self, user_identifier):
|
||||
"""Delete personal data across all systems (right to erasure)."""
|
||||
results = {
|
||||
"request_id": f"ERASE-{datetime.now(timezone.utc).strftime('%Y%m%d%H%M%S')}",
|
||||
"data_subject": user_identifier,
|
||||
"systems": {},
|
||||
}
|
||||
|
||||
for system_name, source in self.data_sources.items():
|
||||
try:
|
||||
deleted = source.delete_user_data(user_identifier)
|
||||
retained = source.get_retained_data(user_identifier)
|
||||
results["systems"][system_name] = {
|
||||
"status": "deleted",
|
||||
"records_deleted": deleted,
|
||||
"retained_data": retained, # Data kept for legal obligations
|
||||
"retention_basis": source.retention_legal_basis,
|
||||
}
|
||||
except Exception as e:
|
||||
results["systems"][system_name] = {
|
||||
"status": "error",
|
||||
"error": str(e),
|
||||
}
|
||||
|
||||
return results
|
||||
|
||||
def export_portable_data(self, user_identifier, format="json"):
|
||||
"""Export data in machine-readable format for portability."""
|
||||
data = self.process_access_request(user_identifier)
|
||||
if format == "json":
|
||||
return json.dumps(data, indent=2, default=str)
|
||||
elif format == "csv":
|
||||
return self._convert_to_csv(data)
|
||||
raise ValueError(f"Unsupported format: {format}")
|
||||
```
|
||||
|
||||
## Data Processing Agreement (DPA) Requirements
|
||||
|
||||
```yaml
|
||||
dpa_requirements:
|
||||
mandatory_clauses:
|
||||
article_28:
|
||||
- Subject matter, duration, nature, and purpose of processing
|
||||
- Type of personal data and categories of data subjects
|
||||
- Obligations and rights of the controller
|
||||
- Processing only on documented instructions from controller
|
||||
- Confidentiality obligations on processor personnel
|
||||
- Appropriate technical and organizational security measures
|
||||
- Conditions for engaging sub-processors (prior authorization)
|
||||
- Assistance with data subject rights requests
|
||||
- Assistance with security obligations (Art. 32-36)
|
||||
- Deletion or return of data after service ends
|
||||
- Audit and inspection rights for the controller
|
||||
|
||||
sub_processor_management:
|
||||
- [ ] List of current sub-processors provided by processor
|
||||
- [ ] Notification mechanism for new sub-processors (30-day notice)
|
||||
- [ ] Right to object to new sub-processors
|
||||
- [ ] Sub-processors bound by same data protection obligations
|
||||
- [ ] Processor remains liable for sub-processor compliance
|
||||
|
||||
international_transfers:
|
||||
mechanisms:
|
||||
- Standard Contractual Clauses (SCCs) - most common
|
||||
- Binding Corporate Rules (BCRs) - intra-group transfers
|
||||
- Adequacy decision (countries deemed adequate by EC)
|
||||
- Derogations for specific situations (explicit consent, contract necessity)
|
||||
transfer_impact_assessment:
|
||||
- [ ] Assess laws of the destination country
|
||||
- [ ] Evaluate effectiveness of safeguards
|
||||
- [ ] Document supplementary measures if needed
|
||||
- [ ] Review periodically for legal changes
|
||||
|
||||
dpa_registry:
|
||||
track_per_processor:
|
||||
- Processor name and contact details
|
||||
- DPA execution date
|
||||
- Data types processed
|
||||
- Sub-processors and their locations
|
||||
- SCC version used for international transfers
|
||||
- TIA completion date
|
||||
- Next review date
|
||||
```
|
||||
|
||||
## Data Protection Impact Assessment (DPIA) Template
|
||||
|
||||
```yaml
|
||||
dpia_template:
|
||||
when_required:
|
||||
- Systematic and extensive profiling with significant effects
|
||||
- Large-scale processing of special category data
|
||||
- Systematic monitoring of publicly accessible areas
|
||||
- Any processing on national supervisory authority's list
|
||||
- New technologies with likely high risk to rights and freedoms
|
||||
|
||||
assessment:
|
||||
section_1_description:
|
||||
processing_activity: ""
|
||||
purpose: ""
|
||||
legal_basis: ""
|
||||
data_categories: []
|
||||
data_subjects: []
|
||||
recipients: []
|
||||
retention: ""
|
||||
data_flows: "Describe how data moves through systems"
|
||||
|
||||
section_2_necessity:
|
||||
is_processing_necessary: ""
|
||||
is_processing_proportionate: ""
|
||||
alternatives_considered: ""
|
||||
data_minimization_applied: ""
|
||||
|
||||
section_3_risks:
|
||||
risk_assessment:
|
||||
- risk: "Unauthorized access to personal data"
|
||||
likelihood: "medium"
|
||||
severity: "high"
|
||||
risk_level: "high"
|
||||
existing_controls: "Encryption, access controls, audit logs"
|
||||
residual_risk: "medium"
|
||||
|
||||
- risk: "Accidental data loss or destruction"
|
||||
likelihood: "low"
|
||||
severity: "high"
|
||||
risk_level: "medium"
|
||||
existing_controls: "Backups, replication, DR procedures"
|
||||
residual_risk: "low"
|
||||
|
||||
- risk: "Excessive data collection beyond purpose"
|
||||
likelihood: "medium"
|
||||
severity: "medium"
|
||||
risk_level: "medium"
|
||||
existing_controls: "Data minimization review, schema validation"
|
||||
residual_risk: "low"
|
||||
|
||||
section_4_measures:
|
||||
technical_measures:
|
||||
- Pseudonymization of personal data
|
||||
- Encryption at rest (AES-256) and in transit (TLS 1.3)
|
||||
- Access controls with least privilege
|
||||
- Automated data retention enforcement
|
||||
organizational_measures:
|
||||
- Staff training on data protection
|
||||
- Data protection policies and procedures
|
||||
- Incident response procedures
|
||||
- Regular access reviews
|
||||
monitoring:
|
||||
- Audit logging of all data access
|
||||
- Anomaly detection for unusual access patterns
|
||||
- Regular compliance testing
|
||||
|
||||
section_5_sign_off:
|
||||
dpo_consultation: "Required if high residual risk"
|
||||
dpo_opinion: ""
|
||||
supervisory_authority_consultation: "Required if risk cannot be mitigated"
|
||||
approval_date: ""
|
||||
next_review_date: ""
|
||||
```
|
||||
|
||||
## GDPR Compliance Checklist
|
||||
|
||||
```yaml
|
||||
gdpr_compliance_checklist:
|
||||
governance:
|
||||
- [ ] Data Protection Officer appointed (if required under Art. 37)
|
||||
- [ ] Records of Processing Activities (ROPA) maintained
|
||||
- [ ] Privacy policies published and up to date
|
||||
- [ ] Data protection training conducted for all staff
|
||||
- [ ] Data breach response plan documented and tested
|
||||
|
||||
lawful_processing:
|
||||
- [ ] Legal basis identified and documented for each processing activity
|
||||
- [ ] Consent mechanisms comply with Art. 7 (freely given, specific, informed)
|
||||
- [ ] Consent withdrawal is as easy as giving consent
|
||||
- [ ] Legitimate interest assessments completed where applicable
|
||||
- [ ] Special category data has Art. 9 legal basis documented
|
||||
|
||||
data_subject_rights:
|
||||
- [ ] DSAR intake process established (multiple channels)
|
||||
- [ ] Identity verification procedure defined
|
||||
- [ ] Response within 30 days (or extension communicated)
|
||||
- [ ] Right to access implemented and tested
|
||||
- [ ] Right to rectification implemented
|
||||
- [ ] Right to erasure implemented with legal retention exceptions
|
||||
- [ ] Right to portability implemented (structured, machine-readable export)
|
||||
- [ ] Right to object implemented (especially for direct marketing)
|
||||
|
||||
technical_measures:
|
||||
- [ ] Encryption at rest and in transit for all personal data
|
||||
- [ ] Pseudonymization applied where feasible
|
||||
- [ ] Access controls enforce least privilege
|
||||
- [ ] Audit logging of personal data access
|
||||
- [ ] Data retention automated with defined schedules
|
||||
- [ ] Secure deletion procedures verified
|
||||
|
||||
third_parties:
|
||||
- [ ] Data Processing Agreements signed with all processors
|
||||
- [ ] Sub-processor notification mechanism in place
|
||||
- [ ] International transfer safeguards implemented (SCCs, etc.)
|
||||
- [ ] Transfer Impact Assessments completed
|
||||
- [ ] Processor compliance verified periodically
|
||||
|
||||
breach_management:
|
||||
- [ ] Breach detection and assessment procedures documented
|
||||
- [ ] 72-hour supervisory authority notification process ready
|
||||
- [ ] Individual notification procedures for high-risk breaches
|
||||
- [ ] Breach register maintained
|
||||
- [ ] Post-breach review and improvement process
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Privacy impact assessments
|
||||
- Data processing agreements
|
||||
- Consent management
|
||||
- Breach notification (72 hours)
|
||||
- Data Protection Officer (if required)
|
||||
- Maintain a comprehensive Records of Processing Activities as the foundation of GDPR compliance
|
||||
- Implement privacy by design: build data protection into systems from the start, not retrofitted
|
||||
- Apply data minimization rigorously: do not collect personal data "just in case"
|
||||
- Automate DSAR processing to meet the 30-day response deadline consistently
|
||||
- Keep consent granular and purpose-specific; avoid bundled consent for multiple purposes
|
||||
- Conduct DPIAs before launching high-risk processing activities
|
||||
- Ensure data processing agreements are signed with every processor before sharing personal data
|
||||
- Implement automated retention enforcement to prevent storage beyond defined periods
|
||||
- Train all staff who handle personal data, not just the IT and legal teams
|
||||
- Regularly audit data flows to discover shadow processing or undocumented data stores
|
||||
|
||||
@@ -9,66 +9,420 @@ metadata:
|
||||
|
||||
# HIPAA Compliance
|
||||
|
||||
Implement HIPAA requirements for healthcare data protection.
|
||||
Implement HIPAA Security Rule, Privacy Rule, and Breach Notification Rule requirements for systems that create, receive, maintain, or transmit electronic Protected Health Information (ePHI).
|
||||
|
||||
## HIPAA Rules
|
||||
## When to Use
|
||||
|
||||
- Building or operating systems that handle electronic Protected Health Information
|
||||
- Configuring cloud infrastructure for HIPAA-eligible workloads
|
||||
- Establishing Business Associate Agreements with vendors
|
||||
- Implementing technical safeguards for PHI protection
|
||||
- Preparing for HIPAA compliance audits or OCR investigations
|
||||
|
||||
## HIPAA Rules and Safeguards
|
||||
|
||||
```yaml
|
||||
security_rule:
|
||||
administrative:
|
||||
- Risk analysis
|
||||
- Security management
|
||||
- Workforce training
|
||||
- Contingency planning
|
||||
|
||||
physical:
|
||||
- Facility access
|
||||
- Workstation security
|
||||
- Device controls
|
||||
|
||||
technical:
|
||||
- Access control
|
||||
- Audit controls
|
||||
- Integrity controls
|
||||
- Transmission security
|
||||
administrative_safeguards:
|
||||
164.308_a_1: "Security Management Process"
|
||||
actions:
|
||||
- Conduct risk analysis (required)
|
||||
- Implement risk management program (required)
|
||||
- Apply sanction policy for violations (required)
|
||||
- Review information system activity (required)
|
||||
|
||||
164.308_a_3: "Workforce Security"
|
||||
actions:
|
||||
- Authorization/supervision procedures (addressable)
|
||||
- Workforce clearance procedure (addressable)
|
||||
- Termination procedures (addressable)
|
||||
|
||||
164.308_a_4: "Information Access Management"
|
||||
actions:
|
||||
- Access authorization policies (addressable)
|
||||
- Access establishment and modification (addressable)
|
||||
- Isolate healthcare clearinghouse functions (required)
|
||||
|
||||
164.308_a_5: "Security Awareness and Training"
|
||||
actions:
|
||||
- Security reminders (addressable)
|
||||
- Protection from malicious software (addressable)
|
||||
- Log-in monitoring (addressable)
|
||||
- Password management (addressable)
|
||||
|
||||
164.308_a_6: "Security Incident Procedures"
|
||||
actions:
|
||||
- Response and reporting procedures (required)
|
||||
|
||||
164.308_a_7: "Contingency Plan"
|
||||
actions:
|
||||
- Data backup plan (required)
|
||||
- Disaster recovery plan (required)
|
||||
- Emergency mode operation plan (required)
|
||||
- Testing and revision procedures (addressable)
|
||||
- Applications and data criticality analysis (addressable)
|
||||
|
||||
164.308_a_8: "Evaluation"
|
||||
actions:
|
||||
- Periodic technical and nontechnical evaluation (required)
|
||||
|
||||
physical_safeguards:
|
||||
164.310_a: "Facility Access Controls"
|
||||
164.310_b: "Workstation Use"
|
||||
164.310_c: "Workstation Security"
|
||||
164.310_d: "Device and Media Controls"
|
||||
|
||||
technical_safeguards:
|
||||
164.312_a: "Access Control"
|
||||
actions:
|
||||
- Unique user identification (required)
|
||||
- Emergency access procedure (required)
|
||||
- Automatic logoff (addressable)
|
||||
- Encryption and decryption (addressable)
|
||||
|
||||
164.312_b: "Audit Controls"
|
||||
actions:
|
||||
- Implement hardware/software/procedural mechanisms to record and examine access (required)
|
||||
|
||||
164.312_c: "Integrity"
|
||||
actions:
|
||||
- Mechanism to authenticate ePHI (addressable)
|
||||
|
||||
164.312_d: "Person or Entity Authentication"
|
||||
actions:
|
||||
- Verify identity of person/entity seeking access (required)
|
||||
|
||||
164.312_e: "Transmission Security"
|
||||
actions:
|
||||
- Integrity controls (addressable)
|
||||
- Encryption (addressable)
|
||||
|
||||
privacy_rule:
|
||||
minimum_necessary: "Limit PHI use, disclosure, and requests to minimum necessary"
|
||||
individual_rights: "Access, amendment, accounting of disclosures, restrictions"
|
||||
notice_of_practices: "Provide notice of privacy practices to individuals"
|
||||
|
||||
breach_notification_rule:
|
||||
individual_notification: "Within 60 days of discovery"
|
||||
hhs_notification: "Annual for <500 records; within 60 days for 500+"
|
||||
media_notification: "Required when 500+ individuals in a state/jurisdiction"
|
||||
```
|
||||
|
||||
## Technical Safeguards
|
||||
## Technical Safeguards Implementation Checklist
|
||||
|
||||
```yaml
|
||||
requirements:
|
||||
encryption:
|
||||
at_rest: AES-256
|
||||
in_transit: TLS 1.2+
|
||||
|
||||
access_control:
|
||||
- Unique user IDs
|
||||
- Emergency access procedure
|
||||
- Automatic logoff
|
||||
- Encryption/decryption
|
||||
|
||||
audit:
|
||||
- Access logging
|
||||
- Activity monitoring
|
||||
- Log retention (6 years)
|
||||
encryption_requirements:
|
||||
at_rest:
|
||||
standard: AES-256
|
||||
aws_services:
|
||||
- [ ] RDS encryption enabled (KMS managed key)
|
||||
- [ ] S3 bucket default encryption (SSE-KMS)
|
||||
- [ ] EBS volume encryption enabled
|
||||
- [ ] DynamoDB table encryption (KMS)
|
||||
- [ ] ElastiCache encryption at rest enabled
|
||||
- [ ] Redshift cluster encryption enabled
|
||||
- [ ] EFS encryption enabled
|
||||
azure_services:
|
||||
- [ ] Azure SQL TDE enabled (customer-managed key)
|
||||
- [ ] Storage Account encryption (CMK)
|
||||
- [ ] Managed Disk encryption (SSE with CMK)
|
||||
- [ ] Cosmos DB encryption at rest
|
||||
gcp_services:
|
||||
- [ ] Cloud SQL encryption (CMEK)
|
||||
- [ ] Cloud Storage encryption (CMEK)
|
||||
- [ ] BigQuery encryption (CMEK)
|
||||
- [ ] Persistent Disk encryption (CMEK)
|
||||
|
||||
in_transit:
|
||||
standard: TLS 1.2 or higher
|
||||
checks:
|
||||
- [ ] TLS 1.2+ enforced on all load balancers
|
||||
- [ ] HTTP-to-HTTPS redirect enabled
|
||||
- [ ] Internal service-to-service mTLS configured
|
||||
- [ ] Database connections use SSL/TLS
|
||||
- [ ] API gateways enforce TLS minimum version
|
||||
- [ ] Email encryption for PHI (S/MIME or TLS)
|
||||
- [ ] VPN or private connectivity for admin access
|
||||
|
||||
key_management:
|
||||
- [ ] Customer-managed KMS keys for PHI data stores
|
||||
- [ ] Key rotation enabled (annual minimum)
|
||||
- [ ] Key access restricted to authorized roles only
|
||||
- [ ] Key usage audited via CloudTrail / audit logs
|
||||
- [ ] Key deletion protection enabled
|
||||
|
||||
access_control:
|
||||
unique_user_identification:
|
||||
- [ ] Individual user accounts (no shared credentials)
|
||||
- [ ] MFA enforced for all users accessing PHI systems
|
||||
- [ ] Service accounts with unique identities and audited usage
|
||||
- [ ] Federated identity with SSO (SAML/OIDC)
|
||||
|
||||
role_based_access:
|
||||
- [ ] Least privilege roles defined per job function
|
||||
- [ ] PHI access restricted to need-to-know
|
||||
- [ ] Separate roles for data access vs. administration
|
||||
- [ ] Privileged access requires just-in-time approval
|
||||
|
||||
session_management:
|
||||
- [ ] Automatic session timeout (15 minutes idle for workstations)
|
||||
- [ ] Re-authentication for sensitive operations
|
||||
- [ ] Concurrent session limits
|
||||
- [ ] Session tokens secured (HttpOnly, Secure, SameSite)
|
||||
|
||||
emergency_access:
|
||||
- [ ] Break-glass procedure documented and tested
|
||||
- [ ] Emergency access credentials stored securely
|
||||
- [ ] All emergency access usage audited and reviewed
|
||||
- [ ] Emergency access automatically expires
|
||||
|
||||
audit_controls:
|
||||
logging_requirements:
|
||||
- [ ] All PHI access logged (read, write, delete)
|
||||
- [ ] User authentication events logged
|
||||
- [ ] Administrative actions logged
|
||||
- [ ] Failed access attempts logged
|
||||
- [ ] Log integrity protection (hash chaining or WORM storage)
|
||||
- [ ] Logs retained for minimum 6 years
|
||||
- [ ] Regular log review process documented
|
||||
|
||||
monitoring:
|
||||
- [ ] Real-time alerting on unauthorized PHI access attempts
|
||||
- [ ] Anomaly detection for unusual data access patterns
|
||||
- [ ] Privileged action monitoring
|
||||
- [ ] Data export/download alerting
|
||||
```
|
||||
|
||||
## AWS HIPAA Setup
|
||||
## AWS HIPAA-Eligible Architecture
|
||||
|
||||
```bash
|
||||
# Enable CloudTrail for HIPAA auditing
|
||||
aws cloudtrail create-trail \
|
||||
--name hipaa-audit-trail \
|
||||
--s3-bucket-name hipaa-logs \
|
||||
--is-multi-region-trail \
|
||||
--enable-log-file-validation
|
||||
# Verify you are using only HIPAA-eligible AWS services
|
||||
# Reference: https://aws.amazon.com/compliance/hipaa-eligible-services-reference/
|
||||
|
||||
# Use HIPAA-eligible services only
|
||||
# Create a dedicated VPC for PHI workloads
|
||||
aws ec2 create-vpc --cidr-block 10.100.0.0/16 \
|
||||
--tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=phi-vpc},{Key=Compliance,Value=HIPAA}]'
|
||||
|
||||
# Enable VPC flow logs for network auditing
|
||||
aws ec2 create-flow-log \
|
||||
--resource-type VPC \
|
||||
--resource-ids vpc-XXXXXXXX \
|
||||
--traffic-type ALL \
|
||||
--log-destination-type cloud-watch-logs \
|
||||
--log-group-name /vpc/phi-flow-logs \
|
||||
--deliver-logs-permission-arn arn:aws:iam::123456789012:role/VPCFlowLogsRole
|
||||
|
||||
# Create encrypted RDS instance for PHI
|
||||
aws rds create-db-instance \
|
||||
--db-instance-identifier phi-database \
|
||||
--db-instance-class db.r6g.large \
|
||||
--engine postgres \
|
||||
--master-username admin \
|
||||
--master-user-password "USE_SECRETS_MANAGER" \
|
||||
--storage-encrypted \
|
||||
--kms-key-id arn:aws:kms:us-east-1:123456789012:alias/phi-rds-key \
|
||||
--vpc-security-group-ids sg-XXXXXXXX \
|
||||
--db-subnet-group-name phi-subnet-group \
|
||||
--backup-retention-period 35 \
|
||||
--multi-az \
|
||||
--deletion-protection \
|
||||
--enable-cloudwatch-logs-exports '["postgresql","upgrade"]' \
|
||||
--tags Key=Compliance,Value=HIPAA Key=DataClassification,Value=PHI
|
||||
|
||||
# Create S3 bucket with HIPAA controls
|
||||
aws s3api create-bucket --bucket phi-data-bucket --region us-east-1
|
||||
|
||||
aws s3api put-bucket-encryption --bucket phi-data-bucket \
|
||||
--server-side-encryption-configuration '{
|
||||
"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "alias/phi-s3-key"}, "BucketKeyEnabled": true}]
|
||||
}'
|
||||
|
||||
aws s3api put-public-access-block --bucket phi-data-bucket \
|
||||
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
|
||||
|
||||
aws s3api put-bucket-versioning --bucket phi-data-bucket \
|
||||
--versioning-configuration Status=Enabled
|
||||
|
||||
aws s3api put-bucket-logging --bucket phi-data-bucket \
|
||||
--bucket-logging-status '{"LoggingEnabled": {"TargetBucket": "phi-access-logs", "TargetPrefix": "phi-data-bucket/"}}'
|
||||
|
||||
# Enable CloudTrail data events for PHI buckets
|
||||
aws cloudtrail put-event-selectors --trail-name hipaa-audit-trail \
|
||||
--advanced-event-selectors '[{
|
||||
"Name": "PHI-S3-DataEvents",
|
||||
"FieldSelectors": [
|
||||
{"Field": "eventCategory", "Equals": ["Data"]},
|
||||
{"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
|
||||
{"Field": "resources.ARN", "StartsWith": ["arn:aws:s3:::phi-data-bucket/"]}
|
||||
]
|
||||
}]'
|
||||
```
|
||||
|
||||
## Business Associate Agreement Tracking
|
||||
|
||||
```yaml
|
||||
baa_tracking:
|
||||
required_when:
|
||||
- Vendor creates, receives, maintains, or transmits PHI on your behalf
|
||||
- Subcontractor of a business associate handles PHI
|
||||
- Cloud service provider stores or processes PHI
|
||||
|
||||
not_required_for:
|
||||
- Conduit exception (postal service, ISP carrying encrypted data)
|
||||
- Treatment providers sharing PHI for treatment purposes
|
||||
- Plan sponsor receiving summary health information
|
||||
|
||||
baa_registry:
|
||||
format:
|
||||
vendor_name: ""
|
||||
baa_execution_date: ""
|
||||
baa_expiration_date: ""
|
||||
phi_types_shared: []
|
||||
services_provided: ""
|
||||
subcontractors_identified: []
|
||||
breach_notification_sla: "hours"
|
||||
last_risk_assessment: ""
|
||||
next_review_date: ""
|
||||
status: "active | pending | expired"
|
||||
|
||||
cloud_provider_baas:
|
||||
aws:
|
||||
- Sign AWS BAA via AWS Artifact in the console
|
||||
- Applies to all HIPAA-eligible services in the account
|
||||
- Must restrict PHI to eligible services only
|
||||
azure:
|
||||
- Microsoft BAA is part of Online Services Terms
|
||||
- Automatically applies when using qualifying services
|
||||
gcp:
|
||||
- Sign Google Cloud BAA via Google Workspace Admin or Cloud console
|
||||
- Covers HIPAA-eligible GCP services
|
||||
|
||||
review_schedule:
|
||||
- [ ] Annual review of all active BAAs
|
||||
- [ ] Verify vendor compliance certifications are current
|
||||
- [ ] Confirm subcontractor BAAs are in place
|
||||
- [ ] Update BAA registry with any vendor changes
|
||||
- [ ] Assess vendor security posture annually
|
||||
```
|
||||
|
||||
## Risk Analysis Automation
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# hipaa-risk-scan.sh - Technical risk analysis checks for HIPAA
|
||||
|
||||
echo "=== HIPAA Technical Safeguard Checks ==="
|
||||
|
||||
echo "--- Encryption at Rest ---"
|
||||
# Check for unencrypted RDS instances
|
||||
UNENCRYPTED_RDS=$(aws rds describe-db-instances \
|
||||
--query 'DBInstances[?StorageEncrypted==`false`].DBInstanceIdentifier' --output text)
|
||||
[ -z "$UNENCRYPTED_RDS" ] && echo "PASS: All RDS instances encrypted" || \
|
||||
echo "FAIL: Unencrypted RDS: $UNENCRYPTED_RDS"
|
||||
|
||||
# Check for unencrypted S3 buckets
|
||||
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
|
||||
enc=$(aws s3api get-bucket-encryption --bucket "$bucket" 2>/dev/null)
|
||||
[ -z "$enc" ] && echo "FAIL: S3 bucket $bucket has no default encryption"
|
||||
done
|
||||
|
||||
# Check for unencrypted EBS volumes
|
||||
UNENCRYPTED_EBS=$(aws ec2 describe-volumes \
|
||||
--query 'Volumes[?Encrypted==`false`].VolumeId' --output text)
|
||||
[ -z "$UNENCRYPTED_EBS" ] && echo "PASS: All EBS volumes encrypted" || \
|
||||
echo "FAIL: Unencrypted EBS: $UNENCRYPTED_EBS"
|
||||
|
||||
echo "--- Access Control ---"
|
||||
# Check for users without MFA
|
||||
aws iam generate-credential-report > /dev/null 2>&1 && sleep 5
|
||||
aws iam get-credential-report --output text --query Content | base64 -d | \
|
||||
awk -F, '$4=="true" && $8=="false" {print "FAIL: User without MFA: "$1}'
|
||||
|
||||
# Check for unused access keys (90+ days)
|
||||
THRESHOLD=$(date -d '90 days ago' +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -v-90d +%Y-%m-%dT%H:%M:%S)
|
||||
aws iam get-credential-report --output text --query Content | base64 -d | \
|
||||
awk -F, -v t="$THRESHOLD" 'NR>1 && $11!="N/A" && $11<t {print "WARN: Stale access key for "$1}'
|
||||
|
||||
echo "--- Audit Controls ---"
|
||||
# Verify CloudTrail is logging
|
||||
CT_STATUS=$(aws cloudtrail get-trail-status --name hipaa-audit-trail --query 'IsLogging' --output text)
|
||||
[ "$CT_STATUS" = "True" ] && echo "PASS: CloudTrail active" || echo "FAIL: CloudTrail not logging"
|
||||
|
||||
# Verify VPC flow logs
|
||||
for vpc in $(aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --output text); do
|
||||
fl=$(aws ec2 describe-flow-logs --filter "Name=resource-id,Values=$vpc" --query 'FlowLogs[0].FlowLogId' --output text)
|
||||
[ "$fl" = "None" ] && echo "FAIL: No flow logs for VPC $vpc"
|
||||
done
|
||||
|
||||
echo "--- Transmission Security ---"
|
||||
# Check for ALBs without HTTPS listener
|
||||
for alb in $(aws elbv2 describe-load-balancers --query 'LoadBalancers[*].LoadBalancerArn' --output text); do
|
||||
HTTPS=$(aws elbv2 describe-listeners --load-balancer-arn "$alb" \
|
||||
--query 'Listeners[?Protocol==`HTTPS`].ListenerArn' --output text)
|
||||
[ -z "$HTTPS" ] && echo "FAIL: ALB without HTTPS: $alb"
|
||||
done
|
||||
|
||||
echo "=== Scan complete ==="
|
||||
```
|
||||
|
||||
## HIPAA Compliance Checklist
|
||||
|
||||
```yaml
|
||||
hipaa_compliance_checklist:
|
||||
administrative:
|
||||
- [ ] Risk analysis conducted and documented
|
||||
- [ ] Risk management plan implemented
|
||||
- [ ] Security officer designated
|
||||
- [ ] Privacy officer designated
|
||||
- [ ] Workforce security awareness training completed
|
||||
- [ ] Sanction policy documented and communicated
|
||||
- [ ] Contingency plan (backup, DR, emergency mode) documented
|
||||
- [ ] Business associate agreements signed for all applicable vendors
|
||||
- [ ] Periodic evaluation/audit scheduled
|
||||
|
||||
technical:
|
||||
- [ ] Unique user identification enforced
|
||||
- [ ] MFA enabled for all PHI system access
|
||||
- [ ] Automatic logoff configured (15-minute timeout)
|
||||
- [ ] Encryption at rest (AES-256) for all PHI stores
|
||||
- [ ] Encryption in transit (TLS 1.2+) for all PHI transmission
|
||||
- [ ] Audit logging enabled for all PHI access
|
||||
- [ ] Log retention configured for 6+ years
|
||||
- [ ] Integrity controls on PHI (checksums, signatures)
|
||||
- [ ] Emergency access (break-glass) procedure tested
|
||||
|
||||
physical:
|
||||
- [ ] Facility access controls documented
|
||||
- [ ] Workstation use policy in place
|
||||
- [ ] Device and media disposal procedures documented
|
||||
- [ ] Media re-use procedures documented
|
||||
|
||||
breach_response:
|
||||
- [ ] Breach notification procedure documented
|
||||
- [ ] Breach risk assessment methodology defined
|
||||
- [ ] Individual notification template prepared
|
||||
- [ ] HHS notification process understood
|
||||
- [ ] Breach log maintained
|
||||
- [ ] Annual breach assessment reviewed
|
||||
|
||||
operational:
|
||||
- [ ] PHI data inventory maintained
|
||||
- [ ] Minimum necessary access enforced
|
||||
- [ ] Access reviews conducted quarterly
|
||||
- [ ] Vendor risk assessments current
|
||||
- [ ] Incident response plan tested annually
|
||||
- [ ] Policies reviewed and updated annually
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Business Associate Agreements (BAAs)
|
||||
- Minimum necessary access
|
||||
- Breach notification procedures
|
||||
- Regular risk assessments
|
||||
- Conduct a thorough risk analysis annually and after significant system changes
|
||||
- Use only HIPAA-eligible cloud services and sign BAAs before deploying PHI workloads
|
||||
- Encrypt all PHI at rest and in transit with no exceptions
|
||||
- Implement the minimum necessary standard: grant access only to the PHI needed for each role
|
||||
- Maintain audit logs of all PHI access for a minimum of 6 years
|
||||
- Train all workforce members on HIPAA policies at onboarding and annually
|
||||
- Test contingency plans (backup restore, DR failover, emergency access) at least annually
|
||||
- Track all Business Associate Agreements in a central registry with review dates
|
||||
- Document every addressable specification decision (implement, alternative, or not applicable with rationale)
|
||||
- Prepare breach notification templates and procedures before an incident occurs
|
||||
|
||||
@@ -9,77 +9,429 @@ metadata:
|
||||
|
||||
# ISO 27001 Compliance
|
||||
|
||||
Implement ISO 27001 Information Security Management System.
|
||||
Implement an Information Security Management System (ISMS) aligned with ISO/IEC 27001:2022.
|
||||
|
||||
## ISMS Framework
|
||||
## When to Use
|
||||
|
||||
- Establishing an ISMS for the first time in an organization
|
||||
- Preparing for ISO 27001 certification audit
|
||||
- Conducting risk assessments and developing risk treatment plans
|
||||
- Creating the Statement of Applicability (SoA)
|
||||
- Transitioning from ISO 27001:2013 to the 2022 revision
|
||||
- Meeting customer or regulatory requirements for ISO 27001 certification
|
||||
|
||||
## ISMS Plan-Do-Check-Act Cycle
|
||||
|
||||
```yaml
|
||||
plan_do_check_act:
|
||||
pdca_cycle:
|
||||
plan:
|
||||
- Define scope
|
||||
- Risk assessment
|
||||
- Risk treatment plan
|
||||
- Statement of Applicability
|
||||
|
||||
- Define ISMS scope and boundaries
|
||||
- Establish information security policy
|
||||
- Conduct risk assessment
|
||||
- Develop risk treatment plan
|
||||
- Produce Statement of Applicability
|
||||
- Obtain management approval and commitment
|
||||
- Define security objectives and metrics
|
||||
|
||||
do:
|
||||
- Implement controls
|
||||
- Security awareness
|
||||
- Document procedures
|
||||
|
||||
- Implement selected Annex A controls
|
||||
- Deploy technical security controls
|
||||
- Conduct security awareness training
|
||||
- Document all procedures and processes
|
||||
- Implement incident management process
|
||||
- Establish supplier security management
|
||||
|
||||
check:
|
||||
- Internal audits
|
||||
- Management review
|
||||
- Performance measurement
|
||||
|
||||
- Conduct internal audits (at least annual)
|
||||
- Perform management review meetings
|
||||
- Monitor and measure control effectiveness
|
||||
- Review incident trends and near misses
|
||||
- Assess compliance with legal requirements
|
||||
- Evaluate security metrics against objectives
|
||||
|
||||
act:
|
||||
- Corrective actions
|
||||
- Continual improvement
|
||||
- Address nonconformities with corrective actions
|
||||
- Implement continual improvement initiatives
|
||||
- Update risk assessment based on changes
|
||||
- Refine controls based on audit findings
|
||||
- Communicate improvements to stakeholders
|
||||
```
|
||||
|
||||
## Annex A Controls
|
||||
## ISMS Scope Definition
|
||||
|
||||
```yaml
|
||||
control_domains:
|
||||
A.5: Information security policies
|
||||
A.6: Organization of information security
|
||||
A.7: Human resource security
|
||||
A.8: Asset management
|
||||
A.9: Access control
|
||||
A.10: Cryptography
|
||||
A.11: Physical security
|
||||
A.12: Operations security
|
||||
A.13: Communications security
|
||||
A.14: System acquisition/development
|
||||
A.15: Supplier relationships
|
||||
A.16: Incident management
|
||||
A.17: Business continuity
|
||||
A.18: Compliance
|
||||
isms_scope:
|
||||
template:
|
||||
organization: "Company Name, Ltd."
|
||||
scope_statement: |
|
||||
The ISMS covers the design, development, operation, and support of
|
||||
the Company's cloud-based SaaS platform, including all supporting
|
||||
infrastructure, personnel, and processes at the following locations.
|
||||
|
||||
included:
|
||||
locations:
|
||||
- "Primary office: 123 Main Street, City, Country"
|
||||
- "AWS us-east-1 and eu-west-1 regions"
|
||||
- "Remote workers accessing corporate systems"
|
||||
business_processes:
|
||||
- "Software development and deployment"
|
||||
- "Cloud infrastructure management"
|
||||
- "Customer data processing and storage"
|
||||
- "Customer support operations"
|
||||
- "Corporate IT and internal systems"
|
||||
information_assets:
|
||||
- "Customer data (PII, business data)"
|
||||
- "Source code and intellectual property"
|
||||
- "Employee personal data"
|
||||
- "Financial records"
|
||||
- "Security configurations and credentials"
|
||||
technology:
|
||||
- "AWS cloud infrastructure"
|
||||
- "SaaS application stack"
|
||||
- "Corporate IT systems (Google Workspace, Okta, Jira)"
|
||||
- "Development tools (GitHub, CI/CD pipelines)"
|
||||
|
||||
excluded:
|
||||
- "Physical data center operations (inherited from AWS)"
|
||||
- "Third-party SaaS platforms beyond integration points"
|
||||
exclusion_justification: "Physical data center controls are inherited from AWS, which maintains its own ISO 27001 certification."
|
||||
|
||||
interfaces:
|
||||
- "Customer API endpoints"
|
||||
- "Third-party integrations (payment processor, email provider)"
|
||||
- "AWS management plane"
|
||||
```
|
||||
|
||||
## Risk Assessment
|
||||
## Risk Assessment Process
|
||||
|
||||
```yaml
|
||||
risk_assessment:
|
||||
identify:
|
||||
- Asset inventory
|
||||
- Threat identification
|
||||
- Vulnerability assessment
|
||||
|
||||
analyze:
|
||||
- Likelihood rating
|
||||
- Impact rating
|
||||
- Risk calculation
|
||||
|
||||
evaluate:
|
||||
- Risk acceptance criteria
|
||||
- Prioritization
|
||||
- Treatment options
|
||||
methodology:
|
||||
approach: "Asset-based risk assessment"
|
||||
risk_formula: "Risk = Likelihood x Impact"
|
||||
scale: "1-5 for both likelihood and impact (total 1-25)"
|
||||
|
||||
likelihood_scale:
|
||||
1: "Rare - less than once per 5 years"
|
||||
2: "Unlikely - once per 2-5 years"
|
||||
3: "Possible - once per 1-2 years"
|
||||
4: "Likely - multiple times per year"
|
||||
5: "Almost Certain - monthly or more frequent"
|
||||
|
||||
impact_scale:
|
||||
1: "Negligible - minimal operational impact, no data loss"
|
||||
2: "Minor - limited impact, small data exposure, <$10K cost"
|
||||
3: "Moderate - significant impact, data breach <1K records, <$100K cost"
|
||||
4: "Major - severe impact, large data breach, <$1M cost, regulatory action"
|
||||
5: "Critical - catastrophic, massive breach, >$1M cost, business viability at risk"
|
||||
|
||||
risk_matrix:
|
||||
# Impact: 1 2 3 4 5
|
||||
likelihood_5: [5, 10, 15, 20, 25]
|
||||
likelihood_4: [4, 8, 12, 16, 20]
|
||||
likelihood_3: [3, 6, 9, 12, 15]
|
||||
likelihood_2: [2, 4, 6, 8, 10]
|
||||
likelihood_1: [1, 2, 3, 4, 5]
|
||||
|
||||
risk_appetite:
|
||||
accept: "Score 1-4 (low risk, accept with monitoring)"
|
||||
mitigate: "Score 5-14 (medium risk, implement controls to reduce)"
|
||||
escalate: "Score 15-25 (high/critical risk, immediate action required)"
|
||||
|
||||
treatment_options:
|
||||
mitigate: "Implement controls to reduce likelihood or impact"
|
||||
transfer: "Insurance or contractual transfer to third party"
|
||||
avoid: "Eliminate the risk by removing the activity or asset"
|
||||
accept: "Accept with documented management approval"
|
||||
|
||||
example_risk_register:
|
||||
- id: "RISK-001"
|
||||
asset: "Customer database"
|
||||
threat: "SQL injection attack"
|
||||
vulnerability: "Insufficient input validation"
|
||||
likelihood: 3
|
||||
impact: 4
|
||||
inherent_risk: 12
|
||||
treatment: "mitigate"
|
||||
controls: ["A.8.28 Secure coding", "A.8.8 Vulnerability management"]
|
||||
residual_likelihood: 1
|
||||
residual_impact: 4
|
||||
residual_risk: 4
|
||||
risk_owner: "CTO"
|
||||
|
||||
- id: "RISK-002"
|
||||
asset: "Source code repository"
|
||||
threat: "Insider theft of intellectual property"
|
||||
vulnerability: "Excessive access permissions"
|
||||
likelihood: 2
|
||||
impact: 5
|
||||
inherent_risk: 10
|
||||
treatment: "mitigate"
|
||||
controls: ["A.5.15 Access control", "A.8.3 Information access restriction"]
|
||||
residual_likelihood: 1
|
||||
residual_impact: 5
|
||||
residual_risk: 5
|
||||
risk_owner: "VP Engineering"
|
||||
|
||||
- id: "RISK-003"
|
||||
asset: "Cloud infrastructure"
|
||||
threat: "Cloud provider outage"
|
||||
vulnerability: "Single-region deployment"
|
||||
likelihood: 3
|
||||
impact: 3
|
||||
inherent_risk: 9
|
||||
treatment: "mitigate"
|
||||
controls: ["A.5.30 ICT readiness for business continuity", "A.8.14 Redundancy"]
|
||||
residual_likelihood: 3
|
||||
residual_impact: 2
|
||||
residual_risk: 6
|
||||
risk_owner: "Head of Infrastructure"
|
||||
```
|
||||
|
||||
## Statement of Applicability (SoA)
|
||||
|
||||
```yaml
|
||||
# ISO 27001:2022 Annex A Controls - Statement of Applicability
|
||||
soa_template:
|
||||
organizational_controls_5:
|
||||
"A.5.1":
|
||||
control: "Policies for information security"
|
||||
applicable: true
|
||||
justification: "Required to establish security governance"
|
||||
implementation: "Information security policy approved by CEO, reviewed annually"
|
||||
|
||||
"A.5.2":
|
||||
control: "Information security roles and responsibilities"
|
||||
applicable: true
|
||||
justification: "Required for accountability"
|
||||
implementation: "RACI matrix for security responsibilities, CISO appointed"
|
||||
|
||||
"A.5.7":
|
||||
control: "Threat intelligence"
|
||||
applicable: true
|
||||
justification: "Required for proactive threat management"
|
||||
implementation: "Subscribe to threat feeds, CVE monitoring, vendor advisories"
|
||||
|
||||
"A.5.15":
|
||||
control: "Access control"
|
||||
applicable: true
|
||||
justification: "Required for data protection"
|
||||
implementation: "RBAC via Okta, least-privilege IAM policies, quarterly access reviews"
|
||||
|
||||
"A.5.23":
|
||||
control: "Information security for use of cloud services"
|
||||
applicable: true
|
||||
justification: "Primary infrastructure is cloud-based"
|
||||
implementation: "AWS security baseline, CSP shared responsibility documented"
|
||||
|
||||
"A.5.29":
|
||||
control: "Information security during disruption"
|
||||
applicable: true
|
||||
justification: "Business continuity requirement"
|
||||
implementation: "BCP/DR plans tested annually, multi-AZ deployment"
|
||||
|
||||
"A.5.30":
|
||||
control: "ICT readiness for business continuity"
|
||||
applicable: true
|
||||
justification: "Ensure technology supports continuity"
|
||||
implementation: "DR runbooks, RTO/RPO defined, failover tested quarterly"
|
||||
|
||||
people_controls_6:
|
||||
"A.6.1":
|
||||
control: "Screening"
|
||||
applicable: true
|
||||
implementation: "Background checks for all employees before hiring"
|
||||
|
||||
"A.6.3":
|
||||
control: "Information security awareness, education and training"
|
||||
applicable: true
|
||||
implementation: "Annual security training, phishing simulations quarterly"
|
||||
|
||||
"A.6.5":
|
||||
control: "Responsibilities after termination or change of employment"
|
||||
applicable: true
|
||||
implementation: "Offboarding checklist, access revoked within 24 hours"
|
||||
|
||||
physical_controls_7:
|
||||
"A.7.1":
|
||||
control: "Physical security perimeters"
|
||||
applicable: false
|
||||
exclusion_justification: "No company-operated data centers, inherited from AWS"
|
||||
|
||||
technology_controls_8:
|
||||
"A.8.1":
|
||||
control: "User endpoint devices"
|
||||
applicable: true
|
||||
implementation: "MDM enrollment, disk encryption, screen lock policy"
|
||||
|
||||
"A.8.5":
|
||||
control: "Secure authentication"
|
||||
applicable: true
|
||||
implementation: "MFA required for all systems, SSO via Okta"
|
||||
|
||||
"A.8.8":
|
||||
control: "Management of technical vulnerabilities"
|
||||
applicable: true
|
||||
implementation: "Weekly vulnerability scans, 30-day patch SLA for critical"
|
||||
|
||||
"A.8.9":
|
||||
control: "Configuration management"
|
||||
applicable: true
|
||||
implementation: "Infrastructure as code, AWS Config rules, baseline hardening"
|
||||
|
||||
"A.8.15":
|
||||
control: "Logging"
|
||||
applicable: true
|
||||
implementation: "Centralized logging via CloudWatch + SIEM, 12-month retention"
|
||||
|
||||
"A.8.16":
|
||||
control: "Monitoring activities"
|
||||
applicable: true
|
||||
implementation: "SIEM alerting, 24/7 on-call rotation, anomaly detection"
|
||||
|
||||
"A.8.24":
|
||||
control: "Use of cryptography"
|
||||
applicable: true
|
||||
implementation: "TLS 1.2+, AES-256 at rest, KMS key management"
|
||||
|
||||
"A.8.25":
|
||||
control: "Secure development lifecycle"
|
||||
applicable: true
|
||||
implementation: "SAST/DAST in CI, code review required, dependency scanning"
|
||||
|
||||
"A.8.28":
|
||||
control: "Secure coding"
|
||||
applicable: true
|
||||
implementation: "OWASP guidelines, security code review, automated linting"
|
||||
```
|
||||
|
||||
## Internal Audit Program
|
||||
|
||||
```yaml
|
||||
internal_audit:
|
||||
schedule:
|
||||
frequency: "Annual full cycle, quarterly focused audits"
|
||||
cycle: "All ISMS clauses and applicable Annex A controls audited over 12 months"
|
||||
|
||||
audit_plan_template:
|
||||
audit_id: "IA-2025-Q1"
|
||||
scope: "Clauses 4-10, Annex A controls A.5.1-A.5.15"
|
||||
auditor: "Internal auditor (independent of audited area)"
|
||||
audit_dates: "2025-03-10 to 2025-03-14"
|
||||
areas:
|
||||
- area: "Access Control (A.5.15)"
|
||||
auditee: "IT Security Team"
|
||||
evidence_requested:
|
||||
- "Access review records from last quarter"
|
||||
- "Joiner/mover/leaver process records"
|
||||
- "Privileged access management logs"
|
||||
- area: "Risk Management (Clause 6.1)"
|
||||
auditee: "Risk Management Team"
|
||||
evidence_requested:
|
||||
- "Current risk register"
|
||||
- "Risk assessment methodology document"
|
||||
- "Management risk review meeting minutes"
|
||||
|
||||
finding_categories:
|
||||
major_nonconformity: "Requirement not met, significant risk to ISMS effectiveness"
|
||||
minor_nonconformity: "Requirement partially met, limited risk"
|
||||
observation: "Area for improvement, no requirement breach"
|
||||
positive_finding: "Notably effective implementation"
|
||||
|
||||
corrective_action:
|
||||
major: "Root cause analysis within 10 days, corrective action within 30 days"
|
||||
minor: "Corrective action within 60 days"
|
||||
observation: "Address in next ISMS review cycle"
|
||||
verification: "Auditor verifies corrective action effectiveness"
|
||||
```
|
||||
|
||||
## Management Review Meeting
|
||||
|
||||
```yaml
|
||||
management_review:
|
||||
frequency: "At least annually, recommended quarterly"
|
||||
attendees:
|
||||
required:
|
||||
- "CEO or Managing Director"
|
||||
- "CISO or Information Security Manager"
|
||||
- "Department heads"
|
||||
optional:
|
||||
- "Internal auditor"
|
||||
- "Risk manager"
|
||||
- "External consultant"
|
||||
|
||||
mandatory_inputs:
|
||||
- "Status of actions from previous management reviews"
|
||||
- "Changes in external and internal issues relevant to the ISMS"
|
||||
- "Information security performance (metrics and KPIs)"
|
||||
- "Audit results (internal and external)"
|
||||
- "Incident trends and nonconformities"
|
||||
- "Risk assessment results and risk treatment plan status"
|
||||
- "Interested party feedback"
|
||||
- "Opportunities for continual improvement"
|
||||
|
||||
mandatory_outputs:
|
||||
- "Decisions on continual improvement opportunities"
|
||||
- "Decisions on changes needed to the ISMS"
|
||||
- "Resource allocation decisions"
|
||||
- "Updated risk acceptance decisions"
|
||||
|
||||
kpis_to_report:
|
||||
- "Number and severity of security incidents"
|
||||
- "Vulnerability remediation SLA compliance"
|
||||
- "Security awareness training completion rate"
|
||||
- "Access review completion rate"
|
||||
- "Audit finding closure rate"
|
||||
- "Risk treatment plan progress"
|
||||
- "Patch compliance percentage"
|
||||
```
|
||||
|
||||
## ISO 27001 Certification Checklist
|
||||
|
||||
```yaml
|
||||
certification_checklist:
|
||||
stage_1_audit_preparation:
|
||||
- [ ] ISMS scope documented and approved
|
||||
- [ ] Information security policy published
|
||||
- [ ] Risk assessment methodology defined
|
||||
- [ ] Risk assessment completed with risk register
|
||||
- [ ] Risk treatment plan developed
|
||||
- [ ] Statement of Applicability completed
|
||||
- [ ] ISMS objectives defined with measurable targets
|
||||
- [ ] Internal audit program established
|
||||
- [ ] At least one full internal audit completed
|
||||
- [ ] Management review conducted with minutes documented
|
||||
- [ ] Document control process in place
|
||||
|
||||
stage_2_audit_preparation:
|
||||
- [ ] All Annex A controls implemented per SoA
|
||||
- [ ] Evidence of control operation for 3+ months
|
||||
- [ ] Corrective actions from internal audit tracked and closed
|
||||
- [ ] Security awareness training delivered and recorded
|
||||
- [ ] Incident management process operational with records
|
||||
- [ ] Supplier security assessments performed
|
||||
- [ ] Business continuity plan tested
|
||||
- [ ] All mandatory documented information available
|
||||
- [ ] Employees aware of security policy and their responsibilities
|
||||
|
||||
surveillance_audit_readiness:
|
||||
- [ ] All corrective actions from certification audit closed
|
||||
- [ ] Continuous internal audit schedule maintained
|
||||
- [ ] Management reviews conducted per schedule
|
||||
- [ ] Risk register updated with new threats and changes
|
||||
- [ ] Metrics demonstrate ISMS effectiveness
|
||||
- [ ] Changes to ISMS scope documented
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Management commitment
|
||||
- Risk-based approach
|
||||
- Document everything
|
||||
- Regular internal audits
|
||||
- Continuous improvement
|
||||
- Secure visible management commitment with a signed information security policy
|
||||
- Define ISMS scope carefully; too broad makes certification expensive, too narrow reduces value
|
||||
- Use an asset-based risk assessment approach to ensure comprehensive coverage
|
||||
- Maintain the Statement of Applicability as a living document aligned with the risk register
|
||||
- Conduct internal audits with auditors independent of the area being audited
|
||||
- Hold management review meetings quarterly rather than only annually
|
||||
- Integrate ISO 27001 controls into daily operations rather than treating them as a separate compliance exercise
|
||||
- Use metrics and KPIs to demonstrate ISMS effectiveness to auditors and management
|
||||
- Plan for the 3-year certification cycle: certification audit, then two surveillance audits
|
||||
- Start collecting evidence of control operation at least 3 months before the Stage 2 audit
|
||||
|
||||
@@ -9,69 +9,415 @@ metadata:
|
||||
|
||||
# PCI DSS Compliance
|
||||
|
||||
Implement PCI DSS requirements for payment card security.
|
||||
Implement PCI DSS v4.0 requirements for protecting cardholder data across the Cardholder Data Environment (CDE), including network segmentation, encryption, access controls, and ongoing testing.
|
||||
|
||||
## Requirements
|
||||
## When to Use
|
||||
|
||||
- Processing, storing, or transmitting payment card data
|
||||
- Scoping the Cardholder Data Environment for PCI assessment
|
||||
- Selecting the appropriate Self-Assessment Questionnaire (SAQ)
|
||||
- Implementing network segmentation to reduce CDE scope
|
||||
- Preparing for QSA assessment or ASV scanning
|
||||
|
||||
## SAQ Types and Applicability
|
||||
|
||||
```yaml
|
||||
saq_types:
|
||||
SAQ_A:
|
||||
description: "Card-not-present merchants using fully outsourced payment"
|
||||
applies_when:
|
||||
- All payment processing fully outsourced to PCI-compliant third party
|
||||
- No electronic storage, processing, or transmission of cardholder data
|
||||
- Only payment page redirects or iframes from compliant provider
|
||||
requirements: ~22 questions
|
||||
|
||||
SAQ_A_EP:
|
||||
description: "E-commerce merchants with website that affects payment security"
|
||||
applies_when:
|
||||
- E-commerce channel only
|
||||
- Website controls redirect to or loads payment page from third party
|
||||
- No direct processing but website could affect transaction security
|
||||
requirements: ~191 questions
|
||||
|
||||
SAQ_B:
|
||||
description: "Merchants with only imprint machines or standalone terminals"
|
||||
applies_when:
|
||||
- Only standalone POS terminals (dial-out or IP connected)
|
||||
- No electronic cardholder data storage
|
||||
- No e-commerce channel
|
||||
requirements: ~41 questions
|
||||
|
||||
SAQ_C:
|
||||
description: "Merchants with payment application systems connected to internet"
|
||||
applies_when:
|
||||
- Payment application connected to internet
|
||||
- No electronic cardholder data storage
|
||||
- No e-commerce channel
|
||||
requirements: ~160 questions
|
||||
|
||||
SAQ_D:
|
||||
description: "All other merchants and all service providers"
|
||||
applies_when:
|
||||
- Stores cardholder data electronically
|
||||
- Does not fit any other SAQ type
|
||||
- Service providers eligible for SAQ D
|
||||
requirements: "Full set of PCI DSS requirements"
|
||||
|
||||
scope_reduction_strategies:
|
||||
- Use tokenization to replace PAN with non-sensitive tokens
|
||||
- Use P2PE (Point-to-Point Encryption) validated solutions
|
||||
- Outsource payment processing to reduce your CDE footprint
|
||||
- Implement network segmentation to isolate CDE
|
||||
```
|
||||
|
||||
## PCI DSS v4.0 Requirements Overview
|
||||
|
||||
```yaml
|
||||
requirements:
|
||||
1_firewall:
|
||||
- Network segmentation
|
||||
- Firewall configuration
|
||||
- CDE isolation
|
||||
|
||||
3_protect_data:
|
||||
- Mask PAN display
|
||||
- Encrypt stored data
|
||||
- Key management
|
||||
|
||||
6_secure_systems:
|
||||
- Patch management
|
||||
- Secure development
|
||||
- Change control
|
||||
|
||||
8_access_control:
|
||||
- Unique IDs
|
||||
- MFA for remote access
|
||||
- Password policies
|
||||
|
||||
10_logging:
|
||||
- Audit trail
|
||||
- Time synchronization
|
||||
- Log retention (1 year)
|
||||
|
||||
11_testing:
|
||||
- Vulnerability scans
|
||||
- Penetration testing
|
||||
- IDS/IPS monitoring
|
||||
req_1_network_security:
|
||||
"1.1": "Network security controls defined and maintained"
|
||||
"1.2": "Network security controls configured and maintained"
|
||||
"1.3": "Network access to and from CDE is restricted"
|
||||
"1.4": "Network connections between trusted and untrusted networks controlled"
|
||||
"1.5": "Risks to CDE from devices connecting to untrusted networks mitigated"
|
||||
|
||||
req_2_secure_configuration:
|
||||
"2.1": "Secure configuration standards defined and applied"
|
||||
"2.2": "System components configured and managed securely"
|
||||
|
||||
req_3_protect_stored_data:
|
||||
"3.1": "Processes for protecting stored account data defined"
|
||||
"3.2": "Storage of account data is minimized"
|
||||
"3.3": "Sensitive authentication data not stored after authorization"
|
||||
"3.4": "PAN masked when displayed (first 6, last 4 maximum)"
|
||||
"3.5": "PAN secured wherever stored"
|
||||
"3.6": "Cryptographic keys managed securely"
|
||||
"3.7": "Key management procedures documented"
|
||||
|
||||
req_4_transmission_encryption:
|
||||
"4.1": "Strong cryptography protects cardholder data during transmission"
|
||||
"4.2": "PAN protected when sent via end-user messaging"
|
||||
|
||||
req_5_malware_protection:
|
||||
"5.1": "Processes to protect against malware defined"
|
||||
"5.2": "Malware prevented or detected and addressed"
|
||||
"5.3": "Anti-malware mechanisms active and maintained"
|
||||
"5.4": "Anti-phishing mechanisms protect against phishing"
|
||||
|
||||
req_6_secure_development:
|
||||
"6.1": "Secure development processes defined"
|
||||
"6.2": "Bespoke and custom software developed securely"
|
||||
"6.3": "Security vulnerabilities identified and addressed"
|
||||
"6.4": "Public-facing web applications protected against attacks"
|
||||
"6.5": "Changes to all system components managed securely"
|
||||
|
||||
req_7_access_restriction:
|
||||
"7.1": "Access to system components and data restricted by business need"
|
||||
"7.2": "Access appropriately defined and assigned"
|
||||
"7.3": "Access to system components and data managed via access control"
|
||||
|
||||
req_8_user_identification:
|
||||
"8.1": "Processes for user identification defined"
|
||||
"8.2": "User identification and accounts managed"
|
||||
"8.3": "Strong authentication established"
|
||||
"8.4": "MFA implemented for all access into CDE"
|
||||
"8.5": "MFA systems configured to prevent misuse"
|
||||
"8.6": "System and application accounts managed"
|
||||
|
||||
req_9_physical_access:
|
||||
"9.1": "Physical access controls defined"
|
||||
"9.2": "Physical access to CDE managed"
|
||||
"9.3": "Physical access for personnel and visitors authorized"
|
||||
"9.4": "Media with cardholder data managed securely"
|
||||
"9.5": "POI devices protected from tampering"
|
||||
|
||||
req_10_logging:
|
||||
"10.1": "Audit logging processes defined"
|
||||
"10.2": "Audit logs record required events"
|
||||
"10.3": "Audit logs protected from destruction and modification"
|
||||
"10.4": "Audit logs reviewed for anomalies"
|
||||
"10.5": "Audit log history retained"
|
||||
"10.6": "Time synchronization mechanisms configured"
|
||||
"10.7": "Audit logs retained for at least 12 months (3 months immediately available)"
|
||||
|
||||
req_11_testing:
|
||||
"11.1": "Security testing processes defined"
|
||||
"11.2": "Wireless access points managed"
|
||||
"11.3": "Vulnerabilities identified and addressed"
|
||||
"11.4": "External and internal penetration testing performed"
|
||||
"11.5": "Network intrusions and changes detected and responded to"
|
||||
"11.6": "Unauthorized changes to payment pages detected"
|
||||
|
||||
req_12_policies:
|
||||
"12.1": "Information security policy established"
|
||||
"12.2": "Acceptable use policies defined"
|
||||
"12.3": "Risks to CDE formally identified and managed"
|
||||
"12.4": "PCI DSS compliance managed"
|
||||
"12.5": "PCI DSS scope documented and validated"
|
||||
"12.6": "Security awareness program"
|
||||
"12.8": "Third-party service providers managed"
|
||||
"12.9": "TPSPs acknowledge responsibility for cardholder data"
|
||||
"12.10": "Security incidents responded to immediately"
|
||||
```
|
||||
|
||||
## Network Segmentation
|
||||
## Network Segmentation Architecture
|
||||
|
||||
```
|
||||
Internet --> DMZ --> Firewall --> CDE
|
||||
|
|
||||
Non-CDE <-- Firewall --
|
||||
┌──────────────────────────────────────┐
|
||||
│ INTERNET │
|
||||
└──────────────┬───────────────────────┘
|
||||
│
|
||||
┌──────────────▼───────────────────────┐
|
||||
│ DMZ (Public Subnet) │
|
||||
│ WAF → Load Balancer → Web Servers │
|
||||
└──────────────┬───────────────────────┘
|
||||
│ Firewall (Req 1.3)
|
||||
┌──────────────▼───────────────────────┐
|
||||
│ CDE (Cardholder Data Environment) │
|
||||
│ ┌─────────┐ ┌──────────┐ │
|
||||
│ │ Payment │ │ Card DB │ │
|
||||
│ │ App │ │(encrypted)│ │
|
||||
│ └─────────┘ └──────────┘ │
|
||||
│ ┌─────────┐ ┌──────────┐ │
|
||||
│ │Token Svc│ │ HSM/KMS │ │
|
||||
│ └─────────┘ └──────────┘ │
|
||||
└──────────────┬───────────────────────┘
|
||||
│ Firewall (Req 1.3)
|
||||
┌──────────────▼───────────────────────┐
|
||||
│ Non-CDE (Corporate Network) │
|
||||
│ App servers, internal tools │
|
||||
│ (no cardholder data) │
|
||||
└──────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Data Protection
|
||||
```bash
|
||||
# AWS Security Group for CDE isolation
|
||||
aws ec2 create-security-group \
|
||||
--group-name cde-app-sg \
|
||||
--description "CDE Application Security Group" \
|
||||
--vpc-id vpc-CDE
|
||||
|
||||
# Allow only HTTPS from WAF/ALB
|
||||
aws ec2 authorize-security-group-ingress \
|
||||
--group-id sg-CDE-APP \
|
||||
--protocol tcp --port 443 \
|
||||
--source-group sg-ALB
|
||||
|
||||
# CDE database - only accessible from CDE app servers
|
||||
aws ec2 create-security-group \
|
||||
--group-name cde-db-sg \
|
||||
--description "CDE Database Security Group" \
|
||||
--vpc-id vpc-CDE
|
||||
|
||||
aws ec2 authorize-security-group-ingress \
|
||||
--group-id sg-CDE-DB \
|
||||
--protocol tcp --port 5432 \
|
||||
--source-group sg-CDE-APP
|
||||
|
||||
# Deny all other inbound by default (security groups are deny-all by default in AWS)
|
||||
# Document all rules for Req 1.2 - firewall/security group documentation
|
||||
```
|
||||
|
||||
## Encryption and Tokenization
|
||||
|
||||
```yaml
|
||||
encryption:
|
||||
at_rest: AES-256
|
||||
in_transit: TLS 1.2+
|
||||
key_storage: HSM or dedicated key vault
|
||||
|
||||
tokenization:
|
||||
- Replace PAN with token
|
||||
- Store mapping securely
|
||||
- Reduce CDE scope
|
||||
encryption_requirements:
|
||||
stored_data_req_3:
|
||||
pan_encryption:
|
||||
algorithm: AES-256
|
||||
mode: GCM (preferred) or CBC with HMAC
|
||||
key_storage: HSM or dedicated key management service
|
||||
never_store:
|
||||
- Full track data (magnetic stripe)
|
||||
- CVV/CVC/CAV2
|
||||
- PIN / PIN block
|
||||
|
||||
pan_display_masking:
|
||||
rule: "Show maximum first 6 and last 4 digits"
|
||||
examples:
|
||||
masked: "4111 11** **** 1111"
|
||||
acceptable_for_business: "First 6 and last 4"
|
||||
implementation: "Apply masking at application layer before rendering"
|
||||
|
||||
key_management_req_3_6:
|
||||
- Generate keys using approved random number generator
|
||||
- Protect keys with key-encrypting keys (KEKs)
|
||||
- Store key components separately (split knowledge, dual control)
|
||||
- Rotate keys at least annually (or per crypto period)
|
||||
- Retire and replace keys when compromised
|
||||
- Document key custodian responsibilities
|
||||
|
||||
transmission_req_4:
|
||||
protocols:
|
||||
required: "TLS 1.2 or higher"
|
||||
prohibited: "SSL, TLS 1.0, TLS 1.1"
|
||||
cipher_suites:
|
||||
preferred:
|
||||
- TLS_AES_256_GCM_SHA384
|
||||
- TLS_CHACHA20_POLY1305_SHA256
|
||||
minimum: "128-bit key strength"
|
||||
certificate_management:
|
||||
- Use certificates from trusted CAs
|
||||
- Verify hostname and certificate validity
|
||||
- Monitor certificate expiration
|
||||
|
||||
tokenization_strategy:
|
||||
description: "Replace PAN with non-reversible token to reduce CDE scope"
|
||||
implementation:
|
||||
- Use format-preserving tokens (same length/format as PAN)
|
||||
- Token vault in isolated CDE segment
|
||||
- Token-to-PAN mapping encrypted and access-controlled
|
||||
- De-tokenization requires authenticated API call
|
||||
- Log all de-tokenization requests
|
||||
scope_benefit: "Systems using only tokens are out of PCI scope"
|
||||
```
|
||||
|
||||
## Vulnerability Management and Testing
|
||||
|
||||
```bash
|
||||
# Req 11.3 - Internal vulnerability scanning (quarterly minimum)
|
||||
# Using OpenVAS or Nessus
|
||||
openvas-cli --scan-target 10.10.0.0/24 --scan-name "CDE-Quarterly-Scan" \
|
||||
--profile "PCI DSS" --output pci-scan-$(date +%Y%m%d).xml
|
||||
|
||||
# Req 11.3 - External ASV scanning (quarterly, must pass)
|
||||
# Schedule with Approved Scanning Vendor (Qualys, Tenable, etc.)
|
||||
# ASV scan must show no vulnerabilities with CVSS >= 4.0
|
||||
|
||||
# Req 6.3 - Patch management
|
||||
# Check for critical patches on CDE systems
|
||||
yum check-update --security # RHEL/CentOS
|
||||
apt list --upgradable 2>/dev/null | grep -i security # Debian/Ubuntu
|
||||
|
||||
# Req 11.4 - Penetration testing (annual for external, internal, and segmentation)
|
||||
# Must be performed by qualified internal resource or third party
|
||||
# Test both network layer and application layer
|
||||
# Segmentation testing: verify CDE is isolated from non-CDE networks
|
||||
|
||||
# Req 11.5 - File integrity monitoring
|
||||
# Using AIDE (Advanced Intrusion Detection Environment)
|
||||
aide --init # Initialize baseline
|
||||
aide --check # Compare against baseline
|
||||
|
||||
# OSSEC FIM configuration for CDE systems
|
||||
# /var/ossec/etc/ossec.conf
|
||||
# <syscheck>
|
||||
# <frequency>3600</frequency>
|
||||
# <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
|
||||
# <directories check_all="yes">/opt/payment-app</directories>
|
||||
# </syscheck>
|
||||
```
|
||||
|
||||
## Logging and Monitoring (Req 10)
|
||||
|
||||
```yaml
|
||||
required_audit_events:
|
||||
"10.2.1": "All individual user accesses to cardholder data"
|
||||
"10.2.2": "All actions taken by any individual with root or admin privileges"
|
||||
"10.2.3": "Access to all audit trails"
|
||||
"10.2.4": "Invalid logical access attempts"
|
||||
"10.2.5": "Changes to identification and authentication credentials"
|
||||
"10.2.6": "Initialization, stopping, or pausing of audit logs"
|
||||
"10.2.7": "Creation and deletion of system-level objects"
|
||||
|
||||
log_entry_requirements:
|
||||
"10.3.1": "User identification"
|
||||
"10.3.2": "Type of event"
|
||||
"10.3.3": "Date and time"
|
||||
"10.3.4": "Success or failure indication"
|
||||
"10.3.5": "Origination of event"
|
||||
"10.3.6": "Identity or name of affected data/resource"
|
||||
|
||||
retention:
|
||||
minimum: "12 months total"
|
||||
immediately_available: "At least 3 months"
|
||||
archive: "Remaining months can be in archive storage"
|
||||
|
||||
time_synchronization:
|
||||
"10.6.1": "Synchronize clocks using NTP"
|
||||
"10.6.2": "Time data protected from unauthorized access"
|
||||
"10.6.3": "Time settings received from industry-accepted sources"
|
||||
ntp_config: |
|
||||
# /etc/ntp.conf or chrony.conf for CDE systems
|
||||
server 0.pool.ntp.org iburst
|
||||
server 1.pool.ntp.org iburst
|
||||
driftfile /var/lib/ntp/drift
|
||||
restrict default nomodify notrap nopeer noquery
|
||||
restrict 127.0.0.1
|
||||
```
|
||||
|
||||
## PCI DSS Compliance Checklist
|
||||
|
||||
```yaml
|
||||
pci_dss_checklist:
|
||||
scoping:
|
||||
- [ ] CDE boundaries identified and documented
|
||||
- [ ] All in-scope systems inventoried
|
||||
- [ ] Network segmentation validated
|
||||
- [ ] Data flow diagrams current and accurate
|
||||
- [ ] SAQ type determined (if applicable)
|
||||
- [ ] Third-party service providers identified
|
||||
|
||||
network_security:
|
||||
- [ ] Firewalls/security groups restrict CDE access
|
||||
- [ ] Default deny rules on all CDE boundaries
|
||||
- [ ] Wireless networks segmented from CDE
|
||||
- [ ] Remote access uses MFA
|
||||
- [ ] All firewall rules documented with business justification
|
||||
- [ ] Rules reviewed semi-annually
|
||||
|
||||
data_protection:
|
||||
- [ ] PAN masked when displayed (first 6, last 4 max)
|
||||
- [ ] Stored PAN encrypted with AES-256 or equivalent
|
||||
- [ ] Sensitive auth data not stored after authorization
|
||||
- [ ] Encryption keys managed per Req 3.6/3.7
|
||||
- [ ] TLS 1.2+ for all cardholder data transmission
|
||||
- [ ] Tokenization implemented where feasible
|
||||
|
||||
access_control:
|
||||
- [ ] Access restricted on need-to-know basis
|
||||
- [ ] Unique IDs for all users
|
||||
- [ ] MFA for all access into CDE
|
||||
- [ ] MFA for all remote/non-console admin access
|
||||
- [ ] Default/vendor passwords changed
|
||||
- [ ] Shared/group accounts not used (or tightly controlled)
|
||||
- [ ] Access reviewed at least every 6 months
|
||||
|
||||
monitoring:
|
||||
- [ ] Audit logs capture all required events (Req 10.2)
|
||||
- [ ] Log entries include all required fields (Req 10.3)
|
||||
- [ ] Logs protected from modification
|
||||
- [ ] Logs retained 12 months (3 months immediately available)
|
||||
- [ ] Time synchronization configured (NTP)
|
||||
- [ ] Daily log review process or automated alerting
|
||||
- [ ] File integrity monitoring on critical files
|
||||
|
||||
testing:
|
||||
- [ ] Internal vulnerability scans quarterly
|
||||
- [ ] External ASV scans quarterly (passing)
|
||||
- [ ] Internal penetration test annually
|
||||
- [ ] External penetration test annually
|
||||
- [ ] Segmentation test annually (or after changes)
|
||||
- [ ] Web application assessment annually (or WAF deployed)
|
||||
- [ ] IDS/IPS monitoring all CDE network traffic
|
||||
|
||||
policies:
|
||||
- [ ] Information security policy reviewed annually
|
||||
- [ ] Security awareness training for all personnel
|
||||
- [ ] Incident response plan documented and tested
|
||||
- [ ] Third-party service provider compliance confirmed
|
||||
- [ ] Risk assessment performed annually
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Minimize CDE scope
|
||||
- Use tokenization
|
||||
- Quarterly vulnerability scans
|
||||
- Annual penetration tests
|
||||
- ASV scan certification
|
||||
- Minimize CDE scope aggressively using tokenization, P2PE, and outsourced payment processing
|
||||
- Use network segmentation to isolate the CDE and reduce the number of in-scope systems
|
||||
- Never store sensitive authentication data (CVV, track data, PIN) after authorization
|
||||
- Implement MFA for all access into the CDE, not just remote access (v4.0 requirement)
|
||||
- Automate vulnerability scanning and patch management to maintain continuous compliance
|
||||
- Deploy file integrity monitoring on all CDE systems to detect unauthorized changes
|
||||
- Synchronize clocks across all CDE systems using NTP for accurate log correlation
|
||||
- Conduct internal and external penetration tests annually and after significant changes
|
||||
- Review all firewall and security group rules semi-annually with documented business justification
|
||||
- Maintain a current data flow diagram showing all cardholder data transmission and storage points
|
||||
|
||||
@@ -9,74 +9,378 @@ metadata:
|
||||
|
||||
# SOC 2 Compliance
|
||||
|
||||
Implement SOC 2 Trust Services Criteria for certification.
|
||||
Implement SOC 2 Trust Services Criteria controls, evidence collection, and continuous compliance monitoring for Type I and Type II audits.
|
||||
|
||||
## Trust Services Criteria
|
||||
## When to Use
|
||||
|
||||
- Preparing for a SOC 2 Type I or Type II audit
|
||||
- Mapping existing controls to Trust Services Criteria
|
||||
- Automating evidence collection for auditor requests
|
||||
- Building continuous compliance monitoring into CI/CD
|
||||
- Onboarding new services and ensuring SOC 2 control coverage
|
||||
|
||||
## Trust Services Criteria Detailed Checklist
|
||||
|
||||
```yaml
|
||||
criteria:
|
||||
security:
|
||||
- Access controls
|
||||
- Change management
|
||||
- Risk assessment
|
||||
- Incident response
|
||||
|
||||
availability:
|
||||
- System monitoring
|
||||
- Disaster recovery
|
||||
- Capacity planning
|
||||
- SLA management
|
||||
|
||||
processing_integrity:
|
||||
- Input validation
|
||||
- Processing completeness
|
||||
- Output accuracy
|
||||
|
||||
confidentiality:
|
||||
- Data classification
|
||||
- Encryption
|
||||
- Access restrictions
|
||||
|
||||
privacy:
|
||||
- Data collection notice
|
||||
- Consent management
|
||||
- Data retention
|
||||
security_common_criteria:
|
||||
CC1_control_environment:
|
||||
CC1.1: "Management demonstrates commitment to integrity and ethical values"
|
||||
CC1.2: "Board exercises oversight of internal controls"
|
||||
CC1.3: "Management establishes structure, authority, and responsibility"
|
||||
CC1.4: "Commitment to competence - hire and retain qualified personnel"
|
||||
CC1.5: "Individuals are held accountable for internal control responsibilities"
|
||||
evidence:
|
||||
- Code of conduct document
|
||||
- Organizational chart
|
||||
- Job descriptions with security responsibilities
|
||||
- Board meeting minutes discussing security
|
||||
- Background check policy and records
|
||||
|
||||
CC2_communication:
|
||||
CC2.1: "Entity obtains or generates relevant quality information"
|
||||
CC2.2: "Entity internally communicates information including objectives and responsibilities"
|
||||
CC2.3: "Entity communicates with external parties"
|
||||
evidence:
|
||||
- Security awareness training records
|
||||
- Internal security newsletters or updates
|
||||
- Customer-facing security documentation
|
||||
- Status page and incident communication records
|
||||
|
||||
CC3_risk_assessment:
|
||||
CC3.1: "Entity specifies objectives clearly to identify and assess risks"
|
||||
CC3.2: "Entity identifies risks to achievement of objectives"
|
||||
CC3.3: "Entity considers potential for fraud"
|
||||
CC3.4: "Entity identifies and assesses significant changes"
|
||||
evidence:
|
||||
- Annual risk assessment report
|
||||
- Risk register with ratings and treatment plans
|
||||
- Fraud risk assessment documentation
|
||||
- Change management records
|
||||
|
||||
CC4_monitoring:
|
||||
CC4.1: "Entity selects, develops, and performs ongoing/separate evaluations"
|
||||
CC4.2: "Entity evaluates and communicates internal control deficiencies"
|
||||
evidence:
|
||||
- Continuous monitoring dashboard screenshots
|
||||
- Internal audit reports
|
||||
- Vulnerability scan results
|
||||
- Penetration test reports
|
||||
|
||||
CC5_control_activities:
|
||||
CC5.1: "Entity selects and develops control activities to mitigate risks"
|
||||
CC5.2: "Entity selects and develops technology-based controls"
|
||||
CC5.3: "Entity deploys control activities through policies and procedures"
|
||||
evidence:
|
||||
- Information security policy
|
||||
- Access control procedures
|
||||
- Change management procedures
|
||||
- Encryption standards documentation
|
||||
|
||||
CC6_logical_access:
|
||||
CC6.1: "Logical access security over protected information assets"
|
||||
CC6.2: "Prior to access, users are registered and authorized"
|
||||
CC6.3: "Access to data, software, functions, and other IT resources is authorized and modified"
|
||||
CC6.6: "Logical access security measures against threats from outside system boundaries"
|
||||
CC6.7: "Transmission of data between parties is protected"
|
||||
CC6.8: "Controls to prevent or detect unauthorized or malicious software"
|
||||
evidence:
|
||||
- IAM credential report
|
||||
- MFA enforcement configuration
|
||||
- Access review completion records
|
||||
- Firewall and WAF configurations
|
||||
- TLS/encryption configurations
|
||||
- Endpoint protection deployment records
|
||||
|
||||
CC7_system_operations:
|
||||
CC7.1: "Detect anomalies and potential security incidents"
|
||||
CC7.2: "Monitor system components for anomalies"
|
||||
CC7.3: "Evaluate detected events and determine incidents"
|
||||
CC7.4: "Respond to identified security incidents"
|
||||
CC7.5: "Identify and remediate security incidents"
|
||||
evidence:
|
||||
- SIEM alert rules and dashboards
|
||||
- Monitoring configuration (CloudWatch, Datadog, etc.)
|
||||
- Incident response plan
|
||||
- Incident tickets and post-mortems
|
||||
|
||||
CC8_change_management:
|
||||
CC8.1: "Entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes"
|
||||
evidence:
|
||||
- Change management policy
|
||||
- Pull request approval requirements
|
||||
- CI/CD pipeline configurations
|
||||
- Deployment records with approvals
|
||||
|
||||
CC9_risk_mitigation:
|
||||
CC9.1: "Entity identifies, selects, and develops risk mitigation activities"
|
||||
CC9.2: "Entity assesses and manages risks associated with vendors"
|
||||
evidence:
|
||||
- Risk treatment plans
|
||||
- Vendor assessment records
|
||||
- Business associate agreements
|
||||
- Insurance certificates
|
||||
|
||||
availability_criteria:
|
||||
A1.1: "System processing capacity and availability are maintained"
|
||||
A1.2: "Environmental protections and recovery measures"
|
||||
A1.3: "Recovery plan procedures to support system availability"
|
||||
evidence:
|
||||
- Uptime SLA documentation
|
||||
- Capacity monitoring dashboards
|
||||
- Disaster recovery plan
|
||||
- DR test results
|
||||
- Backup verification records
|
||||
|
||||
processing_integrity_criteria:
|
||||
PI1.1: "Entity obtains or generates, uses, and communicates quality information"
|
||||
evidence:
|
||||
- Input validation procedures
|
||||
- Data processing accuracy checks
|
||||
- Error handling and retry logic documentation
|
||||
- Output reconciliation records
|
||||
|
||||
confidentiality_criteria:
|
||||
C1.1: "Entity identifies and maintains confidential information"
|
||||
C1.2: "Entity disposes of confidential information"
|
||||
evidence:
|
||||
- Data classification policy
|
||||
- Encryption configurations
|
||||
- Data retention and destruction policies
|
||||
- Secure disposal records
|
||||
|
||||
privacy_criteria:
|
||||
P1-P8: "Privacy notice, choice, collection, use, disclosure, access, quality, monitoring"
|
||||
evidence:
|
||||
- Privacy policy (published)
|
||||
- Consent management records
|
||||
- Data processing inventory
|
||||
- DSAR handling procedures
|
||||
```
|
||||
|
||||
## Key Controls
|
||||
## Tool Mappings for Control Evidence
|
||||
|
||||
```yaml
|
||||
controls:
|
||||
control_to_tool_mapping:
|
||||
CC6.1_logical_access:
|
||||
- MFA enforcement
|
||||
- Role-based access
|
||||
- Access reviews
|
||||
|
||||
aws:
|
||||
- IAM credential report (aws iam generate-credential-report)
|
||||
- IAM Access Analyzer findings
|
||||
- AWS SSO configuration
|
||||
- GuardDuty findings
|
||||
azure:
|
||||
- Azure AD sign-in logs
|
||||
- Conditional Access policies
|
||||
- PIM role assignments
|
||||
github:
|
||||
- Organization member list and roles
|
||||
- Repository access permissions
|
||||
- Branch protection rules
|
||||
okta:
|
||||
- User status report
|
||||
- MFA enrollment report
|
||||
- Application assignment report
|
||||
|
||||
CC7.2_monitoring:
|
||||
- Log aggregation
|
||||
- Alert thresholds
|
||||
- Incident tracking
|
||||
|
||||
tools:
|
||||
- CloudWatch / Azure Monitor / Cloud Monitoring dashboards
|
||||
- Datadog / New Relic / Grafana alert configurations
|
||||
- SIEM (Splunk, Elastic, Sentinel) saved searches
|
||||
- PagerDuty / OpsGenie escalation policies
|
||||
evidence_format:
|
||||
- Dashboard screenshots with date stamps
|
||||
- Alert rule configuration exports
|
||||
- Incident response records from ticketing system
|
||||
|
||||
CC8.1_change_management:
|
||||
- Change requests
|
||||
- Approval workflows
|
||||
- Testing requirements
|
||||
tools:
|
||||
- GitHub/GitLab PR merge requirements
|
||||
- CI/CD pipeline configurations (GitHub Actions, Jenkins)
|
||||
- Terraform plan outputs
|
||||
- Deployment logs
|
||||
evidence_format:
|
||||
- PR with approvals and CI checks
|
||||
- Deployment audit trail
|
||||
- Change advisory board meeting notes (if applicable)
|
||||
```
|
||||
|
||||
## Evidence Collection
|
||||
## Evidence Collection Automation
|
||||
|
||||
```bash
|
||||
# Access review export
|
||||
aws iam generate-credential-report
|
||||
aws iam get-credential-report
|
||||
#!/usr/bin/env bash
|
||||
# collect-soc2-evidence.sh - Automated SOC 2 evidence collection
|
||||
# Run monthly or before audit requests
|
||||
|
||||
# Audit logs
|
||||
aws cloudtrail lookup-events --start-time $(date -d '30 days ago' --iso)
|
||||
EVIDENCE_DIR="./soc2-evidence/$(date +%Y-%m)"
|
||||
mkdir -p "$EVIDENCE_DIR"
|
||||
|
||||
echo "=== CC6.1 - Logical Access Evidence ==="
|
||||
|
||||
# AWS IAM credential report
|
||||
aws iam generate-credential-report
|
||||
sleep 10
|
||||
aws iam get-credential-report --output text --query Content | \
|
||||
base64 -d > "$EVIDENCE_DIR/aws-iam-credential-report.csv"
|
||||
|
||||
# AWS IAM Access Analyzer findings
|
||||
aws accessanalyzer list-findings \
|
||||
--analyzer-arn "arn:aws:access-analyzer:us-east-1:123456789012:analyzer/org-analyzer" \
|
||||
--filter '{"status": {"eq": ["ACTIVE"]}}' \
|
||||
> "$EVIDENCE_DIR/access-analyzer-findings.json"
|
||||
|
||||
# MFA enforcement status
|
||||
aws iam list-users --query 'Users[*].UserName' --output text | \
|
||||
tr '\t' '\n' | while read -r user; do
|
||||
mfa=$(aws iam list-mfa-devices --user-name "$user" --query 'MFADevices[0].SerialNumber' --output text)
|
||||
echo "$user,$mfa"
|
||||
done > "$EVIDENCE_DIR/mfa-status.csv"
|
||||
|
||||
# GitHub organization members and roles
|
||||
gh api orgs/YOUR_ORG/members --paginate --jq '.[] | [.login, .role_name // "member"] | @csv' \
|
||||
> "$EVIDENCE_DIR/github-org-members.csv"
|
||||
|
||||
# GitHub branch protection rules
|
||||
for repo in $(gh repo list YOUR_ORG --json name -q '.[].name'); do
|
||||
gh api repos/YOUR_ORG/$repo/branches/main/protection \
|
||||
> "$EVIDENCE_DIR/branch-protection-$repo.json" 2>/dev/null
|
||||
done
|
||||
|
||||
echo "=== CC7.2 - Monitoring Evidence ==="
|
||||
|
||||
# CloudTrail status
|
||||
aws cloudtrail get-trail-status --name org-audit-trail \
|
||||
> "$EVIDENCE_DIR/cloudtrail-status.json"
|
||||
|
||||
# Active CloudWatch alarms
|
||||
aws cloudwatch describe-alarms --state-value ALARM \
|
||||
> "$EVIDENCE_DIR/active-alarms.json"
|
||||
|
||||
# GuardDuty findings summary
|
||||
aws guardduty list-findings --detector-id DETECTOR_ID \
|
||||
--finding-criteria '{"criterion":{"severity":{"gte":4}}}' \
|
||||
> "$EVIDENCE_DIR/guardduty-findings.json"
|
||||
|
||||
echo "=== CC8.1 - Change Management Evidence ==="
|
||||
|
||||
# Recent deployments (GitHub Actions)
|
||||
gh run list --repo YOUR_ORG/YOUR_REPO --limit 50 --json conclusion,createdAt,displayTitle,headBranch \
|
||||
> "$EVIDENCE_DIR/recent-deployments.json"
|
||||
|
||||
# Pull requests merged in audit period
|
||||
gh pr list --repo YOUR_ORG/YOUR_REPO --state merged --limit 100 \
|
||||
--json number,title,author,mergedBy,mergedAt,reviews \
|
||||
> "$EVIDENCE_DIR/merged-prs.json"
|
||||
|
||||
echo "=== A1 - Availability Evidence ==="
|
||||
|
||||
# Backup status
|
||||
aws rds describe-db-snapshots --db-instance-identifier prod-db \
|
||||
--query 'DBSnapshots | sort_by(@, &SnapshotCreateTime) | [-5:]' \
|
||||
> "$EVIDENCE_DIR/rds-backup-snapshots.json"
|
||||
|
||||
# S3 replication status
|
||||
aws s3api get-bucket-replication --bucket prod-data-bucket \
|
||||
> "$EVIDENCE_DIR/s3-replication-config.json"
|
||||
|
||||
echo "Evidence collected in $EVIDENCE_DIR"
|
||||
tar -czf "$EVIDENCE_DIR.tar.gz" "$EVIDENCE_DIR"
|
||||
echo "Archive: $EVIDENCE_DIR.tar.gz"
|
||||
```
|
||||
|
||||
## Audit Preparation Timeline
|
||||
|
||||
```yaml
|
||||
audit_prep_timeline:
|
||||
12_months_before:
|
||||
- Select auditor firm and sign engagement letter
|
||||
- Perform gap assessment against TSC criteria
|
||||
- Remediate identified control gaps
|
||||
- Begin formal evidence collection cadence
|
||||
|
||||
6_months_before:
|
||||
- Conduct internal readiness assessment
|
||||
- Verify all controls are operating effectively
|
||||
- Complete risk assessment and update risk register
|
||||
- Ensure vendor assessments are current
|
||||
- Test disaster recovery procedures
|
||||
|
||||
3_months_before:
|
||||
- Run automated evidence collection and verify completeness
|
||||
- Conduct access review and remediate findings
|
||||
- Review and update all policies and procedures
|
||||
- Perform vulnerability scan and penetration test
|
||||
- Confirm all training records are current
|
||||
|
||||
1_month_before:
|
||||
- Prepare evidence request list responses
|
||||
- Organize evidence into auditor-friendly structure
|
||||
- Brief key personnel on audit interviews
|
||||
- Verify monitoring dashboards show healthy state
|
||||
- Confirm incident response records are complete
|
||||
|
||||
during_audit:
|
||||
- Designate audit liaison for request management
|
||||
- Provide timely evidence and clarifications
|
||||
- Track open auditor questions
|
||||
- Escalate issues to control owners promptly
|
||||
|
||||
after_audit:
|
||||
- Review draft report and provide management response
|
||||
- Create remediation plan for any exceptions
|
||||
- Communicate results to stakeholders
|
||||
- Update controls and processes based on findings
|
||||
- Begin next audit period evidence collection
|
||||
```
|
||||
|
||||
## Continuous Compliance Monitoring
|
||||
|
||||
```yaml
|
||||
# GitHub Actions workflow for continuous SOC 2 checks
|
||||
name: SOC2 Compliance Checks
|
||||
on:
|
||||
schedule:
|
||||
- cron: '0 6 * * 1' # Weekly on Monday
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
access-review:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check MFA enforcement
|
||||
run: |
|
||||
USERS_WITHOUT_MFA=$(aws iam generate-credential-report && sleep 5 && \
|
||||
aws iam get-credential-report --output text --query Content | \
|
||||
base64 -d | awk -F, '$4=="true" && $8=="false" {print $1}')
|
||||
if [ -n "$USERS_WITHOUT_MFA" ]; then
|
||||
echo "::error::Users without MFA: $USERS_WITHOUT_MFA"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Check for unused credentials
|
||||
run: |
|
||||
THRESHOLD=$(date -d '90 days ago' +%Y-%m-%dT%H:%M:%S)
|
||||
aws iam get-credential-report --output text --query Content | \
|
||||
base64 -d | awk -F, -v t="$THRESHOLD" '$5!="N/A" && $5<t {print $1" last used "$5}'
|
||||
|
||||
- name: Verify CloudTrail is logging
|
||||
run: |
|
||||
STATUS=$(aws cloudtrail get-trail-status --name org-audit-trail --query 'IsLogging' --output text)
|
||||
[ "$STATUS" = "True" ] || (echo "::error::CloudTrail logging stopped" && exit 1)
|
||||
|
||||
- name: Check GuardDuty is enabled
|
||||
run: |
|
||||
DETECTOR=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
|
||||
[ "$DETECTOR" != "None" ] || (echo "::error::GuardDuty not enabled" && exit 1)
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Continuous compliance monitoring
|
||||
- Annual risk assessments
|
||||
- Regular control testing
|
||||
- Documentation maintenance
|
||||
- Start with a gap assessment to understand current control maturity before engaging an auditor
|
||||
- Automate evidence collection to reduce the burden of auditor requests and ensure consistency
|
||||
- Map each control to a specific tool, owner, and evidence artifact for traceability
|
||||
- Implement continuous monitoring rather than point-in-time checks for Type II readiness
|
||||
- Maintain a central evidence repository organized by control criteria
|
||||
- Conduct quarterly internal reviews to catch control drift before the audit period
|
||||
- Keep policies living documents with version history and annual review dates
|
||||
- Train all employees on their role in maintaining SOC 2 controls
|
||||
- Use the audit preparation timeline to avoid last-minute scrambling
|
||||
- Treat each auditor exception as an improvement opportunity rather than a failure
|
||||
|
||||
Reference in New Issue
Block a user