Applies to: (examples; Faculty,Staff, Students, etc)

Faculty , Staff , Students , Contractors_Vendors

Policy Overview:

This policy describes types of electronic identities in use for systems and applications; criteria for creating identities and accounts; how identities should be authenticated; how authorizations should be managed; and how accounts and privileges should be deprovisioned.

Applies to all active members of the University community, including faculty, students, staff, and affiliates, and to authorized visitors, guests, and others for whom University technology resources and network access are made available by the University.  This policy also applies to campus visitors who avail themselves of the University’s temporary visitor wireless network access, and to those who register their computers and other devices through Conference and Event Services programs or through other offices, for use of the campus network. 

Details:

Part I of the policy is applicable to individual account holders. It defines account holders’ responsibilities to protect their accounts and properly use their authorizations.

Part II of the policy is applicable to Information System operators responsible for Identity and Access Management for information systems.

Procedures:

Responsibilities of the Individual

Every person with access to University’s systems is responsible for selecting strong passwords, keeping the passwords secure, and reporting any unauthorized use of accounts.

Users must:

• Create passwords that conform to best practices for selecting passwords which address length and complexity.
• Not share passwords related to any University system with any other person.
• Not use passwords related to any University system for non-University accounts.
• Immediately change passwords and notify the appropriate system administrator and/or Information Security if there is reason to believe that a password has been improperly disclosed, accessed or used by an unauthorized person.
• Use privileges associated with an account only for the purpose for which they were authorized.
• Use privileged accounts and authorizations only when such privilege is needed to complete a function.
• Log off or use screen locking technologies that require authentication when leaving a device unattended.

This part of the policy applies to all University community members who configure and/or maintain devices and applications for the University.

Account Types
There are three types of accounts at UHSP:

User Accounts: These are uniquely associated with a specific person. These accounts may either exist in a central repository to which systems may federate to consume the identity and authentication information or they may be created locally on a system or device where federation is not practical or possible. The use of the centrally created account with federated authentication is always the preferred method.

Shared Accounts: Shared accounts are created to support multiple users sharing the same identity. For example, these may be created when there is a need to share a set of resources or because a poor product implementation requires it. The use of shared accounts should be discouraged as it lacks accountability.

Service Accounts: A service account is used when it is necessary for systems or applications to authenticate to other systems or applications without any association to a person. These accounts should be created sparingly and documentation of the purpose for them should be kept. Their use must be periodically reviewed. Further, the password requirements for service accounts must be no less stringent than user accounts. Finally, service accounts may not be used by people to authenticate aside from initial testing. Service accounts with elevated privileges must be closely monitored for abuse.

Sub Account Types

There are three sub account types that primary account types can fall into.

Centrally Managed Accounts: The process of requesting a centrally managed account is defined by Information Services & Technology’s Identity and Access Management Service and adhere to the following guidelines:

Limit the use of generic or shared accounts.

Systems storing Restricted Use and/or Confidential information must not be configured to allow access using shared or anonymous accounts.

NOTE: Enterprise Directory Services
Information about centrally created accounts and identities are stored in central directory run by Information Services and Technology. The most common implementations of the directory service are Active Directory (AD) and Lightweight Directory Access Protocol (LDAP). University information systems should use enterprise directory services whenever possible and avoid creating local accounts and authorizations.

Non-centrally Managed Accounts: When accounts or authorizations are created outside of the enterprise directory and/or enterprise authentication system, the unit creating the accounts must define the procedure by which they will be approved and created. The procedure must be consistent with the guidelines expressed for centrally managed accounts.

Privileged Accounts: Certain accounts may have extra privileges related to the management of a device or application. This is often thought of as an account type but it is more accurately described as an account with privileged authorizations. Administrative privilege can be added to any of the three account types. Having at least one account with privileges is generally unavoidable but the use of privilege should be limited and the direct use of shared accounts with privileges should be discouraged as it lacks accountability.

Authentication

Authentication is the process by which a system or application confirms that a person or device really is who or what it is claiming to be and through which access to the requested resource is authorized. Strong authentication protocols help both to protect personal and University information and prevent misuse of University resources.

All accounts, centrally defined or not, must require authentication before use, except in rare cases when it is necessary to use an account that does not require authentication for “anonymous” access. Anonymous access may be used only for information classified as Public in the Data Classification.

Types of Authentication
Authentication may take many forms. Authentication is generally broken down into three types:

• Something you know: The most common forms are a password, pin, or pattern.
• Something you have: The most common forms are a hardware token, certificate, or a software authenticator like Duo or Microsoft Authenticator.
• Something you are: This category is often called biometric authentication and the most common form is fingerprint readers including Apple’s Touch-ID.
  Multifactor Authentication (MFA) involves combining more than one authentication type and generally provides a stronger assurance of the person’s identity. Combining only two of the types is called two-factor authentication (2FA).

Enterprise Authentication Services: Authentication credentials for centrally created accounts and identities are stored in central repositories run by the Information Technology Department.  Passwords are stored centrally in a Kerberos database. 

Federated Authentication: Systems and applications may authenticate identities using our enterprise authentication services by federating with them.  For systems and non-web applications, federation for password authentication is achieved through direct Kerberos authentication or by joining the system to our Active Directory.  Systems and non-web applications may also federate with our Azure AD services.

Shared and Service Accounts: Credentials for accounts that are shared or used by systems or applications must be handled carefully. Follow the following rules when managing these credentials:

• Ensure that only people with a need to know a password have access to it.
• Where reasonable, use multifactor authentication for these accounts, especially on accounts that have privilege such as application or system administrator accounts.
• Where reasonable, require the individual to authenticate to the system as an individual first and then switch to the administrator account, such as the capability provided by the Linux/Unix sudo utility.
• Change the password associated with the account any time a person with knowledge of it ends their affiliation with the University.
• Avoid saving passwords in scripts and configuration files that can be read by others.
• Where possible, apply secondary controls on how these accounts may be used such as by controlling where the accounts can be used from (on campus only, e.g.) or when (working hours only).

Application and System Administrator Responsibilities
Any person charged with the responsibility of setting up a system or application that requires authentication must configure the system to enforce our authentication policy (below) to the extent possible within the system or application. Variances from the stated authentication policy for Restricted Use systems must be approved by the Information Security Team.

Authentication Policy

Whenever possible and reasonable, any application or system, whether on premise or in the cloud, should use federated authentication over local accounts and passwords. The minimum password length is 12 characters and longer is recommended. Passwords must be complex. Passphrases are recommended so users can have a long password without the complexity. Example: “Today is a bright and sunshiny day.” Passphrases that are long offer better protection than short complex passwords with number, letters (upper and lower case), and symbols.

Authorization

Authorizations are the implicit or explicit permission to use a resource associated with an account. Once the use of an account is authenticated, a system or resource may determine if the person or software requesting access is authorized to use it. The management and maintenance of authorizations is shared responsibility of Information Services & Technology and local system and application administrators.

All units engaged in granting authorizations are encouraged to develop procedures that meet the requirements articulated below in the authorization policy.

Types of Authorizations
There are several types of authorizations to consider.

New User Privileges: When an account is created in the University’s central identity system, certain authorizations are immediately created with it, such as the ability to authenticate against our enterprise authentication systems, access to our network, and several online resources. Accounts are granted these authorizations automatically either implicitly or explicitly in the account creation process managed by IT and are sometimes related to the individual user’s affiliation with the University. For some types of guests, it may be possible to customize what these new user privileges are.

Application and System Administrators must not circumvent the authorizations contained within new user privileges by, for example, encouraging sharing accounts, creating proxy authentication services to enable users to make requests with the privileges of other users, or creating secondary authentication and authorization systems aimed at bypassing these controls.

System Level Authorizations: Once an account is created on a local system, the account is authorized to access the system and use software and services available to that system. In general, these authorizations are implicit in the creation of an account on the system rather than granted explicitly to the account once created. Some account types have special privileges associated, such as an “administrator”, “super user”, or “root” account that is responsible for administrative functions of the system including updating software and managing other accounts.

