Free Cryptographic Management Policy Builder

1. Purpose

This policy establishes requirements for the use of cryptographic controls to protect sensitive data. The goal is to ensure that appropriate encryption algorithms, key management practices, and cryptographic standards are implemented to protect data confidentiality, integrity, and authenticity in accordance with SOC 2 and industry best practices.

2. Scope

Applies to all systems, applications, databases, and infrastructure that store, process, or transmit restricted or confidential data. Includes encryption of data at rest and in transit, cryptographic key lifecycle management, digital certificates, API keys, and authentication credentials. Covers all personnel who configure encryption, manage keys, or implement cryptographic controls.

3. Roles

• Chief Security Officer (CSO) – owns this policy, approves cryptographic standards, oversees key management program
• Security Team – maintains cryptographic standards, reviews encryption implementations, manages key management systems
• Infrastructure Team – implements encryption for infrastructure, manages TLS certificates, configures encryption at rest
• Engineering Teams – implements application-level encryption, manages API keys and secrets, follows secure coding practices
• Key Management Administrator – operates key management systems, performs key rotations, manages access to cryptographic material

4. Core Principles

• Encrypt sensitive data – all restricted and confidential data must be encrypted at rest and in transit
• Use strong algorithms – only approved, industry-standard cryptographic algorithms are permitted
• Protect keys properly – cryptographic keys must be stored securely and accessed only by authorized systems and personnel
• Rotate regularly – keys and certificates must be rotated according to defined schedules
• Never hardcode secrets – no cryptographic material in source code or configuration files

5. Encryption Requirements

5.1 Data Classification

Encryption requirements are based on data classification (reference: Data Classification Policy):

• Restricted Data: MUST be encrypted at rest and in transit (e.g., customer PII, payment card data, health information, authentication credentials)
• Confidential Data: MUST be encrypted in transit, SHOULD be encrypted at rest (e.g., business-sensitive information, internal communications)
• Internal Data: SHOULD be encrypted in transit (e.g., internal documentation, non-sensitive business data)
• Public Data: No encryption requirements (e.g., marketing materials, public documentation)

5.2 Encryption of Data at Rest

Mandatory for:

• Production databases containing customer data or PII
• File storage systems (S3, Azure Blob Storage, Google Cloud Storage) containing restricted data
• Backup and archive storage
• Employee laptops and mobile devices
• Database backups and snapshots
• Log files containing sensitive information

Implementation Requirements:

• Use AES-256 encryption or stronger
• Leverage cloud provider managed encryption (AWS KMS, Azure Key Vault, GCP KMS) where available
• Enable full disk encryption on all endpoints (BitLocker, FileVault, LUKS)
• Encrypt database tablespaces and file systems containing sensitive data
• Document encryption status in asset inventory

5.3 Encryption of Data in Transit

Mandatory for:

• All external API endpoints and web applications
• Database connections from applications
• Internal service-to-service communication involving restricted data
• VPN connections and remote access
• Email transmission of sensitive information
• File transfers containing restricted data

Implementation Requirements:

• TLS Version: TLS 1.2 minimum, TLS 1.3 preferred. TLS 1.0 and 1.1 are prohibited.
• Cipher Suites: Use only strong cipher suites with forward secrecy (e.g., ECDHE-RSA-AES256-GCM-SHA384)
• Certificate Requirements: Use certificates from trusted Certificate Authorities (CA). No self-signed certificates in production.
• Certificate Key Size: Minimum 2048-bit RSA or 256-bit ECC
• HTTPS Everywhere: All web applications must redirect HTTP to HTTPS
• HSTS: Enable HTTP Strict Transport Security headers
• Database Connections: Use TLS/SSL for all database connections (RDS with SSL, MongoDB with TLS)

6. Approved Cryptographic Algorithms

6.1 Symmetric Encryption

Approved:

• AES-256 (preferred)
• AES-192
• AES-128 (minimum acceptable)
• ChaCha20-Poly1305

Prohibited: DES, 3DES, RC4, Blowfish

6.2 Asymmetric Encryption

Approved:

