Keywords

1 Introduction

With the ever-looming threats to software systems, security, safety, survivability, and robustness factors are becoming more and more critical. These are focused on defence against the threats of making it operable even in exceptional conditions [22]. However, their implementation does not guarantee complete protection, as attacks might still succeed, and disasters might disable the systems [19]. For this reason, there is a growing interest in applying measures allowing for post-incident investigation [25], for which digital forensic methods are utilised.

Often, results from digital forensic investigation are relied upon in a court of law [8]. Those typically involve investigations of criminal cases but also internal investigations as part of incident response [38] or post-mortem analysis of disasters [19]. The results, called digital evidence, must conform to a high standard of soundness to be admissible. As such, forensic investigation is a laborious, costly, and delicate process to avoid the spoliation of digital evidence. Still, its success is not assured as the evidence might be inconclusive or completely missing.

Forensic readiness was formulated to mitigate such issues, aiming to increase the value of evidentiary data while lowering the cost of the investigation [42]. Traditionally, it is approached as a series of organisational processes [26, 38]. Recently, however, an idea of approaching forensic readiness from a software engineering perspective was formulated, coining the term forensic-ready software systems [35]. Such a system can, in anticipation of an incident, proactively collect potential digital evidenceFootnote 1 and soundly conduct forensic processes.

Currently, there is a rough idea about which requirements the forensic-ready software systems should address [35], how they should be elicitated [14], and represented [16]. However, the understanding of factors and their relationships that form forensic-ready software systems is insufficient. As such, it is challenging to define proper implementable and verifiable requirements for such systems.

1.1 Research Questions

The goal of this paper is to define a reference model of forensic readiness qualitative factors, to enable the definition of on-point and verifiable requirements for forensic-ready software systems. Based on the initially defined requirements, literature survey, and interviews conducted with forensic experts [11], a taxonomy of factors is defined. Then, the model is demonstrated by formulating verifiable requirements for an automated valet parking service that addresses inadequacies regarding a potential incident investigation. To reach this goal, we formulate the following research questions:

RQ1: What are the factors that form the forensic readiness requirements? The aim is to create a reference model of its components starting from the preliminary requirements. Additionally, the model should provide more insight into the relationship between the requirements, including their classification.

RQ2: How can the factors be manifested as a concrete requirement? The aim is to describe the procedure of defining a concrete forensic readiness requirements, using the reference model concerning a particular system.

1.2 Research Method

To answer the research questions, we advised a research method depicted in Fig. 1. As a starting point, we gathered three principal inputs. The first is a list of preliminary requirements by Pasquale et al. [35], listed in Table 1, which are explicit for forensic-ready systems. The second is requirements and obligations surveyed from related literature, including general forensic readiness. The third is the findings from the interviews with digital forensic experts (e.g., investigators, lawyers) on their problems, ideas of a forensic-ready software system, and evidence quality factors [11], conducted as part of previous work.

Fig. 1.
figure 1

Research Method

Full size image

With the inputs in place, the candidate factors are elicited by inspecting the requirements, properties, and needs of forensic readiness. Then the reference model is iteratively created, grouping the factors and creating a hierarchy. In a case of ambiguity, a particular factor is re-examined. The resulting model corresponds to RQ1. Then, the model is demonstrated on a running scenario, formulating concrete forensic readiness requirements for the system corresponding to RQ2. If the model is found unsatisfactory, it is redesigned.

The paper is structured as follows: After introducing the topic and aim, Sect. 2 summarises the related work. Then Sect. 3 presents the forensic readiness qualitative factor reference model. It is demonstrated in Sect. 4 on a running example, where it is used to manifest concrete requirements. Finally, Sect. 5 answers the research questions and concludes the paper.

2 Related Work

Design of forensic-ready software systems, or sometimes systems forensic-by-design, was approached by several domain-specific frameworks. For example, cyber-physical cloud systems [1], medical cyber-physical systems [24], and smart buildings [5]. A common component of the frameworks is the utilisation of a risk-based approach and emphasis on validation and verification. On the other hand, the frameworks typically do not go into detail regarding the implementation.

Focusing on the software engineering point of view, a survey was conducted to explore the practice of considering forensic readiness in the development of software systems [23]. It culminated in publishing the idea of a forensic-ready software system [35], including the preliminary requirements and open challenges. Some of the requirements were already addressed. For example, a preservation of minimal and relevant evidence [2] and automated logging instrumentation [37]. Furthermore, the representation of forensic-ready software systems and incidents in cyber-physical environments has been explored [3, 4].

2.1 Forensic Readiness Software Requirements

Forensic-ready software systems take the concept of forensic readiness and apply it as a high-level qualitative aspect, or non-functional requirement, of a software system. However, to implement it, a solid foundation is needed to guide the formulation, validation, and verification of the specific requirements [13]. A preliminary set of requirements was formulated with the idea of a forensic-ready software system [35]. They are summarised in Table 1.

In a sense, forensic readiness is similar to other non-functional requirements like dependability (especially security [22] and safety [21]), which share some attributes. The security requirement is defined as a condition over the phenomena of the environment that we wish to make true by installing the system in order to mitigate risks [17, 31]. They can be classified based on the area they specify (e.g., intrusion detection, integrity, authentication, immunity) [22]. Mostly, however, they are discussed based on their qualitative factor [20] (attribute, characteristics, property, aspect), a subject of its condition. They can be the security criteria violated by the mitigated risk (e.g., confidentiality, integrity, availability) [34]. In this regard, the violated properties of STRIDE [40] are also relevant. Other works use requirement categories mapped on the incident-handling process, creating a security checklist [6]. Notably, the factors can be organised in a quality model [20], which creates a taxonomy-like structure of the qualitative (i.e., non-functional) aspects to address the measurable requirements.

Table 1. Preliminary Requirements for Forensic-Ready Software Systems [35]
Full size table

Risk management is considered a reasonable approach for the identification of forensic-ready requirements. This is corroborated by its utilisation in secure design [29] but also in guidelines for implementing organisational forensic readiness [9, 38]. In the case of forensic-ready software systems, there is an extension of Information Systems Security Risk Management (ISSRM) [17, 31] which adds forensic readiness concepts [14, 15] and accompanying metrics for evaluation. Additionally, the work utilises a custom notation for modelling [16].

As noted with the risk management case, there is an overlap with security and forensic readiness scopes [25], which includes requirements. While there was little done in terms of requirements analysis and representation on the forensic readiness side, the security side contains numerous approaches. A good example of security requirements is a list by Firesmith [22]. For a model-based example, UMLsec [28] captures the security concerns into the UML model and analyses them. On the risk management side, Secure Tropos [30] and Misuse Cases [41] are the well-known approaches.

2.2 Summary

Various works have capabilities of forensic-ready systems, but their requirements are rarely addressed or their implementation verified. While there are preliminary requirements defined, they have several limitations. The relationship between them is unclear as there can overlap in some contexts (e.g., a provenance record of potential evidence contributes to its non-repudiation). Furthermore, the requirements can be satisfied in multiple ways (e.g., non-repudiation might combine corroborating evidence integrity assurance). Lastly, there is a gap in connecting risk-based techniques to formulating concrete requirements that would verifiably address the identified risks.

3 Factors of Forensic Readiness Requirements

This section presents the identified qualitative factors (i.e., attributes, characteristics, properties, aspects) of forensic-ready software systems, which make up the requirements. Defining the factors aims to facilitate the elicitation of precise, implementable, and verifiable forensic readiness requirements from forensic readiness scenarios [14]. In this regard, a reference quality model is proposed, describing components of a qualitative requirement [20], depicted in Fig. 2.

The reference model is created iteratively, following the set method. During each step, the elicited factors from the source material are examined for similarity in purpose or target. The resulting hierarchy is checked for consistency so that one factor is not duplicated and factors with the same overarching purpose are aggregates of a higher one.

Fig. 2.
figure 2

Excerpt from Firesmith’s Quality Model Definition [20]

Full size image

Per the definition, a quality requirement specifies a minimum amount of a quality factor [20], which can be decomposed into subfactors. It refers to a quality criterion, which is evidence for or against the existence of a factor or subfactor. A quality metric then quantifies the factor. Thus, the implementation of such a requirement (a control [29]) is verifiable. The factors discussed below are all special cases of forensic readiness that may be composed of further subfactors.

