4.8 Architecture and Engineering Case Lab

Case Lab: Designing a Secure Partner Data Platform

Scenario: A health analytics company is building a partner data platform that receives files from hospitals, processes them in a cloud environment, exposes dashboards to approved partner users, and sends summarized reports to a research team. The platform uses containers, managed databases, object storage, a third-party identity provider, and a small on-premises appliance at some hospital sites.

The business goal is faster analytics without exposing patient data or disrupting hospital operations. The security team must support confidentiality, integrity, availability, privacy, auditability, and partner trust. The organization also wants a design that can survive vendor changes, certificate rotation, regional outages, and eventual retirement of the on-premises appliance.

Start by identifying assets and trust boundaries. Patient files, derived datasets, dashboard results, encryption keys, identity assertions, audit logs, container images, and reports are critical assets. Trust boundaries exist between hospitals and the cloud, partners and dashboards, containers and managed services, administrators and the management plane, and the company and third-party providers.

The dominant security model is not one model alone. Confidentiality thinking similar to Bell-LaPadula helps prevent lower-authorized users from reading sensitive datasets. Integrity thinking similar to Biba and Clark-Wilson helps ensure incoming files are validated and transformed only through controlled processes. State machine thinking helps with upload, quarantine, processing, release, archival, and deletion transitions.

A useful threat scenario is partner credential compromise. The attacker may try to access dashboards, export data, call APIs, or change report settings. Controls should include phishing-resistant MFA where feasible, conditional access, short session lifetimes, least privilege roles, anomaly detection, export limits, and partner notification procedures. The residual risk owner may be the business owner for partner access.

Another scenario is build pipeline compromise. If a malicious image reaches production, it could alter analytics or expose data. Controls should include protected branches, peer review, dependency scanning, image signing, admission control, runtime restrictions, and separation between build administrators and production deploy approvers. The architecture should reject unsigned or unapproved images automatically.

Cryptography choices should be practical. Use TLS with proper certificate validation for hospital appliance connections and partner access. Use symmetric encryption for stored files, backups, and database fields where needed. Use a managed key service or HSM-backed service so applications can use keys without exporting raw material. Use digital signatures for software updates and possibly for report approval evidence.

Key management needs explicit ownership. The platform team may own application data keys, the security team may own policy and monitoring, and a cloud operations team may operate the key service. Hospital appliances need device identity, certificate renewal, secure update, and procedures for lost or replaced hardware. Certificate expiration should be monitored as an availability risk.

Cloud shared responsibility must be written as a matrix. The provider may secure facilities and managed service infrastructure, but the company still owns data classification, IAM, key policy, logging configuration, network exposure, retention, and incident response. If a SaaS identity provider is used, federation settings, lifecycle provisioning, and access review remain customer duties.

The on-premises appliance adds edge risk. It may be in a hospital network closet with uneven physical protection. It should use secure boot, signed updates, limited local storage, encrypted communication, device certificates, tamper-evident handling where justified, and documented replacement procedures. If it stores data during outages, offline retention and upload replay protections are required.

Physical and environmental security cannot be ignored. Cloud facilities are mostly provider controlled, so assurance reports and contract terms matter. Hospital-side appliances need minimum placement requirements, access restrictions, asset inventory, and instructions for return or destruction. Administrative laptops used to manage the platform also need endpoint hardening because they can reach sensitive control planes.

Lifecycle planning should be included before launch. Define how partners are onboarded and offboarded, how data retention works, how keys rotate, how logs are retained, how containers are updated, how appliances are retired, and how a provider exit would occur. Retirement should include data migration or deletion, certificate revocation, access removal, and sanitization evidence.

Use this executive decision memo format:

• Decision needed: Approve the proposed platform control baseline and residual risk owners.
• Highest risks: Partner overaccess, build compromise, cloud misconfiguration, appliance lifecycle gaps, and certificate outage.
• Required controls: Federation with MFA, least privilege, signed images, managed keys, private storage, centralized logging, secure appliance updates, and tested recovery.
• Evidence: Threat model, control matrix, key inventory, certificate monitoring, access review records, security test results, and decommissioning checklist.
• Residual risk: Limited partner misuse and provider dependency remain, subject to monitoring, contracts, and periodic review.

A common weak recommendation is to encrypt everything and move on. Encryption is necessary, but it does not solve identity, authorization, integrity, monitoring, physical access, or lifecycle closure. Another weak recommendation is to accept provider defaults without reviewing whether they match the data classification and business impact.

For CISSP case work, sequence matters. Start with the business objective and data classification, then define trust boundaries and threat scenarios. Select controls that reduce the most important risks, assign ownership, and specify evidence. End with residual risk and operating procedures so the design can be managed after approval.