230 likes | 362 Views
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
E N D
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
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
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
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).”
FSA Comprehensive Security Strategy 48 Month Timeline
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
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)
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
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)
Two-Factor Authentication (TFA) Objectives • Comply with OMB M-07-16 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
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
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)
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
Modifications: COD Changes Past Current • 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
Modifications: PM Changes Previous Current • 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 • 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
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)
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
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 5th 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
Feedback So, how did we do?
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)
Contact Info Bridget-Anne Hampden Senior Advisor Federal Student Aid Bridget-Anne.Hampden@ed.gov