d-bis/the_order
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: comprehensive project structure improvements and Cloud for Sovereignty landing zone

Browse Source 
- Add Cloud for Sovereignty landing zone architecture and deployment
- Implement complete legal document management system
- Reorganize documentation with improved navigation
- Add infrastructure improvements (Dockerfiles, K8s, monitoring)
- Add operational improvements (graceful shutdown, rate limiting, caching)
- Create comprehensive project structure documentation
- Add Azure deployment automation scripts
- Improve repository navigation and organization
This commit is contained in:
defiQUG
2025-11-13 09:32:55 -08:00
parent 92cc41d26d
commit 6a8582e54d
202 changed files with 22699 additions and 981 deletions
Download Patch File Download Diff File Expand all files Collapse all files

280
docs/governance/frameworks/privacy.md Normal file
View File

@@ -0,0 +1,280 @@
# Privacy & Data Governance Pack
**Version:** 1.0
**Date:** November 10, 2025
**Status:** Draft
---
## Overview
This document provides the privacy and data governance framework for the DSB, including Privacy Policy, Data Protection Impact Assessment (DPIA), Data Processing Agreements (DPAs), Records of Processing Activities (ROPA), and Retention & Deletion Schedules.
## Privacy Policy
### Principles
**Data Minimization:**
* Collect only necessary data
* Limit data collection scope
* Regular data audits
* Purge unnecessary data
**Purpose Limitation:**
* Clear purpose statements
* No secondary use without consent
* Regular purpose reviews
* Consent management
**Transparency:**
* Clear privacy notices
* Accessible policies
* Regular updates
* User notifications
**Accountability:**
* Data protection officer
* Regular audits
* Compliance monitoring
* Incident reporting
### Lawful Bases
**Consent:**
* Explicit consent for sensitive data
* Withdrawable consent
* Consent management
* Consent records
**Legal Obligation:**
* KYC/AML requirements
* Sanctions screening
* Regulatory reporting
* Court orders
**Legitimate Interests:**
* Fraud prevention
* Security measures
* Service improvement
* Analytics (anonymized)
**Public Task:**
* Governance functions
* Administrative tasks
* Public safety
* Regulatory compliance
## Data Protection Impact Assessment (DPIA)
### Scope
**Assessments:**
* Identity verification
* Credential issuance
* KYC/AML screening
* Sanctions screening
* Member registry
* Appeals process
### Risk Assessment
**Risks:**
* Data breaches
* Unauthorized access
* Data loss
* Privacy violations
* Discrimination
**Mitigations:**
* Encryption
* Access controls
* Audit logging
* Data minimization
* Regular reviews
### Residual Risk
**Rating:**
* Low: Acceptable with standard controls
* Medium: Acceptable with enhanced controls
* High: Requires additional mitigation
* Critical: Cannot proceed without mitigation
## Data Processing Agreements (DPAs)
### Third-Party Processors
**Providers:**
* KYC providers (Veriff)
* Sanctions providers (ComplyAdvantage)
* Cloud providers (AWS, Azure)
* Email/SMS providers
* Analytics providers
### Requirements
**DPA Elements:**
* Purpose and scope
* Data types
* Security measures
* Sub-processors
* Data location
* Retention periods
* Deletion procedures
* Audit rights
* Breach notification
* Liability
## Records of Processing Activities (ROPA)
### Activities
**Identity Verification:**
* Purpose: Identity verification
* Data: Name, DOB, nationality, documents, selfie
* Lawful basis: Legal obligation, consent
* Retention: 365 days (KYC artifacts), 6 years (metadata)
**Credential Issuance:**
* Purpose: Credential issuance
* Data: Credential data, proof, status
* Lawful basis: Contract, legal obligation
* Retention: Indefinite (credential status), 6 years (metadata)
**KYC/AML Screening:**
* Purpose: Compliance screening
* Data: Identity data, screening results
* Lawful basis: Legal obligation
* Retention: 365 days (artifacts), 6 years (results)
**Member Registry:**
* Purpose: Member management
* Data: Member data, status, history
* Lawful basis: Contract, legitimate interests
* Retention: Indefinite (active members), 6 years (inactive)
## Retention & Deletion Schedules
### Retention Periods
**KYC Artifacts:**
* Raw documents: 365 days
* Processed data: 6 years
* Audit logs: 7 years
**Application Data:**
* Application metadata: 6 years
* Decisions: 6 years
* Appeals: 6 years
**Credential Data:**
* Credential status: Indefinite
* Credential metadata: 6 years
* Audit logs: 7 years
**Member Data:**
* Active members: Indefinite
* Inactive members: 6 years after inactivity
* Revoked members: 6 years after revocation
### Deletion Procedures
**Process:**
1. Identify data for deletion
2. Verify retention period expired
3. Backup if required
4. Delete data
5. Verify deletion
6. Update records
7. Audit log
**Methods:**
* Secure deletion
* Cryptographic erasure
* Physical destruction (if applicable)
* Verification and audit
## Individual Rights
### Right to Access
**Process:**
1. Request received
2. Identity verification
3. Data retrieval
4. Response (within 30 days)
5. Data provision
### Right to Rectification
**Process:**
1. Request received
2. Identity verification
3. Data verification
4. Correction
5. Notification
6. Update systems
### Right to Erasure
**Process:**
1. Request received
2. Identity verification
3. Eligibility check
4. Data deletion
5. Verification
6. Notification
### Right to Portability
**Process:**
1. Request received
2. Identity verification
3. Data extraction
4. Format conversion
5. Secure delivery
## Data Breach Response
### Incident Classification
**Personal Data Breach:**
* Unauthorized access
* Data loss
* Data alteration
* Unauthorized disclosure
### Response Process
1. Immediate containment
2. Impact assessment
3. Notification (if required)
4. Remediation
5. Post-incident review
6. Documentation
### Notification
**Requirements:**
* Supervisory authority: 72 hours
* Affected individuals: Without undue delay
* Content: Nature, impact, measures, advice
---
## Revision History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2025-11-10 | Chancellor | Initial draft |
---
## Approval
**Data Protection Officer:** _________________ Date: _________
**Chancellor:** _________________ Date: _________
**Founding Council:** _________________ Date: _________

