Information Security: Identity and Access Management Standard

Original Issuance Date: December 15, 2023

Last Revision Date: March 4, 2024

Effective Date: December 1, 2024

1. Purpose of Procedures

To provide structure and standards for the deployment and management of Information Technology (IT) Identity and Access Management (IAM) controls used to mitigate Information Security (IS) threats throughout the University of Wisconsin (UW) System.

2. Responsible UW System Officer

Associate Vice President for Information Security

3. Definitions

Please see SYS 1000, Information Security: General Terms and Definitions, for a list of general terms and definitions. Terms and definitions found within this policy include:

Account Types

Authentication

Authentication Assurance

Authorizations

Data Steward

Digital Credentials

Federated Identity Provider

Federation

High Impact System

High Risk

Identity

Identity Assurance

Identity Provider

IT Asset Owner

Low Risk

Multi-Factor Authentication (MFA)

Non-public Information Technology Resources

Password

Passwordless Authentication

Privileged Access Management (PAM)

Secret

User

User Affiliation

Zero Trust Architecture

4. Procedures

A. Standards

I. Identity and Authorization

1. Institution IT resources should use Identities and accounts managed by an institution Identity Provider or authorized Federations.
2. Institutions may require Users to have separate accounts for Privileged Authorizations, or they may implement role-based access control (RBAC) or use a hybrid approach. Highly Privileged Authorizations must use a separate account or Privileged Access Management (PAM) workflows.
3. Institutions must define procedures to ensure accounts and Identities have appropriate Identity Assurance, justification, and approvals. The following controls must be employed:
  1. Approvals for the creation and activation of Identities and accounts must be from a UW System or institution-controlled authoritative source.
  2. Institutions must ensure Authorizations are commensurate with each User’s roles and responsibilities within UW System and employ the principle of least privilege.
  3. Authorizations should apply separation of duties where required to reduce or eliminate the potential for abuse of authorized privileges without collusion.
  4. Privileged and Highly Privileged Authorizations must use Identities that are verified in-person or by secure remote Identity verification as defined by NIST 800-63 or verified using documented processes to achieve similar Identity Assurance.
  5. Highly Privileged Authorizations must be approved by the Data Steward(s) responsible for the IT Asset(s) the account intends to access.
4. Users must not reuse institutional Digital Credentials for personal accounts.
5. Shared Accounts must be used minimally with a documented approval process, purpose, and justification. The following controls must be employed with the use of Shared Accounts:
  1. Creation of a Shared Account must be authorized by the Data Steward(s) responsible for the IT Asset(s) in which the Shared Account will have access.
  2. Activation procedures must be defined based on acceptable risk for the Shared Account and align with requirements for Privileged and Highly Privileged Authorizations.
  3. Shared Accounts should not be used to access High Risk Data. When otherwise necessary, a Privileged Access Management (PAM) should be used to uniquely identify a User of a Shared Account.
6. Service Accounts must have the following controls:
  1. A documented approval process and be authorized by the corresponding IT Asset Data Steward and IT Asset Owner.
  2. Service Accounts with Highly Privileged Authorizations must be used minimally with a documented purpose and justification.

II. Authentication Controls

Authentication is required to access all Non-public Information Technology Resources. The following controls must be used to establish a minimum level of Authentication Assurance:

1. Multi-Factor Authentication (MFA) is required for all access except for read-only Low Risk data. Passwordless Authentication and other strong Authentication types with equivalent Authentication Assurance defined in NIST Special Publication (SP) 800-63B may be used.
2. When MFA or equivalent technology is not available or practical, Passwords alone may be used if adequate procedures exist to monitor that account access is removed or modified in the required timeframes as established in this Standard.
3. Identities and accounts used for Highly Privileged Authorizations should use a PAM solution or technology that achieves AAL3 as defined in NIST SP 800-63B.
4. Application Programming Interfaces (APIs) must use Authentication methods commensurate with acceptable risk.
5. Password controls must include:
  1. Minimum length of 12 characters and 16 characters for Service Accounts. Where devices do not support minimum Passwords, compensating controls must be deployed and documented to meet required Authentication Assurance.
  2. Passwords should be checked against a list of values known to be commonly used, expected, or compromised.
  3. Must not reuse the last 24 Passwords.
  4. User Account Passwords must be changed annually when MFA is not used for Authentication, or where there are not controls that monitor for compromised Passwords.
  5. Service Account Passwords must be changed at least every 5 years, or have compensating controls commensurate with the risk.
  6. Users must not use the same Password across multiple accounts.
  7. Users must not write down Secrets unless secured in an authorized manner that restricts unauthorized individuals from accessing the Secrets.
