Access Control Standards
Overview
This updated standard is to help align existing IT practices around access controls to the requirements in NIST 800-171 (AC | 3.1.x) as well as industry best practices.
What is in this document:
- Zero trust requirements for high-risk data
- Application of principle of least privilege from APM 30.10
- Requirements of external/public systems
- Session and timeout requirements
- Remote and wireless access
What is NOT in this document:
- Identity types and authentication (see: Identity and Authentication standard)
- Auditing requirements for authentication (see: Audit and Accountability standard)
- Full coverage of 3.1.* under NIST 800-171 for Controlled Unclassified Information
Potential impact or action items for implementing this standard:
- System and application owners may need to formally document user access and privileges per C. 2.
- Operators of Public Systems will need to register and document according to C. 3. B. including any process updates necessary.
- Select systems will implement device health and management requirements per C. 1. B. which may require testing, user communication and guidance. Devices must be managed and healthy to access high-risk systems.
- Managers of privileged access should review how they document access requests per C. 2.
- Changes for application timeouts will need to be implemented for C. 5. which may impact some users. For example, to re-authenticate every 12 hours instead of 24 hours on applications on unmanaged devices.
Policy Reference
APM 30.10 Identity and Access Management Policy
APM 30.11 University Data Classification and Standards
APM 30.12 Acceptable Use of Technology Resources
APM 30.14 Cyber Incident Reporting and Response
APM 30.16 Technology Hardware Lifecycle Management
Purpose
This Access Control standard supports APM 30.11 University Data Classification and Standards and other relevant university policies.
Scope
These standards are the minimum baseline for all managed and unmanaged systems that access, store or process University of Idaho data (see APM 30.14 C-6) or using University of Idaho technology resources (see APM 30.12 C-1) at the Low, Moderate- or High risk levels (see APM 30.11) not otherwise covered by an approved systems security plan.
Standards
Non-public systems must identify users and/or devices prior to access.
- 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 - 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
- Currently supported operating system.
- Latest security patches are installed within 30 days to allow a grace period for patches to be installed as per patching requirements.
- Device has a password set.
- Device is encrypted.
- Device has the system firewall enabled.
- Identified as a unique managed technology device.
- University Managed endpoint security is installed where supported.
- 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:
- 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
- If multiple levels of permissions are provided, such as privileged or administrator roles, each group must be documented.
- Moderate and high-risk applications must also provide role/permissions provided to account type or group.
- Limit access to only users and systems with a legitimate education interest or documented business requirement.
Applies to: Low / Moderate / High
- Document and retain user access requests and approvals for at least 1-year.
Applies to: Moderate / High
- Disable account access once there is no longer a requirement for access.
Applies to: Low / Moderate / High
- 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
- Privileged accounts are identified through the ‘su-‘, ‘ad-‘, ‘admin-‘ or ‘net-‘ prefixes. (3.1.5[a], 3.5.3[b])
- Privileged accounts not using these prefixes may exist that are specific to local systems or applications if recorded as privileged accounts within application documentation.
- 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:
- External systems for storage:
- Must not be used in place of systems defined in ‘approved storage locations’3 or ‘What Microsoft 365 Applications are approved for use?‘4 knowledge base articles. (3.1.20[a-b])
Applies to: Low / Moderate / High
- 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])
- 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
- Must not be used in place of systems defined in ‘approved storage locations’3 or ‘What Microsoft 365 Applications are approved for use?‘4 knowledge base articles. (3.1.20[a-b])
- For public systems:
- Application owners must create and maintain a list of users authorized to publish. (3.1.22[a])
Applies to: Low / Moderate / High
- 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
- 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
- Application owners must define post/content removal or correction procedures. (3.1.22[e])
Procedure must:
- Include who removals must be reported to.
- Be able to complete required remediation within a timely manner required by CSIRT as per APM 30.14.
Applies to: Low / Moderate / High
- Application owners must create and maintain a list of users authorized to publish. (3.1.22[a])
To ensure trust in the login mechanism, systems must adhere to the following standards:
- Automatically lock accounts after at most 20 bad attempts within 10 minutes. (3.1.8[a-b])
Applies to: Low / Moderate / High
- Managed technology device must include the approved system use notification defined in the system use notification knowledge base article5.
Applies to: Low / Moderate / High
- 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 - Requests for extended timeouts must be approved by OIT Security.
- 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.
- Applications must have either a 30-day session limit or a lockout/timeout after 14 days of inactivity (idle).
Applies to: Low
- Application must have a 12-hour session limit and timeout after 30 minutes of inactivity (idle).
Applies to: Moderate
- Reauthentication must use at least one (1) authentication factor as defined by IT Account Creation, Retention and Expiration Standards.
- Sessions with managed devices or applications can utilize the device lockout period rather than enforcement via the web app.
- Applications must have a 12-hour session limit and a lockout after 15 minutes of inactivity (idle).
Applies to: High
- Reauthentication must use at least two (2) authentication factors as defined by IT Account Creation, Retention and Expiration Standards.
- Applications must have either a 30-day session limit or a lockout/timeout after 14 days of inactivity (idle).
- 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
- Terminate user sessions fully and automatically when requested by user or administrator.
Applies to: Low / Moderate / High
- 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.rnveurope.com, or an approved path that will adhere to these standards: (3.1.12[a-b], 3.1.14[a-b])
- Authentication events are recorded with user, timestamp, authentication outcome, remote and assigned IP. (3.1.12[d])
- Remote access must use university credentials and OIT-managed MFA. (3.1.12[c])
- Authentication and session will use strong, modern TLS encryption that is kept up to date. (3.1.13[a-b])
- Regulated data will be required to use approved and validated algorithms such as FIPS.
- 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:
- Wireless Access Points used are recorded within NMS and are managed by OIT. (3.1.16[a-b])
- Wireless access requires authentication over an encrypted channel. (3.1.17[a])
- U of I internal networks such as AirVandalGold — WPA2 Enterprise using PEAP and MSCHAPv2 or EAP-TLS (3.1.17[b])
- U of I Public, Guest or event networks — WPA2 Pre Shared Key (PSK)
Other References
1. NIST SP800-171r2 (February 2020)
All referenced controls are NIST 800-171r2 unless otherwise noted.
2. NIST SP800-53r5 (September 2020)
4. What Microsoft 365 Applications are approved for use?
6. NIST SP800-63-3 summary table
7. IT Account Creation, Retention and Expiration Standards
Definitions
1. Authorized User
Any appropriately cleared individual with a requirement to access an information system.
2. Processes
An application, program, script or other software. The sensitivity of which is determined by the data it can access, including API calls to other applications and local data it brings into memory.
3. Authorized publishers
An individual person who has permissions to publish information on a system.
4. External system
“A system or component of a system that is outside of the authorization boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.” NIST SP800-171r2
5. Public system
A system or application that can be accessed in any form from the general public or the internet.
6. Privileged functionality (3.1.7[a])
Functionality that can impact the confidentiality, integrity or availability of data including but not limited to changes to access permissions, roles, security configuration, changes directly to high-risk or non-public data of other users or that impact the security of high-risk or non-public data of other users.
7. Non-privileged functionality
Standard user activity including but not limited to email, web browsing and general-class tasks.
8. Non-privileged User (3.1.7[b])
A user that is unable to perform privileged functionality. May also be referred to as a standard user or account.
9. Remote Access
“Access to an organizational system by a user (or a process acting on behalf of a user) communicating through an external network (e.g., the Internet).” NIST SP800-171r2
10. Session lockout
A method of removing access to a system that retains the user session information and does not interrupt running processes, but still requires re-authentication prior to regaining access to the system.
11. Session timeout
A Method of removing access to a system that removes the user session information completely and requires re-authentication.
12. Session limit
The length of time a session is valid regardless of activity.
13. System
“A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of information.” NIST SP800-171r2
14. Operating system
“A collection of software that manages computer hardware resources and provides common services for computer programs.” NIST SP 800-152. Includes but is not limited to:
- Windows
- MacOS
- Linux distributions (Ubuntu, RedHat, etc.)
- Android
- iPhone/iPad iOS
- Vendor provided appliance OS
15. University of Idaho Network Management System (NMS)
University of Idaho proprietary system for managing networks, devices on networks and connections between networks.
16. Managed Technology Device
Standard technology hardware that is managed by OIT-defined security and management software. See APM 30.16 Section C-2.
Standard Owner
U of I Office of Information Technology (OIT) is responsible for the content and management of these standards.
VERSION | AUTHOR(S) | DATE | NOTES |
---|---|---|---|
V1 | N. Flynn, M. Parks | 6/23/2023 | |