Signing On for FSA Systems Tokens/Two-Factor Authentication and Modifications to User Sign-on in 2013 Bridget-Anne Hampden U.S. Department of Education

Contents Need Objective Comprehensive Security Strategy Approach Achievements Two-Factor Authentication Technical Proof of Concept Modifications Lessons Learned Feedback Next Steps Questions 2

Need The registration and sign-on for FSA users required a more improved process which still maintained security by: – Simplifying access to FSA systems with single (reduced) sign-on – Creating a standardized solution supporting the entire user community and all business systems – Removing Personally Identifiable Information (PII), such as the current use of Social Security Numbers (SSN) and Date of Birth from log-in – Maintaining a consistent data security posture across all FSA systems 3

Need Previous authentication processes did not address the distinct needs of two very different user groups and FSA: – Privileged Users (partners, schools, etc..) Need to maintain tens/hundreds of FSA user accounts Centralized provisioning – Non-privileged Users (applicants, borrowers, parents) Use of Personally Identifiable Information (PII) in non-privileged (applicant or borrower) User IDs and passwords Ability to provide self service features to the non-privileged users (change password, retrieve username, etc.) Ability to separate authentication and e-signature credentials – FSA Need for centralized operations and management, and audit and reporting capabilities Need for two-factor authentication 4

Objective The Objective of EIMS is to: “make provisioning and access management for FSA systems more efficient and secure for both privileged (partners) and non-privileged users (students/borrowers).” 5

FSA Comprehensive Security Strategy INITIATIVES STRATEGY Security Governance Audit Privacy / Data Protection Trusted Internet Connection (TIC) COD behind TIC / Einstein IPS Enterprise Identity Management Services (EIMS) COD/PM/AIMSPINPRMSSoft Tokens Two Factor Authentication TFA deployed for privileged users Network Intrusion Detection / Monitoring 48 Month Timeline 6

Approach Phase 1: Place all FSA Privileged user systems [e.g. National Student Loan Data System (NSLDS), COD, eCampus-Based System (ECB)] behind a single authentication application (AIMS) which uses one FSA ID and password Phase 1a: Implement two-factor authentication Phase 2: Leverage PM system for COD online enrollments and provide privileged users a single FSA ID for COD and other FSA Systems; test use of Federated IDs Phase 3: Create non-identifiable standard FSA User IDs and passwords for students and borrowers to access FSA systems Phase 4: Move from physical (hard) tokens to the use of soft tokens 7

Achievements Phase 1 – Migrated over 60,000 users to a single FSA ID and password – Consolidated authentication of FSA Privileged user systems (e.g. NSLDS, COD, ECB etc…) behind a single authentication application (AIMS) Phase 1a – Responded to a requirement from OMB to provide additional safeguards for PII data – Modified nine FSA Systems to integrate with Two-Factor Authentication (TFA or hard tokens) – In-process of distributing hard tokens to privileged users (to be completed by Fall 2013) 8

Achievements Phase 2: – Consolidated provisioning through the PM system for COD online enrollments – Re-permissioned over 32,000 COD online users between March and June 2013 – Reduced the number of COD User IDs to a single FSA ID for COD and other FSA Systems – Conducted technical proofs of concept to ensure the feasibility of proposed functionality and scalability of AIMS for Phase 3 9

Achievements Phase 3: Developed requirements for a consolidated authentication and access management system for over 80 million non-privileged users which would: – Implement a User ID and password that does not include personally identifiable information (PII) – Allow for the self service capability to change passwords, retrieve username, etc. – Be scalable for future expected growth – Deploy in late Fall 2014 Began government acquisition process by releasing a Request for Proposals (RFP) 10

Two-Factor Authentication (TFA) Objectives Comply with OMB M which requires the safeguarding against the breach of Personally Identifiable Information (PII) Implement a security protocol which requires all authorized users to enter two forms of authentication to access FSA systems Authentication is made through a hard token derived password accompanied by a User ID and password 11

Two-Factor Authentication Results Modified nine systems to accept new protocols Deployed TFA in 35 countries and the US Deployed tokens to and enabled over 57,000 privileged user accounts – Including Post Secondary schools, Guarantee Agencies, TIVAs and NFPs In process of deploying and enabling Third Party Servicers and Lenders 12

InCommon Federation Technical Proof of Concept Objectives Demonstrate the ability to participate in the InCommon Federation as a Service Provider Identify and document the identity federation scenarios (use cases) for a university user Verify the university user’s login will allow the user to access an FSA application protected by FSA’s Access and Identity Management System (AIMS) Conduct test with the University of Maryland-Baltimore County (UMBC) and Pennsylvania State University (PSU) 13

InCommon Federation Technical Proof of Concept Results Configured AIMS as an InCommon Service Provider using FSA Access and Identity Management System Configured AIMS to trust UMBC and PSU IDs and passwords, as the InCommon Identity Providers Developed user activation module to map InCommon User IDs to FSA IDs Successfully accessed FSA systems using InCommon / University User ID and password 14

Modifications: COD Changes PastCurrent Security Administrator enrolls users through COD for online access Users receive different log-ins for each school and profile Users need to log-out to change schools or profile Users only have access to report structures created for a specific school or profile Primary DPA enrolls users through PM for COD online access Users receive 1 FSA log-in for all schools and profile Users can change schools or profile without logging-out Users have access to all report structures created for any schools or profile 15

Modifications: PM Changes PM provisions COD online access enrollments Primary DPA only needs to enter user and enrollment information into one system, PM, for COD, NSLDS, ECB etc... PM is linked to AIMS which provides COD, NSLDS etc… online access authentication PreviousCurrent PM does not provision enrollments for COD online access Primary DPAs may need to enter user and enrollment information into multiple systems, COD and PM PM is not linked to AIMS for COD online access authentication 16

Modifications: Privacy and Security Improvements FSA requires that all users accept their responsibilities regarding the use of FSA systems and information as is written in the Privacy Statement and the Rules of Behavior In addition, FISMA requires that FSA track this information and provide audit information as requested On a daily basis, users are asked to accept both these statements when they first log-in to COD (or any system accepting the FSA ID) 17

Modifications: Annual Security Training Notification Users are now required to complete Annual Security Training which: – Provides an understanding of the security responsibilities associated with accessing FSA systems – Reminds users of their responsibilities to protect the information in FSA systems especially the PII data of the students, borrowers, and users – Specifies certain activities as not allowed, such as the sharing of FSA IDs For the ten (10) days prior to expiration, users are notified of the expiration of their security training when they log-in to COD If the Annual Security Training is not complete, users will not be able to access COD 18

Lessons Learned Phase 2 Needed to provide greater clarity during pre-enrollment (March – May) on which User ID to use (COD or AIMS) Extent of duplicate ID’s and the amount of time/effort required to “scrub” the data Importance of confirmation of information during enrollment in PM by DPA; mis-keying information resulted in data conflicts and need for additional account cleanup Need for greater clarity in error messages; – Users were confused when they received "Invalid User ID" error message when logging in to COD after May 5 th and thought it was a token or account issue not an enrollment issue Importance of more targeted communication with the DPA and with COD users about the pre-enrollment process 19

Feedback So, how did we do? 20

Next Steps for EIMS Complete distribution of hard tokens Complete procurement award Develop solution which will remove PII for non-privileged users Test and implement the solution (late Fall 2014) 21

Questions?

Contact Info Bridget-Anne Hampden Senior Advisor Federal Student Aid 23