• Section 1 - Executive Summary
• Section 2 - Purpose
• Section 3 - Scope
• Section 4 - Audience
• Section 5 - Requirements
• Types of Accounts
• Access Management
• Technical Controls
• Passphrases, Passcodes, and Multi-Factor Authentication
• Credential Protection
• Account Protection
• Break-Glass Accounts
• Database Access
• Simple Network Management Protocol (SNMP) Community Name Requirements
• Secure Shell (SSH) Keys
• Segregation of Duties
• Exemption for Specialty Devices

Section 1 - Executive Summary

(1) The University's ICT resources including software, hardware, data, and networks are used by staff, students, affiliates, vendors, and members of the public. 

(2) Access management ensures only those with a legitimate need can access our ICT resources. Access management also prevents unauthorised viewing, modification and deletion of data and systems. 

(3) Most staff and students are standard users of ICT resources, and their access is centrally managed. Some staff and students have privileged access, which allows them to perform actions that have a greater impact. Additional controls are required to protect privileged accounts from compromise. This document provides controls for managing both standard and privileged access.

(4) System Owners and Information Owners are responsible for determining access requirements for their ICT resources and for ensuring that access is managed throughout the life of the ICT Resource in accordance with this document.

Section 2 - Purpose

(5) This document provides the University's standard for access controls including account creation, authentication, authorisation, credential management, and monitoring. 

Section 3 - Scope

(6) This document applies to all ICT resources owned and/or managed by the University.

Section 4 - Audience

(7) The primary audience for this document is System Owners, Information Owners, System Administrators, technical staff, and any other staff responsible for managing access to ICT resources.

(8) All persons accessing University ICT resources should be aware of this document and implement the access controls for which they are responsible.

Section 5 - Requirements

Types of Accounts

(9) Table 1 describes account types and their use.

Access Management

(10) Clauses 11 to 17 outline the access management controls for access management that should be applied to all ICT resources.

(11) All decisions to grant, modify, or revoke a user’s access to ICT resources should be recorded in the IT service management (ITSM) tool that is available on the University intranet. 

(12) Access records should be retained for the life of the ICT Resource and in line with the Records Governance Policy to ensure access decisions can be traced.

(13) Approval must be sought prior to granting, modifying, or revoking access as follows:

1. for new students, approval must be sought from the Deputy Vice-Chancellor (Academic) and Vice President as part of the enrolment process; 
2. for new staff, approval must be sought from the Hiring Manager as part of the recruitment process; and
3. for affiliates, approval must be sought from the authorised University staff member within the business unit or School. Affiliates requiring access to University ICT resources must have an active University sponsor. 

(14) All users must acknowledge the University's Information Technology Conditions of Use Policy prior to being granted access.

(15) Access to ICT resources must:

1. be role-based. This means that users should only be given access to the ICT resources they require to fulfil their role; 
2. reflect the least privileges or permissions necessary to perform a role. Permissions may include the right to read, write, execute, or delete resources;
3. be based on a need-to-know. This includes access to data, information, and documents;
4. enforce the segregation of duties where there is a risk of fraud, errors, or conflicts of interest. Refer to Clause 78-79 for details; 
5. be regularly reviewed by Information Owners and/or System Owners in the following cycles to ensure only persons with legitimate access requirements retain access:
   1. standard user access must be reviewed at least every 12 months;
   2. privileged user access must be reviewed every 6 months. This includes generic, shared and root accounts; and
   3. segregation of duties must be reviewed at least every 12 months;
6. be revoked on the day they are no longer required. This applies to terminated employees, transfers to other areas, and changes to roles and responsibilities.

(16) If a staff account is not accessed for 365 consecutive days, the account should be disabled on the 366th day.

(17) All accounts provided to affiliates must include an expiration date that reflects the period of their relationship with the University.

Technical Controls

(18) Clauses 19 to 32 outline the technical controls that should be applied to all ICT resources.

(19) Access to all ICT resources must be attributable to an individual by assigning a unique identity.

(20) Unique identities cannot be reused.

(21) Users must be authenticated using multifactor authentication (MFA) prior to being granted access ICT resources. A Security Exemption must be sought via the ITSM tool for systems that do not require MFA.

(22) If MFA cannot be used, users must be authenticated by a long passphrase that the meets length and complexity requirements in Clause 45.

(23) Where systems cannot support MFA, passphrases must be changed at least once every 365 days. If passphrase expiration cannot be enforced by the system, users must manually change their passphrase using the University's passphrase reset procedure.

(24) Default, generic and shared accounts should not be used except for break-glass scenarios or cloud tenant administration.

(25) Default and generic accounts should be renamed and disabled/removed (except for break-glass and cloud tenant administration).   

(26) The use of generic and shared accounts for break-glass scenarios and cloud tenant administration, must be attributable to an individual.

(27) A separate privileged user account must be created for system administration.   

(28) Non-privileged activities must be performed using a standard user account.

(29) Standard user accounts must not be used to run system services.

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

(31) Standard users and administrators are not permitted to interactively log-in using service account credentials, except, as required to support or troubleshoot the specific service.  

(32) All access to ICT resources must be logged and sent to the Security Operations Centre (SOC) for monitoring and analysis. Digital Technology Solutions (DTS) should be engaged to facilitate the configuration and sending of logs to the SOC.

Passphrases, Passcodes, and Multi-Factor Authentication

(33) Passphrases must be issued using secure means.

(34) First-use passphrases must be randomly generated.

(35) Passphrases must be changed by a user upon first login.

(36) Default passphrases on all systems, network resources, applications and databases must be immediately changed to a unique passphrase.

(37) Unique passphrases must be used for each system.

