Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

best practices for storing ssn? Expand / Collapse
Author
Message
Posted Sunday, May 18, 2014 11:40 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: 2 days ago @ 1:13 PM
Points: 286, Visits: 1,160
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?
Post #1572097
Posted Sunday, May 18, 2014 3:07 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 8:42 AM
Points: 3,014, Visits: 3,099
Hi
Swaping out real SSN with fakes will possibly cause other issues.
I used to do the same thing with scrambling the names, addresses and DOBs
Encryption of SSNs is a good option too.

Regards,
Igor




Igor Micev,
SQL Server developer at Seavus
www.seavus.com
Post #1572109
Posted Sunday, May 18, 2014 5:29 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 12:08 AM
Points: 35,366, Visits: 31,901
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?


Yes...

First, thank you for the concern. I see too many people address the subject of SSNs and other senstivie information if far too cavailier a manner to be right.

In regards to the 3rd party ERD software... If it were me, I'd give them the opportunity to make the necessary changes while looking for some other software that already gives SSNs the respect they deserve. If the original company fails to comply, report them to the Social Security Administration, the SEC, and the correct agencies for PCI and then drop them like a hot potato.

As for having such information in Dev or Staging, you simply must not or it must be encrypted in such a fashion that no unauthorized person can "see" the original. The latter of those two is a tall order to comply with.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1572115
Posted Sunday, May 18, 2014 11:41 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 21, 2014 2:56 AM
Points: 2,603, Visits: 2,061
How about creating seperate table for SSN and DOB having FK reference as empid? After that these two column can be encrypted. The purpose of creating this table is you can exlcude in rplication or after restore you can drop the table for security purpose etc.

Also other concern is the accessing this data i.e. permission to access SSN & DOB should be properly evaluated.


---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
Post #1572142
Posted Monday, May 19, 2014 9:54 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 12:14 PM
Points: 1,706, Visits: 4,848
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 

0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))

:h8Þ8 Ä

Post #1572359
Posted Monday, May 19, 2014 10:18 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 2:56 PM
Points: 13,081, Visits: 12,545
Eric M Russell (5/19/2014)
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 

0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))

:h8Þ8 Ä



This works but doesn't address the legitimate concern that this type of sensitive data should NOT be stored in clear text even in production. This type of thing should be encrypted or hashed. Hashing it only when it gets ported to a dev/test environment is only part of the solution.


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1572375
Posted Monday, May 19, 2014 10:28 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 1:53 AM
Points: 17,812, Visits: 15,738
Sean Lange (5/19/2014)
Eric M Russell (5/19/2014)
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 

0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))

:h8Þ8 Ä



This works but doesn't address the legitimate concern that this type of sensitive data should NOT be stored in clear text even in production. This type of thing should be encrypted or hashed. Hashing it only when it gets ported to a dev/test environment is only part of the solution.


Agreed, the sensitive data needs to be properly encrypted/hashed in production. Hashing the data prior to sending to dev /uat is a must. There is no good reason to have valid SSNs in a dev environment in clear text. Even having SSNs in Dev/uat that are not test SSNs is getting a bit too close to comfort for me.




Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #1572379
Posted Monday, May 19, 2014 10:32 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 12:14 PM
Points: 1,706, Visits: 4,848
Sean Lange (5/19/2014)
Eric M Russell (5/19/2014)
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 

0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))

:h8Þ8 Ä



This works but doesn't address the legitimate concern that this type of sensitive data should NOT be stored in clear text even in production. This type of thing should be encrypted or hashed. Hashing it only when it gets ported to a dev/test environment is only part of the solution.

Yes, in production, it's good to have symmetric key encryption on senstive columns, in addition to role based security and least privilege.

However, symmetric key encryption requires varbinary datatype, setting up encryption key, and then using decrypt and re-cast functions within select statements at runtime, so it involves a significant amount of re-architecture. What I've done in the past is implement a view for each table that contains symmetric encrypted columns with the decrypted and recasted computed columns, so the application or BI doesn't have to mess with that part, they just have to open the symmetric key and select from the view as if it were the base table.

For the dev and QA environment it's a lot more straightforward, just give them the hashed or encrypted columns and don't let them decrypt it.
Post #1572381
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse