The fine line between not encrypting your databases and breach notification
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
Premium Access
Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy
Dig Deeper
-
People who read this also read...
This was first published in February 2009
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 Dummiesand Hacking Wireless Networks For Dummies(Wiley). He's also the creator
of the Security on Wheels information
security audio books and blogproviding security learning for IT professionals on the go. Kevin
can be reached at kbeaver@principlelogic.com.
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.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation