incident-response

name	incident-response
description	Security incident detection, analysis, containment, eradication, recovery, and lessons learned per NIST SP 800-61r2 and ISO 27035
license	Apache-2.0

Incident Response Skill

Purpose

This skill establishes comprehensive procedures for detecting, analyzing, containing, eradicating, and recovering from security incidents affecting the CIA platform. It implements systematic incident management aligned with NIST SP 800-61r2, ISO 27035, and Hack23 ISMS Incident Response Plan with measurable response times and transparent communication.

When to Use This Skill

Apply this skill when:

• ✅ Detecting security alerts or suspicious activity
• ✅ Responding to security breaches or data exposure
• ✅ Managing vulnerability exploitation incidents
• ✅ Coordinating response to service disruptions
• ✅ Handling supply chain security incidents
• ✅ Meeting GDPR 72-hour breach notification requirements
• ✅ Conducting post-incident analysis and lessons learned
• ✅ Updating incident response playbooks

Do NOT use for:

• ❌ Routine maintenance or planned downtime
• ❌ Non-security operational issues
• ❌ Performance degradation without security implications

Decision Tree

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#D32F2F',
      'primaryTextColor': '#fff',
      'lineColor': '#D32F2F',
      'secondaryColor': '#FF9800',
      'tertiaryColor': '#4CAF50'
    }
  }
}%%
flowchart TD
    DETECT["🔍 Incident Detected"] --> VALIDATE{"✅ Confirmed<br/>Security Incident?"}
    
    VALIDATE -->|YES| CLASSIFY{"🏷️ Classify Severity"}
    VALIDATE -->|NO| FALSE["📋 False Positive<br/>Document & Close"]
    
    CLASSIFY -->|🔴 Critical<br/>€10K+ daily loss| S1["🔴 S1: Critical Response<br/>RTO: 30 min<br/>All Stakeholders"]
    CLASSIFY -->|🟠 High<br/>€5-10K daily loss| S2["🟠 S2: High Response<br/>RTO: 1 hour<br/>Key Stakeholders"]
    CLASSIFY -->|🟡 Medium<br/>€1-5K daily loss| S3["🟡 S3: Medium Response<br/>RTO: 4 hours<br/>Internal Only"]
    CLASSIFY -->|🟢 Low<br/><€1K daily loss| S4["🟢 S4: Low Response<br/>RTO: 24 hours<br/>Documentation"]
    
    S1 --> ACTIVATE["🚨 Activate Response Team<br/>CEO + Specialists"]
    S2 --> ACTIVATE
    S3 --> ACTIVATE
    S4 --> ACTIVATE
    
    ACTIVATE --> CONTAIN["🛡️ Containment<br/>Isolate & Preserve"]
    CONTAIN --> INVESTIGATE["🔬 Investigation<br/>Root Cause Analysis"]
    INVESTIGATE --> REMEDIATE["🔧 Remediation<br/>Fix & Restore"]
    REMEDIATE --> VALIDATE_FIX{"✅ Validated?"}
    
    VALIDATE_FIX -->|NO| REMEDIATE
    VALIDATE_FIX -->|YES| NOTIFY{"📢 External<br/>Notification<br/>Required?"}
    
    NOTIFY -->|YES - GDPR| GDPR["📢 GDPR Notification<br/>72-hour deadline"]
    NOTIFY -->|YES - NIS2| NIS2["📢 NIS2 Notification<br/>24-hour initial"]
    NOTIFY -->|YES - Customers| CUSTOMER["📢 Customer Notice<br/>Per SLA"]
    NOTIFY -->|NO| DOCUMENT
    
    GDPR --> DOCUMENT["📝 Incident Report"]
    NIS2 --> DOCUMENT
    CUSTOMER --> DOCUMENT
    
    DOCUMENT --> LESSONS["📈 Lessons Learned<br/>Process Improvement"]
    LESSONS --> CLOSE["✅ Close Incident<br/>Archive Evidence"]
    CLOSE --> MONITOR["🔄 Continuous Monitoring"]
    
    style DETECT fill:#2196F3,color:#fff
    style S1 fill:#D32F2F,color:#fff
    style S2 fill:#FF9800,color:#fff
    style S3 fill:#FFC107,color:#000
    style S4 fill:#4CAF50,color:#fff
    style CONTAIN fill:#7B1FA2,color:#fff
    style INVESTIGATE fill:#1565C0,color:#fff
    style REMEDIATE fill:#FF9800,color:#fff
    style CLOSE fill:#4CAF50,color:#fff

