• Section 1 - Purpose
• Document context
• Section 2 - Procedure
• Part A - Principles
• Part B - Organisation of information security
• Information security roles and responsibilities
• Segregation of duties
• Regulatory authorities
• Contact with special interest groups
• Information security in project management
• Part C - Human resource security
• Employment and contractor practices
• Management responsibilities
• Information security awareness, education and training
• Termination and change of employment
• Part D - Asset management
• Responsibility for ICT assets
• Asset registers
• Asset Custodianship
• Acceptable use of assets
• Return of assets
• Removal and secure disposal or reuse of equipment
• Information security classification
• Media handling
• Disposing of media
• Part E - Access control
• Business requirements of access control
• Access control
• Providing user access
• User access de-registration
• User account inactivity and dormancy management 
• Remote work
• Vendor remote access
• Review of user access rights
• System and application access control
• Access control considerations for new services
• Privileged access rights
• Use of secret authentication information (passwords)
• System and application access control
• Information access restriction
• Secure logon
• Password management system
• Use of privileged utility programs
• Access control to program source code
• Mobile devices
• Part F - Cryptography
• Cryptographic controls
• Key management
• Part G - Physical and environmental security
• Secure areas
• Physical security perimeter
• Physical entry controls
• Securing sensitive offices, rooms and facilities
• Protecting against external and environmental threats
• Working in secure areas
• Delivery and loading areas
• Information and communication technology (ICT) equipment
• Equipment location and protection
• Supporting utilities
• Cabling security
• Equipment maintenance
• Unattended user equipment
• Clear desk
• Part H - Operations security
• Operational procedures and responsibilities
• Documented operating procedures
• Change management
• Capacity management
• Separation of development, testing and operational environments
• Protection from malware
• Backup
• Logging and monitoring
• Event logging
• Protection of log information
• Administrator and operator logs
• Clock synchronisation
• Control of operational software
• Installation of software on operational systems
• Technical vulnerability management
• Restrictions on software installation
• Information systems audit controls
• Part I - Communications security
• Network security management
• Security of network services
• Segregation in networks
• Information transfer
• Information transfer policies and procedures
• Agreements on information transfer
• Electronic messaging
• Confidentiality or non-disclosure agreements
• Part J - System acquisition, development, and maintenance
• Security requirements of information systems
• Artificial intelligence services
• Securing application services on public networks
• Protecting application services transactions
• Security in development and support processes
• System change control procedures
• Technical review of applications after operating platform changes
• Restrictions on changes to software packages
• Secure system engineering principles
• Virtualisation
• Secure development environment
• Outsourced development
• System security testing
• System acceptance testing
• Test data
• Part K - Supplier and cloud service provider relationships
• Information security procedures for supplier relationships
• Addressing security within agreements
• Supplier service delivery management
• Part L - Information security incident management
• Management of information security incidents and improvements
• Responsibilities and procedures
• Reporting information security events
• Reporting information security weaknesses
• Assessment of and decision on information security events
• Response to information security incidents
• Learning from information security incidents
• Collection of evidence
• Part M - Information security and business continuity management
• Information systems continuity
• Planning information systems continuity
• Implementing information security continuity
• Verify, review and evaluate information security continuity
• Redundancies
• Availability of information processing facilities
• Part N - Compliance
• Compliance with legal and contractual requirements
• Intellectual property rights
• Protection of records
• Information security reviews
• Independent review of information security
• Compliance with security policies and standards
• Technical compliance review
• Information security management system (ISMS) performance monitoring process
• Benchmarking
• Section 3 - Glossary

Section 1 - Purpose

(1) This guideline supports the Information Technology Policy and procedures by guiding the University's information security practices regarding the confidentiality, integrity, and availability of all information and communication technology (ICT) infrastructure, systems and processes. It aims to:

1. establish appropriate standards, processes, procedures, and guidelines to support the University’s information security requirements
2. define the University's information security procedure statements and control objectives
3. establish minimum requirements for information security, using a risk-based approach
4. provide clear advice for authorised users about protecting information assets from inappropriate use, modification, loss or disclosure, and foreign interference
5. help identify, assess and manage areas of non-compliance and manage risks to the University's information assets
6. promote and support the adherence to legislation, regulation and industry standards and guidelines including:
   1. NSW Cyber Security Policy
   2. Australian Government Information Security Manual (ISM)
   3. Centre for Internet Security (CIS) Critical Security Controls
   4. International Organisation for Standardisation (ISO)27000 Series
   5. National Institute of Standards and Technology's Cyber Security Framework (NIST CSF)
   6. Guidelines to Counter Foreign Interference in the Australian University Sector

Document context

Section 2 - Procedure

Part A - Principles

(2) The following principles underpin and inform the implementation of these guidelines:

1. Computing and information systems underpin the University's activities and are essential to the teaching, learning, research and administration functions of Charles Sturt University (the University).
2. The University is a critical education asset under the Security of Critical Infrastructure Act 2018 and subject to mandatory reporting under that Act.
3. The University acknowledges the requirement to manage cyber risk arising from criminal activities, internal threats, and local and foreign interference.
4. Appropriate security standards and measures must be established, implemented, monitored, reviewed and improved as required, to ensure that the University's Information Security Management System (ISMS) documentation framework and business objectives are met, and that appropriate security measures are:
   1. in place or planned
   2. supported by industry guidelines, standards, processes, and procedures to ensure compliance.

Part B - Organisation of information security

(3) This part describes the University’s information security management framework.

Information security roles and responsibilities

(4) Information security responsibilities are defined and allocated in accordance with the Information Technology Policy. 

(5) The Chief Information and Digital Officer has overall responsibility for information security within the University. Further details about what this responsibility involves, and the role of Division of Information Technology (DIT) staff, are provided in Appendix B - Risk Management.

(6) System and asset custodians have responsibilities for the protecting individual assets and for carrying out specific information security processes. Responsibilities for information security risk management activities and acceptance of residual risk are as per the Risk Management Policy and procedures.

Segregation of duties

(7) Roles and areas of responsibility are segregated to reduce the risk of unauthorised or inappropriate activity.

1. No individual should have end to end control over critical processes or information.
2. Where full segregation of duties cannot be achieved due to operational or system constraints, appropriate compensating controls must be implemented, such as independent review, monitoring or approval processes. These processes shoud be documented and periodically reviewed.  

Regulatory authorities

(8) The University aims to comply with the NSW Cyber Security Policy.

(9) The University complies with:

1. the Notifiable Data Breaches scheme as per the Information Technology Procedure - Personal Data Breach.
2. the registration, reporting and operational requirements of the Security of Critical Infrastructure Act 2018.

Contact with special interest groups

(10) The DIT ICT Security Team engage with special interest groups, specialist security forums and professional associations including:

1. AusCERT (Australian Cyber Emergency Response Team)
2. Council of Australasian University Directors of Information and Technology (CAUDIT)
3. Australia's Academic and Research Network (AARNet)
4. Australian Cyber Security Centre (ACSC)

Information security in project management

(11) Information security must be integrated into the University's project management methods to ensure that information security risks are identified and addressed throughout all stages of a project. Refer to the DIT Project Security Considerations Guide.

Part C - Human resource security

(12) This part guides how University staff and other authorised users should be supported to ensure they understand and comply with their ICT security responsibilities.

Employment and contractor practices

(13) All employees and authorised users undertaking work for the University must handle the University's information in accordance with the Code of Conduct and/or the terms of the relevant contract or agreement.

(14) Where appropriate to the nature of the role:

1. Information security responsibilities must be addressed prior to, or on commencement of, employment through adequate job descriptions and in the terms and conditions of employment.
2. ICT security responsibilities should be added to job descriptions for management position responsibilities where relevant. 
3. Background verification checks must be carried out on all candidates for employment, including contractors, volunteers and third-party users, proportional to business requirements, the classification of the information to be accessed, and the perceived risks.
4. Screeing of potential and current employees will be in accordance with the Employment Screening Procedure 
5. Screening procedures must also be carried out for agents, contractors, volunteers, and third-party users where appropriate.
6. Where contractors are provided through a recruitment agency, the contract with the recruitment agency must clearly specify the agency’s responsibilities for candidate screening, notwithstanding the notification procedures to be followed if screening has not been completed, or if results give cause for doubt or concern. In the same way, the agreement with the third party must clearly specify all responsibilities and notification procedures for screening.
7. Contractors, volunteers, and other authorised third-party users must sign a contractual agreement or an equivalent privacy and security agreement. The agreement must state the individual and University responsibilities for information security. See also the Finance Procedure - Contractors and Consultants.
8. The terms and conditions of employment or engagement must reflect the requirement to comply with all University policies and procedures.
9. Individuals engaged via a third-party organisation must comply with the University’s information security requirements, and must agree to this before being granted access to the University's ICT systems. Confidentiality agreements with the individuals may only be omitted if an existing contract with the third-party specifies appropriate confidentiality requirements.

(15) During the employment or engagement with the University, authorised users must be aware of:

1. information security threats and concerns
2. their responsibilities and liabilities defined in employment or contractual agreements.

(16) Awareness, education, and training in security procedures and the correct use of information processing facilities will be provided to all authorised users to minimise possible information security risks.

Management responsibilities

(17) Management responsibilities defined in position descriptions include responsibility for the security of information assets that the relevant organisational unit owns or uses. This includes ensuring that authorised users:

1. are adequately briefed on their information security roles and responsibilities prior to being granted access to sensitive information or information systems
2. are provided with guidelines that state information security expectations of their role within the University
3. achieve a level of awareness on information security relevant to their roles and responsibilities within the University
4. conform to the terms and conditions of their employment
5. are issued with the appropriate access rights to the University’s information assets and facilities.

(18) Access rights must be reviewed by system custodians  to ensure that permissions remain appropriate to an infividual’s role and responsibilities. Reviews must be conducted in accordance with the University's defined access review requirements.

Information security awareness, education and training

(19) All authorised users must undertake mandatory ICT security training in accordance with the Information Technology Procedure - Acceptable Use and Access. For employees, training in information security awareness, obligations and disciplinary processes is undertaken during induction and annually thereafter

(20) Where appropriate to the nature of the role and work done, system and asset custodians should ensure:

1. Formal information security awareness programs are implemented to provide authorised users awareness around the importance of information security, cardholder data security and privacy.
2. Users are educated on information security problems and incidents and how to respond to problems and incidents according to the needs of their work role.
3. Multiple methods of communication (e.g. posters, emails, memos, web-based training, meetings and promotions) are used to educate authorised users.
4. Information security awareness, education and training activities:
   1. are suitable and relevant to the authorised user’s roles, responsibilities, and skills
   2. include information on known threats
   3. provide contact details for further information and security advice
   4. list the proper channels for reporting information security incidents.

Termination and change of employment

(21) Managers must ensure that when authorised users depart the University or change roles, the user’s exit or change is managed and that all equipment and information assets assets are returned, and access rights are removed.

(22) Where appropriate, the departing authorised user will be reminded of continuing nondisclosure obligations after leaving.

(23) The communication of exit or role change responsibilities should include:

1. ongoing information security requirements and legal responsibilities
2. responsibilities contained within any confidentiality agreement and continuing these for a defined period after the end of the employee’s, contractor’s, and/or third-party user’s assignment.

Part D - Asset management

(24) This part supports the integrity of the University's information assets, to ensure that data confidentiality is maintained when equipment or services are established, replaced, decommissioned or serviced, or in relation to storage media handling, control and disposal.

Responsibility for ICT assets

Asset registers

(25) Business critical ICT assets must be identified and maintained in the appropriate asset register – Applications Portfolio, Data Assets Register or Infrastructure Assets Register.

Asset Custodianship

(26) Asset custodians must be assigned for all ICt assets and be recorded within the respective asset register.

(27) Asset custodians are required to:

1. determine appropriate classification levels for their information assets (as per the Information Classification and Handling Procedure) and make decisions about authorised users permitted to access and use the information
2. work with DIT to implement appropriate risk management processes
3. maintain asset registers and specific security control procedures (e.g. access control)
4. implement and maintain effective control measures
5. provide appropriate recovery capabilities consistent with the Information Technology Procedure – Disaster Recovery.

Acceptable use of assets

(28) The Information Technology Procedure - Acceptable Use and Access defines:

1. appropriate use of computing and communications resources
2. information stored on or transmitted via the University's computers, networks, telephones and/or other communications devices.

Return of assets

(29) All authorised users must return all University assets in their possession upon termination of their employment, contract or agreement. The termination process should be formalised in accordance with Part C and should include the return of all previously issued software, corporate documents and ICT equipment. This includes:

1. mobile computing devices
2. keys
3. access cards
4. software
5. manuals
6. all University-owned information stored on electronic media.

(30) In cases where an authorised user has university operational knowledge, that information should be documented and transferred to the University. Where the authorised user plays a role in information security plans (e.g. incident response procedure or contingency plan), respective plans must be updated accordingly.

Removal and secure disposal or reuse of equipment

(31) Sensitive information must be removed from any information system equipment that has been used for University business prior to its disposal, donation or re-use.

(32) Disposal of equipment should be undertaken as per the Information Technology Procedure – Purchasing and Disposal.

Information security classification

(33) The Information Classification and Handling Procedure requires information assets to be protectively marked into one of four classifications. The way the data is handled, published, moved and stored will be dependent on this scheme. See also the Data Access Form.

Media handling

(34) The use of removable media, including USB storage devices, must be restricted to minimise the risk of data loss, unauthorised access or malware introduction:

1. Removable media must not be used unless there is a defined business requirement, and must be conducted in accordance with approved processes and controls. 
2. Individuals must take appropriate steps to ensure the security of any computer media removed from the University. All media must be stored in a safe and secure environmentin accordance with the classification of the data stored on the media.
3. Remote users who may or may not have direct access to the University network must ensure that data, which is backed up to removable media, uses strong encryption methods and is stored in a secure manner.

(35) Data stored on removeable media must be classified by the relevant data or business custodian, in accordance with the  Information Classification and Handling Procedure.

Disposing of media

(36) All computer media must be disposed of securely and safely when no longer required. Refer to the Information Technology Procedure - Purchasing and Disposal.

(37) University information must only be disposed of when its retention requirements have been  met, in accordance with the Records Management Policy and Records Management Procedure. 

(38) Physical media containing data that is no longer required must be either:

1. physically destroyed using the secure University disposal service
2. degaussed (decreasing or eliminating a remnant magnetic field)
3. rendered irretrievable using secure sanitisation software.

(39) For hard-copy materials, acceptable methods of disposal include shredding, incineration, and pulping.

Part E - Access control

(40) This part details access control requirements for information and/or information processing facilities.

Business requirements of access control

Access control

(41) Business requirements for access control must be defined and documented:

1. Access to system components and/or sensitive information must be restricted to individuals whose job requires such access.
2. All authorised users that are provided access should be given a clear statement of the business requirements which must be met by the access controls.
3. Access to privileged accounts must be restricted to the least privilege level necessary to perform job responsibilities.
4. Assignment of privileges must always be based on each individual’s job classification and function. Levels of privileges required for each role (e.g. user, administrator) for accessing resources must be defined.
5. System custodian approval is required for all access, and should be documented and specify the required privileges.
6. Wherever possible, access controls should be implemented via automated access control systems (e.g. Identity and Access Management systems) with access control roles (e.g. access request, access authorisation, access administration) implemented, with appropriate separation of duties.

(42) Authorised users are provided with a unique user ID and a password for access to any aspect of the University's ICT systems.

(43) Shared, generic or group user IDs and/or passwords must not be created nor used. Conference accounts must be restricted to internet access only.

Providing user access

(44) Authorised users are allocated access rights and permissions that correspond with the tasks they are expected to perform, in accordance with the Information Technology Procedure - Acceptable Use and Access. Access rights should be role-based (e.g. a user account will be added to a group that has been created with access permissions required by that job role).

(45) Temporary access to the University's network and/or computer systems can be requested via the Temporary Access Administration System, and must include a declaration by the account supervisor that appropriate checks have been carried out and correct authorisation obtained prior to temporary access account creation.

User access de-registration

(46) When an employee departs the University under normal circumstances, standard process are triggered by the human resources management system and implemented by University’s approved identity and access management platform(s) to remove their access from managed ICT systems.

1. In exceptional circumstances, where there is a risk that a departing employee may take action that will harm the University prior to, or upon termination of their employment, senior management (Band 6 or above) may request that the uers’s  access is removed in advance of notice of termination being given. This precaution should especially apply in the case where the individual concerned has privileged access rights (e.g. domain administrator rights).
2. For services not managed by University’s identity and access management platform(s), the system custodian must suspend the departed user’s access.

(47) User accounts will be initially suspended or disabled only and not deleted. User account names should not be reused as this may cause confusion in the event of a later investigation.

(48) User access management controls must ensure that inactive or dormant accounts are identified and addressed in accordance with defined inactivity thresholds. 

User account inactivity and dormancy management 

(49) User accounts must be actively managed to reduce the risks associated with prolonged inactivity. 

1. Inactivity thresholds should be defined to identify accounts that require review. Subject to the nature of the system, recommended thresholds are:
   1. for standard user accounts, 90 days
   2. for privileged or elevated access accounts, 30 days or as otherwise determined based on risk.  
2. Accounts that exceed defined inactivity thresholds must be reviewed and, where no ongoing business need is identified, access removed or restricted. 
3. Controls to identify and manage inactive accounts should be implemented and progressively automated where technically feasible. 
4. Managers or account owners may be contacted to confirm ongoing access where required. Where no justification is provided, access should be removed. 
5. Exceptions must be documented, justified, approved, and subject to periodic review.

Remote work

(50) The University provides secure remote access services that allow authorised users to work from a remote worksite. Appropriate controls must be implemented to authorise and control remote work activities.

1. Any remote access for work purposes must employ multifactor authentication mechanisms (e.g. 2-Step Verification, SMS codes) where provided.
2. Authorised users must structure their remote working environment so that it is compliant with the Employment Conditions Procedure - Workplace Attendance.
3. When using direct remote access services (e.g. virtual private network – VPN), authorised users should use managed University devices that are kept up to date with current operating system and application software updates, and a current anti-virus solution.
4. Remote access using personal computing devices should use gateway services (e.g. virtual desktop infrastructure – VDI).

(51) Direct remote access using personal computing devices must be approved by the Manager, Infrastructure and provisioned via the IT Service Desk.

(52) Use of remote access services are logged and recorded, including the user’s name and logon/off times.

Vendor remote access

(53) Vendor access to the University's computer systems is granted solely for the work commissioned and for no other purposes.

(54) Vendors must comply with all applicable University policies, standards and agreements, and vendor agreements and contracts should specify:

1. agreed methods and technologies required to facilitate remote access
2. University information and systems the vendor should have access to. If, at the time of contract negations this is unknown or ambiguous, mention of this should be made in the agreement
3. how University information is to be protected by the vendor. A copy of the vendor’s security and privacy policy should be made available to the University
4. acceptable methods for the return, destruction or disposal of University information in the vendor’s possession at the end of the contract
5. agreement that the Vendor must only use University information and information systems for the purpose of the business agreement
6. any other University information acquired by the vendor in the course of the contract cannot be used for the vendor’s own purposes or divulged to others.

(55) Approval for vendor remote access should be sought via the system custodian or relevant manager.

(56) Privileged level access will be monitored and logged as per ‘Privileged access rights’ heading below.

(57) Before accessing University information systems and, unless covered by an existing contract or agreement, an authorised representative of the vendor must sign DIT's Vendor Security, Privacy, Copyright and Confidentiality Agreement Form.

(58) For vendors using a generic University account for remote access, contracts or agreements must include a requirement to inform the University of vendor staff moves and changes. Passwords must be changed as per the Information Technology Procedure - Passwords.

Review of user access rights

(59) On a regular basis (at least twice a year), asset and system custodians will be required to review and document who has access to their areas of responsibility and the level of access in place. This identifies:

1. people who should not have access (e.g. those who have left the University)
2. user accounts with more access than required by the role
3. user accounts with incorrect role allocations
4. accounts with extended periods of inactivity, including those exceeding definited inactivity thresholds, which must be reviewed and remediated in accordance with University requirements
5. accounts belonging to authorised users on long periods of leave
6. generic accounts
7. user accounts that do not provide adequate identification (e.g. generic or shared accounts)
8. accounts that breach segregation of duties
9. any other issues.

System and application access control

(60) As part of the evaluation process for new or significantly changed systems, requirements for effective access control should be addressed and appropriate measures implemented.

(61) These should consist of a comprehensive security model that includes support for, but not limited to:

1. creation of individual user accounts
2. definition of roles or groups which user accounts can be assigned
3. allocation of permissions to objects (e.g. files, programs, menus) of distinct types (e.g. read, write, delete, execute) to subjects (e.g. user accounts and groups)
4. provision of varying views of menu options and data according to the user account and its permission levels;
5. user account administration (e.g. ability to disable and delete accounts)
6. user logon controls:
   1. non-display of password as it is entered
   2. account lockout once number of incorrect logon attempts exceeds a specified threshold
   3. information about number of unsuccessful logon attempts and last successful logon once user has successfully logged on
   4. date and time-based logon restrictions
7. device and location logon restrictions
8. user inactivity timeout
9. password management:
   1. ability for user to change password
   2. controls over acceptable passwords
   3. password expiry
10. hashed/encrypted password storage and transmission
11. security auditing facilities
    1. logon/logoffs
    2. unsuccessful logon attempts
    3. object access
    4. account administration activities.

Access control considerations for new services

(62) As part of the selection of cloud service providers specifically, the following access-related considerations must be observed:

1. user registration and deregistration functions provided
2. facilities for managing access rights to the cloud service
3. extent access to cloud services, cloud service functions and cloud service customer data can be controlled on an as required basis
4. availability of multi-factor authentication for administrator accounts
5. procedures for the allocation of secret information (e.g. passwords).

(63) Addressing these requirements as part of the selection process will ensure that the provisions of this document can be met in the cloud, as well as within on-premise systems.

Privileged access rights

(64) Privileged access rights such as those associated with administrator-level accounts must be identified for each system or network and tightly controlled:

1. In general, privileged access accounts should not be used for day to day use of the system. A separate “admin” user account should be created and used only when additional privileges are required. These accounts must be specific to an individual (e.g. “John Smith Admin”). Generic admin accounts must not be used as they provide insufficient identification of the user.
2. Access to admin level permissions must only be allocated to individuals whose roles require them and who have received sufficient training to understand the implications of their use.
3. User accounts must not be used for privileged access in automated routines such as batch or interface jobs or as service accounts.

(65) Identified system or application custodians are responsible for approving or granting privileged access rights, and the authorisation level of those rights.

(66) Day to day management of privileged access rights are the responsibility of the delegated system or application administrator.

(67) The activity of privileged accounts must be monitored and logged including but not limited to:

1. logon/logoff times
2. commands issued
3. information accessed, copied or moved.

(68) Logs should be protected from unauthorised access and modification.

(69) Privileged accounts should be subject to more frequent review and stricter inacitivity thresholds due to their elevated risk profile.

Use of secret authentication information (passwords)

(70) Users are bound by the Information Technology Procedure - Passwords. Quality and complex passwords must be enforced, with the quality and complexity of passwords created by users enforced by controls in the password management system.

System and application access control

Information access restriction

(71) Access to information and application system functions must be restricted in accordance with the Information Technology Procedure - Acceptable Use and Access. All information that is sensitive, critical, and/or valuable, must have system access controls to ensure that they are not improperly disclosed, modified, deleted, or rendered unavailable.

(72) User privileges must be defined so ordinary users cannot gain access to, or otherwise interfere with, either the individual activities or private data of other users.

Secure logon

(73) Access to operating systems must use a secure logon process, with physical access to business information system hardware restricted.

(74) If any part of a logon sequence during the logging into a computer or data communications system process is incorrect, the user must only be given feedback that the entire logon process was incorrect.

(75) Every logon screen for multi-user computers must include a special banner stating that:

1. the system may only be accessed by authorised users
2. only authorised users may logon
3. system usage will be monitored and logged
4. unauthorised system usage or abuse is subject to criminal prosecution.

Password management system

(76) A formal password management system must be enforced. This password management system must include various password controls such as, but not limited to:

1. compliance with the Information Technology Procedure - Passwords
2. the recording of individual’s password management actions
3. the enforcement of regular password changes
4. the storage of passwords in an unrecoverable format.

(77) Information systems must not use vendor supplied defaults for system passwords and other security passwords.

(78) Users are bound by the University Information Technology Procedure - Passwords requiring users to follow industry best security practices in the selection and usage of passwords.

Use of privileged utility programs

(79) All information system tools and utilities that may be used to either cause significant damage and/or override systems must automatically be restricted to authorised users for intended usage purposes.

Access control to program source code

(80) Access to program source code must be restricted to authorised employees and agents and on a need-to-know basis only.

Mobile devices

(81) Only Univeristy-managed personal computing devices are given privileged network access to critical University information systems. Non university-managed mobile devices will only be given privileged network access where approved by the Chief Information and Digital Officer or nominee.

(82) Policies and supporting security measures should be adopted to manage the risks introduced by using managed devices. Appropriate controls must also be implemented to protect against the risks of working with mobile computing facilities used in unprotected environments.

(83) All managed and non-managed mobile devices containing sensitive information must employ storage encryption for all files.

(84) The University provides selected authorised users with portable computer equipment so that they may perform their jobs at remote locations.

1. Information stored in University portable computer equipment is University property and may be inspected or analysed in any manner at any time by the University.
2. The equipment must be returned to the University on cessation of employment with the University.
3. Authorised users must keep all portable devices containing University information in their possession, unless stored and/or deposited in a secure location.

Part F - Cryptography

(85) This part supports proper and effective use of cryptography to protect the confidentiality of information in the event of unauthorised access or interception.

Cryptographic controls

(86) Data classified as highly sensitive and/or confidential/private should be encrypted in transport over the internet as well as in storage. Deciding whether a cryptographic solution is appropriate must be part of the wider process of risk assessment and selection of controls, and should determine:

1. whether a cryptographic control is appropriate
2. what type of control must be applied
3. what purpose and operational process applies to such control.

(87) Specialist advice should be sought from the ICT Security Team to:

1. identify the appropriate level of protection
2. define suitable specifications that will provide the required protection and support for the implementation of a secure key management system.

Key management

(88) If encryption technology is in use, key management must be in place, including key management policies and procedures to ensure that all cryptographic keys are protected against:

1. modification
2. loss
3. destruction
4. unauthorised disclosure (secret and/or private keys)
5. equipment used to generate, store and archive keys (which must be physically protected)

(89) For keys used for the encryption of sensitive and/or critical data against disclosure and misuse, that key management policies and procedures should inlude:

1. restriction to the fewest number of custodians necessary for access to keys
2. key-encrypting keys are at least as strong as the data-encrypting keys they protect
3. key-encrypting keys are stored separately from data-encrypting keys
4. keys are stored securely in the fewest possible locations and forms
5. the crypto period(s) for each key type in use is defined, inclusive of the process for key changes at the end of the crypto period(s)
6. the retirement or replacement of keys when the integrity of the key has been weakened
7. the replacement of known or suspected compromised keys
8. any keys retained after the retirement or replacement of such keys are not used for encryption operations
9. a process specifying how to generate strong keys, how to securely distribute keys and how to securely store keys
10. a process preventing the unauthorised substitution of keys
11. a process for key custodians to acknowledge (in writing or electronically) their understanding and acceptance of key-custodian responsibilities.

Part G - Physical and environmental security

(90) This part sets out physical security requirements for the University such as computer room requirements, guarding, physical locks, and the security structure of all relevant premises within the offices of the University.

Secure areas

Physical security perimeter

(91) The University must define and use an appropriate security perimeter to protect areas such as data centres, which contain information processing facilities. Perimeter security barriers such as walls, card controlled entry gates and/or manned reception desks, should be utilised dependent on the level of physical security required.

(92) Data centre physical security must be reviewed at least annually.

Physical entry controls

(93) Remote data centre physical entry controls are governed by the data centre operator contracted to the University to provide data centre services.

(94) On-campus physical entry controls are governed by the Facilities and Premises Procedure - Access, Use and Security.

1. Secure areas are protected by appropriate entry controls to ensure that only authorised users are allowed access.
2. CCTV cameras and/or other access control mechanisms monitor individual physical access to sensitive areas. Such mechanisms are protected from tampering and/or disabling.
3. Entry and access logs are normally stored for at least three months, unless otherwise either restricted by law or increased by a subsequent standard or guideline.

(95) Access to offices, computer rooms, or work areas containing sensitive and/or critical information must be physically restricted, with access only provided to those with a valid business need. Authorised user access lists must be periodically reviewed with access revoked for individuals no longer requiring access.

(96) Documented processes and/or procedures for assigning identification cards to onsite authorised users and visitors define the processes for

1. granting of new identification cards
2. changing of access requirements
3. revoking identification cards for terminated onsite authorised users.

(97) Authorised users who can access the identification card generation and/or access control system(s) are documented and periodically reviewed.

(98) Visitor logs for data centres and secure areas must be retained for at least three months and contain the:

1. visitor’s name
2. organisation represented
3. onsite physical access.

(99) All authorised users must wear an identification badge on their outer clothing when in data centres and/or facilities that store sensitive and/or critical University data. This identification must be clearly visible and distinguishable between onsite authorised users and visitors.

(100) Employees must not permit unknown or unauthorised users access through doors, gates, and/or other entrances to restricted and/or sensitive areas.

Securing sensitive offices, rooms and facilities

(101) Controlled areas should be created to protect offices, rooms, and facilities that should not be open to general or public access. All employees must ensure doors to sensitive areas, rooms, and/or information processing facilities are locked, preventing unauthorised access when not in use. Physical and/or logical controls must be implemented, restricting access to publicly accessible network connection points.

Protecting against external and environmental threats

(102) Information systems must be housed in a secure manner, protected from external and environmental threats to the premises. Such threats include, but are not limited to:

1. theft
2. tampering
3. damage
4. destruction
5. flood
6. fire.

(103) Data centres must have:

1. fire detection and suppression
2. power conditioning
3. air conditioning
4. humidity control
5. other computing environment protection
6. appropriate intrusion alarm systems automatically alerting authorised users to take immediate action.

Working in secure areas

(104) Additional controls and guidelines for working in sensitive areas must be used to enhance the security provided by the physical controls protecting the secure areas. Access to sensitive areas must be authorised and based on individual job functions with access revoked immediately upon termination.

Delivery and loading areas

(105) Delivery and loading areas should be controlled, and where possible, isolated from information processing facilities to avoid unauthorised access.

Information and communication technology (ICT) equipment

Equipment location and protection

(106) On-premise equipment must be located and/or protected to reduce the risks from environmental threats, hazards, and opportunities for unauthorised access.

(107) Physical access to networking and/or communications hardware must be restricted by appropriate physical controls. All business critical production computer systems including, but not limited to servers, firewalls, proximity access control, systems, and/or voice mail systems must be physically located within a secure data centre.

(108) Authorised users who detect tampering with and/or substitution of devices are encouraged to report this. Training should be provided on how to:

1. verify the identity of any third-parties who claim to be repair or maintenance staff, before allowing them to modify or troubleshoot devices
2. obtain verification before installing, replacing, and/or returning devices
3. identify suspicious behaviour around devices (e.g. attempts by unknown persons to unplug or open devices)
4. report suspicious behaviour and indications of device tampering or substitution to appropriate staff.

Supporting utilities

(109) Key ICT equipment must be protected from power failures and surges and other electrical anomalies. Uninterruptible power supply (UPS) systems, line conditioners, electrical power filters, and/or surge suppressors must be used for business critical ICT infrastructure.

(110) Critical supporting utilities must be tested on a regular basis to ensure equipment has adequate capacity, in accordance with the manufacturer’s recommendations.

Cabling security

(111) Power and telecommunications cabling carrying data and/or supporting information services must be protected from interception or damage. Installation and maintenance of power and telecommunication cabling must follow current industry security standards.

Equipment maintenance

(112) Equipment sent off-site for maintenance purposes must have any sensitive or confidential information erased to ensure the confidentiality and integrity of information.

Unattended user equipment

(113) Users must ensure that unattended equipment contains appropriate protection and/or security controls when unattended. If the computer system to which an authorised user is connected contains sensitive information, the authorised user must not leave their personal computer, workstation, or terminal unattended without locking or logging out.

Clear desk

(114) Unless information is in active use by authorised users, desks must be clear and clean during non-working hours with sensitive information locked away.

Part H - Operations security

Operational procedures and responsibilities

(115) Operations security aims to:

1. secure the operation of information processing facilities
2. implement and maintain the appropriate level of information security on information assets
3. minimise the risk of system failures
4. protect and maintain the integrity and availability of information and information processing facilities
5. ensure the protection of information in networks and the protection of the supporting infrastructure
6. prevent unauthorised disclosure, modification, removal or destruction of assets and interruption of business activities
7. maintain the security of information exchanged within the University and with any external party
8. detect unauthorised information processing activities
9. protect information system against an individual falsely denying having performed an action.

Documented operating procedures

(116) Operating procedures for information systems must be documented and maintained. Operating procedures must include, but not be limited to:

1. procedures for processing and handling information
2. instructions for handling errors or other exceptional conditions
3. include support contacts for unexpected operational or technical difficulties.

Change management

(117) Nonstandard changes to information processing facilities and systems must be documented and controlled via the University Change Advisory Board (CAB). Extensions, modifications, and/or replacements to production software and hardware must be performed only when approval from CAB has been received prior to the proposed change window start time.

(118) A change control procedure for all changes is defined and includes the:

1. documentation of impact
2. documented approval by authorised parties
3. testing of functionality to ensure such change does not adversely impact the security of the system
4. testing of all custom code updates for compliance with industry standards and requirements where applicable
5. back-out, and/or change rollback procedures
6. communications plan ensuring relevant stakeholders are aware of any potential impact.

(119) Risk assessments and/or vulnerability assessments must be conducted when implementing new systems or making significant changes to existing systems.

(120) Adequate rollback procedures must be developed for all changes to production systems ensuring information processing in the case of a change failure can be promptly restored to the respective state prior to the most recent change.

(121) All changes to information processing facilities must be communicated to all relevant authorised users. Changes to the environment may also trigger the requirement to perform specific security tests, inclusive of, but not limited to vulnerability assessments and penetration tests confirming that changes made have not inadvertently degraded the security profile of the University.

Capacity management

(122) Capacity demands must be monitored with projections of future capacity requirements made to ensure that adequate processing power, storage and other required resources are available.

Separation of development, testing and operational environments

(123) Facilities and functions used in the development of computing solutions, notwithstanding their respective testing, must strictly be kept separate from production systems. This is to reduce the likelihood of accidental, and/or unauthorised changes to production systems, subsequently creating operational problems and/or compromising the University's related information.

(124) Separation can be achieved through physical or logical separation, appropriate to the sensitivity of the information and/or functions of the system concerned.

Protection from malware

(125) Detection and prevention controls to protect against malware and appropriate user awareness procedures must be implemented. Approved anti-malware software must be deployed across the University network to all systems, remain enabled, and contain regular definition updates and scanning.

(126) Anti-malware solutions and/or other appropriate controls should also be implemented and configured to prevent or detect the use of:

1. unauthorised software on information systems (e.g. server application whitelisting)
2. known or suspected malicious websites (e.g. blacklisting), and generate software logs with such logs retained for at least one year.

(127) Anti-malware mechanisms must be confirmed as actively running and cannot be disabled or altered by users unless specifically authorised by management on a case-by-case basis for a limited period.

(128) Systems that are malware-infected must be disconnected from the network until such time when the anti-malware software has been updated and all malware eradicated.

(129) Appropriate content filtering mechanisms must be deployed to protect all user initiated connections. Formal measurement and reporting procedures must also be implemented to record the number and severity of actual or suspected malicious code incidents.

Backup

(130) The University must ensure backup facilities are provided and used. Backup strategies are developed in collaboration with system custodians and contain copies of essential business information and software. All sensitive, valuable, and/or critical information recorded on backup computer media and stored outside University offices must be given an appropriate level of physical and environmental protection. Backup and restore procedures must be securely and adequately documented.

(131) Critical business information and critical software archived on computer storage media for prolonged periods must be tested at least annually providing assurance that such data can be completely and efficiently recovered.

(132) Refer to Appendix C for backup details.

Logging and monitoring

Event logging

(133) Audit logs must be produced for business critical systems, showing:

1. start and stop times for production applications
2. system boot and restart times
3. system configuration changes
4. system errors and corrective actions taken
5. confirmation of correct handling of files and related output.

(134) Audit trails must be retained for at least one year. Audit trails must be implemented to link all system component access to each individual user. For event reconstruction, audit trails should contain event information that may include, but not limited to:

1. privileged account system activities
2. individual user accesses to sensitive information
3. all changes to access controls at the network, operating system or application layers
4. access to all audit trails
5. invalid access attempts
6. use of and changes to identification and authentication mechanisms. This includes but is not limited to, the creation of new accounts, elevation of privileges and all changes, additions or deletions to accounts with root or administrative privileges
7. initialisation, stopping, or pausing of the collection of audit logs
8. creation and deletion of system-level objects.

(135) Audit trail entries recorded for all system components for each event must contain, but not be limited to:

1. identification of the user involved
2. type of event
3. date and time of event
4. success and/or failure indication
5. origination or source of event
6. identity or name of affected data, system component or resource.

Protection of log information

(136) All system and application logs must be maintained and stored securely in a form that cannot be accessed by unauthorised users. Any one authorised to access logs must have a demonstrable need for access to perform their regular duties, or as otherwise approved by the appropiate authority.

(137) Audit trails must be secured and promptly backed up to a centralised log server or to media that is difficult to alter. Only individuals with job-related needs may have access to view audit trail files.

(138) Log information should be exported to a security information and event monitoring solution for automated analysis, alerting and actioning.

Administrator and operator logs

(139) Administrators and operational staff activities must be logged, and the logs retained for at least one year, with a minimum of three months available online. These logs must be subject to regular and independent checks.

Clock synchronisation

(140) Time synchronisation technology such as the Network Time Protocol (NTP) must be used to synchronise all critical system clocks, dates, and times.

Control of operational software

Installation of software on operational systems

(141) Operational program libraries must only be updated by nominated administrators or system custodians with appropriate authorisation. Configuration management processes should be used to track and control all implemented software and related system documentation. Changes to operational systems must undergo the formal change management processes.

Technical vulnerability management

(142) Systems and processes must be in place to collect information about information system technical vulnerabilities. New security vulnerabilities should be identified using reputable outside information sources.

(143) The University’s exposure to these vulnerabilities must be evaluated and appropriate measures taken to address the associated risk.

(144) All patches and security updates should be pushed out in a formalised and secure manner. 

1. Critical or high-ranking patches should be installed within one month of release.
2. Other security patches should be applied within an appropriate period (e.g. within three months).

(145) For internet accessible web applications, new threats and vulnerabilities must be addressed on an ongoing basis and the applications protected against known attacks. Automated technical solutions that detect and prevent web-based attacks (e.g. a Web Application Firewall (WAF)) should be installed in front of public-facing web applications to provide continual checks of all traffic and generate alerts where applicable.

(146) Processes to review the security of public-facing web applications must be undertaken using either manual or automated tools or methods. These processes must be documented and reviewed:

1. at least twice a year
2. after any changes
3. by an organisation that specialises in application security
4. once all vulnerabilities are corrected.

(147) Such web application must be re-evaluated post remediation actions.

Restrictions on software installation

(148) An authorised user shall not introduce software or technology designed to disrupt, corrupt or destroy programs and/or data, or sabotage University ICT facilities as per the Information Technology Procedure - Acceptable Use and Access.

(149) Access rights for the installation of software should follow the principle of least privilege.

Information systems audit controls

(150) Operational system audits must be planned and agreed upon to minimise the risk of disruptions to business processes. Audit requirements, scope and access (other than read-only) must be authorised and adequate resources provided. Procedures, requirements and responsibilities should be documented with all access monitored and logged.

Part I - Communications security

(151) This part ensures the protection of information in networks and supporting information processing facilities.

Network security management

(152) Controls must be implemented to achieve and maintain performance, reliability and security in networks inclusive of information in transit. Firewalls must be installed at each internet connection between any de-militarised zone (DMZ) and/or intranets and between any wireless network.

(153) Configuration standards must be documented, implemented, updated and referenced for the installation and administration of all firewalls and routers. Rule sets and/or access control lists (ACLs) of firewalls and/or routers must be reviewed at least every six months. Configuration standards must include a description of groups, roles, and responsibilities for management of network components. They must also include a list of all services, protocols and ports necessary for business, inclusive of business justifications for protocols considered to be insecure.

(154) All data transmitted over open public networks must be secured using strong cryptography and security protocols including, but not limited to TLS (transport layer security), and/or IPsec. A process should also be specified for:

1. the acceptance of only trusted keys and/or certificates
2. the protocol in use to only support secure versions and configurations (e.g. that insecure versions or configurations are not supported)
3. the implementation of proper encryption strength per the encryption methodology in use.

(155) Configurations and related parameters on all hosts attached to the University network must comply with current policies and standards. Security risk assessments must be conducted as a part of network design processes with such assessments carried out when introducing new network services or making significant changes to existing services.

(156) All administrative access must be encrypted using security protocols, including but not limited to SSH (Secure Shell), VPN, or TLS. This applies to both web-based management and other administrative access. Responsibilities and procedures for the management of the network must also be established and documented.

(157) Network diagrams and configurations including connections to other systems and networks must be maintained and kept current. Network diagrams must identify all connections between the environments containing critical and/or sensitive data and other networks including any wireless networks.

(158) For critical business systems, methods to obscure IP addressing must be in place to prevent the disclosure of the private IP addresses and routing information from internal networks to the Internet. Such methods may include, but are not limited to:

1. Network address translation (NAT)
2. placing servers containing critical and/or sensitive data behind proxy servers and/or network load balancers
3. removal or filtering of route advertisements for private networks that employ registered addressing
4. internal usage of RFC1918 private address space instead of public addresses.

(159) Personal firewall software must be installed and active on any managed or non-managed devices used to access University’s network infrastructure that also connects to the Internet when outside of the University network. Personal security software must not be alterable by users of managed or non-managed devices. Security policies and operational procedures for managing firewalls should be documented, in use, and known to all affected parties.

Security of network services

(160) Clear descriptions of security attributes, service levels and management requirements for all network services used by the University must be provided, inclusive of service level agreements and monitoring for services provided in-house or outsourced.

Segregation in networks

(161) Controls must be implemented in networks to segregate groups of information services, users and information systems. Security risk assessments must be conducted as a part of network design processes with such assessments carried out regularly on data networks.

Information transfer

Information transfer policies and procedures

(162) When transferring confidential or private information outside of the University, procedures and controls must be developed and implemented to protect the exchange, confidentiality and integrity of information.

Agreements on information transfer

(163) Formal agreements must be established for the electronic and/or manual exchange of information between the University and other organisations, third parties or clients.

Electronic messaging

(164) All employees of the University with access to email facilities are bound by the Information Technology Procedure - Acceptable Use and Access.

Confidentiality or non-disclosure agreements

(165) Where no contractual agreement exists, confidentiality and/or non-disclosure agreements reflecting the needs of the University for the protection of information should be used, regularly reviewed and documented.

Part J - System acquisition, development, and maintenance

(166) This part details the specific criteria for the acquisition, development and maintenance of information systems.

Security requirements of information systems

(167) System custodians and project managers must consider security requirements at all stages of system application development, for in-house and outsourced software.

1. DIT must be consulted on security requirements and specifications in the initial stages of project development.
2. All software development efforts should follow defined processes for system and/or software development life cycle, with security measures defined at each stage of the process.

(168) Business requirements for new information systems, or enhancements to existing information systems, must specify the information security controls requirments, based on risk assessment and risk management frameworks. Security requirements and controls should reflect the business value of information assets involved and the potential business impact or loss that may result from a failure or absence of security.

Artificial intelligence services

(169) Use of suppliers or cloud service providers that offer artificial intelligence (AI), machine learning, or automated decision-making capabilities must comply with the University's information security, privacy, and information classification requirements.

(170) University information classified as confidential/private or highly sensitive must not be used in supplier provided or externally hosted AI services unless the service has been formally approved and appropriate contractual, security, and privacy controls are in place.

(171) AI-enabled services are subject to the same supplier assurance, risk assessment, access control, and monitoring requirements as other cloud and third-party services

Securing application services on public networks

(172) Information involved in application services traversing public networks should be protected using strong encryption methods from fraudulent activity and unauthorised disclosure and modification.

Protecting application services transactions

(173) Information involved in application integration services should be protected to prevent:

1. incomplete transmission
2. misrouting
3. unauthorised message alteration
4. unauthorised disclosure
5. unauthorised message duplication and/or replay.

Security in development and support processes

(174) Software and system development rules should be established and applied to all developments within the University.

System change control procedures

(175) The implementation of changes must be controlled using the University Information Technology Infrastructure Library (ITIL) change management procedures. The change management procedures must also be used for the testing and implementation of security patches and software modifications.

Technical review of applications after operating platform changes

(176) When hosting environments and/or operating systems are significantly changed, business critical applications must be reviewed and tested to ensure there are no adverse impacts or information security risks to the application.

Restrictions on changes to software packages

(177) Modifications to vendor supplied software packages must be discouraged and/or limited to necessary changes. All changes must be strictly controlled, documented and approved via change control procedures.

Secure system engineering principles

(178) Guidelines for engineering of secure systems should be documented, maintained, reviewed and applied to any information system implementation efforts.

Virtualisation

(179) Virtualisation of systems can deliver increased operational efficiency in terms of hardware, network, storage and utilities usage. The security requirements of all virtualisation components must be considered.

(180) Most security vulnerabilities and threats apply equally to virtualised and physical environments however virtualisation may introduce additional security implications.

(181) All elements of a virtualisation solution must be secured and security maintained through software updates, configuration reviews and security testing.

(182) Administrator access to the hypervisor must be restricted, managed and monitored.

(183) Hypervisors and guest operating systems should be monitored for indicators of compromise.

Secure development environment

(184) The University should establish and appropriately protect secure development environments for system development and integration efforts, encompassing the entire system development lifecycle.

(185) Privileged access to development and test environments should use different credentials from those used to access production environments.

Outsourced development

(186) When outsourcing software development projects the University should consider:

1. licensing arrangements, code ownership, and intellectual property rights
2. certification of the quality and accuracy of the work carried out
3. escrow arrangements in the event of failure of the third party
4. rights of access for audit of the quality and accuracy of work done
5. contractual requirements for quality and security functionality of code
6. testing before installation (e.g. penetration testing, vulnerability testing, source code analysis) to detect malicious and/or Trojan code.

System security testing

(187) Testing of application security functionality should be integrated into development processes.

System acceptance testing

(188) Acceptance criteria for new information systems, upgrades and new versions must be established with suitable tests of the system carried out prior to acceptance. Requirements and criteria for acceptance of new systems must be clearly defined, agreed, documented and tested.

Test data

(189) Test data should be carefully selected and protected. If production data is used in development or test environments, it should be masked or obscured.

(190) Test data, applications and related systems must be protected from unauthorised access and modifications. Operational databases containing sensitive and/or critical production data/information must not be used for testing purposes.

(191) Confidential and personally identifiable information (PII) used for testing purposes, including sensitive details and content, must be appropriately protected. Production data must not be used for testing or development.

Part K - Supplier and cloud service provider relationships

(192) This part supports protection of the University's assets accessible by suppliers.

Information security procedures for supplier relationships

(193) Use of cloud services does not transfer accountability for information security. The University retains responsibility for data protection, identity, access control, and configuration. Information security requirements for mitigating the risks associated with supplier access to University assets must be agreed with the supplier and documented.

(194) Any authorised users contemplating the use of cloud-based services, or the transfer or storage of University information externally, must consult DIT to ensure that the solution is viable and secure.

(195) Cloud service procurement should be undertaken in accordance with the NSW Government Cloud Policy and DIT's project security considerations.

Addressing security within agreements

(196) All relevant information security requirements should be established and agreed upon with each supplier that may access, process, store, communicate, and/or provide ICT infrastructure components for the information of the University.

(197) Contractual agreements should consider and include the security considerations as described in the NSW Government Cloud Policy and DIT's project security considerations.

Supplier service delivery management

(198) Service providers should be engaged following established processes that include appropriate due diligence checks. The University must maintain a list of service providers and a written agreement from each that includes an acknowledgement by the service provider of their responsibility for securing critical and/or sensitive data that the service provider possesses, or otherwise stores, processes, or transmits on behalf of the University.

(199) Service provider contracts and the provider’s compliance with information security requirements must be reviewed regularly and/or when significant changes occur, to ensure that appropriate security controls and practices are in place to protect University information. Reviews should be completed:

1. at defined intervals appropriate to the level of risk, the services provided, and the classification of the information handled by the service provider
2. when there are changes to hosting arrangements (such as data location or cloud service environments) or the scope or nature of services provided
3. when there are material changes to the service provider’s security posture (e.g. reported security incidents or audit findings)
4. at contract renewal time.

(200) Service providers should provide regular reports on the status of the services delivered, and the University should review reports regularly to ensure adherence to agreements.

(201) When required, service providers should allow the University, or an entity on its behalf, to audit the service provider’s facilities, networks, computer systems and procedures for compliance in accordance with the agreed information security policies and standards.

(202) Changes to the services provided by third parties must be managed in line with formal change control procedures, including consideration of business system criticality and processes involved for risk (re)assessment. These changes may include:

1. enhancements to the services provided
2. use of new technologies
3. adoption of new products, versions or releases
4. changes to physical location of service facilities.

Part L - Information security incident management

(203) This part provides definitions of the types of security incidents that may occur and plans for corrective action.

Management of information security incidents and improvements

Responsibilities and procedures

(204) A consistent and effective approach must be applied to the management of information security incidents. Incident management responsibilities and procedures must be established to ensure quick, effective and orderly responses to security incidents and software malfunctions.

(205) Individuals responsible for handling information security incidents must provide accelerated problem notification, damage control, and problem correction services in the event of computer related emergencies such as virus outbreaks and intrusions.

(206) Individuals responsible for handling information systems security incidents must have clearly defined responsibilities and be provided the authority to handle incidents and create security incident reports.

(207) The Division of Information Technology (DIT) is responsible for defining and operating a critical incident response process.

Reporting information security events

(208) Information security events associated with information systems must be reported to the IT Service Desk.

(209) A formal reporting and incident response procedure must be established for all breaches of information security, actual or suspected.

(210) All authorised users must be made aware of the procedure for reporting security incidents and the need to report incidents immediately.

(211) The DIT's critical incident response process must be tested at least annually and testing procedures must be in place.

Reporting information security weaknesses

(212) Any observed or suspected security weaknesses in, or threats to, systems or services must be reported to the IT Service Desk. All authorised users must be made aware of this and be instructed not to attempt to deliberately exploit suspected vulnerabilities.

Assessment of and decision on information security events

(213) Information security events should be assessed to determine whether they are to be classified as information security incidents.

Response to information security incidents

(214) Information security incidents should be responded to by the DIT ICT Security Team including other relevant authorised users of the University and/or external parties.

Learning from information security incidents

(215) Mechanisms must be in place to enable the types, volumes and costs of incidents and malfunctions to be quantified and monitored. An annual analysis of reported information security problems and violations must be prepared. Knowledge gained from analysing and resolving information security incidents should be used to reduce the likelihood or impact of future incidents.

Collection of evidence

(216) Where action against an individual or organisation involves the law, either civil or criminal, the evidence presented must conform to the rules for evidence laid down in the relevant law or in the rules of the specific court in which the case will be heard. This must include compliance with any published current standard and/or code of practice to produce admissible evidence.

Part M - Information security and business continuity management

Information systems continuity

(217) Information systems continuity must be embedded within the University's business continuity management systems.

Planning information systems continuity

(218) A managed process regarding information systems availability requirements must be in place for the development and maintenance of business continuity throughout the University. Plans based on appropriate risk assessments must be developed as part of the overall approach to the University's business continuity. This is described in the Information Technology Policy. The ICT Security Team in conjunction with the Division of Information Technology leadership oversee the implementation of this. The extent of such plans is dependent on the delivery of a business impact analysis (BIA).

(219) Such BIA must result in the specification of the:

1. maximum period that the University can go without critical information processing services
2. period in which management must decide whether to move to an alternative processing site
3. minimum acceptable production information system recovery configuration after a disaster or crisis.

Implementing information security continuity

(220) Plans must be developed to maintain or restore business operations in a timely manner following a disaster or crisis.

