[showhide show_caption=”Table of Contents \u00bb\u00bb\u00bb” hide_caption=”Close Table of Contents\u00ab\u00ab\u00ab”]<\/p>\n
1 General information<\/a> [\/showhide]<\/p>\n The Logging Policy of Tallinn University of Technology (hereinafter referred to as \u201cthe university\u201d) has been prepared in accordance with the requirements of the ISO 27001:2022 standard and the university\u2019s Information Security Policy. The purpose of the Logging Policy is to ensure that logs are generated, stored and analysed to support the fundamental principles and objectives of the university\u2019s information security, thereby protecting IT assets and data while ensuring their availability, integrity and confidentiality (and enabling the collection of legal evidence from logs when required).<\/p>\n \u201cLogs\u201d<\/strong> means automatically or manually generated records of actions within a system or application that contain information about operations, events, changes, security incidents and other circumstances.<\/p>\n \u201cLogging\u201d<\/strong> means the process of recording actions, events and changes.<\/p>\n \u201cLog aggregation\u201d<\/strong> means consolidating logs from multiple sources into one central hub, allowing for more comprehensive analysis and monitoring.<\/p>\n \u201cAnomaly detection\u201d<\/strong> means the process of identifying deviations from normal behaviour that may indicate a potential security threat.<\/p>\n The Logging Policy applies to all information systems and IT assets used by the university, including those managed by third parties. The Policy governs the generation, storage and analysis of logs, including exceptional cases, failures, and other critical events. The Policy applies to all components of the information system and persons associated with them, i.e. the university staff, students and third parties. The persons responsible for logging shall ensure that logs are generated, stored, and analysed accurately and securely.<\/p>\n All information systems and IT assets must generate logs in accordance with established requirements and security standards. Logs must be securely stored and kept confidential for a period long enough to help with the investigation and resolution of potential security incidents. Access to logs must be restricted to authorised users who have a legitimate need to know. Logs must be analysed regularly to detect potential security incidents, data breaches and anomalous behaviour. Logs must be protected from unauthorised modification and deletion. The logging configuration must be documented and reviewed regularly to ensure that it is relevant and effective. The log retention period and regulatory requirements for each information system or IT asset are specified in the JIRA Assets module.<\/p>\n The university collects logs from various information and data systems that record the operations, usage, and changes to these systems. Logs must be monitored regularly, and users are prohibited from modifying logs, i.e. access to logs should be read only.<\/p>\n Logging and monitoring tools must comply with the university\u2019s information security standards and be updated regularly.<\/p>\n By consolidating logs from information systems and IT assets into a centralised repository, log aggregation enhances the ability to detect more complex security incidents.<\/p>\n The persons responsible for collecting, storing, and analysing logs must be aware of their responsibilities, and their actions must be documented.<\/p>\n The objective of storing and managing logs is to ensure the transparency and auditability of actions performed within systems and applications, facilitating quick detection of and response to security incidents and use of the logs for other purposes, such as analysis and service continuity.<\/p>\n Log administrators are responsible for contributing to regulatory compliance and audits by supplying the necessary log data. Logs are also used to evaluate and enhance the effectiveness of security measures, thereby supporting proactive security management.<\/p>\n Each event log must contain at least the following data:<\/p>\n \u2022 user ID; o The following standard shall be used: UTC time in ISO8601 format YYYY-MM-DDTHH:mm:ss.SSSZ;<\/p>\n \u2022 input values (e.g. file names, query objects, authentication method); The following events must be logged, unless it is technically impossible and approved as an exception:<\/p>\n \u2022 successful and failed login attempts, incl. failed authentication attempts, and brute-force attacks; Users, including those with privileged access, must not have the right to delete or disable their activity logs, unless it is not technically feasible to impose such restrictions. All log data shall be stored and protected against unauthorised access, and access rights to log data shall be documented in accordance with the IT Asset Access Control Policy.<\/p>\n Log information must be protected from unauthorized modification, whereas:<\/p>\n \u2022 when logs are sent for log aggregation, all log data must be encrypted using protocols such as TLS; The following methods can be used to protect logs:<\/p>\n \u2022 cryptographic hashing; The availability and integrity of the logs must be ensured even in the event of data loss or system failure. Backup log files must be secured using the same security measures as those applied to original log files.<\/p>\n Logs that must be retained for an extended period should be archived in compliance with data and\/or regulatory requirements. The retention periods for the logs are defined for each specific information system or IT asset.<\/p>\n If an organization must send system or application logs to a third party in order to detect errors, any sensitive information should be removed from the logs using data masking techniques if possible. Usernames, IP addresses, hostnames, organization names, and any other unnecessary information should be removed prior to sending logs to a third party.<\/p>\n Log analysis entails examining and interpreting information security events to identify unusual activity or anomalous behaviour that may indicate potential compromise. The Information Security Division of the Information Technology Services analyses the university\u2019s log data. The Information Security Division uses automated tools designed to detect and alert anomalies and potential security incidents.<\/p>\n The results of log analysis must be documented and regularly reviewed to assess and enhance the effectiveness of logging. The results of log analysis are incorporated into the information security risk management process, so that identified risks and vulnerabilities can be effectively evaluated and managed.<\/p>\n The Information Security Manager shall coordinate the implementation, monitoring, and regular review of the Logging Policy. The Information Security Manager conducts regular exercises and tests to validate the effectiveness of logging systems and policies.<\/p>\n Regular monitoring and audits shall be organised by the Information Security Manager to ensure compliance with the requirements of the Logging Policy.<\/p>\n If any non-compliance is detected, corrective measures are taken and documented.<\/p>\n All logging settings and procedures shall be clearly documented and available to authorised persons. The Logging Policy shall be reviewed and updated at least once a year to ensure its relevance and effectiveness.<\/p>\n All university employees and third parties are responsible for implementing and complying with the Logging Policy to ensure the security of the university\u2019s information systems and data.<\/p>\n The Policy must be available to all persons concerned, who should be provided with an overview of the Policy along with necessary training.<\/p>\n The Policy shall be reviewed and updated at least once a year or as necessary to ensure it aligns with the changing regulatory requirements and technological advancements.<\/p>\n","protected":false},"excerpt":{"rendered":" [showhide show_caption=”Table of Contents \u00bb\u00bb\u00bb” hide_caption=”Close Table of Contents\u00ab\u00ab\u00ab”] 1 General information 2\u00a0 Definitions 3\u00a0 Scope of application 4\u00a0 Principles 5\u00a0 Objectives 6\u00a0 Log management 6.1 Log data 6.2 Log events 6.3 Protection of log data 6.4 Log analysis 7\u00a0 Supervision 8\u00a0 Documentation and review 9\u00a0 Implementation [\/showhide] 1\u00a0 General information The Logging Policy of […]<\/p>\n","protected":false},"author":4,"featured_media":0,"parent":8909,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"smart_processes":["https:\/\/smart.taltech.ee\/en\/process\/it-management\/"],"footnotes":""},"categories":[182],"tags":[],"legislation_type":[151],"legislation_approval":[190],"subdivision":[209],"faculty":[],"division":[226],"department":[264],"class_list":["post-10166","post","type-post","status-publish","format-standard","hentry","category-legislation","legislation_type-order","legislation_approval-director-for-administration","subdivision-it-en","division-support-activites","department-information-technology-services"],"acf":{"smart_processes":["https:\/\/smart.taltech.ee\/en\/process\/it-management\/"]},"_links":{"self":[{"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/posts\/10166","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/comments?post=10166"}],"version-history":[{"count":0,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/posts\/10166\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/posts\/8909"}],"wp:attachment":[{"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/media?parent=10166"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/categories?post=10166"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/tags?post=10166"},{"taxonomy":"legislation_type","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/legislation_type?post=10166"},{"taxonomy":"legislation_approval","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/legislation_approval?post=10166"},{"taxonomy":"subdivision","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/subdivision?post=10166"},{"taxonomy":"faculty","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/faculty?post=10166"},{"taxonomy":"division","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/division?post=10166"},{"taxonomy":"department","embeddable":true,"href":"https:\/\/oigusaktid.taltech.ee\/en\/wp-json\/wp\/v2\/department?post=10166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n2\u00a0 Definitions<\/a>
\n3\u00a0 Scope of application<\/a>
\n4\u00a0 Principles<\/a>
\n5\u00a0 Objectives<\/a>
\n6\u00a0 Log management<\/a>
\n6.1 Log data<\/a>
\n6.2 Log events<\/a>
\n6.3 Protection of log data<\/a>
\n6.4 Log analysis<\/a>
\n7\u00a0 Supervision<\/a>
\n8\u00a0 Documentation and review<\/a>
\n9\u00a0 Implementation<\/a><\/p>\n1\u00a0 General information<\/h1>\n
2\u00a0 Definitions<\/h1>\n
3\u00a0 Scope of application<\/h1>\n
4\u00a0 Principles<\/h1>\n
5\u00a0 Objectives<\/h1>\n
6\u00a0 Log management<\/h1>\n
6.1 Log data<\/h2>\n
\n\u2022 name of the information system or IT asset;
\n\u2022 system activities, i.e. including clearly identifiable automated processes;
\n\u2022 authentication and logon\/logoff events: if authentication is performed through a third-party identity management service provider, the event logging is performed and managed in the relevant service logs. These events are not saved in the application\u2019s logs;
\n\u2022 date, time and relevant details of the events.<\/p>\n
\n\u2022 device identification information, system identifier and location;
\n\u2022 the event or action log type or category (e.g. user identification, administration and type details);
\n\u2022 network addresses and protocols;
\n\u2022 correlation ID: to track an event chain;
\n\u2022 session ID: when session-based monitoring is applied.<\/p>\n6.2 Log events<\/h2>\n
\n\u2022 successful and failed attempts to access data and other resources;
\n\u2022 if an application has an administrator interface or other tools for modifying a system configuration, all successful and failed configuration change attempts must be logged. If a configuration change occurs outside the application (e.g., at the server or infrastructure level), the change must be recorded in system administration or infrastructure logs;
\n\u2022 warnings and error messages generated by the information system or IT assets;
\n\u2022 data export and import operations;
\n\u2022 use of privileges;
\n\u2022 files accessed and the type of access, including the deletion of critical data files;
\n\u2022 alerts generated by the access control system;
\n\u2022 enabling and disabling security systems, e.g. antivirus software and intrusion detection systems;
\n\u2022 creation, modification, or deletion of identities, including changes in roles;
\n\u2022 transactions performed by users within applications. These include technical users (applications) performing automated operations.
\n\u2022 log receipt time in the management and processing system;
\n\u2022 use of log management and processing programs and applications.<\/p>\n6.3 Protection of log data<\/h2>\n
\n\u2022 changes to the saved message types should not be allowed;
\n\u2022 it should be ensured that log files cannot be edited or deleted;
\n\u2022 it is essential to prevent the failure to record events or the overwriting of previously recorded events when the log files storage is full;
\n\u2022 all logging settings and procedures must be subject to version control and updated in line with changes in systems and regulations.<\/p>\n
\n\u2022 saving to a read-only file;
\n\u2022 saving to a public transparency file.<\/p>\n6.4 Log analysis<\/h2>\n
7\u00a0 Supervision<\/h1>\n
8\u00a0 Documentation and review<\/h1>\n
9 Implementation<\/h1>\n