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].

Table 1. Comparison of related forensic readiness approaches
Full size table

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.

Fig. 1.
figure 1

FR-ISSRM domain model [8] (risk treatment-related concepts omitted)

Full size image

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].

Fig. 2.
figure 2

An asset-level model of the Wireguard VPN Connection scenario

Full size image

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.

Table 2. Selected Forensic Readiness Goals
Full size table

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.

Fig. 3.
figure 3

Composite Forensic Readiness Scenario of a data manipulation

Full size image
Table 3. Description of risks in the composite Forensic Readiness Scenario
Full size table

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.

Table 4. Forensic readiness model-based metrics
Full size table

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.

Fig. 4.
figure 4

The attack process of the simulation

Full size image
Table 5. (Potential) evidence considered during the investigation
Full size table

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.

Table 6. Proposed Forensic Readiness Requirements
Full size table

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.