At AAU, management must ensure that users and administrators are trained in the IT products they use and/or manage. This is to ensure that a product or system is not used in a way that could lead to potential vulnerabilities in the system.

Therefore, it is good practice to train the employees who are expected to use the system before a new product is put into use.

It should also be considered whether IT support should be involved so that they are prepared to receive questions about the system.

If necessary, it can be considered whether additional awareness training should be carried out afterwards, e.g. annually, so that users continue to have the latest knowledge about the system. Team Security, in collaboration with other stakeholders, ensures that general awareness campaigns about IT security are carried out throughout the university. However, this does not mean that you cannot take the initiative to raise awareness at your specific place of employment if you see a need for it. Team Security is always available for dialog and sparring about awareness.

As the (system) owner of a product, you are not only responsible for the professional handling of the product - you must also ensure that the development, operations and security departments in particular are well trained in the security of and in the product.

Aalborg University provides various tools for its employees.

See the software ITS provides here.

There may also be other areas where a common tool would be beneficial, and Team Security is always ready to enter into a dialog and help with sparring on this.

Aalborg University has developed a data classification that forms the basis for, among other things, operating agreements and security levels. Depending on the classification of a given type of data, there are different rules and requirements for how the data can and must be processed. Generally speaking, the more confidential the information, the better it must be protected. In this context, it is important to remember that confidentiality is not only about whether there is personal data in the system, but also whether it is confidential business information.

It follows from the AAU Security Handbook that all information assets must have a defined owner. This owner is responsible for ensuring that the asset is classified and handled accordingly. It is thus the asset owner's responsibility to ensure that the asset is subject to the security required by the classification.

Work is ongoing to develop and define the role of the system/asset owner so that it is clearly defined what tasks are included in this role and how the role is assigned.

Data minimisation is about just that - minimising the amount of data. It covers everything from the collection, processing and storage of data. In order to comply with the principle of data minimisation, it is important to be able to justify why you have collected data. If you process data where there are no objective and work-related arguments for the data processing, you should stop processing the data.

This also applies to retention periods, so you don't keep data for longer periods than necessary. However, there may also be legal requirements that determine how long data can and must be stored. If there are no such legal requirements, it is important that you have an adequate argumentation for how long you store your data.

It's also worth noting that this principle also applies to log files, which should also be limited to what is necessary. However, log files are also mentioned separately as they are inherently difficult to limit, as they are often used in situations where you don't necessarily know in advance what you're looking for.

Overall, access management is a very central security component of any system. There are many different ways to build access control into systems, and they can vary greatly in complexity. In Aalborg University's central systems, access is managed through Entra ID or Active Directory (AD). When new systems are deployed, it is therefore preferable that they also use Entra ID or AD for user management, as many of the existing processes and procedures can be reused.

The requirements for user account control and access rights management follow the overall classification of the system. As a starting point, a system must, as a minimum, support AAU's general security requirements as defined in the Security Handbook. It is precisely for this reason that integration to AAU's Entra ID or AD is preferable, as it automatically fulfils AAU's security requirements. If a system is not integrated to AAU's Entra ID or AD, or alternatively is administered in AAU's Identity Management System (IDM), separate controls must be carried out with users in this system. In addition, it will be the responsibility of the owner of the system in question to ensure that the system complies with AAU's minimum requirements, including the examples of good practice below.

Good practice:

• All user rights should be reviewed regularly, at least every 6 months.
• Administrator rights are granted solely on the basis of a specific business need and are removed as soon as the need disappears.
• The use of administrator accounts must be limited to what is absolutely necessary.
• The use of service accounts must also be limited to what is absolutely necessary.
• Service accounts must also be customised for the purpose and have the least possible privileges to be able to perform this service.
• Service accounts must be named so that it is clear that it is a system account.
• Users and privileges must be traceable with audit logs.
• Audit logs must always be assessed in relation to whether they should be included in AAU's central log management system.
• There must be a procedure for how rights in the individual system are changed, assigned, revoked and cancelled.

