Issue Description:
The University has mandated eliminating collection and use of
SSN as a primary identifier except where a legitimate business
need exists. The SISS Office must secure the data, making it unavailable
to all but the small number of users across functional areas whose
business practices require access to SSN data.
When Dr. Trask issued the Social Security Number policy last year,
SISS had over 1300 users able to view the SSN. Of those users,
approximately 150 had the ability to update that data. Our solution
reduces to fewer than 100 the number of users having any access
to the full social security number.
Our first step in securing the SSN via the application relied
on newly-delivered security functionality in Peoplesoft. DDA (Demographic
Data Access) security allowed us to mask all but the last 4 digits
of the SSN on certain pages, and we applied that security immediately
to search results throughout the system.
This left us the remaining tasks of:
1. Establishing a SISS-specific policy for reasonable use while
following the intent of the university mandate;
2. Completing the job of securing the application, not just in
the search results but in the Bio/Demo data pages as well;
3. Analyzing incoming and outgoing data for SSN occurrence and
if present, determining whether there is a “compelling need.”
Reasonable Use:
Social security numbers will continue to be collected
by Admissions offices for the benefit of Financial Aid users and
for the purpose of matching records to incoming data from sources
including but not limited to: electronic and paper applications,
academic testing agencies, recruiting services.
Some users in Admissions, Financial Aid, Student Financials and
Student Records will have the ability to view and update the SSN.
Some will have the ability to report against SSN data. Some specific
reports requiring SSN have been identified to be: Pell, NSLDS,
National Student Clearinghouse, 1042S, 1098T, and most student
loan reporting going out to lenders.
For the sake of establishing a starting point as well as standardizing
the process of assigning this security, the SISS security administrator
will reduce the number of users with “SSN view/update security”
down to the 93 who currently have correction rights to the Bio/Demographic
data. The rationale is that these users are already in a position
of trust. We’re also going to work with those departments
to determine whether any additional reduction in those numbers
can be accomplished.
For reporting, we are segregating all tables containing SSN into
a distinct group for which security can be assigned on a case-by-case
basis. We are communicating the University policy to departments
and prompting them to begin the process of removing SSN data from
reports.
Table access will be much more tightly controlled than page access
because a user could produce a report with thousands of social
security numbers along with supporting personal data. This poses
a greater risk to the confidentiality of SSN data than someone
who can access the data one record at a time.
We propose limiting table access to key users in the central
and SISS offices, with a small number of users distributed out
among the school offices. This would allow for tighter controls
with a reasonable fallback. If the local user responsible for
this data was unavailable at a critical time, the Registrar’s
Office or SISS Office could act as backup and provide the service.
Securing the Application:
In order to lock down access to the SSN via the Peoplesoft
pages, we are cloning an existing page to create a new page for
the purpose of entering and updating this data. This allows us
to separate out that activity from all other data entry activity
and to more easily limit user access. The “power users”
mentioned above will be granted specific rights to this page and
will be responsible for that data in their respective offices.
This allows other permanent and temporary staff to update all
other Bio/Demographic data without ever seeing the SSN. We will
be able to easily report on users who are updating the data and
we’ll continue to have an audit record on specific activities.
Incoming/Outgoing Data:
We have been in contact with all recipients of data
extracts containing SSN and we are already engaged in removing
it from those extracts we’ve so far identified. There are
a few recipients who are requesting that we continue to provide
SSN data until certain data dependencies are worked out across
units. In cooperation with the IT Security Office we established
a procedure for documenting and evaluating these requests. IT
Security will follow up with those offices.
In Conclusion:
The SISS Office anticipates meeting the University’s
June 30th deadline in restricting access to the social security
number by either masking or removing it in every context within
our control. The few exceptions to this expect to have alternatives
in place before the end of the summer, and in all cases will be
closely monitored by the IT Security Office.
symbol require