Recently, in Massachusetts a law was passed (rather silently) that data containing personally identifiable information, must be encrypted. PII is defined by the state, as containing the residents first and last name, in combination with either,
A. SSN
B. drivers license or ID card #
C. Debit or CC #
Due to the nature of the software we make, all of our clients use SQL as the backend. Typically servers will be running SQl2005 Standard or above, sometimes SQL 2008. Almost all client machines use SQL2005 Express. We use replication between client and server. Unfortunately, to get TDE you need to have SQL Enterprise on each machine, which is absolutely not an option. I'm looking for recommendations of products that will encrypt a DB. Right now, I'm not interested in whole disk encryption at all.
With regard to the regulation, there are two clauses implying when to use encryption:
Thereby, unless the database is on a laptop or portable device, it is not required that you encrypt the database itself (although there are other pieces of the regulation which apply to the data in that state). Furthermore, encryption the data in that state would not cover you for the intended purpose; when the data is in transit. I would recommend that you look into transport level security (ex:HTTPS) for adherence to that.
However, if the nature of your question is truly about getting the data encrypted at the database level, I would certainly recommend using a product like TrueCrypt, which will let you encrypt a virtual disk represented as a file in the standard file system. From a practicality standpoint, however, I would recommend that you consider field level encryption. That is, encrypting/decrypting the fields at the application/service level and storing the encrypted values in the data fields.
This is also a PCI requirement of when working with Credit Card info. You're probably looking at encrypting the actual data in the tables themselves. When I went through this I had to create new columns in the table(s), generate the encrypted data of their respective source columns, then removing the source (unencrypted) columns. The problem is then your app(s) have to change to be able to work with the encrypted data.
You will also want to turn on Force Protocol Encryption on the server.
TDE only encrypts data at rest. That's an important point. So if someone breaks into the SQL Server while it is up and running, data is unencrypted. So Squillman's approach is the only way to ensure the data is actually encrypted unless you know what keys to decrypt with. If this is sufficient (data at rest), Encrypting File System (EFS) provided by the OS is an option. This can be set on individual files, or at the folder level (better to do it at the folder level). One difference is that EFS will not encrypt the backups. Backups of TDE-enabled databases are encrypted. You would need to use a third party product like SQL LiteSpeed or Red Gate SQL Backup to ensure the backups are secured.
And with respect to Force Protocol Encryption, I wouldn't go this route. I'd rather use an IPSEC policy at the OS level using Kerberos to generate the secure tunnel. This removes the need for an SSL certificate to be installed for SQL Server to use.
If TDE is not an acceptable then your only option is BitLocker volume level encryption. To work with SQL Server in a performant manner the encryption has to be able to encrypt/decrypt a page in a file, which means it has to be able to set the encryption key in the corresponding state for accessing the offset of the page in the file. This rules out all file-level encryption solutions, because they cannot decrypt/encrypt the block X of the file w/o first decrypting/encrypting the block X-1 (to set the key in proper state).