Once of the most important design features for the application when using the SAKA is: how to secure the decryption credentials for authorized applications that communicate with the SAKA. In order to decrypt any sensitive data, the Foundation services of the SAKA requires the following four parameters:

TABLE 2: Parameters for the Encryption service

While all data sent to the SAKA is over SSL/TLS, the application, nonetheless, must have the username and password for the credential authorized to request decrypted data. This can present a security risk for the company, as it could lead to potential exposure of plaintext CHD with the compromise of an authorized credential.

However, many e-commerce sites have service level agreements with business units mandating very high uptimes for the infrastructure; as a result systems/applications are generally designed to restart automatically if they experience any failures. This leads to a conundrum: to automate the start-up of an application designed to decrypt tokenized data on the SAKA, the application must have access to the authorized credentials somewhere without human intervention. Unfortunately, there is no technology that can secure the credentials for unattended restarts - hidden files on the disk, registry settings, property files, smartcards, Trusted Platform Modules (TPM), Hardware Security Modules (HSM), etc. - without adding costs and constraints, leaving residual risks or adding new risks.

As PCI-DSS and other security regulations mature, auditors are finally knowledgeable about these risks and asking more pertinent questions.

Since the industry recognizes that applications need access to plaintext CHD at some point to perform their business function, an appropriate balance between security and availability is to design the application to restart automatically, but wait for one or more Operators to provide the authorized credential through an internally visible web-page or webservice. Upon receiving the credential (or parts of the credential and assembling them into a single String or char-array), the application performs a sanity-check with the credential to verify it works, and caches them in main memory for use as long as the application remains running.

Now, when the application needs to call the SAKA for decryption, deletion or relay services, it can find the data-structure in memory containing the credentials to the SAKA. If the machine/application is restarted, the application goes back to waiting for the Operator to provide the credentials.

Using one Operator to provide the credentials makes it convenient for operations, but leaves residual risks that a single person could compromise the security of the system. Having multiple Operators provide only a part of the credential, and assembling them upon receiving them, provides increased security since it would require collusion amongst multiple individuals to compromise the system.

Having appropriate configuration and change-management systems on the system infrastructure ensure that tools that scan/dump memory contents to files cannot be installed without knowledge. Similarly, if systems in the application tier are running on virtual machines (VM), it is important to establish controls when saving/relocating VM instances to other machines to ensure the protection of the decryption credentials in the saved/relocated VM instances. Ideally, such instances should be shut down normally to wipe out their memory contents and restarted through a “cold-boot” , thereby requiring the SAKA decryption credentials to be provided again.

Design Consideration #2