SQL Server with Mr. Denny

Jun 29 2009   7:37PM GMT

If I wanted to learn the law, I would have been a lawyer

Denny Cherry Denny Cherry Profile: Denny Cherry

So your probably a lot like me, you were a teen who liked to play with computers and you managed to end up in IT.  This is awesome you figured, I play with computers and someone actually pays me for this.

During the 90’s life was good, there wasn’t any regulations to deal with, you followed best practices to the extent that the company you worked for could afford them.  Change control usually consisted of sending out an email saying “Hey, were going to change a bunch of stuff, nothing should break.”.  Today however things are different, very different depending on how large the company is that you work for, and if your company is public or private.

Today I work for a private company, so we are able to run things much like the “good old days”, but most are not so lucky.  Change control processes are cumbersome at best, and the number of legal compliance issues that we have to not only be aware of the existence of, but actually understand is quite daunting.  You’ve got everyone’s favorite SOX which says that lots of stuff needs to be controlled and duties must be separated, but doesn’t give any sort of guidelines as to how to do this, or what duties should be done by who.  If you take credit cards over the web, or process credit cards over the web then you’ve got PCI (which I’m dealing with now on our shopping cart server).  If you work for a company which stored medical records then got help you when it comes to HIPAA.  For those that aren’t aware of HIPAA part of it basically says that every lookup to medical records has to be logged.  Within an application that’s easy.  Windows SQL Server 2008 that’s easy, but what about the legacy SQL 2000 medical application?  It provides no guidance other than to say “do it”.

I remember that when Windows 2003 SP 1 was released (it may have been SP 2) there was a thread on a forum somewhere (probably tek-tips.com) where we were discussing SP1 and HIPAA.  Somewhere in HIPAA is says that you have to keep your systems patched.  Somewhere else it also says that systems which stored medical information on there cannot report data back to a vendor.  Well SP1 introduced code that would allow a sysadmin to have the server report usage and error data back to Microsoft.  So which part of HIPAA should you violate?

On top of all the federal regulations, states are now passing data encryption laws which have to be dealt with.  Here in California we’ve had data encryption regulations in place since 2003 or so.  At several companies that I’ve worked at the IT managers didn’t know anything about the law and what it meant.  The law here in California is so vague that it is almost meaningless.  It says (in laymen terms) that if your data is breached, and the data isn’t encrypted then you have to tell your customers either directly or via the media.  But it doesn’t define encryption, or how strong that encryption has to be.  It at least defines what data items it includes (name, address, username, password, social security number, etc) but if you take the law at face value doing a simple character replacement is sufficient to comply with the law.  While this complies with the letter of the law it obviously doesn’t comply with the spirit of the law, but the letter of the law is what matters in court.

Having to keep track of all these laws which apply to us is mind boggling at best, and impossible at worst.  And reading the laws is amazingly painful.  The California law I sited above, which I’ve read several times, still confuses me to no end; and I’ve reviewed it with the legal team at one company already due to a data breach.  And consider that there are data encryption laws in several states, all of which you have to comply with if you have customers in that state, or if you do business in that state.  I have no idea which states have these laws, or even how many states have these laws.  Even if I did, I’d then need to find the overlaps and the exceptions, then figure out how to build our database to meet these laws.  Beyond that I’d have to anticipate the future laws that could be coming in the other states and account for those potential laws at the same time.

At this point handling the database design is just getting more complex.

Now the new Transparent Data Encryption is great for handling data at rest.  It keeps your backups all encrypted and save.  But what happens when the bad guy breaks in and swipes the data by logging into the database.  Yea the data is encrypted on disk, so technically we are covered, but the data is still out there and usable because the bad guy was able to login as a database user with select access to the tables and dump the data to his system via a SELECT statement.  What has to happen now?

I don’t know about you, but I got into this field so that I wouldn’t have to worry about stuff like this.  I guess those times are over with.

This rant is now complete.  See what happens when I get on a plane at 6:30am and the nice lady starts poring coffee down my throat for the entire flight.

Denny

1  Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
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
  • Chrissie1
    in court the letter of the law is of no importance. It's the interpretation of the judges that count and the day of the week. you can also choose not to incrypt and when your data is stolen just post a messag on your blog (which can be considered the media) or a little add in your local newspaper stating all the SSN's and creditcardnumbers of the people that were affected. BTW chrissie doesn't blog there anymore ;-)
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: