Legacy Encryption and Key Management in a Retail Tax System
A retailer's tax-reporting application stores 1.2 million customer Social Security numbers in a database encrypted with AES-128. The key is in a plaintext configuration file on the application server and is the same for production and test. The public load balancer still accepts TLS 1.0, and a vendor API retrieves full SSNs for monthly reconciliation. Customer-support staff can view full SSNs in the order screen. A six-month migration is funded, but the vendor says the API cannot change for nine months. The database administrator wants to avoid performance impact during quarter-end.
1. How should the team prioritize the cryptographic gaps?
Read the worked answer
Prioritize by exposure and exploitability, not by algorithm strength alone. The plaintext shared key is the highest risk because anyone with application-server or test-environment access can decrypt production data. Next is the vendor API returning full SSNs and support staff viewing them, because these create broad human and network exposure. TLS 1.0 is a real but narrower issue if the endpoint is internet-facing. A practical order: remove production data from test or re-key test separately; move keys to a managed key store with access logging and separation of duties; restrict and monitor the vendor API; mask SSNs in the support UI; then disable TLS 1.0 after confirming client compatibility. Quarter-end performance concerns can be managed with off-peak re-keying and testing, but should not defer key isolation.
2. What key-management design fits a six-month migration with a vendor that cannot change for nine months?
Read the worked answer
Use envelope encryption or tokenization rather than a single static key. Generate data-encryption keys per tenant or dataset, wrap them with a master key held in a hardware security module or managed key service, and store only wrapped keys in the database. Separate production and test keys completely, with distinct access policies. For the vendor, issue a scoped API credential that returns tokenized values or masked SSNs unless a reconciliation case is approved, and log every full-value retrieval. Rotate the master key on a defined schedule and after any suspected exposure. Because the vendor integration cannot change for nine months, put a compensating control in front of it: an API gateway that enforces mTLS, rate limits, and field-level authorization, and a manual approval workflow for full SSNs.
3. How should support-screen masking be handled without breaking customer verification?
Read the worked answer
Mask SSNs by default and expose only the last four digits. For verification, support staff should not need the full value; use challenge questions, a one-time code, or a partial-match workflow. If full access is occasionally required, implement step-up authorization with a reason code, manager approval, and audit logging. Measure how often the exception is used and review it. This preserves customer service while reducing bystander and screenshot exposure. The decision should be documented as a policy exception with an expiry date, not left to individual agents.