Skip to content

Latest commit

 

History

History
524 lines (386 loc) · 29.7 KB

File metadata and controls

524 lines (386 loc) · 29.7 KB

Hack23 Logo

🔒 Hack23 AB — Cryptography Policy

🛡️ Encryption Excellence Through Systematic Implementation
🎯 Demonstrating Cryptographic Expertise for Security Consulting

Owner Version Effective Date Review Cycle

📋 Document Owner: CEO | 📄 Version: 1.2 | 📅 Last Updated: 2026-01-25 (UTC)
🔄 Review Cycle: Annual | ⏰ Next Review: 2027-01-25


🎯 Purpose Statement

Hack23 AB's cryptographic implementation demonstrates how systematic encryption practices directly enable both security excellence and business innovation. Our cryptography policy serves as both operational framework and client demonstration of our cybersecurity consulting expertise.

As a cybersecurity consulting company, our approach to cryptography becomes a showcase of professional cryptographic standards, demonstrating to potential clients how proper encryption implementations enable business security without hindering functionality.

Our commitment to transparency means our cryptographic practices become a reference implementation, showing how systematic encryption approaches create competitive advantages through robust security foundations.

— James Pether Sörling, CEO/Founder


🔍 Purpose & Scope

This policy establishes cryptographic standards and procedures for Hack23 AB, ensuring appropriate encryption of data at rest, in transit, and in processing across all systems and applications.

Scope: All systems in Asset Register, data per Data Classification Policy, and supplier services per SUPPLIER.md.


🔒 Mandatory Cryptographic Requirements

MUST HAVE - Encryption at Rest

ISO 27001 A.8.24 NIST CSF 2.0 PR.DS EU CRA

Organizations implementing this policy MUST:

flowchart TD
    subgraph "🔐 Encryption at Rest Requirements"
        EXTREME[Extreme Data<br/>✅ MUST: HSM Encryption]
        HIGH[High Data<br/>✅ MUST: AES-256 CMK]
        STANDARD[Standard Data<br/>✅ MUST: AES-256 Service]
    end
    
    subgraph "🔑 Key Management Requirements"
        KMS[Key Management Service<br/>✅ MUST: Centralized KMS]
        ROTATION[Key Rotation<br/>✅ MUST: Annual minimum]
        BACKUP[Key Backup<br/>✅ MUST: Cross-region]
    end
    
    subgraph "📋 Compliance Gates"
        AUDIT[Audit Logging<br/>✅ MUST: All key operations]
        ACCESS[Access Control<br/>✅ MUST: Least privilege]
        MONITORING[Monitoring<br/>✅ MUST: Real-time alerts]
    end
    
    EXTREME --> KMS
    HIGH --> KMS
    STANDARD --> KMS
    
    KMS --> AUDIT
    ROTATION --> ACCESS
    BACKUP --> MONITORING
    
    style EXTREME fill:#D32F2F
    style HIGH fill:#FFC107
    style STANDARD fill:#4CAF50
Loading

Encryption at Rest Requirements:

  • MUST implement AES-256 encryption for all data storage systems
  • MUST use centralized key management service (AWS KMS or equivalent)
  • MUST enforce customer-managed keys (CMK) for high-classification data
  • MUST implement automated key rotation (annual minimum, quarterly preferred)

MUST HAVE - Encryption in Transit

CIS Control 3.10

Data transmission security implementation MUST:

graph LR
    subgraph "🌐 Transport Layer Requirements"
        TLS13[TLS 1.3 Preferred<br/>✅ MUST: Modern protocols]
        TLS12[TLS 1.2 Minimum<br/>✅ MUST: Legacy support]
        CIPHERS[Strong Ciphers<br/>✅ MUST: AEAD suites only]
    end
    
    subgraph "🔒 Protocol Implementation"
        HTTPS[HTTPS Everywhere<br/>✅ MUST: All web traffic]
        API[API Security<br/>✅ MUST: TLS + signatures]
        EMAIL[Email Encryption<br/>✅ MUST: TLS + S/MIME]
    end
    
    subgraph "📊 Validation Requirements"
        TESTING[Protocol Testing<br/>✅ MUST: Automated validation]
        GRADING[Security Grading<br/>✅ MUST: SSL Labs A+]
        MONITORING[Traffic Monitoring<br/>✅ MUST: Weak cipher detection]
    end
    
    TLS13 --> HTTPS
    TLS12 --> API
    CIPHERS --> EMAIL
    
    HTTPS --> TESTING
    API --> GRADING
    EMAIL --> MONITORING
    
    style TLS13 fill:#4CAF50
    style HTTPS fill:#1565C0
    style TESTING fill:#FFC107
