Storing Social Security Numbers

Question

The HR department at the company that I am currently working for has requested that I provide a system for storing employee social security numbers in our company database. The

Answer 1

Don't use the SSN as a primary key or otherwise proliferate their values any more than necessary. Use employee ID numbers or other unique-ID's generated. This will reduce the complexity of the problem.

If at all possible, keep the SSN's in a complete different database instance and do not allow it to be accessed by the day-to-day functions of the external application.

Once you've isolated the SSN, you can use any of the suggested methods to encrypt the data. Encrypting the physical tables and encrypting the stored-fields will make it harder for someone to steal the physical database files or to view SSN's using basic SQL access.

The main concern is to limit access to the SSN table through DB mechanisms, limit OS access, and secure the machine physically. Through the DB, use the most constrained permissions possible. Do not allow web, online, or other "shared" accounts access to the table if at all possible. On OS access, limit logins and directory access to a well known list of users. Turn on any and all auditing possible. As far as physical security, the machine should be in a locked/secured location.

Follow NSA guidelines on computer security where the SSN's are stored and any machine that has access to that machine.

Since you are just a small company, you don't need to worry too much about keeping mailing supplies and funds/insurance for identity monitoring in the event of a breach. Organizations with large numbers of employees and/or customers have faced significant challenges in meeting the legal requirements for breach notification. Finding 26 million envelopes on short notice isn't easy.