Shared SFTP Account for Cardholder Data Transfer
An issuer sends daily personalization files containing primary account numbers, names, and track-equivalent data to a bureau over an MPLS circuit. The files are pushed by an issuer-side job to an SFTP server in the bureau's demilitarized zone. The current design uses one shared account, 'cardprod', with a 12-character password rotated every 180 days; the password is stored in a script on the issuer's job scheduler and known to four bureau operators. An internal audit notes that logs show the account is used from two issuer IP addresses and occasionally from a bureau engineer's workstation. The bureau's security team proposes to add a second shared account for the new issuer and to shorten rotation to 90 days. The application owner says per-user accounts are impossible because the legacy job scheduler supports only one credential.
1. Assess the logical-security risks in the current SFTP design. Why is adding a second shared account and shortening rotation insufficient?
Read the worked answer
The shared 'cardprod' account destroys attribution: logs cannot show which of the four operators, or which issuer job, performed an action. A password known to four people and stored in a script is a shared secret, and 180-day rotation (or 90-day) does not fix that. The logs show use from two issuer IPs and occasionally from a bureau engineer's workstation, which suggests the credential is being used outside the intended server-to-server path and that cardholder data may be pulled to an endpoint. Adding a second shared account for the new issuer increases the number of shared secrets and still cannot support non-repudiation. The data includes PANs and track-equivalent data, so access must be uniquely attributable, least-privilege, and encrypted in transit with managed keys. The proposal addresses password age, not identity or scope.
2. What redesign or compensating controls would you recommend, and what must be true before you accept a legacy workaround?
Read the worked answer
Target state: per-user authentication to a controlled file-transfer gateway, with the legacy job using a service credential that is vaulted and not known to operators. Individuals who need to administer or troubleshoot should authenticate through the gateway with MFA and unique IDs; the service credential should be usable only from allowlisted issuer IPs and only for the specific file path. Encrypt files with strong cryptography, manage keys in an HSM or key vault, restrict decryption to the personalization process, and log file-level access to a SIEM. For a legacy workaround, I would require: no interactive use of the shared account; credential vaulting with check-out/check-in; source-IP allowlisting; removal of the engineer's workstation path; file integrity monitoring; alerting on anomalous volumes; and a funded date to retire the shared account. Without those, the risk remains too high for PAN data.
3. The bureau proposes moving the SFTP server from the DMZ to the internal network to simplify firewall rules. Evaluate this change.
Read the worked answer
Moving the server inward for firewall convenience generally increases risk: an Internet-facing or partner-facing file transfer service is better segmented in a DMZ, where a compromise has a narrower path to the internal personalization network. The current problem is not the DMZ location; it is the shared credential and uncontrolled paths. If the server moves, the bureau would need at least equivalent segmentation-strict allowlists, no direct Internet exposure, a hardened host, IDS/IPS, and a controlled one-way path into production. I would not approve the move as a simplification. I would approve it only if the architecture shows that the internal placement does not widen access to cardholder data and that the transfer gateway remains a choke point with logging and encryption.