9:00 – 10:30 a.m., December 12, 2014, FAC 228D
I. Web Infrastructure - Update (Dave Moss)
II. Email and Calendaring - Update (Sandra Germenis)
III. WITI Committee - Update (Jennifer Chance)
IV. IAM Committee - Update (David Burns and C.W. Belcher)
V. Two-factor Authentication – Chancellor’s Announcement (Cam Beasley)

U T W E B I N F R A S T R U C T U R E P R O J E C T U P D A T E – D E C E M B E R 2 0 1 4
Overview
UT Web, the university’s new web hosting platform, is now available in production. This centrally funded service managed by Information Technology Services (ITS) is available at no cost to colleges, schools, and departments and replaces the legacy Web Central service. UT Web is designed for both static HTML pages as well as dynamic websites and applications. Features include improved performance, security, and reliability while offering enhanced self-service capabilities to improve the web publisher experience.
Migration Plan
Migrations from Web Central are underway and scheduled to run through December 2015.
 The first two customer sites are now live on UT Web: o http://clm.utexas.edu/ o http://neuroscience.utexas.edu/
 The fall 2014 semester migration schedule also includes: o School of Law o Office of the Vice President for University Operations (Technology Resources) o Cockrell School of Engineering Faculty Innovation Center o Office of the Executive Vice President and Provost o ITS Applications Software Distribution and Sales o College of Fine Arts o University Communications o Moody College of Communication AdGrad o University Health Services o Texas Memorial Museum
Support and Documentation
ITS will offer support during this transition period with comprehensive documentation and regularly scheduled office hours.
For More Information
For more information on UT Web, including detailed technical specifications and how to request service, please visit http://www.utexas.edu/its/utweb/.
1 UT Web Infrastructure Project Update
December 2014

Calendaring and Email Strategy 12/2014 1
Calendaring and Email – Campus Strategy
Guiding Principles
The university should pursue a strategy of a single cloud-based platform for calendaring and email for business class users (primarily faculty and staff) across the university in order to deliver the functional requirements desired and needed by those users. The service must meet the following functional requirements:
1.
2.
3.
4.
5.
Individual user mailbox and enterprise calendaring services
Basic shared resource capabilities
Feature end user experience parity across major operating systems and e-mail clients
Interoperability with other user populations (e.g. students, alumni, outside entities) and technology services
Individual accounts provisioned for all newly affiliated staff and faculty and deprovisioned as affiliations end (some exceptions may apply)
Timeline
It is estimated that meeting all functional requirements with a single cloud-based platform for calendaring and email may take up to 3 to 5 years. In the interim, the timeline has been divided into short and medium term steps to assist with meeting the goal.
Short Term – 12 to 18 months
Two cloud offerings will continue to be offered to CSUs through the Summer of 2016. These are Office 365 and
UT Mail. In addition to this, an on-premise Exchange service will continue to be maintained through the summer of 2016.
The service owners will define a cycle of migration windows that will allow each CSU an opportunity to migrate their constituents from one of the three platform to another as needed. The decision will be left to the CSU, however the service owners will make recommendations based on the CSUs specific environment and functionality requirements.
The service owners will pursue adding interoperability tools between the supported systems.
Medium Term – 18 months to 3 years
No later than May 2016, it will be determined if a cloud- based platform for calendaring and email meets all of the functional requirements for business class users.
Retire existing on premise Exchange. If a cloud-based solution does not meet all functional requirements pick either a new on-premise or in a private cloud Exchange service for the subset of users whose functional requirements are not met.
By May 2016, the service owners will have begun the implementation of interoperability tools between the supported systems if it was determined to be feasible.
Long Term – 3 to 5 years
The official calendaring and email service for conducting university business will be a single cloud-based (e.g., hosted) platform. The university will continue to offer students UTMail which also can be an option for individual choice by faculty and staff.

Calendaring and Email Strategy 12/2014 2
Action Items
In order to accomplish the strategy set forth in this document, the below items will need to be completed in the time frames suggested.
Short Term – 12 to 18 months Medium Term – 18 months to 3 years Long Term – 3 to 5 years
AIC to approve the strategy recommended by this subcommittee
Extend short-term on-premise Exchange maintenance agreement. This is already funded through April 2015 and the expected cost is ~$18,000/year to renew with the understanding extended maintenance ends April
2017 for current hardware.
Governance to approve funding interoperability project to include $27,000 for tool to show Google calendar free/busy to Office 365 users and offer tools to better
New task force issue findings on if either current cloud solution meets all functional requirements.
Governance to approve funding refresh of on-premise
Exchange if all functional requirements are not met and or revisit functional requirements.
Governance to approve funding professional services required to move final on-premise Exchange customers to a long-term email and calendaring solution (estimated
$70/mailbox based on previous work).
To be determined by upcoming Task Force. manage resource calendars.
CSUs still on-premise need to determine which cloud solution they prefer for calendaring and email, with service owner’s assistance, no later than May 2016.
Service owner to create a communication plan for campus communication outlining the findings and action items recommended by this subcommittee.
AIC to convene task for no later than January 2016 to review functional capabilities of cloud products and determine if all functional requirements are met.
Make decision to fund (or table) a migration tool to
UTMail based on CSU feedback and demand, with the
December 2014 estimated cost being $60k.

Calendaring and Email Strategy 12/2014 3
Individual User Functionality
There are two types of users defined by the subcommittee: business users and basic users. The functionality for both user types will has been documented by and published by the subcommittee .
Basic Shared Resource Functionality
The calendaring and email system will allow for the existence of resources (e.g. rooms or projectors) that are available for reservation. A concerted effort will be made, where possible, to include resources like this within the calendaring and email system such that employees who manage the resources can do so within the system’s client and that employees who wish to make a reservation may do the same. The system will allow globally visible distribution groups, to which appropriate individual employees can be delegated membership control. If possible, the system will contain a searchable address list that contains the primary contact information for all employees, regardless of whether they use the system for their primary mailbox or not. For any complex room scheduling needs, alternative methods and products should be evaluated and pursued.
Client Functionality
The calendaring and email system will allow for parity in functionality across all major operating systems used by employees at the university. Service owners will publish a matrix of supported email clients and will update that matrix on a regular basis
Interoperability
Where opportunities presents themselves, efforts will be made to publish relevant calendaring information to external systems used by staff, faculty, and students or to pull in information from those systems. Examples of this might include publishing a room’s schedule outside of the system or pulling in faculty or advisor appointments from external appointment systems into the faculty or advisors personal calendar. Where opportunities present themselves, employees’ individual mailboxes or calendars will allow for integration with other communication services such as instant messaging, telephony, and social media for business purposes.
Administration and Support
This calendaring and email account will be provisioned for all employees as part of the normal onboarding process. The accounts will be updated or deprovisioned as the employee's status changes.

Initiative
IAM Solution Selection
IAM Solution Implementation
Planning
UTLogin Transition / Central
Web Authentication Retirement
Status
Complete
In Progress The charter for the IAM Modernization Program is in development. This program will coordinate multiple projects to implement the SailPoint IdentityIQ software,
Complete
Notes
SailPoint’s IdentityIQ solution was selected during the IAM Technology Selection RFP process. The contract was signed in November and implementation planning is underway. transition and retire legacy IAM services, and implement the integrations and bridges required to maintain IAM services as the IAM environment and the campus computing environment as a whole (via ASMP) are being modernized.
The transition of campus systems to UTLogin was completed in September, allowing the retirement of Fat Cookie and the legacy Central Web Authentication system.
UTLogin OpenAM v11 Upgrade
UTLogin Realm Policy Manager
Enhancement
Complete A major upgrade of the UTLogin software infrastructure was completed in November.
This upgrade improved authentication session failover capabilities and addressed a number of system bugs.
In Progress This enhancement will allow UT Web site owners to manage UTLogin policy settings for their sites via self-service, rather than having to request policy changes be made by the UT Web administrators.
Identity Assurance Framework
Development
Toopher Pre-generated One
Time Password Enhancement
IAM Server & Operating System
Refreshes (TIM, TED, WHIPS, ID
Photos, & TRAC)
IAM Integration with ASMP /
Workday
In Progress The Identity Assurance Framework will provide an objective assessment process to assist campus units in identifying the appropriate level of assurance for their systems to mitigate the risks of compromised authentication.
Complete This enhancement allows customers who do not have mobile devices to use the
Toopher two-factor authentication service.
In Progress A number of IAM servers and operating systems must be replaced or upgraded to ensure these systems are running on supported hardware and software. The team is using virtualized servers wherever possible.
In Progress The team is currently developing the IAM Integration Strategy, which will guide implementation of the integrations and bridges needed to maintain IAM services as
ASMP progresses.
12/12/2014 1