3.1 Evidence Factors

The evidence factors are a group of qualities of a single piece of potential evidence, essentially any information that can support legal proceedings, demonstrate due diligence, manage the impact of risk, and support a claim or dispute [38]. Therefore, its qualities should be aligned with such actions, especially in being convincing to a 3rd party. Figure 3 depicts the relationships between the evidence factors. The rest of the section describes them in more detail.

Digital evidence is commonly associated with legal context [8, 32] and is obliged to follow legal requirements. While they differ based on the legal framework [39], they do follow common principles [11]. However, proactively collected “potential” evidence can be, in many cases, more lenient, as it is not (yet) in the scope of a formal investigation. Still, high-quality potential evidence greatly improves the evidentiary value of the proper evidence when it is required.

Fig. 3.
figure 3

Forensic Readiness Qualitative Factors: Evidence Factors

Full size image

Non-Disputability addresses the prevention of disputes regarding the potential evidence. In this sense, the fundamental disputes aim at admissibility, i.e., acceptance in a court of law. In other words, it gives assurances on the genuineness of potential evidence. Generally, the purpose of non-disputability in forensic readiness is to safeguard the evidentiary value of the data and increase its confidence [7]. Consequently, non-disputability should allow for confident disputation of non-genuine potential evidence. It concerns the possible dangers of tampering or corruption of (potential) evidence [8, 39].

As a result, the non-disputability influences the evidentiary value of the potential evidence. It is further decomposed into subfactors, complementing and potentially substituting one another. For example, even if the potential evidence is not protected against tampering (Integrity), it could have high value due to multiple independent pieces of evidence supporting it (Corroborability) [7]. It is usually referred to as “Non-Repudiation” [35, 36], but we instead consider Non-Repudiation as a factor closer to security and capture it here only as a subfactor.

Timeliness addresses the accuracy of time of origin, or generally, any time information associated with the potential evidence. It motivates a timely creation of potential evidence relative to an action or event and assurance of the correctness of the time information. The reliability of the time is related to the Integrity [43] or can be corroborated by other time information.

Redundancy addresses the extent and manner of storing duplicities of potential evidence. It is related to Integrity as a way to provide integrity assurance and Corrborability as the copy corroborates the original and vice versa [38].

Integrity addresses the assurance that the potential evidence was not tampered with [42]. In other words, it addresses the non-disputability of potential evidence corruption based on its unauthorised creation, modification, or deletion. It directly relates to integrity in a security sense [22].

Authenticity addresses the non-disputability of potential evidence origin. It relates to Authentication from a security perspective, which often implies Integrity [33]. Additionally, authenticity might relate to Attributability, concerning binding the person or device of origin but must give stronger guarantees making the attribution non-disputable.

Provenance addresses a record-keeping of the actions on potential evidence during its lifecycle. This includes origin, transportation, modification, accessing, and processing records [35]. A specific example of provenance in forensic readiness sense is proactive maintenance of chain of custody, which is mandatory for true digital evidence [10]. It relates to auditability, albeit in a narrower sense, focusing strictly on the potential evidence lifecycle to achieve non-disputability.

Corroborability addresses the degree of support by a different, ideally independent, potential evidence. High corroborability enhances the overall non-disputability (i.e., certainty) of potential evidence [7]. It is based on the assumption that the corruption of one would be detectable by others. Moreover, an undetectable corruption of one should require the corruption of another. It relates to Linkability, albeit in a narrower sense, focusing on the non-disputability.

Non-Repudiation addresses the extent to which any aspect of potential evidence is prevented from repudiation. Thus, there is a significant overlap with the non-repudiation from a security perspective [22]. As noted, non-repudiation for digital evidence is often a synonym for the whole non-disputability [35, 36]. However, here it is considered as its part, as the ability of one party to repudiate potential digital evidence arguably does have an impact on disputes.

Evidence Availability addresses the extent of potential evidence availability during an investigation. It encompasses the existence, preservation, and ability to retrieve the potential evidence [35]. Typically, the requirements specify which, where, and when the potential evidence is created, what it should contain, and its retention. Its subfactors are Existence addressing the actual presence of potential evidence; Volatility addressing the window of when it can be preserved or accessed and; Accessibility, addressing the ease of access for an investigator.

Admissibility the concern of acceptability in a court of law. Generally, admissibility is a set of legal tests a judge performs to assess the formal evidence [7]. However, their exact nature is dependent on the legal framework. It could be considered the most important quality of digital evidence, typically involving the proper handling and Non-Disputability qualities. While it is not a primary concern of potential evidence, it might be considered based on its intended use.

Relevancy addresses the need for the potential evidence and its fitness in a forensic readiness scenario [14]. From an investigation point of view, it specifies the ability of the potential evidence to support or refute investigation hypotheses [35]. Thanks to the mapping of scenarios, the relevancy addresses the specific reason why it is preserved and its value. As such, it acts as a counterweight to privacy regulations demanding that the evidence collection is not excessive by explicitly stating the reason and extent.

Utilisability addresses the assistance in the forensic investigation itself to ease the work of the investigator or cybersecurity response team. In other words, it is a factor that addresses the helpfulness and contribution of potential evidence to the effectiveness of the investigation. It refers to one of the principal aims of forensic readiness. Different aspects of the support are reflected by its subfactors.

Processability addresses the degree of ease of automated processing of the potential evidence. It concerns aspects like data format, which influences its effectiveness and reliability [12], but also the availability of tools to process it.

Comprehensibility addresses the knowledge the potential evidence can provide to the investigation. In other words, the knowledge about the semantics of potential evidence. Arguably, the apriori knowledge of the information the potential evidence can provide (e.g., from documentation [38]), including its limits, can help accelerate the investigation. Additionally, it concerns possible errors [32] and allows validation of the results [12].

Linkablility addresses the degree to which the potential evidence can be linked or correlated with others. Presence and awareness of the existing links are essential in reconstructing events during the investigation. Moreover, strong linkability should allow for easier explorative analysis [35].

Transferability addresses the degree to which the potential evidence can be transferred to another custody. Typically, the evidence is transferred to local law enforcement based order for evidence release [38]. However, the release might also demand a cross-border or cross-organisational transfer. It concerns the easiness of the transfer, including the need for supplementary material and privacy.

Attributability is a factor describing a degree of ability to bind potential evidence with an entity, meaning a person, device, place, or application. Specifically, establishing attributability to a person is considered highly important [11].

3.2 Scenario Factors

The scenario factors are a group of qualities of a set of potential evidence referring to a particular forensic readiness scenario [14]. In contrast to the qualities of single potential evidence, these factors address how well they work together towards forensic readiness. Figure 4 depicts the relationships between the scenario factors. The rest of the section describes them in more detail.

Fig. 4.
figure 4

Forensic Readiness Qualitative Factors: Scenario Factors

Full size image

Completeness addresses the degree to which the scenario includes sufficient potential evidence for its investigation. From an investigation point of view, it specifies whether the potential evidence is sufficient to support or refute investigation hypotheses [35].

Minimality addresses the degree to which the scenario includes only the potential evidence important for the investigation. Its purpose is to limit the amount of potential evidence an investigator must go through [35]. Essentially, it refers to a proactive forensic triage [27].

Explainability addresses the degree of the ability to explain conclusions based on the scenario clearly [38]. It deals with the number of phenomena that could be effectively described and the manner of doing so.

3.3 Process Factors

The process factors are a group of qualities of the digital forensic investigation process, scoped on those that can be reasonably affected by proactive measures. As such, it refers to the qualitative factors of forensic-ready software systems conducting forensic processes [35]. Figure 5 depicts the relationships between the process factors. The rest of the section describes them in more detail.

Fig. 5.
figure 5

Forensic Readiness Qualitative Factors: Process Factors

Full size image

Process Soundness addresses the degree of soundness of the conducted forensic processes. In other words, it deals with the assurance that the process does not diminish the value of potential evidence [32]. It is further specified by subclasses focusing on a different part of soundness.

Unaffectedness addresses the degree of assurance that the conducted processes do not affect the meaning or interpretation of the potential evidence.

Error Explainability addresses the degree to which the errors in the forensic process can be detected and explained.

Transparency addresses the degree to which the process can be re-examined and verified by an independent party.

3.4 Cross-Cutting Factors

The cross-cutting factors are a group of qualities influencing forensic readiness in general, or they address a principle applicable to all other factor groups. For example, Legal Compliance must be accounted for in virtually all aspects of a forensic-ready software system. Figure 6 depicts the relationships between the cross-cutting factors. The rest of the section describes them in more detail.

Fig. 6.
figure 6

Forensic Readiness Qualitative Factors: Cross-Cutting Factors

Full size image

Reviewability addresses the degree to which the system’s actions, components, or data involving potential evidence and forensic processes support audit and legal review. The goal is twofold. The first is to enable legal advice on an incident [38]. The second is allowing the inspection of forensic-ready controls to analyse nominal and abnormal behaviour in a similar sense to security auditing [22]. That could result in meta-potential evidence, similar to Provenance.

Compliance addresses the degree to which is the forensic-ready software system compliant with the law, regulations, or organisational policies [35]. It is further specified by subfactors focusing on the specific part, namely Legal, Regulatory, and Local. The factor places constraints on others. For example, demand a level of Transferability to law enforcement, or on the other hand, forbid the existence of potential evidence.

4 Running Example

This section presents a running scenario used to demonstrate the reference model of qualitative factors by manifesting the forensic readiness requirements based on it. The scenario describes issuing a parking permit within Automated Valet Parking (AVP), which is a service allowing the user to leave an autonomous vehicle in a drop-off area to park it automatically. It is represented by a BPMN process model, depicted in Fig. 7. The process model is enhanced by BPMN4FRSS [16] notation to describe evidence sources (magnifying glass symbol) and potential evidence (green BPMN data objects). Previously, the process model was utilised to demonstrate a risk-oriented approach for eliciting forensic readiness requirements [15] and the design of privacy-preserving services [18].

Fig. 7.
figure 7

Automated Valet Parking (AVP) Scenario: Issuing a Permit

Full size image

There are three entities present in the execution of the AVP scenario. Each entity has different assumptions regarding its cooperability during a possible investigation [15]. The description of the entities is as follows:

  • Autonomous Vehicle (AV): Representing the vehicle. It contains a User Device that handles communication with the Parking Service Provider and stores the issued parking permit. From the forensic readiness point of view, the entity is semi-cooperative, meaning that evidence is fully under the user’s custody but could be obtained if it benefits the user.

  • Parking Service Provider (PSP): Representing a contact point of the parking service deployed in the cloud. It acts as an intermediary between AV and Parking Lot Terminals. It orchestrates the search, reservation, and parking permit delivery. As it is entirely under the stakeholder’s control, the entity is cooperative, and its data can be used during an investigation.

  • Parking Lot Terminal (PLT): Representing an edge IoT device physically located at the parking lot, which provides relatively easy physical access. It controls access to the particular parking lot by issuing and checking the parking permits and is the source of authoritative data regarding the parking lot. The entity is cooperative and under stakeholder control.

The BPMN process model in Fig. 7 describes a nominal execution of the scenario. It also highlights several sources of potential evidence generated during the execution as part of the business process and logging. Still, there are several deficiencies in effectively investigating incidents regarding this system. While the risk of these incidents could be mitigated by deploying security controls, they do not entirely prevent them. In this sense, forensic readiness can complement security [15], where it handles situations where security controls fail.

4.1 Forensic Readiness Scenarios

The scenario-based planning is utilised in general forensic readiness [9, 38]. Also, the forensic-ready risk management approach FR-ISSRM [14] defines Forensic Readiness Scenario (FR Scenario) as a focal point for the assessment, aiming to elicit Forensic Readiness Requirements (FR Requirements). The FR Scenario is a combination of a Risk, Forensic Readiness Goal (FR Goal) capturing the reason why it is considered, and Evidence relevant to investigate the occurrence of Risk given the FR Goal. The FR Requirements enhance the FR Scenarios to aid the investigation (e.g., adding missing evidence, enhancing their quality). Subsequently, the FR Requirements are implemented by concrete Forensic Readiness Controls (FR Controls). The BPMN4FRSS [16] notation captures the FR-ISSRM concepts as a process model to assist the FR Scenario assessment.

