Information that if breached owing to accidental or malicious activity would have an insignificant impact.

The information is authorised for public access, however it may not be made available in the public domain.

Information that if breached owing to accidental or malicious activity would be unlikely to cause harm to UQ, another organisation or an individual if released publicly.

The information has a restricted audience, and access must only be authorised based on academic, research or business need.

Information that if breached owing to accidental or malicious activity could reasonably be expected to cause harm to UQ, another organisation or an individual if released publicly.

The information has a restricted audience, and access must only be authorised based on strict academic, research or business need.

Information that if breached owing to accidental or malicious activity could reasonably be expected to cause serious harm to UQ, another organisation or an individual if released publicly.

The information has a restricted audience, and access must only be authorised based on very strict academic, research or business need.

• All data must be assigned an appropriate Information Domain, Information Domain Custodian and Information Steward as per the Information Governance and Management Framework.
• For research data, a First-named Chief Investigator (also referred to as Lead Chief Investigator) and Head of School or Institute must be determined / assigned at the start of the project.
• When planning organisational roles and responsibilities, considerations should be given to minimising the number and types of roles which require highly privileged access to classified data.
• If production data is used for testing, then test systems need to be treated the same as production systems in terms of data controls and mitigations.
• Systems should be designed and configured following the principle of “least privilege” – consumers should only be given access to the data required to execute their responsibilities.
• Data retention and disposal requirements must be understood.
• Data Sovereignty must be considered. Refer to 3.8 Data sovereignty. 

A Privacy Impact Assessment (PIA) and Risk Assessment should be conducted for SENSITIVE data that include Personal Information. The PIA can be completed between the Information Steward and Information Service Provider.

• PIA and Risk Assessment must be conducted for PROTECTED data that include Personal Information. The PIA can be completed between the Information Steward and Information Service Provider.
• All employees must complete training specific to dealing with PROTECTED data.

Links:

• UQ Information Governance and Management Framework
• Office of the Australian Information Commissioner - Guide to undertaking privacy impact assessments

• Data quality at the time of creation is the primary responsibility of the Information Creator and must be compliant with the overarching policies and procedures.
• The individual who created the data must be identified and recorded where possible.
• Any business process specific to regulatory or legislative requirements for data creation must be considered and implemented.
• Consideration should be given to the University’s moral and ethical obligations to educate and accurately inform the public.
• Consideration should be given to whether the data could lead to reputational damage to the University or others (e.g. if breached).
• Consideration should be given to the level of confidence and accuracy of data from a perspective of whether a data breach may lead to defamation.

Links:

• UQ Information Governance and Management Framework

• Systems should be designed and configured following the principle of “least privilege” – users and systems should only be given access to the data required to execute their responsibilities.
• Account credentials should be centrally managed to reduce the number of systems handling credentials. Where possible, systems should use UQ Authenticate (Single Sign-On (SSO) is preferred, however Same Sign-On is acceptable).
• Organisational policies and procedures relating to employee terminations, resignations or changes in responsibilities should carefully and thoroughly consider issues of data access control and retention. Account removal from systems, as well as management of role/group membership, should be automated.
• Systems should enable and use exploit mitigation technology (i.e. ASLR, NX, stack canaries, and any other mitigations) recommended by hardware or OS software vendors.
• Systems should use anti-virus software where possible, and regularly update definitions.
• Systems should use Intrusion Detection Systems (IDS) and other techniques to detect exfiltration of data and unusual activity.
• Systems should be designed to use network segmentation and default-deny firewalls to contain the impact of unauthorised access.
• User authorisation for data access and modification should require multiple ‘factors’ (e.g. something you know, such as a password, and something you have, such as a device).
• Password policies should be written to encourage the highest quality passwords possible, by following guidelines such as NIST Special Publication 800-63B. Users’ use of appropriate password managers and other aides which increase password quality should be encouraged.
• Data should be backed up, using methods appropriate to its classification. Backups should be useable for the detection of unauthorised changes in the production copy as well as recovery from disasters (e.g. they should be append-only or use snapshots and offline storage).
• Note: long term archival requirements are addressed under section 3.6 Retain and archive.
• External providers storing data on UQ’s behalf should implement similar controls and mitigations to those required for storing it at UQ. 

• If deploying a system which supports encryption at rest, this functionality should be enabled and used.
  • Keys for encryption may be kept with the disks in the same system, but should not be stored on the disks (e.g. TPM is acceptable).
  • The procedure for key destruction/erasure should be known and tested, and reliably carried out at time of system disposal.
• Access control for OFFICIAL – PUBLIC data is only required for modification or “write” operations. Public data may be read by anyone.

• Systems should support encryption at rest, and it should be enabled and used.
  • Keys for encryption may be kept with the disks in the same system, but should not be stored on the disks (e.g. TPM is acceptable).
  • The procedure for key destruction/erasure should be known and tested, reliably carried out at time of system disposal.
• Systems must be kept in secure facilities with physical access control and mitigation such as alarms, surveillance and guard patrols.
• Consider disabling features such as the ability to allow public access to data, for systems which support this (e.g. in AWS S3, disable public access at the bucket level).
• Hardware purchased or used for storage should be tracked down to individual disks via the UQ asset management system where possible (with HDD serial numbers recorded where possible). Loss of hardware due to theft or misplacement should be detected quickly and reported to appropriate person up chain of command.
• Regular review of access control policy (e.g. file system permissions, role/group membership) should be carried out by the Information Steward, looking for outdated or incorrect policy.
• Local copies of data should not be made to portable devices. Data should remain on UQ managed endpoints.
• Systems that support audit trail features, should have these enabled.
• Detection and monitoring should be in place for phishing or credential compromise of users with data access.
• External providers storing data on UQ’s behalf should be required either by contract or local law to inform UQ promptly if a breach is detected. Also refer to the Application Security Standard.
• Systems should be designed to minimise the likelihood and impact of ‘horizontal movement’ between systems, or between system components. Suggested controls include firewalls, WAF, IDS, strict ACLs, etc. Designs involving a large internal trust domain (e.g. a trusted management VLAN) should be avoided.

• Systems must support encryption at rest, and it must be enabled and used.
  • Keys for encryption should not be kept solely with the disks in the same system: at least part of the key should be stored outside the physical chassis.
  • The procedure for key destruction/erasure must be known and tested, reliably carried out at time of system disposal.
  • In some cases, physical security controls may be considered as the basis for an exemption for this requirement.
• Systems must be kept in secure facilities with physical access control and mitigation such as alarms, surveillance and guard patrols. Surveillance should be monitored 24/7 and response to alarms should occur within a specified and agreed timeframe.
• Must disable features such as the ability to allow public access to data, for systems which support this (e.g. in AWS S3, disable public access at the bucket level).
• Hardware purchased or used for storage must be tracked down to individual disks via the UQ asset management system where possible (with HDD serial numbers recorded where possible). Loss of hardware due to theft or misplacement must be detected quickly and reported to appropriate person up chain of command.
• Regular reviews of access control policy (e.g. file system permissions, role/group membership) must be carried out by the Information Steward, looking for outdated or incorrect policy.
• Local copies of data must not be made to portable devices. Data must remain on UQ managed endpoints on the UQ secured networks.
• Systems must support audit trail features, must have these enabled, and must be monitored for unusual activity. Audit trails should be stored separately in a tamper-proof fashion for a minimum retention period.
• User authorisation for data access and modification must require multiple ‘factors’ (e.g. something you know, such as a password, and something you have, such as a device).
• Detection and monitoring must be in place for phishing or credential compromise of users with data access.
• External providers storing data on UQ’s behalf must be required either by contract or local law to inform UQ promptly if a breach is detected. Also refer to the Application Security Standard.
• Procurement and tender processes must evaluate controls and mitigations implemented by external providers to ensure their equivalence to the minimum requirements set out in this procedure and relevant standards. Including these requirements in any formal contract should be strongly considered.
• Systems must be designed to minimise the likelihood and impact of ‘horizontal movement’ between systems, or between system components.
• System components which communicate over a network connection internally must treat that traffic as though it contains data at the same classification level as the highest stored within that system (and therefore must implement appropriate controls and mitigations for data transmission such as authentication, TLS etc.).
• Suggested controls include firewalls, WAF, IDS, strict ACLs etc. Designs involving a large internal trust domain (e.g. a trusted management VLAN) must be avoided.
• The University should solicit legal advice on the obligations of data storage providers prior to signing contracts. Refer to the ICT Procurement Framework.
• Systems must implement mechanisms to automatically detect and mitigate bulk exfiltration of data (e.g. rate limits, network traffic monitoring).
• Regular penetration testing of systems must be carried out and all findings acted upon.
• Regular reviews of vendor contracts to evaluate their ongoing compliance with this procedure and future versions of it must be carried out.
• Systems must not place credentials or authorisation tokens in log files or audit records.

