Encryption Policy

This policy sets the encryption principles, controls, and standards for all data and environments at Tanqory to protect confidentiality, integrity, and availability using widely accepted algorithms and practices. All roles—including vendors and subprocessors—must follow this alongside Network Security, Key Management, Data Classification/Retention, BCP/DR, Incident Response, Third-Party Risk Management, and contractual/legal requirements. If conflicts arise, the more specific/recent document or stricter law prevails.

1) Purpose and Scope

• Protect personal data, payment data, customer/merchant/employee data, and confidential business data at rest and in transit across all data classifications.
• Cover cloud (Production/Staging/Sandbox), internal networks, endpoints, mobile devices, backup media, and APIs/integrations with external providers.
• Use modern algorithms, standards, and key lengths; block deprecated/unsafe protocols.
• Define clear responsibility for selection, design, implementation, monitoring, and necessary exceptions, with audit evidence.
• Support applicable laws/standards: GDPR/PDPA, PCI DSS, SOC 2, ISO 27001/27002, NIST SP 800-57/52/171, MAS TRM, HIPAA/FedRAMP/NIS2/DORA as relevant.
• Communicate requirements to personnel and counterparties via training and contractual/technical guides.

2) Governance, Roles, and Responsibilities

• CISO (or delegate) owns the policy and approves high-risk changes/exceptions.
• Security Architecture sets allowed/denied algorithms, key lengths, and protocols.
• SecOps enforces technically (policy-as-code), detects/blocks weak protocols, and reports compliance.
• DPO reviews personal data compliance and cross-border rules.
• Engineering/DevOps follow secure SDLC and approved crypto libraries/SDKs; enable HTTPS/TLS and at-rest encryption.
• Third-Party/Vendor Owners ensure suppliers meet contracted crypto standards and allow audit/assurance.
• End users must handle passwords/keys/tokens safely and must not disable encryption.

3) Core Encryption Principles (Data in Transit / Data at Rest)

• Data in Transit: TLS 1.2+ with hardened configs (see Appendix A) for web/API/email/file/database traffic over public/untrusted networks.
• Data at Rest: Strong symmetric crypto (e.g., AES-256-GCM) for databases, disks, volumes, snapshots, backups, and corporate mobile devices.
• Key Management: Use KMS/HSM for Key Encryption Keys (KEK) and rotate per policy.
• Hashing/Integrity: SHA-256 or stronger; avoid MD5/SHA-1 for security use cases.
• Signing: Asymmetric keys (RSA 2048/3072 or ECDSA P-256/P-384) for code/document/token signing.
• Secret Handling: No secrets/keys/certs in source code or logs; use secret manager/parameter store with access logging.

4) Approved vs. Prohibited Algorithms/Protocols

• Approved: AES-256/128 (GCM/CTR), TLS 1.2/1.3 with PFS (ECDHE), RSA 2048/3072/4096, ECDSA P-256/P-384, SHA-256/384/512, Ed25519, HTTPS (enable HSTS where suitable).
• Prohibited: SSL/TLS < 1.2, RC4, 3DES/DES, MD5, SHA-1 for auth, plaintext transport (HTTP/FTP/Telnet), reversible/plaintext password storage.
• Email/files: STARTTLS/SMTPS/IMAPS/POP3S; S/MIME/PGP for high-confidentiality content; avoid sending personal data unencrypted.
• Databases/storage: Enable TDE or volume encryption; use TLS/mTLS for sensitive inter-service traffic.
• Certificates: Use trusted public CAs externally; controlled private CA internally; auto-renew with expiry monitoring.

5) Key Management

• Use KMS/HSM to generate, store, use, and rotate KEKs/DEKs with Separation of Duties.
• Rotation: KEK at least annually; DEK/secrets/API keys every 90–180 days or immediately on suspected compromise.
• Access requires MFA and RBAC; log every key access/use; review access/usage at least quarterly.
• Backup keys encrypted and region-separated (where law/contract allows); test key recovery per BCP/DR cadence.
• No key sharing via unencrypted/informal channels; do not log keys.

6) Secrets and Credentials

• Store secrets (DB passwords, API tokens, OAuth client secrets, SSH keys) in encrypted, RBAC-controlled secret managers.
• Set token/session TTL by risk (e.g., automation 24–72h; user tokens 8–24h); enforce secret rotation per risk/policy.
• Use mTLS for sensitive internal services; apply certificate pinning where supported.
• Hash passwords with tunable work-factor functions (bcrypt/Argon2); never use SHA-1/MD5 for password storage.
• Mask/redact secrets in UIs/logs.

7) Secure SDLC and Delivery

