Co-Located Keys, an Unrotated Ticket Key, and a $180k Legacy Interface

Use likelihood of key or plaintext compromise × blast radius of what that key protects, and treat key custody separately from protocol hygiene.

1. Transport key and column key in one vault, passphrase in Jenkins. A single Jenkins compromise yields the key that protects data in transit and the key that protects data at rest. Separation of keys exists precisely so one breach does not decrypt everything. The blast radius is the entire patient database, and the attack surface (a CI system with broad access) is routinely compromised.

2. Unencrypted database tapes. Any lost or stolen tape is a reportable mass disclosure. Likelihood is moderate but the impact is total and irreversible - you cannot re-encrypt a tape that is already in a courier's van. This pairs catastrophically with finding 1, because the same vault holds the only keys that could have protected the data.

3. Session ticket key never rotated. A static ticket key means anyone who obtains it and has retained captured traffic can decrypt past sessions; it also removes forward secrecy across seven years of traffic. Likelihood is lower than 1 or 2, but the historical exposure cannot be undone.

4. TLS 1.0/1.1 with CBC. Internet-facing and trivially visible, but exploitation needs a positioned attacker or a downgrade-capable client, and the data is also protected by the application layer. Cheap to fix, so fix it in this window - but rank it below key custody.

5. 3DES on the lab interface. Genuinely weak and should be retired, but the endpoints are known, the traffic is nightly, internal, and single-purpose. It is the least urgent provided it is segmented.

State the framework explicitly: a low CVSS finding on key custody can outrank a high-severity cipher finding.

Isolate the weak channel so its weakness stops mattering, and paper the decision.

Technical containment:

• Move the analyser and its interface host onto a dedicated segment with an ACL permitting only that host pair on that one port. 3DES traffic then never crosses shared infrastructure.
• Insert a protocol-breaking relay where possible: the analyser drops files to a hardened host over the legacy channel, and the relay re-transmits over TLS 1.2 or SFTP into the portal. This shrinks the legacy surface to a single hop.
• Disable 3DES everywhere else immediately - the exception applies to one interface, not to the estate.
• Log and alert on any connection to that segment from an unexpected source; a sudden change in volume or source is the detection signal.

What makes the exception defensible:

• A written risk acceptance signed by the business owner of the laboratory service, not by IT alone, stating the clinical consequence of disabling the interface.
• The vendor quote ($180k, nine months) attached as evidence that the cost and timeline are externally imposed rather than chosen.
• A dated expiry tied to the upgrade milestone, with a quarterly review and an owner.
• The compensating controls named above with evidence they are operating.

What makes it indefensible: an open-ended exception, no segmentation, and no expiry. Auditors accept documented risk with controls; they reject undocumented risk with none.

Separate the duties and the stores.

• Split the vault: transport keys and data-at-rest keys live in different stores with different administrators and different approval paths. Neither team alone can decrypt the database.
• Move both into an HSM or cloud KMS with non-exportable keys. The private key and the column key should never be readable files on a build server, encrypted or otherwise.
• Replace the static Jenkins credential with short-lived, workload-identity-based authentication (OIDC federation) so there is no long-lived passphrase to steal. Jenkins should be able to use the key without ever being able to read it.
• Assume the current key material is already compromised: rotate the TLS key pair, invalidate and reissue the session ticket key, and re-wrap the column key, because you cannot prove the vault was never read.

What "rotating the column key" actually requires depends on the design:

• With a single symmetric key encrypting the column directly, rotation is a bulk decrypt-and-re-encrypt of every row - expensive, long-running, and risky on a live clinical database.
• The better design is envelope encryption: a data encryption key per table or tenant, wrapped by a key encryption key held in the HSM. Rotating the KEK then means re-wrapping the small set of DEKs - minutes, not a full table rewrite - and a compromised DEK can be rotated by re-encrypting only its own rows.

Also fix the tape problem in the same change: backup encryption keys must be in the HSM with a documented escrow and recovery procedure, or the first successful restore will fail because nobody can find the key.