Applies to: (examples; Faculty,Staff, Students, etc)
Faculty , Staff , Students , Contractors_Vendors
Faculty , Staff , Students , Contractors_Vendors
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.
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.
This policy focuses on requirements for systems and applications. While it is important to consider encrypting or password-protecting individual files or documents, especially if the files may be sent electronically or stored on a portable device, the intent of the policy is not to set requirements for such individual files or documents.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:
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 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:
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:
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:
Pre-authorized requests
As appropriate, the Data Custodian and Data Trustee may pre-approve authorizations for roles that always need such authorizations.
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:
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:
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;
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.
Position/Office/Department | Responsibility |
All computer and infrastructure users | Abide by terms of Identity and Access Management Policy |
Information Security Team | Employees designated to manage breaches under the Security Incident Response Policy. |
Human Resources | Provide information to IT regarding new employees, job changes, departing employees. In addition, HR assists IT with data access clarification based on position and job duties. |
Digital Millennium Copyright Act Policy
Data Protection Standards policies
Name |
Contact Information |
Lewis, Zachary, AVP IT |
Zachary.Lewis@uhsp.edu, 314-446-8402 |
Knoll, Eric, Vice President Operations |
Eric.Knoll@uhsp.edu, 314-446-8375 |