The University of Texas at AusMn
InformaMon Technology Services
IdenMty & Access Management
FY 2014-
­­2015
IAM Roadmap Overview
FY 2015-­­2016
Status Key
Complete In
Progress
Planned
Future
FY 2016-­­2017
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
S O N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A
IAM SoluMon SelecMon (P0)
IAM SoluMon ImplementaMon Planning (P0)
UTLogin TransiMon / CWA ReMrement (P0)
UTLogin OpenAM v11 Upgrade (P0)
UTLogin Realm Policy Manager Enhancement (P1)
IdenMty Assurance Framework Development (P1)
IdenMty Assurance Framework ImplementaMon (P1)
Toopher Pre-­­generated OTP Enhancement (P1)
Shibboleth Toopher IntegraMon (P1)
Shibboleth BC/DR Improvements (P1)
Toopher Hard Token Enhancement (P1)
UTLogin Toopher IntegraMon (P1)
Lightweight AuthenMcaMon & BYOId (P1)
AuthenMcaMon Service Resiliency (P1)
Group & Role Management (P1)
DPUSER Workday IntegraMon (P1)
OHSC Workday IntegraMon (P1)
AuthorizaMon ReporMng Repository (P2)
Access Request Workflows (P3)
Access RecerMficaMon (P3)
TIM Server Refresh & Database MigraMon (P0)
IAM IntegraMon with ASMP / Workday (P1)
TIM Replacement (P2)
TED Server Refresh (P0)
WHIPS OS Upgrade / VM Refresh (P0)
ID Photos OS Upgrade / VM Refresh (P0)
ID Card System Replacement (P2)
TRAC Saturn/Gemini ReMrement (P0)
TRAC UTS ReMrement (P1)
SDS UTS ReMrement (P1)
TRAC Replacement (ServiceNow) (P3)
Apps Build Server Maintenance (P1)
FY 14-­­15 Sustainment
(Stewardship, Maintenance, Oversight)
FY 15-­­16 Sustainment
(Stewardship, Maintenance, Oversight)
FY 16-­­17 Sustainment
(Stewardship, Maintenance, Oversight)
12/12/2014

