ÀÏ°ÄÃÅ×ÊÁÏ

I. OBJECTIVE & PURPOSE

Accounts that access electronic computing and information resources require prudent oversight. The objective and purpose of this policy is to establish a standard for the administrative activity related to the user account life-cycle at the ÀÏ°ÄÃÅ×ÊÁÏ (ÀÏ°ÄÃÅ×ÊÁÏ). The process involved with managing the account life-cycle is commonly referred to as Identity Lifecycle Management.

II. STATEMENT OF POLICY

This policy is applicable to all users and applications that will access information technology resources at ÀÏ°ÄÃÅ×ÊÁÏ. The policy also applies to individuals that are responsible for account management, as well individuals who have access to shared information or University networks. This policy covers departmental and centrally managed accounts, as well as service accounts.

III. DEFINITIONS

• Account - Any combination of a User ID (sometimes referred to as a username) and authentication token(s) (i.e., passwords or passphrases) that grants an individual user access to a computer, an application, the network or any other information or technology resource.
• Attribute - A piece of information that determines the properties of a field or tag in a database or a string of characters in a display.
• Authentication- The process or action of verifying the identity of a user or process.
• Account Provisioning - A business process for creating and managing access to resources in an information technology (IT) system. To be effective, an account provisioning process shall ensure that the creation of accounts and access to software and data is consistent and simple to administer.
• Local Administrator - An individual in a non-ITS department responsible for administering access control for a local system.
• Data Owner - An individual responsible for the accuracy and integrity of a set of data.
• De-provisioning - The act of removing access from, and freeing up resources reserved by end users including the related file transfer workflows.
• Guest Account - A user account created for a person with no formal relationship to the university that is granted very limited privileges, permissions and access to resources on a network.
• Identity Lifecycle Management - Collection of technologies and business processes utilized in creating, managing, coordinating and restricting the identification, access and governance of identities for access to business tools and information.
• Multi-Factor Authentication - A method of confirming a user's claimed identity in which a user is granted access only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism.
• Principle of Least Privilege - The concept of promoting minimal user profile privileges on computers, based on users' job duties. When applied to processes on the computer, each system component or process shall have the least authority necessary to perform its duties.
• Privilege - Allocated powers that a particular end user has to a particular system resource, such as a file or folder.
• Privileged Account - User account that has been allocated powers within the computer system which are significantly greater than those available to the majority of users.
• Privilege Creep - The gradual accumulation of access beyond what an individual needs to do their job.
• Service Account - An account that is created explicitly to provide a security context for services running as a server.
• Shared Account - A user account that can be used by more than one user.
• Shared Secrets - Pieces of data, known only to the parties involved, which are used in a secure communication method. The shared secret can be a password, a passphrase, a big number, or an array of randomly chosen bytes.

IV. ACCOUNT REQUIREMENTS

An account (at a minimum) consists of a user ID and unique authentication token(s) (usually a password/passphrase). All accounts will have associated attributes that determine which resources on the network the user is authorized to access. Passwords must comply with the requirements set forth in the Passwords on Computing Systems Managed by ITS policy.

V. IDENTITY LIFECYCLE MANAGEMENT

Account Provisioning (Account creation)

The departmental owners, administrators and administrative entities of ÀÏ°ÄÃÅ×ÊÁÏ data (Data Stewards), shall make decisions regarding access to their data. Account setup and modification require the approval of the requestor's supervisor and/or the Data Steward.

The Data Steward is to determine the proper levels of access granted. This level of access is to be founded upon the principle of least privilege. The "principle of least privilege" dictates that access is to be granted based on the minimum requirements needed to fulfill job responsibilities.

The identity of users must be authenticated before providing them with account and password details. Delivery of usernames and passwords is to be accomplished in a secure manner. Usernames/Passwords shall NOT be emailed to any party including (but not limited to) remote users and vendors.

The date when the account was issued shall be recorded in an audit log.

Active Accounts Management

All accounts shall be reviewed at least annually by the Data Owner(s) or authorized designee; this is to ensure that access and account privileges are commensurate with job function and to remediate privilege creep. The Information Technology Services (ITS) department will also conduct periodic reviews for any system connected to the ÀÏ°ÄÃÅ×ÊÁÏ network.

All guest accounts with access to ÀÏ°ÄÃÅ×ÊÁÏ computing resources shall contain an expiration date of six months or the work completion date, whichever occurs first. All guest accounts must be sponsored by someone with an advanced level of oversight such as a dean, director, etc. Each sponsor will be accountable for all actions of the guest during the window of access.

Administrative entities are responsible for notifying IT Security for all role changes including but not limited to: new job, different assignment, duty change, or access no longer needed.

Account De-Provisioning (Disabling/Revoking/Accounts)

All accounts will be disabled, or revoked if account privileges are no longer commensurate with an individual's function at the university, or their "need-to‐know" status changes.

All accounts will be de-provisioned if it is determined that the account has been compromised or misused, and will only be reinstated at the direction of the Chief Information Officer (CIO) or their designee.

Under normal circumstances, user account de-provisioning will adhere to the following schedule:

