Abstract
While approaches aimed at developing forensic-ready systems are starting to emerge, it is still primarily a theoretical concept. This paper presents a case study of integrating forensic readiness capabilities into SensitiveCloud, an information system for storing and processing sensitive data. A risk-based approach to forensic readiness design is followed to achieve it. Consequently, weaknesses in both processes and systems are identified, and forensic readiness requirements are formulated. This case study reports on lessons learned in a practical implementation of a forensic-ready system, its impact on security, and its support towards ISO/IEC 27k.
You have full access to this open access chapter, Download conference paper PDF
Similar content being viewed by others
Keywords
1 Introduction
Information security is, without a doubt, a key component of information systems, as there is an incentive to keep its data protected against misuse [23]. This incentive stems from regulations, legislation, competitive pressure, contracts, and risks of reputation or financial loss. Security is ever so important for information systems working with highly sensitive data, like biological research or medical records. In these cases, a data leakage could expose the sensitive information of individuals and lead to severe fines, making such systems a very lucrative target.
As such, users might be concerned about security when entering data into the system. Indeed, data breaches have been caused by inadequate security risk mitigation [12]. To dispel such concerns and testify due diligence in security, information systems can work towards security certifications (e.g., ISO/IEC 27k family of standards [21]), demanding continuous improvement of security posture, i.e., security status, resources, and capabilities in the organisation [22].
However, security can never be taken as absolute. Thus, forensic readiness [32] aims to prepare for digital forensic investigations and scenarios requiring digital evidence [7, 27], complementing the security practice [17]. Recently, it was approached from a software engineering perspective, creating the notion of forensic-ready software systems [25] or systems forensic-by-design. They include requirements for conducting sound forensic processes and generating sound evidence.
The methods for designing and developing forensic-ready systems still cannot be considered mature and are mostly theoretical. As many conceptual frameworks feature risk management, we formulated Forensic-Ready Information Systems Security Risk Management (FR-ISSRM) [10], a risk-based design approach, to bridge this gap. Still, a practical demonstration and evaluation are missing.
This paper presents a case study on developing a forensic-ready system following the FR-ISSRM approach. It allowed identifying weaknesses in incident handling and investigation, remediable by implementing forensic readiness requirements and gaining insight into set security processes. Additionally, our contribution serves as material for the information systems engineering community, providing a practical reference for theoretical concepts.
2 State of the Art
Related Work. The importance of implementing forensic readiness was highlighted in a few studies. For example, three security incident investigations in public administration, finance, and manufacturing domain were assessed in [24]. The study exposed inadequacies which led to the failure to investigate the incident or to prevent it. Another study examining devices deployed in smart grid infrastructure showed a severe lack in supporting the investigation of attacks [19].
Traditional forensic readiness controls are organisation-focused, including plans for investigation cost-effectiveness and minimal business interruption [18], escalation policies [27], and personnel training [7]. Then, system-oriented controls address evidence storage [3, 30], integrity [33], and proactive preservation [4]. In the cloud domain, forensic-supporting architecture is proposed [34]. Attention is also given to the representation of forensic-ready systems, utilising Sequence Diagrams [26], or Business Process Model and Notation (BPMN) [10].
Implementation of forensic readiness is a topic of numerous guides, standards, and frameworks. Table 1 presents the overview, denoting addressed aspects and focus on a specific domain. It notes their addressing of systems, specifying requirements, including an implementation process, model support, evaluation techniques, and risk assessment, too. Risk management is a part of forensic readiness implementation approaches [1, 16, 27]. In the area of information systems (IS), there is Information Systems Security Risk Management (ISSRM) [11, 23], a model-based approach harmonising the security risk management for IS. It has been practically applied [2], shown to cover ISO/IEC 27k requirements [14], and integrated with enterprise architecture [15]. It supports modelling approaches (e.g., Risk-Oriented BPMN [5]), including extension of ArchiMate [15].
Forensic-Ready Risk Management. From a security standpoint, forensic readiness is considered an add-on [9] to cover residual and low-probable risks, assuming that an incident eventually occurs. A Forensic-Ready Information Systems Security Risk Management (FR-ISSRM) [8] was formulated to conceptualise risk management in forensic readiness. This allows systematic assessment of forensic readiness and assists in formulating requirements for forensic-ready software.
The FR-ISSRM concepts are organised in a domain model, visualised in Fig. 1, as an extension of the ISSRM domain model [11]. Asset is anything valuable that has a part in the organisation’s objectives. It is divided into an Information System (IS) Asset (i.e., a component of an IS) and a Business Asset (i.e., information, processes, capabilities, and skills). The Risk is a combination of a Threat with one or more Vulnerabilities leading to a negative Impact on Assets. The combination of a Threat and Vulnerabilities represents an Event [23]. FR-ISSRM adds Evidence, a Business Asset representing a piece of information potentially usable in digital forensic investigation, its point of origin (Evidence Source) and retrieval (Evidence Store). The purpose of implementation of forensic readiness is captured by Forensic Readiness Goal (FR Goal). Together, they contribute to Forensic Readiness Scenario (FR Scenario), describing how exactly is a FR Goal addressed, using the Evidence, and covering a particular Risk. Then, the Forensic Readiness Requirement (FR Requirement) is a condition to be satisfied in the system to meet the FR Goal, and Forensic Readiness Control (FR Control) is its implementation.
A model-driven approach of forensic-ready risk management is enabled by BPMN for Forensic-Ready Software Systems (BPMN4FRSS) [10] modelling notation, an extension of BPMN. The models capture the parts of a system, supporting decision-making in the forensic-ready risk management process. Specifically, the analysed part is modelled as a process using BPMN [23]. It describes systems activities (Task), happenings (Event), exchanged data (Data Object), parts of the system and other participants (Pool), and communication between them (Message Flow). Then, BPMN4FRSS enhances it with forensic readiness aspects, the most important being Evidence (stereotyped Data Object) and Evidence Source (magnifying glass symbol). Figure 2 shows an example of a BPMN4FRSS diagram. Additionally, model-based metrics are formulated to evaluate evidence quality and their coverage in the process [8].
3 Research Method
The case is SensitiveCloudFootnote 1, a system run in an academic environment, a platform for the computation and storage of sensitive data. It aims to support medical research implying a security need. Technologically, the system is built on Kubernetes (K8s), a container orchestration platform managed by Rancher [31], accessible through Wireguard virtual private network (VPN). The SensitiveCloud team involved in the study (henceforth Team) consists of three technical specialists (K8s and DevOps), a security manager and an executive manager, where security and executive managers are also co-authors of this paper.
Employed security controls are primarily based on ISO/IEC 27k [21], aspiring for certification. Forensic readiness is considered in conjunction with it to improve the security posture further. It is expected to contribute towards observability (ISO/IEC 27001:2013 Annex A.12.4), incident response (ISO/IEC 27001:2013 Annex A.16.1), and legal compliance involving evidence release.
3.1 Research Questions
The study follows the FR-ISSRM implementation process [8], describing the procedure of specifying forensic readiness concepts. However, the plausible way of implementing forensic readiness in a real system is unknown, as the FR-ISSRM concepts must be instantiated and evaluated from empirical data. Therefore, we derived research questions (RQ) to frame the effort, addressing areas of the FR-ISSRM implementation process vital for the practical development of a forensic-ready system. They divide the problem into the design using FR-ISSRM (RQ1), its assessment (RQ2), and understanding its impact on the system (RQ3).
RQ1: What data is needed to establish a forensic readiness model of an existing information system? Forensic readiness relies on information about the system, which can be compiled into a model. However, the feasibility, manner, and implications of its instantiation from available knowledge of a system are crucial in a real environment. The answers shall be built on gathered artefacts and enquiries.
RQ2: How can the forensic readiness of a system be evaluated based on the established model and empirical knowledge? While metrics for static analysis of the model exist, they have several limitations in preciseness. Moreover, the model built on empirical knowledge is likely imprecise due to unintentional misspecification or omission. Thus, the evaluation of the system should go beyond the model itself and enrich it with empirical knowledge. The answers shall be based on model-based metrics and simulated incident investigations.
RQ3: What are the effects of FR-ISSRM process execution and its artefacts on the security posture? Conduction of the FR-ISSRM process is expected to provide insights into forensic readiness and related subjects regarding the system in question, namely security monitoring and incident handling. Therefore, an inquiry shall be made on those subjects and lessons learned from the stakeholders.
3.2 Research Design
In this study, guidelines for conducting case studies [28] were followed. It is action research, as the main author oversees the forensic readiness implementation.
The foundation of the study is the FR-ISSRM implementation process, supplemented by empirical evaluation. Initially, FR-ISSRM was presented to the Team by the authors of this paper in the level of detail required to perform the study. The study consists of three phases, during which the authors interacted with the Team to collect, create, and analyse materials for the study.
Mapping Phase is concerned with mapping the available knowledge and compiling it into a model of the system. Primarily, security risk management documentation is reviewed for Assets and Risks. Then, concrete incentives for forensic readiness, FR Goals, are established and mapped on the Risks, leading to the definition of FR Scenarios with Evidence Sources. Lastly, a subset of FR Scenarios is selected as units of analysis. Chosen FR Scenarios are captured in BPMN4FRSS [10] notation, supported by our diagramming toolFootnote 2. The authors explained the notation to the Team and consulted the diagrams afterwards.
Evaluation Phase uses the models to evaluate the forensic readiness of the system (both organisational and technical). The aim is to assess that the occurrence of FR Scenarios can be reliably investigated. First, purely model-based metrics are computed by the authors, providing a quick estimation. Then, the models are used to construct a simulated incident by a member of the Team, akin to forensic readiness exercise [7, 27], planned based on a protocolFootnote 3, prepared by the authors to minimise the impact on a system. It focuses on verifying implemented controls, a sound investigation process, and a discrepancy between expected and actual potential evidence. Lastly, the simulation is executed by the Team.
Feedback Phase processes the results by the authors, based on which treatments, the FR Requirements, are formulated, addressing the shortcomings in the system and adjusting the models. Moreover, a semi-structured interview is conducted with the Team, discussing their perception of the process and results. The aim is to use the results and gained experience to enhance the system.
4 Mapping
The SensitiveCloud’s business goal demands security risk awareness by design. This awareness also applies to forensic-ready systems. Identifying what needs to be ready, for what circumstance and why is the first step of the implementation.
Security Risk Management is a prerequisite for conducting FR-ISSRM. Therefore, its documentation must be reviewed for alignment issues with FR-ISSRM. We note two obstacles. The first is a lack of Business Asset (i.e., primary in ISO/IEC 27k [21]) while focusing only on the IS Assets. Remediation is expanding the asset definitions with the Team. The second is a very abstract formulation of risks based on threat catalogue entries. Such risks are instantiated with a concrete Business Asset relation as part of FR Scenario modelling.
Forensic Readiness Goals are formulated to capture the incentive for forensic readiness as a claim towards a Business Asset. In total, 13 FR GoalsFootnote 4 were conceived from a discussion with SensitiveCloud management. They focus primarily on having trustworthy data in the case of investigating a data breach, addressing the protection of logs and audit requirements of ISO/IEC 27k [21], customer disputes, and legal obligations for evidence release. For this study, FR Goals listed in Table 2 are selected as their investigation is deemed most probable.
Forensic Readiness Scenarios describe a concrete occurrence of a Risk in the system, which generates Evidence addressing an FR Goal. However, the abstract risks made their direct instantiation difficult. Instead, the authors together with the Team created asset-level models, describing a process of regular operation involving the Business Assets, which abstract risks can affect. For example, Wireguard VPN Connection can be affected by an Impact Leaked VPN key due to a Physical theft of the admin’s laptop Event. The Asset-level models were captured as a brief textual description (e.g., Establishing access to the SensitiveCloud private network using Wireguard). However, due to criticality, those related to the Logical perimeter access policy were modelled as processes using BPMN4FRSS [10] notation (e.g., Fig. 2). Then, their initial Evidence Sources were identified through discussion with the Team.
Proper Risks are created by mapping the abstract ones onto asset-level models, which are then inspected for relevance with FR Goals. The Risk, FR Goal, and Evidence from the asset-level models are sufficient to define an FR Scenario. Notably, multiple FR Goals are found relevant to one Risk with the same Evidence. While it formally leads to multiple FR Scenarios, we merged them to reduce the quantity. In total, 118 FR Scenarios is defined (344 unmerged).
Unit of the Analysis for this study is chosen as a composite from the most high-risk FR Scenarios. Figure 3 shows the BPMN4FRSS diagram, and Table 3 contains descriptions of Risks. The composite combines three FR Scenarios into a complex chain of attack, addressing data leakage and tampering. It is selected by the Team, due to the probability and Impact of the Risk.
5 Evaluation
Initially, the Team did not find an issue regarding forensic readiness, as they followed the standard observability practice. The asset-level models with Evidence, were agreed to reflect the system and set FR Goals are covered. This claim is tested, examining if an investigation can be reliably performed.
Model-based Forensic Readiness Metrics [8] derived from the model in Fig. 3 are summarised in Table 4. Relative Evidentiary Value (REV) estimates the Evidence’s trustworthiness. It combines tamper resistance of creation TR (the value is proportional to the privilege required), a sum of independent copies \(\mathcal {S}_C\), and links from the same \(L^{=}\) and different \(L^{\ne }\) contexts (process’s participants). Links mean a sum of base values B of other evidence that can be corroborated (e.g., by equality), with the same context being penalised by a sum of managed contexts. Scenario Coverage (SC) is a ratio of components of the process model (divided by message flow) with an Evidence Source \(\mathcal {\hat{K}}\) and all its components \(\mathcal {K}\), scoped to managed contexts and the whole composite scenario.
While they indicate a good posture, due to corroborability on K8s level, three weak spots are identifiable. Firstly, the value of Wireguard Connection and Wireguard Log is diminished by non-inclusion in the central log storage, retaining a single copy. Secondly, the links with Wireguard Connection are unknown in the prior models, diminishing REV and is an issue in the investigation. Lastly, no Evidence of Rancher’s response is created, lowering SC. Moreover, the metrics do not reflect volatility, which is found to be an issue for Wireguard Connection.
Simulated Incident is a more complex validation method. It is based on conducting an artificial attack presented in Fig. 4, from the Risks described in Table 3. The attack deals with disclosed and modified data on the SensitiveCloud storage due to leaked access credentials on the user side. The Team’s task is to handle the incident and investigate its scale and root cause, which puts the forensic-ready system to the test in a realistic manner.
Notably, the simulated incident is performed on the live system, akin to penetration testing. Careful planning is mandatory not to disturb the system’s operation. It includes the preparation of Kubernetes deployment and user account, including the full onboarding process and subsequent clean-up.
A successful test means formulating an answer to the investigation query backed by a correlated chain of Evidence. Furthermore, each Evidence should be corroborated by at least one other independent Evidence.
Investigation of the simulated incident sought to answer a compound query: Which data was accessed, who accessed it and how? To answer it, the Team used Evidence compiled in Table 5. It shows which Evidence was recognised before the incident, what was actually collected, and what was used for the answerFootnote 5.
The simulation started with an email from a user to the SensitiveCloud contact address, reporting unknown data on the storage and sensitive data published online. First, the Team realised that the user was part of a research group, having a single project utilising a shared service identity with the required permissions. On learning this, Team changed the configuration of Wireguard VPN to deny access with the shared identity in case it was compromised. Likewise, storage permissions were also revoked to restrict further access to sensitive data.
With the access restricted, the Team went through logs to answer the query. First, based on the Wireguard Log, they identified an IP address not belonging to the research group. Thus, bolstering the suspicion of credential compromise. Next, aiming to determine accessed resources, the Team found that the Kube-API Audit did not record any data due to misconfiguration. They assumed the attacker accessed the container directly, based on Rancher Ingress Log, but could not confirm it due to a proxied IP address routed by Rancher. The extent of affected data was determined only from unreliable Container Bash History.
Ultimately, the investigation failed to reliably answer the query due to unverified assumptions and dependence on unreliable data. Therefore, a complete chain of Evidence was not established, nor was it corroborated by another source.
6 Feedback
This chapter sums up the results and feedback provided by the Team members. It is used to propose enhancements to the system and its processes.
Forensic Readiness Requirements, listed in Table 6 are suggested to the Team for implementation to address the shortcomings, thus enhancing the presented composite FR Scenario. The simulation uncovered the following issues to remedy: Used Evidence was not confirmed from another source nor created a complete chain (due to IP hidden behind routing proxy); misconfigured audit logging caused missing, expected, Evidence; Evidence from Wireguard VPN is volatile and thus might be unavailable. Furthermore, combining the results with the model shows reliance on tamperable data from a container, which should be correlated with independent Evidence or coming from a more privileged source.
Incident Handling Shortcomings are also to be addressed. The documentation was incomplete for several critical system components (e.g., Wireguard VPN, Rancher internal routing). Thus a single point of failure (parts that only a single person could investigate) was identified. This manifested in the spoilage of Wireguard Connections due to changing the configuration before securing the Evidence. An issue was also found in verifying the incident reporter’s eligibility.
Interviews with Team members were then conducted to gather opinions on forensic readiness, evaluate the experience with the process, and identify lessons learned. The transcriptions were coded by open coding, followed by axial codingFootnote 6.
Primarily, the hands-on experience with the forensic readiness, and namely the simulation, represented a learning opportunity contributing to the general security-related awareness. “It is basically a form of training for the team, a tool to testify proper workings of the processes.” The simulation, exploiting the benefits of gamification, provided an enlightening and practical perspective on the security of the SensitiveCloud design and operation.
The FR-ISSRM concepts and modelling via BPMN4FRSS diagrams motivated consideration of the system from another angle. “It somehow pushes a person to think about it from a different angle than before. Or you need to look at it from the security point of view.” It helped to think of hidden relations and interactions, which served as a valuable input to the documentation design and filled gaps in yet undocumented aspects of the system. However, the models are seen as laborious, too formal, and hard to grasp, albeit helpful in the end. “The formalism is really an overhead, but looking back, when I don’t need to do it. It is, in fact, very interesting and valuable.”
Forensic readiness was affirmed as a practical complement to ISO/IEC 27k. “For me, it is one of the iterations of the Information Security Management System.” It increased the maturity of the Team by shifting towards a security-oriented perspective, and the simulation added structure to the abstract notion of security. “Suddenly people start to think about the business side of how to make the system somehow transparently, securely, \(\ldots \)” It was agreed that verifying the forensic readiness of the system should be included in the security plan.
7 Discussion and Conclusion
In this case study, we utilised the FR-ISSRM approach to design and analyse forensic readiness capabilities in SensitiveCloud, an information system for storing and processing sensitive data. Together with the Team, we established the incentives for FR Goals and mapped them onto the system Assets and Risks. Then we evaluated the system to elicit FR Requirements where the FR Goals are unfulfilled. Additionally, we updated the incident handling process.
7.1 Answers to Research Questions
RQ1: What data is needed to establish a forensic readiness model of an existing information system? Assets, FR Goals, Risks, and Evidence, are the basic blocks of a forensic readiness model. Based on them, FR Scenarios can be compiled.
However, we noticed that the Risks need to be described in detail. An abstract, catalogue-like definition is insufficient as it is harder to identify the Evidence. Therefore, we opted for modelling the Assets as scenarios of their regular operation, on which we instantiated the abstract risks into ISSRM Risk.
The FR Goals steer the implementation. However, we note an incentive to focus on IS rather than Business Assets in defining them, which complicates further decisions. A remedy was proposed to first define higher-level business drivers for forensic readiness independent of the system.
BPMN4FRSS notation was used for Asset and, subsequently, FR Scenario modelling. However, the Team found it challenging to describe the system’s workings as a process model. Thus, we adjusted the approach to model only high-level interactions (message flows between pools) and resulting Evidence (e.g., a message M to a pool P leads to the generation of evidence E1 and E2). While simpler and still usable for defining the FR Scenarios, the insight is limited. In the end, only the most critical parts of the system were modelled in detail.
RQ2: How can the forensic readiness of a system be evaluated based on the established model and empirical knowledge? Static model-based evaluation and empirical simulation both yield insight towards forensic readiness.
The model-based evaluation computes metrics from the BPMN4FRSS model. While a quick indicator, they are not comparable across the FR Scenarios. However, they were able to point out issues (e.g., inadequacy and strong dependence on a single copy of data). But, their explanation is not straightforward as deeper insight is needed to tell which factor influenced the value.
A more complex evaluation combines the model and empirical knowledge by arranging a simulated incident and observing its investigation. Its aim was threefold: (1) to test the actual availability and usefulness of the potential evidence as captured in the model, (2) to identify gaps in the potential evidence, and (3) to observe the cooperation between systems and Team in incident handling. Indeed, flaws were found in all three areas. For evaluation, the gathered potential evidence was compared to the expectations, assumptions, supporting evidence, and impact in answering the investigation query. While costly, the simulation provided the most insight, so future work should aim to improve its effectiveness.
RQ3: What are the effects of FR-ISSRM process execution and its artefacts on the security posture? A direct impact on security posture is twofold. First, forensic readiness supports incident handling and investigation process. It is in the form of pre-prepared data pointing to the circumstances of the incident. Forensic readiness is thus concerned with the availability of data when needed. Therefore, the evaluation focused on ensuring that enough data exists. On the other hand, too much data is also undesirable. However, this situation was not encountered in the study, thus remaining unverified. The second impact is essentially an audit of security posture, albeit from a different angle. Both the model but especially the simulated indecent pointed out several weaknesses.
As a side-effect, the Team gained deeper insight into the system as modelling and identifying Evidence requires inspecting the systems’ behaviour, causes and effects. This alone was recognised as a valuable, although tedious, result. Naturally, the model was included in the documentation.
7.2 Threats to Validity
Construct Validity is primarily threatened by misunderstandings of forensic readiness concepts and aims within the Team. It was mitigated by supervision during each of the phases and validating sub-results. Indeed, it was found that the theoretical concepts were hard to grasp for the technical team. Thus, the tasks and enquiries were switched to be less abstract and more actionable.
Internal Validity is threatened by the team’s low maturity of processes and formalisms in the SensitiveCloud environment and low experience with forensic investigation. Therefore, the gained observations are influenced by this fact. A consistency of BPMN4FRSS models, e.g., the choice of contexts, is critical to metrics. Thus, a session was held with the Team to explain the semantics and establish a common approach. Additionally, some of the Evidence defined in the model was not utilised during the simulation. This issue was explicitly questioned during the feedback interview to capture the reasoning behind the omission.
External Validity is threatened by choice of examined FR Scenario and SensitiveCloud environment. While the FR Scenario was chosen to cover as much of the FR Goals, its main characteristic is that the attacker (except for stealing access credentials) used the system legitimately. Generalisation on scenarios outside this characteristic (e.g., gaining access to a node by container escaping) is not guaranteed. Furthermore, the insights are arguably more relevant for process-wise low-mature environments.
Reliability in this case study depends on the security risk assessment, formulation of FR Scenarios, and interpretation of the evaluation result. The study builds on already performed risk assessments, and each artefact (FR Goals, instantiated Risks, FR Scenarios, models) was validated by the Team to avoid errors. For the topics discussed in the feedback phase, at least two interviewees mentioned them unless explicitly stated. Similarly, at least two technical Team members confirmed the explanation of the potential evidence. The requirements were then proposed to address missing information and validate assumptions.
7.3 Lessons Learned and Future Work
Like all security-related domains, forensic readiness is a continuous effort to improve processes, maturing technologies and training people. Firstly, our evaluation has uncovered several issues in the system (e.g., misconfiguration of Kube-API Audit, volatile Wireguald Log). Secondly, the execution of the FR-ISSRM process contributed to the overall maturity of the system’s secure environment. In particular, the practical experience with the simulated incident investigation led to a sincere recognition of security and incident preparedness. As such, it completed the standard continuous security practices (e.g., those accompanying ISO/IEC 27k). Thirdly, to get forensic readiness and general IT security into the common practice of relevant technological individuals and teams, the framework must be explained to its target audience; the simulation helped to achieve this purpose by being a hands-on exercise. Also, the value of models was understood only after the exercise, albeit limited to simple constructs and semantics.
Future work will continue with the practice and expand on more complex FR Scenarios. Due to the positive experience, forensic readiness is included in security management plans, with periodical exercises planned. But, to do so effectively, research must be made to optimise the FR-ISSRM process, especially the time complexity. Lastly, we aim to expand the tool support to automate and expand the model-based evaluation, bringing more direct value to the models. The work shall focus on how to make the models and process more accessible.
Notes
- 1.
- 2.
Tool available at: https://github.com/FREAS-tools/freas-bpmn4frss-library.
- 3.
Template and guidelines available at: https://doi.org/10.58126/8c9w-eh29.
- 4.
Full list available at: https://doi.org/10.58126/8c9w-eh29.
- 5.
The protocol is available at: https://doi.org/10.58126/8c9w-eh29.
- 6.
Dataset with codes available at: https://doi.org/10.58126/8c9w-eh29.
References
Ab Rahman, N.H., Glisson, W.B., Yang, Y., Choo, K.K.R.: Forensic-by-design framework for cyber-physical cloud systems. IEEE Cloud Comput. 3(1), 50–59 (2016)
Affia, A.-A.O., Matulevičius, R., Nolte, A.: Security risk management in cooperative intelligent transportation systems: a systematic literature review. In: Panetto, H., Debruyne, C., Hepp, M., Lewis, D., Ardagna, C.A., Meersman, R. (eds.) OTM 2019. LNCS, vol. 11877, pp. 282–300. Springer, Cham (2019). https://doi.org/10.1007/978-3-030-33246-4_18
Afzaal, M., Di Sarno, C., Coppolino, L., D’Antonio, S., Romano, L.: A resilient architecture for forensic storage of events in critical infrastructures. In: IEEE HASE 2012, pp. 48–55 (2012)
Alrajeh, D., Pasquale, L., Nuseibeh, B.: On evidence preservation requirements for forensic-ready systems. In: ESEC/FSE 2017, pp. 559–569. ACM (2017)
Altuhhova, O., Matulevičius, R., Ahmed, N.: An extension of business process model and notation for security risk management. Int. J. Inform. Syst. Model. Design 4, 93–113 (10 2013)
Bajramovic, E., Waedt, K., Ciriello, A., Gupta, D.: Forensic readiness of smart buildings: Preconditions for subsequent cybersecurity tests. In: IEEE ISC2 2016, pp. 1–6 (2016)
CESG: Good Practice Guide No. 18: Forensic Readiness. Guideline, National Technical Authority for Information Assurance, United Kingdom (2015)
Daubner, L., Macak, M., Matulevičius, R., Buhnova, B., Maksović, S., Pitner, T.: Addressing insider attacks via forensic-ready risk management. J. Inform. Secur. Appl. 73, 103433 (2023)
Daubner, L., Matulevičius, R.: Risk-oriented design approach for forensic-ready software systems. In: ARES 2021. ACM (2021)
Daubner, L., Matulevičius, R., Buhnova, B., Pitner, T.: Business process model and notation for forensic-ready software systems. In: ENASE 2022, pp. 95–106. SCITEPRESS (2022)
Dubois, É., Heymans, P., Mayer, N., Matulevičius, R.: A Systematic Approach to Define the Domain of Information System Security Risk Management, pp. 289–306. Springer (2010). https://doi.org/10.1007/978-3-642-12544-7_16
EDPB: Data breach: the italian sa fines inail eur 50,000. Decision, European Data Protection Board (2022), https://edpb.europa.eu/news/national-news/2022/data-breach-italian-sa-fines-inail-eur-50000_en
Elyas, M., Ahmad, A., Maynard, S.B., Lonie, A.: Digital forensic readiness: expert perspectives on a theoretical framework. Comput. Secur. 52, 70–89 (2015)
Ganji, D., Kalloniatis, C., Mouratidis, H., Malekshahi Gheytassi, S.: Approaches to develop and implement iso/iec 27001 standard - information security management systems: systematic literature review. Int. J. Adv. Softw. 12, 228–238 (2019)
Grandry, E., Feltus, C., Dubois, E.: Conceptual integration of enterprise architecture management and security risk management. In: 17th IEEE International Enterprise Distributed Object Computing Conference Workshops, pp. 114–123 (2013)
Grispos, G., Glisson, W.B., Choo, K.K.R.: Medical cyber-physical systems development: A forensics-driven approach. In: IEEE/ACM CHASE 2017, pp. 108–113 (2017)
Grobler, C.P., Louwrens, C.P.: Digital forensic readiness as a component of information security best practice. In: New Approaches for Security, Privacy and Trust in Complex Environments, pp. 13–24. Springer (2007)
Grobler, C., Louwrens, C., von Solms, S.: A framework to guide the implementation of proactive digital forensics in organisations. In: ARES 2010, pp. 677–682 (2010)
Iqbal, A., Ekstedt, M., Alobaidli, H.: Digital forensic readiness in critical infrastructures: A case of substation automation in the power sector. In: Digital Forensics and Cyber Crime, pp. 117–129. Springer (2018). https://doi.org/10.1007/978-3-319-73697-6_9
ISO/IEC: Information technology — Security techniques — Incident investigation principles and processes. Standard, International Organization for Standardization, Switzerland (2015)
ISO/IEC: Information technology — Security techniques — Information security risk management. Standard, International Organization for Standardization, Switzerland (2018)
Joint Task Force Transformation Initiative: Risk management framework for information systems and organizations: A system life cycle approach for security and privacy. Tech. Rep. Special Publication (NIST SP) - 800–37 Rev. 2, NIST (2018)
Matulevičius, R.: Fundamentals of secure system modelling. Springer (2017). https://doi.org/10.1007/978-3-319-61717-6
Mouhtaropoulos, A., Dimotikalis, P., Li, C.T.: Applying a digital forensic readiness framework: Three case studies. In: IEEE HST 2013,pp. 217–223 (2013)
Pasquale, L., Alrajeh, D., Peersman, C., Tun, T., Nuseibeh, B., Rashid, A.: Towards forensic-ready software systems. In: Proceedings of the 40th ICSE: New Ideas and Emerging Results, pp. 9–12. ICSE-NIER 2018, ACM (2018)
Rivera-Ortiz, F., Pasquale, L.: Automated modelling of security incidents to represent logging requirements in software systems. In: ARES 2020. ACM (2020)
Rowlingson, R.: A ten step process for forensic readiness. Int. J. Digital Evidence 2 (01 2004)
Runeson, P., Höst, M., Rainer, A., Regnell, B.: Case Study Research in Software Engineering: Guidelines and Examples. Wiley (2012)
Simou, S., Kalloniatis, C., Gritzalis, S., Katos, V.: A framework for designing cloud forensic-enabled services (cfes). Requirements Eng. 24(3), 403–430 (2019)
Singh, A., Ikuesan, R.A., Venter, H.: Secure storage model for digital forensic readiness. IEEE Access 10, 19469–19480 (2022)
SUSE: SUSE Rancher Technical Architecture Guide. White paper, SUSE, Luxembourg (2021)
Tan, J.: Forensic readiness. Tech. rep., @stake, Inc. (2001)
Wang, J., Peng, F., Tian, H., Chen, W., Lu, J.: Public auditing of log integrity for cloud storage systems via blockchain. In: Security and Privacy in New Computing Environments. pp. 378–387. Springer (2019)
Zawoad, S., Hasan, R.: Trustworthy digital forensics in the cloud. Computer 49(3), 78–81 (2016)
Acknowledgement
This research was supported by ERDF “CyberSecurity, CyberCrime and Critical Information Infrastructures Center of Excellence” (No. CZ.02.1.01/0.0/0.0/16_019/0000822). Computational resources were supplied by the project “e-Infrastruktura CZ” (e-INFRA CZ LM2018140) supported by the Ministry of Education, Youth and Sports of the Czech Republic. A special thanks to the e-INFRA CZ SensitiveCloud team for their participation in the study. This research was also co-founded by the European Union under Grant Agreement No. 101087529. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or European Research Executive Agency. Neither the European Union nor the granting authority can be held responsible for them.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Copyright information
© 2023 The Author(s)
About this paper
Cite this paper
Daubner, L., Matulevičius, R., Buhnova, B., Antol, M., Růžička, M., Pitner, T. (2023). A Case Study on the Impact of Forensic-Ready Information Systems on the Security Posture. In: Indulska, M., Reinhartz-Berger, I., Cetina, C., Pastor, O. (eds) Advanced Information Systems Engineering. CAiSE 2023. Lecture Notes in Computer Science, vol 13901. Springer, Cham. https://doi.org/10.1007/978-3-031-34560-9_31
Download citation
DOI: https://doi.org/10.1007/978-3-031-34560-9_31
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-031-34559-3
Online ISBN: 978-3-031-34560-9
eBook Packages: Computer ScienceComputer Science (R0)