Friday, February 20, 2009

A Business Analyst's Guide to Encryption

First, let's make sure everyone understands the topic; WikiPedia defines encryption thus:
In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.
Sounds pretty easy, right? Encryption is part of the practice of cryptography, defined like so:
Cryptography (or cryptology; from Greek κρυπτός, kryptos, "hidden, secret"; and γράφω, gráphō, "I write", or -λογία, -logia, respectively)[1] is the practice and study of hiding information
Broken down into the most simple explanation encryption is the process of hiding information whereby information that is humanly readable has some algorithm (or mutation) applied to it to it to make it meaningless without the secret key, which is usually a string of characters of some kind. The first and most early form of encryption is attributed to Julius Caesar, when information needed to be passed across a battlefield and had to be unreadable by the enemy in case it was intercepted. The code involved taking the alphabet and shifting it a certain number of positions to the right of left. If the key was R3, it meant that the letter a became a d, and the d became a g, and so on... thus you could write khoor and it would be translated back to hello. But enough history.

Modern cryptography involves creating a cipher that cannot easily be cracked by a computer, so extremely complex algorithms are applied, and tested against brute-force breakage. You've likely heard of some of the most common ones, namely 3DES, DES, AES and others. These are all of varying strengths, meaning, it takes varying degrees of computational capability (typically beyond the lifespan (usefulness) of the message) to crack the code and discover the message.

Now that you have a foundational understanding of cryptography, encryption and ciphers... let's address this all from a business angle. When you read regulations like PCI (Payment Card Industry) Standard, or HIPAA, or countless other industry-specific regulations which specifically call out information protection, you will read about encryption. Encryption is typically mandated, but it is rarely defined properly for implementation in the business context.

To be clear, there are two cases when you, the business analyst or project manager, will need to care about encryption:
  • Data in motion - This involves data moving from one place, to another, generally when data is being moved across systems. This data could be anything from pin codes, to IP addresses, to anything you can think of... on the wire, in transit, between two (or more) points. The reason this distinction is important is because data in motion is the most common type of encryption that is in use on the Internet. You may already know it... as SSL (or Secure Sockets Layer). SSL is the most common way that encryption is presented to users of systems, and presented as a security measure to safeguard information traveling from point to point across untrusted systems.
  • Data at rest - Data at rest isn't moving. While this may sound obvious, it means that it is currently being stored or manipulated by a single system, contained witin that closed system without traveling outside it. This type of data can be written to a USB key, in memory, or on a CD Rom. Data at rest doesn't have the threat of being intercepted when traversing a hostile segment, but it can be transported with the storage medium as in the case of a CD Rom.
Now that you understand those 2 very distinct types of encryption situations... think about which one generally gets used the most, and how extensively. I'm willing to be that when someone says encryption, the first thing you think of is SSL. SSL and that golden lock in the bottom-right corner of your browser immediately inspires trust that the information you're typing into your browser is secure.


All that means is that once you hit the submit button, the information (if encrypted properly) cannot easily be intercepted, and understood if plucked off the wire. Think of the likelihood of someone getting in-between the server you're connected to, and yourself. Think of how difficult it would be to slip-stream an intercept into that connection. Now think about your browser. Think about the browser you're typing your credit card into. Your precious information, as you type it, sits in that browser's memory in the clear, meaning anyone (or any thing) can read it.

So let's say you're on your favorite web site, buying your favorite book or widget. You look for that golden lock and once you see it you assume you're safe. You then diligently enter all your credit card information which your browser packages up, and sends across the internet in the clear. The sticking point here is that due to SSL Encryption, the tunnel the data passes along is encrypted. This does not mean your data is encrypted.

As an analogy, imagine you're sending a package using FedEx (or whom ever you like to ship with). Since you're shipping a letter that's super-secret you want it to be safe from prying eyes. If you were to use the physical equivalent of SSL encryption, you would put your letter in a metal box, put a lock on it and both you and the partner receiving the package would have a key. You're assuming the carrier wasn't going to pry open the box. But... ask yourself what if. What if that carrier pries open the box - your information is now able to be ready by anyone who wants to read it!

Now let's assume that rather than tackling that from a position of data in transit which you just did, you want to tackle the problem from a position of data at rest, meaning that you don't care if the letter is being moved or on your desk... you use a cipher to make sure that unless someone has the key they can't read it... even if they do pop open that lock while it's being transported.

Does this set off any alarms in the back of your mind? It should. Most businesses only tackle data security using the notion that data only needs to be encrypted while it's traveling... but this obviously doesn't account for the endpoints. So what if the data is safe as it travels along the tunnel between your server and your partner... what if your partner's server gets hacked and someone steals everything off that server. You just had your information stolen! If you had applied encryption to the data at rest then you wouldn't care!

What I am hoping to enstill in you is this: if you have the data you're safeguarding encrypted at rest it doesn't matter if you're using SSL or plain-text transfer, or if the information gets intercepted, or stolen... it won't be any good to anyone. Using SSL on your web servers and leaving your databases completely unencrypted is not just irrisponsible, but border-line negligent, given what you now know. All the SSL in the world won't protect your database (with precious customer data) should someone hit you with SQL Injection and steal all the information right through your web application.

So let's review... we have data at rest, and data in motion. If you're already using encryption for data at rest, then things like SSL and encryption for data in motion is just icing on the cake... make sense?

(in your databases, flat files, on disks... otherwise...)

No comments: