[ top ]

Documented access policy

Access to telephone and computer services and associated data will be controlled on the basis of business requirements.

Service providers (both ITSS and external) are to be given a clear statement of the security requirements for system access in order to implement and maintain an effective level of control of access to information services and data.

The business owner/s of each application will maintain a clearly defined access policy statement, which defines the access rights of each user or group of users. The policy statement will define the following:

• The information security requirements of the application;
• Policies for information dissemination and entitlement, e.g. the 'need to know' principle;
• Security Classification (using the University Security Classification Labels standard) of the data held in or services provided by the application;
• Conformance to relevant legislation as well as any contractual obligations regarding protection of access to data or services;
• Standard user access profiles for common categories of job.
• A schedule of when access rights need to be reviewed.

[ top ]

2.0 Account management

User identifiers

This will ensure that a subsequent audit can take place to trace individual activities if needed.

There are four kinds of user ID in use at the University of Auckland:

Individual user ID.

Individual user IDs are the preferred method of providing access to the University network.

The fundamental concept of setting up unique user IDs is that responsibility for actions taken whilst connected to the University network can be attributed to individuals. Each user is accountable for their actions and can be audited by the systems to which they have access rights.  

A privileged account is a special case of an individual user ID that permits elevated access rights for specific systems or applications support and maintenance.

Individual users are responsible to ensure they adhere to the terms and conditions of use.

Application specific user ID;

An application specific user ID controls access to the separate applications available on the network. Access rights and privileges are programmed within the application code.

Guest ID;

A guest ID is associated with an account that does not have a specific, individual user ID but rather a more generic ID such as may be required when a contractor is to be given access.

Such accounts are generally intended for temporary use by an authorised visitor and must;

• be kept to a minimum
• have an owner responsible for their management and to ensure passwords are reset for each user
• have access limited to a list of application programs only and have, at most, restricted network access.

Group user ID (Group Account)

A Group Account is one that is set-up with a functional group or organisational identifier, i.e. a group of users use the same user ID and PIN and password to access a common application on a shared end user device or computer.

Group Accounts are strenuously discouraged and must be avoided whenever possible and, where in use, their phasing out must be prioritised for the earliest opportunity.

Group Accounts will be permitted under the following conditions:

• There is a demonstrable need to provide "group" access where the overhead of logging off and back on again is not acceptable.
• The number of applications accessible is kept to a minimum.
• Group Accounts are provided with the minimum access privileges required to meet business needs (for example, read/write access is not permitted where read only access will suffice).
• Group Accounts for super user or administrator accounts, to network attached computers, will not be permitted 
• Group Accounts will not be used to permit remote accesses
• Whenever possible, Group Accounts must be tied to specific physical client device(s)
• Group Account owners are responsible for their correct use at all times.

User IDs will not give any indication of the user's privilege level, e.g. manager, supervisor or status in the University (contractor, employee, etc.).

[ top ]

The University will move towards a model whereby all authorised users are allocated a unique and consistent ID across all authentication zones. This will allow the;

• consistent implementation of policy and standards
• automation of procedures for all users; e.g. creation, allocation and deletion of user IDs and user accounts
• improved ease of access for users

In all cases, before accounts are activated;

• for employees: the appropriate user account request form must be correctly completed and authorised by the information system owner
• for students: the appropriate verification of student status has been formally completed by Student Administration.

[ top ]

2.3 All users must have an individual user ID with an associated PIN or password.

An account and password pair can be likened to a key set issued to an individual. These are signed out for their use to access various parts of the institution and for no other purpose. Users do not get copies cut (i.e. replicate their credentials somewhere un-trusted), leave their keys where they can be easily stolen or loan them to any other person. Furthermore, these keys remain the property of the University.

The sharing of individual PIN and passwords is not permitted for any reason. User IDs should also be treated as confidential and only revealed, upon request, to authorised individuals; e.g. system administrators or helpdesk personnel trying to resolve a support issue.

Individual users (including contractors and Partners) are responsible for the use of their own PIN numbers, user accounts and passwords from the date of the start or renewal of their contracts.

[ top ]

2.4 User accounts will not be activated until the authorisation process and subsequent audit trail is correctly completed.

New users must not be able to access systems until all of the activities relating to their access are completed; e.g. signed approvals, completion of an employment contract.

HR, information system owners and ITSS must have appropriate processes in place to ensure this policy is complied with.

[ top ]

2.5 Formal procedures will control allocation and removal of user accounts.

These controls ensure that only authorised individuals access the University information resources and that the privileges they have are defined and enforceable.

These procedures cover all stages of user access, from initial registration of new users to final de-registration of users who no longer require access to information resources.

•  A new user is not permitted, under any circumstances, to inherit the user ID of the person they have replaced
•  HR must inform information system owners and ITSS immediately upon the permanent departure of a staff member (such as resignation or death). Whenever circumstances permit, this same requirement also applies to the temporary departure of an employee for longer than two months (such as extended leave or absence of a contractor or consultant).

System administrators must immediately disable all such user ID accounts.

• Information system owners will review the access rights of user ID accounts on formal notification of re-deployment (e.g. promotion or transfer) of a staff member.
• System administrators will:

• Ensure that redundant or disabled user IDs are not re-issued to another user within three months;
• Maintain a formal record of all persons registered to use a service;
• Disable accounts that have been inactive for 60 days (employees) or 90 days (students) after consultation with appropriate managers.
• Check the status of accounts, and remove redundant user accounts that are no longer required (or which have not been used for 120 days or more and for which the owner cannot be identified) after consultation with appropriate managers.
• Disable unused telephone extensions, after discussion with the line manager to whom they belong.

• Line management will ensure that appropriate exit procedures are carried out with outgoing staff members or contractors before departure, including;

• Staff data files are to be properly accounted for and handed over to that person’s immediate manager for subsequent distribution to succeeding staff;
• A thorough house keeping takes place of outgoing staff members or contractors data before they depart;
•  The Help Desk is informed of their departure and requested to disable or delete all associated accounts.

[ top ]

2.6 Users must not be able to break out of their environment and access either local or server-based system files.

Users must not be able to use the escape, control D, control C, control Alt Del or other similar keys to exit applications and gain access to a system prompt.

All users must be forced to use the correct business applications log on/off processes.

[ top ]

Review of user access rights

2.7 User access rights will be reviewed regularly and if requested by a system owner.

Systems administrators will;

• Conduct a formal review of users' access rights when requested.
• Review authorisations for special privileged access rights at more frequent intervals to ensure that unauthorised privileges have not been obtained;
• Ensure that staff privileges keep pace with the information security levels required by their job function.

[ top ]

Additional access control

2.8 Areas of the University network classified CONFIDENTIAL or higher by business owners may require additional protection.

Sensitive areas such as secure pages on web servers, partitions on hosts or servers or even, under some circumstances, entire systems may require further user identification and/or authentication. This may occur during any active session when users attempt to access areas or data classified as CONFIDENTIAL or higher by business owners.

These areas will be secured by a combination of either user ID and PIN or password and role-based access controls to protect them from access by the general user population or public. The use of strong authentication techniques (e.g. two-factor authentication systems such as SecurID) should be considered.

[ top ]

Privilege management

2.9 Privileged access to information systems must be strictly controlled and logged.

The unnecessary allocation and use of system privileges significantly increases the vulnerability of systems.

The allocation of privileges must be controlled through a formal authorisation process.

• Privileged accounts (super users on UNIX, routers and LAN servers, SANs, etc) must only be used when necessary, and not for normal day-to-day operation;
• Where technically possible, users must initially log on with a personal user ID and only be granted privileged access by way of group assignment;
• Privileged and guest accounts must be renamed from any default whenever possible;

The use of telephone privileges (e.g. toll and international calling) for other than business use is only permitted with prior line management approval. Staff members who are allocated a telephone with toll and other privileges must ensure that these are not abused.

Users should not permit the unauthorised use of any telephone in their care. If necessary, staff can request a PIN number if their telephone is at risk of abuse.

[ top ]

2.10 PINs or passwords for emergency privileges must be lodged in a safe and secure location and accessed only in accordance with authorised procedures.

The use of emergency privileged accounts, set up in advance for emergency access, must be controlled; e.g. store super user IDs in a sealed envelope in a secure location such as a safe, together with a list of people permitted access in an emergency. The sealed envelope should contain details of the systems administrator to be contacted if used. This will ensure that a new sealed envelope with privileged account information is provided.

PABX administrator PIN or passwords are likewise to be stored in a secure location and only used when appropriate.

Any actions taken during an emergency must be accurately recorded.

[ top ]

2.11 Privileges must only be granted on the basis of business requirements to access a system, e.g. operating system, database management system.

Privileges will only be allocated on a role-based model and as required, i.e. the minimum requirement for their functional role and only when needed.

Users must not be able copy, read, update or delete infrastructure software or to execute system software which they are not authorised to run on server or client computers.

System administrators and other technical staff, contractors and partners, who install and upgrade system infrastructure software, are the only exceptions.

[ top ]

2.12 Group user accounts must have an owner who is responsible for their use.

The account owner will maintain a complete list of all staff that use group user accounts.

Telephones available for group use will not be provided with access to special privileges, i.e. international tolls.

[ top ]

  2.13 System routines should be developed to avoid the need to grant special privileges to users.

The development of scripts or routines will also avoid possible syntax errors inherent in regular manual input of command line entries.

[ top ]

2.14 Users assigned privileges for special purposes must use a different user ID for normal business use.

A user assigned privileged access; e.g. the role of backup operator, must only use the backup operator user ID when carrying out that specific task. At all other times, users are to log on using their own user ID.

[ top ]

3.0 Password management

Allocation

3.1 The allocation of user IDs, PINs and passwords must be strictly controlled.

User IDs and passwords or PINs are required as the principal means of validating a user's authority to access information services.

The Policy requires:

• mandatory use of a PIN or user ID and password;
• only the Help Desk or information system owner is permitted to allocate initial PINs or passwords to a user, who will be required to change it on first use before access to systems will be granted;
• when new accounts are created, the system administrator must assign a unique password that is not known to anyone else (and especially not a 'standard' password) and conforms to the University minimum standard;
• PIN or passwords are conveyed to users in a secure manner; e.g. conveyance of PIN and passwords through third parties or through unprotected (clear text) electronic mail messages is not permitted.
• Delivery of a password or PIN verbally on the phone is acceptable as long as;
  
  • it is only carried out by authorised persons who must ensure that they can not be overheard
  • that they verify the user is who they say they are; e.g. through an agreed set of Q&A
    
• users must acknowledge receipt of PIN or passwords.

[ top ]

Storage and transmission

3.2 PIN and passwords are automatically classified as CONFIDENTIAL and must be protected appropriately.

If passwords or PINs are stored on hosts, they will be encrypted. Under no circumstances are PIN and password information to be stored in clear text on hosts, even if they do not relate to the host on which they are stored.

Passwords or PINs must be encrypted during transmission.

The recommended level of protection is to use a one-way encryption algorithm.

Clear text PIN or passwords must never be embedded into application or user files, end user device emulator or file transfer set-ups, etc unless on a computer stored or operated in a proven secure area.

PIN or password files must be stored separately from the main application system data.

[ top ]

Management system

  3.3 An effective password management system will be used.

The University of Auckland PIN or password management system will:

• Enforce the use of individual PIN or passwords to maintain accountability;
• Require users to select and change their own PIN or password and include a confirmation procedure to allow for typing errors;
• Ensure passwords conform to the University minimum standard by exposing them to a utility such as "crack" or similar;
• Enforce individual PIN or password changes every twelve months or at earlier intervals whenever;

• an audit identifies that a PIN or password has been used which does not conform to the standard; or
• system tools compromise a PIN or password, or
• a user suspects that their PIN or password has been compromised; or
•  the system owner has specified more frequent password changes due to the sensitivity of the system or information being accessed (see 1.1)

• Enforce Group Account PIN or password changes for network connected systems (and standalone systems providing access to information classified as Confidential or higher) at intervals of 60 days or whenever personnel changes occur;
• Enforce PIN or password changes for privileged accounts, e.g. those with access to system utilities, every 60 days;
• Maintain a record of previous user PIN (if possible on telephone systems) or passwords, e.g. for the previous 12 months, and prevent users from reusing them;
• Not display PIN or passwords on the screen when being entered;
• Prevent new staff from inheriting PIN or user IDs and passwords from their predecessors;
• Permit students to reset passwords via a web page that verifies their identity by asking questions about their University enrolment;
• Only allow student password resets by members of an authorized UDS group.  Anyone who is not a member of this group will not be allowed to reset passwords.  Additions and deletions of staff to or from this group will be logged;
• Ensure that students appearing in person (e.g. at a Help Desk) will be required to identify themselves to the staff member by presenting a current University of Auckland ID card.  The staff member will check that the card is current, and that the student matches the photograph.
• Log password reset requests, keeping details including the NetID (for which the password was reset), the name of the resetting staff member and the time the reset was initiated.
• Ensure that reset passwords comply with the University minimum standard.  If the reset request was anonymous; i.e. the administrator did not see the new password, and the new password was delivered via secure means (e.g. an SSL web stream), it can be used as the user's new password.  Otherwise, the user must be forced to change this password the next time they log in.
• Permit routine PIN and password changes to be made only by the user;  
• Ensure PIN and passwords reuse is not permitted within 12 months or 12 iterations;
• Alter default vendor PIN or passwords (and IDs if possible) following installation of software.
• Disable user access of all permanent staff, contractors or consultants immediately they leave.
• Keep telephone PIN numbers as secure as possible using tools available on the management system.
  

[ top ]

Password User Responsibilities

  3.4 Users must follow good practice when managing their user IDs, PINs or passwords.

Good end user practices in the selection and use of PIN and passwords are essential.

All users are required to adopt the following practises when setting and managing their PIN and passwords:

