350 likes | 358 Views
Session T-03. Federal Student Aid Technical Architecture Initiatives. James McMahon Ganesh Reddy U.S. Department of Education. Person Record Management System and PIN Re-engineering. James McMahon. NSLDS. DMCS. DLCS. DLSS. COD. Gathering and Using Person Data.
E N D
Session T-03 Federal Student Aid Technical Architecture Initiatives James McMahon Ganesh Reddy U.S. Department of Education
Person Record Management System and PIN Re-engineering James McMahon
NSLDS DMCS DLCS DLSS COD Gathering and Using Person Data Aid Awareness and Application Aid Delivery Servicing/ Consolidation • Create or • Update • (DL, FFEL and • Perkins) • Create Or Update • Create or • Update CPS • Create or • Update PIN
Why Person Data Management? • No single version of the “truth” for a customer account • Disparate systems developed with duplicative and conflicting information about applicants and recipients • Different system keys for identifying individuals • Use of the SSN in authentication and customer identification
Why Person Data Management? (cont’d) • Difficulty in developing single picture of customer data • Comingling of authentication and demographic functions • Lack of integration with enterprise security architecture • No flexibility in interfacing with authenticated and unauthenticated users
What will Person Data Management do? • Deploy a new paradigm for person data management via a shared service at the enterprise level that all business applications can use • Improve data quality for person data throughout the Student Aid Lifecycle • Enable increased tracking and reporting capabilities for program integrity and program oversight • Enable the Integrated Student View, Single Sign-On, and additional streamlining initiatives • Provide infrastructure to allow for elimination of use of SSN as key identifier in Federal Student Aid systems
What is the Person Data Management Program? • Person Data Management (PDM) is primarily comprised of two major projects: • The Person Record Management Service (PRMS) • A re-engineering of the current PIN solution
What is PRMS? • PRMS will be the master record for Federal Student Aid of an applicant or recipient’s demographic information • PRMS will be an enterprise shared service using a publish and subscribe model following Service-Oriented Architecture principles • Legacy applications will transition to use of the PRMS in a phased manner
What is PRMS? (cont’d) • Will provide an enterprise account number (FAN = FSA Account Number) for persons: • Creates a unique identifier as the enterprise identifier • Protects the person’s identity • Passes the new identifier to other systems • Allows people interacting with Federal Student Aid systems to not use personal identifying information to access detailed information • Helps in resolving data quality issues • Maintains history of person data • Acts as the master source/location of person data where it is maintained and shared with other internal systems
Conceptual Diagram of PRMS Conceptual Depiction 10
What is PIN Re-engineering? • A re-engineered PIN solution will: • Separate person demographic and authentication information and the functions associated • Introduce an enterprise approach to use of user ID and password • Strengthen the authentication credential (PIN) • Integrate the authentication function with Federal Student Aid ’s enterprise security architecture solution
PDM Solution(s) Conceptual Architecture The PDM solution includes two databases: Person Data Hub and the Person Directory: • Person Data Hub • will be the new master data management solution for person data for identity (e.g., SSN, name, DOB) and demographic data (e.g., address, email address) • Person Directory • will store a copy of authentication information.
Ganesh Reddy Virtual Keyboard, Two Factor Authentication and Active Confirmation
Tactical Improvements to IT Security Quick fixes and high impact improvements that can be implemented in a short timeframe to enhance the IT security • Virtual Keyboard • Implement technologies appropriate for Federal Student Aid that evade potential "key logging" • Two-Factor Authentication (T-FA) • Implement Two-Factor Authentication solution for privileged users to access National Student Loan Data System (NSLDS) from internet • Active Confirmation • Assess current state of access controls for partners and deploy an “active confirmation” process
Keylogging – Virtual Keyboard Keylogging (Keystroke logging) is a method of capturing and recording user keystrokes. Some of the common technologies used to evade keylogging include: • Anti-spyware • Monitoring what programs are running • Firewall • Network Monitors • Automatic form filler programs • Alternative keyboard layouts • One-time passwords • Smartcards • Virtual keyboards Virtual keyboards are provided on the application login page and do not require end users to acquire additional software
Federal Student Aid Virtual Keyboard Features Virtual keyboards are provided on the Security Architecture (SA) login page and do not require end users to acquire additional software. Some of the features of Federal Student Aid Virtual Keyboard include: • Highly effective in evading “Key Logging” • Widely used by many financial institutions • Least expensive technology to deploy (even for 50 million users) • Does not require any new hardware or software on client machines • Does not require any changes to the applications • Available to all applications that use SA • Works in conjunction with the existing keyboard • Usage is optional but can be made mandatory based on security policy • Keys can entered by mouse click or by leaving mouse on the key for 2 seconds • Virtual keyboard randomly shifts on the screen • Supports multiple keyboard layouts (US and Dvork)
What is Two-Factor Authentication? Two-Factor Authentication (T-FA) uses two pieces of information and processes (two different methods) to authenticate a person's identity for security purposes. Authentication factors are generally classified into three categories: • Something the user has • ID card, security token, software token, phone, or cell phone • Something the user knows • password, pass phrase, or personal identification number • Something the user is • fingerprint or retinal pattern, voice recognition, or another biometric identifier Two-Factor Authentication requires the use of solutions from two of the three categories of factors.
T-FA Implementation Approach Evaluate and select software for T-FA that can be incorporated quickly into Federal Student Aid security architecture. • The product selected will be Federal Student Aid’s (interim) enterprise standard for implementing T-FA and may be used with many of Federal Student Aid’s online applications. • The initial installation will likely be for the NSLDS application access for employees and contractors. In the future, T-FA will be added to other applications with PII data. • The T-FA application would control the request for a second factor for authentication and only make the request when the employee or contractor is accessing the application from outside of EDUCATE, the Department’s network. The future capability may include other trading partners, such as schools and financial partners. • The T-FA tool should work seamlessly with Federal Student Aid security architecture and applications.
T-FA Implementation Milestones Implement Two-Factor Authentication (T-FA) for privileged users to access Federal Student Aid systems from internet, coming from outside of the EDUCATE network • Complete evaluation of Two-Factor Authentication technologies • Develop a Web Service to initiate T-FA challenge after standard application login • Coordinate with NSLDS team to integrate T-FA into its web login process • Conduct a product evaluation to select a T-FA tool for employees and contractors accessing NSLDS from internet
T-FA Technologies Some of the common technologies used as the second factor authentication in concert with UserID and Password include: • Hardware Tokens - generate a constantly changing one-time password to enable authentication. • Software Tokens on PCs - enable authentication with computer as second factor authenticator. • Software Tokens on Mobile Devices - allow authentication from smart phones and PDAs. • Smart Cards - enable authentication as well as of physical access. • USB Tokens - enable authentication without the need to key in a token code (can be plugged into a standard USB port). • Biometric Devices - enable authentication according to the physical characteristics of a user (fingerprint and retina scans).
T-FA Requirements The Two-Factor Authentication (T-FA) tool evaluation and selection is based on the following requirements categories: 1. Client-Side Software and Tokens 2. Server Environment 3. Security 4. Performance and Scalability 5. User Experience 6. Vender Support 7. Cost
T-FA Evaluation Factors Two-Factor Authentication solution or tool should: • Be reliable, scalable, and available, and meet sub-second performance standards • Be compatible and interoperable with Federal Student Aid Technology and Policy Standards • Seamlessly integrate with existing Federal Student Aid architectures and infrastructure • Support web applications and should not require client-side software • Be compliant with NIST, FIPS and other federal T-FA standards • Have well documented APIs, implementation and configuration procedures • Have ongoing operations and maintenance product support • Be based on mature technology and should be commercially available with a broad installed market base
What is Active Confirmation? • Active confirmation is the process of a Designated Point Administrator (DPA) reviewing users' access privileges on a establish time schedule and confirming these users' privileges. This will help ensure an updated and secure environment for system accessibility. • The Federal Student Aid DPAs will be required to review their list of users who access Federal Student Aid systems and confirm that each individual continues to be a valid user. This will be done on a periodic basis.
“Active Confirmation” Process • Assess current state of access controls for partners and determine feasibility of deploying an “active confirmation” process. Entities will be routinely asked to review their list of users with access to Federal Student Aid systems and confirm that each individual continues to be a valid user on his/her behalf. • Internal Review Team performed a high level assessment and provided recommendations to determine feasibility of deploying an “active confirmation” process for NSLDS, CPS, DMCS, and COD • The foundation for active confirmation exists in current state user management processes within NSLDS, CPS, and DMCS • Enterprise Access Management group will review the recommendations and determine the feasibility of deploying an “active confirmation” process
Contact Information • We appreciate your feedback and comments. We can be reached at: • james.mcmahon@ed.gov • ganesh.reddy@ed.gov