• RSA 2048-bit minimum (4096-bit preferred)
• Elliptic Curve Cryptography (ECC) 256-bit minimum (P-256, P-384, P-521)
• Ed25519 (for SSH keys and signing)

Prohibited: RSA 1024-bit or less, DSA

6.3 Hashing Algorithms

Approved:

• SHA-256 (minimum)
• SHA-384
• SHA-512
• SHA-3 family
• BLAKE2

For Password Hashing: bcrypt (cost factor ≥12), Argon2id, scrypt, PBKDF2 with SHA-256 (100,000+ iterations)

Prohibited: MD5, SHA-1, plain text password storage

6.4 Message Authentication Codes (MAC)

Approved:

• HMAC-SHA256
• HMAC-SHA384
• HMAC-SHA512
• Poly1305 (when used with ChaCha20)

7. Cryptographic Key Management

7.1 Key Generation

• Keys must be generated using cryptographically secure random number generators (CSRNG)
• Use cloud provider key management services (AWS KMS, Azure Key Vault, GCP KMS) for infrastructure keys
• Application-level keys generated using approved libraries (OpenSSL, crypto libraries)
• Minimum key lengths: AES-256, RSA-2048, ECC-256
• Document key generation method and parameters

7.2 Key Storage

• Cloud Infrastructure: Use AWS KMS, Azure Key Vault, GCP KMS, or HashiCorp Vault
• Application Secrets: Use secrets management systems (AWS Secrets Manager, HashiCorp Vault, Kubernetes Secrets with encryption)
• Never store keys in: Source code, configuration files, environment variables (without secrets manager), plain text files, logs
• Hardware Security Modules (HSM): Required for payment processing keys and other high-value cryptographic material
• Encryption of Keys: Keys at rest must be encrypted using key encryption keys (KEK) or master keys

7.3 Key Access Control

• Access to key management systems restricted to authorized personnel (least privilege)
• Service accounts and applications use role-based access to keys (IAM roles, service principals)
• Implement separation of duties: key administrators cannot be sole developers
• All key access logged and monitored
• Multi-factor authentication required for human access to key management systems
• Quarterly access reviews of key management system permissions

7.4 Key Rotation

Rotation Schedule:

