Operations Security Policy (A.12)

Operating procedures for information processing facilities must be documented and made available to staff who need them (12.1.1)
Units must assume the role of system owner and ensure that operational procedures are in place for the systems and infrastructure for which they are responsible, to the extent that these assets are generally defined as critical in accordance with the applicable risk assessment or specifically defined as Type A systems. System ownership must be carried out in accordance with the University’s IT governance model (medarbejdere.au.dk/strategi/itgovernance).
The system owner is responsible for ensuring that operational procedures are carried out to a standard that provides the necessary operational and information security. Generally speaking, operating procedures must be archived securely, be documented, kept up to date and made available only to persons with relevant operational responsibilities or a legitimate business need.
If responsibility for assets is shared between several units at Aarhus University, it is the responsibility of the unit with system ownership to 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 entities. Such arrangements regarding the allocation of responsibilities must be set out in a system management agreement between the entities.

Changes to information processing facilities and information systems must be subject to change management procedures (12.1.2)
All units responsible for systems and infrastructure must have a procedure in place for managing changes to them. This is to ensure the ongoing management and risk assessment of the impact of changes on operational and information security. This procedure should be designed in accordance with ITIL or another recognised methodology.

The use of resources must be monitored and adjusted in line with current and anticipated capacity requirements (12.1.3)
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must ensure the following for them:

• Dimensioning and customisation to meet capacity requirements and needs.
• Regular capacity monitoring as needed and to the extent necessary to ensure reliable operation and availability. The form monitoring takes must reflect the overall criticality of the asset and system classification (where relevant), and support the necessary documentation of the systems’ availability.
• Registration of significant disruptions and irregularities in operations.

Development, testing and production environments must be separated and secured (12.1.4)
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must ensure the logical or physical separation of development and test environments from the production environment in order to prevent unauthorised access to or changes in the production environment.
In this context, the migration from development to production must also undergo testing and verification to ensure an adequate level of operational and information security, as well as usability, prior to implementation. Approved software must be protected against unauthorised subsequent modification and, where possible, only object code—and not source code—should be migrated to the production environment.

Protection against malware must be implemented and supported by appropriate user awareness (12.2.1)
Units responsible for systems and infrastructure must, where possible and necessary, ensure the installation of and provide guidance on antivirus protection, defined as a tool for the effective detection and prevention of malware. Exceptions may include laboratory setups without an internet connection or segmented networks, provided that their isolation safeguards the university’s other operational and information security against threats such as the spread of malware.
Security measures to prevent malware on equipment must be implemented in accordance with the applicable risk assessment. In addition, servers must be configured so that only the necessary services are available.  This will typically be achieved by disabling unnecessary functions and limiting access with firewalls. Work stations must also be secured before use. At a minimum, this involves installing the latest security patches for the operating system and applications, as well as antivirus protection.

Backups of information, software and systems must be maintained and tested regularly in accordance with the agreed subject-specific backup policy (12.3.1)
AU’s subject-specific backup policy stipulates that units responsible for IT systems must ensure that data stored on IT equipment is backed up and stored in a manner that is adequate in terms of capacity and security, in accordance with the applicable risk assessment. Where responsibility is shared between several units, planning must be carried out in collaboration with the relevant system owners and documented in system management agreements.
Backups, backup copies and redundant systems must be located in such a way that any incident at the primary site cannot affect the secondary site.
The ability to restore data from backup solutions must be tested regularly. Furthermore, recovery must be tested following any system or process changes that may affect the backup solution.
This policy sets out the minimum requirements for backups. Some units may impose stricter requirements.

Logs recording activities, exceptions, errors and other relevant events must be created, stored, protected and analysed (12.4.1, 12.4.2 and 12.4.3)
Units responsible for data logging must ensure that users are adequately informed about the scope and purpose of the data logging measures in place.

Use of log files
It is not permitted to use log files to track the actions of individual users, unless this is for the purpose of troubleshooting and rectifying errors at the user’s own request, or in the case of reports concerning illegal activities, alerts from antivirus/antispam or similar security systems, or where there is reasonable suspicion of unauthorised behaviour. This means that AU IT does not compile records of individual users’ activities and does not assess whether individuals’ activities are relevant to their work at AU.
If there is a need to monitor an individual’s behaviour, permission must first be obtained from the individual themselves (e.g. when responding to alarms) or from their immediate superior (e.g. in cases of reasonable suspicion of unauthorised behaviour, cf. policies, legislation, etc.).
AU IT is authorised to use log files for the following purposes:

• Statistics on things like email, internet and network traffic to and from AU.
• Statistics on things like the use of certain programmes or certain types of network traffic.
• Statistics relating to a division at AU, e.g. a department/school/centre or an administrative division, provided that the data does not make it possible to identify individuals.
• Troubleshooting and alerts.
• Follow-up on security incidents.

Logging facilities and log data must be protected against tampering and unauthorised access (12.4.2)
All units responsible for logging must ensure that logging facilities and log data are protected against tampering, technical errors and unauthorised access.

Activities performed by the system administrator and system operator must be logged, and the log must be protected and reviewed regularly (12.4.3)
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must ensure sufficient actions performed by users with administrator rights are logged. Such logs must be reviewed on a random basis at intervals of at least three months and in accordance with the applicable risk assessment.

Networks, systems and applications must be monitored for abnormal behaviour, and appropriate measures must be taken to assess potential information security incidents
At Aarhus University, a security incident is defined as any incident that impacts confidentiality, integrity or availability.
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must ensure that information about access and attempted access, as well as abnormal behaviour and potential security incidents, is logged and monitored. This must be performed in compliance with the applicable risk assessment and the necessary alerts and tracking of unauthorised activity and security incidents. Where this gives rise to a need to implement appropriate measures, the unit must ensure that this is done.
The error logging procedure must be designed with a view to the affected systems’ requirements for analysis, rectification and preventive measures.
The audit logging procedure must be designed to meet the requirements of the systems concerned for the tracking and analysis of security incidents.
As a general rule, logs of security and error events must be kept for at least three months.

The clocks in the information processing systems used by the organisation must be synchronised with approved time sources. (12.4.4)
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must ensure that they keep time accurately. Where possible, automatic time synchronisation from a recognised time server should be used; in other cases, time settings must be checked and corrected as frequently as necessary.

Procedures and measures must be implemented to ensure the secure management of software installation in test and production systems (12.5.1)
This means that units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must implement such procedures and measures to ensure the secure management of software installation.
Software installation carried out by users on user devices: As a general rule, units assume responsibility for operational and information security on the basis of a risk-based approach if users install software that has not been approved by a central provider at Aarhus University. This includes responsibility for carrying out the necessary risk assessment and licence management.

Information must be gathered regarding technical vulnerabilities in the information systems used; the organisation’s exposure to such vulnerabilities must be assessed; and appropriate measures must be implemented. (12.6.1 and 12.6.2)
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must stay informed about relevant security patches for them. The responsible unit must ensure that such systems and infrastructure are installed on servers, workstations and other equipment within the relevant operational systems in accordance with the applicable risk assessment.
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must ensure that security testing procedures are designed and carried out in accordance with a risk-based approach and in compliance with the following minimum requirements:

• The security level of externally accessible network equipment and servers must be tested at least four times a year using an appropriate combination of automated and manual tests.
• A security test of internal security measures, restrictions, limitations and network connections must be carried out at least twice a year. The security test may include both automated scans and manual inspections.
• Similarly, information on technical vulnerabilities must be obtained from relevant sources at least twice a year. Identified vulnerabilities must be evaluated and risk-assessed without delay, after which they must be addressed in accordance with established task prioritisation processes.

Audits and other assurance activities involving the assessment of test and production systems must be planned and agreed between the person conducting the test and the relevant management team. (12.7.1)
Units responsible for systems and infrastructure that are generally defined as critical in accordance with the applicable risk assessment, or specifically defined as Type A systems, must ensure that audit requirements and activities are planned in such a way as to minimise the impact on relevant business processes.
The providing unit must ensure that systems and infrastructure provided across units at Aarhus University comply with agreed change management processes. These processes must be organised in accordance with ITIL or another recognised methodology, enabling changes to be submitted, approved and incorporated into cross-organisational planning of service windows.

As an employee, you must safeguard work-related data by performing regular backups, for example by storing data on one of the university’s network drives. This ensures that data can be recovered if it has been deleted or overwritten, a hard drive has failed, or a computer has been stolen.

• • AU’s servers and network drives are backed up, and as a general rule, all data should be stored on AU’s servers.
• • If data cannot be stored immediately on secure servers (e.g. data collected in the field or whilst calculations are being carried out), AU staff members are obliged to ensure that the data is stored at the earliest opportunity.
• • Social networks such as Facebook, Twitter, Google+ and others are not private and are not secure. Only information that can be made available on AU’s public websites (i.e. in the lowest classification category) may be shared via social media.