It can often be a good idea to use multi-factor authentication (MFA) for specific systems. There can be a variety of reasons for using this type of protection, and if in doubt, a risk assessment will often clarify the reasons.

Best practice:

• By integrating with Entra ID, systems can utilise an AAU-wide MFA solution.
• Use MFA for data classification higher than "Public Information".
• Consider which type of MFA to use (Microsoft Authenticator, SMS or email with one-time code).

It is a fundamental prerequisite for good security that a user account does not have more rights than required to fulfil a given task. An employee may change task areas many times during their working life, and it is important that a system can support this so that an employee does not accumulate unnecessarily many access rights. It is therefore important to always work on the basis that an account should have as few accesses as necessary to fulfil its tasks.

Good practice:

• Set up access based on the principle that no one should have access in the first place.
• Employees should not have administrator rights on their work computers.
• Ensure that files and folders are only accessible to accounts that have a business need to access them.
• Services/integrations should use accounts that are customised for the purpose and have the least amount of privileges to be able to perform this service. This also applies to database accounts used in applications, etc.
• Set restrictions for guest access, students and the like.
• Use audit logging to ensure traceability is intact, especially for administrator accounts and other accounts with special and additional privileges.
• Permissions should be structured so that a user cannot see more than they need to. There must be appropriate shielding of data.

It should always be considered whether individual accounts should be used for different purposes to avoid an unnecessary accumulation of user rights. Accounts should therefore be divided based on the individual requirements of the business system, as well as according to access management in the AAU Security Handbook.

Best practice:

• Centrally manage access to the functions of the different business systems (e.g. in IDM).
• Consider exactly what data should be accessible to a specific user function and build and assign rights accordingly.
• User rights must be constructed so that, as a starting point, only read access is granted, and additional rights such as write and delete can only be granted if there is a work-related need.

When building systems, it is essential that there is a logical separation of development, test and production data. This is done both to ensure that errors in the development and test environments are not transferred to the production environments, but also because there may be a significantly different security setup for test and development environments.

Production data must therefore not be used in development and test environments unless it can be documented that data in these environments is subject to the same security as in the production environment. This also applies to user and rights management, which must ensure that the people working in the test and development environments do not have access to more data than absolutely necessary, cf. the principle of data minimisation. Access to the development and test environment must therefore be subject to the same level of security as the production environment if there is sensitive personal data or production data in the environment.

The use of data in the different environments must therefore be considered according to the classification with which the data is labelled.

Best practice:

• There should always be separate environments for operations, development and testing.
• Using automated deployment/deployment that follows predefined processes and procedures can help increase the security of the development process.
• Developers should not have access to the production environment, as it is rarely possible to restrict their access in this environment.
• If possible, reference architecture should be used, as this can increase the certainty that the right architectural choices are made.
• As a rule, production data should not be used in the test and development environment.

Equipment provided by AAU follows the minimum requirements defined in the Security Handbook, among others. These computers are managed by ITS and are therefore continuously updated to comply with the applicable security requirements. However, it is still the employee's responsibility to contact ITS if they experience irregularities on the computer. It is also the employee's responsibility to ensure that the computer is switched off at regular intervals so that any updates can be carried out.

At AAU, it is natural for employees to use their own devices, known as "bring your own device" (BYOD). This is an important option to have, but it also introduces a number of security challenges as they are not controlled by ITS. This means there can be challenges with lack of updates, lack of encryption, lack of logging and traceability.

It is therefore important to consider the necessity of using a device that is not provided by AAU. Where possible, the use of BYOD devices should be kept to an absolute minimum, and if they are used, it should be done in a way that recognises the potential risks that such a device brings.

Best practice:

• Employees should use computers that are managed by ITS so that software is updated regularly.
• On all AAU computers, ensure that there is antivirus protection, automatic updating and monitoring from ITS.
• On the client side, use a software firewall that is an integral part of Windows, macOS and Linux.
• Consider disabling Powershell in Windows if it is not used on a daily basis by the user.
• Ensure that all employee computers have full disc encryption. Decryption keys should be stored centrally.