Incident Severity Classification

Severity Matrix

Severity	Financial Impact	Operational Impact	RTO	Escalation
🔴 S1: Critical	€10K+ daily loss	Complete outage	30 minutes	CEO + External Consultant
🟠 S2: High	€5-10K daily loss	Major degradation	1 hour	CEO + Insurance Provider
🟡 S3: Medium	€1-5K daily loss	Partial impact	4 hours	CEO Investigation
🟢 S4: Low	<€1K daily loss	Minor inconvenience	24 hours	CEO Scheduled Review

Incident Classification Examples

🔴 S1: Critical Incidents

• Ransomware infection affecting production systems
• Active data breach with PII exposure
• Complete service outage affecting all users
• Successful credential theft with admin access
• Criminal liability (GDPR Article 83 violations)

🟠 S2: High Incidents

• Exploitation of critical vulnerability (CVSS 9.0+)
• Partial data exposure (limited user data)
• Major service degradation (>50% users affected)
• Unauthorized access to sensitive systems
• Regulatory investigation triggered

🟡 S3: Medium Incidents

• Attempted exploitation (blocked by controls)
• Security misconfigurations discovered
• Malware detected and quarantined
• Moderate service impact (<50% users)
• Minor compliance violations

🟢 S4: Low Incidents

• Failed login attempts (below threshold)
• Security scan false positives
• Minor policy violations
• Suspicious activity with no impact
• Documentation issues

Incident Response Lifecycle

Phase 1: Preparation

Pre-Incident Readiness:

Incident_Response_Team:
  - CEO: James Pether Sörling (Incident Commander)
  - Security Lead: Primary responder
  - Development Lead: Technical remediation
  - External Consultant: On-call security expert
  - Legal Counsel: GDPR/regulatory compliance
  - Insurance Provider: Cyber insurance liaison

Tools_and_Resources:
  - AWS Detective: Log analysis and investigation
  - AWS Security Hub: Centralized security findings
  - AWS GuardDuty: Threat detection
  - GitHub Security: Repository security monitoring
  - CloudWatch Logs Insights: Query and analysis
     


      
        
       
       
      


     
      
     
        
      

Preparation Checklist:

• Incident Response Plan: Reviewed and updated quarterly
• Contact List: Current and tested (External Stakeholder Registry)
• Playbooks: Scenario-specific procedures documented
• Tools: AWS security services enabled and monitored
• Training: Annual tabletop exercises conducted
• Backups: Verified and tested monthly
• Insurance: Cyber insurance policy active and adequate
• Legal: Retainer with legal counsel for GDPR compliance

Phase 2: Detection and Analysis

Detection Sources:

flowchart LR
    subgraph "🔍 Automated Detection"
        GUARD[AWS GuardDuty<br/>Threat Detection]
        SECHUB[AWS Security Hub<br/>Findings Aggregation]
        CODEQL[CodeQL<br/>Code Scanning]
        DEPEND[Dependabot<br/>Vulnerability Alerts]
    end
    
    subgraph "👁️ Manual Detection"
        USER[User Report<br/>Security Concern]
        AUDIT[Security Audit<br/>Findings]
        RESEARCH[Security Researcher<br/>Disclosure]
        MONITOR[System Monitoring<br/>Anomalies]
    end
    
    subgraph "🎯 Incident Triage"
        VALIDATE[Validate Incident]
        CLASSIFY[Classify Severity]
        ASSIGN[Assign Response Team]
    end
    
    GUARD --> VALIDATE
    SECHUB --> VALIDATE
    CODEQL --> VALIDATE
    DEPEND --> VALIDATE
    USER --> VALIDATE
    AUDIT --> VALIDATE
    RESEARCH --> VALIDATE
    MONITOR --> VALIDATE
    
    VALIDATE --> CLASSIFY
    CLASSIFY --> ASSIGN
    
    style VALIDATE fill:#FF9800,color:#fff
    style CLASSIFY fill:#D32F2F,color:#fff
    style ASSIGN fill:#1565C0,color:#fff