• Enforce HTTPS/TLS externally and TLS internally for sensitive paths; run SAST/DAST to detect insecure crypto.
• Use vetted, maintained crypto libraries; avoid homegrown crypto.
• Code review to catch secrets in code; use git hooks/scanners to prevent secret commits.
• Code signing for critical binaries/updates; verify signatures before deployment.
• In CI/CD, isolate runners/agents; use per-environment secrets; block Production secrets from unnecessary pipelines.

8) Testing, Monitoring, and Audit

• Regularly scan TLS/cert/protocol configs (e.g., monthly or after changes); auto-block disallowed ciphers/protocols.
• Quarterly key usage reviews; revoke unused/expired keys promptly.
• Penetration tests/Red Team on sensitive data paths; verify TLS/mTLS/at-rest encryption and secret handling.
• Track metrics: deprecated protocol detections, key rotation timeliness, secret/key exposure incidents.
• Retain audit trails at least 1–3 years or longer per law/contract.

9) Exceptions and Legacy Systems

• Any weaker protocol/algorithm use (e.g., legacy device support) requires CISO approval, documented rationale, sunset date, and compensating controls.
• Maintain decommission plan and executive tracking for legacy systems not meeting standards.
• Assess personal/financial/contractual impact and adjust SLA/contract if needed.

10) Incident Response and Notifications

• On suspected/confirmed key/secret compromise, follow IRP: revoke keys, rotate secrets, assess data impact, and log the incident.
• Notify regulators/customers/users per law/contract (e.g., GDPR 72h, SG PDPA 3 days) if personal data is affected.
• Add new detection rules post-incident and harden crypto/secret controls to prevent recurrence.

11) Backup, Recovery, and Cross-Border

• Backups must be encrypted to production-equivalent or stronger levels and stored only in allowed regions; separate access to backup keys from production keys.
• Validate integrity/malware-free before restore.
• Honor data residency with supported regions/providers; encrypt cross-border transfers.
• For non-adequate destinations, apply SCCs or client-side encryption with keys not accessible to the recipient.

12) Training, Communication, and Records

• Annual training for staff/developers on proper crypto/secret handling; ad-hoc training for new standards/tech.
• Publish allow/deny algorithm lists and exception request steps via internal portal/technical guides.
• Keep records of exceptions, key rotations, secret access, scans, pen test/audit results for ≥1–3 years or as required by stricter law/contract.
• Review/update the policy at least annually or after critical vulnerabilities/new laws/standards.

Appendix A: Allowed/Disallowed Algorithms & Protocols (Examples)

• Allowed: TLS 1.2/1.3 with ECDHE, AES-256-GCM/ChaCha20-Poly1305, RSA 2048/3072/4096, ECDSA P-256/P-384, SHA-256/384/512, Ed25519.
• Disallowed: SSLv2/v3, TLS 1.0/1.1, RC4, 3DES/DES, MD5, SHA-1 for security use, export/anonymous ciphers, plaintext HTTP/FTP/Telnet.
• Server configs: disable insecure renegotiation; enable HSTS/OCSP stapling where appropriate.

Appendix B: Key/Secret Rotation (Example Guidance)

• KEK: at least annually or sooner if needed.
• DEK: every 90–180 days or on risk signal.
• API tokens/service accounts: every 90 days or use short-lived tokens (24–72h).
• Certificates: auto-renew with ≥30-day advance alerts.
• If industry/contract is stricter, follow the stricter rule.

Appendix C: Standards Mapping (For Audit)

• ISO/IEC 27001/27002 (A.8.24–A.8.28): encryption/key management/data protection.
• NIST SP 800-57/52/171: key management/protocols/protection of sensitive data.
• PCI DSS 4.0 (Req.3/4): cardholder data encryption and transmission.
• SOC 2 (CC6/CC7): logical access/change/monitoring controls tied to crypto.
• HIPAA/FedRAMP/NIS2/DORA/MAS TRM: sectoral crypto/incident/key management requirements; add sub-appendices if customers/contracts require.
• GDPR/PDPA and other privacy laws: encryption as an Article 32 measure and for cross-border safeguards.

Appendix D: Glossary

• AES: Advanced Encryption Standard (symmetric).
• API: Application Programming Interface.
• BCP/DR: Business Continuity/Disaster Recovery.
• DEK: Data Encryption Key.
• HMAC: Hash-Based Message Authentication Code.
• HSM: Hardware Security Module.
• KMS: Key Management Service.
• KEK: Key Encryption Key.
• MFA: Multi-Factor Authentication.
• mTLS: Mutual Transport Layer Security.
• PFS: Perfect Forward Secrecy.
• PII: Personally Identifiable Information.
• PKI: Public Key Infrastructure.
• RBAC: Role-Based Access Control.
• SCC: Standard Contractual Clauses.
• TLS: Transport Layer Security.
• TDE: Transparent Data Encryption.