• Section 1 - Introduction
• Section 2 - Scope
• Section 3 - Audience
• Section 4 - Requirements
• User Registration
• User Access Provisioning
• Privilege Management
• Review of User Access
• Removal or Adjustment of Access Rights
• Passwords
• Privileged Accounts
• Break-Glass Accounts
• Password Management Software

Section 1 - Introduction

(1) The University of Newcastle is committed to and is responsible for ensuring the confidentiality, integrity, and availability of the data and information stored on its systems.

(2) The purpose of this manual is to define the minimum standards required to ensure that user access is based upon authentication and authorisation, and that unauthorised access to systems and services is prevented.

(3) It is the responsibility of all Information Owners and System Owners to determine appropriate access controls, access rights and restrictions for their information and information systems. They must assure that access is provided only to authorised users and that unauthorised access is prevented.

(4) Furthermore, it is important for all University staff, students, affiliates, contractors, volunteers or visitors using University ICT resources to understand the need to ensure appropriate authorisation to any system or service provided by the University.

Section 2 - Scope

(5) The minimum standards outlined in this manual apply to all University ICT services and systems.

Section 3 - Audience

(6) These standards are primarily aimed at system administrators and technical staff, including Digital Technology Solutions staff, who are responsible for the management of access controls for University ICT services and systems.  This includes third parties supporting University of Newcastle IT systems.

Section 4 - Requirements

User Registration

(7) A formal user registration and de-registration process should be implemented to enable assignment of access rights.

(8) The following control objectives must be covered in the design of user registration procedures:

1. the allocation of unique user identities;
2. all University accounts must be accountable to an individual (e.g. no shared or generic accounts).
3. obtaining appropriate authorisation prior account creation;
   1. for students, authorisation is provided by the DVC(A) as part of the enrolment process.
   2. for staff, authorisation is provided by the hiring manager as part of the recruitment process.
   3. for affiliates, authorisation is provided by an authorised University staff member within the unit or school.
4. preserving segregation of duties;
5. user acknowledgement of the policy regarding acceptable use, outlined in the Information Technology Conditions of Use Policy;
6. no reissuing of user identities to new users.

(9) All third parties requiring access to University information assets must have an active University sponsor. All user accounts provided to third parties must include an expiration date no greater than one (1) year from the date the access is granted.

User Access Provisioning

(10) Access privileges are to be assigned through the use of the Role-Based Access Control (RBAC) model.

(11) RBAC is an access control mechanism that permits system administrators to allow or disallow other user’s access to objects under their control.

(12) The "role" in RBAC refers to a system of user roles, which are assigned to user groups and their users. Roles are assigned permissions, which define what a user can or can't do within a system or on an object. Roles can be particular to an application or may be defined more broadly as a job function or user type within the University, and may be a superset of more granular roles.

(13) Roles can be granted new permissions as new applications and systems are incorporated, and permissions can be revoked from roles as needed. This type of access simplifies management of privileges and permissions.

(14) The following RBAC implementation standards apply:

1. a user can only have access to an object (i.e dataset) based on an assigned role;
2. roles are to be defined based on a persona or job function.  A persona is a profile that can be used to describe a type of user, e.g. student, staff, Researcher, guest;
3. permissions are defined based on role’s authority, and responsibilities within a job function or of a persona;
4. operations on an object, such as view, edit or delete, are invoked based on permissions assigned to a role;
5. permissions configured on objects should only be based on roles, and not users;
6. roles are designed and implemented based on the principle of least privileged;
7. a role contains only the minimum amount of permissions required;
8. a user’s account is assigned to a role that allows him or her to perform only what is required for that role.

Privilege Management

(15) All access privileges will adhere to the following principles:

1. Need to know – the legitimate requirement of a person to know, access, or possess sensitive information that is critical to the performance of the authorised job function.
2. Least Privilege – every user and program must operate using the least set of privileges necessary to complete the authorised job function.
3. Segregation of duties – the practice of dividing the steps in a system function among different individuals, so as to keep a single individual from subverting the process.

(16) Need to know is enforced through the User Access Provisioning process.

(17) Least privilege and segregation of duties are achieved by:

1. limiting the role of system administrator to the fewest number of individuals necessary to achieve adequate service;
2. implementing fine grain access privileges for the performance of privilege tasks;
3. separating system administrator accounts from regular user accounts;
4. separating system administrator functions from audit and logging functions.  System administrators must not have the ability to modify or de-activate logs of their own activities.

(18) In addition to various regular end-user roles, programmers, developers and testers will have separate roles with different privileges to system administrator roles.

Review of User Access

(19) University information asset and IT asset owners must review user access rights on a regular basis to ensure that role changes, such as promotion, demotion, transfer, and termination are correctly reflected in all information systems under their management.

Removal or Adjustment of Access Rights

(20) The access rights of all users to information and information processing facilities shall be removed upon termination of employment, contract or association with the University, or adjusted upon change.

Passwords

(21) Username and passwords are used to facilitate authorised access to University information assets. These credentials are intended to protect data from unauthorised access and ensure that only authorised users have access.

(22) All initial system and application passwords must be issued by University staff through a secure means. Once a password has been issued, full responsibility for that account and associated password is transferred to the user. On first login all initial passwords will need to be changed, this will be an automated enforcement mechanism configured for all systems and applications to which users are being granted access.

Password Requirements

(23) All passwords, including initial passwords, must be constructed and implemented according to the following rules:

1. passwords must be at least 10 characters in length;
2. passwords must include at least one uppercase and one lowercase letter, one number, and one special character (i.e %,!,* or similar).  All American Standard Code for Information Interchange (ASCII) and Unicode characters should be made available for use in a password;
3. passwords must not contain any user identifier, student identifier, or any part of the user’s name;
4. passwords that are the same as the last 10 passwords that have been used must not be re-used;
5. passwords must not contain common or banned words, i.e. those known to be commonly-used, expected, or compromised, e.g.:
   1. passwords obtained from previous breach corpuses, i.e. passwords known to be compromised; or
   2. repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

Password Protection

(24) The following user account controls must be enforced for all systems:

1. account lockout threshold:  5 invalid logon attempts.
2. account lockout duration:  15 minutes.
3. reset count lockout counter after:  15 minutes.
4. minimum password age:  1 day.
5. if a staff account is not accessed for 365 consecutive days, the account should be disabled on the 366^th day.
6. users must be forced to change their password if their credentials are known or suspected to be compromised.
7. email alerts should be sent to users when a login is detected from a new device.

(25) In the event that a password has been shared with Digital Technology Solutions for troubleshooting scenarios, the password must be immediately changed after this work is complete.

(26) In the event that an account or password is suspected to have been compromised, the incident must be reported to the 17000 IT Service Desk and the password must be changed immediately.

Mobile Device Passwords

(27) All smart devices containing University data (including email) must be secured with either:

1. a 4-digit PIN; or
2. a Biometric lock with a compliant backup password/PIN.

Privileged Accounts

(28) The following clauses apply to all privileged accounts created for University owned or managed systems, including but not limited to:

1. Privileged Personal Accounts - privileged accounts assigned to individual users (typically University IT Support Staff). Examples include the following privileged groups: DBA, Server Administrator, Tenant Admin, Domain Admins.
2. Generic/Shared Administrative Accounts - privileged accounts that exist in virtually every device or software application.  These accounts hold “super user” privileges and are often shared among University IT Support staff. These accounts may be used by multiple users. Examples: Windows Administrator, UNIX root, Oracle SYS, SA.
3. Break Glass (Emergency) Accounts – break glass accounts are a type of Generic/Shared Administrative Account used by the University when elevated privileges are required for business continuity, disaster recovery, or to fix urgent problems.
4. Service Accounts – these are privileged accounts that provide a security context to a running service, daemon or process, such as a file server, web server, e-mail server, etc., or are used by applications to access databases and other applications.

(29) Privileged accounts provide a high degree of access to University ICT resources and therefore pose a significant risk if used in an unauthorised manner.

(30) As privileged accounts provide a significant level of control over University ICT resources, individuals with access to these accounts are expected to exercise a high degree of caution.

(31) All users with access to privileged accounts must maintain the confidentiality of any information that they have access to both during and after their employment with the University.

Privileged Account Password Requirements

(32) Privileged user access to any of the University's ICT domains, services and systems must be authenticated using multi-factor authentication (MFA) unless there is a system limitation that prevents its use. Privileged credentials must only be used when performing tasks that specifically require those privileges. While performing normal activities, administrators must use a separate, unprivileged account.