Initial Assessment Checklist:

• Incident Confirmed: Validate security incident vs. false positive
• Scope Identified: Affected systems, data, and users documented
• Timeline Established: Initial detection and estimated start time
• Severity Classified: Using severity matrix (S1-S4)
• Evidence Preserved: Logs, snapshots, and artifacts collected
• Team Notified: Response team activated per severity level
• Stakeholders Informed: CEO notified within RTO
• Communication Plan: Notification requirements assessed

Analysis Activities:

# 1. Collect AWS CloudTrail logs
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-16T00:00:00Z \
  --max-results 100 \
  > incident-cloudtrail-logs.json

# 2. Query CloudWatch Logs
aws logs filter-log-events \
  --log-group-name /aws/lambda/cia-production \
  --start-time $(date -d '24 hours ago' +%s)000 \
  --filter-pattern "ERROR" \
  > incident-application-logs.txt

# 3. Check AWS GuardDuty findings
aws guardduty list-findings \
  --detector-id YOUR_DETECTOR_ID \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}' \
  --sort-criteria '{"AttributeName":"updatedAt","OrderBy":"DESC"}' \
  > incident-guardduty-findings.json

# 4. Review AWS Security Hub findings
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --max-results 100 \
  > incident-securityhub-findings.json

# 5. Analyze access patterns
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=SUSPECTED_USER \
  --start-time 2024-01-15T00:00:00Z \
  > incident-user-activity.json

# 6. Create evidence package
tar -czf incident-evidence-$(date +%Y%m%d-%H%M%S).tar.gz \
  incident-*.json incident-*.txt

Phase 3: Containment

Short-Term Containment:

Immediate_Actions:
  Network_Isolation:
    - Action: Isolate affected systems from network
    - Method: AWS Security Group rule changes
    - Command: |
        aws ec2 revoke-security-group-ingress \
          --group-id sg-AFFECTED \
          --protocol all \
          --cidr 0.0.0.0/0
  
  Access_Revocation:
    - Action: Disable compromised user accounts
    - Method: AWS IAM policy detachment
    - Command: |
        aws iam delete-login-profile \
          --user-name COMPROMISED_USER
        aws iam list-access-keys \
          --user-name COMPROMISED_USER | \
          jq -r '.AccessKeyMetadata[].AccessKeyId' | \
          xargs -I {} aws iam delete-access-key \
            --user-name COMPROMISED_USER \
            --access-key-id {}
  
  Session_Termination:
    - Action: Invalidate active sessions
    - Method: AWS IAM role trust policy update
        
  
          
           
      

Long-Term Containment:

Sustained_Protection:
  System_Patching:
    - Action: Apply security patches to affected systems
    - Priority: Critical vulnerabilities first
    - Validation: Test in staging before production
  
  Password_Rotation:
    - Action: Force password reset for all affected users
    - Method: AWS Cognito password reset enforcement
    - Scope: All users if credential exposure suspected
  
  Certificate_Revocation:
    - Action: Revoke and reissue compromised certificates
    - Method:   
           
  
  
             
           
          
  
  
          
         
            

Phase 4: Eradication

Root Cause Elimination:

Malware_Removal:
  - Identify all infected systems (AWS Systems Manager inventory)
  - Terminate compromised EC2 instances
  - Deploy clean AMI from known-good backup
  - Scan file systems with AWS Inspector
  - Verify integrity with AWS CloudWatch Logs Insights

Vulnerability_Patching:
  - Apply security patches addressing root cause
  - Update dependencies (Dependabot PRs)
  - Fix configuration weaknesses (AWS Config remediation)
  -      


        
        
       
        


       
        
       
         
         

Eradication Checklist:

• Root Cause Identified: Technical analysis complete
• Vulnerability Fixed: Patch applied or workaround implemented
• Malware Removed: All infected systems cleaned or replaced
• Accounts Secured: Unauthorized access revoked
• Configuration Hardened: Security controls strengthened
• Validation Testing: Security scans confirm clean state
• Documentation Updated: Changes recorded in change log

Phase 5: Recovery

System Restoration:

Restore_Services:
  Phase_1_Critical:
    - Restore database from pre-incident backup
    - Deploy application from verified clean build
    - Restore S3 data from backup or versioning
    - Verify data integrity (checksums, record counts)
  
  Phase_2_Validation:
    - Run security scans (CodeQL, OWASP Dependency Check)
    - Execute integration tests (Maven verify)
    - Perform manual security testing
    - Validate monitoring and alerting
  
  Phase_3_Gradual_Rollout:
    -    
         
        
         


      
      
       
      

Recovery Verification:

# 1. Verify application functionality
curl -s https://www.hack23.com/cia/ | grep -q "Citizen Intelligence Agency"
echo "Application accessible: $?"

# 2. Check database connectivity
psql -h DATABASE_HOST -U cia_user -d cia_db -c "SELECT COUNT(*) FROM politician;"

# 3. Verify API endpoints
curl -s -o /dev/null -w "%{http_code}" https://api.hack23.com/health
# Expected: 200

# 4. Test authentication
# Perform test login with known credentials
# Verify MFA enforcement

# 5. Scan for vulnerabilities
mvn dependency-check:check
# Expected: No critical vulnerabilities

# 6. Monitor logs for errors
aws logs tail /aws/lambda/cia-production --follow --filter-pattern "ERROR"

Phase 6: Post-Incident Activities

Lessons Learned Analysis:

# Incident Post-Mortem Template

## Incident Summary
- **Incident ID:** INC-2024-001
- **Date Detected:** 2024-01-15 09:30 UTC
- **Date Resolved:** 2024-01-16 14:00 UTC
- **Severity:** S2 (High)
- **Duration:** 28.5 hours

## Incident Details
- **Type:** Unauthorized access attempt
- **Attack Vector:** Exposed API endpoint with weak authentication
- **Affected Systems:** Production API server (EC2 instance i-0123456789abcdef)
- **Data Impact:** No data exfiltration confirmed
- **Business Impact:** €8K estimated revenue loss (service degradation)

## Timeline
- **2024-01-15 09:30 UTC:** GuardDuty alert - suspicious API calls
- **2024-01-15 09:45 UTC:** Incident validated, CEO notified
- **2024-01-15 10:00 UTC:** Response team activated (S2 severity)
- **2024-01-15 10:30 UTC:** Affected endpoint isolated (security group update)
- **2024-01-15 11:00 UTC:** Root cause identified (missing authentication)
- **2024-01-15 12:00 UTC:** Fix deployed to staging, testing complete
- **2024-01-15 14:00 UTC:** Fix deployed to production
- **2024-01-15 15:00 UTC:** Monitoring confirms normal operation
- **2024-01-16 14:00 UTC:** Incident closed after 24-hour observation



New API endpoint deployed without authentication middleware. Exposed endpoint allowed unauthenticated access to internal admin functions.


 Code review process did not catch missing @PreAuthorize annotation
 Integration tests did not include security test cases
 Deployment pipeline lacked security gate (CodeQL did not run)


 Tight deadline pressure led to shortened review
 Developer unfamiliar with Spring Security patterns
 Security requirements not explicitly documented in user story


 ✅ Detection within 15 minutes (GuardDuty alert)
 ✅ Incident validation within 15 minutes
 ✅ Containment within 1 hour (met RTO)
 ✅ Clear communication with CEO throughout
 ✅ No data loss or exfiltration
 ✅ Root cause identified quickly


 ❌ Vulnerability introduced during deployment
 ❌ Code review did not catch security issue
 ❌ Security tests inadequate
 ❌ Deployment pipeline lacked security gate


 
 [ ] Add CodeQL to required CI/CD checks (blocker) - Owner: DevOps Lead
 [ ] Create security test template for API endpoints - Owner: Security Lead
 [ ] Update code review checklist with security items - Owner: Dev Lead

 
 [ ] Conduct security training for development team - Owner: CEO
 [ ] Implement Spring Security audit (all @RequestMapping) - Owner: Dev Team
 [ ] Add AWS WAF rules for API protection - Owner: Security Lead

 
 [ ] Establish security champion program - Owner: CEO
 [ ] Implement automated security testing framework - Owner: QA Lead
 [ ] Document secure coding standards - Owner: Security Lead


  15 minutes (target: <30 min) ✅
  15 minutes (target: <1 hour) ✅
  1 hour (target: <1 hour) ✅
  28.5 hours (target: <24 hours) ⚠️
  2 hours (partial degradation)


  Not required (no personal data breach)
  Not required (not material incident)
  Sent via email (transparency commitment)
  Submitted claim for revenue loss


  James Pether Sörling, CEO
  2024-01-16
  Closed
  ISMS-PUBLIC/incidents/INC-2024-001.md

Incident Response Playbooks

Playbook 1: Ransomware Incident

Ransomware_Response:
  Detection:
    - Indicators: Mass file encryption, ransom notes, unusual process activity
    - Sources: AWS GuardDuty, CloudWatch anomaly detection, user reports
  
  Immediate_Actions:
    - Isolate affected systems (network segmentation)
    - Disable user accounts (prevent lateral movement)
    - Preserve evidence (EBS snapshots, memory dumps)
    - Notify CEO and cyber insurance provider
  
  Containment:
    - Terminate infected EC2 instances
    - Disable   
           
           
  
  
           
         
       
           
  
  
         
         
       
         
  
  
           
        
          
        
  
  
         
       
        

Playbook 2: Data Breach Incident

Data_Breach_Response:
  Detection:
    - Indicators: Unauthorized data access, data exfiltration, S3 bucket exposure
    - Sources: AWS CloudTrail, GuardDuty, Security Hub, public disclosure
  
  Immediate_Actions:
    - Assess scope of breach (what data, how many records)
    - Classify data per Data Classification Policy
    - Preserve evidence (CloudTrail logs, network logs)
    - Activate legal counsel for GDPR compliance
  
  Containment:
    - Block unauthorized     
       
           
         
  
  
          
           
           
          
  
  
           
            
           
          
  
  
          
       
        
        
  
  
        
         
       
         

Playbook 3: DDoS Attack

DDoS_Response:
  Detection:
    - Indicators: Service degradation, high network traffic, AWS Shield alerts
    - Sources: CloudWatch metrics, AWS Shield, user reports
  
  Immediate_Actions:
    - Activate AWS Shield Advanced if not enabled
    - Enable AWS WAF rate limiting
    - Engage AWS DDoS Response Team (DRT)
    - Notify CEO and stakeholders
  
  Mitigation:
    - CloudFront distribution to absorb traffic
    - AWS Shield Advanced  
          
           
  
  
          
           
           
         
  
  
        
        
         
       
  
  
          
         
       
       
  
  
          
           
         
          

GDPR Breach Notification Requirements

72-Hour Notification Rule

GDPR_Compliance:
  Article_33_Requirements:
    - Notification to supervisory authority within 72 hours
    - Description of nature of breach
    - Name and contact details of DPO (if applicable)
    - Description of likely consequences
    - Measures taken or proposed to address breach
  
  Article_34_Requirements:
    - Direct notification to individuals if high risk
    - Clear and plain language description
    - Measures to mitigate adverse 
        
  
  
       
      
          
      
  
  
    
             
            
           
            
          
    
    
           
           
         
             

GDPR Notification Template:

# Data Breach Notification to Supervisory Authority

**To:** Integritetsskyddsmyndigheten (IMY)
**From:** Hack23 AB (Data Controller)
**Date:** [Within 72 hours of breach awareness]
**Reference:** GDPR Article 33

## 1. Description of the Personal Data Breach

**Nature of Breach:**
[Describe what happened: unauthorized access, data loss, ransomware, etc.]

**Date/Time of Breach:**
- Breach Occurred: [Estimated start time]
- Breach Detected: [Detection timestamp]
- IMY Notified: [Current timestamp]

**Categories of Personal Data:**
- [X] Names and contact details
- [ ] Financial information
- [ ] Health data
- [ ] Special categories (Article 9)
- [X] Login credentials

**Data Subjects Affected:**
- Number: Approximately [X] individuals
- Categories: [Users, customers, employees, etc.]

## 2. Contact Point

