Post-Acquisition Encryption Inventory with Departing Key Holders
After acquiring a 60-person logistics firm, the security team inventories its encryption. The customer portal supports TLS 1.0 and TLS 1.2 with CBC cipher suites, using a certificate from an internal CA whose root was created in 2014 with SHA-1 and is trusted by all 400 employee laptops. Payment card data (about 12,000 cards monthly) sits in a MySQL 5.7 database with AES-256 encryption at rest provided by the storage layer; the application also encrypts the PAN column with AES-256-CBC using a static key that appears in a configuration file in the application repository and on three admin Confluence pages. Backups go to object storage encrypted with SSE-C, and that key is stored in the same CI system. The PCI assessor visits in 14 weeks. Two of the three administrators who hold the keys leave at the end of the month.
1. Separate the real risks from the cosmetic findings and lay out a 14-week order of work.
Read the worked answer
The live risk is the PAN key: a static AES key in a repo and on wiki pages means anyone with repository read access - CI service accounts, contractors, anyone who cloned before the acquisition - can decrypt 12,000 cards a month of stored data. Two of three key holders leaving makes it time-boxed. That is first, and it is a confidentiality problem today, not a compliance problem at week 14.
Second is the SSE-C backup key living in the same CI system as the backups. Key and ciphertext in one trust domain means the encryption provides little protection against a CI compromise or an insider; it is the same failure mode as the PAN key, one layer down.
Third is TLS 1.0 with CBC suites on the portal - real, internet-facing, and cheap to fix once client compatibility is checked.
Fourth is the SHA-1 root trusted by 400 laptops. It is not an immediate break of confidentiality; it is a trust and re-issuance project with a rollout dependency, so it runs in parallel rather than first.
Sequencing: weeks 1-3 remove the key from the repository and wiki (history included) and rotate; weeks 2-6 design the KMS and envelope scheme; weeks 4-8 re-encrypt the PAN column; weeks 6-10 TLS and cipher changes; weeks 8-14 CA replacement. Build the assessor's evidence pack as you go, not in week 13.
2. Design the key management remediation, including how you rotate keys protecting data that is already stored.
Read the worked answer
Target state is envelope encryption with a managed KMS or HSM. The application generates or requests a data key per record or batch, the KMS wraps it under a customer master key that never leaves the HSM, and the application authenticates to the KMS using a workload identity rather than a static secret in a config file. Separate duties so key administrators cannot read data and data-reading roles cannot alter key policy, and log every decrypt call for audit.
Rotating existing data is the hard part. Run a background re-encryption job: read with the old key, write with a new data key, record progress per row or batch so it is resumable. Use dual-read during migration - attempt the new key first, fall back to the old - so the application stays available. Keep the retired key in decrypt-only state until the last ciphertext has been migrated and verified, then destroy it. That destruction is also your crypto-shredding mechanism for deletion requests: delete the wrapped data key and the record becomes unrecoverable.
For backups, move SSE-C to SSE-KMS so the client is not presenting a key per request and the key is not stored beside the ciphertext in CI.
Do the rotation before the two administrators leave, not after. Once they are gone, custody records and any unrecorded copies leave with them.
3. What is the plan for the TLS and certificate findings, and what is the main risk in executing it?
Read the worked answer
On the portal: require TLS 1.2 or higher with AEAD suites only (AES-GCM, ChaCha20-Poly1305), disabling CBC, TLS 1.0, and TLS 1.1 at the load balancer. Inventory clients first - a logistics firm often has partner integrations and older handheld scanners that will break, and discovering that post-change is worse than discovering it pre-change. Enable the change in monitor-then-enforce mode if the platform supports it.
The internal CA is the sequencing trap. Four hundred laptops trust the 2014 SHA-1 root; if you remove that root before the replacement is distributed everywhere, every internal TLS connection fails at once, including laptops that have been offline for months. Correct order: publish the new root to all devices via GPO or MDM, confirm coverage, re-issue leaf certificates with SHA-256 from the new CA, migrate services, then remove the old root after a grace period. Never remove before step one completes fleet-wide.
Prioritize the internet-facing cipher and protocol change ahead of the internal CA work, because that is where an attacker can actually negotiate a weak suite today. For the assessor, the key-management evidence matters more than the TLS remediation, so sequence reporting accordingly.