Signing On for FSA SystemsTokens/Two-Factor Authentication and Modifications to User Sign-on in 2013

Bridget-Anne HampdenU.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

NeedPrevious 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 StrategyINITIATIVES

STRATEGY

Security Governance

Audit

Privacy / Data

Protection

Trusted Internet Connection (TIC)

COD behind TIC / Einstein IPS

Enterprise Identity Management Services

(EIMS)COD/PM/AIMS PIN PRMS Soft Tokens

Two Factor AuthenticationTFA deployed for privileged users

NetworkIntrusion

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-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

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 ChangesPast 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

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

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

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 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

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 InfoBridget-Anne HampdenSenior AdvisorFederal Student AidBridget-Anne.Hampden@ed.gov

23