INTRODUCTION
Both tokenization and end-to-end encryption can be combined to create a awesome credit card tokenization system. Sometimes enterprises wish to do less. Below, the risks the “encryption method” are described in the table. The table lists “attacks” in the first column (“Exploit”). Other columns are “encryption methods”, and are described below, for example “E2E” is “End to End Encryption”.
The table body contains information about the effectiveness of the “encryption method” in defending against the corresponding “attack”. The values used in the table are defined at the end of the table.
TABLE 1
| Exploit | Description | E2E | NE2E | App | DB Col | DB Cont | Disk |
|---|---|---|---|---|---|---|---|
| Spear Phishing | Targeted emails that appear to be from another source, intent on obtaining PII. | YES | YES | ? | NO | NO | NO |
| Rogue Employee | Developer, DBA, Customer Service, Director, etc that has special access, intent on obtaining PII. | YES | YES | NO | NO | NO | NO |
| Social Engineering | Phone call, in person, other based on manuplation and deception, intent on obtaining PII. See Spear Phishing. | YES | YES | ? | NO | NO | NO |
| Unauth Priv Escalation | Using a bug to obtain elevated OS or database access with the intent of obtaining PII. | YES | YES | NO | NO | NO | NO |
| SQL INJECTION | Using insecure code to change the SQL code to function in a manner not intended by the application, with the intent of obtaining PII. | YES | YES | ? | ? | NO | NO |
| Cross Site Request Forgery, Cross Site Scripting | A type of attack that occurs when a malicious website causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated, with the intent of obtaining PII. | ? | ? | ? | ? | NO | NO |
| Access To Database Backups | An attacker is able to obtain database backups with the intent of obtaining PII. | YES | YES | YES | YES | YES | NO |
| Weak Authentication | An application service account or a system administrator’s access is breached due to having a weak password, with the intent of obtaining PII. | YES | YES | ? | ? | NO | NO |
| Exploitation of vulnerable/misconfigured databases | A database bug is exploited, or a database configuration is incorrect and is exploited, with the intent of obtaining PII. | YES | YES | YES | NO | NO | NO |
| Communication protocol vulnerabilities | Communication vulnerability is exploited with the intent of obtaining PII. (for example, a portion of the server memory can be returned, note heartbleed) | YES | ? | NO | NO | NO | NO |
| Other / Malware | Many possibilities with the intent of obtaining PII, ie a bot, keystroke logger, etc. | YES | ? | NO | NO | NO | NO |
| Exploit | Description | E2E | NE2E | App | DB Col | DB Cont | Disk |
YES – The encryption method is designed to protect from the attack.
NO – The encryption method is NOT designed to protect from the attack.
? – The encryption method is NOT designed to protect from the attack, but actually may be effective. Its effectiveness is dependent on specific vulnerability and how the vulnerability is applied.
PII – Personally identifiable Information (ie, credit card numbers, cardholder names, addresses, etc)
CREDIT CARD PRIMER
A 16 digit credit card number (PAN / Primary Account Number) contains public data (known plaintext) and private data. The first set of six digits is considered public/known and contains the credit card type and the bank identifier. The last set of four digits (including the check digit) are commonly used as a reference to the card by the card owner, and thus, is also considered public/known. The middle set of six digits (digits 7-12) is considered private. All that to emphasize a basic rule of cryptology: one should not encrypt public/known data along with private data. Encrypt only the middle set of six digits.
Credit Card Number Reference
TABLE DETAILS (see above)
1. E2E (End-to-End Encryption)
The private portion of the credit card is encrypted using a public key in the web browser and the cyphertext sent along with the plaintext first six & the plaintext last four via a HTTP POST to the web server. The application receives cyphertext to add to the database. The private portion of the credit card is only decrypted using a private key by the credit card processor.
2. NE2E (Nearly End-to-End Encryption, ie, Encryption in the web browser via asymmetric keys, and decryption upon hardened egress)
The private portion of the credit card is encrypted using a public key in the web browser and the cyphertext sent along with the plaintext first six & the plaintext last four via a HTTP POST to the web server. The application receives cyphertext to add to the database. The private portion of the credit card is only decrypted, using a private key, on a hardened egress server prior to sending the plaintext credit card number to the credit card processor.
3. App (Encryption by Application)
The private portion of the credit card is encrypted once received by the application. The cyphertext is then sent to the database server. The private portion of the credit card is decrypted by the application which in turn sends the plaintext credit card number to the credit card processor.
4. DB Col (Database Columnar Encryption)
The private portion of the credit card is encrypted once received by the database (the application provides the data and a symmetric key). The private portion of the credit card is decrypted by the database when queried by the application (the application provides the key). The application then sends the plaintext credit card number to the credit card processor.
5. DB Cont (DB Container Encryption, ie, Transparent Database Encryption or DB Data At Rest Encryption
In a TDE system, plaintext versions of the private portion of the credit card are INSERTed or UPDATed. No key from the application is necessary. The application (or anyone with the proper access) can SELECT the plaintext version of the private portion of the credit card number without needing to provide a key. TDE encrypts database containers such that all backups are encrypted even if explicit backup encryption is not used. Also, if the containers are ever unmounted form the database, they would be unreadable. Tempdb containers are encrypted, but information in buffers is not encrypted. Note, database containers, being opened exclusively by the database engine, are never (or very, very rarely) attacked. Therefore, if proper backup encryption is used, TDE provides no (or very, very little) protection. See my 13-Nov-2015 BLOG post describing the hassles of TDE, and why I recommend it never be used. Use standard backup encryption and disk encryption instead.
Please comment below if you know of a published attack that was a result of reverse engineering database containers. Please provide a source as I’m very interested.
6. Disk (Disk Encryption, ie, BitLocker)
Disk encryption encrypts the entire hard drive. This is protection mainly for notebook/portable computers that, once powered town, can not be booted (or the disk contents read), until a key (usually made available using the user’s password after a successful login). On a server, which is very rarely powered down, this would protect against the hard disk being discarded without being wiped.
Database backups should be encrypted by the standard backup utility. Do not rely on other encryption to protect backups.
KEY MANAGEMENT
DATA IN TRANSIT
Data in transit should always be protected by a current TLS (formally SSL) architecture. This includes transmission internally, and between data centers (even over leased lines). Google recently discovered preying eyes on fibre optic communications between data centers and has since implemented full TLS encryption. Even though the Google breach involved government actors, a lone telecommunications technician would be capable of doing same.
HOW TO AVOID PCI & AVOID ENCRYPTION
First consider what it will do to your company’s reputation. Would you be be seen as a lessor competitor when you’re not willing to take on the security of credit cards? What about other data? If another company experiences a breach with your data, do you escape the reputation hit… after all, it is your data? Why would anyone come to you when you’re not willing to undertake the additional security required to handle credit cards, especially when they can go to your competitor that is marketing their world class data security.
If the reputation is not an issue, consider outsourcing the credit card tokenization functionality completely. Credit Card Tokenization Services are a dime a dozen. Companies like CyberSource will do that for you. Your company then would simply process tokens rather than credit cards. No encryption, no creation/maintenance of complex software, etc. No risk? Not. Just be sure you understand the risk when your data is involved.
When must you outsource? If your company does not have a Corporate Information Security Steering Committee (CISSC) with a clear executive level charter, outsource the credit card tokenization. Without such a committee empowered by an executive charter, it will be difficult to make the necessary decisions related to security.
SUMMARY
Careful analysis of the enterprise is required. Is reputation an issue? Is security an issue? If appropriate, outsource the credit card tokenization to a third party. If outsourcing is not an option, consider the best possible encryption architecture for which the organization is capable. End-to-End Encryption is considered the best architecture (see above table). Don’t forget key management, backup encryption. Follow the Policies, Standards, and Procedures provided by your CISSC!
