Reflections

At the beginning of the module, an examination of common definitions of information risk management was made and Information Security Management concepts were introduced. Furthermore, a discussion on the definition of the terms risk and risk management and approaches to quantitative and qualitative assessment options was carried out within the framework of the seminar. Getting started with the module provided a general introduction to the topic. A lot of what was already discussed in the previous module, "Network and Information Security Management", was taken up again and the knowledge was refreshed. I see the fact that there is no agreed definition of risk as such, and that it is interpreted differently by different sources, as a finding that needs to be emphasized. As a result, finding suitable evaluation criteria can be made more difficult. As a general but fundamentally satisfactory definition, I think the equation Risk = Threat * Vulnerability * Asset can be used. This shows the aspects that contribute to the creation of the risk, but also establishes that risk is a quantifiable value. Another question to be reflected is whether an assessment of risk should be undertaken on a purely quantitative level, or whether a qualitative assessment also has a right to exist? While an obvious answer to the question could be 'Yes, within the scope of the possible applications', the question arises as to what applicable use a purely qualitative assessment has in the context of Information Risk Management, since such an assessment has no comparable value other security aspects and also no directly usable comparison of companies is possible. A risk that is classified as 'high' in one company may only be 'medium' or 'low' in another company on the basis of proportionality. Two risks can also be classified as 'high', but have completely different consequences if a breach occurs. While an information disclosure breach can generate reputation and financial damage and is therefore classified as 'high', a tampering breach, which is also defined as 'high', can result in the entire database being deleted and the company being unable to act. Both events have a high impact on the company, however, in one case the image will be damaged and financial damage may occur, while in the other situation the company may become incapacitated. In this example, it is noticeable that comparability on a qualitative level is difficult. One could now argue that the risk of information disclosure can also be classified as 'medium' and thus a ranking is created, but there are many other risk scenarios, so that a subdivision of 'lowest', 'low', 'medium', 'high', 'highest' arises. At this point at the latest, it is noticeable that further subdivision inevitably results in a quantitative evaluation matrix, since the terms should be given better than a numerical value from a certain number. This leads to the simple conclusion that an Information Risk Management investigation, if considered sufficiently in-depth, always results in a quantitative assessment. Due to the lack of participants in the seminar, the discussion was unfortunately limited, so that this argumentation approach could not be addressed satisfactorily. However, it shows how complex information risk management and the definition of suitable evaluation criteria and definitions can be.

The subject of this unit was a discussion between qualitative and quantitative assessment approaches. The positive influence of user participation in the risk management process was also discussed. While the application of qualitative and quantitative risk management assessment methods raised questions in the last unit, a better idea could be developed in this unit. The understanding of the respective advantages of the evaluation approaches in the respective situations leads to a better assessment of possible applications. This includes the realization that, depending on the context, a qualitative or quantitative assessment is preferable. Especially in situations where a quantitative assessment can give a misleading picture of a complete understanding of all parameters, a qualitative assessment should be considered. Furthermore, there are contexts in which a quantitative assessment is difficult or impossible. The discussion in the seminar was able to provide many insights. Considering the positive influences of users on the risk management process has also opened up a new perspective. While in many studies one of the greatest risks for security incidents is due to insider threats, positive factors of participation in security infrastructures could be identified during the unit and the seminar session (Giandomenico & Groot, 2020). The study by Spears & Barki (2010) has shown that the participation of users in risk management not only creates greater awareness of the importance of security aspects and their importance, but can also increase the efficiency of the security department. In addition, users can contribute to increasing the quality of the security infrastructure with their business-related perspective, since they are the active users of this infrastructure and can therefore impart practical experience and application-related knowledge about the system. This knowledge moves the users of an application from a potential source of danger to a positive influence. Changing perspectives and emphasizing positive user impacts on security is important to harness the potential of this resource to ensure security infrastructures are as effective as possible.

• Giandomenico, N. & Groot, J. (2020) Insider vs. Outsider Data Security Threats: What’s the Greater Risk? Digital Guardian. Available from: https://digitalguardian.com/blog/insider-outsider-data-security-threats [Accessed 13 March 2022].
• Spears, J. & Barki, H. (2010) User Participation in Information Systems Security Risk Managment. Management Infromation Systems Research Center, University of Minnesota. Available from: https://www.jstor.org/stable/25750689 [Accessed 14 March 2022].