6. Accounts must be locked out after a maximum of 14 unsuccessful attempts, for a minimum of 5 minutes. If there are other controls to mitigate Password guessing and brute force attack, the account lockout may be up to 100 failed attempts for a minimum of 1 hour.
7. Session reauthentication controls:
  1. Users with Highly Privileged Authorizations accessing High Risk data and High Impact Systems must reauthenticate at least once per 12 hours or following any period of inactivity lasting 15 minutes. Users with Privileged Authorizations must reauthenticate at least once per 14 days. All other Users with Authorizations to Non-public Information Technology Resources must reauthenticate at least once per 30 days.
  2. Reauthentication must be commensurate with the initial Authentication process used to access the application, and it may require only a memorized Secret with the still-valid session Secret if the session has not reached its time limit.
  3. Institutions may use adaptive Authentication capabilities to enhance controls and support Zero Trust Architecture implementations.

III. Identity and Access Lifecycle Management

The following are controls pertaining to the creation, maintenance, and deactivation of accounts, Identities, and Authorizations:

1. Initial Passwords and Password resets must force the User to change the Password upon first use.
2. Recovering authenticators that are lost requires the same Identity Assurance.
3. When Passwordless Authentication is used, institutions must implement lifecycle management controls for the authenticators.
4. Users must immediately change Passwords and notify the institution if they have reason to believe their Digital Credentials have been compromised.
5. Accounts, Identities, and corresponding Authorization attributes must be removed, disabled, or adjusted within the following timeframes, or as defined for the User Affiliation in the institution’s high-level IAM architecture documentation. This includes Shared and Service Accounts when Users have knowledge of the Digital Credentials:
  1. When access is no longer required by the User or the User’s roles and responsibilities change:
    1. Standard Authorizations – maximum 90 days
    2. Privileged Authorizations – maximum 96 hours.
    3. Highly Privileged Authorizations – maximum 48 hours
  2. Immediately for involuntarily terminated, expelled, or other potentially adversarial changes in relationship.
  3. Immediately for compromised Identities and accounts, including authenticator loss, theft, damage, and unauthorized duplication.
6. Account identifiers should not be reused for different Users and should be reused for a returning User. If an account identifier is reused for a different User, default Authorizations must limit access to mitigate risk from reuse, must have controls that monitor for timely decommissioning, and the account identifier must be inactive for a minimum of one year prior to reuse.
7. Attestation is required for Highly Privileged Authorizations, Shared Accounts, and Service Accounts, and must be reviewed annually by authorization approver or delegated authority to verify appropriate Authorizations.

IV. Identity Provider Services

The following controls are required for Identity Provider services:

1. Applications and institution Identity Providers must ensure Authentication Secrets are not:
  1. Written to any persistent store, unless required for Authentication.
  2. Maintained in system memory beyond the end of the User’s session.
  3. Used for any purpose beyond Authenticating the User for the service the User is logging into, unless required by IAM operations.
2. All applications that use the institution or UW System Identity Providers must designate primary technical and security contact(s).
3. When Federated Identity Providers are used, institutions must have an authorization process, and must verify the I&A Assurance levels claimed by the provider meets the assurance levels required by this policy. Where UW policy requirements are unable to be met, compensating controls must be implemented and documented to meet I&A Assurance requirements.
4. Institution Identity Providers should maintain capabilities that allow immediate termination of a session upon notice of a compromise or to mitigate other security events.

5. Related Documents

NIST Special Publication 800-63

Regent Policy Document 25-3, Acceptable Use of Information Technology Resources

UW System Administrative Policy 1030, Information Security: Identity and Access Management

6. Procedure History

Revision 1: March 4, 2024

First Approved: December 15, 2023

UW System Administrative Procedure 1030.A