278
docs/governance/frameworks/threat-model.md Normal file
View File

@@ -0,0 +1,278 @@
# Threat Model
## Overview
This document outlines the threat model for The Order monorepo, identifying potential threats, attack vectors, and mitigation strategies.
## System Architecture
### Components
- **Identity Service**: Verifiable credential issuance and verification
- **Intake Service**: Document ingestion and processing
- **Finance Service**: Payment processing and ledger management
- **Dataroom Service**: Secure document storage and access
- **Database**: PostgreSQL for data persistence
- **Storage**: S3/GCS for object storage
- **KMS**: Key management for cryptographic operations
- **Cache**: Redis for caching
- **Message Queue**: Background job processing
- **Event Bus**: Event-driven communication
### Data Flow
1. User authentication (JWT/DID/eIDAS)
2. Document upload and processing
3. Verifiable credential issuance
4. Payment processing
5. Document storage and access
6. Audit logging
## Threat Categories
### 1. Authentication & Authorization Threats
#### Threat: Unauthorized Access
- **Description**: Attackers gain access to system without proper authentication
- **Attack Vectors**:
- Stolen credentials
- Weak authentication mechanisms
- Session hijacking
- Token theft
- **Impact**: High - Unauthorized access to sensitive data and operations
- **Mitigation**:
- Strong authentication (MFA, OAuth2/OIDC)
- Secure token storage and transmission
- Session management with timeouts
- Rate limiting on authentication endpoints
- Audit logging of authentication events
#### Threat: Privilege Escalation
- **Description**: Users gain access to resources beyond their authorization
- **Attack Vectors**:
- Role manipulation
- Authorization bypass
- Missing access controls
- **Impact**: High - Unauthorized access to sensitive operations
- **Mitigation**:
- Role-based access control (RBAC)
- Principle of least privilege
- Regular access reviews
- Authorization checks on all endpoints
- Multi-signature requirements for critical operations
### 2. Data Protection Threats
#### Threat: Data Breach
- **Description**: Unauthorized access to sensitive data
- **Attack Vectors**:
- Database injection attacks
- Unencrypted data storage
- Insecure data transmission
- Insider threats
- **Impact**: Critical - Exposure of sensitive data
- **Mitigation**:
- Encryption at rest and in transit
- Database access controls
- Data masking in non-production
- Regular security audits
- Access logging and monitoring
#### Threat: Data Tampering
- **Description**: Unauthorized modification of data
- **Attack Vectors**:
- SQL injection
- Man-in-the-middle attacks
- Insider threats
- **Impact**: High - Data integrity compromise
- **Mitigation**:
- Input validation and sanitization
- Parameterized queries
- Digital signatures for critical data
- Audit logging
- Immutable storage (WORM) for critical documents
### 3. Cryptographic Threats
#### Threat: Weak Cryptography
- **Description**: Use of weak cryptographic algorithms or keys
- **Attack Vectors**:
- Weak encryption algorithms
- Insufficient key length
- Poor key management
- Cryptographic implementation flaws
- **Impact**: Critical - Compromise of cryptographic security
- **Mitigation**:
- Strong encryption algorithms (AES-256, RSA-2048+)
- Secure key management (KMS/HSM)
- Key rotation policies
- Cryptographic library updates
- Regular security audits
#### Threat: Key Compromise
- **Description**: Unauthorized access to cryptographic keys
- **Attack Vectors**:
- Key theft
- Weak key storage
- Key exposure in logs or errors
- **Impact**: Critical - Complete system compromise
- **Mitigation**:
- Hardware Security Modules (HSM)
- Key rotation policies
- Secure key storage (AWS KMS, Azure Key Vault)
- Access controls on key operations
- Audit logging of key usage
### 4. API Security Threats
#### Threat: API Abuse
- **Description**: Unauthorized or excessive API usage
- **Attack Vectors**:
- Rate limiting bypass
- API key theft
- DDoS attacks
- Automated scraping
- **Impact**: Medium - Service disruption, resource exhaustion
- **Mitigation**:
- Rate limiting
- API authentication
- Request validation
- DDoS protection
- Monitoring and alerting
#### Threat: Injection Attacks
- **Description**: Malicious code injection through API inputs
- **Attack Vectors**:
- SQL injection
- NoSQL injection
- Command injection
- LDAP injection
- **Impact**: High - Data breach, system compromise
- **Mitigation**:
- Input validation and sanitization
- Parameterized queries
- Output encoding
- Least privilege access
- Security testing
### 5. Infrastructure Threats
#### Threat: Container Vulnerabilities
- **Description**: Vulnerabilities in container images or runtime
- **Attack Vectors**:
- Vulnerable base images
- Misconfigured containers
- Container escape
- **Impact**: High - System compromise
- **Mitigation**:
- Container image scanning
- Image signing (Cosign)
- SBOM generation
- Regular updates
- Security best practices
#### Threat: Supply Chain Attacks
- **Description**: Compromise through third-party dependencies
- **Attack Vectors**:
- Malicious packages
- Compromised dependencies
- Typosquatting
- **Impact**: High - System compromise
- **Mitigation**:
- Dependency scanning
- Package verification
- SBOM tracking
- Regular updates
- Supply chain security monitoring
### 6. Compliance & Legal Threats
#### Threat: Non-Compliance
- **Description**: Failure to meet regulatory requirements
- **Attack Vectors**:
- GDPR violations
- eIDAS non-compliance
- Data retention issues
- **Impact**: High - Legal and financial consequences
- **Mitigation**:
- Compliance audits
- Regulatory monitoring
- Data protection measures
- Privacy policies
- Legal review
## Attack Scenarios
### Scenario 1: Credential Theft
1. Attacker steals JWT token from compromised client
2. Attacker uses token to access API endpoints
3. Attacker issues fraudulent verifiable credentials
4. **Mitigation**: Token expiration, refresh tokens, MFA, audit logging
### Scenario 2: Database Injection
1. Attacker sends malicious SQL in API request
2. Database executes malicious query
3. Attacker extracts sensitive data
4. **Mitigation**: Parameterized queries, input validation, least privilege
### Scenario 3: Key Compromise
1. Attacker gains access to KMS key
2. Attacker decrypts sensitive data
3. Attacker signs fraudulent credentials
4. **Mitigation**: HSM, key rotation, access controls, audit logging
### Scenario 4: DDoS Attack
1. Attacker floods API with requests
2. Service becomes unavailable
3. Legitimate users cannot access service
4. **Mitigation**: Rate limiting, DDoS protection, auto-scaling, monitoring
## Risk Assessment
### Risk Matrix
| Threat | Likelihood | Impact | Risk Level | Priority |
|--------|-----------|--------|------------|----------|
| Data Breach | Medium | Critical | High | 1 |
| Key Compromise | Low | Critical | High | 2 |
| Unauthorized Access | Medium | High | High | 3 |
| API Abuse | High | Medium | Medium | 4 |
| Injection Attacks | Medium | High | High | 5 |
| Container Vulnerabilities | Medium | High | High | 6 |
| Supply Chain Attacks | Low | High | Medium | 7 |
| Non-Compliance | Low | High | Medium | 8 |
## Mitigation Strategies
### Immediate Actions
1. Implement comprehensive input validation
2. Enable encryption at rest and in transit
3. Set up security monitoring and alerting
4. Conduct security code review
5. Implement rate limiting
### Short-term Actions (1-3 months)
1. Conduct penetration testing
2. Implement MFA for critical operations
3. Set up automated security scanning
4. Create incident response plan
5. Conduct security training
### Long-term Actions (3-6 months)
1. Implement HSM for key management
2. Conduct comprehensive security audit
3. Establish bug bounty program
4. Implement advanced threat detection
5. Regular security assessments
## Review Schedule
- **Monthly**: Threat model review, security updates
- **Quarterly**: Comprehensive security audit
- **Annually**: Penetration testing, compliance audit
- **As needed**: New features, security incidents, major changes
## References
- [OWASP Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
- [STRIDE Threat Model](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats)
- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)