• Select PINs and passwords that conform to the University minimum standard. Don't use a weak password just because it's easier to remember. 
• Only reveal your user ID if requested by an authorised person; e.g. system administrators or helpdesk personnel trying to resolve a support issue.
• Keep all PIN and passwords confidential;
• Don't give your password to ANYONE. Don't give it to your manager, your spouse, your friend, the VC, your mother, or any other authority! 
• Don't write down your user ID or password: remember it. It's better to have your password reset because you forgot it than to have it stolen 

(NOTE: An exception to this applies to emergency user IDs and Passwords – see 2.10)

• Change PIN and passwords whenever there is any indication of possible system or PIN or password compromise;
• Change PIN or passwords for privileged accounts, e.g. those that access system utilities, every 60 days;
• Change initial PIN or passwords at the first logon;
• Do not include PIN or passwords in any automated logon process, e.g. stored in a macro or function key.
• You are responsible for ANY activity using your account user ID and password. 
• Don't let anyone observe you entering your password. Cover your keyboard when logging in if someone is watching you, or ask them to turn away. 
• If your password has been changed or reset and you didn't request it or change it, please let the Helpdesk (x 85100) know.

It is the business owners responsibility to ensure that all users have been instructed in the selection of secure PIN or passwords and their use.

[ top ]

4.0 Monitoring system use

   4.1 All systems will be regularly monitored to ensure compliance to this Policy.

System administrators must comply with this Policy in respect to the systems for which they are responsible. Log files are to be:

• Created automatically wherever possible;
• Reviewed for performance or security exceptions by system administrators on a regular, documented schedule.

Monitoring is necessary to ensure that only authorised processes are being performed. The level of monitoring required will depend upon the individual facility in question.

Monitoring may provide:

• Fully maintained audit log recording the user ID, origin, log on and log off times, destination and source extension for every session. This information should be recorded for all end user devices sessions and network connections.
• Notification of every instance of user ID account lockout due to a failure to successfully log on or obtain a dial-tone as a result of either incorrect PIN or password and/or user ID;
• Tracking of allocation and use of accounts with a privileged access capability;
• A log of accesses to, or use of, University network resources;
• A log of server processes which accept user ID-protected connections (e.g. mail servers, FTP servers) must record the details of those connections in the audit log;
• A means of detecting unauthorised use of system utilities or applications (such as FTP, telnet, and ping) or the use of tools such as SATAN or CRACK. Only a minimum of clearly specified hosts is permitted to execute these utilities and programmes.
• Logon patterns for indications of abnormal use or revived user IDs and passwords or PINs.

All monitoring activities will be formally authorised by management.

[ top ]

University minimum password standard

Passphrase

The existing password standard (below) remains but recent research suggests that a valid alternative is to use a "passphrase" where length rather than complexity provides the required level of security. It has also been demonstrated that users may be able to remember a passphrase more easily that a complex password as they are able to select a phrase that is easy for them to remember.

For users wishing to use passphrases the following minimum standard applies.

• Use a minimum of fourteen characters and at least one character from the following three classes:

• English upper case letters
• English lower case letters
• Non-alphanumeric (special) characters such as punctuation symbols.

Examples of passphrases that meet the standard are;

She loves you Yeh! Yeh! Yeh!
I make BLUE guitars in my spare time!
I love to eat Big Mac's
Where have all the flowers gone?

Password

The following minimum standard for password creation applies to users of University information systems.

• Use a minimum of eight characters and at least one character from three of the following four classes:

• English upper case letters
• English lower case letters
• Numerals (0,1,2,...)
• Non-alphanumeric (special) characters such as punctuation symbols.

• Very important passwords (e.g. password for any privileged or administrative account) should be at least 10 characters long;
• Do not base PIN or passwords on any of the following details:

• Months of the year, days of the week or any other aspect of the calendar;
• Family names, initials or car registration numbers;
• A proper name or any word in the dictionary without altering it in some way;
• Can be derived from a dictionary word, e.g. by reversing letters;
• Department or faculty names, identifiers or references;
• Telephone numbers or similar all numeric groups;
• User ID, user name, group ID or other system identifier;
• More than two consecutive identical characters;
• All-numeric or all-alphabetic groups;
• Obvious phrases or sequences such as "OTTFFSSE" or "12345";

• Don't reuse a password: construct a new password each time it is changed. 

The following strategies will help users to generate a password that is easy to remember, is hard to guess and complies with the University policy.

• Use a mixture of upper and lower case and punctuation e.g. KeepOut!
• String several words or parts of words together e.g. it’sCold
• Choose a phrase, perhaps a line from a poem or song and form passwords by concatenating words from the phrase along with digits and/or punctuation. e.g.  Tw1nLit*  (from twinkle, twinkle, little star), Yat550ml (from you are the sunshine of my love)
• Invent phrases like car registration plates e.g. one4you!

[ top ]

Version history

[ top ]