Access Control

Non-public systems must identify users and/or devices prior to access.

1. Authentication sources use identity types as defined by Identification and Authentication standard section D-1. (3.1.1[a-c])
   Applies to: Low / Moderate / High
2. Any device used to access high-risk university resources must be identified as a healthy, managed technology device by one of the following approved methods: Duo device health, Azure Conditional access, signed device certificates or other OIT-approved inventory meeting conditions below:

   Applies to: High

   1. Currently supported operating system.
   2. Latest security patches are installed within 30 days to allow a grace period for patches to be installed as per patching requirements.
   3. Device has a password set.
   4. Device is encrypted.
   5. Device has the system firewall enabled.
   6. Identified as a unique managed technology device.
   7. University Managed endpoint security is installed where supported.
3. Authorization is granted to resources based on identity types based on groups or affiliation within an OIT-managed identity source (3.1.2[e-f])

   Applies to: Low / Moderate / High

To ensure compliance with APM 30.10 B-1 the following standards ensure least privilege is implemented and is auditable:

1. System/Application owners must document authorized account types or groups within documentation as well as any relevant system security plans or knowledge base articles. (3.1.2[a-b])

   Applies to: Low / Moderate / High

   1. If multiple levels of permissions are provided, such as privileged or administrator roles, each group must be documented.
   2. Moderate and high-risk applications must also provide role/permissions provided to account type or group.
2. Limit access to only users and systems with a legitimate education interest or documented business requirement.

   Applies to: Low / Moderate / High

3. Document and retain user access requests and approvals for at least 1-year.

   Applies to: Moderate / High

4. Disable account access once there is no longer a requirement for access.

   Applies to: Low / Moderate / High

5. Privileged functionality must be limited only to accounts intended to be privileged accounts as per APM 30.10 Section A-2. (3.1.7[c])

   Applies to: Moderate / High

   1. Privileged accounts are identified through the ‘su-‘, ‘ad-‘, ‘admin-‘ or ‘net-‘ prefixes. (3.1.5[a], 3.5.3[b])
6. Privileged accounts not using these prefixes may exist that are specific to local systems or applications if recorded as privileged accounts within application documentation.
7. Privileged accounts must not be used for non-privileged functions as per APM 30.10 Section B-1. (3.1.6[b])

To ensure data is not inappropriately being shared:

1. External systems for storage:
   1. Must not be used in place of systems defined in ‘approved storage locations’³ or ‘What Microsoft 365 Applications are approved for use?‘⁴ knowledge base articles. (3.1.20[a-b])

      Applies to: Low / Moderate / High

      1. Unapproved systems or applications are subject to restrictions via network or other application controls if sufficient risk is identified by OIT Security and restriction is approved by CIO/VP of IT. (3.1.20[c-d])
   2. May only be used for university data after being reviewed and approved by OIT prior to use for university purposes. (3.1.20[e-f])

      Applies to: Low / Moderate / High

2. For public systems:
   1. Application owners must create and maintain a list of users authorized to publish. (3.1.22[a])

      Applies to: Low / Moderate / High

   2. Application owners must define a procedure of review, including a data sensitivity review, prior to posting or enabling in cases of automated publishing systems. (3.1.22[b-c])

      Applies to: Low / Moderate / High

   3. Application owners must register systems with OIT as they are created and attest that postings do not and will not contain non-public information and are periodically reviewed at the system owner's or OIT’s discretion. (3.1.22[d])

      Applies to: Low / Moderate / High

   4. Application owners must define post/content removal or correction procedures. (3.1.22[e])

      Procedure must:

      1. Include who removals must be reported to.
      2. Be able to complete required remediation within a timely manner required by CSIRT as per APM 30.14.

         Applies to: Low / Moderate / High

To ensure trust in the login mechanism, systems must adhere to the following standards:

1. Automatically lock accounts after at most 20 bad attempts within 10 minutes. (3.1.8[a-b])

   Applies to: Low / Moderate / High

2. Managed technology device must include the approved system use notification defined in the system use notification knowledge base article⁵.

   Applies to: Low / Moderate / High

1. Enforce a session lockout and timeout for user access to systems after a period of inactivity (idle) (3.1.10[a-b], 3.1.11[a-b]):

   Applies to: Low / Moderate / High

   Device/Access type	Lockout	Timeout
   Default	15 mins	N/A
   High-risk systems	5 mins	N/A
   Shared workstations	15 mins	20 mins
   Shared high-risk workstations	5 mins	20 mins
   SSH Access	3 min keep alive	90 mins

   1. Requests for extended timeouts must be approved by OIT Security.
2. Enforce a web session limit for user access and a lockout/timeout for user access after a period of inactivity (idle) consistent with NIST 800-63b.
   1. Applications must have either a 30-day session limit or a lockout/timeout after 14 days of inactivity (idle).

      Applies to: Low

   2. Application must have a 12-hour session limit and timeout after 30 minutes of inactivity (idle).

      Applies to: Moderate

      1. Reauthentication must use at least one (1) authentication factor as defined by IT Account Creation, Retention and Expiration Standards.
      2. Sessions with managed devices or applications can utilize the device lockout period rather than enforcement via the web app.
   3. Applications must have a 12-hour session limit and a lockout after 15 minutes of inactivity (idle).

      Applies to: High

      1. Reauthentication must use at least two (2) authentication factors as defined by IT Account Creation, Retention and Expiration Standards.
3. Lockout for operating systems must show a pattern-hiding display such as a lock screen, static images, a clock or even a blank screen. (3.1.10[c])

   Applies to: Low / Moderate / High

4. Terminate user sessions fully and automatically when requested by user or administrator.

   Applies to: Low / Moderate / High

5. Automatically terminate sessions when sessions are no longer required or valid.

   Applies to: Low / Moderate / High

Remote access is granted through the U of I VPN, vpn.uidaho.edu, or an approved path that will adhere to these standards: (3.1.12[a-b], 3.1.14[a-b])

1. Authentication events are recorded with user, timestamp, authentication outcome, remote and assigned IP. (3.1.12[d])
2. Remote access must use university credentials and OIT-managed MFA. (3.1.12[c])
3. Authentication and session will use strong, modern TLS encryption that is kept up to date. (3.1.13[a-b])
   1. Regulated data will be required to use approved and validated algorithms such as FIPS.
4. Remote access to high-risk networks requires device authentication as listed in Section C-1b of this document.

To ensure data and systems can be safely accessed and utilized by in-person individuals, they must utilize the appropriate U of I wireless networks while using wireless on campus which will adhere to these standards:

1. Wireless Access Points used are recorded within NMS and are managed by OIT. (3.1.16[a-b])
2. Wireless access requires authentication over an encrypted channel. (3.1.17[a])
   1. U of I internal networks such as AirVandalGold — WPA2 Enterprise using PEAP and MSCHAPv2 or EAP-TLS (3.1.17[b])
   2. U of I Public, Guest or event networks — WPA2 Pre Shared Key (PSK)