Table 2. Forensic Readiness Scenarios
Full size table

For this paper, three FR Scenarios are considered, described in Table 2, capturing incidents to investigate. Figure 7 depicts their composite BPMN4FRSS model. However, through their assessment, several inadequacies can be found:

  1. S1:

    How the Parking permit was stored cannot be determined, as the PLT parking permit storage audit log is created both in nominal execution and during the incident. Moreover, it could be tampered with by the attacker.

  2. S2:

    The link between the PSP parking availability request log and the PLT parking availability request log uses only circumstantial data (time, IP address).

  3. S3:

    Correct delivery of the Parking permit cannot be proven only by the PSP parking permit request log.

The identified inadequacies can be addressed by appropriate FR Requirements. That means manifesting a particular forensic readiness quality factor.

4.2 Manifestation of the Factors

Table 3 contains the description of the FR Requirements, addressing the found inadequacies. The correctness of their implementation by FR Control can be verified due to the establishment of the minimal acceptable value of a metric.

Table 3. Forensic Readiness Requirements
Full size table

The FR Requirements are established by the following approach. First, a factor (or subfactor) referring to the inadequacy or enhancement of the FR Scenario is selected from the reference model. Then a criterion is defined, which maps the selected factor to the concrete inadequacy of the FR Scenario. Essentially, an FR Control that meets such criteria shall resolve the inadequacy. However, that is practically impossible to reach and verify (e.g., complete satisfaction of “System shall be available” criterion is not feasible).

Then, a metric, which quantifies the factor, is selected to define the minimum acceptable value for the criterion. The value needs to be realistic [29]. For the AVP, the following metrics are used: (1) Scenario Coverage [14], a model-based metric quantifying the coverage of Evidence, (2) Relative Evidentiary Value [14], quantifying the confidence in the Evidence, (3) Number of links with the non-circumstantially linkable Evidence, and (4) Existence which is a factor of expected and actual occurrences. Together, the criterion and its minimum acceptable value make up the requirement.

As factors can aggregate multiple subfactors, the metric and control can address only their subset. It is acceptable, as the satisfaction of a requirement is tied to the metric, which could be influenced differently by different subfactors. For example, to satisfy S1.FRR2 is enough to increase the Redundancy by an independent copy. Otherwise, the requirement might target a subfactor directly.

5 Conclusion

This paper presented a forensic readiness qualitative factor reference model as a foundation for formulating verifiable requirements. The model was shown to supplement the FR-ISSRM, an existing forensic-ready risk management approach, by filling the gap in defining the concrete form of the Forensic Readiness Requirements. Consequently, the set research questions are answered as follows:

RQ1: What are the factors that form the forensic readiness requirements? Based on the inputs, a reference model of forensic readiness qualitative factors was established. The factors are organised in a taxonomy, describing desired qualities of a forensic-ready software system. Notably, several factors (e.g., Non-Disputability) share a common aim, which can be addressed by their combination, creating sub-factors. Such hierarchical organisation is important for enabling alternative implementations and applying metrics. While the aim was to make the model consistent, its completeness is not guaranteed. However, adding new factors, sub-factors, or their further decomposition is possible.

RQ2: How can the factors be manifested as a concrete requirement? The reference model was used to define forensic readiness requirements based on the results from forensic-ready risk management. Concretely, an automated valet parking service with several inadequacies in forensic readiness was presented. These were transformed into specific criteria with associated minimum acceptable values, forming verifiable requirements. Moreover, the model’s hierarchical nature does not limit the implementing controls other than meeting the minimum acceptable value of a given metric.

Future Work branches into three directions, which tackle a challenge in the assurance of forensic-ready software systems. First and foremost, the reference model needs to be further validated in a more in-depth study involving empirical analysis of a system. Secondly, richer metrics shall be explored to ascertain how to measure the factors and identify possible gaps. Thirdly, checklist-like guidelines of the systems based on the reference model shall be investigated.