Security Documentation Skill

Purpose

Ensure comprehensive, up-to-date security documentation exists for the CIA platform, enabling security reviews, compliance audits, and knowledge transfer.

When to Use

• ✅ After security architecture changes
• ✅ When new threats identified
• ✅ During compliance audits
• ✅ For security onboarding
• ✅ Before major releases

Required Security Documents

1. SECURITY.md (Required)

# Security Policy

## Supported Versions

| Version | Supported          |
| ------- | ------------------ |
| 2.x.x   | :white_check_mark: |
| 1.x.x   | :x:                |

## Reporting a Vulnerability

**DO NOT** create public GitHub issues for security vulnerabilities.

Email: security@hack23.com
PGP Key: [Link to public key]

Expected response time: 48 hours

2. SECURITY_ARCHITECTURE.md (Required)

# Security Architecture

## Authentication & Authorization

### Authentication Flow
\`\`\`
User → Login Form → Spring Security → BCrypt Verification → JWT Token → Access Granted
\`\`\`

### Authorization Model
- Role-Based Access Control (RBAC)
- Roles: GUEST, USER, ADMIN
- Method-level security with @PreAuthorize

## Data Protection

### Encryption
- At Rest: AES-256-GCM for sensitive fields
- In Transit: TLS 1.3 with strong cipher suites

### Data Classification
| Level | Examples | Protection |
|-------|----------|------------|
| Public | Politician names, party | No encryption |
| Internal | Analysis reports | Access control |
| Confidential | Personal IDs | Encrypted, audit logged |
| Restricted | API keys, passwords | Secrets manager |

## Network Security

### Architecture Diagram
\`\`\`
Internet → CloudFlare WAF → Load Balancer → App Servers (Private Subnet) → Database (Private Subnet)
\`\`\`

### Security Controls
- WAF: OWASP ModSecurity rules
- Rate Limiting: 100 req/minute per IP
- DDoS Protection: CloudFlare
- Network Segmentation: VPC with private subnets

3. THREAT_MODEL.md (Required)

# Threat Model

## Assets
1. User credentials
2. Politician personal data
3. Voting records
4. API keys for external services

## Threat Actors
- **External Attackers**: Unauthorized access, data theft
- **Malicious Insiders**: Privilege abuse
- **Nation States**: APT, espionage

## STRIDE Analysis

### Spoofing
- **Threat**: Attacker impersonates legitimate user
- **Mitigation**: MFA, strong password policy, rate limiting

### Tampering
- **Threat**: Modification of voting records
- **Mitigation**: Data integrity checks, audit logging, database triggers

[... Continue for all STRIDE categories]

## Attack Trees

\`\`\`
Goal: Compromise Politician Data
├─ Exploit Authentication
│  ├─ Brute Force [Mitigated: Rate limiting]
│  └─ Session Hijacking [Mitigated: Secure cookies]
└─ Exploit Authorization
   └─ Privilege Escalation [Mitigated: RBAC]
\`\`\`

4. DATA_MODEL.md (Existing, ensure security section)

# Data Model

## Security Considerations

### Encrypted Fields
- `politician.personal_id_encrypted` - AES-256-GCM
- `user.password_hash` - bcrypt (cost factor 12)

### Audit Logging
All changes to these tables are audited:
- `politician`
- `voting_record`
- `user`
- `system_configuration`

5. INCIDENT_RESPONSE.md (Required)

# Incident Response Plan

## Severity Classification

| Severity | Criteria | Response Time |
|----------|----------|---------------|
| Critical | Data breach, system compromise | 1 hour |
| High | Authentication bypass | 4 hours |
| Medium | DoS attack | 24 hours |
| Low | Minor configuration issue | 1 week |

## Response Phases

1. **Detection & Analysis**
   - Monitor alerts
   - Classify severity
   - Assemble response team

2. **Containment**
   - Isolate affected systems
   - Revoke compromised credentials
   - Enable additional logging

3. **Eradication**
   - Remove malware/backdoors
   - Patch vulnerabilities
   - Reset credentials

4. **Recovery**
   - Restore from backups
   - Verify system integrity
   - Gradual service restoration

5. **Post-Incident**
   - Root cause analysis
   - Update controls
   - Document lessons learned

6. VULNERABILITY_MANAGEMENT.md (Required)

# Vulnerability Management

## Vulnerability Classification

| CVSS Score | Severity | SLA |
|------------|----------|-----|
| 9.0-10.0 | Critical | 7 days |
| 7.0-8.9 | High | 30 days |
| 4.0-6.9 | Medium | 90 days |
| 0.1-3.9 | Low | 180 days |

## Scanning Schedule

- **Daily**: Automated dependency scans (OWASP Dependency Check)
- **Weekly**: CodeQL SAST scans
- **Monthly**: Full penetration testing
- **Quarterly**: External security assessment

## Remediation Process

1. Vulnerability identified
2. Risk assessment
3. Prioritization
4. Patch/fix development
5. Testing
6. Deployment
7. Verification
8. Documentation

7. ACCESS_CONTROL_MATRIX.md (Required)

# Access Control Matrix

| Resource | Guest | User | Admin |
|----------|-------|------|-------|
| View public politician data | ✅ | ✅ | ✅ |
| View confidential data | ❌ | ❌ | ✅ |
| Create user account | ✅ | ❌ | ✅ |
| Modify user account | ❌ | Own | All |
| Delete user account | ❌ | Own | All |
| System configuration | ❌ | ❌ | ✅ |
| View audit logs | ❌ | ❌ | ✅ |

Documentation Standards

Markdown Format

• Use GitHub-Flavored Markdown
• Include table of contents for long documents
• Use code fences with language identifiers
• Add diagrams using Mermaid or ASCII art

Diagrams

graph LR
    A[User] -->|HTTPS| B[Load Balancer]
    B --> C[App Server 1]
    B --> D[App Server 2]
    C --> E[PostgreSQL Primary]
    D --> E
    E --> F[PostgreSQL Replica]

Update Frequency

Document	Update Trigger	Review Frequency
SECURITY.md	CVE published	Quarterly
SECURITY_ARCHITECTURE.md	Architecture change	Per release
THREAT_MODEL.md	New threat identified	Annually
INCIDENT_RESPONSE.md	Post-incident	After incidents

Documentation Checklist

Before marking security documentation complete:

• ✅ All required documents exist
• ✅ Documents are up-to-date (< 90 days old)
• ✅ Diagrams reflect current architecture
• ✅ Contact information is current
• ✅ Links work (no 404s)
• ✅ Code examples compile/run
• ✅ Reviewed by security team
• ✅ Approved by CISO/security officer

Hack23 ISMS Policy References

Security Documentation Framework:

• Secure Development Policy - Required architecture documentation portfolio
• Information Security Policy - Documentation requirements (ISO 27001 A.5.10)
• ISMS Transparency Plan - Public security posture documentation
• Threat Modeling - Threat model documentation requirements
• Incident Response Plan - Incident procedures documentation (ISO 27001 A.16.1)
• Change Management - Change documentation requirements
• CLASSIFICATION.md - Documentation classification requirements

All Hack23 ISMS Policies: https://github.com/Hack23/ISMS-PUBLIC

CIA Platform Documentation Examples

Current State Architecture:

• Security Architecture: CIA SECURITY_ARCHITECTURE.md - Complete security controls
• Threat Model: CIA THREAT_MODEL.md - STRIDE analysis
• Architecture: CIA ARCHITECTURE.md - C4 models
• Data Model: CIA DATA_MODEL.md - Database schema
• Flowchart: CIA FLOWCHART.md - Process flows
• SWOT: CIA SWOT.md - Strategic analysis

Future State Architecture:

• Future Security: CIA FUTURE_SECURITY_ARCHITECTURE.md
• Future Architecture: CIA FUTURE_ARCHITECTURE.md

References

• ISO 27001:2022 A.5.10: Information security policies documented
• ISO 27001:2022 A.16.1: Incident management procedures documented
• NIST CSF ID.GV-1: Cybersecurity policy established
• NIST SP 800-53 SA-5: System documentation requirements
• CIS Control 1.4: Maintain detailed asset inventory documentation