Loading

Transport Security Requirements:

  • MUST implement TLS 1.3 for all new implementations
  • MUST support TLS 1.2 minimum for legacy compatibility
  • MUST use only modern cipher suites with forward secrecy
  • MUST achieve SSL Labs A+ rating for all public endpoints

MUST HAVE - Key Management Framework

ISO 27001 A.8.24 NIS2 Art.21

Cryptographic key management MUST:

sequenceDiagram
    participant GEN as 🔑 Key Generation
    participant STORE as 🏦 Secure Storage
    participant USE as 🔐 Key Usage
    participant ROTATE as 🔄 Key Rotation
    participant DELETE as 🗑️ Secure Deletion
    
    GEN->>STORE: ✅ MUST: HSM generation
    STORE->>USE: ✅ MUST: Least privilege access
    USE->>ROTATE: ✅ MUST: Annual rotation
    ROTATE->>DELETE: ✅ MUST: Secure key destruction
    DELETE->>GEN: ✅ MUST: Audit trail maintained
Loading

Key Management Requirements:

  • MUST generate all cryptographic keys using hardware security modules
  • MUST implement centralized key management with AWS KMS or equivalent
  • MUST enforce role-based access control for all key operations
  • MUST maintain complete audit trails for key lifecycle events

🔒 Cryptographic Standards Framework

🛡️ Approved Encryption Algorithms

NIST Approved FIPS 140-3

Algorithm Type Algorithm Key Size Implementation Status
🔐 Symmetric AES 256-bit AWS KMS Approved
🔑 Asymmetric RSA 4096-bit SSH Keys Legacy Support
🔑 Asymmetric Ed25519 256-bit Preferred Approved
🔍 Hashing SHA-256 256-bit Integrity Approved
🔍 Hashing SHA-3 256-bit Future Approved

Prohibited Algorithms

Security Risk

Deprecated Algorithm Security Issue Replacement Deadline
MD5 Collision SHA-256 Immediate
SHA-1 Collision SHA-256 Immediate
DES/3DES Weak Keys AES-256 Immediate
RC4 Stream Cipher AES-GCM Immediate

🏗️ Implementation Architecture

📊 Encryption by Data Classification

Data Protection

Implementation follows Data Classification Policy requirements:

Classification Level Encryption Requirement Key Management Implementation
Extreme HSM-based AES-256 CloudHSM Hardware Security Module
Very High AES-256 + CMK KMS CMK Customer Managed Keys
High AES-256 encryption KMS Service Service Managed Keys
Moderate Standard encryption S3 SSE Service Default
Low Basic protection Service Default Platform Standard

🌐 Transport Layer Security Implementation

flowchart TB
    subgraph "🌐 Public Internet"
        USERS[Users/Clients<br/>TLS 1.3 Preferred]
        CDN[CloudFront CDN<br/>TLS Termination]
        WAF[AWS WAF<br/>Cipher Suite Filtering]
    end
    
    subgraph "🔒 Application Layer"
        ALB[Application Load Balancer<br/>TLS 1.2+ Only]
        API[API Gateway<br/>Modern Ciphers]
        LAMBDA[Lambda Functions<br/>HTTPS Everywhere]
    end
    
    subgraph "💾 Data Layer"
        RDS[RDS PostgreSQL<br/>Force SSL]
        S3[S3 Buckets<br/>HTTPS Required]
        KMS[KMS Operations<br/>TLS 1.3]
    end
    
    USERS --> CDN
    CDN --> WAF
    WAF --> ALB
    
    ALB --> API
    API --> LAMBDA
    
    LAMBDA --> RDS
    LAMBDA --> S3
    LAMBDA --> KMS
    
    style USERS fill:#1565C0
    style CDN fill:#4CAF50
    style ALB fill:#FF9800
    style RDS fill:#7B1FA2
Loading

🔑 AWS KMS Integration Architecture

AWS Integration

Comprehensive key management per Asset Register AWS services:

AWS Service Encryption Method Key Type Status
S3 Buckets SSE-KMS Customer Managed Active
RDS PostgreSQL Encryption at Rest Customer Managed Active
Lambda Functions Environment Variables Function-specific CMK Active
CloudTrail Logs Log Encryption Service Managed Active
WorkMail Email Encryption Service Managed Active

🛡️ Security Control Framework

🔍 Certificate Management

