EDGC Decision Date: August 12, 2024
Decision
Implement a reversible encryption approach in the Person API to transmit SSN and ITIN to approved API consumers (i.e., SIS), with a key rotation endpoint requiring rotation at least every 90 days.
Background
The Person API will begin to express SSN and ITIN, both considered restricted data elements, to limited API consumers for the purposes of identity matching. Universities of Wisconsin Student Information Systems are expected to be the sole consumer of this data, aligning with current SIS data usage in PICH.
These data elements will be secured with an additional permission that will only be granted to approved API consumers (i.e., SIS); this permission will be required for SSN and ITIN to be present in Person API data, else it will be excluded. API consumers will continue only to see person data from institutions for which they are authorized.
Given the restricted nature of this data, several technical mechanisms for securing SSN and ITIN were considered with the most prominent being reversible encryption and tokenization. Reversible encryption is a means to transmit SSN and ITIN as encrypted values to the API consumer whereby only that consumer can decrypt the value to its original form with a unique, rotatable key. This method can be achieved by PeopleSoft-based Student Information System API consumers today.
Tokenization is a means to transmit an irreversible hashed value, or token, to the API consumer. As compared with reversible encryption, tokenization would require additional time to validate the approach between Person API and SIS. This approach would also require more infrastructure to retrieve tokenized values for SSN and ITIN when needed for any business process. It would also require SIS to stop storing raw SSN and ITIN collected through their normal business operations to achieve its full security benefits.
SSN and ITIN data will be stored in the Person API data store in an encrypted state. Additionally, all person API data is encrypted at rest through Google Cloud Platform’s managed database service. We also plan to exclude these data elements from the request form so that requests for access are limited to critical consumers like SIS.
Recommendation
Use a reversible encryption approach to transmit SSN and ITIN to approved API consumers (i.e. SIS). Universities of Wisconsin Student Information Systems already store SSN securely in their systems, so this approach balances security, practicality, and time to implement. SIS developers have validated they will be able to implement this mechanism, and the Person API team will be able to deliver the work in fall 2024.
This mechanism will also implement a key rotation endpoint that will allow SIS to programmatically change encryption keys on some interval to enhance security and ensure that only the intended API consumer may decrypt SSN and ITIN data. The API team proposes a 90-day maximum encryption key lifespan, but this may be changed according to EDGC guidance.
Who developed the recommendation?
- This recommendation was developed by:
- Charlie Calderon, Associate Director for Enterprise Integration, UW-Madison
- Jon Terrones, Product Management Lead for Enterprise Integration, UW-Madison
- Jared Kosanovic, Enterprise Integration Architect, UW-Madison
Who was consulted in the development of the recommendation?
The following stakeholders were consulted:
- Allison La Tarte, Vice Provost for DAPIR, UW-Madison
- Scott Owczarek, Assoc. Vice Provost and Financial Aid Director & Assoc. Vice Provost and University Registrar, UW-Madison
- Lisa Johnston, Director of Data Governance, UW-Madison
- Catharine DeRubeis, Director of Human Resources Information Services, UW-Madison
- Joe Tarter, Director of Application Infrastructure Services, UW-Madison
- Tom Jordan, Solutions Architect, UW-Madison
- Phil Hull, Data Strategist & Steward, UW-Madison
References
Appendix
| Case | Business Process / Workflow Implications |
| Instructors/advisors received from PICH (current state) without a match | The UW-Madison RO runs into a couple of these a week. Staff manually search using information from PICH including SSN, birthdate, and gender to determine if someone exists in SIS and if so, add the instructor/advisor records, or if not, create a new record. |
| Staff who need a new SIS account | Some are sent through PICH with a SIS ID but many are not. These also require manual matches to determine if they exist in SIS or a new record needs to be created. We often run into some with an older SIS record whose last names are different, or those with no matches so a new record must be created. Frequency is a couple a month. |
| Person exists and we do not have enough to match on we create a new ID | If the person exists and we do not have enough to match on, we create a new ID; this often results in the person having instructor or advisor data in one record, and their former student data in another. The same is true if they are created as a new person when a SIS account is created resulting in duplicate SIS records. Their self-service access may be in one record, and their employee access in another. They may ultimately be linked in the Person Hub with one HR record, and two SIS records (a faculty/advisor and a student). If going through MyUW, the SIS record last touched is the one the data is pulled from. This can result in someone seeing instructor/advisor/student access one day, then their employee records the next. It can go back and forth until the duplicate records are resolved in SIS. Frequency is less than the examples above but more impactful for the student/employee experience. |