Log Management Best Practices in Cloud Based Software Development Lifecycle, Expert Analysis

Piia Alavesa LOG MANAGEMENT BEST PRACTICES IN CLOUD BASED SOFTWARE DEVELOPMENT LIFECYCLE, EXPERT ANALYSIS JYVÄSKYLÄN YLIOPISTO INFORMAATIOTEKNOLOGIAN TIEDEKUNTA 2024 TIIVISTELMÄ Alavesa, Piia Lokinhallinnan parhaat käytännöt pilvipohjaisen ohjelmistokehityksen elinkaaressa, asiantuntija-analyysi Jyväskylä: Jyväskylän yliopisto, 2024, 76 s. Kyberturvallisuus, pro gradu -tutkielma Ohjaajat: Koskelainen, Tiina (Jyväskylän yliopisto) ja Karttunen, Juha (Metso Oyj.) Lokit ovat tärkeitä, koska ne kertovat järjestelmän tilasta, ja niiden avulla voidaan tunnistaa minkä tahansa tyyppiset kyberhyökkäykset tai luoda tietopohjainen kuva käyttäjien työtavoista. Monet viimeaikaiset lait ja standardit pakottavat lokinhallintaan. NIS2 direktiivi pakottaa tietyt valmistajat huomioimaan lokinhallinnan ja -käsittelyn ohjelmistokehitysprosessin vaiheissa. Ohjelmistohallinnan automaatiota tulisi edistää myös standardien IEC 62443 ja ISO 27001 mukaisesti. Tämä sisältää lokinhallintatyökalujen ja työkaludokumentaation, lokinhallintatoimintojen teknisen ohjeistuksen ja tiedon jakamisen lokinhallintahenkilöstölle. ISO 27001 jopa mainitsee yhdeksi menetelmistään sen, että turvallinen SDLC tulee määrittää ja käyttöönottaa. Kohdeorganisaatio toimii globaalin ohjelmistokehityksen (GSD) kontekstissa, jossa työtä tehdään useassa paikassa samanaikaisesti. Siksi on vielä tärkeämpää, että tietoturvavaatimuksista ollaan tietoisia ja käytetään sertifiointia. Nämä ovat mahdollisia keskittämällä lokinhallintaa esimerkiksi työkaluilla kuten keskitetyllä lokinhallinnalla (CLM), sovituilla menettelyillä ja rakentamalla monet lokinhallinnan edellyttämistä toiminnoista pilvialustaan. Tutkimusmenetelmänä on asiantuntija-analyysi laadullisin haastatteluin ja kyselyin kuudelle asiantuntijalle, joilla on usean vuoden kokemus aihealueesta. Tutkimus kerää asiantuntijoiden näkemykset lokinhallinnan parhaista käytännöistä huomioiden myös lainsäädännön, standardit ja kirjallisuuskatsauksen sekä artikkelit aiheesta. Kerätty materiaali analysoitiin koodaamalla ne ohjelmistokehitysprosessin, työkalujen, lokeihin liittyvien vaatimusten ja toimintojen pohjalta induktiivisesti. Tämä tutkimus päättelee, että lokinhallintatoimintojen tulee perustua ohjelmistokehityksen elinkaareen (SDLC). Keskittymällä ratkaisujen rakentamisprosessiin voidaan varmistaa, että rakennettava tuote on laadukas. Jokainen asiantuntija oli samaa mieltä, että hyvin määritelty pilviarkkitehtuuri auttaa varmistamaan, että monet lokeihin liittyvät vaatimukset käsitellään oikein. Yhtä tärkeää on määrittää standardoidut lokinhallintaprosessit työskentelytavoiksi, kuten lokitarkastuksiksi, turvallisten koodauskäytäntöjen, kuten OWASP:n (Open Worldwide Application Security Project) noudattaminen ja SDLC-prosessia tukevien työkalujen, kuten Jiran, käyttö työn organisointiin ja seurantaan. Avainsanat: lokinhallinta, SDLC, pilvialusta, asiantuntija-analyysi ABSTRACT Alavesa, Piia Log Management Best Practices in Cloud Based Software Development Lifecycle, Expert Analysis Jyväskylä: University of Jyväskylä, 2024, 76 pp. Cyber Security, Master’s Thesis Supervisors: Koskelainen, Tiina (Jyväskylän yliopisto) and Karttunen, Juha (Metso Ltd.) Logs are important because they inform about the system health and can be used to identify any type of cyber-attacks or give a data-based overview of users’ ways of working. Recent legislation and standards enforce log management. NIS2 directive forces certain manufacturers to take logging procedures into software development process’ phases. Software management automation should be promoted as defined in standards IEC 62443 and ISO 27001. This covers distribution of log management tools, technical guidance in log management and delivering the needed data to the log management personnel. ISO 27001 even mentions one of its controls being that the secure development lifecycle should be established and applied. The target organization of this study operates in Global Software Development (GSD) where work is being done in many locations simultaneously. In GDS, it is even more important that the security requirements are known, and certification is used. This is possible via centralizing the log management with tools such as Centralized Log Management (CLM), agreed procedures, and building many of the log management required functionality on the cloud platform. The research method used is expert analysis with qualitative interviews and a survey with six participants who all have several years of domain expertise. The research gathers the views of subject matter experts around the log management best practices but also reflects the legislation, standards, literature review, and articles about the topic. The gathered data was analyzed via theming in reflection on the software development process, tooling, logging related requirements, and logging activities inductively. This research concludes that the log management activities should be built on the Software Development Lifecycle (SDLC). Placing focus on the process of how solutions are built, one can ensure that the product being built will be of good quality. All interviewed experts agreed that a well-defined cloud architecture helps to ensure many of the log related requirements are handled accordingly. As important is to set up standardized log management processes into ways of working such as log inspections, following secure coding practices such as OWASP (Open Worldwide Application Security Project), and using tools supporting SDLC process such as Jira as a management tool to organize and track the work. Keywords: log management, SDLC, cloud platform, expert analysis FIGURES FIGURE 1 Cyber security research potential topic brainstorming ideas ............. 10 FIGURE 2 Zotero hierarchy of the main topics within the literature review ..... 12 FIGURE 3 SDLC phases .............................................................................................. 15 FIGURE 4 Log inspection process ............................................................................. 19 FIGURE 5 Cloud data generation and analysis in general level........................... 20 FIGURE 6 Monitoring, measurement, analysis, and evaluation process of security measures ........................................................................................................ 25 FIGURE 7 Centralized Log Management dashboard ............................................. 43 FIGURE 8 Microsoft Defender XDR with an example cyber security attack originated from a phishing email .............................................................................. 47 FIGURE 9 Activities graph based on this study i.e. log management activities within SDLC ................................................................................................................. 57 FIGURE 10 Security log entry example from Microsoft SIEM .............................. 58 TABLES TABLE 1 Software development lifecycle objectives with a security perspective. ........................................................................................................................................ 16 TABLE 2 Commonly known logs and their purpose ............................................. 17 TABLE 3 Storage times according to the Information Management Board........ 21 TABLE 4 The research procedure. ............................................................................. 30 TABLE 5 The interviewed teams, the experts, and their backgrounds. .............. 33 TABLE 6 Semi-structured interview with themes .................................................. 34 TABLE 7 Additional questions for the experts........................................................ 35 TABLE 8 The length of the transcripts. Noted that the first interview was a joint interview ....................................................................................................................... 35 TABLE 9 Applied coding/theming .......................................................................... 36 TABLE 10 Log related requirements relevant to the target organization ........... 39 TABLE 11 Target organization example use cases for collecting logs ................. 45 TABLE 12 Generalized table of ways of working and tools per target organization teams ...................................................................................................... 49 TABLE 13 The research questions’ generalized answers linked to the reference chapters ......................................................................................................................... 54 TABLE 14 Overall findings for good logging practices within SDLC ................. 71 TABLE OF CONTENTS TIIVISTELMÄ ABSTRACT FIGURES AND TABLES FOREWORD LIST OF ABBREVIATIONS 1 INTRODUCTION.................................................................................................. 9 1.1 Method and target of this research ........................................................... 9 1.1.1 Research questions ........................................................................... 11 1.1.2 Literature mapping strategy ........................................................... 12 1.2 Structure of this thesis ............................................................................... 13 2 PREVIOUS RESEARCH ..................................................................................... 14 2.1 Software Development Lifecycle (SDLC) ............................................... 14 2.2 Logs and logging ....................................................................................... 17 2.3 Log management ....................................................................................... 18 2.3.1 Log requirements ............................................................................. 19 2.3.2 Log generation .................................................................................. 19 2.3.3 Log storage ........................................................................................ 20 2.3.4 Log protection ................................................................................... 22 2.3.5 Log analysis ....................................................................................... 22 2.4 Cloud platforms ......................................................................................... 22 2.5 External requirements for log handling ................................................. 23 2.5.1 Standardization and guidance related to logs ............................. 24 2.5.2 Regulations regarding logs ............................................................. 26 3 METHODS ........................................................................................................... 29 3.1 Procedure .................................................................................................... 30 3.2 The target organization ............................................................................. 31 3.2.1 The teams ........................................................................................... 31 3.3 Expert evaluation method ........................................................................ 32 3.3.1 Reliability and validity .................................................................... 32 3.3.2 The interviews and additional questions ...................................... 33 3.4 Transcripts .................................................................................................. 35 3.5 Data analysis ............................................................................................... 36 4 RESULTS .............................................................................................................. 38 4.1 Requirements .............................................................................................. 38 4.2 Log generation ........................................................................................... 42 4.3 Log analysis ................................................................................................ 44 4.4 Log management tooling .......................................................................... 46 4.5 Secure software development lifecycle .................................................. 48 5 DISCUSSION ....................................................................................................... 52 5.1 Expert opinions on log management ...................................................... 52 5.2 Scientific and practical contribution ....................................................... 57 5.3 Limitations .................................................................................................. 57 5.3.1 Thesis scope ....................................................................................... 58 5.3.2 Some bias in interviews ................................................................... 58 5.3.3 Sampling and acquiescence ............................................................ 59 5.3.4 Translation and language ................................................................ 59 5.3.5 Sample size ........................................................................................ 59 5.3.6 Coding and transcript data ............................................................. 59 5.4 Future work ................................................................................................ 60 6 CONCLUSION .................................................................................................... 61 REFERENCES ................................................................................................................ 63 APPENDIX 1 OVERALL FINDINGS ........................................................................ 71 FOREWORD Thank you, my sisters, Dr. Paula Alavesa for her amazing support in the research process, and M.Sc. LLM Eija Alavesa for the great initial idea for the thesis topic and especially the comments regarding regulations. Thank you, my best friend Dr. John Zuta for giving me space for the thesis writing, and energy through supporting the work, cups of coffee and my favorite dish, Jollof rice. Thank you, University of Jyväskylä for the great master’s degree program in cyber security and Dr. Tiina Koskelainen for supervising the work and regularly giving me good advice to always progress with this work. Thank you, Metso and all the experts who partook in the interviews. Thank you, my initial thesis supervisor M.Sc. Antti Lehvonen with a very good kick-off and knowledgeable support in the research and thank you Metso supervisor M.Sc. Juha Karttunen for taking over this role. Thank you also to my former manager in Metso Janne Lampinen and Katja Helenius from Metso HR for making my study leave possible. Thank you, the Design System team in Metso for the great work you have done while I have been working on my thesis. Finally thank you Employment Fund’s adult education allowance, the financial support, that made it possible for me to take a leave from work and finalize my master’s studies in cyber security. September 16, 2024 in Stavanger, Norway M.Sc. Piia Alavesa LIST OF ABBREVIATIONS API Application Programming Interface ASM Automated Software Management CaaS Cloud-as-a-Service CEO Chief Executive Officer CIO Chief Information Officer CLM Centralized Log Management CRA Cybersecurity Resilience Act CSIRT Cyber Security Incident Response Team GDPR General Data Protection Regulation GSD Global Software Development IaaS Infrastructure-as-a-Service IACS Industrial Automation and Control Systems IAM Identity and Access Management IP Internet Protocol ISMS Information Security Management System IT Information Technology KQL Kusto Query Language ML Machine Learning MO Metso Outotec MS-SDL Microsoft Software Development Life Cycle NIS National Network and Information Systems OWASP Open Worldwide Application Security Project PaaS Platform-as-a-Services RQ Research Question SaaS Software-as-a-Service SDLC Software Development Lifecycle SIEM Security Information and Event Management SME Small and medium-sized enterprises SOAR Security orchestration, automation, and response SOC Security Operations Center SPL Splunk Processing Language SSE-CMM System Security Engineering-Capability Maturity Model STaaS Storage-as-a-Service XDR Extended detection and response Cyber-attacks are happening constantly. It is projected that 1,7 million ransomware attacks occur daily i.e. 19 occurrences every second. Out of that, a business is the victim every 11 seconds (Palatty, 2022). An example of the latest cyber-attack, which was targeting an oil company Halliburton happened just recently. Without knowing the actual nature of the attack, the recent news tells a good example of a potential cyber-attack, which could happen to any company (Gatlan, 2024). As a result, the company needed to close some systems in business operations and some global connectivity networks were also affected. The American oil company is one of the largest companies in the field operating in 70 countries with over 40 000 employees (Hampton, 2024). This case may be very similar to the example defined in FIGURE 8 where malware is installed because of a user’s mistake of clicking on a malicious link. Logs can tell us lot about the solutions and systems being built and used. Log events are a good source for finding suspicious activities malware and ransomware (Ring et al., 2021). Logging is an effective strategy for detecting ransomware with centralized logging. Since logs are of different types and from different sources, organizations should standardize this information. Collecting log data with a security information and event management (SIEM) system one can streamline threat detection. SIEM systems utilize centralized logs storing, analyzing, and monitoring the security events, identifying security incidents, as well as ransomware in real-time. Logging and log management are the core of secure operations ensuring business continuity and the company's up-to-date threat image (Staff, 2021). 1.1 Method and target of this research This research was done within the context of the target organization by interviewing experts with support from the literature and additional sources of information related to good log management practices. In other words, using 1 INTRODUCTION 16 related to each step of SDLC according to Khan et al. (2022), Khan et al. (2024), Silveira (2021) and Sugiantoro et al. (2020). TABLE 1 Software development lifecycle objectives with a security perspective. SDLC step (Khan et al., 2022) Objective (Silveira, 2021) Description (Silveira, 2021) Security requirements according to Khan et al. (2024) Security requirements according to Sugiantoro et al. (2020) Requirement engineering Overview and scope of the software Scope and requirements of the software have been defined. Reviewing, analyzing, and validating the security requirements is done. Security requirements are shared within the development teams. Context of a solution and security impact is known Designing Design specification Overall system architecture is available. Access control and traceability of incidents are tackled in the designs. Authentication and logging are in order. Coding Implementati on of the defined solution Components of the software are implemented. Potential security issues are tackled in coding. Approved tools are used, and implementations are done with the latest versions. Testing Software testing Execution of the code with ensuring that the code works in various environments. Testing according to the threat modelbased use cases is done. Latest security analyses are used. Deployment Release of software Software deployment is done in each system location. Security incidents are logged and monitored. Response plan is available. Maintenance Bug fixing, upgrading, and releasing new features Defines the end of the development cycle. Released maintenance phase is available. Security incidents are logged and monitored. Execution of the incident response plan when needed. 17 GSD (Global Software Development) is a software engineering field focusing on the aspects of a global software development environment where software development is been done in at least two different locations divided by national or country borders (Bajta et al., 2018). In the GSD context, the top security risks within SDLC are e.g. improper listing of security requirements, lack of security models updating, and lack of certification (Khan et al., 2022). According to Khan et al. (2022), the software quality and security issues get more complicated as the software development grows more distributed and concurrent. 2.2 Logs and logging As the systems being built get more complex and the number of potential threats against digital solutions rises, the amount of collected logs rises. With more events to be logged and more logs to collect the importance of the logs grows making the log generation and analysis more problematic. It is important to know the affected services and devices when a security incident occurs so that it can be further researched. Log data consists of important information about user actions, authentication events, and any security events, but also dependencies between devices and services (Söderström, 2013). TABLE 2 gives an overview of what type of data can be collected and how it can be used. The log data is also useful when there are no disturbances. The data can be used, for example, in reporting or different trends can be identified from it. Log information can also be used to predict risks and hunt for threats. Systems used to gather and analyze the logs should react quickly, partly automatically, to stimuli obtained from observations (Enfo, 2021). The process of collecting logs is logging, which creates the log file (Khan et al., 2016). In the wider sense logging means storing and utilizing log data. Log information is needed to find out what, why, and when something happened. Devices and operators connected to the Internet collect log data. A log means a chronological record of events and their causes. Events and changes in information systems, applications, information networks, and information contents are logged. As a matter of fact, logs are created all the time, everywhere. The systems and solutions collect logs, the wireless access point and wired network router stores event logs, the phone operator records communication logs, the everyday software access control logs, error logs, etc. (Traficom, 2023). TABLE 2 Commonly known logs and their purpose. (Traficom, 2023) Log type Collected data Used for The maintenance log Maintains information about changes made to the system's operation and changes to the system's user rights. Very useful in version control and monitoring the overall architecture of the operating environment. 18 Log type Collected data Used for The event log Probably the most common and necessary form of log. It registers user logins and logouts and information about other normal processes performed by the system. Entries about data additions, deletions, and changes must be recorded. The origin of the changed data can be seen from the log entries, so that its correctness can be traced and verified if necessary. The error log Records the cause of the error in the log as precisely as possible, so that it is also easier to fix the cause of the error. Useful for troubleshooting and solving problem situations. 2.3 Log management Log management is essential for organizations. Logs indicate the status of the system and contain security events occurring within the system. Logs are used for a lot of different things, like keeping track of users’ actions, following authentication attempts, and other security events. Organizations are facing the same issues of log generation, storage, protection, and analysis (Söderström, 2013). One of the challenges is balancing between the inadequate amount of log management assets and the increasing amount of data. Also, confidentiality, integrity and availability of the logs can be damaged on purpose or even accidentally (Kent & Souppaya, 2006). Organizations need to collect and use the logs systematically and wisely. The first step is to ensure that the right information is been collected by defining the operational requirements (Hellman, 2006). Initially logs were used for troubleshooting, but nowadays, they provide useful information such as network performance, previous events, identifying and analyzing the found bugs, optimizing the performance, user activity tracking, and inspecting malicious behavior (Khan et al., 2016). The log management infrastructure consists of log generation, log analysis, log storage, and log monitoring i.e. hardware, software, networks, and sources where the data is generated, stored, analyzed, and disposed of (Kent & Souppaya, 2006). A systematic approach is a must when it comes to log generation and analysis. This needs to be considered throughout and after the product lifecycle (Söderström, 2013). One way to ensure that logs are of good quality is to use log inspections. Log inspections are a way to verify that security is handled accordingly with planning, kick-off meetings, individual checks, log meetings, documentation and verifying corrections, and closing the meeting as defined in FIGURE 4. Log inspections can validate that teams are gathering correct data thus, providing input for the log requirements (Odera et al., 2023). 19 FIGURE 4 Log inspection process. (Adapted from Odera et al., 2023) 2.3.1 Log requirements Security requirements aim to achieve the desired effect but can also be seen as constraints for the system because they limit the system’s functional requirements or features (Haley, 2008). The diversity of gathered logs increases and makes the log related requirements more complex. In large organizations, the logs are collected from different sources. Logs are collected from the cloud for different purposes and contain data from applications, networks, systems, firewalls, etc., and can be used to analyze different malicious behavior. The log data must also be stored securely to ensure the integrity of the gathered data (Haley, 2008). Gathering logs can be seen as an essential security control to identify and analyze security incidents and potential security incidents. Data is gathered either in real time i.e. when executing an action, or within certain intervals (Khan et al., 2016). Legislation and standards also provide requirements for log generation described in more detail in chapter 2.5 External requirements for log handling. 2.3.2 Log generation In computer data logging the events within a system are recorded, resulting in log entries that include event characteristics and timestamps (Mejri et al., 2022). It is important to record log events, manage the log events appropriately, and protect them from unauthorized access (Söderström, 2013). Log means recorded events in chronological order and their causes. Events and changes in systems, 20 applications, and networks are logged. The logs generated from various sources provide a record of events useful for diagnosing problems, auditing activities, and understanding system behavior as defined in overall level in the FIGURE 5. There are quite many tools for logging. Some logging tools can be mentioned such as Scalyr, Splunk, and Datadog (Logit.io Ltd, n.d.). In some cases, an organization might want to store almost every log generated, if it favors usability over security. The log generation and storage should be part of the organization’s policies and procedures. At the same time, organizations should allow flexibility in log generation because systems differ, and the amount of log generated differs as well (Kent & Souppaya, 2006). FIGURE 5 Cloud data generation and analysis in general level. (Khan et al., 2016) 2.3.3 Log storage Ideally uniquely identified logs and log events would be stored in a centralized server to be further analyzed (Söderström, 2013). The log data should be available throughout the product lifecycle or sometimes even later as a reference and as data to be used and learned from. However, the most common cloud service providers only keep the data for 30 days. Barely having a log data management system and storing them accordingly does not solve the potential issues. The valuable data needs to be available when it is needed in a usable format sometimes also after 30 days. The company needs to identify which log data is valuable, how long data can or should be stored, and which systems and business areas are in the scope of log management. For example, it is quite difficult to find deviations from the log data produced by telecommunication devices if the device does not recognize threats from traffic or the data produced by the device is not enriched with external threat information (Enfo, 2021). 21 There are some guidelines for storage times when it comes to gathered logs and log data provided by different organizations. The one from the Information Management Board (2024) can be seen as a good basis for data storage times as shown in the TABLE 3. Their guidance applies to datasets and documents managed in the state administration and municipalities. Though recommendations would not be valid for all organizations, the recommendations can be used by all information management experts who need help defining retention times (The information management board, 2024). Logs can be cleared when the data is not needed anymore after a certain date and time (Kent & Souppaya, 2006). TABLE 3 Storage times according to the Information Management Board (2023). Process Title of the data Definition of the data Storage period The basis of the storage period Logging Plan Log principles, log plans, log management plan Five years Section 21 of the Act on Information Management subsection 2 Report Usage, change, and transferred log data Five years Section 21 of the Act on Information Management subsection 2 and 5 Report Technical log data if confidential or personal data is processed Five years Section 21 of the Act on Information Management subsection 2 and 5 Request Log data inspection/ review request Two years Section 21 of the Act on Information Management subsection 2 Answer The response to a log data inspection/ review request Two years Section 21 of the Act on Information Management subsection 2 Decision Decision on the transfer of log data Ten years Section 21 of the Act on Information Management subsection 2 Evaluation Criticality classification of information systems Five years Section 21 of the Act on Information Management subsection 2 Description Information system interface/ connection description Two years Section 21 of the Act on Information Management subsection 2 22 2.3.4 Log protection Confidentiality, integrity, availability, nonrepudiation, and privacy are the very core of a secure logging system (Ali et al., 2022). Confidentiality is the avoidance of unauthorized access to the logs. Integrity is confirming that the data is not deleted or altered. Availability is that the log data is available when the data is being needed or used. Nonrepudiation specifies that there is enough data on the occurrence of an activity (Ali et al., 2022). Care must be taken to separate the logs from the rest of the environment so that a possible data security breach cannot affect the integrity of log events. The log data should also be backed up and log entries should be recorded, and warnings should be set for unauthorized editing attempts (Traficom, 2023). 2.3.5 Log analysis Logs are required to be available in such a structure that they can easily be utilized (Ali et al., 2022). Different cloud vendors provide different types of services for storing data. For example, Microsoft provides Windows Azure storage as a Storage-as-a-Service (STaaS) (Khan et al., 2016). According to Khan et al. (2016), different service providers also offer cloud analytics for users to integrate data, diagnostics, and troubleshooting with graphical user interfaces to dig into the root cause of incidents. Log analysis is important but without proper processes, the value of logs is significantly lower (Kent & Souppaya, 2006). 2.4 Cloud platforms Recent reports say that companies are actively moving into the cloud, and over half of the companies’ infrastructure is in the cloud. Cloud security is seen as the main challenge when adapting to cloud usage (Pluralsight, 2023). Cloud computing generates issues from different sources to be included in data collection. Especially in cases where the logs are generated from different sources and format differs log management causes problems. This has led to organizations moving to cloud computing with logging services known as logas-a-service where the logs are sent to be stored and analyzed in cloud storage (Khan et al., 2016). With cloud computing, the number of potential vulnerabilities has increased. The amount of connected users challenges building secure software solutions. Many of the vulnerabilities are the result of flaws left unattended during the software development process. Roughly 50% of software security issues stem from flawed software architectures (Alenezi et al., 2022). Therefore, a thorough review of high-level design is essential. As part of risk management, it is advisable to treat logs as critical for any security-related event and archive them for long-term investigations (Alenezi et al., 2022). 23 Organizations with cloud services should have an infrastructure in place to actively deal with the log analysis. This would ensure three steps in managing the cloud’s logs i.e., first scanning the cloud to detect potential misconfigurations or breaches. Secondly integrating a vulnerability scanning solution. The last and third step is monitoring and analyzing the generated logs with a log management system providing continuous analysis of the gathered logs. The organization should take responsibility for cloud security together with the cloud service provider (Mejri et al., 2022). The quality of the gathered data needs to be verified regularly, and one needs to choose the gathered data wisely. There needs to be a balance between capturing every event versus not having enough data to be analyzed. Multiple platforms can handle log analysis locally, and only forward the relevant information to Security Information and Event Management (SIEM). Because each of the solutions e.g. identity and access management (IAM), firewall, and end user behavior already collect large amounts of data into their sources there is no need to duplicate it. As a result, the duplicated data is less leading to less costs (Diver et al., 2020, pp. 78–80). SIEM products support numerous types of log sources leading to the fact that they are very good at analyzing and collecting log data from different sources. They can identify malicious events and start automated event responses when needed. Many SIEM products also have graphical user interfaces incident tracking and reporting features both storing data. They also tackle the confidentiality, integrity, availability, nonrepudiation, and privacy of the gathered data (Kent & Souppaya, 2006). 2.5 External requirements for log handling The issues needing logging must be aligned not only with the goals and requirements set by the company or its customers. Also, external requirements related to logging e.g., legislation and standards need to be tackled. Many of the external requirements and legal acts also consider the lifecycle of the software or product, both address the importance of logs, logging, and log management. The accountability of a system is important so that actions can be traced to the entity, which was responsible for the event (IEC/TR 62443-3-1, 2009). The legislation might in some cases set requirements e.g., for the content of the log and the storage period. It also aims to ensure the integrity of the information in the logs and the purpose of use of the log. There are different types of logs, therefore their processing method and legal demands depend on what kind of information the log contains and for what purpose the log was originally collected (Traficom, 2023). If the companies cannot protect information and comply with legal requirements they can destroy the customer trust, end contracts, get fined, and lead to fallen stock prices, and lawsuits (Hellman, 2006). 24 2.5.1 Standardization and guidance related to logs The ISA/IEC 62443 (2019) Security for Industrial Automation and Control Systems (IACS) part 4.2 about technical security requirements for IACS components defines requirements for applying and maintaining secure industrial automation and control systems (IACS). This standard also defines some logging requirements regarding auditable events, automated notifications or integrity violations, tempering attempts, timestamps, time synchronization, audit storage capacity, warnings of storage capacity thresholds, response to audit failures, protection of audits, audit records on write-once media, audit log accessibility and programmatic accessed to audit logs. The ISA/IEC 62443 part 4.2 (2019) forces access to the logs for authorized persons and tools to audit the logs. There needs to be records created out of security events, which allows to audit of the logs accordingly. The categories of these events are access control, request errors, control system events, backup and restore events, configuration changes, and audit log events. The IEC 62443 Part 4.2 (2019) standard encourages the use of auditing and log management tools maintaining the integrity of IACS systems throughout the lifecycle. Automated software management tools (ASM) should be used to enable software lifecycle management, version controlling, and patching is a good way to ensure that also log management is handled accordingly (IEC/TR 62443-3-1, 2009). ISA/IEC 62443 (2019) part 3.3 of system security requirements and security levels refers to OWASP with secure development practices. OWASP (OWASP Foundation, Inc., n.d.) offers resources for secure coding. OWASP lists logging related requirements, which are finding security incidents, monitoring policy violations, setting a baseline, supporting non-repudiation controls, offering information about the problems, contributing to incident investigations, and attack detection. According to OWASP, the logs should be used consistently across the application portfolio and industry standards should be used to ensure that the data can be used and managed with a wide variety of systems. The logs can also be used for performance monitoring for example to check the site loading times, compliance monitoring, business process monitoring with transactions and connection, and audit trails of data additions, modifications, or deletions (OWASP Foundation, Inc., n.d.). OWASP is an open-source community project with tools e.g. standards, documentation, and code, which purpose is to foster secure software. One of the projects of OWASP is the Top 10 risks with log related category of A09:2021-Security Logging and Monitoring Failures. Lack of proper logging can lead to failures such as inadequacy visibility in incidents and emerged threats. One of the prevention methods in the A09:2021 is an established incident response and recovery plan following the National Institute of Standards and Technology (NIST) 800-61r2 or later (OWASP Foundation, Inc., n.d.). OWASP refers to NIST SP 800-92 Guide to Computer Security Log Management (Kent & Souppaya, 2006). NIST SP 800-92 delivers an overview guideline for creating an effective log management strategy, which explicitly 25 expresses that organizations need to establish policies and set standard actions for log management. According to NIST SP 800-92 log management should be prioritized in the organizations and organizations should ensure that there is an arrangement, enough staff with log management responsibilities, and standardized processes available for log management. ISO/IEC 27001 (2023) standard for information security, cyber security, and privacy protection for information security management systems (ISMS) lists of controls for mitigating security risks. For example, one of the logging related controls requires the recording of events, exceptions, faults, and additional activities so that they can be stored, analyzed, and protected. According to the standard networks, systems, and applications need to be watched for atypical behavior and corrective actions need to be taken to assess information security events. The standard also encourages continuous improvement of the systems by setting measurable and monitorable objectives and plans to achieve and evaluate them. Furthermore, the ISO/IEC 27001 (2023) mentions one of the controls being that the secure development lifecycle should be established and applied. ISO 27004 (2016) standard lists techniques for monitoring, measuring, analyzing, and evaluating information security management. The standard intends to help the ISO/IEC 27001 (2023) by providing practical examples for monitoring, measuring, analyzing, and evaluating information security. The standard lists several techniques of what to measure e.g., output of logs and scans and incidents and audit results. The standard highlights that one needs to measure the effectiveness and verify the needs of the used controls. The standard promotes iterative way to improve the efficiency of the security controls as shown in the FIGURE 6 both insists that the collecting, analyzing, and reporting of the data should be automated as much as possible. The measured security practices should be documented and communicated regularly to the management and the results should be sent to the right persons responsible for analyzing or evaluating them. Naturally, there should be enough data to analyze, and the results need to be tested to ensure they are useful for the organization. FIGURE 6 Monitoring, measurement, analysis, and evaluation process of security measures. Adapted from ISO 27004 (2016). 1. Identify information needs 2. Create and maintain measures 3. Establish procedures 4. Monitor and measure 5. Analyze results 6. Evaluate information and performance effectiveness 32 the basis for all the application teams. On top of that cyber and information or cloud security is developed via centralized ops i.e. Security Operations Center. Metso has a SOC team providing company threat detection, response, and prevention capabilities. It is an outsourced team of IT security professionals. The SOC teams aim to improve the proactive defense against potential security threats (Scapicchio et al., 2024). Geminex is a metallurgical digital twin providing operational data and insights on performance for clients on mining and metallurgical operations (Metso, n.d.). The Geminex product team works within Mineral’s digital organization. 3.3 Expert evaluation method This chapter presents the research method used in the study. Initially, the chosen method was expert evaluation with a mixed method approach collecting qualitative and complementing it with quantitative material. The quantitative material was the raw logs, and the qualitative material were the expert interviews with additional questions. At first, qualitative semi-structured interviews with domain experts were conducted, followed by quantitative data logs collection to complement the findings from the interviews. The raw log data was asked during the interviews with the experts but in the end that was not used in the research. There was too little sampling of log data thus it was left out of the scope of the research and the study does not contain quantitative analysis. Experts were asked about their own experience when it comes to log management. They were asked to answer the questions openly with positive as well as negative issues. The interviewer i.e. thesis writer is employed in the target organization, which may have created a pragmatic nature of the interviews. The pragmatic aspect focuses on the functional needs of a solution rather than feelings and thoughts (Väänänen-Vainio-Mattila & Wäljas, 2009). The researcher also asked for the users to sometimes share their screens as going through the loosely structured interview questions because the questions were related to the actual current context of logging and log management. 3.3.1 Reliability and validity The interviewer focused on open-ended questions without leading questions. Conducting interviews is a skill and requires listening, taking notes, and figuring out where and what points to follow with further questions. It can be also noted that analysis is challenging with transforming notes and video recordings of open-ended responses into insights and data to be handled in the research (Lazar et al., 2017, p. 188). The Data analysis part has been defined in more detail in the chapter 3.5. 33 The persons who were interviewed all had connections to the cloud platform and were selected in a way that all the levels within cloud platform architecture, tooling, and cloud applications development were targeted. The number of teams was 5, and in total 6 experts were interviewed. For qualitative research often the number of users is around five where one can genuinely dig into how users approach their work (The Interaction Design Foundation, n.d.). 3.3.2 The interviews and additional questions There were in total of 4 interviews where 5 teams and 6 experts were interviewed during April 2024. The length of the interviews ranged between around 42 min to nearly an hour. The longest interview was done with two different teams with cloud architecture ownership within Metso from IT and Minerals Digital. In addition, the experts were asked more specific questions on the work process and tools they are using to maintain the ways of working later during the summer of 2024. TABLE 5 presents the teams and experts who were interviewed in the research in more detailed level. TABLE 5 The interviewed teams, the experts, and their backgrounds. Team/Group ID Background Time Length IT Cloud Platform group Expert 1 18 years of experience in IT ranging from System Administrator to Architect. Wednesday, April 24. 2024 from 11.00 to 12.00 56 min 38 sec Mineral Digital (cloud) Infrastructure Expert 2 Roughly 20 years in IT. Out of 2016 worked with Cloud solutions. IT Operations Expert 3 Worked in the target organization from May 2022. Working in cyber security since 1996. Thursday, 18. April 2024 from 13.00 to 14.00 44 min 56 s Expert 4 In the target organization from May 2002. Working in cyber security since 2002. SOC group Expert 5 In the current position 2,5 months as a key Analyst in SOC. Roughly 7 years in total working in SOC operations. Monday, 22. April 2024 from 9.30 to 10.30 42 min 17 s Minerals Digital Geminex product team Expert 6 About 10 years in product development. Analyst, Specialist, Product Owner, etc. In the target organization as a Product Owner in 2023. Wednesday, 17. April 2024 from 14.00 to 15.00 47 min 34 The purpose of the interviews was to get information through relaxed discussions around the themes with the focus areas as defined in TABLE 6. The questions were drafted around the research questions explained in the chapter 1.1.1. so that one would get as much information related to them as possible. During the interviews, it was also agreed that if further clarification or information is needed all the experts could be contacted later. The information related to ways of working presented in TABLE 7 was asked later after the interviews, roughly 9 weeks after the initial interviews. TABLE 6 Semi-structured interview with themes. Theme Example question Noted/focus on Reason for gathering the data Why are the software logs gathered? Monitor, track, and learn about incidents. Also, to avoid the incidents or work on preventing one, and learn about users and their behavior. Examples of how logs have been used. What type of logs do you gather? Few latest examples of usage. The data, which is been collected with the logs. General information about the collected data. – Ask for examples. Tools and technology stack How do you collect the logs? Tools, software etc. Where to store the logs? Physical location? Format? What tools are used to analyze the logs? Software, tools, etc. Requirements for log gathering Who decides what data is been gathered with the logs? Who owns the logs? Where do the requirements for log gathering come from? Business lines, policies, guidelines, etc. How to handle the requirements on the logs? Who is responsible for the logs? Who owns the logs? Tracking What are the KPIs relevant for log management? The storage time, the amount of gathered data, the usefulness of the gathered data, etc. 35 Theme Example question Noted/focus on Raw logs Ask for examples. TABLE 7 Additional questions for the experts. Theme Question Noted/focus on Ways of working Could you describe the specific tools that assist you during your work management process? Jira, confluences etc. The ways of working within the teams and the tools supporting the work Could you elaborate on any specific methodologies you utilize in your job tasks? Like scrum, agile, or SAFe. Could you describe the specific tools that assist you during your work management process? Jira, confluences etc. 3.4 Transcripts Four interviews were held for a total length of 3 hours, 10 minutes, and 42 seconds. The expert interviews were done in English, except for the interviews where there were only Finnish-speaking people present. The fact that the interviewer is not an English native can always affect the results though the target company’s official language is English, and it is used widely within the IT and software development teams. Metso is also a global company operating close to 50 countries with over 100 nationalities (Metso, n.d.). In general, the interviews held in English had more words than the interviews held in Finnish. When translated from Finnish into English it is estimated to have roughly 35% of expansion of space. This is mainly because in Finnish words compound nouns are used to replace a string of words affecting the number of words (Andiamo!, n.d.). Translation has been done for the quoted parts of the interviews where the interview was done in Finnish. Noted also that the expert interview session with two teams in present took the most time and thus, also had the most amount of transcript available as shown in the TABLE 8 with details of the length and language of the held interviews. TABLE 8 The length of the transcripts. Noted that the first interview was a joint interview. Team Length Language Number of words Number of characters IT Cloud platform and, Mineral Digital (cloud) Infrastructure 56 min 38 sec English 7059 35 361 36 Team Length Language Number of words Number of characters IT CIO Office and IT Operations 44 min 56 s Finnish 3227 21 283 SOC team 42 min 17 s Finnish 3581 24 524 Mineral Digital Intelligent Automation, Geminex 47 min English 5544 27 263 3.5 Data analysis The material was treated with thematical analysis, which is widely used in qualitative analyses. In this method, the material is structured into themes and patterns (Myers & Newman, 2007). There are two approaches in thematic analysis, usually a little of both are used at the same time. The approaches are 1. deductive, i.e., use existing frameworks in coding and categorization, or 2. Inductive i.e., all codes and categories are developed based on the material and the research question of the thesis (Braun & Clarke, 2006). The material was themed inductively in this research. The theming was done according to the research questions i.e. reasons for gathering log data, tools, and technology stack, requirements for gathering logs, and how the logs are been gathered, used and tracked in real whereas the selected suitable code was included as referred in TABLE 9. The aim was to answer to main and all the subresearch questions presented in chapter 1.1.1. A software tool ATLAS.Ti was used for coding the material. ATLAS.ti is a tool for analyzing qualitative data. ATLAS.ti allows editing the transcripts and structuring the expert interview data accordingly into insights, quotes, and coding based on different themes (ATLAS.Ti, n.d.). Noted that the writer is experienced in theming and categorizing different qualitative research via affinity diagramming. Affinity diagramming refers to arranging connected observations and findings into groups. Affinity diagramming can also be referred to as card sorting and is a good way to determine information architecture or a solution (Krause & Pernice, 2024). In the same way as affinity diagramming, the thematical analysis brings flexibility into the work but at the same time there are no clear rules for the analysis, meaning that any type of coding goes (Braun & Clarke, 2006). TABLE 9 Applied coding/theming. Code Groundedness Research question Group Application team log management 4 RQ1 Software dev process Commercial tool 9 RQ1.3 Tools 37 Code Groundedness Research question Group Costs 7 RQ1.3 Tools Dashboard 12 RQ1.3 RQ1.4 Tools Log data usage Existing guideline 2 RQ1.2 Existing guidelines Location 2 RQ1.4 Log data usage Log type 14 RQ1.4 Log data usage Open-source tool 17 RQ1.3 Tools Ownership 10 RQ1.4 Log data usage Reason for log 40 RQ1 RQ1.1 Software dev process Requirements Requirements 19 RQ1.1 Requirements Retention time 19 RQ1.1 RQ1.4 Requirements Log data usage Sentinel 6 RQ1.3 Tools Tool 66 RQ1.3 Tools Tracking 16 RQ1 RQ1.4 RQ1.5 Software dev process Log data usage Prevention work Use case 18 RQ1.1 RQ1.4 RQ1.5 RQ1.6 Requirements Log data usage Prevention work Users User 7 RQ1.6 Users Ways of working 45 RQ1 Software dev process 38 In the target organization, there are several requirements for the log gathering mostly originating from policies and laws but also from the customers. Although the development teams ensure that the requirements are tackled accordingly, the IT architecture team builds in rules and models available for all the product teams. Solutions such as Azure Cloud, SIEM, and Log Analytics help organization’s product teams. While the application teams focus mainly on performance monitoring, troubleshooting bugs, and predictive maintenance when gathering the logs, the IT architecture team aims to build security related requirements into the cloud platform itself to ensure that the main requirements related to log gathering are considered. So, the process takes care of logs, so there's no requirement defined for every new subscription onboarded in our environment. (Expert 1) 4.1 Requirements Law and policies are big drivers when it comes to requirements related to logs as defined in more detailed in the TABLE 10. In the target organization, there is a structure of policy, directives, and guidelines when it comes to IT security. It contains for example statements of retention times from a global perspective. These statements are approved by the CEO. The target organization’s Geminex team aims to comply with the requirements of ISO 27001 (2023) during the following year. To comply with the standard’s requirements on log management, automation and building many of the required controls on the cloud platform itself is important. The log management infrastructure and logging management should be in place to comply with the standards and legislation. Complying with certain security compliance like NIS2 or GDPR whatever falls into cloud products. (Expert 2) 4 RESULTS 39 If we are talking about NIS2 requirements on some other security requirements. Some rules take control, and we will force development teams to fall in common place that. (Expert 1) For the product development teams the log and security related requirements come usually from the development team itself. For example, in general there should not be unauthorized access to the product. But sometimes the requirements come from the customer e.g. they want to know who made changes to the product. we will do in future. It's actually a sactivities, events and log related-work Some requirement that they want to know who accepted the set points. (Expert 6) Normally the SOC activities are not linked to the security frameworks as such, but the requests to follow a certain policy or law come from the IT security team. On some level, there is also a push from the customers’ side to ensure the security is handled accordingly e.g. certifying according to a certain standard. Standardization can be seen to measure the system security (Vaarandi & Pihelgas, 2014). Apply for IEC 27001 certification and that is the target because if we get it then it will be easier for us to convince our customers to send their data to a cloud solution. (Expert 6) TABLE 10 Log related requirements relevant to the target organization. Standard, regulation, or publication Log related requirement Log management process (of the organization) Log type (Refer to the chapter 2.2 Logs and logging.) ISA/IEC 62443 Access to the logs for authorized humans and tools to audit the timely gathered logs. The system events (access control, request errors, control system events, backup and restore events, configuration changes, and audit log events) are recorded. IP data usage Identity assurance Workstation assurance Anomaly detection Configuration / Management /Platform assurance SOC process Event log Maintenance log Error log ISO/IEC 27001 Synchronized logs recording activities shall be produced, stored, protected, and analyzed. Workstation assurance IP Data usage Event log Maintenance log 40 Standard, regulation, or publication Log related requirement Log management process (of the organization) Log type (Refer to the chapter 2.2 Logs and logging.) ISO/IEC 27004 Compliments ISO/IEC 27001. Lists examples of what to measure e.g., the output of logs and scans, and guides on auditing results. Ensure there is enough data to be analyzed and evaluated. Document and communicate the secure practices (e.g. log management) to management and relevant personnel. Workstation assurance Anomaly detection Configuration / Management /Platform assurance Event log Maintenance log Error log NIST SP 800-92 Provides an overview guideline for creating an effective log management strategy. IP data usage Identity assurance Workstation assurance Anomaly detection Configuration / Management /Platform assurance SOC process Event log Maintenance log Error log Data privacy regulations A person’s ability to determine how his personal information is used. GDPR data minimization principle states personal data must be limited to what is necessary for the Identity assurance Event log 41 Standard, regulation, or publication Log related requirement Log management process (of the organization) Log type (Refer to the chapter 2.2 Logs and logging.) purposes of processing the data. NIS2 Where applicable companies defined as providers of key services in the sectors must implement security measures and notify national authorities of serious incidents within 24 hours. SOC process Configuration / Management /Platform assurance Workstation assurance Event log Maintenance log Cyber security Resilience Act (CRS) Ensure a sufficient level of cyber security of the products and ensure that the consumers and businesses have a way to ensure that their cyber security is in order. IP data usage Identity assurance Workstation assurance Anomaly detection Configuration / Management /Platform assurance SOC process Event log Maintenance log Act on Electronic Communication Services A corporate subscriber is obliged to maintain information security of communications, traffic data and location data of their users. IP data usage Identity assurance SOC process Event log Requirements from the customers Any requirement related to secure operations of digital products or platforms. Dependent on the customer request Error log Event log 48 blocking an IP via a firewall or locking a suspicious user account. Azure Sentinel Playbook is a separate service to be bought separately. Like all the Azure services the costs can go very high when every logic app action and connector increases the cost thus it is important to design playbooks as simple as needed (Diver et al., 2020, pp. 307–309). Many of the security requirements related to logs, logging, and log management can be tackled with the software selections and work on the cloud platform. Ensuring that all the teams get the benefit of log analytics is important. For example, the users should not be overwhelmed with log data. For example, not all the use cases are relevant to all the customers the applications are being made for, but only to the development team working with the product. It is important that the organization defines to whom the gathered data is delivered for example metrics of daily port scanners can be irrelevant for an executive just wanting details on business level metrics. The gathered data should be centralized and out of that there would be different levels of detail for different stakeholders. If necessary, the experts can drill down to the root cause of an anomality. are generated in virtual machine where Unix is installed. Then we have a. Logs Scheduler or Chrome job that pushes this log data to Azure log Analytic, Azure service and from the Azure log analytics Grafana brings the data. And in the long run, the Grafana dashboard will have the data where you at the look high level picture and then go to the lowest level. But we're not there yet. To some extent, our business stakeholders as well, but maybe a different dashboard for them. (Expert 6) 4.5 Secure software development lifecycle Software security is about how to utilize different techniques and methods to ensure the safe and reliable use of software systems. Prioritizing the security in SDLC allows product teams to identify and resolve security issues throughout the software development process. There are several sources of software vulnerabilities, and if the software development teams cannot always prioritize security, the quality of the software weakens. This is apparent when there are no negative consequences from the customer or business for the security related work. Sometimes development teams handle security related features less important and focus rather on delivering new features (Vaarandi & Pihelgas, 2014). It is as important to ensure that the knowledge and understanding of certain log or security related requirements are shared for the organization and the customer. Unfortunately, also in the target organization, many times, the more visible feature requirements take priority in software product development. This is not according to the (secure) software development lifecycle principles. Sometimes the Product Owner needs to remind customers that also security related requirements need to be taken care of for creating a stable and reliable 49 product. Note that not prioritizing the log management practices is also against the standards related to logs and secure development practices. The more features you add, the better the product is. So that's the kind of the point of view that they have. I don't blame them. It comes from the customers because customers request those features. But on the other hand, it's I think to some extent product owner is responsible to convince them that hey we also have to provide you a stable system. (Expert 6) Target company’s IT Security Policy mandates that, “event logs record user activities, liabilities, and exceptions”, and “The information security events must also be produced and regularly evaluated or reviewed”. To ensure that security is handled accordingly the development teams must have sufficient knowledge and resources to work with security related issues. The Metso teams’ ways of working vary from team to team. Nevertheless, the platform and the tooling ensure that data is gathered, monitored, and analyzed accordingly. Tools have already defaulted on what to follow but the teams can also define levels of data and what to gather. Teams can add on to ensure for example the performance and smooth operation of the software product by adding their own ways to generate and analyze the log data. It is though always good practice to ensure whether the additions make sense according e.g. the potential compliance risks, costs of the needed work and the costs the amount of data generates. TABLE 12 gives an overview of the used tools and ways of working within the target organization’s teams. Any automation of processes and use of tools supporting SDLC process such as Jira is encouraging (Pathak, 2022). Jira (Atlassian, n.d.) is an issue and project tracking tool, which can be also used to ensure that logs and log management related requirements are handled properly. Atlassian (Atlassian, n.d.) also provides tools such as Tempo for performance tracking and Confluence for company wiki to document and share also the security related work. There is also information in the MO (Metso Outotec) Handbook of security policies and directives shared via intranet to all the company employees. The target organization promotes agile software development work, which purpose is to ensure that people doing the work together in collaboration and continuously validating that the right things are being done (Agile Alliance, 2015). TABLE 12 Generalized table of ways of working and tools per target organization teams. Team Ways of working Log related tools Other tools or way of working Example IT Operations There is a set of IT security policies and directives in the overall level all the MO Handbook with policies and directives of the target organization. Committed to cloud/Azure Utilizes e.g. Jira, Confluence, and Tempo. A portfolio management approach for the work. IAM (Identity and Access Management) 50 Team Ways of working Log related tools Other tools or way of working Example teams should follow. first principle. With CLM (Centralized Log Management). related work such as Access Management, log management, and security incident processes are managed within IT. IT Cloud platform Does not monitor the detailed level of how teams execute logging. Committed to the cloud/Azure first approach and are building a cloud platform supporting the chosen approach. Splunk in some Operations. Utilizes e.g. Jira, Confluence, and Tempo. The requirements for logging are built into the platform. Azure Sentinel services for capturing logs, and all the logs created in Azure Active Directory are sent to SOC team. Mineral Digital (cloud) Infrastructure Build a cloud platform to help in the work where security is one pillar. Committed to the cloud/Azure first approach. Azure Monitor Activity Log, Elastic stack, Splunk in some operations. Investigating e.g. Datadog and SolarWinds (SolarWinds, n.d.) is mainly for monitoring network e.g. servers. Works agile in the scrum. Uses tools such as Jira and Confluence. Jira for task management, Confluence for Documentation (Atlassian, n.d.). In some of the projects Microsoft Teams Tasks is also used. Geminex Dependent on the product team. Individual application teams decide what they want to capture. Grafana with Prometheus Azure Log Analytics In addition, plans to get ISO/IEC 27001 certificate Works agile in a scrum. Utilizes e.g. Jira, Confluence, and Tempo. In general, the team follows a Secure Development Lifecycle (SDLC). It is a software engineering process that helps software teams build more secure 51 Team Ways of working Log related tools Other tools or way of working Example Geminex team uses an agile software development process. software and address compliance requirements. In the future use Azure Log Analytics with Grafana to visualize the data. SOC SOC service is an outsourced service providing support for the customer. Continuous service with the customer. Sentinel SIEM Sentinel Log Analytics Defender XDR Paloalto’s XSOAR Constant communication with the target organization. Requests come from the target organization and are handled case by case by the external SOC team. 52 The purpose of this research was to find out how to get anonymized information – in the form of logs – from the systems for continuous development and measurement of information security in the cloud platform context and the SDLC process. The research was based on expert analysis with qualitative interviews and a survey with six participants with several years of domain expertise. 5.1 Expert opinions on log management The target organization has a cloud first approach, and it is working with a welldefined and managed cloud architecture ensuring that also log management related requirements are executed accordingly. All experts agreed that the log management functionalities can be built into the cloud platform to ensure that systems are getting enough needed data to develop and measure information security. Building log management mechanisms into the platform ensures that requirements related to log management are tackled properly. The collecting, analyzing, and reporting of the log data should be automated as much as possible as it is in the target organization via SOC operations. According to the experts, it is important to align the ways logs are gathered. Similarly, according to OWASP, the logs should be used consistently in the application portfolio, and industry standards should be used to ensure that the data can be managed with a wide variety of systems. The target organization uses a tool called CLM allowing the collecting and storing of logs from various Azure services, applications, and infrastructure. Nevertheless, the collected or needed data also differs. The teams in the target organization are given enough flexibility in log generation because systems differ, and the number of generated logs differs as mentioned also in NIST SP 800-92. Sometimes it is unclear what to log, and how many levels of details data should be gathered. One way to ensure that teams are collecting the 5 DISCUSSION 53 right data helping the software development teams in the work are log inspections, which should be used in the target organization more widely. The Log inspection process by Odera et al. (2023) highlights importance of the audits and evaluations for checking that the right data is gathered and monitored. The target company has documentation available from overall IT policy, incident response process and even more detailed use case level descriptions of the gathered logs. One of the risks according to experts is that the logs are gathered too widely and not documented, leading to compliance risk. The product level security practices should be always documented, and the results should be sent to the right persons responsible for analyzing or evaluating them in this case to the SOC team and the product teams in question. Also, NIST SP 800-92 highlights that there needs to be shared and maintained documentation on log management policies and procedures available following the log management strategy defined for the organization (Kent & Souppaya, 2006). The target organization can place more effort into shared documentation in log management documentation available for all the teams involved in log generation e.g. via a shared Confluence (Atlassian, n.d.) space. According to experts, the company needs to identify which log data is valuable enough to be gathered as it is expensive. Checks for the gathered information need to be done to ensure that the logs are collecting the right data, and that the log gathering is in balance with the costs and legislation. Sometimes it is too easy to gather too many logs, for this type of case there is also an automated notification sent for excessive log gathering, and these cases need to be checked case by case. Naturally, there should be enough data to analyze, and the results need to be tested to ensure they are useful for the organization, but the data should also be balanced with the costs. The software security is more complicated in the target organization’s GSD context with simultaneous and distributed development work. Because of the nature of the GSD, the controls, tools, and practices of secure SDLC must be in place e.g., the security requirements should be known and listed, and certificating should be used (Khan et al., 2022). These guidelines should be offered for all the development teams gathering logs. As mentioned earlier, this is something the target organization can put effort into. The product teams could develop and maintain shared practices in log gathering in collaboration. Collaborative work is already familiar in the target organization with the agile software development practices guaranteeing that people are working together. Sometimes the needs of the business lines differ, in practice many times feature development takes priority over security requirements. This is why it is also the software team’s responsibility to explain to the stakeholders requesting a new feature that the systems also need to be stable and secure as explained by an expert during the interview. The product teams do have autonomy in the work. The software development teams have also built their log management setup to ensure that they are collecting the right things regarding performance monitoring, dependency checks, or specific requests from the customers. 54 The experts were very aware of the latest standards and legislation related to the security work. Many standards and legislation enforce log management. NIS2 forces the manufacturers to take logging procedures into software development process phases. ISO/IEC 27001 (2023) mentions that the secure development of software and systems should be founded and practiced. The experts believe that standardization helps teams to succeed and ensures customers the quality of the product. For example, the target organization’s Geminex product team aims to comply with the requirements of ISO 27001 (2023) during the following year. Nevertheless, it can be highlighted that all regulations do not cover every company’s need. When planning to log, each organization must identify its roles (e.g. private company or provider of key service) when it comes to regulation and the information, they are handling (e.g. business continuity critical or personal data). The role and handled information should be matched with the required/ necessary regulation requirements (Traficom, 2023). TABLE 13 summarizes the findings related to the literature and target organization practices with reference to the chapters where these are handled in more detailed level. TABLE 13 The research questions’ generalized answers linked to the reference chapters. No. Research question SDLC phase The required log related work Log related work in the target organization Reference chapter(s) RQ1 How to get anonymized information from the systems for continuous development and measurement of information security? All phases Log management in place with reviewed log related requirements. The generation, analysis, and improvement of the log management throughout SDLC. Target organization has cloud first approach in handling cloud application related requirements. The product teams can define the level of details the logs are gathered and sent to SOC team to be analyzed. 2.1 Software Development Lifecycle (SDLC) 2.2 Logs and logging 2.3 Log management 4.2 Log generation 4.3 Log analysis 4.5 Secure software development lifecycle RQ1.1 What are the log related needs of the business lines and company? Require ment engineeri ng Log management and logs requirements gathering via standards, guidelines, legislation, and specific customer The target organization’s product teams have autonomy to build their own solutions in regards of monitoring specific requests from the 2.3.1 Log requirements 2.5 External requirements for log handling 4.1 Requirements 55 No. Research question SDLC phase The required log related work Log related work in the target organization Reference chapter(s) requirements e.g. via certification or needs to know users’ actions e.g. edits. customer. Geminex product team aims to certify according to ISO 27001. RQ1.2 What are the existing (internal and external) guidelines or policies for log management? Require ment engineeri ng, Designin g, Coding, Testing Standardizatio n, legislation, and guidance related to logs and log management are known. The target organization aims to handle requirements related to standardization and legislation by creating the rules in the cloud platform. 2.5.1 Standardization and guidance related to logs 2.5.2 Regulations regarding logs 4.1 Requirements RQ1.3 What are the tools and the ways to analyze the logs based on the information relevant to the targets or goals? Coding, Testing, Deploym ent, Mainten ance Log management tools with secure coding practices e.g. OWASP. The tools are heavily Microsoft based though there is also some usage of other tools, also opensource tools are used by the software product teams. The teams also try out new tools if needed. 2.4 Cloud platforms 4.4 Log management tooling 4.5 Secure software development lifecycle RQ1.4 How incidents are monitored, tracked, and learned from? Mainten ance Log analysis via building shared tools for it and allowing the product teams to define additional things they wish to monitor. E.g., the target organization has a service called Centralized Log Management (CLM) showing the details where the users can navigate to the root cause of the potential incident. 2.3.5 Log analysis 4.3 Log analysis RQ1.5 How to avoid the incidents or work on preventing them? Coding, Testing, Deploym ent, Following standards and certifications. Building common ways The practices around log management differ from team to team and their 2.5 External requirements for log handling 56 No. Research question SDLC phase The required log related work Log related work in the target organization Reference chapter(s) Mainten ance and tooling for log management. experience and knowledge on secure practices. Nevertheless, the cloud platform approach ensures alignment. 4.1 Requirements 4.4 Log management tooling RQ1.6 What can we learn about users and their behavior? Mainten ance Logs tell about user behavior and are used to e.g. track user actions, and authentication events. Logs are used in various ways for example tracking user actions, and suspicious security events. Briefly mentioned in 2.2 Logs and logging, 2.3.3 Log storage and 2.4 Cloud platforms. Experts see that log management is handled well enough by following the common ways of tooling, standardization, and certifications. NIST SP 80092 (Kent & Souppaya, 2006) says that organizations should set up standardized processes for log management allowing and leading to better decision-making. This can be created and maintained with log management infrastructure as it is in the target organization. There should also be enough knowledgeable staff working with log management responsibilities (NIST SP 800-92). The log management activities such as log requirements gathering, log generation, log storage, log protection, and log analysis can be linked to SDLC. The research concludes that the priority of log management within SDLC should be built into the organization’s ways of working. In the target organization it is seen very important to define the infrastructure and tooling for the log management so that many log management related requirements are handled accordingly. Software development teams should also prioritize log management and logs related tasks within the SDLC. The FIGURE 9 lists activities graph based on this study. The graph has been adapted from the APPENDIX 1. The table in the appendix presents the phases of SDLC, log management use cases within the company, and summaries of good logging practices, which can ensure compliance with the regulations and standards. In the target organization especially defining the Requirement engineering phase’s architecture for the log management and Designing phase’s defined log management tooling were seen important and are something to add on to the SDLC process’ log management practices supported by the literature. These 2 controls for good log management practices are bolded in the FIGURE 9. 57 FIGURE 9 Activities graph based on this study i.e. log management activities within SDLC. 5.2 Scientific and practical contribution The literature provides very good examples to ensure log management is done well but there is always a possibility to add on these from the knowledge of experts or practitioners. Expert users can be seen as important source of information for developing security measures and can be seen as valuable resource to develop the security design. This is because the security measures can be seen as good as the people developing and handling the organizational security controls (Spears & Barki, 2010). One of the thesis’ purposes was to show and list the log management activities in relation to the literature on the topic and experts input of their practices. The findings of this thesis can be used as the requirements for a guideline to be made for any software development team to efficiently gather and use logs in their work. 5.3 Limitations The thesis research scope changed just slightly during the research, which has been explained in this chapter. The initial idea was also to analyze log data, but this was left out of the study’s scope because of not enough data to be analyzed. 64 Braun, V., & Clarke, V. (2006). Using thematic analysis in psychology. Qualitative Research in Psychology, 3(2), 77–101. https://doi.org/10.1191/1478088706qp063oa Corporation for Digital Scholarship. (n.d.). Zotero | Your personal research assistant. Retrieved November 21, 2023, from https://www.zotero.org/ Cortazzi, M., Pilcher, N., & Jin, L. (2011). Language choices and ‘blind shadows’: Investigating interviews with Chinese participants. Qualitative Research, 11(5), 505–535. https://doi.org/10.1177/1468794111413225 Diver, R., Bushey, G., & Rader, J. S. (2020). Learn Azure Sentinel: Integrate Azure Security with Artificial Intelligence to Build Secure Cloud Systems. Pp. 29, 78– 80, 183, 307–309. Directorate General for Internal Market, Industry, Entrepreneurship and SME. (n.d.). Data protection under GDPR. Your Europe. Retrieved August 29, 2024, from https://europa.eu/youreurope/business/dealing-withcustomers/data-protection/data-protection-gdpr/index_en.htm Diver, R., Bushey, G., & Perkins, J. (2022). Microsoft Sentinel in Action: Architect, Design, Implement, and Operate Microsoft Sentinel As the Core of Your Security Solutions: Vol. Second edition. Packt Publishing. Pp. 32–33, 35 69, 144, 173, 175, 186–187. https://search.ebscohost.com/login.aspx?direct=true&db=e000xww&AN =3164520&site=ehost-live Enfo. (2021, June 6). Lokitieto voi pelastaa katastrofilta – kadonnutta tietoa ei saa takaisin. https://www.enfo.fi/blogi/lokitieto-voi-pelastaa-katastrofiltakadonnutta-tietoa-ei-saa-takaisin European Commission. (2023, September 14). Directive on measures for a high common level of cybersecurity across the Union (NIS2 Directive) | Shaping Europe’s digital future. https://digitalstrategy.ec.europa.eu/en/policies/nis2-directive European Union. (n.d.). EU Cyber Resilience Act | Shaping Europe’s digital future. Retrieved July 2, 2024, from https://digitalstrategy.ec.europa.eu/en/policies/cyber-resilience-act European Union. (2023, December 1). Cyber Resilience Act—Factsheet | Shaping Europe’s digital future. https://digitalstrategy.ec.europa.eu/en/library/cyber-resilience-act-factsheet Gatlan, S. (2024, August 23). US oil giant Halliburton confirms cyberattack behind systems shutdown. US Oil Giant Halliburton Confirms Cyberattack behind Systems Shutdown. https://www.bleepingcomputer.com/news/security/us-oil-gianthalliburton-confirms-cyberattack-behind-systems-shutdown/ 65 Grafana Labs. (n.d.). About Grafana | Grafana documentation. Grafana Labs. Retrieved July 5, 2024, from https://grafana.com/docs/grafana/latest/introduction/ Grafana Labs. (n.d.). Grafana | Query, visualize, alerting observability platform. Grafana Labs. Retrieved July 5, 2024, from https://grafana.com/grafana/ guywi-ms, & AbbyMSFT. (2024, February 29). Azure activity log and activity log insights—Azure Monitor. https://learn.microsoft.com/en-us/azure/azuremonitor/essentials/activity-log-insights Hagaman, A. K., & Wutich, A. (2017). How Many Interviews Are Enough to Identify Metathemes in Multisited and Cross-cultural Research? Another Perspective on Guest, Bunce, and Johnson’s (2006) Landmark Study. Field Methods, 29(1), 23. https://doi.org/10.1177/1525822X16640447 Hahnel, C., Jung, A. J., & Goldhammer, F. (2023). Theory Matters: An Example of Deriving Process Indicators From Log Data to Assess Decision-Making Processes in Web Search Tasks. European Journal of Psychological Assessment : Official Organ of the European Association of Psychological Assessment, 39(4), 271–279. https://doi.org/10.1027/1015-5759/a000776 Haley, C. B. (2008). Security Requirements Engineering: A Framework for Representation and Analysis. IEEE Transactions on Software Engineering, 34(1), 133. https://doi.org/10.1109/TSE.2007.70754 Hampton, L. (2024, August 21). Top US oilfield firm Halliburton hit by cyberattack, source says. Reuters. https://www.reuters.com/technology/cybersecurity/top-us-oilfield-firmhalliburton-hit-by-cyberattack-2024-08-21/ Hellman, G. (2006). From Logs to Logic: Best Practices for Security Information Management. EDPACS, 33(12), 1–10. https://doi.org/10.1201/1079.07366981/46050.33.12.20060601/93398.1 IEC. (2009). IEC/TR 62443-3-1:2009 Industrial communication networks. Network and system security. Part 3.1: Security technologies for industrial automation and control systems. https://webstore.iec.ch/en/publication/7031 IEC. (2019) IEC 62443-3-3:2019 Industrial communication networks. Network and system security. Part 3.3: System security requirements and security levels. https://sales.sfs.fi/fi/index/tuotteet/SFSsahko/CENELEC/ID2/6/76447 0.html.stx IEC. (2019) IEC 62443-4-2:2019 Security for industrial automation and control systems - Part 4.2: Technical security requirements for IACS components https://www.iecee.org/certification/iec-standards/iec-62443-4-22019 66 ISA. (2019). ISA/IEC 62443 Series of Standards—ISA. Isa.Org. Retrieved November 21, 2023, from https://www.isa.org/standards-andpublications/isa-standards/isa-iec-62443-series-of-standards ISO. (2019). ISO/IEC 25010:2019:en Systems and software engineering— Systems and software Quality Requirements and Evaluation (SQuaRE)— System and software quality models. https://www.iso.org/standard/78176.html ISO. (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection. Information security management systems. https://www.iso.org/standard/27001 ISO. (2016). ISO/IEC 27004:2016 Information technology. Security techniques. Information security management. Monitoring, measurement, analysis and evaluation. https://www.iso.org/standard/64120.html ISO. (2015). ISO 9000:2015(en) Quality management systems. Fundamentals and vocabulary. https://www.iso.org/obp/ui/en/#iso:std:iso:9000:ed-4:v1:en JYKDOK. (n.d.). Retrieved November 21, 2023, from https://jyu.finna.fi/MyResearch/Home?auth_method=Shibboleth Kent, K., & Souppaya, M. (2006). NIST SP 800-92 Guide to Computer Security Log Management (NIST Special Publication (SP) 800-92). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-92 Khan, R. A., Khan, S. U., Akbar, M. A., & Alzahrani, M. (2022). Security risks of global software development life cycle: Industry practitioner’s perspective. Journal of Software: Evolution and Process, 36(3), e2521. https://doi.org/10.1002/smr.2521 Khan, S., Gani, A., Wahab, A. W. A., Aminu Bagiwa, M., Shiraz, M., U. Khan, S., Buyya, R., & Y. Zomaya, A. (2016). Cloud Log Forensics: Foundations, State of the Art, and Future Directions. ACM Computing Surveys, 49(1), 1–42. https://doi.org/10.1145/2906149 Krause, R., & Pernice, K. (2024, April 26). Affinity Diagramming: Collaboratively Sort UX Findings & Design Ideas. Nielsen Norman Group. https://www.nngroup.com/articles/affinity-diagram/ Lazar, J., Heidi Feng, J., & Hochheiser, H. (2017). Research Methods in HumanComputer Interaction. Pp. 153, 187–188. Logit.Io Ltd. (n.d.). Top 60 Log Management Tools [2023]. Retrieved December 13, 2023, from https://logit.io Malterud, K., Siersma, V. D., & Guassora, A. D. (2016). Sample Size in Qualitative Interview Studies: Guided by Information Power. Qualitative Health Research, 26(13), 1753–1760. https://doi.org/10.1177/1049732315617444 67 MashaMSFT, rwestMSFT, VanMSFT, rothja, 0x7FFFFFFFFFFFFFFF, ramakoni1, DCtheGeek, fenxu, MikeRayMSFT, suresh-kandoth, TimShererWithAquent, PRMerger19, pmasl, PiJoCoder, craigg-msft, & JaDunn. (2024, July 29). The transaction log—SQL Server. https://learn.microsoft.com/en-us/sql/relational-databases/logs/thetransaction-log-sql-server?view=sql-server-ver16 Mejri, O., Yang, D., & Doh, I. (2022). Cloud Security Issues and Log-based Proactive Strategy. 2022 24th International Conference on Advanced Communication Technology (ICACT), 392–397. https://doi.org/10.23919/ICACT53585.2022.9728822 Metso (n.d.). About us. Retrieved December 13, 2023, from https://www.metso.com/corporate/about-us/ Metso. (n.d.). Digital solutions for Mining. Metso. Retrieved July 4, 2024, from https://www.metso.com/products-andservices/digitalization/digitalization-solutions-for-mining/ Metso. (n.d.). Geminex—Metso. Retrieved July 10, 2024, from https://www.metso.com/mining/solutions/geminex/ Metso. (n.d.). People. Metso. Retrieved July 11, 2024, from https://www.metso.com/corporate/sustainability/engaged-and-diverseexperts/ Microsoft. (n.d.). Explore | Azure global infrastructure experience. Retrieved August 28, 2024, from https://datacenters.microsoft.com/globe/explore?info=region_westeurop e Microsoft. (n.d.). Microsoft Sentinel—Cloud-native SIEM Solution | Microsoft Azure. Retrieved July 12, 2024, from https://azure.microsoft.com/enus/products/microsoft-sentinel MSFTTracyP, joe-davies-affirm, & BrendaCarter. (2024, May 31). How do I pilot and deploy Microsoft Defender XDR? - Microsoft Defender XDR. https://learn.microsoft.com/en-us/defender-xdr/pilot-deploy-overview Myers, M. D., & Newman, M. (2007). The qualitative interview in IS research: Examining the craft. Information and Organization, 17(1), 2–26. https://doi.org/10.1016/j.infoandorg.2006.11.001 NIS 2 Directive. (n.d.). Retrieved February 29, 2024, from https://www.nis-2directive.com/ Odera, D., Otieno, M., & Ounza, J. E. (2023). Security risks in the software development lifecycle: A review. World Journal of Advanced Engineering Technology and Sciences, 8(2), 230–253. https://doi.org/10.30574/wjaets.2023.8.2.0101 OWASP Foundation, Inc. (n.d.). A09 Security Logging and Monitoring Failures— OWASP Top 10:2021. Retrieved August 25, 2024, from 68 https://owasp.org/Top10/A09_2021Security_Logging_and_Monitoring_Failures/ OWASP Foundation, Inc. (n.d.). About the OWASP Foundation | OWASP Foundation. Retrieved August 25, 2024, from https://owasp.org/about/ OWASP Foundation, Inc. (n.d.). Logging—OWASP Cheat Sheet Series. Retrieved August 26, 2024, from https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.ht ml OWASP Foundation, Inc. (n.d.). OWASP Top Ten | OWASP Foundation. Retrieved August 25, 2024, from https://owasp.org/www-project-topten/ Palatty, N. J. (2022, December 15). 100+ Ransomware Attack Statistics 2024: Trends & Cost. https://www.getastra.com/blog/security-audit/ransomwareattack-statistics/ Palo Alto Networks. (n.d.). Strata Logging Service. Retrieved July 10, 2024, from https://docs.paloaltonetworks.com/strata-logging-service Pan, X. (2024). Independent Study of Splunk. OAlib (Online), 11(4), 1–16. https://doi.org/10.4236/oalib.1111496 Pathak, A. (2022, June 21). Software Development Life Cycle (SDLC): A Complete Guide. Geekflare. https://geekflare.com/software-development-life-cyclesdlc-guide/ Pelttari, T. (2022, December 9). Confluence Mobile—DVV external Confluence. Poikkeamien Havaitseminen. https://wiki.dvv.fi/plugins/servlet/mobile?contentId=203565514&fbclid= IwAR0uBSzfO2GVLvVBZ8rv_VqGOQ7iYzIF4mkC3ctde_pJQYyeAQHMZ V9jL60#content/view/203565514 Pluralsight. (2023, June). 2023 State of Cloud | Pluralsight. https://learn.pluralsight.com/resource/offers/2023/state-of-cloud Prometheus Authors. (n.d.). Overview | Prometheus. Retrieved July 5, 2024, from https://prometheus.io/docs/introduction/overview/ Prometheus Authors. (n.d.). Prometheus—Monitoring system & time series database. Retrieved July 5, 2024, from https://prometheus.io/ Ring, M., Schlör, D., Wunderlich, S., Landes, D., & Hotho, A. (2021). Malware detection on windows audit logs using LSTMs. Computers & Security, 109, 102389-. https://doi.org/10.1016/j.cose.2021.102389 Scapicchio, M., Downie, A., & Finio, M. (2024, March 15). What Is a Security Operations Center (SOC)? | IBM. https://www.ibm.com/topics/securityoperations-center SFS Suomen Standardit ry. (n.d.). SFS Online. Retrieved September 14, 2024, from https://online.sfs.fi/fi/index.html.stx 69 shlipsey3, alexbuckgit, miguel-s-ferreira, MicrosoftGuyJFlo, klettier, DavidCBerry13, ktoliver, YajvendraGupta, v-kents, DCtheGeek, ArvindHarinder1, American-Dipper, jdmartinez36, PRMerger17, shashishailaj, ManojReddy-MSFT, MarileeTurscak-MSFT, cawrites, itechedit, … daveba. (2024, March 8). Learn about the audit logs in Microsoft Entra ID - Microsoft Entra ID. https://learn.microsoft.com/enus/entra/identity/monitoring-health/concept-audit-logs Silveira, S. F. (2021, February 9). How Does The Software Development Lifecycle Work And Which Tools Are Essential In All Stages SDCL? - Ubiminds. Ubiminds. You, International. https://ubiminds.com/en-us/softwaredevelopment-lifecycle-sdlc/ SolarWinds. (n.d.). Download Free Network Management & Free Network Monitoring Software from SolarWinds. Retrieved July 5, 2024, from https://www.solarwinds.com/free-tools Spears, J. L., & Barki, H. (2010). User Participation in Information Systems Security Risk Management. MIS Quarterly, 34(3), 503–522. https://doi.org/10.2307/25750689 Staff, H. (2021, July 29). Detecting and Responding to Ransomware: How Logging Everything Helps Mitigate Ransomware Risks. Crowdstrike.Com. https://www.crowdstrike.com/blog/detecting-and-responding-toransomware-how-logging-everything-helps-mitigate-ransomware-risks/ Sugiantoro, B., Anshari, M., & Sudrajat, D. (2020). Developing Framework for Web Based e-Commerce: Secure-SDLC. Journal of Physics. Conference Series, 1566(1), 12020-. https://doi.org/10.1088/1742-6596/1566/1/012020 Söderström, O. (2013). Secure Audit Log Management. Procedia Computer Science, 22, 1249–1258. https://doi.org/10.1016/j.procs.2013.09.212 TerryLanfear, FaithOmbongi, changeworld, DavidCBerry13, v-kents, bwren, DCtheGeek, DennisLee-DennisLee, msmbaldwin, & barbkess. (2023, August 29). Azure security logging and auditing. https://learn.microsoft.com/en-us/azure/security/fundamentals/logaudit The Artificial Intelligence Act - Regulation (EU) 2024/1689. Retrieved August 29, 2024, from https://www.artificial-intelligence-act.com/ The information management board. (2024, March 11). Suositus tietoturvallisuuden vähimmäisvaatimuksista [Sarjajulkaisu]. Valtiovarainministeriö. https://julkaisut.valtioneuvosto.fi/handle/10024/165487 The information management board. (2023, October 25). Suositus tietoaineistojen säilytysajasta ja toimenpiteistä säilytysajan päätyttyä [Sarjajulkaisu]. fi=Valtiovarainministeriö|sv=Finansministeriet|en=Ministry of Finance|. https://julkaisut.valtioneuvosto.fi/handle/10024/165223 70 The Interaction Design Foundation. (n.d.). What is Qualitative Research? — Updated 2023. Retrieved November 15, 2023, from https://www.interaction-design.org/literature/topics/qualitativeresearch Traficom. Collecting and using log data. (2023, March 6). NCSC-FI. https://www.kyberturvallisuuskeskus.fi/en/ncsc-news/instructions-andguides/collecting-and-using-log-data Traficom. Mitä NIS2-direktiivissä esitetyt kyberhygieniakäytännöt ovat? (2024, May 20). Kyberturvallisuuskeskus. https://www.kyberturvallisuuskeskus.fi/fi/ajankohtaista/mita-nis2direktiivissa-esitetyt-kyberhygieniakaytannot-ovat Traficom. Näin keräät ja käytät lokitietoja. (2023, March 6). Kyberturvallisuuskeskus. https://www.kyberturvallisuuskeskus.fi/fi/ajankohtaista/ohjeet-jaoppaat/nain-keraat-ja-kaytat-lokitietoja University of Jyväskylä. (n.d.). Master’s Thesis Seminar. University of Jyväskylä Study Guide. Retrieved August 27, 2024, from https://studyguide.jyu.fi/en/courseunit/kybs5505/ Vaarandi, R., & Pihelgas, M. (2014). Using Security Logs for Collecting and Reporting Technical Security Metrics. https://doi.org/10.1109/MILCOM.2014.53 Väänänen-Vainio-Mattila, K., & Wäljas, M. (2009). Developing an expert evaluation method for user eXperience of cross-platform web services. https://doiorg.ezproxy.jyu.fi/10.1145/1621841.16218 Zhao, P., Wen, Q., Pei-Jung, L., & Peiwei, L. (2024). Reconceptualizing the Link Between Validity and Translation in Qualitative Research: Extending the Conversation Beyond Equivalence. International Journal of Qualitative Methods, 23. https://doi.org/10.1177/16094069241260134 71 APPENDIX 1 OVERALL FINDINGS TABLE 14 Overall findings for good logging practices within SDLC. SDLC step (Khan et al., 2022) Objective (Silveira, 2021) Descriptio n (Silveira, 2021) Security requirements (Khan et al., 2024) Security requirements (Sugiantoro et al., 2020) Log related regulation Log related standard or guideline Log manageme nt use case within the company Good logging practices Requirement engineering An overview of the scope project or software is known. The scope and requirements of the software have been defined. The reviewing, analyzing, and validating of the security requirements is done. The documentation has been done. The security requirements are shared within the development teams. The context of a solution and security impact is known NIS2 needs to be tackled to ensure that the appropriate security measures will be implemented. Cyber security Resilience Act (CRS) to ensure that cyber security of the products and business is in order also with requirements related to logging. GDPR data minimization principle states personal data ISO/IEC 27001, logs recording activities shall be produced, stored, protected, and analyzed. ISA/IEC 62443, access for authorized users for the auditable system events. NIST SP 80092 for log management strategy. Requirements of logs are known and reviewed. Log management infrastructure for logging in place (especially in the target organization). Log management principles and procedures in place. Documented requirements for log management. Prioritizing secure SDLC activities e.g. via awareness, guidance, and training regarding log data. 72 SDLC step (Khan et al., 2022) Objective (Silveira, 2021) Descriptio n (Silveira, 2021) Security requirements (Khan et al., 2024) Security requirements (Sugiantoro et al., 2020) Log related regulation Log related standard or guideline Log manageme nt use case within the company Good logging practices must be limited to what is necessary for the purposes of processing the data. Act on Electronic Communication Services (Regulation 917/2014) a corporate subscriber is obliged to maintain information security of communications, traffic data and location data of their users. Prioritizing log management. Enough staff/resources for log management. Identify which systems and business areas are in the scope of the log management and which log data is valuable. Designing Design specification The overall system architecture is available. Access control and traceability of incidents are tackled into the designs. Authentication and logging are in order. NIS2 needs to be tackled to ensure that the appropriate security measures Identity assurance SOC process Access to the gathered data for the relevant personnel is in place. 73 SDLC step (Khan et al., 2022) Objective (Silveira, 2021) Descriptio n (Silveira, 2021) Security requirements (Khan et al., 2024) Security requirements (Sugiantoro et al., 2020) Log related regulation Log related standard or guideline Log manageme nt use case within the company Good logging practices will be implemented. Act on Electronic Communication Services (Regulation 917/2014) a corporate subscriber is obliged to maintain information security of communications, traffic data and location data of their users. Configuration / Management /Platform assurance Workstation assurance IP Data usage Authentication and logging are defined. Log management tooling is defined (especially in the target organization). Coding Implementation of the defined solution The components of the software are implemented. Potential security issues are tackled in coding. The approved tools are used, and implementations are done with the latest versions. NIS2 needs to be tackled for implementing the appropriate security measures. Cyber security Resilience Act (CRS) to ensure ISO/IEC 27004 that the log management has been documented. ISA/IEC 62443 with referencing to OWASP. Operation IT with incident troubleshooting and audit trail Shared documentation with secure coding practices. The log data should also be backed up and log entries