Certificate Security

Domain certificate management aligned with Network Security Policy:

Domain Certificate Type Issuer Security Features
hack23.com DV SSL ACM Auto Renewal
blacktrigram.com DV SSL ACM CloudWatch Alerts

🔒 Modern Cipher Suite Requirements

Cipher Security

Approved cipher suites for TLS 1.3:

TLS_1_3_Ciphers:
  - TLS_AES_256_GCM_SHA384          # ✅ AEAD with perfect forward secrecy
  - TLS_CHACHA20_POLY1305_SHA256    # ✅ AEAD optimized for mobile
  - TLS_AES_128_GCM_SHA256          # ✅ AEAD acceptable for performance

TLS_1_2_Ciphers:
  - ECDHE-RSA-AES256-GCM-SHA384     # ✅ Forward secrecy + AEAD
  - ECDHE-RSA-AES128-GCM-SHA256     # ✅ Forward secrecy + AEAD
  - ECDHE-RSA-CHACHA20-POLY1305     # ✅ Forward secrecy + AEAD

Prohibited_Ciphers:
  - All non-AEAD ciphers             # ❌ No authentication
  - RC4 family                       # ❌ Stream cipher weakness
  - DES/3DES family                  # ❌ Inadequate key strength

📊 Cryptographic Performance Metrics

🎯 Security Posture KPIs

Security Excellence

Metric Category KPI Target Current Status Framework Badge
🔐 Encryption Coverage Data at Rest 100% Complete ISO 27001 A.8.24
🌐 Transport Security TLS Implementation 100% A+ Rating NIST CSF PR.DS
🔑 Key Management KMS Integration 100% Full Integration CIS Control 3
📋 Algorithm Compliance Approved Algorithms 100% NIST Compliant FIPS 140-3
🔄 Key Rotation Automated Rotation Annual minimum Automated ISO 27001 A.8.24

🔄 Continuous Security Improvement

flowchart LR
    ASSESS[🔍 Crypto Assessment] --> IMPLEMENT[🔒 Algorithm Updates]
    IMPLEMENT --> VALIDATE[✅ Security Validation]
    VALIDATE --> MONITOR[📊 Performance Monitoring]
    MONITOR --> ASSESS
    
    ASSESS --> THREAT[🚨 Threat Intelligence]
    THREAT --> QUANTUM[🔮 Post-Quantum Prep]
    QUANTUM --> IMPLEMENT
    
    style ASSESS fill:#1565C0
    style IMPLEMENT fill:#4CAF50
    style VALIDATE fill:#FF9800
    style MONITOR fill:#7B1FA2
Loading

Business Value Demonstration:

Cost Avoidance Trust Enhancement Compliance Excellence Innovation Enablement


✍️ Code Signing & Commit Verification

GitHub Signing GPG Keys

All code commits and releases MUST be cryptographically signed:

Signing Type Algorithm Key Size Requirement Verification
Git Commits GPG/RSA 4096-bit ✅ MUST sign all commits Verified
Git Tags GPG/RSA 4096-bit ✅ MUST sign all releases GitHub verified badge
SSH Auth Ed25519 256-bit ✅ MUST use for Git operations SSH key fingerprint audit
Maven Artifacts GPG/RSA 4096-bit ✅ MUST sign for Maven Central Sonatype verification

GPG Key Management:

  • ✅ Primary signing key: 4096-bit RSA with 2-year expiration
  • ✅ Subkeys for signing operations (rotate annually)
  • ✅ Private keys protected with strong passphrase (see Password Policy below)
  • ✅ Public keys published to GitHub, keyservers, and Maven Central
  • ✅ Key backup stored in encrypted offline storage

🔑 SSH Key Management

SSH Security

SSH key requirements for infrastructure access:

Use Case Algorithm Key Size Passphrase Rotation
GitHub Access Ed25519 256-bit ✅ Required Annual
AWS EC2 Access Ed25519 256-bit ✅ Required Annual
Server Administration Ed25519 256-bit ✅ Required Annual
Legacy Systems RSA 4096-bit min ✅ Required Annual

SSH Hardening Requirements:

  • MUST disable password authentication on all servers
  • MUST use Ed25519 for new key generation (RSA-4096 for legacy only)
  • MUST protect private keys with strong passphrase
  • MUST use SSH agent with timeout (12 hours maximum)
  • MUST maintain authorized_keys audit trail
  • MUST NOT share SSH keys between systems or personnel

🔐 Password & Secrets Management

Secrets Management Password Policy

