Here you will find the current policy for operational reliability concerning equipment, information, and software managed by AU IT.
The objective of Aarhus University’s policies and rules for Operations Security Policy is to:
ensure the correct and secure operation of information processing facilities
ensure that information and information facilities are protected against malware
protect against data loss
record incidents and provide evidence
ensure the integrity of operating systems
prevent exploitation of technical vulnerabilities
minimize the impact of audit activities on operating systems
Operational procedures for information processing facilities shall be documented and made available to employees who require them (12.1.1)
Units shall assume the role of system owner and ensure the establishment of operational procedures for the systems and infrastructure for which they are responsible, insofar as these assets are generally defined as critical according to the current risk assessment or specifically defined as Type A systems.
The fulfilment of system ownership responsibilities shall be based on the university’s IT governance model (medarbejdere.au.dk/strategi/itgovernance).
Among other things, it is the system owner’s responsibility to ensure the management of operational procedures to an extent satisfactory for maintaining the required operational and information security. Operational procedures shall generally be securely stored, documented, kept up to date, and only made available to individuals with relevant operational responsibility or a work-related need.
If the responsibility for assets is shared between several units at Aarhus University, the unit with system ownership responsibility shall ensure a clear division of responsibilities regarding operational and information security. This applies, for example, in cases where the role of system owner for a Type A system and the operational responsibility for its underlying hardware and software components are not held by the same unit. Such divisions of responsibility shall be documented in a system management agreement between the units.
Changes to information processing facilities and information systems shall be subject to change management procedures (12.1.2)
All units responsible for systems and infrastructure shall have a procedure for managing changes to them, in order to ensure continuous control and risk assessment of how such changes affect operational and information security. The process should be organised in accordance with ITIL or another recognised framework.
Use of resources shall be monitored and adjusted in line with current and projected capacity requirements (12.1.3)
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall ensure the following for these assets:
Sizing and adjustment according to capacity requirements and needs.
Ongoing capacity monitoring as required and to an extent sufficient to ensure reliable operation and availability. Monitoring shall reflect the general criticality and classification of the asset and support the necessary documentation of system availability.
Logging of significant disturbances and irregularities in operations.
Development, test, and production environments shall be separated and secured (12.1.4)
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall ensure logical or physical separation of development and test environments from the production environment to prevent unauthorised access to or modification of the production environment.
Furthermore, migration from development to production shall be subject to testing and control to ensure an adequate level of operational and information security as well as usability before implementation. Approved software shall be protected against unauthorised subsequent modification, and, where possible, only object code—not source code—shall be migrated to the production environment.
Protection against malware shall be implemented and supported by appropriate user awareness (12.2.1)
Units responsible for systems and infrastructure shall, to the extent necessary and possible, ensure the installation and user guidance for antivirus protection, defined as tools for the effective detection and prevention of malware.
Exceptions may apply to laboratory setups without internet connectivity or segmented networks whose isolation ensures that the university’s overall operational and information security cannot be compromised, e.g. through malware propagation.
Security measures to prevent malware on equipment shall be planned according to the current risk assessment. Servers shall be configured so that only the necessary services are available—typically through disabling unnecessary functions and restricting access via firewalls. Workstations shall also be secured before use. As a minimum, this includes installing the latest security patches for operating systems, applications, and antivirus protection.
Backup of information, software, and systems shall be maintained and tested regularly in accordance with the agreed subject-specific backup policy (12.3.1)
Aarhus University’s subject-specific backup policy stipulates that units responsible for IT systems shall ensure adequate capacity and security for the storage and backup of data on IT equipment, in accordance with the current risk assessment. Where responsibility is shared between multiple units, planning shall take place in cooperation with relevant system owners and be documented in system management agreements.
Backups, safety copies, and redundant systems shall be located so that incidents at the primary site cannot propagate to the secondary site.
The ability to restore data from backup solutions shall be tested regularly. Restoration shall also be tested after any system or process changes that could affect the backup solution.
This policy defines the minimum requirements for backup; stricter requirements may be applied locally.
Logs recording activities, exceptions, errors, and other relevant events shall be produced, retained, protected, and analysed (12.4.1, 12.4.2, 12.4.3).
Units responsible for logging shall ensure that users are adequately informed about the scope and purpose of the implemented logging.
Use of Log Files
It is not permitted to use log files to track the actions of individual users unless this is done for troubleshooting or error correction at the user’s own request, or in connection with reports of illegal activities, alerts from antivirus/antispam or similar security systems, or in cases of reasonable suspicion of unauthorised behaviour.
Accordingly, AU IT does not produce overviews of individual users’ activities and does not assess whether an individual’s actions are relevant to their work at Aarhus University.
If there is a need to trace an individual user’s actions, prior authorisation must be obtained either from the user themselves (e.g. in follow-up to alerts) or from their immediate manager (e.g. in cases of substantiated suspicion of unauthorised activity, in accordance with policies, laws, and regulations).
AU IT may use log files for the following purposes:
Compiling statistics on, for example, email, internet, and network traffic to and from AU.
Compiling statistics on the use of specific programs or types of network traffic.
Producing statistics related to subsets of AU (e.g. a department, centre, or administrative area), provided that individual users cannot be identified from the data.
Troubleshooting and alerting.
Follow-up on security incidents.
Logging facilities and log information shall be protected against tampering and unauthorised access (12.4.2).
All units responsible for logging shall ensure that logging facilities and log data are protected against manipulation, technical errors, and unauthorised access.
Activities performed by system administrators and system operators shall be logged, and such logs shall be protected and reviewed regularly (12.4.3).
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall ensure that all actions performed by users with administrative privileges are logged. Such logs shall be reviewed on a sample basis at least every three months and in accordance with the applicable risk assessment.
Networks, systems, and applications shall be monitored for abnormal behaviour, and appropriate actions shall be taken to evaluate potential information security incidents.
At Aarhus University, a security incident is defined as any event affecting the confidentiality, integrity, or availability of information or systems.
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall ensure the logging and monitoring of information on access and access attempts, abnormal behaviour, and potential security incidents.
This monitoring shall be organised according to the current risk assessment and ensure the necessary alerting and tracing of unauthorised activities and security incidents.
Where such monitoring reveals the need for remedial action, the responsible unit shall ensure that appropriate measures are implemented.
Error logging shall be arranged to support the affected systems’ needs for analysis, remediation, and corrective action.
Audit logging shall be arranged to support the systems’ needs for tracking and analysing security incidents.
Logs of security and error events shall generally be retained for at least three months.
Clocks of information processing systems used by the organisation shall be synchronised with approved time sources (12.4.4).
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall ensure that accurate time is used. Preferably, automatic time synchronisation shall be implemented using a recognised time server; otherwise, time settings shall be checked and corrected regularly as necessary.
Procedures and measures for the secure management of software installation in test and production systems shall be implemented (12.5.1).
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall implement such procedures and measures for the secure management of software installation.
Regarding software installation performed by users on their own devices:
Units assume operational and information security responsibility on a risk-based basis if users install software not approved by a central provider at Aarhus University. This includes responsibility for conducting the necessary risk assessment and managing software licences.
Information about technical vulnerabilities in the information systems in use shall be obtained, the organisation’s exposure to such vulnerabilities evaluated, and appropriate measures implemented (12.6.1 and 12.6.2).
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall remain informed about relevant security updates. The responsible unit shall ensure their installation on servers, workstations, and other equipment within the relevant operational environments, in accordance with the current risk assessment.
Units responsible for such systems shall also ensure that security testing is organised according to a risk-based approach and in line with the following minimum requirements:
The security level of externally accessible network equipment and servers shall be tested at least four times per year using an appropriate combination of automated and manual testing.
At least twice per year, internal security controls, restrictions, and network connections shall be tested. Such security testing may include both automated scans and manual inspections.
At least twice per year, information about technical vulnerabilities shall be obtained from relevant sources. Identified vulnerabilities shall be promptly evaluated and risk-assessed, after which they shall be managed according to the applicable task prioritisation processes.
Audits and other assurance activities involving the assessment of test and production systems shall be planned and agreed upon between the party conducting the test and the relevant management (12.7.1).
Units responsible for systems and infrastructure that are generally defined as critical according to the current risk assessment or specifically defined as Type A systems shall ensure that audit requirements and activities are planned to minimise the impact on relevant business processes.
Systems and infrastructure provided across units at Aarhus University shall be covered by agreed Change Management processes established by the providing unit. These processes should be organised in accordance with ITIL or another recognised framework, ensuring that changes can be reported, approved, and included in cross-organisational planning of service windows.
As an employee, you must ensure that work-related data is securely backed up on a regular basis — for example, by storing data on one of the university’s network drives. This ensures that data can be restored if it has been deleted or overwritten, if a disk fails, or if a computer is stolen.
AU’s servers and network drives are included in the university’s backup procedures, and as a general rule, all data should be stored on AU’s servers.
If data cannot immediately be stored on secure servers (for example, data collected in the field or generated during computations), AU employees are required to ensure that such data is transferred to secure storage at the earliest opportunity.
Social networks such as Facebook, Twitter, and Google+ are not closed or secure environments. Only information that may be made publicly available on AU’s official websites (i.e., in the lowest classification category) may be distributed via social networks.