• Data Encryption Keys (DEK): Annually, or immediately upon suspected compromise
• Key Encryption Keys (KEK): Every 2 years, or immediately upon suspected compromise
• TLS/SSL Certificates: 90 days before expiration (automate with Let's Encrypt or cert-manager)
• API Keys: Annually, or immediately upon suspected compromise
• SSH Keys: Annually, or immediately upon user role change/termination
• Database Credentials: Every 90 days, or immediately upon personnel changes
• Service Account Keys: Every 90 days

Rotation Procedures:

• Automated rotation preferred (AWS KMS automatic rotation, certificate automation)
• Maintain rotation schedules in key management system
• Alert 30 days before certificate expiration
• Document all manual key rotations in change management system
• Test rotation procedures in non-production environments first
• Maintain previous key versions for decryption of older data (grace period)

7.5 Key Compromise Procedures

If key compromise is suspected or confirmed:

• Immediately revoke compromised key and generate new key
• Trigger incident response process (reference: Incident Response Plan)
• Assess scope of potential data exposure
• Re-encrypt all data protected by compromised key
• Review access logs to identify unauthorized key usage
• Document incident and lessons learned
• Notify affected parties if required by regulations

7.6 Key Destruction

• Keys must be securely destroyed when no longer needed
• Use cryptographic erasure or secure deletion methods
• Document key destruction date and method
• Retain keys only as long as needed for data recovery or compliance retention
• Ensure all copies of keys are destroyed (backups, caches, replicas)

8. Certificate Management

8.1 Certificate Lifecycle

• Certificate Authority: Use trusted public CAs (Let's Encrypt, DigiCert, GlobalSign) for external-facing systems
• Certificate Validity: Maximum 90-day validity preferred (automated renewal), 1-year maximum
• Certificate Inventory: Maintain inventory of all certificates in use (automated discovery tools recommended)
• Certificate Monitoring: Alert 30 days before expiration, alert again at 15 days and 7 days
• Wildcard Certificates: Avoid where possible; use specific domain certificates or SAN certificates

8.2 Certificate Automation

• Automate certificate issuance and renewal (Let's Encrypt with certbot, cert-manager for Kubernetes)
• Use Infrastructure as Code to manage certificate deployment
• Implement automated testing to verify certificate validity
• Configure automatic certificate rotation for load balancers and CDNs

8.3 Certificate Revocation

• Revoke certificates immediately upon key compromise or system decommissioning
• Revoke certificates when employee with access to private key leaves organization
• Monitor Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP)

9. Secrets Management

9.1 Secrets Management Tools

Approved Tools:

• AWS Secrets Manager (for AWS infrastructure)
• Azure Key Vault (for Azure infrastructure)
• GCP Secret Manager (for GCP infrastructure)
• HashiCorp Vault (for multi-cloud or hybrid environments)
• Kubernetes Secrets (with encryption at rest enabled)

9.2 Secret Types

• API Keys: Third-party API keys for external services (Stripe, SendGrid, etc.)
• Database Credentials: Connection strings, usernames, passwords for databases
• Service Account Credentials: OAuth tokens, service account keys, IAM credentials
• Encryption Keys: Application-level encryption keys
• SSH Keys: Private keys for server access
• JWT Signing Keys: Keys for signing and verifying JSON Web Tokens

9.3 Secret Handling Requirements

• Never commit secrets to version control: Use .gitignore, pre-commit hooks, and secret scanning tools (GitHub secret scanning, GitGuardian, TruffleHog)
• Never log secrets: Redact or mask secrets in application logs, error messages, and debug output
• Never expose secrets in URLs: Use request headers or body for authentication credentials
• Never store secrets in environment variables directly: Use secrets management systems that inject secrets at runtime
• Rotate immediately after exposure: Any secret accidentally committed or logged must be rotated immediately

10. Algorithm and Protocol Review

• Security Team reviews approved algorithm list annually
• Deprecate algorithms when vulnerabilities are discovered or industry standards change
• Monitor NIST recommendations and security bulletins for cryptographic algorithm guidance
• Plan migration away from deprecated algorithms with sufficient lead time
• Document algorithm selection rationale for auditors

11. Compliance and Auditing

11.1 Encryption Verification

• Quarterly scans to verify encryption is enabled on all databases and storage containing sensitive data
• Quarterly TLS/SSL configuration testing (SSL Labs, testssl.sh)
• Automated monitoring for expired or expiring certificates
• Code reviews to verify proper cryptographic implementation

11.2 Key Management Auditing

• All key access logged with timestamp, principal, and action
• Quarterly review of key management system access logs
• Annual review of key rotation compliance
• Document all key generation, rotation, and destruction activities

11.3 Secret Scanning

• Enable GitHub secret scanning on all repositories
• Implement pre-commit hooks to prevent secret commits (git-secrets, detect-secrets)
• Regular scans of historical commits for secrets (TruffleHog, GitGuardian)
• Immediate revocation and rotation upon secret detection

12. Training Requirements

• All engineers complete secure coding training including cryptography best practices during onboarding
• Annual security training includes section on proper handling of cryptographic material
• Security Team receives specialized training on cryptographic standards and key management
• Training on secrets management tools for teams deploying applications

13. Exceptions

Exceptions to this policy require Chief Security Officer approval with documented business justification, risk assessment, compensating controls, and timeline for remediation. Exceptions must be reviewed quarterly and removed when no longer necessary.

14. Enforcement

Violations of this policy, including storing secrets in code, using weak encryption, or failing to rotate keys as required, may result in revocation of system access and management review. Intentional circumvention of cryptographic controls is grounds for termination.

15. References

• SOC 2 – Confidentiality and Encryption Controls
• NIST Special Publication 800-175B – Guideline for Using Cryptographic Standards
• NIST Special Publication 800-57 – Recommendation for Key Management
• [Your Company] Data Classification Policy
• [Your Company] Access Management Policy
• [Your Company] Information Security Policy

16. Revision History

Date	Version	Author	Description
[Date]	1.0	Chief Security Officer	Initial release