Cryptographic Password Requirements:

Password Type Minimum Length Complexity Rotation Storage
Master Passwords 20+ characters High entropy passphrase Annual Hardware token + memory
Service Accounts 32+ characters Random generation 90 days AWS Secrets Manager
API Keys 40+ characters Cryptographic random 90 days AWS Secrets Manager
Database Credentials 32+ characters Random generation 90 days AWS Secrets Manager
Encryption Passphrases 25+ characters High entropy Annual Hardware token

Secrets Management Architecture:

flowchart TB
    subgraph "🔐 Secrets Storage"
        SM[AWS Secrets Manager<br/>Primary secrets store]
        KMS[AWS KMS<br/>Secrets encryption]
        PARAM[SSM Parameter Store<br/>Configuration secrets]
    end
    
    subgraph "🔑 Key Hierarchy"
        MASTER[Master CMK<br/>Secrets Manager CMK]
        APP[Application Keys<br/>Per-service secrets]
        ROTATE[Automatic Rotation<br/>Lambda-based]
    end
    
    subgraph "📋 Audit & Compliance"
        TRAIL[CloudTrail<br/>Access logging]
        ALERT[CloudWatch Alerts<br/>Anomaly detection]
        REVIEW[Quarterly Review<br/>Access audit]
    end
    
    SM --> KMS
    PARAM --> KMS
    KMS --> MASTER
    MASTER --> APP
    APP --> ROTATE
    
    SM --> TRAIL
    TRAIL --> ALERT
    ALERT --> REVIEW
    
    style SM fill:#FF9800
    style KMS fill:#4CAF50
    style MASTER fill:#1565C0
Loading

Prohibited Practices:

  • NEVER store secrets in source code, environment files, or documentation
  • NEVER transmit secrets via unencrypted channels (email, chat, tickets)
  • NEVER reuse passwords across different systems
  • NEVER use predictable or dictionary-based passwords

🚨 Cryptographic Incident Response

Incident Response

Key Compromise Response Procedures:

Incident Type Severity Response Time Immediate Actions
Private Key Exposure Critical <1 hour Revoke key, rotate affected systems, notify stakeholders
Password/Secret Leak High <4 hours Rotate secret, audit access logs, assess exposure scope
Weak Algorithm Detection Medium <24 hours Plan migration, assess risk, implement stronger algorithm
Certificate Expiry Medium <24 hours Renew certificate, validate deployment, test connectivity
HSM/KMS Issue Critical <1 hour Activate backup keys, engage AWS support, incident documentation

Incident Response Steps:

  1. Detection & Triage - Identify scope and severity of cryptographic incident
  2. Containment - Revoke compromised keys/certificates immediately
  3. Eradication - Remove exposure source, rotate all potentially affected secrets
  4. Recovery - Deploy new cryptographic material, validate system functionality
  5. Post-Incident - Document lessons learned, update procedures, enhance monitoring

Notification Requirements:

  • Internal: CEO notified within 1 hour for Critical/High severity
  • External: Per Incident Response Plan requirements
  • Regulatory: GDPR 72-hour notification if personal data potentially affected

🔮 Post-Quantum Cryptography Roadmap

NIST PQC Quantum Ready

NIST Post-Quantum Cryptography Standards (Finalized 2024):

Algorithm Type Standard Use Case Adoption Status
ML-KEM (CRYSTALS-Kyber) Key Encapsulation FIPS 203 Key exchange, TLS Monitoring
ML-DSA (CRYSTALS-Dilithium) Digital Signature FIPS 204 Code signing, certificates Monitoring
SLH-DSA (SPHINCS+) Digital Signature FIPS 205 Long-term signatures Monitoring

Transition Timeline:

  • 2025-2026: Inventory cryptographic assets, monitor AWS/cloud provider PQC support
  • 2027-2028: Hybrid implementations (classical + PQC) for high-value assets
  • 2030+: Full PQC migration per NIST/NSA guidance

Current Actions:

  • ✅ Cryptographic asset inventory maintained in Asset Register
  • ✅ Monitoring AWS KMS PQC roadmap
  • ✅ Algorithm agility designed into key management architecture
  • 🔄 Awaiting cloud provider hybrid TLS support

📚 Related Documents

🎯 Strategic & Governance

🔒 Security Policies

💻 Asset & Development


📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification: Confidentiality: Public
📅 Effective Date: 2026-01-25
⏰ Next Review: 2027-01-25
🎯 Framework Compliance: ISO 27001 NIST CSF 2.0 CIS Controls