The fine line between not encrypting your databases and breach notification

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.

More on SQL Server security and compliance Meet compliance with improved database security practices  Logging for security compliance in SQL Server

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 independent information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC where he 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. Copyright 2008 TechTarget

Rate this Tip To rate tips, you must be a member of SearchSQLServer.com. Register now to start rating these tips. Log in if you are already a member. Digg This!     StumbleUpon     Del.icio.us    RELATED CONTENT SQL Server Security Meet compliance requirements with improved database security practices Hardening the network and OS for SQL Server security Securing the server and database in SQL Server SQL Server security made simple and sensible Blog: Protect your databases from the internal threat Setting up SQL Server Service Broker for secure communication The keys to database backup protection for SQL Server Understanding transparent data encryption in SQL Server 2008 Securing SQL Server with access control, login monitoring and DDL triggers SQL Server security: Controlling access via database roles SQL Server Database Compliance Meet compliance requirements with improved database security practices Understanding transparent data encryption in SQL Server 2008 Sarbanes-Oxley compliance checklist: IT security and SQL audits SQL Server 2008 security and compliance features reduce security risks Security testing for compliance – just how much do you need? Logging for security compliance in SQL Server Expert: Lengthy logs not always a good thing Licensing concerns when upgrading SQL Server Are you ready for a compliance audit of your SQL Server database? Database Management and Administration Using traces in SQL Server Profiler Meet compliance requirements with improved database security practices Hardening the network and OS for SQL Server security Securing the server and database in SQL Server How SQL Server 2008 components impact SharePoint implementations Troubleshooting Distributed Transaction Coordinator errors in SQL Server Achieving high availability and disaster recovery with SharePoint databases Clearing the Windows page file and its effect on server performance Deploying a SQL Server virtual appliance for Microsoft Hyper-V How to create SQL Server virtual appliances for Hyper-V RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary data corruption  (SearchSQLServer.com) data hiding  (SearchSQLServer.com) RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.