The University of Texas at AusMn
InformaMon Technology Services
IdenMty & Access Management
IAM Roadmap Initiative Descriptions
IAM Solution Selection: Select and procure new IAM software to support and enable the roadmap goals.
IAM Solution Implementation Planning: Complete high-­­level planning for the implementation of the software selected in the IAM Solution Selection project.
UTLogin Transition / CWA Retirement: Transition Central Web Authentication & Fat Cookie customers to UTLogin and retire the CWA/FC authentication system.
UTLogin OpenAM v11 Upgrade: Upgrade UTLogin to the current version of OpenAM software to address bugs, implement session management enhancements, and stay current with vendor support.
UTLogin Realm Policy Manager Enhancement: Enhance the UTLogin RPM to allow delegated administration of sites on shared hosting environments like UT Web and
Windows Web Hosting.
Identity Assurance Framework Development & Implementation: Implement a framework to assist campus departments in assessing the risks associated with their applications and selecting an appropriate level of assurance to mitigate those risks.
Toopher Pre-­­generated OTP Enhancement: Add the ability to use pre-­­generated one-­­time-­­passwords (OTPs) with Toopher.
Shibboleth Toopher Integration: Enable two-­­factor authentication for applications that use SAML-­­based authentication.
Shibboleth BC/DR Improvements: Leverage UDC-­­B to improve the time required to return Shibboleth to service in the event UDC-­­C becomes unavailable.
Toopher Hard Token Enhancement: Add the ability to use hard (physical) OTP tokens with Toopher.
UTLogin Toopher Integration: Enable two-­­factor authentication for applications that use UTLogin for authentication.
Lightweight Authentication & BYOId: Implement a lightweight identifier and authentication service and integrate with external identity providers (Bring Your Own
Identity).
Authentication Service Resiliency: Improve the resiliency of central authentication services by leveraging off-­­campus hosting.
Group and Role Management: Implement enterprise group and role management services.
DPUSER & OHSC Workday Integration: Implement required connections between Workday and DPUSER and OHSC.
Authorization Reporting Repository: Implement a repository to collect authorization information from major campus systems to provide a picture of "who has access to what."
Access Request Workflows: Implement flexible and extensible access request process for campus applications/servers.
Access Recertification: Implement access reporting and review processes to ensure that application/server access is needed and appropriate.
TIM Server Refresh & Database Migration: Retire out-­­of-­­warranty servers and migrate to virtual server infrastructure and enterprise Oracle service.
IAM ASMP / Workday Integration: Implement bridges and integrations between IAM systems and ASMP/Workday systems.
TIM Replacement: Replace TIM identity administration and provisioning services with SailPoint, and retire TIM.
TED Server Refresh: Retire out-­­of-­­warranty servers.
WHIPS OS Upgrade / VM Refresh: Migrate to supported OS version and refresh virtual server infrastructure.
ID Photos OS Upgrade / VM Refresh: Migrate to supported OS version and refresh virtual server infrastructure.
ID Card System Replacement: Modernize ID Card System and remove mainframe dependency.
TRAC Saturn/Gemini Retirement: Retire use of out-­­of-­­warranty servers.
TRAC UTS Retirement: Migrate TRAC functions off end-­­of-­­life UTS service.
SDS UTS Retirement: Migrate SDS functions off end-­­of-­­life UTS service.
TRAC Replacement (ServiceNow): Replace TRAC functionality with ServiceNow.
Other Apps Build Server Maintenance: Maintenance and enhancements required to support ITS Applications software build and testing infrastructure.
12/12/2014

The University of Texas at Arlington
The University of Texas at Austin
The University of Texas at Brownsville
The University of Texas at Dallas
The University of Texas at El Paso
111e University of Texas-Pan American
The University of Texas of the Permian Basin
The University of Texas at San Antonio
The University of Texas at Tyler
The University of Texas
Southwestern Medical Center
The University of Texas
Medical Branch at Galveston
The University of Texas
Health Science Center at Houston
The University of Texas
Health Science Center at San Antonio
The University of Texas
M . D. Anderson Cancer Center
The University of Texas
Health Science Center at Ty l er www .
utsystem.edu
The University of Texas System
Nine Universities. Six Health Institutions. Unlimited Possibilities.
Office of the Chancellor
601 Colorado Street , Austin, Te x as 78701-2982
Phone: 512 499 4201 Fax: 512 499 4215
December 2, 2014
MEMORANDUM
TO :
FROM:
Presidents, The University of Texas System
Francisco G. Cigarroa, M. D.
£-
A:
SUBJECT: Enhanced Remote Access Authentication Re
No doubt you are aware that cyber-threats and attacks continue to increase in number and sophistication. This past year, The University of Texas
System institutions experienced cyber-attacks posing direct financial threat to our employees and institutions. Such attacks often start with a "phishing" campaign wherein criminals send deceptive email messages with the intent of convincing employees to reveal their logon IDs and passwords . Criminals t h e n use the stolen credentials to access and change the employee's banking information causing the employee's paycheck to be deposited to an account controlled by the criminals. Similar tactics have been used to submit fraudulent claims for unemployment benefits and to submit bogus income tax returns to steal refunds. The vast majority of these attacks are launched remotely, often from overseas.
These incidents demonstrate that passwords alone are no longer sufficient to protect University data that is of high value to criminals; therefore, I am directing that each U. T. institution implement enhanced "two­ factor authentication" in certain high risk situations to prevent criminals from committing these offenses against U. T. System institutions and employees.
Most people are familiar with two-factor authentication as it is used when withdrawing funds from an ATM machine. The two factors required for an
ATM transaction are the person's PIN (something the person knows) and the
ATM card (something the person possesses). In the University environment, authentication factors will typically consist of the person's password
(something known) along with her mobile phone or a token device (something in possession).
I am directing that two-factor authentication be required in situations that involve remote access to resources, specifically in the following situations:
• when an employee or individual working on behalf of the University (such as a student worker, contractor, or volunteer) logs on to a University network using an enterprise remote access gateway such as VPN, Terminal Server,
Connect, Citrix, or similar services;

Presidents, The University of Texas System
December 2, 2014
Page 2
• when an individual working from a remote location uses an online function such as a web page to modify employee banking, tax, or financial information; or
• when a server administrator or other individual working from a remote location uses administrator credentials to access a server that contains or has access to confidential
University data.
Please note, modification of employee banking and financial information from remote locations is to be blocked until two-factor authentication controls are in place. I encourage all institutions to implement these controls as quickly as possible, but no later than by August 31, 2015.
A Frequently Asked Questions (FAQ) document to address anticipated questions is attached. As additional questions arise, the FAQ will be updated and distributed to the
U. T. System Chief Information Officers and Chief Information Security Officers. Please direct other questions that you or your staff may have to Mr. Lewis Watkins at lwatkins@utsystem.edu or (512) 499-4540.
Thank you.
FGC:bc
Attachment cc: Dr. Scott C. Kelley
Dr. Pedro Reyes
Dr. Raymond S. Greenberg, M.D., Ph.D.
Dr. Wesley Byerly

is Two-Factor Authentication?
Two-factor authentication is a method of assuring a person is who he or she claims to be by requiring that person to provide any two of the following when attempting to access resources or conduct transactions:
1. something the individual knows (e.g. a password);
2. something the individual has on his person (e. g. token, mobile phone, ATM card, or other device); or
3. a characteristic that is unique to the person (e. g. fingerprint, handprint, etc.).
Q-2. Why are U. T. System institutions implementing two-factor authentication?
The number and diversity of computer security incidents occurring within U. T. System and in organizations throughout the world illustrate that the combination of user-ID and password is no longer sufficient for protecting confidential information. Criminals have devised sophisticated schemes for stealing people's logon credentials and using them to commit crimes. As a result, there have been instances in which University employee pay deposits were redirected to fraudulent accounts. Also, credentials have been used to illegally access protected health information residing on University servers. Two-factor authentication is a best practice recognized as being effective for helping prevent these types of incidents.
How do criminals obtain people's logon-IDs and passwords?
They do so through a variety of methods. A common method is through "phishing" wherein a criminal sends bogus email or text messages in an attempt to trick recipients into revealing their logon credentials (logon-ID and password). Also, criminals continuously scan the Internet searching for technical weaknesses within organizations that can be exploited to steal data -including employee logon credentials. In some cases logon credentials may have been stolen from a business or organization having no relationship to the University. The criminal then attempts to use the stolen credentials at the victim's workplace in hopes the employee has used the same password at work as in other places. Also, there are black market sites on the Internet where criminals who have stolen credentials offer them for sale to others.
Q-4. Am I a target? Why would criminals want my logon-IDs and passwords?
All University employees are potential targets. Everyone has information about themselves that criminals can potentially use for identity theft. Also, University employees have access to and come into contact with confidential personal, student, or patient information (e.g., social security numbers, bank accounts, credit card numbers, etc.) and valuable information related to research and scientific discoveries. Criminals may also use employee credentials when performing other illegal activities because it makes it more difficult to detect unauthorized activities.
Page 1 5

Why System
More sophisticated attacks have become prevalent mostly past two years, and until recently, costs and lack of available user-friendly technology posed barriers to widespread adoption of two-factor authentication. These barriers have diminished significantly over the past year. There are now a good number of low cost, easy to use, two­ factor authentication products that work as apps on mobile phones.
Q-6. How will the two-factor authentication requirements impact users?
Users who access University resources only from on-site (i.e. campus) locations will not be impacted by this requirement. Users who sometimes access resources from on-site locations and sometimes from off-site locations will be impacted only when doing so from off-site in the situations described in Q-7. Until two-factor authentication capabilities are in place, employees' ability to change their University banking and financial information will be restricted to on-site locations.
Q-7. Under what circumstances will two-factor authentication be required?
Two-factor authentication is to be required in each of the following situations:
1. when an employee or individual working on behalf of the University (such as a student worker, contractor, or volunteer) logs on to a University network using an enterprise remote access gateway such as VPN, Terminal Server, Connect, Citrix, or similar services;
2. when an individual working from a remote location uses an online function such as a web page to modify employee banking, tax, or financial information; or
3. when a server administrator or other individual working from a remote location uses administrator credentials to access a server that contains or has access to confidential
University data. ·
Q-8. How is ''Remote Location" defined?
A location is "remote" or "off-site" if it lies outside the physical boundaries of the
Institution. Some examples of a remote location would include the McDonald's just across the street from campus, an employee's home, a hotel room, Starbucks, France, etc. Two-factor authentication is required for access from these locations.
Some examples of locations that can be considered as being within the borders of the
Institution- not remote locations - include satellite facilities, clinics, observatories, and other teaching, research, or patient care facilities that are owned/operated by the
Institution. Two-factor authentication is not required for access from these locations.
Q-9. How is "Remote Location'' determined in shared application situations such as the shared PeopleSoft applications hosted at the ARDC?
Again, remote location is based on the location of the individual accessing resources relative to the individual's Institution. For example:
• A UTSA employee would be on-site when accessing ARDC hosted PeopleSoft data from a UTSA location. Two-factor authentication is not required.
• The same UTSA employee is considered to be at a remote site when accessing
PeopleSoft from any other location (e.g., from home). Two-factor authentication is required.
Page 2 of 5

If the UTSA employee visits another U. Institution and uses that Institution's
Guest network to access PeopleSoft, the employee is a remote site relation to her
Two-factor authentication is location of an application and/or data being accessed does not impact the two-factor authentication requirement in any way. The requirement to use two-factor authentication is based solely on the location of the individual accessing the resource in relation to the person's institution. If the individual is working from on-campus, two­ factor authentication is not required. If the individual is working from outside the campus boundary, then two-factor authentication is required. an employee's use for remote access is to retrieve and send email
(including calendar and contacts), must the employee use two-factor authentication?
It depends on how the employee chooses to access his email. There is no U. T. System requirement to use two-factor authentication if the employee accesses email using Outlook
Web Access (OWA) or a similar approach that prevents access to resources other than email. However, if an employee uses VPN or one of the other services noted in Q-7 to connect to the network prior to accessing email, two-factor authentication is required when authenticating to the network. Contact your institution's help desk for assistance if you wish to change how you access your University email.
Q-12. Can an institution choose require two-factor authentication other than those outlined above? situations
Yes, two-factor authentication is currently recognized as a best practice. The circumstances identified in Q-7 are a minimum requirement and pertain specifically to this initiative. There are many other situations in which prudent practice suggests that two-factor authentication be used. Based on risk, and as time and resources permit,
Institutions are encouraged to expand use of two-factor authentication.
Q-13. Can adaptive techniques that require different levels of authentication based on risk level be used?
They cannot be used in the above situations because these situations have been identified as being high risk thereby warranting a traditional two-factor process. Based on risk, institutions may choose to use adaptive technologies in other situations as appropriate.
Q-14. Is there a requirement to use specific products?
No, institutions are not required to use a specific product. Toopher and Duo are recommended products because each of these are part of the Internet2 Netplus program and as such have been vetted for use in higher education. Also, these products are easy to use and relatively easy to deploy. However, there is no requirement to use either product.
3 5