The aim of this unit was to gain insights into the Software Development Life Cycle (SDLC) and to examine methods with which the process can be carried out and improved. Furthermore, risks were determined in the individual phases of the SDLC and mitigation measures were determined. In the historical considerations of the development of SDLC methods, it is noticeable that there was a move away from the waterfall method towards agile methods and that these have advantages compared to the waterfall method due to time aspects but also security aspects. Breaking the linear and rigid course of software development and implementation enables faster and more application-oriented development, in which the interests of the stakeholders are brought to the fore. For me, this change in development towards customer-oriented software development is, on the one hand, a purely logical process in order to react to the requirements of interest groups in relation to the rapidly growing market of digitization and SaaS and, on the other hand, to do justice to the security aspects of such a development (Soofi et al., 2014). I also consider an agile SDLC approach to be more product-oriented, since the requirements for the software can change during the development process and the ultimately expected features of the software may not be achieved with a rigid structure. Furthermore, the Agile approach offers more opportunities to influence new security gaps and vulnerabilities, so that a potentially more secure program can be developed. The DevOps approach can also contribute to this (Bass, 2018). The consideration of the risks in the individual phases of the SDLC has shown which priorities must be set in the individual phases of development. It was interesting to see which individual aspects have to be considered and the form in which risks can occur. The status Report, which is completed and submitted in this unit, helps to develop further competencies within the framework of risk management. This provides a basis for the Risk Assessment Report planned later on, which will examine these aspects in more detail and thus train the competence of reflected risk awareness and risk assessment, as well as analysis.

• Bass, L. (2018) The Software Architect and DevOps. IEEE Software, 35(1): 8-10. Available from: https://www.computer.org/csdl/magazine/so/2018/01/mso2018010008/13rRUx0gedI [Accessed 26 March 2022].
• Soofi, A., Khan, M., Talib, R. & Sarwar, U. (2014) Security Issues in SaaS Delivery Model of Cloud Computing. International Journal of Computer Science and Mobile Computing. 3(3):15-21. Available from: https://d1wqtxts1xzle7.cloudfront.net/33147894/V3I3201401-with-cover-page-v2.pdf?Expires=1648200555&Signature=CI7Ulg~jlAW5EcqXb8ScIWOerUIiHggNPCMyCOTjPNtfY6j9cPhP0OZyYf~i-ftobRi5i8Z2Kuvf4o4hd55jfz5RgQbzJn9pV0bDEnWJO9P2ZfCoSE-Huba6G5-rNwZX5vFnQwbSGKXlzkwhUXRB7WycdjrghTTjMXvrwJX2TKbhafaC6AN0YQUXOgPyI1OTDkG6RV5in9pk1rhVNv2PewMeAILGCd395GQJfGMDjd0364E~7VkDJtLd6cyEI~BhEIT5V-0zU3b3smZNF4-B6uemiTc8XIJe05paVjGsR0H0Wlio5S0qU0x1H6LIoP3~JPgwZZJUWLZRmnj~62fWGw__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA [Accessed 25 March 2022].

The subject of the unit was an investigation of risks and their impact on the Software Development Life Cycle (SDLC). The most significant risks in the individual phases of software development were analyzed and reduction approaches determined. An interesting finding was to see how the choice of methodology can influence risk mitigation strategies. During the seminar, various approaches to structuring SDLC, such as the waterfall or the agile approach, were discussed. It was recognized that the agile approach is often a better choice in terms of risk minimization, since this approach can influence the final product at various points. However, situations were also discussed in which the waterfall approach offers advantages, for example if the project is relatively small, as this may enable the project to be implemented more quickly. When looking at the DevOps approach, I noticed that it should be pursued as a matter of principle, as it provides the framework for secure software development. Since DevOps can be used with both the waterfall and the agile approach, it offers a good complement to both SDLC methods. The examination of the risks during the phases of the SDLC has shown the multitude of potential risks that can occur and what needs to be considered in the respective phase. Thus, Hijazi et al. (2014) characterized one hundred risks in the phases of the SDLC. On the one hand, this large number of risks shows which hurdles software development can be confronted with. On the other hand, this illustrates the importance of detailed planning of a project (Sugiantoro et al., 2020). The seminar was a great help for me to expand my knowledge, as the discussion highlighted various aspects, which expanded my horizon of experience.

• Hijazi, H., Alqrainy, S., Muaidi, H. & Khdour, T. (2014) RISK FACTORS IN SOFTWARE DEVELOPMENT PHASES. European Scientific Journal. 10(3): 1-20. Available from: https://www.researchgate.net/profile/Thair-Khdour/publication/266144501_Risk_Factors_in_Software_Development_Phases/links/542806610cf2e4ce940c36cc/Risk-Factors-in-Software-Development-Phases.pdf [Accessed 28 March 2022].
• Sugiantoro, B., Anshari, M. & Sudrajat, D. (2020) Developing Framework of Web Based e-Commerce: Secure SDLC. Journal of Physics: Conference Series. 1566(1):1-9. Available from: https://iopscience.iop.org/article/10.1088/1742-6596/1566/1/012020/pdf [Accessed 03 April 2022].

This unit focused on business continuity (BC) and disaster recovery (DR) plans. The factors Business Impact Assessments (BIA), Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) were examined as determining factors for BC and DR plans. BC represents a fundamental aspect for a functioning company and is a central part of risk management to prevent unwanted situations and to reduce their impact. It was interesting to see what recommendations exist to ensure BC. In addition to the standards that ISO 22301 specifies, an important finding was that a BC plan must be regularly checked to ensure it is up to date in order to be able to do justice to changes in the company and external influences (ISO, 2019). Therefore, part of the BC plan is the BIA, which evaluates the potential risks and the associated costs of an incident on a quantitative level. In order to be able to react appropriately to the dangers, the factors RTO and RPO represent two factors within the framework of cyber security, which must be tailored to the company-specific requirements in order to reduce the damage as effectively as possible in the event of an incident. The various strategies that were discussed were an interesting starting point. Depending on business needs, such an RTO can be less than 1 hour to over 48 hours, with an RPO ranging from less than 1 minute to more than 24 hours. Factors terminating this is the choice of digital infrastructure to ensure DR. While a short RTO and RPO should be targeted, these features also come with a higher cost. With a view to their corporate structure and industry, companies must therefore evaluate which structure meets the respective requirements (Hamadah, 2019). In order to carry out such an assessment, the individual requirements can first be determined using the categories: Availability, Recoverability, Resilience, Data Corruption and Regions. This first insight into BC and BIA has therefore shown me that the one-size-fits-all approach does not apply. BC and BIA plans must be adapted to the corporate structures and regularly checked to ensure that they are up to date in order to meet the requirements of risk management.

• ISO (2019) Security and resilience - Business continuity management systems – Requirements. Available from: https://nobelcert.com/DataFiles/FreeUpload/ISO%2022301%20(2019).pdf [Accessed 08 April 2022].
• Hamadah, S. (2019) Cloud-Based Disaster Recovery and Planning Models: An overview. ICIC Express Letters. 13(7): 593-599. Available from: https://www.researchgate.net/profile/Siham-Hamadah/publication/337389708_ICIC_Express_Letters_ICIC_International_c_2019_ISSN/links/5dd52d4da6fdcc37897b1e8c/ICIC-Express-Letters-ICIC-International-c-2019-ISSN.pdf [Accessed 09 April 2022].

This unit has created an outlook on the future of Information Risk Management. Furthermore, hard problems defined by the NSA in relation to IRM were examined. The requirements for IRM are subject to an appropriate pressure to adapt, particularly due to the rapid change in cyber security, which is due to the enormous development of new opportunities offered by the further development of the Internet, but also the associated dangers. Technical advances, for example in relation to machine learning and risk management, can help to develop better BCP and DR plans. The seminar in this unit was very informative, as a bridge was built from the BCP, DR, RTO and RPO discussed in the previous unit and their interdependence in IaaS and IaC. With this in mind, considerations could be made as to which technical advances could contribute to a more stable BCP, but also which additional or new threats could arise as a result. The hard problems related to security science listed by the NSA provide a general overview of the issues to be considered when developing and using digital architecture (Adam, 2015). It should be noted that these five hard problems, Scalablity and Composability, Policy-Governed Secure Collaboraton, Security Metrics Driven Evaluation, Design, Development and Deployment, Resilient Architectures and Underatanding and Accounting for Houman Behavior, are not actually new insights, but rather because of the new requirements must be viewed from modified perspectives. It should be emphasized that the enormous development, especially with regard to the Internet, cloud computing and IoT, requires a new focus in order to adequately evaluate the five hard problems mentioned and to apply them in the new context.

• Adam, T. (2015) The Science of Scruity 5 Hard Problems. Science of Security and Privacy. Available from: https://cps-vo.org/group/sos/hardproblems [Accessed 18 April 2022].

In the Information Risk Management module, a risk analysis was carried out as part of a team project for a company that wanted to embed an Enterprise Resource Planning (ERP) system in their company. Since miscommunication has turned out to be one of the central risk factors in risk management, software development within the framework of the SDLC, as well as teamwork in projects and the risks of miscommunication are discussed below. Hijazi et al. (2014) describes miscommunication as a risk factor that occurs in all phases of the SDLC and sees the dangers of this risk in the developers' understanding problems with regard to the software functions to be implemented or unrealistic expectations on the part of the users. It should be noted that miscommunication not only represents the character of communication, which leads to a different understanding of the subject of communication due to poor communication practices, but also the lack of communication can be defined as miscommunication (Anolli et al., 2002). As a result, the understanding of the term is expanded to include a context, which means that a better clarification of the requirements for successful communication can be determined. Nottingham (2014) highlights that company executives report that they spend 30% of their time dealing with risk issues, but the biggest challenges lie in a unclear understanding of the objectives of risk management processes and structures. This emphasizes the importance of functioning communication in order to work productively and in a time- and cost-oriented manner. In addition, poor communication can lead to frustration between task groups, stakeholders, and managers, which can lower morale (Aoyama et al., 2015). This clearly shows the importance of miscommunication as a risk factor in Information Risk Management. The risk in this regard, in my view, lies not only in the insufficient development of software related to the SDLC, emerging dangers and untapped potential for better implementation of security structures, but also in a psychological factor that reduces productivity, as well as working atmosphere and could cause long-term damage to the company's reputation. These findings also have implications for my consideration of the risk of miscommunication in a team. While the communication in the team of the Information Risk Management module can be described as good, I brought negative experiences in this context to the teamwork of the module. In the past, the teamwork in my teams was partly characterized by miscommunication, which often showed itself through a lack of communication. This made scheduling more difficult, and tasks were not evenly divided, resulting in additional work for individuals and the potential of teamwork not being satisfactorily used. The positive experience in terms of communication, which I was able to experience in this team, showed me the importance of functioning communication and motivated me to actively contribute to a positive communication climate and to take on the role of communication manager. Furthermore, this encourages me to further train my skills for future teamwork. In order to be able to further develop my skills in this context, practices should be trained that have a positive influence on the communication climate, but also study a definition-oriented rhetoric to avoid miscommunication. A positive influence on my professional future is clearly recognizable in increasing skills in terms of teamwork and as a manager.

• Anolli, L., Ciceri, R. & Riva, G. (2002) Say not to say: New perspectives on miscommunication. Available from: https://books.google.de/books?hl=de&lr=&id=PsiLjRHr1JQC&oi=fnd&pg=PR5&dq=miscommunication+definition&ots=GnMiUpVJh0&sig=b8dSxVZtQtrRrQIezVqPs5AFQLU#v=onepage&q=miscommunication%20definition&f=false [Accessed 08 April 2022].
• Aoyama, T., Naruoka, H., Koshijima, I. & Watanabe, K. (2015) How management goes wrong? – The human factor lessons learned from cyber incident handling exercise. Procedia Manafacturing. 3: 1082-1087. Available from: https://reader.elsevier.com/reader/sd/pii/S2351978915001791?token=269732F4AE556CC332128E76128A529074BE74BDA60FEE7ABAB95D7B7038C0EADFDFA775E58554849EFE6BF820C78EB3&originRegion=eu-west-1&originCreation=20220402084124 [Accessed 10 April 2022].
• Hijazi, H., Alqrainy, S., Muaidi, H. & Khdour, T. (2014) RISK FACTORS IN SOFTWARE DEVELOPMENT PHASES. European Scientific Journal. 10(3): 1-20. Available from: https://www.researchgate.net/profile/Thair-Khdour/publication/266144501_Risk_Factors_in_Software_Development_Phases/links/542806610cf2e4ce940c36cc/Risk-Factors-in-Software-Development-Phases.pdf [Accessed 08 April 2022].
• Nottingham, L. (2014) Risk communication. Available from: https://www.marshmclennan.com/content/dam/mmc-web/Global-Risk-Center/Files/Risk-Communication-Feb-2014.pdf [Accessed 09 April 2022].