10. Secure Design and Architecture #

10.1 Design artifacts #

Each project must produce and maintain lightweight design artifacts that are sufficient to assess risk and guide implementation:

• Data flow diagram showing users, services, data stores, integrations, and trust boundaries; clearly label where Restricted Data is stored or flows, and all subprocessors/regions.

• Residency map indicating storage and access locations (Canada by default) and any proposed cross‑border paths (must not proceed without an approved exception).

• Role model mapping business roles to permissions (RBAC/ABAC) and sensitive operations.

10.2 Threat and privacy analysis #

Perform a right‑sized threat and privacy review during design. Identify high‑risk entry points (auth flows, file uploads, admin APIs), data misuse risks, and the mitigations implemented (e.g., MFA, WAF rules, rate limiting, schema validation). When new PI uses, cross‑border transfers, or high‑risk processing are introduced, a DPIA is required before build. PENDING: DPIA trigger checklist and template link

10.3 Environment segregation and data use #

Development, test, staging, and production must be logically and physically separated with distinct identities, secrets, and networks. Production Restricted Data must not be used in non‑production; when realistic data is necessary, use anonymized or de‑identified datasets. Admin credentials must be unique per environment, and CI/CD must never deploy from production hosts or use production secrets in lower environments.

10.4 Authentication and authorization #

Federate human access to the Application with CLD’s IdP and enforce MFA for admin roles and Restricted Data access. Implement RBAC/ABAC with least privilege, deny by default, and explicit allow lists for sensitive actions. Support time‑boxed elevation for Support and break‑glass only under documented procedures. PENDING: IdP/protocols; standard roles and scopes

10.5 Cryptography and secrets #

Encrypt data in transit with TLS 1.2+ and in storage with strong algorithms (e.g., AES‑256 or equivalent). Prefer FIPS‑validated crypto modules where available. Manage keys and secrets using an approved vault/KMS; never hard‑code secrets in source, images, or configuration files; rotate keys on a defined cadence and when personnel change. Use unique keys per environment and per data store where feasible.

10.6 API and input protections #

Expose APIs with OAuth 2.0/OIDC using appropriate flows (Authorization Code + PKCE for user flows; Client Credentials or mTLS for service‑to‑service), with narrow scopes and short‑lived tokens. Validate and sanitize all inputs (including headers and file metadata); enforce JSON/XML schema where applicable; set conservative request/response size limits; implement rate limiting and abuse detection; return generic errors that do not leak stack traces or configuration. PENDING: Allowed OAuth grants; access/refresh token TTLs; scope conventions; rate‑limit defaults

10.7 Web security controls #

Place internet‑facing apps behind a WAF configured to mitigate OWASP Top 10 and common API attacks; enable DDoS and bot protections as appropriate. Set secure headers (e.g., HSTS, Content‑Security‑Policy, X‑Frame‑Options/Frame‑Options, Referrer‑Policy, X‑Content‑Type‑Options). Enforce cookie flags (HttpOnly, Secure, SameSite) and implement session idle and absolute timeouts with re‑authentication for privileged operations. PENDING: Header and timeout defaults

10.8 File upload controls #

Restrict uploads to approved MIME types and sizes; verify content type server‑side; scan uploads with AV/antimalware before processing; quarantine or block on detection per policy; strip sensitive image metadata (e.g., EXIF/GPS) unless explicitly required and documented. Store content encrypted; validate access control on every retrieval. PENDING: Max size (__ MB); allowed types; AV behavior; EXIF rule

10.9 Configuration and dependencies #

Adopt secure defaults and baseline hardening: disable default/admin accounts, remove unused services, restrict admin interfaces from the public internet, and require MFA for administrative consoles. Track third‑party libraries and services; maintain an SBOM; update dependencies promptly for High/Critical CVEs; pin versions to avoid supply‑chain drift. External services must be authenticated and authorized with least privilege and audited.

10.10 Observability and audit #

Design for auditability and troubleshooting: emit structured, SIEM‑ready logs for authentication, authorization decisions, permission changes, admin/config actions, API calls, file events (including AV result), and control blocks (WAF/IDS/EDR). Include who/when/where/what/outcome and a correlation ID; avoid logging secrets and full identifiers. Provide health endpoints, metrics, and traces suitable for operations dashboards and alerting. PENDING: CLD SIEM forwarding method; minimum log fields; retention target

10.11 Availability and recoverability #

Engineer to meet the assigned tier’s RTO/RPO using appropriate redundancy, backups, and recovery processes. Backups must be encrypted and periodically restored to verify integrity and recovery time; document runbooks, rollback steps, and pre‑checks. Consider immutability/object‑lock where warranted for critical data. PENDING: Tiers and RTO/RPO; restore test cadence; immutability requirement

10.12 Administrative access and change safety #

Restrict administrative access to trusted networks (VPN/zero‑trust) and require MFA. Use change‑safe mechanisms (feature flags, canary or blue‑green deployments for higher‑risk releases) and document rollback criteria and steps. Prohibit direct changes in production consoles that bypass version control and review, except under documented break‑glass with post‑facto review.

10.13 Mobile‑specific (if applicable) #

When mobile clients are in scope, use platform keychains for secrets, enforce transport security, detect jailbreak/root, minimize on‑device storage, and consider certificate pinning to reduce interception risk. [If mobile not in scope, mark N/A]

10.14 Exceptions #

Any deviation from this section requires a documented exception with scope, rationale, risk assessment, compensating controls, owner, approval (ISO and Executive Sponsor), and expiry.