**Data Protection Officer (if applicable):**
- Name: [DPO Name] or CEO: James Pether Sörling
- Email: [e-mail]
- Phone: [Contact number]

## 3. Likely Consequences

**Assessment of Impact:**
[Describe potential harm to individuals: identity theft, financial loss, discrimination, etc.]

**Risk Level:** [High / Medium / Low]

**Justification:**
[Explain risk assessment considering data sensitivity, number affected, safeguards in place]

## 4. Measures Taken

**Containment:**
- [List immediate actions taken to stop breach]

**Mitigation:**
- [Actions to reduce harm to individuals]

**Prevention:**
- [Measures to prevent recurrence]




 Logs archived: [Yes/No]
 Forensic investigation: [In progress / Complete]


 Required: [Yes/No]
 Completed: [Yes/No / In progress]
 Method: [Email / Letter / Website notice]


[Attached incident report, forensic analysis, etc.]

---


This notification is made in compliance with GDPR Article 33. Hack23 AB commits to cooperating fully with the supervisory authority and providing updates as investigation progresses.

 James Pether Sörling, CEO
 [Submission date]

External Stakeholder Registry

Key Contacts for Incident Response:

Regulatory_Authorities:
  Swedish_DPA:
    Name: Integritetsskyddsmyndigheten (IMY)
    Email: [e-mail]
    Phone: [phone]
    Website: https://www.imy.se/
    Purpose: GDPR breach notification
  
  Swedish_Cert:
    Name: CERT-SE (Swedish Computer Security Incident Response Team)
    Email: [e-mail]
    Phone: [phone]
    Website: https://www.cert.se/
    Purpose: Critical infrastructure incidents

Legal_and_Insurance:
  Legal_Counsel:
    Contact: [Law firm details]
    Purpose: GDPR compliance, regulatory response
  
  Cyber_Insurance:
    Provider: [Insurance ]
     [ ]
     [ ]
        


  
      
        
        
  
  
     [ ]
         


  
         
          
  
  
        
        

Compliance Mapping

ISO 27001:2022

• A.5.24 - Information Security Incident Management Planning and Preparation
• A.5.25 - Assessment and Decision on Information Security Events
• A.5.26 - Response to Information Security Incidents
• A.5.27 - Learning from Information Security Incidents

NIST CSF 2.0

• DE.AE - Anomalies and Events (Detection Process)
• RS.AN - Analysis (Response Planning)
• RS.MI - Mitigation (Response Activities)
• RS.IM - Improvements (Post-Incident Activity)

CIS Controls v8

• Control 17 - Incident Response Management
• Control 17.1 - Designate Personnel to Manage Incident Handling
• Control 17.2 - Establish and Maintain Contact Information for Reporting Security Incidents
• Control 17.3 - Establish and Maintain an Enterprise Process for Reporting Incidents
• Control 17.4 - Establish and Maintain an Incident Response Process
• Control 17.5 - Assign Key Roles and Responsibilities

NIST SP 800-61r2

• Section 2.3 - Incident Response Team Structure
• Section 3.1 - Preparation
• Section 3.2 - Detection and Analysis
• Section 3.3 - Containment, Eradication, and Recovery
• Section 3.4 - Post-Incident Activity

References

• Hack23 ISMS: Incident Response Plan
• NIST SP 800-61r2: Computer Security Incident Handling Guide
• ISO 27035: Information Security Incident Management
• GDPR Articles 33-34: Personal Data Breach Notification
• AWS Incident Response: https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/
• CISA Incident Response: https://www.cisa.gov/incident-response

Examples from CIA Platform

Incident Example: API Endpoint Exposure

Incident Summary:

• Type: Unauthorized access (security misconfiguration)
• Severity: S2 (High)
• Detection: AWS GuardDuty alert
• Duration: 28.5 hours (detection to closure)
• Impact: No data breach, service degradation

Key Learnings:

• GuardDuty detected within 15 minutes (excellent MTTD)
• Code review process improved (security checklist)
• CodeQL added as required CI/CD gate
• Security training scheduled for development team

---

Document Maintenance:

• Review Frequency: Quarterly
• Last Updated: 2024-01-15
• Next Review: 2024-04-15
• Owner: Security Team / CIA Project Maintainers