• Systems must support encryption at rest, and it must be enabled and used.
  • Keys for encryption must not be kept solely with the disks in the same system; at least part of the key must be stored outside the physical chassis.
  • The procedure for key destruction/erasure must be known and tested, and reliably carried out at time of system disposal.
  • In some cases, physical security controls may be considered as the basis for an exemption for this requirement.
• Systems must be kept in secure facilities with physical access control and mitigation such as alarms, surveillance and guard patrols. Surveillance must be monitored 24/7 and response to alarms must occur within a specified and agreed timeframe.
• Systems should make use of policy preventing lone malicious actions, such as an N-person rule for access and modification to PROTECTED data.
• Must disable features such as the ability to allow public access to data, for systems which support this (e.g. in AWS S3, disable public access at the bucket level).
• Hardware purchased or used for storage must be tracked down to individual disks via the UQ asset management system where possible (with HDD serial numbers recorded where possible). Loss of hardware due to theft or misplacement must be detected quickly and reported to appropriate person up chain of command.
• Regular reviews of access control policy (e.g. file system permissions, role/group membership) must be carried out by the Information Steward, looking for outdated or incorrect policy.
• Local copies of data must not be made to portable devices. Data must remain on UQ managed endpoints on the UQ secured networks.
• Systems must support audit trail features, must have these enabled, and must be monitored for unusual activity. Audit trails must be stored separately in a tamper-proof fashion for a minimum retention period. Automated actions such as account suspension and limits should be taken in response to anomalous behaviour.
• Detection and monitoring must be in place for phishing or credential compromise of users with data access.
• User authorisation for data access and modification must require multiple ‘factors’ (e.g. something you know, such as a password, and something you have, such as a device). Device factors with strong anti-cloning and anti-tampering features are highly recommended (e.g. Common Criteria EAL4 or higher).
• External providers storing data on UQ’s behalf must be required either by contract or local law to inform UQ promptly if a breach is detected. Also refer to the Application Security Standard.
• Procurement and tender processes must evaluate controls and mitigations implemented by external providers to ensure their equivalence to the minimum requirements set out in this procedure and relevant standards. Including these requirements in any formal contract should be strongly considered.
• Systems must be designed to minimise the likelihood and impact of ‘horizontal movement’ between systems, or between system components.
• System components which communicate over a network connection internally must treat that traffic as though it contains data at the same classification level as the highest stored within that system (and therefore must implement appropriate controls and mitigations for data transmission such as authentication, TLS, etc.). Suggested controls include firewalls, WAF, IDS, strict ACLs, etc. Designs involving a large internal trust domain (e.g. a trusted management VLAN) must be avoided.
• The University should solicit legal advice on the obligations of data storage providers prior to signing contracts. Refer to the ICT Procurement Framework.
• Systems must implement mechanisms to automatically detect and mitigate bulk exfiltration of data (e.g. rate limits, network traffic monitoring).
• Regular penetration testing of systems must be carried out and all findings acted upon.
• Must carry out regular reviews of vendor contracts to evaluate their ongoing compliance with this procedure and future versions of it.
• Systems must not place credentials or authorisation tokens in log files or audit records.

Links:

• Endpoint Security Standard
• Application Security Standard
• Data Security Controls Standard
• Access and Privileges Management Framework
• ICT Procurement Framework

• If data is subject to copyright, permission should be obtained from the copyright holder before transmission.
• Data in transit should be protected by cryptographic security mechanisms which provide confidentiality and integrity, where systems support it and implementation cost is not prohibitive. TLS is recommended. 

• Data in transit should be protected by cryptographic security mechanisms which provide confidentiality and integrity. TLS is recommended. Mechanisms that support forward secrecy should be preferred.
• Network devices should be located in secure areas, ideally with monitoring.
• Regular inspections of key cabling runs and network devices looking for malicious changes or insertions should be carried out.
• Wireless clients used to access data should use strict certificate checking for WPA-Enterprise (i.e. there should be mutual authentication), and regular scans for rogue access points should be carried out.
• Data transferred in bulk via portable disks, devices and other media should be encrypted, with keys transferred separately.
• Media used for bulk data transfer should be managed in accordance with best practice standards requiring prompt erasure after use.
• Where available, dedicated systems should be used for the sharing and transmission of data, rather than ad-hoc methods (e.g. email, print outs).
• Endpoint credentials used to secure communications should be managed in accordance with best practices for managing TLS certificates.

• Data in transit must be protected by cryptographic security mechanisms which provide confidentiality and integrity. TLS is recommended. Forward secrecy must be enabled.
• Network devices must be located in secure areas, with surveillance and an audit trail of physical access.
• Regular inspections of key cabling runs and network devices looking for malicious changes or insertions must be carried out.
• Wireless clients used to access data must use strict certificate checking for WPA-Enterprise (i.e. there should be mutual authentication), and regular scans for rogue access points must be carried out.
• Data transferred in bulk via portable disks, devices and other media must be encrypted, with keys transferred separately.
• Bulk transport of data should consider using secret sharing (e.g. N-out-of-M schemes) or cryptographic security protocols which split the data securely across multiple media.
• Media used for bulk transfer must be managed in accordance with best practice standards requiring prompt erasure after use.
• Where available, dedicated systems must be used for the sharing and transmission of data, rather than ad-hoc methods (e.g. email, print outs).
• Endpoint credentials used to secure communications should be managed in accordance with best practices for managing TLS certificates.
• Intermediary devices (e.g. network devices or printers) which handle SENSITIVE data should limit the use of features such as packet capture, traffic inspection, or print out recall, and where needed restrict the use of said features to the minimum possible number of employees. Disposal of such devices must be managed in accordance with a strict lifecycle procedure which includes erasure of all internal storage.
• Do not print SENSITIVE data unless there is a genuine requirement to do so. If required, do not use printers that are located in low security areas or connected to general office networks. Printed documents must be disposed of securely in accordance with document disposal best practice.
• Procurement and tender processes should evaluate controls and mitigations implemented by external providers to ensure their equivalence to the minimum requirements set out in this procedure. Including these requirements in any formal contract should be strongly considered. Must carry out regular reviews of vendor contracts to evaluate their ongoing compliance with this procedure and future versions of it.

• Data in transit must be protected by cryptographic security mechanisms which provide confidentiality and integrity. TLS is recommended. Forward secrecy must be enabled.
• Network devices must be located in secure areas, with surveillance and an audit trail of physical access.
• Regular inspections of key cabling runs and network devices looking for malicious changes or insertions must be carried out.
• Wireless clients used to access data must use strict certificate checking for WPA-Enterprise (i.e. there should be mutual authentication), and regular scans for rogue access points must be carried out.
• Data transferred in bulk via portable disks, devices and other media must be encrypted, with keys transferred separately and not reused for subsequent transfers.
• Bulk transport of data must consider using secret sharing (e.g. N-out-of-M schemes) or cryptographic security protocols which split the data securely across multiple media.
• Media used for bulk transfer must be managed in accordance with best practice standards requiring prompt erasure after use.
• Where available, dedicated systems must be used for the sharing and transmission of data, rather than ad-hoc methods (e.g. email, print outs).
• Endpoint credentials used to secure communications should be managed in accordance with best practices for managing TLS certificates.
• Intermediary devices (e.g. network devices or printers) which handle PROTECTED data must strictly limit the use of features such as packet capture, traffic inspection, or print out recall, and where needed restrict the use of said features to the minimum possible number of employees. Disposal of such devices must be managed in accordance with a strict lifecycle procedure which includes erasure of all internal storage.
• Do not print PROTECTED data unless there is a genuine requirement to do so. If required, do not use printers that are located in low security areas or connected to general office networks. Printed documents must be disposed of securely in accordance with document disposal best practice.
• Procurement and tender processes must evaluate controls and mitigations implemented by external providers to ensure their equivalence to the minimum requirements set out in this procedure. Including these requirements in any formal contract should be strongly considered. Must carry out regular reviews of vendor contracts to evaluate their ongoing compliance with this procedure and future versions of it.

Links:

• Destruction of Records Procedure
• Data Security Controls Standard

• The Information Steward must approve the retention and archival of University data and records.
• Digital archive storage solutions should follow controls as outlined under section 3.3 Store and Secure.
• Data that is archived must be accessible, usable and readable, with due diligence taken to ensure archived data remains accessible and readable throughout the entire arching period. 

Links:

UQ Information Governance and Management Framework

• Refer to the Destruction of Records Procedure.
• Both the Information Domain Custodian and Information Steward must endorse the destruction of any University records. However, the final approval must be obtained from the UQ Records Manager, as per the Records Destruction Procedure.
• Destruction process and approvals of data records needs to be documented and captured into the Enterprise Document and Records Management System.

Links:

• UQ Information Governance and Management Framework
• Destruction of Records Procedure

 Permitted |  Permitted with caution* |  Permitted with caution for research only*  |  Not permitted

* Risk assessment must be undertaken