STANDARDS, BLACK & WHITE, GREY, DANGEROUS

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?



* The encryption that encrypts database containers in Oracle and Microsoft SQL Server is called TDE (Transparent Data Encryption).

Troy Frericks.
blog 6-Mar-2016
=
Copyright 2015-2016 by Troy Frericks, http://dba.frericks.us/.
#

END-TO-END ENCRYPTION, THE GOLD STANDARD

End-to-End Encryption is an implementation of encryption. It is a method of encrypting data at the absolute soonest possible point in time and decrypting the data only at the very last possible moment. The encryption algorithm used when encrypting/decrypting is irrelevant to the definition of End-to-End Encryption. Using End-to-End Encryption means that the data is encrypted as it travels through the internet (in transit), to application servers, into databases (at rest), and out of databases, to be processed. This insures that the data is encrypted and the plain-text version is not available to DBA’s, Developers, Network Engineers, Managers, Unix/Windows Administrators, Help Desk Personnel, Storage Administrators, Security Personnel, etc. End-to-End Encryption is considered the best and most secure implementation of encryption.

A very simple example… data is encrypted by the sender as soon as the message is composed. It is encrypted as it flows to an email application on the sender’s computer. It is encrypted as it flows through the sender’s router, through the internet (and all that that entails), to the recipient’s router. It’s encrypted as it rests within the recipient’s email application. It is only decrypted just prior to the recipient reading the message.

Here’s an example that one may find in an enterprise… A credit card number (let’s call it a PAN for Primary Account Number) is encrypted by javascript in the browser just after the Submit button is pressed. The cyphertext (encrypted data) is http posted to an app server, and the app server updates a column in a database. The PAN is encrypted ASAP in this example.

To use the PAN in the above example, the cyphertext is copied from the column in the database to a server that has the single purpose of decrypting the cyphertext just prior to sending it to the credit card processor through a leased line connected directly to that server. The PAN is decrypted at the last possible moment.

Or is it? It would be better if the credit card processor would decrypt the PAN just prior to posting the charge on their system. That would be ideal, but in 2015… in the era of vintage 1928 mag stripes still on our credit cards, the credit card processors are accepting all kinds of risk paid for by their 1.5-4% fees. The processors simply will not undertake the extra effort to do decryption, manage keys, etc. They receive credit cards that are only encrypted via TLS or SSL. TLS/SSL encryption is to encrypt data ‘in transit’. It does not encrypt ‘data at rest’ like End-to-End encryption does.

Note in our enterprise example, with the given situation, data is decrypted at the last possible moment. It’s not possible to decrypt on the credit card processor’s system, so it’s decrypted on a dedicated server, just prior to sending to the processor.

End-to-End encryption is considered the best encryption because the data is encrypted while in transit, and at rest, from the moment it is sent, to the moment it is received. It provides better protection than all the other encryption methods including the ‘at rest’ database specific methods (ie, columnar encryption), ‘in transit’ network specific methods (ie, TLS/SSL), etc.

Troy Frericks.
blog 27-Dec-2015
=
Copyright 2015 by Troy Frericks, http://dba.frericks.us/.
#