IT Governance Policy Project

advertisement

OWLS, INC.

Social Security Number Policy

Abstract

This policy is a living document that guides and dictates our company approach towards the safety and security of the Social Security

Numbers of our employees and customers. This document outlines the approach we have taken to protect that security and to that end we have included the controls put in place to ensure that the security and safety of our employees and clients and their personal information are never compromised.

Ariana Levinson; Shakiya Lisane; Marcus Wilson; Vu Do

Reason for Policy:

The organization is committed to providing awareness and guidance on the storage, use, and transmission of social security numbers (SSNs) to help deter and prevent identity theft. This policy will outline the framework and controls to enforce that framework in all actions involving SSNs.

This policy will apply to all SSNs that are associated with full-time employees, internal and external contract or temporary employees, thirdparties, and customers. Failure of compliance with this policy can result in disciplinary and legal action.

Policy Mission:

Protect the storage, use, and transmission of SSNs

SSNs will be permitted to be collected only as justified by business or law. SSNs must be stored securely using encryption and masking methods for electronic materials and in an appropriate secure area for all physical non-electronic material. SSNs are not permitted to be used in non-secure data fields such as comments, notes, and other open text fields that are not marked as SSN fields. SSNs should not be included in any electronic communication such as e-mails, e-mail attachments, or instant messaging.

Increase the overall awareness of the sensitivity of SSNs

The organization will continue to promote awareness of the sensitivity and proper use of SSNs. SSNs will not be assigned to individual employees or customers as a unique identifier. Customer identification numbers and employee numbers should be used for identification in applications and databases. There are resources available on the company intranet to outline the process for selecting an appropriate unique identifier for both customers and employees.

Prevent the exposure of SSNs in the event of a security breach

The organization is dedicated to preventing a data loss or breach by taking the necessary steps to limit the company, employee, thirdparty, and customer exposure by protecting the SSN data that is collected by the company.

Compliance with local, state, and federal government mandates

The organization will adhere to government procedures and polices when it comes to the required collection and storage of SSNs for employment, tax, and other purposes mandated by law.

Maintain customer trust in regards to data privacy and security

As an organization we respect our customers’ privacy and confidentially of their personal data which includes SSNs. We will follow this policy and continue to hold ourselves accountable for the SSNs that we collect.

Policy Audience and Responsibilities

Employees, Stakeholders, and Management Acknowledgement of policy and compliance

Customers Informed of policy

Control Objective 1: Technical Security of SSN Data

Control

Number

Control

1.1

1.2

Masking SSNs: SSNs should only be visible in the following format: xxx-xx-1234. Only the last four numbers should be visible. This

Encrypting SSNs: SSNs should be strongly encrypted. Partial masking is not enough.

1.3

Policy Controls

In order to ensure the safety and security of our employees and clients (and their information), specific controls have been implemented across the company. They are broken down into several different categories that are laid out in the table below. Any employees found to be intentionally violating any of the policies and controls laid out below will face severe disciplinary and legal action.

Protecting SSNs: SSNs should be stored on internally facing servers behind a firewall.

Explanation

Ensuring that only the last four digits are visible will reduce the risk that someone within the company who has access to SSN data could take the number and commit identity theft. Careful vetting of employees is not always enough.

If a malicious individual were to hack in and take SSNs, they should be encrypted and completely unreadable. Knowing that they would be completely unreadable even if they were taken is an extra vote of confidence towards our company in an age where data breaches are common place and identity theft has become a normal occurrence.

This is very sensitive data and as such it needs to be well protected. The servers hosting this data should be internal and they should be behind a firewall; a hacker should not be able to get in from the outside.

1.4 Vulnerability Scanning: Vulnerability scans should be run on any systems that host SSN data and any critical vulnerabilities found (CVSS 4 or 5) should be remediated within 30 days of discovery.

Hackers and other malicious individuals are constantly coming up with new and creative ways to break into systems or exploit vulnerabilities that already exist. No system is perfectly secure and vulnerability scans are required to find the most critical vulnerabilities so that they can be remediated. The NIST Common Vulnerability Scoring System (CVSS) is a well-known and well respected metric for assessing vulnerability. Any vulnerability found with a CVSS score of 4 or 5 is considered critical, and should be remediated as soon as possible. This policy specifies that they need to be remediated within 30 days of discovery.

1.5

1.6

Secure Data Entry: Any methods of data entry that will be used for SSN data must be secure.

Backups: Periodic backups should be done regularly, tested, and secured.

Any websites, applications, databases, etc. through which users are asked to enter their SSN information should be secured. All websites used for data entry should be at the very least encrypted using TLS (HTTPS).

If data were to become corrupted or a system was to fail, current accurate backups will be required to restore proper functioning and data integrity. To that end, data should be backed up regularly and a test restoration should be performed at least quarterly to ensure those backups are actually usable. Furthermore those backups need to be properly secured whether they are stored physically or electronically.

Control Objective 2: Reducing SSN Usage to Reduce Risk

Control

Number

Control

2.1 SSN Usage for Authentication: SSNs should be used as little as possible for user authentication

Explanation

When a customer calls or an employee must verify their information, the individual should only be asked for the last 4 digits of the SSN. Ideally a different type of authentication should be used instead of SSNs i.e. pin, challenge questions, etc.

Control Objective 3: Logical Access Controls

Control

Number

Control

3.1

3.2

3.3

3.4

3.5

User Registration: Access is to be granted on an as-need basis, and terminated users must have permissions removed within 2 business days of termination.

User Rights Review: The list of everyone who has access to view SSN data should be reviewed quarterly and signed off on by the business owner

Non-Disclosure Agreement: All users are required to sign a non-disclosure agreement

Security of Physical Data: Any forms, papers, etc. that has SSN data on them should either be securely locked up or cross-shredded once they are no longer required.

Security of Infrastructure: Any servers that are used to host SSN data must be properly secured.

Explanation

New users should only be provisioned the permissions they need to do their jobs and no more according to the principle of least privilege. If a user does require access to sensitive information (such as SSN data) that access must be approved directly by the business owner and documented.

When a user is terminated, IT must remove their access within two business days following the termination. If access is not removed timely, a disgruntled employee could get into the system and cause significant damage (including the theft and disclosure of SSN data).

The same is true of transferred users – if a user is promoted or demoted and their access needs change, their permissions should change to reflect that within two business days.

This review is used as a secondary control in the event that provisioning and deprovisioning controls fail. Every quarter a list of all users who have access to SSN data should be reviewed by the business owner to ensure that those individuals still require those permissions. If the

Business Owner sees an individual on the list that no longer requires that access, he or she should submit a ticket to IT requesting that access be removed as soon as possible (within two business days).

All users regardless of position or assigned permissions will be required to sign a non-disclosure agreement that includes a clause about SSN confidentiality. NDAs should be completed digitally and then archived as a permanent record available for retrieval.

If a new employee or customer was asked to fill out any forms that included a request for their

SSN, that form should either be securely locked away, or preferably destroyed via crossshredding once the information has been entered into secure digital record. If papers with SSN data are not properly destroyed, anyone so inclined -including a regular office employee who just comes across the papers - could use the information on them in a malicious manner.

The physical servers themselves that host SSN data must be secured. Only authorized individuals should have access to servers and there should be multiple layers of security.

Download