• Active Student and Alumni - Expire at the beginning of the third term without enrollment at ÀÏ°ÄÃÅ×ÊÁÏ.
• Expelled Students - Privileges may be terminated immediately at the direction of the Vice President of Student Affairs or the Student Ombudsman.
• Employee (Faculty/Staff) - Expire at the point of termination.
• Retiree Faculty and Staff - Same as employee accounts, with opt-in email forwarding address creation.
• Emeritus Faculty - Retain email account until no longer needed.
• Consultants, guests, and other outside individuals - Until the account is no longer needed or six months is reached. Renewals for another 6 months are available upon request.

Emergency circumstances such as an emergency termination may require that a user account be de-provisioned immediately. Any such request must be initiated from Human Resources Director of Employee Labor Relations.

VI. INDIVIDUAL ACCOUNT STANDARDS

Account Holder Responsibilities

Users are responsible for all activity performed with their username, which is their ÀÏ°ÄÃÅ×ÊÁÏ ID. ÀÏ°ÄÃÅ×ÊÁÏ IDs shall not be utilized by anyone but the individuals to whom they have been issued. Users shall not allow others to perform any activity with their ÀÏ°ÄÃÅ×ÊÁÏ IDs. Similarly, users are not to perform any activity with ÀÏ°ÄÃÅ×ÊÁÏ IDs belonging to other users. A user lacks any authority to delegate use of their ÀÏ°ÄÃÅ×ÊÁÏID to any other person for any reason. All of the aforementioned scenarios constitute unauthorized access. Any suspected unauthorized access of a user account shall be reported immediately to the ITS Help Desk or ITS Security.

Passwords

Users are solely responsible for the confidentiality of their authentication token(s). Regardless of the circumstances, passwords must never be shared. To do so exposes the authorized user to responsibility for any actions that the other party takes with the password. If users need to share computer files, they shall use official, University provided mechanisms, so long as doing so does not violate any applicable policies, regulations, laws or other compliance requirements. All users are responsible for both the protection of their user account password and the data secured by or accessed via their user account. For further guidance on handling computer data, users may refer to the Network Acceptable Use Policy.

Departmental Accounts

For access to sensitive information managed by a department, account management processes shall comply with the standards outlined above. In addition, naming conventions shall not deviate from the format used by centrally managed email addresses or usernames. Should the potential for deviation arise, the applicable system(s) shall not be connected to the campus network until a mutually satisfactory arrangement is reached.

Shared Accounts

Use of shared accounts is normally prohibited. However, there may be circumstances in which the functionality of a process, system, device or application may require the use of a shared account. Such exceptions will require documentation that justifies the need for a shared account, with a copy of the documentation shared with ITS. Each shared account must have a designated owner who is responsible for the management of access to that account and the actions taken by proxy users of the account. The owner is also responsible for the above mentioned documentation, which shall include a list of individuals who have access to the shared account. The documentation must be available upon request for an audit or a security assessment. Any exceptions must be approved by the Chief Information Officer (CIO) or their designee.

VII. ADMINISTRATION OF PASSWORD CHANGES

Procedures for password resets

The identity of users must be authenticated before providing them with ID and password details. In addition, it is required that stricter levels of authentication (such as face-to-face) be used for those accounts with privileged access.

Whenever possible, temporary passwords (passkeys) shall be used to authenticate a user when resetting a password or activating a guest account, and will comply with the above standards. Passkeys provide one-time access to a system or application and require the user to change to a password of their choice upon initial login. Where passkeys are not feasible, pre-expired passwords will be used.

Automated password resets are available and will be utilized, provided that a recognized and approved method is used such as multiple randomized challenge and response questions.

• Passwords must be reset in an encrypted fashion (HTTPS, SSL, SSH, or VPN, for example).
• Password change events shall be recorded in an audit log.

Procedures for maintenance of "shared secrets"

Those responsible for access to systems/applications/servers, etc. protected by high-level super-user passwords (or the equivalent) must have proper auditable procedures in place to maintain custody of those "shared secrets" in the event of an emergency and/or should the super-user password holder become unavailable. These documented procedures, which must be appropriately secured, shall delineate how these passwords are logically or physically accessed, as well as who in the "chain of command" becomes responsible for access to and/or resets the password.

VIII. APPLICATION AND SYSTEM STANDARDS

Applications developed at ÀÏ°ÄÃÅ×ÊÁÏ or purchased from a vendor shall contain the following security precautions:

• Where technically or administratively feasible, shared ID authentication shall not be permitted.
• Authentication shall occur external to an application, i.e., applications will NOT implement their own authentication mechanism. Instead, existing University managed authentication services shall be relied upon. Examples include LDAP, CAS, Shibboleth, etc.
• Passwords must not be stored in clear text or in any easily reversible form.
• Role-based access controls shall be used whenever feasible in order to support changes in staff or assigned duties.
• Where technically or administratively feasible, systems shall allow for lockouts after a set number of failed attempts (six is the recommended number). Access shall then be locked for a minimum of ten minutes, unless a local system administrator intercedes. Lock-outs shall be logged unless the log information includes password information. Refer to the Passwords on Computing Systems Managed by ITS Policy.