AVC-IT & CIO FY 2011-12 BUDGET PLANNING INTERNAL USE Two-factor authentication service for applications and desktops ABBA Category Two: Information Technology 1. Amount of One-Time Funding Request (FY 1): $67,952 2. Control Unit/Department Funding Contribution: $ 3. Department(s) to receive funding: IST - CalNet 4. Project Manager: Dedra Chamberlin/CalNet PM 5. Describe the Activity: A number of IST and campus departments have expressed a need to deploy two-factor authentication to protect sensitive systems and information. IST has been working on a two-factor Proof of Concept based on the Yubico YubiKey. The PoC is due to complete near the end of this fiscal year. This is a request to expand the PoC to a campus-wide two-factor authentication service. The Yubico YubiKey is a USB-based, event-driven, one time password token that is synchronized with a server. As the token lacks a PIN or passphrase, it is only a single factor device. The Validation Server is an open-source, PHP-based server requiring no per-seat license costs. The tokens are relatively inexpensive, making this a significantly more affordable option. The YubiKey is proposed provided that: 1. It is used with the CalNet Passphrase at each authentication event. (This may be easier with certain authentication mechanisms such as CAS, Shibboleth, or PAM than for network devices or Windows.) 2. Login from mobile devices (generally lacking a USB port) is not required. 6. Describe the significance of the activity, indicating how the activity is in alignment with Chancellor s objectives (see http://newscenter.berkeley.edu/chancellor/access/) : 1. In the world of electronic identity, authentication refers to the act of proving that a person requesting a transaction is who they claim to be. This can be accomplished by using one of the following: 1. Something the person knows that is known only to that person, such as a password or PIN. 2. Something the person has that nobody else does, such as a personal hardware token or ID card. 3. Something the person is, that is something intrinsic to the individual such as a fingerprint or retina scan. April 25, 2011 1
AVC-IT & CIO FY 2011-12 BUDGET PLANNING INTERNAL USE No single factor is perfect. Passwords can be shared or obtained via social engineering techniques, hardware tokens can be stolen or borrowed, biometric signatures can be copied. The requirement of two factors to authenticate an individual (two-factor authentication or T-FA) reduces the risk that the individual s credentials have been compromised, therefore increasing the level of assurance that the individual is who they claim to be. 2. At UC Berkeley, the common central authenticator is the CalNet Passphrase, something the person knows. An additional authenticator, the CalNetKey, is also something the person knows (in this case a PIN instead of a passphrase), and is therefore insufficient for a second factor. For purposes of implementing T-FA, any new technology must be either something a person has or something a person is. 3. Reference: UC Berkeley Two-Factor Authentication: Analysis and Approach, July 2010. Prepared on behalf of the CalNet Identity and Access Management team with input from IST and campus collaborators. Please see UCB Two-Factor Authentication - Draft (.pdf). Having a second authentication credential in use reduces the potential security impact for individuals following any compromise of the primary (CalNetID) authentication credential. This in turn encourages the wider use of the primary authentication technology in otherwise marginal applications, or by applications that might otherwise have to apply for an exception to the stricture on proxy CalNet authentication, thus improving the general security posture of the campus. The existence of TF-A services will facilitate the creation and secure deployment of applications dealing with sensitive data for use by appropriate audiences. As noted above, a two-factor authentication service would provide a measure of security needed to implement other OE initiatives such as student/staff portals, the advising toolkit, online performance evaluation tools, and online financial planning tools. The impact on existing applications is to provide an option to enhance their security for a wider audience while potentially eliminating less secure mitigation to risk that may be in use as an alternative to TF-A. Some departments have stated that if a central two-factor solution is not implemented, they will need to implement one on their own. This would be inefficient and difficult to support over time. 7. Work Plan Provide a work plan for the proposed solution with high-level steps to complete the solution, including timeline. (Try to limit your plan to no more than seven steps.) Milestone 1. Complete and document the Proof of Concept (POC) project already in place 2. Develop policy outlines and assign ownership of policy and technology Timeline Summer 2011 Summer/Fall 2011 April 25, 2011 2
AVC-IT & CIO FY 2011-12 BUDGET PLANNING INTERNAL USE 3. Scale the POC technolgies to meet initial target needs Fall 2011 Work with Cal 1 Card to design frontline support for campus-wide 4. service and train support staff Spring 2012 5. Scale POC to meet larger campus need Summer 2012 6. Begin user training and education Summer 2012 7. Evaluate implementation success and consider improvements or alternatives Ongoing 8. Describe any savings or increase in income that will result from this activity, and how it will be measured. Distinguish savings in time and/or money, and identify any resulting reduction of staffing levels. Improving the security for sensitive campus applications reduces the need for expensive and image-damaging notifications and costly related measures following security breaches. TF-A is often mandated by policy or law in certain circumstances which places campus units in the position of having to forgo some functionality or operate in a non-compliant fashion. There are several OE resource requests that would likely require the use of second-level or twofactor authentication given the sensitivity of the data being protected, such as staff payroll information in the case of the staff portal proposal, student grades and advising records in the case of the Academic Commons and Advising Toolkit proposals. 9. Funding: describe the overall funding plan for this activity. Describe any cost-sharing, matching, or external fund sources that might be used to support the activity. The above referenced analysis of two-factor authentication solutions for UC Berkeley outlined proposed implementation costs for such a service as follows: Task Setup Maintenance (Yr) Backend Infrastructure $3,840 $16,752 Client Infrastructure $33,600 $3,840 Token Management $10,880 $2,560 Policy $32,000 $1,920 Total $25,072 The two-factor Proof of Concept project funded through the IST-DCAT this year has covered the setup costs for backend and client infrastructure. This request is for funding to cover the token management and policy costs for setting up and initial service and for maintenance/operating costs for one year. The service could become self-sustaining within 1-2 years if it were deployed as a recharge service. April 25, 2011 3
AVC-IT & CIO FY 2011-12 BUDGET PLANNING INTERNAL USE Total request for funding is: Year 1: Token management setup: $10,880 Policy: $32,000 Maintenance for year 1: $25,072 Grand total: $67,952 April 25, 2011 4
UC Berkeley - FY 2011-12 Campus Budget Process Section V: Block Grant Funding Model and Budget Block Grant Name: Two Factor Authentification Projections Funding Model Sources Item # FY 11-12 FY 12-13 FY 13-14 Cummulative Total 1 IST - - - - 2 Other Sources - - - - 3 Request for Block Grant 67,952 - - 67,952 4 Grand Total 67,952 - - 67,952 Expense Budget Projections Cummulative Total FY 11-12 FY 12-13 FY 13-14 5 Salaries - - - - 6 Benefits - - - - 7 Consultants/Contractors 50,672 - - 50,672 8 General S&E - - - - 9 Hardware Maintenance - - - - 10 Infrastructure Services - cost of recharge services 17,280 - - 17,280 11 Inventorial Equipment - - - - 12 Software Maintenance/Licenses - - - - 13 Software Purchase - - - - 14 Travel/Training - - - - 15 Other Costs - - - - 16 Grand Total 67,952 - - 67,952 17 FUNDS LESS EXPENSE $0 $0 $0 $0 18 Carryforward $0 $0 $0 19 Cummulative Total $0 $0 $0 $0 FY 2011-12 Block Grant Request Application
UC Berkeley - FY11-12 Campus Budget Process Section V Part II: Line Item Description of Funding Model and Budget Block Grant: Two Factor Verification Title Item Funding Model Sources # 1 IST 2 Other Sources 3 Request from the Block Grant 68K 4 Total Funding Description Expense Budget 5 Salaries 6 Benefits 34% 7 Consultants/Contractors assist with proof of concept and policy 8 General S&E 9 Hardware Maintenance Infrastructure services (backup, storage, colocation, 10 network nodes, desktop support, etc.) 11 Inventorial Equipment 12 Software Maintenance/Licenses 13 Software Purchase 14 Travel/Training 15 Other Costs 16 Total Expenses backend infrastructure, client infrastructure, token management, policy 17 FUNDS LESS EXPENSES Funds Less Expenses 18 Carryforward 19 Cummulative Total FY 2011-12 Block Grant Request Application
Budget Area Dept Org Id Budget Category Line of Business Initiative Funded by Expense Category Expense Description FY11 Actuals FY12 Proj Amt FY13 Proj Amt FY14 Proj Amt Cummulative Base FY11 Amt Base FY12 Amt Base FY13 Amt FY11 Proj FY12 Proj FY13 Proj FY09 Base FY10 Base FY11 Base FY12 Base FY13 Base Funding Funding Type Funding Source Received Date Account Program Fund Notes Request for Block Infrastructure Services 26300 Major Project Grant Consultants/Contractors $ - $ 50,672.00 $ - $ - $ 50,672.00 General S&E $ - $ - $ - $ - $ - Hardware Maintenance $ - $ - $ - $ - $ - Request for Block Infrastructure Services - cost of Infrastructure Services 26300 Major Project Grant recharge services $ - $ 17,280 $ - $ - $ 17,280.00 Inventorial Equipment $ - $ - $ - $ - $ - Other Costs $ - $ - $ - $ - $ - Software Maintenance/Licenses $ - $ - $ - $ - $ - Software Purchase $ - $ - $ - $ - $ - Travel/Training $ - $ - $ - $ - $ - Other Costs $ - $ - $ - $ - $ - Other Costs $ - $ - $ - $ - $ - Salaries $ - $ - $ - $ - $ - Benefits $ - $ - $ - $ - $ - Salaries $ - $ - $ - $ - $ - Benefits $ - $ - $ - $ - $ - 0% 0% 0% 0% 0% Central Permanent 0% 0% 0% 0% 0% Central Permanent 0% 0% 0% 0% 0% Central Permanent 0% 0% 0% 0% 0% Central Permanent
Budget Area Dept Org Id Budget Category Infrastructure Services 26300 Major Project Infrastructure Services 26300 Major Project
Line of Business Initiative Expense Category Consultants/Contractors Infrastructure Services - cost of recharge services
Expense Description FY11 Actuals FY12 Proj Amt FY13 Proj Amt $ 50,672 $ - rge services $ 17,280 $ - $ - $ - $ - $ -
FY14 Proj Amt Cummulative Funding Type $ - $ 50,672 $ - $ 17,280 $ - $ - $ - $ -
Request for Block Grant Request for Block Grant IST Other Sources Funding Source Program Fund
Notes