Month: March 2016

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

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.

TDE Reference

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.

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.

Standards – every department should have them… every organization should have them. Written, formally approved, and easily accessible Standards are the hallmark for consistency within a business.

For the Standard to be effective, it must be supported, and, indeed, promoted by all levels, including management. For example, if management does not treat the Standards as black & white, but adds grey to the Standard by allowing exceptions by decree, the Standard may as well not exist.

The goal when creating the Standard is to create it such that it is black & white by accounting for any possible grey. Laws, ordinances, regulations, etc use legal ease to accomplish the same task, but standards should be written in the most understandable language for the target audience, with industry jargon well defined. The Standard should include an exception process to deal with any grey that is later perceived. There may even be an ‘continuous improvement’ mechanism to remove later grey.

For several reasons, it’s difficult for management to say “no, follow the Standard” to someone wanting to ‘just do it’. Management may not understand the need for consistency within aother department. They may not understand the experience brought into play, the experience that spawned the need to create the Standard. They may see it as just another roadblock, not worth the effort in complying.

Here’s an example… The Standard dictated four tiers or environments which included production. The application was to be tested in three tiers prior to production. The experience that created the Standard was that skipping most of the tiers and going directly to production was more error prone, and on average cost more time than the few hours required to properly QA the application. Frequently when skipping testing, it goes to production, errors are found, it goes back to development, then back to production… and back/forth… when just doing it right would have yielded less app downtime, and/or faster time to production. On one occasion, the app screwed up the data, and the DBA had to restore a several hundred gigabyte database up to the point of the release. The customer lost several hours of data from the point of the release until the bug was caught / the app shut down. The sad thing is, in the heat of the moment, inexperienced developers don’t understand that although it’s counterintuitive, taking a few hours to follow the Standard is almost always the faster path to production than running to their manager to see if they can force a ‘just do it’ put it in production now situation.

SO, WHAT ARE STANDARDS ANYWAY? WHAT ABOUT POLICIES, PROCEDURES, ETC

Standards are a specific formalization of a Policy or a piece of a Policy. If a Policy does not exist, a Standard is a formalization of an implied or de facto policy.

Policies are general statements from management; ie, sometimes Policies are so general that they are ‘published’ via email. Note, Policies should be general, but can be formal and properly published.

Procedures describe, step by step, how something is done to implement a Standard or a piece of a Standard (or a Policy if the Standard does not exist).

Best Practice is a suggested way of doing something given a Policy does not exist.

An example…
Policy: “Patient records privacy shall be respected”
Standard: “Access to patient records shall be audited. Access shall be granted only to those that have a need to know”
Procedure: “To request access to a patient record, obtain a ‘PT Info’ form, fill out the top portion, the ‘level’ section, and the ‘justification’ section. Turn the form into the PT Records receptionist”
Best Practice: “Request information (as a consult) from the patient’s GP”

Creating a short example is difficult! Please contribute your example/s in the comments section below.

GREY, DANGEROUS?

So, when are Standards grey? In reference to a Standard, I’ve heard the statement… “how about some grey here, life’s not black & white”. That was uttered by someone that was not willing to take the few extra hours to follow the Standard, and the requested leeway was not in the company’s best interest.

As indicated above, organizational Standards need to be black & white, with the grey accounted for in the Standard.

I see industry Standards as being deliberately grey, with an auditor or examiner turning the grey to black & white. Would an examiner’s job be easier if the Standard were black & white?

An example for which I’ve been dealing is the PCI DSS Standard by the PCI Security Standards Council. PCI (Payment Card Industry) has a person that performs audits. This person, designated as a QSA (Qualified Security Assessor). S/he has the final say with regard to interpreting the Standard.

The PCI standard Standard, IMHO, is overly grey, to the point of being ambiguous in places. Because of this, the QSA appears to have been passing audits with no real effective encryption of credit card numbers (BTW, the Standard refers to credit card numbers as PAN [Primary Account Number]).

By ambiguous, I mean ‘data at rest’ & ‘data in transit’ in a database context. Let’s first look at a file context. These terms, in the file context are somewhat well defined. A file at rest is encrypted when the file is encrypted. If the file is encrypted, it’s also encrypted while in transit. If it’s not encrypted, it can be encrypted while in transit with network encryption protocols like HTTPS. But, even the file context is somewhat grey when defining ‘data at rest’. If there is an unencrypted file on a disk that has full disk encryption active on it, is the data in the file encrypted at rest? That’s the same problem with encrypting the database container*. It offers zero protection to anyone on the running system using standard tools to view/steal the data. No protection. Zip. Nada. None! (I might add: aucun, keiner, zilch!)

Now, consider the database context. You can have data ‘at rest’ on the disk, it can be ‘in transit’ from the disk to the database engine, where it is manipulated by the engine. It can be ‘data at rest’ in the database buffers and remain ‘at rest’ there for several days depending on how busy the system is. To further add to the ambiguity, the data in a database is “logically” at rest when you INSERT or UPDATE… it’s not moving through a network, which most would call ‘in transit’. It’s ‘at rest’ “in the database”. One would view the ‘data at rest’ with a SELECT statement. Maybe we should get rid of some of the ambiguity by calling that data ‘data in use’, which the Standard does not address.

The specific example of the ambiguity: The PCI Standard requires credit card numbers to be encrypted ‘at rest’ and while ‘in transit’. The standard does not define ‘at rest’ nor ‘in transit’, and thus the standard allows credit card numbers to be encrypted with a type of encryption that encrypts the database containers (obviously ‘at rest’), and TLS/SSL when transferred through the network (obviously while ‘in transit’). That combination of encryption is ‘transparent’ to anyone querying the database.

Because the standard is grey or even ambiguous with what ‘data at rest’ is in a database context, many systems that exist today are subject to all kinds of attacks that query the database, and are protected from attacks that would reverse engineer the contents of offline database containers. This means that the Standard would not have prevented ANY of the known attacks to date. Because of that ambiguity, PCI does not guide an organization into being more secure against the most common attacks, ie, weak DBA passwords, cross site scripting, cross site request forgery, social engineering of DBA’s, privilege escalation, etc. A vulnerability that would exploit offline unencrypted database containers is so, so rare, that it does not even have a name.

So, what use does database container encryption protect? A side-effect of this type of encryption is that backups are encrypted, but backups should be explicitly encrypted by other means.  I assert that this type of encryption is dangerous in the sense that it’s being used to pass an audit/certification that is supposed to mean that there is real protection for customer data. Because the Standard is too grey, so much so that it is ambiguous, the Standard is really just theater.

Do you know of any database attacks that have been used used to attack database containers? Please comment below.

DANGEROUS? CAN IT BE FIXED?

If the PCI Standard required credit card numbers to be encrypted with end-to-end encryption (or as near the holy grail of end-to-end as is practical) utilizing industry accepted asymmetric key encryption, would that make the PCI Standard more black & white with regard to encryption? Would that offer more protection than the current standard? Would that mean less Theater? Your thought?