Data Encryption Guide for Small Businesses

Encryption at rest protects data stored on devices, servers, databases, and backup media. If a device is lost, stolen, or accessed by an unauthorized party, encrypted data is unreadable without the decryption key. Full-disk encryption: Every device in your organization should have full-disk encryption enabled: - Windows: BitLocker (included in Windows Pro and Enterprise). Enable via Group Policy or Intune. Store recovery keys in Entra ID. - macOS: FileVault (built-in). Enable via MDM profile. Escrow recovery keys to your MDM solution. - Linux: LUKS (Linux Unified Key Setup). Configure during OS installation. - Mobile devices: iOS encrypts by default when a passcode is set. Android supports encryption through device settings or MDM enforcement. Full-disk encryption satisfies most compliance requirements for device-level data protection. Verify enforcement through your MDM solution — conditional access policies can block non-encrypted devices from accessing corporate resources. Database encryption: For databases containing sensitive data: - SQL Server: Transparent Data Encryption (TDE) encrypts the database files at rest. Available in Standard and Enterprise editions. - PostgreSQL: Use pgcrypto extension for column-level encryption or filesystem-level encryption. - Cloud databases: AWS RDS, Azure SQL, and Google Cloud SQL all support encryption at rest by default. Verify it is enabled. - MongoDB: Enable encryption at rest using the WiredTiger storage engine with encryption. Backup encryption: Backups are frequently overlooked in encryption strategies. An unencrypted backup is a complete copy of your sensitive data sitting without protection. Encrypt all backups — local, cloud, and offsite. Use AES-256 encryption and store encryption keys separately from the encrypted backups.

Encryption in transit protects data as it moves between systems — from your users' browsers to your web server, from your application to your database, and from your email server to the recipient. TLS for websites and web applications: All websites and web applications must use HTTPS with TLS 1.2 or TLS 1.3. TLS 1.0 and 1.1 are deprecated and vulnerable. TLS configuration best practices: - Minimum version: TLS 1.2. Prefer TLS 1.3 where supported. - Disable: SSLv2, SSLv3, TLS 1.0, and TLS 1.1. - Cipher suites: Use strong cipher suites only. Prefer AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Disable RC4, DES, 3DES, and export ciphers. - Certificate: Use 2048-bit RSA or P-256 ECDSA certificates from a trusted Certificate Authority. Renew certificates before expiration. - HSTS: Enable HTTP Strict Transport Security to prevent protocol downgrade attacks. Set max-age to at least one year (31536000 seconds). - OCSP stapling: Enable for faster certificate validation. Cyber Defense Agent verifies TLS: Every CDA scan checks your TLS version, cipher suites, certificate validity, and HSTS configuration. TLS issues are flagged in your Cyber Defense Score with specific remediation guidance. Email encryption: Email in transit should use TLS (STARTTLS or implicit TLS). Most email providers enforce this by default. CDA's email authentication scan verifies that your mail server supports and prefers TLS for inbound and outbound connections. For sensitive email content, consider: - Microsoft 365 Message Encryption (included in Business Premium) - Google Workspace Client-Side Encryption - S/MIME or PGP for end-to-end encryption (more complex, use for highly sensitive communications) VPN and remote access encryption: All remote access connections must be encrypted. Use WireGuard, IPSec, or OpenVPN — never use PPTP (broken encryption). ZTNA solutions (Cloudflare Access, Tailscale, Zscaler) encrypt all traffic by default.

Cyber Defense Agent scans your external TLS configuration as part of every assessment. Here is what CDA checks and how to fix common issues: CDA TLS checks: 1. TLS version — CDA verifies that your server supports TLS 1.2 or 1.3 and does not accept connections using TLS 1.0 or 1.1. If deprecated versions are enabled, CDA flags this as a finding. 2. Certificate validity — CDA checks certificate expiration, trust chain, and whether the certificate matches the domain. Expired or mismatched certificates break trust and trigger browser warnings. 3. Cipher suite strength — CDA tests the cipher suites your server accepts. Weak ciphers (RC4, DES, export ciphers) are flagged. Strong configurations use only AEAD ciphers. 4. HSTS header — CDA checks for the Strict-Transport-Security header. Missing HSTS means browsers can be tricked into connecting over HTTP. 5. Certificate transparency — CDA verifies that your certificate is logged in Certificate Transparency logs, which helps detect misissued certificates. Fixing common TLS issues: - Upgrade TLS version: In your web server configuration (Nginx, Apache, IIS), set the minimum TLS version to 1.2. For Nginx: ssl_protocols TLSv1.2 TLSv1.3; For Apache: SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 - Renew expired certificates: Use Let's Encrypt for free, automated certificate renewal (certbot). Set up auto-renewal cron jobs or use your hosting provider's auto-renewal feature. - Enable HSTS: Add the Strict-Transport-Security header in your web server or CDN configuration. Start with a short max-age for testing, then increase to 31536000 (one year). - Update cipher suites: Use Mozilla's SSL Configuration Generator (ssl-config.mozilla.org) to generate a secure cipher suite configuration for your web server and TLS version.