security

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?