(38) Passphrases must not be shared i.e., known to more than one individual. 

(39) User identities must be verified prior to resetting passphrases.

(40) The minimum age for passphrases should be 1 day or greater.

(41) Passphrases used for single-factor authentication must be a list of random words, with a minimum length of 14 characters.  

(42) Passphrases should not contain any identification information or be the same as the last 10 passphrases.

(43) MFA should require the use of a passphrase and a universal 2nd Factor security key, software based one-time passphrase token, physical one-time token, biometric authentication, or SMS.

(44) Passphrases implemented as part of MFA must be at least 10 characters in length.

(45) Passphrases for generic, default, shared, local administrator and service accounts must be at least 20 characters in length.

(46) Passcodes for mobile phones must be at least 4 digits, or a biometric authentication with a passcode as a backup if the biometric fails.

(47) Passphrases and passcodes must not be written down or stored in plain text.  

(48) If passphrase management software is used, the passphrase to access this software should be unique and meet the requirements of a local administrator/service account passphrase.

(49) Cloud-based passphrase management software should be used with MFA.

(50) If a passphrase has been shared with DTS for troubleshooting, the passphrase must be changed once the work is complete.

(51) If an account or passphrase is suspected to have been compromised, the incident must be reported to the 17000 IT Service Desk and the passphrase must be changed immediately.

Credential Protection

(52) Credentials (i.e., the combination of username and passphrase) must be kept separate from the systems that they are used to authenticate to.

(53) Credentials must be obscured as they are entered into systems to protect credentials from compromise.

(54) Credentials stored on systems must be protected by a passphrase manager, a hardware security module, or by adopting methods such as salting, hashing, and stretching them before storage.

(55) Windows Defender Credential Guard and Windows Defender Remote Credential Guard should be enabled where available to provide additional protection for credentials.

(56) Privileged user accounts in Windows should be placed in a Protected Users security group where available. This security group will apply non-configurable protections to privileged user’s credentials. 

(57) Service accounts for Windows servers should be created as group Managed Service Accounts. This feature provides automated credential management and ensures service account credentials are long, unique, unpredictable, and managed.

(58) Cached credentials should be limited to one previous logon to prevent the retrieval of cached credentials by an adversary.

Account Protection

(59) The following controls should be implemented for University accounts:

1. Account lockout threshold:  5 invalid logon attempts;
2. Account lockout duration:  15 minutes; and
3. Reset account lockout counter after:  15 minutes.

(60) Email alerts should be sent to users when a login is detected from a new device.

Break-Glass Accounts

(61) Passphrases for break-glass accounts should be machine-generated and held in the University's approved privileged access management (PAM) platform to ensure they are available to system administrators. DTS should be engaged for PAM use.

(62) A break-glass procedure must be created by the System Owner or Information Owner to define the roles, responsibilities, and process for using break glass accounts.

(63) If a break-glass account is used, access to the 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 used the account), such as within the PAM platform.

(64) Passwords for break-glass accounts  must be changed immediately after each time they are used.

Database Access

(65) User access, user queries, and user actions on databases should occur only through programmatic methods. Programmatic access refers to the use of a programming language to access a database, which provides more security than direct/manual access.  

(66) Only database administrators should be able to directly access or query databases.

(67) Application IDs for database applications should only be used by the applications (and not by individual users or other non-application processes).

Simple Network Management Protocol (SNMP) Community Name Requirements

(68) SNMP version 1 should not be used to monitor network devices as the protocol versions are insecure.

(69) Default SNMP community strings on network devices should be changed and write access disabled.

(70) SNMP community strings must meet the requirements of a local administrator/service account password. 

(71) SNMP community strings should be changed when someone leaves the University who would know or had used the password.

Secure Shell (SSH) Keys

(72) SSH version 1 should be disabled. Only SSH version 2 should be used.

(73) Public key-based authentication should be used for SSH connections.

(74) SSH private keys should be protected with a password or key encrypting key.

(75) When SSH-agent or similar key caching programs are used, the program should be limited to workstations and servers with screen locks and key caches should expire within 4 hours of inactivity.

(76) SSH daemon should be configured to:

1. only listen on the required interfaces;
2. have a login grace time of no more than 60 seconds;
3. host-based authentication should be disabled;
4. rhost-based authentication should be disabled;  
5. the ability to login directly as root should be disabled;
6. empty passphrases should be disabled;
7. connection forwarding should be disabled;
8. gateway ports should be disabled; and
9. X11 forwarding should be disabled.

(77) When using logins without a password for SSH connections, the following should be disabled:

1. access from IP addresses that do not require access;
2. port forwarding;
3. agent credential forwarding;
4. X11 display remoting; and
5. console access.

Segregation of Duties

(78) System Owners and Information Owners are responsible for defining segregation of duties requirements and regularly reviewing the implementation of those requirements. In general, a person should not be both the requestor and approver of an action; a person should not be able to ‘mark their own work’; and a person should not perform actions that may present conflict of interest or enable fraud, e.g., making payments and reconciling bank statements. Additionally, no one person should be able to initiate a transaction, request and approve a transaction, record a transaction, reconcile balances, handle assets and review reports.

(79) The following controls should be implemented to restrict administrative and privileged accounts:

1. limit the role of System Administrator to the fewest number of individuals necessary to achieve adequate service;
2. implement granular permissions for the performance of privileged tasks;
3. separate System Administrator accounts from regular user accounts;
4. separate 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.

Exemption for Specialty Devices

(80) Due to the wide variety of specialty devices and their frequently limited capabilities, particularly regarding passphrase 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 as defined by the University's Data Classification and Handling Policy and Standard or perform highly critical functions.