Application Level Authorizations: Similar to systems, accounts may have to be explicitly added to applications to enable access; a new user allocation may be insufficient for an individual’s job function and additional authorizations will have to be granted.

Privileged Authorizations: Certain authorizations grant access to administer a system or application and/or access to see data that is created or maintained by others. Privileged access is dependent on the specific person’s job duties, not the duties of the person’s organizational unit. Information Security is solely responsible for authorizing privileged access to IT servers and applications that process or store client data and any University system containing sensitive or confidential information.

Principles of Authorization

Least Privilege
An authorization should only provide the privileges required for the function to be performed and no more. Following this principle helps ensure proper workflows are followed and access to functions that may expose data is contained as much as possible.

Separation of Duties
When an authorization is granted to an account it must be approved by multiple individuals. Multiple approvers ensure that the Principle of Least Privilege is followed from both a technical and process perspective, decreases opportunity for conflict of interest or fraud, and reduces the risk of error. As applied to authorization, separation of duties requires that the administrative and technical approver are not the same person, or if they must be, then the Data Custodian is not filling either role.

Roles in Authorization
Authorizing an account to use a system or application is a distributed responsibility shared by Information Services & Technology, our IT partners, and sometimes external partners who might create authorizations at our direction.

Data Custodians
In general these authorizations are granted by “Data Custodians”, who are entrusted with the maintenance of the data. These are typically Systems Administrators, Database Administrators, or Application Administrators. See the Data Management Guide for details on this role.  These individuals are responsible for executing the approved account definition/modification/removal request, after validating that appropriate approvals have been granted.

Data Trustees
Data Trustees are leaders entrusted with the responsibility to ensure that University data is used appropriately by the institution.  Their full jobs are defined in the Data Management Guide.  Within authorization, they have a special role when approving access to data types that have an associated Trustee, also defined in the Data Management Guide

Administrative and Technical Approvers
All requests for authorization must be approved from a Data Trustee and technical approver (Data Custodian.) These approvers must be two different people to ensure separation of duties. These approvers are responsible for ensuring the Principle of Least Privilege is applied from their respective viewpoints.

Data Trustee Approval: The Data Trustee approval confirms that the authorization requested is needed to perform a required function. The approver should sufficiently understand the full scope of the authorization being granted before making a decision and ensure Least Privilege is applied.

Technical Approval (Data Custodian): The technical approval confirms that the privilege requested is required to achieve the approved administrative need. The approver should sufficiently understand the full scope of the authorization being granted before making a decision and ensure Least Privilege is applied.

Information Security
Information Security is solely responsible for authorizing privileged access to IT servers and applications that process or store client data and any University system containing PII or regulated information. Information Security will confirm that the user to be authorized has signed the appropriate confidentiality agreement(s), taken appropriate training, and/or holds appropriate credentials for accessing the resource.

Application and System Authorizations
Authorizing access may be automated based on a person’s membership in a specific group or a manual process. When authorizing a person to use an application or a system, a Data Custodian must adhere to the following authorization policy.

Authorization Policy
Before granting access to a system or application, the Data Custodian must ensure the following policy is adhered to:

1. Use role-based authorization schemes over individual authorizations whenever practical.
2. Be as granular as possible in your authorizations.
3. Ensure that the authorization has the appropriate approvals:
   1. Administrative and Technical Approvals are always required. These approvers must:
      1. Ensure the principles of Least Privilege and Separation of Duties are applied.
      2. When approving privileges to a shared account consider everyone who has access to that account and whether or not such privilege is appropriate for everyone.
   2. All requests for access to data for which there is a Data Trustee must be approved by the Data Trustee. See the Data Management Guide for more details.
   3. All requests for access to a system or application containing PII or confidential information have been approved by Information Security.
4. Privileged access may be granted permanently only if that specific person’s job duties routinely require that level of access, otherwise, the access must be temporary.
5. All authorization requests must be documented, including the nature of the request, the time period for which it has been granted, all related approvals that were obtained, and the names of the approvers.

