1 PURPOSE
The University System of New Hampshire (USNH) is committed to preserving the privacy of the individuals who entrust us with their personal information and safeguarding the confidentiality, integrity, and availability of all institutional information and information technology resources. As such, this standard defines privileged access and identifies the security controls required to manage this elevated level of access.
2 SCOPE
This standard applies to all USNH business and academic units and USNH-owned information systems that collect, store, process, share or transmit institutional data. Personally owned devices connecting to the University Campus Network must meet the Bring Your Own Device standard requirements.
3 STANDARD
3.1 Privileged Access
Privileged access, which may also be referred to as “administrative access,” “administrator access,” or “super-user” access, is defined as access to a USNH information technology resource that enables an individual to directly modify that resource. For example:
- Access to a database that allows direct modification of the data in that database or to change the structure of the database itself, or to alter the configuration of the server the database sits on, would all be considered privileged access
- Access within an application that allows configuration or modification of the application for other users, allows for granting of access to that application, or that is used to administer that application in a way that the majority of users cannot
- Access to technology infrastructure (e.g., server, disk array, network device, router)
- Access to manage a cloud hosted service
Privileged access makes it possible to compromise the:
- Underlying stability and security of critical information technology resources
- Confidentiality and integrity of institutional information
- Availability of the resources and information necessary to conduct normal operations at all USNH component institutions
As such, additional security controls for managing privileged access shall be followed to mitigate the increased risk of compromise and unauthorized use.
3.1.1 Access to an application where a community member can configure their own experience or take actions within the application that result in modification of the data as the result of normal use of the application would not be considered privileged access
3.2 TYPES OF PRIVILEGED ACCESS
Privileged access can only be granted to those community members whose job responsibilities require it. There are two specific types of privileged access recognized at USNH.
3.2.1. Administrator Access
Administrator access is associated with specific types of roles like system administrator, database administrator, or network administrator. Although this type of privileged access encompasses the administration of a range of information technology resources, for ease in differentiation, this type of privileged access is referred to as Administrator Access throughout this Standard.
This type of privileged access provides one of the following types of authorizations, which are defined in more detail later in this Standard.
- Application Administrator Accounts
- Database Administrator Accounts
- Device and Interface Administrator Accounts
- Server Administrator Accounts
- System Administrator Accounts
3.2.2 Elevated Access
This type of privileged access relates specifically to authorizations that provide super-user level access to perform functions within an application. Unlike an Application Administrator Account, this access is not built into the application. It is an account set-up within the application to perform privileged functions like enabling access or determining authorization levels for other accounts, up to and including administering, configuring, or otherwise managing the application itself.
3.2.2.1 Elevated access may authorize a community member to perform an action or interact with information as another community member or to add/modify/delete information belonging to other community members in ways that other community members who do not have elevated access would not be able to.
3.3 SHARED ADMINISTRATOR ACCESS REQUIREMENTS
Administrator accounts, as defined in this section, are not generally associated with a named individual but are used by a small team that is responsible for administering the application, database, or other information technology resource. The team approach is only allowed when:
- It is required to ensure redundant coverage for support of the application AND
- The password for the account is managed in an approved password vault tool, where it can be checked out by authorized community members when this level of privileged access is required AND
- For Application Administrator Accounts only, the application only allows for one account with this kind of authorization to exist within the application
This is one of the few circumstances under which it is allowable for a shared account to exist at USNH.
3.3.1 Although this type of account cannot be tied to a non-primary identity, whenever possible, it should mirror the naming convention defined for non-primary identities used to provide administrator access defined in the Non-Primary Identity Management Standard.
3.3.2 This type of privileged access is considered a system administrator-level authorization under the USNH Password Policy. Additionally, as more than one individual has knowledge of the password for these accounts, the password shall also be changed whenever the membership of the team administering the information technology resource changes.
3.3.3 Any actions with this type of account must be logged, whenever it is technically possible to do so, to ensure an audit trail exists
3.4 Application Administrator Accounts
3.4.1 Application administrator access exists entirely within the bounds of the application that is being administered and is the account built into the application to provide full administrative control of the application. For example, when setting up most web applications, there is an account built into the application, often called “admin” or “administrator” that has all rights over the configuration and management of that application.
3.4.2 If the individuals responsible for administering the application also need user-level (non-privileged) access that allows them to use the application, the non-privileged access shall be provided by a separate authorization. The account used for administering the application cannot be used to perform nonprivileged actions.
3.5 Database Administrator Accounts
3.5.1 Database Administrator access is provided by a local “root” or master account that exists within and provides full access to the database. It allows creation, modification, and deletion of all databases within that instance and is also authorized to setup other identities and authorize access to databases.
3.5.2 If the individuals responsible for administering the database also need user-level (non-privileged) access that allows them to use the database, the non-privileged access shall be provided by a separate authorization. The account used for administering the database cannot be used to perform nonprivileged actions.
3.6 Device and Interface Administrator Accounts
Device and Interface Administrator access is provided by a local account that is embedded in the operating system of the device. These accounts are used for management and administration of Internet of Things (IoT) devices including, but not limited to, cameras, printers, network switches, uninterruptible power supply (UPS) systems, temperature sensors, and lights-out-management interfaces.
3.7 Server Administrator Accounts
3.7.1 A local master account provides server administrator access within the operating system installed on a server. This is the equivalent of a local admin account on a desktop or laptop. It is the "administrator" account on Windows servers, the "root" identity on a Linux/Unix server, and the first user account created on a macOS installation.
3.7.2 Although this type of administrator account must exist, it shall not be used to gain direct access to these resources except in emergencies. Regular access to these resources is provided via other mechanisms defined here.
3.8 System Administrator Access Requirements
3.8.1 System administrator access is granted to a specifically named individual using a non-primary identity. It cannot be granted to an individual's primary identity or authorized for any account tied to a primary identity. A non-primary identity enables this access as it segregates privileged access from non-privileged access and decreases the likelihood of, and potential for, unauthorized use of the privileged access.
System administrator access applies to the management of operating systems and applications, appliances, or tools.
3.8.2 Non-primary identities established to enable privileged access shall follow the following naming convention adm_username as defined in the Non-Primary Identity Management Standard.
3.8.3 System administrator access can only be used to perform actions that require privileged access. Non-privileged actions like checking email, using an internet browser, etc., shall only be performed with the individual's non-privileged access.
3.8.4 Although a system administrator account is, by nature, a privileged account, it shall still be configured based on least privilege, and only the privileged access needed to perform job duties shall be granted. Privileged access and additional permission within that authorization shall never be granted "in case" a community member might need them.
3.8.5 System administrator accounts can only be used by one individual, and all access granted to the non-primary identity used to provide the access shall be revoked when the community member's primary identity access changes.
3.8.6 This type of privileged access is considered a system administrator-level authorization under the USNH Password Policy.
3.8.7 Any actions with this type of account must be logged whenever it is technically possible to ensure an audit trail exists.
3.9 ELEVATED ACCESS REQUIREMENTS
3.9.1 Elevated Access is granted to a specifically named individual using a non-primary identity whenever technically possible and administratively practical and should not be given to an individual's primary identity or authorized for any account tied to a primary identity.
3.9.2 A non-primary identity enables this access as it segregates privileged access from non-privileged access and decreases the likelihood of, and potential for, unauthorized use of the privileged access.
3.9.3 Non-primary identities established to enable elevated access shall follow the naming convention adm_username defined in the Non-Primary Identity Management Standard. Elevated access shall be configured based on least privilege, and only the privileged access needed to perform job duties shall be granted. Privileged access and additional permissions within that authorization shall never be granted "in case" a community member needs them.
3.9.4 Elevated access accounts are not considered system administrator-level authorizations for password management.
3.9.5 Administrative (ADM) accounts will be allowed to authenticate to single sign-on services or systems only from a USNH trusted network location. Trusted network locations include the on-campus networks or the VPN.
3.10 GRANTING PRIVILEGED ACCESS
3.10.1 Privileged Access shall only be granted to individuals with an active USNH employee role associated with their primary identity, as defined in the Identity Management Standard.
3.10.2 Sponsored users and students at USNH component institutions cannot be granted privileged access to any USNH information technology resource. When this type of access is necessary to fulfill a business need, an exception to this standard shall be requested and approved.
3.10.3 Administrator Access to information technology resources shall be requested through the Cybersecurity Ops, Engineering & IAM (IAM) team according to the standard processes and procedures provided. This ensures access will be disabled/deprovisioned appropriately using standard de-provisioning procedures.
3.10.4 Elevated Access shall be requested via the standard request process for the specific application where the access is needed.
3.10.5 Requests for all privileged access shall have documented approval from the appropriate Technology Service Owner or Data Steward. The request and approval shall be stored for at least 12 months to preserve the audit trail.
3.10.6 Cybersecurity (Identity and Access Management (IAM) defines standard request/approval processes and procedures for privileged access.
3.10.7 All individuals granted privileged access shall be required to sign the Enterprise Technology & Services Confidentiality and Cybersecurity Agreement before the access is granted and annually after that as part of the annual privileged access review process.
3.10.8 Cybersecurity GRC is responsible for maintaining the Enterprise Technology & Services Confidentiality and Cybersecurity Agreement, preserving signed copies for all individuals required to sign it, notifying individuals when their agreement shall be resigned, and tracking completion of initial and annual renewal agreements.
3.11 ANNUAL PRIVILEGED ACCESS AUDIT
Business Application Owners and Technology Service Owners shall conduct an annual review of privileged access to the information technology resources under their purview. This review shall confirm the following:
-
Privileged access for each community member is still appropriate based on their current responsibilities.
-
Individuals with privileged access follow the specific requirements for this type of access defined in the USNH Password Policy.
-
Individuals with privileged access have agreed to the current Enterprise Technology & Services Confidentiality and Cybersecurity Agreement within the past 12 months.
3.11.1 The required annual audit of privileged access shall be conducted as part of the yearly overall access audit requirement defined in the Access Management Standard. Any privileged access identified as no longer needed during this audit shall be revoked immediately. The revocation date and reason shall be documented as part of audit results to preserve the audit trail.
DOCUMENT HISTORY
- Approved by: Tom Nudd, Chief Information Security Office V1.0, January 27, 2021
- Reviewed by: Dr. David Yasenchock, Director, Cybersecurity GRC
- Revision History:
- V 1.0 R Boyce-Werner, March 5, 2020
- V 1.1 Dr. David Yasenchock October 14, 2022
- V 1.2 Cybersecurity GRC Working Group, April 23, 2024
- K SWEENEY, Revised formatting, May 30, 2024
-
K Sweeney, Added section 3.9.5, Sept 25, 2024