214
docs/governance/frameworks/trust-framework.md Normal file
View File

@@ -0,0 +1,214 @@
# Trust Framework Policy (TFP)
**Version:** 1.0
**Date:** November 10, 2025
**Status:** Draft
---
## Overview
This Trust Framework Policy (TFP) defines the trust posture, Levels of Assurance (LOA), and assurance events for the Decentralized Sovereign Body (DSB) identity system.
## Trust Posture
The DSB operates as an **Assured Identity Provider** with defined Levels of Assurance (LOA 1-3) and assurance events (onboard, renew, recover).
## Levels of Assurance (LOA)
### LOA 1 - Basic Identity Verification
**Description:** Basic identity verification with minimal evidence requirements.
**Requirements:**
* Email verification
* Self-declared identity information
* Optional: Social media verification
**Use Cases:**
* Honorary membership
* Basic service access
* Community participation
**Evidence:**
* Email verification
* Self-declared information
### LOA 2 - Enhanced Identity Verification
**Description:** Enhanced identity verification with document check and liveness verification.
**Requirements:**
* Government-issued identity document (passport, national ID, driver's license)
* Document authenticity verification
* Liveness check (selfie with document)
* Sanctions screening
* PEP screening
**Use Cases:**
* eResidency
* Service roles
* Professional orders
**Evidence:**
* Document verification
* Liveness check
* Sanctions screen
* Address attestation (optional)
### LOA 3 - Highest Level Verification
**Description:** Highest level verification with in-person or video interview.
**Requirements:**
* All LOA 2 requirements
* Video interview with trained interviewer
* Multi-source corroboration
* Background attestations
* Oath ceremony
* Service contribution verification
**Use Cases:**
* eCitizenship
* Governance roles
* Public offices
* Honors
**Evidence:**
* Video interview
* Sponsorship
* Residency tenure
* Background attestations
* Oath ceremony
## Assurance Events
### Onboarding
**Process:**
1. Application submission
2. Identity verification (LOA-appropriate)
3. KYC/AML screening
4. Risk assessment
5. Approval/rejection
6. Credential issuance
**Timeline:**
* LOA 1: < 24 hours
* LOA 2: < 48 hours (median)
* LOA 3: < 7 days
### Renewal
**Process:**
1. Renewal application
2. Identity re-verification (LOA-appropriate)
3. Status check (good standing, compliance)
4. Credential renewal
**Timeline:**
* LOA 1: < 24 hours
* LOA 2: < 48 hours
* LOA 3: < 7 days
### Recovery
**Process:**
1. Recovery request
2. Identity verification
3. Security checks
4. Credential recovery or re-issuance
**Timeline:**
* LOA 1: < 24 hours
* LOA 2: < 48 hours
* LOA 3: < 7 days
## Incident Handling
### Security Incidents
**Classification:**
* **Critical:** Key compromise, data breach, systemic fraud
* **High:** Individual credential compromise, unauthorized access
* **Medium:** Suspicious activity, policy violations
* **Low:** Minor issues, false positives
**Response:**
1. Immediate containment
2. Investigation
3. Remediation
4. Notification (if required)
5. Post-incident review
### Credential Compromise
**Process:**
1. Immediate revocation
2. Investigation
3. Re-issuance (if appropriate)
4. Security enhancements
## Audit
### Internal Audit
**Frequency:** Quarterly
**Scope:**
* Identity verification procedures
* Credential issuance processes
* Security controls
* Compliance with policies
### External Audit
**Frequency:** Annually
**Scope:**
* PKI infrastructure
* Issuance processes
* Privacy compliance
* Security posture
## Compliance
### Privacy
* GDPR compliance
* Data minimization
* Purpose limitation
* Individual rights
### Security
* ISO 27001 alignment
* SOC 2 Type II (future)
* Penetration testing
* Bug bounty program
### Legal
* KYC/AML compliance
* Sanctions screening
* Data protection
* Consumer protection
---
## Revision History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2025-11-10 | CISO | Initial draft |
---
## Approval
**CISO:** _________________ Date: _________
**Founding Council:** _________________ Date: _________
**External Reviewer:** _________________ Date: _________