It's a well-known phrase that nothing is 100% secure. Therefore, the best recommendation is to use multiple layers of protection as it reduces the chances of successful attacks. These layers should also be spread across different efforts, which in the NIST framework is defined as the ability to "Identify, protect, detect, respond and recover". The ideal scenario is to have implemented security measures in all five of these categories. However, this can be a daunting task, so below are some specific areas to focus on.

A Configuration Management Database (CMDB), which is a kind of inventory of your IT environment and asset lists, will be supportive tools when uncovering potentially vulnerable systems. There are various lists and databases of this nature in AAU, and work is ongoing to consolidate these.

Good practice:

• That a risk assessment is in place that sets the framework for the security level of the system.
• Ensure that patches are always applied at both the OS level and application level, and where possible and appropriate, this process should be automated.
• Constantly consider whether there are applications that are unnecessary to use and remove them to minimise risk.
• The system owner should ensure that there is a responsible person who continuously monitors what security patches are released by the vendor and assesses how and how quickly a patch should be implemented.
• It is important that there are fixed procedures in place to ensure that a decision has been made on how long it will take from the release of a patch until it is implemented.

These points also apply to any development and test environments.

It's important to recognise that the threat landscape is constantly changing, which is why vulnerabilities and threats must be reassessed on an ongoing basis. It's rarely enough to conduct one risk assessment and then not reassess the system. It's a continuous process, where it must be ensured that action plans are followed up on and that the measures required by a risk assessment are implemented.

There can be many sources of information about threats and risks, and it is important that the owner of the system is continuously informed about these so that action can be taken if a vulnerability emerges.

The Security team works with the sector threats as well as the risk assessments.

Best practice:

• It is important to continuously stay updated on the current threat landscape in order to stay ahead of vulnerabilities.
• A risk assessment should be revisited at least once a year or if the need arises through changes to the system.

Equipment provided by AAU must be covered by centrally managed malware/end-point protection. Data from these is used in connection with the university's SIEM and SOC solutions. AAU uses MS Defender, Jamf Protect and Tenable.io agent.

Good practice:

• Antivirus/end-point protection must be in place on all devices including servers.
• Ensure installation of security updates and patches.
• There must be system functionality to ensure that suspicious links in emails are blocked automatically.

System monitoring helps maintain daily operations, capacity management and IT security. Anomalies can be detected using the university's SIEM systems. This can be used both for monitoring operational stability, but also for monitoring and detecting security incidents. This monitoring work is to some extent gathered in Team Security, and it is therefore always possible to enter into a dialogue about system monitoring of relevant systems.

Good practice:

• If applicable, it is important to have relevant logs delivered to the university's SIEM systems.
• It is therefore a good idea to enter into a dialogue with Team Security about possible misuse scenarios and breakdown scenarios so that alerts can be set up.
• Define who should respond to alerts and create contingency plans in case a security incident or disruption occurs.

At AAU, all services provided centrally must have backup and restore functionality. There can be many different scenarios and situations where it is necessary to be able to restore something as a result of user error, system failure, ransomware or crash.

It is important to ensure that you have considered how quickly data may need to be restored and have tested this in a contingency test. Depending on how critical a backup is, there may be many different security considerations to take into account, such as whether the backup should be located in a different physical location, whether it should be cut off from network access, etc.

Best practice:

• Test backups regularly. Perform restores of the backups to ensure that what you restore also provides the functionality you expect from the product.
• Back up business-critical data daily. Other operational data at least weekly. The frequency is determined by the importance/data classification.
• Automate the backup function.
• Ensure that recovery has an acceptable time horizon according to the system's importance level, which should also be tested during recovery.
• Depending on the criticality assessment, consider whether backups should be stored off-site so that ransomware cannot spread there.

If applicable, new products should be implemented in the current contingency plan. The current contingency plan is maintained by ITS.

The system owner should ensure that there is a contingency plan for the system in question if the classification of the system dictates this. Depending on the classification, it may also be relevant to perform tests of the contingency plan.

Good practice:

• If there is data in the system that cannot be dispensed with, it is necessary to have a backup of all data. See section 4.4.
• Make sure you have documentation for the recovery of critical systems.
• Tests of the contingency plan must be carried out so that you have an overview of any errors and deficiencies. These can be corrected on an ongoing basis to ensure a robust contingency plan.
• For critical systems, it is important to test the restore speed so that you are prepared for whether the time required is acceptable or whether additional measures need to be implemented.
• The contingency plan must be continuously evaluated and improved, and ownership of this process must be strong and firmly anchored.

Log data is used in Team Security to monitor security incidents, operational stability, and to investigate security incidents. In addition, log data is used in many different places in AAU for various tasks. Overall, one of the most important tasks is to log the amount of information that is needed, but no more than that. When purchasing new systems, it is therefore important to consider whether there is log data in the system that could benefit from being transferred to the central log management platform (SIEM platform). This also ensures a decoupling from the source system, which helps to increase the security of the log.

It's important to realise that log management is not just a big black hole, but a major asset in daily operations. It can be used for capacity management, analysing and troubleshooting, and much more. It is therefore important to always consider whether the log from your system could be relevant to collect centrally. This is a dialogue that Team Security would love to enter into and discuss.

Best practice:

• Always consider whether the log from your system could be relevant to others, both from a security and operational perspective.
• If the log is relevant, assess which parts of your system it makes sense to monitor and set up alarms on this monitoring.
• Keep the alarm level at a level that ensures you don't get flooded with less important alarms and lose sight of the important alarms.
• Activate all logs, but only as part of the process of deciding which ones to keep.
• It can be useful to ensure that there is a uniform extraction of data and that it complies with the CIM model.

It is important to have a change log for your systems, as there may be situations where a change has introduced an error and you need to be able to find the point in time when the error was introduced. There are several different systems that can support this process, and it will often differ from system to system. The most important thing is that a change log exists and that it is complete and accurate.

Good practice:

• Ensure that the change log contains all the relevant information that is needed for future troubleshooting, for example.
• Have clear goals.
• Choose the right tool.
• Train staff.

All products must have a documented process for service and service windows, and the ITS CAB is informed of these service windows.

Good practice:

• Document ordinary / regular service windows.
• Document extraordinary / urgent / emergency service windows.
• Document standard changes that can be made without individual approval.
• Document the sign-off strategy, platform.

In general, segmentation of networks and services on the network must be maintained. This segmentation must also be maintained when implementing new products, and it is the responsibility of the owner of these products to enter into a dialogue about how to ensure this in the most appropriate way.

It is also the owner's responsibility to consider what methods the users of the new asset can use to access the asset at the network level. It is important that there must be some form of authentication of the users for the network services.

Best practice:

• Separate students, guests and employees on both the wired and wireless network.
• Use ACL and VLAN or similar technologies to create logically separated traffic.
• Use whitelisting for network access. Consider creating a positive list where everything else is prohibited.
• Ensure that sensitive systems are separated from less secure systems.
• Pay particular attention to systems that process sensitive personal data, as there may be special requirements for these systems.

When it comes to best practice for a platform, it can be very diffuse and it can be difficult to recognise what the best best practice is. Many suppliers often state their own best practices for the product, which can be beneficial to follow. Sometimes it is also possible to seek inspiration from third parties, for example in community groups. An important source of best practice can also be found in the experience gained at AAU if the system is known or has been used previously.

When introducing new systems/products or major changes to existing systems, a formal change process should always be followed. This process should generally cover the following areas: documentation, requirements specification, testing, quality control and implementation. When testing a system, there are many different methods, each with different goals and outcomes. It is therefore important to choose the test that is relevant to what you want to investigate. Examples include load testing, stress testing, UAT (user acceptance testing), penetration testing, etc. Because they each produce different results, it is therefore important to be clear about what you want to investigate before initiating a test.

Good practice:

• It's important to follow a well-defined plan of action, including making sure you define your scope and the scenario you want to analyse.
• There should be a usable result of the test, such as a report.
• If relevant, it may be necessary to utilise an independent review of code, requirements, etc.

One method of uncovering vulnerabilities in a given production environment can be penetration testing, and these tests are usually divided into two categories: whitebox and blackbox. In a known (whitebox) test, there is information about the system, including which environments exist, which components the production consists of, etc. Opposite this is an unknown (blackbox) test, which is pure hacking on the part of the tester, where they have no prior knowledge of the system they are hacking. As with the above, different types of tests produce different results, so it's important to choose the test that is right for the system in question.

These tests can be performed on on-premises services as well as cloud services.

Good practice:

• If deemed necessary for the system, either a whitebox or blackbox penetration test should be conducted.
• During a penetration test, you should "monitor" your system to ensure that there is no continuous lowering of security levels.
• Vulnerability scans can also be conducted, which are less intrusive than a penetration test.

As a public institution, Aalborg University is subject to several different types of legislation. It is therefore important as an asset owner to be aware of which laws and regulations apply to your system. One of the most well-known legislations is GDPR, which a system is subject to if it contains personal data. Similarly, there is legislation in the areas of finance and research. The vast majority of areas are regulated by legislation, and it is therefore important to be aware of what applies to your system, as there can often be a number of requirements that you need to comply with.

Good practice:

• Ensure that you comply with current legislation relevant to the system in question.
• If you are unsure of which legal requirements you are subject to, you can contact the Contracts Unit.

Depending on the asset, there may be different requirements for the controls that an asset may be subject to. Often these are requirements resulting from legislation, but they may also be requirements from the business, an IT audit or a certification body. Once the various requirements have been identified, the control must be performed, documented and acted upon if necessary.

It is the owner of the asset who is responsible for ensuring that the check is carried out. The owner does not necessarily have to carry out the verification, and it may be delegated to an authorised person, but the responsibility will still remain with the asset owner.

Good practice:

• Always check whether there is a requirement for checks on a given asset.
• The checks often need to be carried out at a fixed time interval, so it is important to have system support for this task so that a reminder is automatically sent out when the check is due.
• The result of the check must be logged in Workzone.
• If the result of the check meant that an action had to be taken, this action must also be documented, including when it was carried out.

A Logging Event should, if applicable, contain the following information:

• User ID(s)
• System activities
• Date/time timestamp(s)
• Information about important events, e.g. logon or logoff
• Device identity and/or location
• System identification
• Information about successful/rejected access attempts to the system
• Information about successful/rejected access attempts to data or other resources
• System configuration changes
• Use of privileges/permissions
• Use of system tools or applications
• File(s), access and type of access
• Network addresses and protocols
• Activation or deactivation of protection systems, e.g. antivirus or intrusion detection system
• Information about transactions carried out by the user in applications
• Alarm triggered by access management system

These logs may contain sensitive, personal and/or confidential information. Therefore, appropriate measures should be taken to protect these logs.

AAU, Aalborg University

AD, Active Directory

AV, Antivirus

BP, Best Practice

BYOD, Bring Your Own Device

CAB, Change Advisory Board

CIA, Confidentiality Integrity Availability

CIM, Common Information Model

CMDB, Change Management Data Base

GDPR, General Data Protection Regulation

IdM, Identity Management

IDS, Intrusion Detection System

ISO, International Standard Organisation

ISU, Information Security Committee

ITS, IT Services

ITSM, IT Service Management

ITIL, IT Infrastructure Library

MDM, Mobile Device Management

MFA, Multi Factor Authentication

NIST, National Institute of Standards and Technology

SIAM, Service Integration And Management

SIEM, Security Information and Event Management

SLA, Service Level Agreement

SOC, Security Operational Centre

UAT, User Acceptance Test

VPN, Virtual Private Network