Pre-authorized requests

As appropriate, the Data Custodian and Data Trustee may pre-approve authorizations for roles that always need such authorizations.

• Requests for authorization to access PII or confidential data may not be pre-approved.
• Pre-authorization for privileged account authorizations may be considered but are generally discouraged.

NOTE: Even where authorizations are pre-approved, a record of the request and approval process must be made and kept.

Deprovisioning

Systems and applications should be designed and deployed in a way that facilitates easy removal of a person’s authorizations and accounts at appropriate times.

Centrally Managed Accounts and Authorizations
The enterprise level accounts or authorizations that are listed in the enterprise directory service and have authentication credentials in our enterprise authentication services shall be deprovisioned in accordance with the policies of our Identity and Access Management service, adhering to the principles that:

• Individuals with no affiliation with the University should not have an account.
• Accounts for individuals with no lasting associations with the University, identified as affiliates within our IAM policies, should only exist for a limited period of time without reauthorization.

Non-Centrally Managed Accounts and Authorizations
When accounts or authorizations are created outside of the enterprise directory and/or enterprise authentication system, the unit creating the accounts must define a mechanism to deprovision the account in a timely fashion (generally within a few business days unless a specific timeframe is requested) and consistent with the conditions expressed for centrally managed accounts.

NOTE: It is insufficient to rely on the central deprovisioning of accounts as a method of terminating locally deployed authorizations, as the timeliness of the account deprovisioning is dependent on a number of factors that are beyond the control of the local systems and application administrators.

Auditing

Audit Trail
Data Custodians are responsible for ensuring that an audit trail of activity exists that includes the following:

• Ensuring that any account or authorization created, deleted, removed, or changed is audited in a system of record and available for review. This log would contain proof of approvals for the creation, deletion, removal, or change and the system and any system or application level log that the account or authorization was modified, if such can be logged. Or primary means of logging this information are through the ticketing system, any audit log records kept outside of this system must be approved by the manager or director of each IT sub department.
• Any system or application that authenticates or authorizes an account to take an action should log that activity to a standard location and format if possible. Any system containing data that is classified as sensitive or confidential requires auditing logs for accountability. The log should include both successful and failed authentications and authorizations.
• Ensuring that the system or application audit logs are properly configured and functioning normally over time.
• Conducting routine audits of account and authorization activity to ensure that only authorized use is occurring and maintain audit documentation accordingly. As part of this audit:
  • Provide a list of accounts with privileged access to the appropriate management approvers for review.
  • Support and encourage periodic review by Data Trustees for information covered under a Trustee’s responsibilities.

Account and Authorization Audits
Information Security and/or Internal Audit and Advisory Services may make routine or ad-hoc requests to audit the accounts and authorizations of any University information system along with the associated audit trail. These audits will ensure that accounts and authorizations are consistent with this document, including that:

There is a request for every account with elevated privilege, shared account, or service/process account;

• The request was approved both by an administrative and technical manager;
• The request is compliant with applicable regulation, policy, best practice;
• The granted privileges were indeed required for the approved administrative use;
• Requests for temporary privileges are expired on the agreed expiration date;
• Every account is held by a person still at the institution; and
• The account holder’s job function still requires the granted privilege.

Exceptions

Information Security is authorized to grant exceptions to the requirements set forth in this document. Any exception granted will require a thorough review of the situation and the implementation of appropriate compensating controls.

In addition, Information Security may publish directives aimed at clarifying the intent of a standard to aid in the interpretation of this policy.

Important

Failure to comply with the Data Protection Standards may result in harm to individuals, organizations or the University. The unauthorized or unacceptable use of University Data, including the failure to comply with these standards, constitutes a violation of University policy and may subject the User to revocation of the privilege to use University Data or Information Technology or disciplinary action, up to and including termination of employment.

Responsibilities:

Resources:

Digital Millennium Copyright Act Policy

Data Protection Standards policies

Policy Contacts:

Supplemental Information:

Original PDF: