Problem solve Get help with specific problems with your technologies, process and projects.

The fine line between not encrypting your databases and breach notification

Neglecting to encrypt personal information in your SQL Server database can leave your organization vulnerable to certain compliance issues. Get the facts to keep you and your company protected.

Now that we're well into the era of compliance, it's important to know that we're up against more than just the HIPAAs and the PCIs of the world. A large percentage of businesses -- large and small -- now fall under the umbrella of state breach notification laws as well. At this point, 45 states have these laws, with a federal law currently in the making. This means if you store personal information in your SQL Server systems for someone that resides in one of those 45 states, then your organization may have even more compliance efforts ahead of it.

Oddly enough, I've found that many people in business aren't even aware of these state laws. Unlike the federal privacy and information security laws for financial, healthcare and other industries, the state breach notification laws center around unencrypted personal information. Those laws say that if a known or suspected security breach occurs and personal information is not encrypted, there can be consequences.

A typical outcome involves the company having to notify each and every person that was or could have been affected. That may not sound like a big deal until you factor in the costs of postage for thousands of letters going out. Even if you discount administrative costs, at the current rate for postage, you're looking at thousands of dollars for a relatively small number of individuals. This is arguably more expensive than it would've been to encrypt the sensitive information to begin with.

So how do you translate this into database and SQL Server security requirements? Well, if you take a look at most of the recommendations on the Web, some people -- most of whom have no clue about what's involved -- will tell you to "encrypt personal information." Of course it's not that simple, but nevermind the burden. The fact is that the law is the law, and it'll behoove your organization to step back and see just what needs to be done. This involves taking an inventory of personal information stored in your databases, determining which states are involved and then analyzing the specific legal requirements for each state.

I'm a big believer in the notion of not storing sensitive information unless you have to.

Those in the role of a DBA or network administrator aren't typically responsible for compliance. Still, regardless of who owns the compliance function, remember that this issue is very likely to come back to your plate eventually. In fact, it might make sense to get started on this now so you can present it to management on your own terms rather than the other way around. Given that each of the 45 states approaches this issue a little differently (data types, encryption method, security of encryption keys, etc.) you'd be wise to get others involved as early as you can. Your organization's compliance officer and/or legal counsel are the people I'd start with.

Now remember: You don't have to encrypt personal information. If you choose not to encrypt, however, be prepared for breach notification procedures and their associated costs, along with other potential penalties. Everything related to information security is a trade-out, so this is a business decision that'll have to come from the key players involved. Now is the time to start asking questions and coming up with some reasonable solutions.

Even with the encryption features included with SQL Server 2005 and improved security controls in SQL Server 2008, addressing the state breach notification requirements can be quite a headache. Sure, DBAs can encrypt fields or the entire database at the file level, but it's by no means an easy task – especially for existing systems. Unfortunately, your managers and auditors, who likely live in the world of black and white, probably don't care how difficult it's going to be to encrypt sensitive personal information in every possible location.

I'm a big believer in the notion of not storing sensitive information unless you have to, and I come across sensitive information in this context quite often. When I ask about it, the typical responses are "I didn't know we had that" or "We don't even need that any more." Let this be a motivating factor to get the ball rolling and take an inventory. Once you determine what personal information is stored in your environment, you may see that your business doesn't need to keep some or most of it. So start there.

If you discover that you have personal information on people from various states, and management doesn't want to bear the business risk, then at least you've got some new projects in the pipeline. Certainly nothing wrong with that.

ABOUT THE AUTHOR

Kevin Beaver, is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC. Kevin specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security on Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at  kbeaver@principlelogic.com .
 

This was last published in February 2009

Dig Deeper on SQL Server Security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchDataCenter

SearchDataManagement

SearchAWS

SearchOracle

SearchContentManagement

SearchWindowsServer

Close