(33) All privileged account passwords, including initial passwords, must be constructed and implemented according to the following rules:

1. password length – the password must be at least 14 characters long;
2. password complexity – the password must include one uppercase and one lowercase character, one number and one special character (i.e %,!,* or similar);
3. password attributes – the password must not contain a user identifier or any part of the account owner’s name;
4. password history – passwords that are the same as the last 24 passwords that have been used must not be re-used;
5. password expiry – passwords must be changed immediately when a staff member who has accessed that password leaves their employment with the University;
6. minimum password age – 1 day;
7. account lockout threshold – 5 invalid logon attempts;
8. account lockout duration – 15 minutes;
9. reset account lockout counter after 15 minutes;
10. group or shared passwords are prohibited (unless an exception is approved).  The only exceptions to this are
    1. ‘break-glass’ accounts, which must not be used for day-to-day support;
    2. ‘test’ accounts, which may be shared during pre-production phases;
11. default passwords of any system, network resource, application or database etc., must be changed either during the installation process or immediately thereafter.

Break-Glass Accounts

(34) Passwords for break-glass accounts should be machine generated and held in the University's approved Privileged Account Management (PAM) platform to ensure they remain available to system administrators.

(35) A break-glass procedure defining the roles and responsibilities for use of break glass accounts should be created by each relevant System Owner or Information Owner.

(36) When a break-glass account is used, access to the privileged account must be:

1. limited to the minimum amount of time necessary;
2. associated to a change, problem or incident number/ticket;
3. recorded by the specific database, system or application; and
4. logged in an auditable record (which identifies the individual User who ‘broke the glass’), such as within the PAM platform, for later review.

(37) After a break-glass procedure has been completed, the password for the break glass account must be changed.

Password Expiry and Multi-Factor Authentication (MFA)

(38) If a Uni-ID or privileged account is protected with MFA, then there is no requirement to expire the associated password.

(39) If a Uni-ID or privileged account is not protected with MFA, then the requirement for password expiry will be based on the data classification that a Uni-ID is authorised to access based on the roles that it has been assigned:

Specialty Devices

(40) Due to the wide variety of specialty devices and their frequently limited capabilities, particularly with regard to password management, specialty devices such as fax machines, printers, physical access control equipment, copy machines, specialty lab equipment, phones, etc. are not subject to these requirements unless those devices are used to store or protect Highly-Restricted information or perform highly critical functions.

Service Account and Simple Network Management Protocol (SNMP) Community Name Requirements

(41) The password length and complexity requirements for service accounts and SNMP community names are increased to allow for less frequent expiration. This ensures that key services are not disrupted due to regular change.

(42) Service accounts must not be shared between applications or services, i.e. a separate account must be created for each application and service.

(43) Using a standard user account or Uni-ID to run system services is prohibited.

(44) End users and administrators are not permitted to remotely or interactively log in using service account credentials except as required to support or troubleshoot the specific service:

1. password and SNMP community name length – must be a minimum of 15 characters long;
2. password and SNMP community name complexity – must include at least one uppercase and one lowercase character, one number and one special character (i.e %,!,* or similar);
3. password and SNMP community name attributes – must not contain a user identifier or any part of a name;
4. password and SNMP community name reuse – must not be use passwords or community names that are identical or substantially similar to those that have been previously used;
5. password expiry – generally never, but the password must be changed when someone leaves the University who would know or had used the password.

Secure Shell (SSH) Keys

(45) SSH keys are a common way to connect to Unix\Linux based computers. Whilst they can provide a convenient and secure means of connection, the University does not currently have appropriate processes to ensure the security of their use across a user’s lifecycle at the University, e.g. SSH keys may not be reliably disabled when a user leaves the University.

(46) As such, the use of SSH keys for authentication is prohibited.

Password Management Software

(47) Passwords must not be written down or stored in clear text, although password management software may be used. Special care should be taken to secure the password tool, as it will grant access to all passwords.

(48) The password manager tool must employ encryption at AES256 or SHA2 or stronger. The password used to access this application must also be very strong and unique, and meet the requirements of a Service Account Password.

(49) Use of cloud-based password management tools is forbidden unless MFA is used.