ArchPass Standard
1.0 Overview
The Vice President for Information Technology (VPIT) of the University of Georgia (UGA) is providing a Two-Factor Secure network (ArchPass) for University systems containing Restricted data.
2.0 Objective / Purpose
This standard outlines the criteria for systems to be placed behind ArchPass two-factor authentication. Also outlined within this standard are exception processes for: 1) systems that meet the criteria for ArchPass but are protected in a sufficient manner to warrant exclusion from ArchPass and 2) systems that do not meet the criteria for ArchPass but request ArchPass protection. This standard is to be applied in addition to the Minimum Security Standards for Sensitive Devices.
3.0 Scope
This standard applies to access to systems which contain Restricted data maintained by the University or a party acting on the behalf of the University. This standard does not apply to data or records that are personal property of a member of the University community or data created and/or kept by individual employees or affiliates for their own use.
4.0 Standard
4.1 Restricted Data Should Be Placed Behind Two-Factor Authentication
All University units should attempt to employ the ArchPass two-factor authentication solution for systems containing Restricted data.
4.2 Criteria for Placing Systems behind Two-Factor Authentication
Systems meeting all of the following criteria must be placed behind two-factor authentication.
- 4.2.1 Systems that are available through the campus firewall via remote VPN.
- 4.2.2 Systems that contain restricted information, including Social Security Numbers, Credit Card Holder Data, HIPAA Protected Health Information, or Customer Financial Information covered by the Gramm Leech Bliley Act.
- 4.2.3 Systems that are not accessed by students, unless the students require such access as a part of employment as a student worker, etc. Multi-factor authentication on student systems should be avoided when possible.
5.0 Exception Processes
5.1 Exception Processes for Two-Factor Authentication (ArchPass)
Exceptions may be granted in cases where security risks are mitigated by alternative methods, or in cases where security risks are at a low, acceptable level and compliance with minimum security requirements would interfere with legitimate academic or business needs. To request a security exception, use the Policy or Standard Exemption Request Form on the Office of Information Security (OIS) website.
5.2 Process 1: Request for system to not be behind Two-Factor Authentication (ArchPass), even if system meets requirements
Step 1: Requestor sends a request through the Policy or Standard Exemption Request Form on the Office of Information Security (OIS) website. Be certain to include that this is a request to not be behind Two-Factor Authentication (ArchPass) even if the system meets the criteria. Please provide the name of system, amount of sensitive data, type(s) of sensitive data, typical use, number of users, IP address, and reason for not wanting to participate.
Step 2: OIS will perform a risk assessment and provide a recommendation on accepting or rejecting the request.
Step 3: OIS will contact the requestor and let them know the decision.
Step 4: If the request is granted, no further action is needed.
Step 5: If the request is denied, OIS will work with the requestor to plan the migration process.
5.3 Process 2: Request for system to be placed behind Two-Factor Authentication (ArchPass), even if system does not meet requirements:
Step 1: Requestor sends a request through the Policy or Standard Exemption Request Form on the Office of Information Security (OIS) website. Be certain to include that this is a request to be behind Two-Factor Authentication (ArchPass) even if the system does not meet the criteria. Please provide the name of system, amount of sensitive data, type(s) of sensitive data, typical use, number of users, IP address, and reason for the request for inclusion in the ArchPass program.
Step 2: OIS will perform a risk assessment and provide a recommendation on accepting or rejecting the request.
Step 3: OIS will contact the requestor and let them know the decision.
Step 4: If the request is denied, no further action is needed.
Step 5: If the request is approved, OIS will work with the requestor to plan the migration process.
6.0 Enforcement and Implementation
6.1 Roles and Responsibilities
Each University department/unit is responsible for implementing, reviewing, and monitoring internal policies, practices, etc. to assure compliance with this standard. The Office of Chief Information Officer is responsible for enforcing this standard.
6.2 Consequences and Sanctions
Violation of this standard may incur the same types of disciplinary measures and consequences as violations of other University policies, including progressive discipline up to and including termination of employment or, in the cases where students are involved, reporting of a Student Code of Conduct violation.
Violation of this standard may also result in termination of contracts or commitments to vendors and other affiliates. Legal action may be pursued where appropriate.