- - p --
•
.- -· - ·-·.
Q-15. What costs are involved?
As a result of a contract that U. T. Austin secured, there is no licensing cost for use of
Toopher. The cost for Duo licenses depends on the size of an institution and whether or not licenses are being purchased for faculty and staff only or for faculty, staff, and students. Duo costs are explained here: http://www.incorrimon.org/duo/fees.html Also, under certain circumstances the institution may incur a small communications charge.
Q-16. What about employees who do not own mobile phones or who do not want to load an app on their mobile phones?
If the employee is one who must utilize remote access to perform his/her duties, the employee can use a token hardware device. These devices are about the size of a USB memory stick. Whenever the user is required to provide a second factor credential, the device will display a one-time numeric code for the user to enter. This is in addition to the user's password. The numeric code proves that the user is in possession of the token device. Token devices vary in cost, and we do not have a specific brand to recommend.
Q-17. What will the institution pay for? Phone? Token?
Each institution has guidelines regarding to whom a university purchased phone might be provided. There is no intent or expectation that this two-factor initiative will impact an institution's current mobile phone policy. It is an institutional decision whether and under what circumstances it might provide a token device to an employee.
Q-18. What if a situation exists that requires two-factor authentication but for technical or other reasons it is not possible, or is imprudent, to implement the requirement?
A temporary exception may be granted by the institutional Information Security Officer.
Exceptions must be documented and include the following elements:
1. a statement defining the nature and scope of the exception;
2. the rationale for the exception;
3. an expiration date for the exception;
4. a description of any compensating security measures that are to be required; and
5. the signature of the Information Security Officer and the Owner of the business function controlling the Information Resources potentially put at risk.
Q-19. What are the two-factor authentication requirements in medical work settings wherein U. T. physicians or other health professionals work in a facility owned/operated by an affiliated business partner?
Based on the criteria noted in Q-8, these locations meet the criteria for being considered
"remote." Therefore, two-factor authentication should be used for accessing University resources unless there are factors that make it impossible or imprudent to do so. Any decision to not use two-factor authentication should be based on risk assessment and be documented as noted in Q-18.
Page 4 of 5

Q-20 . At my institution, employees access their banking and financial records through our self-service portal which uses Shibboleth for authentication . How does this impact our moving to two-factor authentication?
Use of Shibboleth simplifies implementation of two-factor authentication. Shibboleth can easily determine whether a transaction is initiated locally or from a remote location and will initiate the two-factor requirement only when needed. Depending on the version,
Shibboleth may need to be upgraded prior to turning on two-factor authentication.
Q-21. Are resources available to assist with implementation?
U. T. System has several employees who are available to provide assistance. Assistance may consist of providing consulting and guidance on deployment of two-factor in various situations. Assistance can also be provided relating to upgrade and integration with
Shibboleth. Project management and training development and delivery is also available.
Send inquiries to CISO@utsystem.edu
.
Q-22 Where can I obtain more information?
Direct technical questions to Paul Caskey at: pcaskey@utsystem.edu
Direct policy questions to Lewis Watkins at: lwatkins@utsystem.edu
Q-23. What is the deadline for implementation?
August 31, 2015
Page 5 of 5