(221) The Information Technology Service Continuity Management (ITSCM) team must prepare and update a crisis management plan, covering topics such as:

1. a process for managing the crisis
2. crisis decision making
3. the safety of employees
4. damage control
5. communications with third parties such as the media.

(222) The ITSCM team will develop, implement and test business continuity and/or disaster recovery plans. Such plans must specify how alternative facilities such as, but not limited to telephones, systems, and networks, will be provided for authorised users to continue operations in the event of an interruption to, or failure of, critical business processes.

(223) All business continuity plans must consider the information security requirements of the University.

Verify, review and evaluate information security continuity

(224) The University should verify established and implemented information security continuity controls at reoccurring intervals ensuring such controls are valid and effective during adverse situations. Business continuity plans must be tested regularly by respective teams as outlined in the ITSCM and undergo regular reviews ensuring such plans are up to date and effective.

Redundancies

(225) Appropriate redundancy, as determined by required service levels, must be in place for critical systems and assets ensuring the availability of information processing facilities.

Availability of information processing facilities

(226) The University should identify business requirements for the availability of information systems. Where the availability cannot be guaranteed using existing system architecture, redundant components and/or architectures should be considered.

(227) Where applicable, redundant information systems should be tested ensuring successful failover between components and/or other functions as intended.

Part N - Compliance

(228) This part suports compliance with legal, statutory, regulatory, and/or contractual obligations related to information security and/or other security requirements.

Compliance with legal and contractual requirements

(229) For every University production information system, all relevant statutory, regulatory and contractual requirements must be identified. This includes but is not limited to:

1. NSW Cyber Security Policy
2. NSW Government Cloud Policy
3. Privacy and Personal Information Protection Act 1998 No 133
4. Australian Privacy Principles
5. Federal Mandatory Data Breach Notification
6. State Records Act 1998 No 17

Intellectual property rights

(230) Appropriate procedures must be implemented to ensure compliance with legal restrictions on the use of material in respect of intellectual property rights and on the use of proprietary software products.

(231) All computer programs and program documentation owned by the University must include appropriate copyright notices.

Protection of records

(232) University records must be protected from loss, destruction, and falsification. Refer to the Records Management Policy, Privacy Management Plan and the Information Technology Procedure - Personal Data Breach.

Information security reviews

(233) The University must conduct information security reviews to ensure that information security controls are implemented and operated in accordance with the University's policies and procedures.

Independent review of information security

(234) The University's approach to managing information security and its implementation (e.g. control objectives, controls, policies, processes and procedures) should be reviewed independently at planned intervals or when significant changes occur.

Compliance with security policies and standards

(235) The University must ensure that all security procedures within their areas of responsibility are carried out correctly. Areas within the University that must be subjected to regular reviews to ensure compliance with security policies, procedures and standards include, but are not limited to:

1. information systems
2. system providers
3. management
4. users, and 
5. custodians of information and assets.

(236) Variances from generally accepted information system control practices must be noted and promptly initiated for corrective action.

Technical compliance review

(237) Technical compliance should be reviewed with the assistance of automated tools which generate technical reports for subsequent interpretation by technical specialists. Alternatively, manual reviews by experienced system engineers supported by appropriate software tools may be performed.

(238) Any technical compliance reviews such as penetration tests or vulnerability assessments should only be carried out by competent authorised users and/or under the supervision of such users.

Information security management system (ISMS) performance monitoring process

(239) The operation of the ISMS will be monitored in accordance with the University ISMS performance monitoring process.

Benchmarking

(240) Cyber security benchmarking should be conducted to ensure that the University's cyber security posture is aligned with the evolving threat landscape and sector opportunities.

(241) With reference to industry benchmarks, frameworks, standards and best practices, the University will identify gaps and vulnerabilities in deployed security controls and develop remediation plans to address these issues as part of an ongoing continuous improvement program.

(242) Benchmarking reviews will be carried out by competent authorised parties and will include the following elements:

1. Assessment of current cyber security controls and procedures against sector peers.
2. Identification of gaps and vulnerabilities.
3. Development of remediation plans.
4. Tracking of progress and reporting on results.

Section 3 - Glossary

(243) This guideline uses terms defined in the Information Technology Policy, as well as the following:

1. Administrative privileges – means any feature or facility of an information system that enables the user to override system or application controls.
2. Asset custodian – means an authorised user with responsibility and ownership of Information and Communication Technology (ICT) assets as identified and listed in the University's asset registers.
3. Business critical assets – include:
   1. information
   2. software
   3. physical assets
   4. services.
4. DIT Change Advisory Board (CAB) – ensures that all requested IT changes are thoroughly checked and assessed from both a technical and business change risk/impact perspective. No change can be implemented in any production environment without appropriate CAB approval.
5. Cloud platform – means on-demand access of hosted applications, systems and infrastructure in various forms and models, including:
   1. Infrastructure as a Service (IaaS)
   2. Platform as a Service (PaaS)
   3. Identity as a Service (IDaaS)
   4. Software as a Service (SaaS)
   5. Integration platform as a Service (IPaaS).
6. Computer media - includes:
   1. tapes
   2. disks
   3. cassettes
   4. faxes
   5. removable media
   6. printed reports.
7. Computer system(s) – means any University system used for the processing of information, either within the University premises, or at an off-site location. This includes private and/or third-party equipment, if such equipment is used to access University information.
8. Controlled area – means any area or space on University premises to which general or public access is not available at that time. This may be characterised by signs, locked doors, fences, boom-gates, sentinel tape, or be defined by the instruction of a Campus Security Officer or designated member of staff.
9. Cryptography key – means a string of bits used by a cryptographic algorithm to transform plain text into unreadable format or vice versa.
10. Crypto period – means the time for which a cryptography key is valid.
11. Custodian – means the senior responsible officer of the group that administers and operates that information asset or system.
12. Failover – means a procedure by which a system automatically transfers control to a duplicate system or redundant system when it detects a fault or failure.
13. Information security - encompasses:
    1. ICT security policies
    2. organisation of information security
    3. ICT asset management
    4. information security compliance obligations
    5. information security components of human resources management
    6. ICT communications and operations management
    7. information security components of business continuity management
    8. ICT services access control
    9. ICT security incident management
    10. ICT systems acquisition, development and maintenance
    11. ICT asset physical and environmental security.
14. Hypervisor – means software, firmware or hardware that creates and runs virtual machines.
15. Malware – means malicious software. An umbrella term used to refer to a variety of forms of hostile or intrusive software.
16. Managed device – means a University supplied personal computing or mobile device registered to the Universitynetwork with standard University software installed and updated by the Division of Information Technology.
17. Need to know – means access to the sensitive information necessary for the conduct of an individual’s official duties.
18. Network services – include:
    1. messaging (e.g. email, instant messaging)
    2. file transfer
    3. interactive access
    4. application access.
19. Non-managed personal computing/mobile device - is a personal computing or mobile device not registered to the University network. Setup is as received out of the box from the vendor. Includes telephony devices connected to the cellular network.
20. Personal identification number (PIN) - means a secret number (usually four to six digits in length) known only to an individual. Used to confirm identity and gain access to an Information and Communication Technology (ICT) system.
21. Principle of least privilege – means an authorised user is given access only which is essential to perform the needs of their work role.
22. Privileged access – means the ability to perform an action (e.g. administrative functions) outside of a user’s day to day job function, using a secondary account.
23. Resources – means information technology support staff, technologies and supporting infrastructure owned or maintained by the University.
24. System custodian – means university executive staff with responsibility and ownership of information or Information and Communication Technology (ICT) assets as identified and listed in the University's Applications Portfolio, or the Primary Budget Centre Manager responsible for non-listed systems.
25. Service provider – means an organisation engaged by the University to provide services for and in the name of the University.