Business Process Model and Notation for Forensic-Ready Software

Systems

Lukas Daubner

1 a

, Raimundas Matulevi

cius

2 b

, Barbora Buhnova

1 c

and Tomas Pitner

1 d

Faculty of Informatics, Masaryk University, Brno, Czech Republic

Institute of Computer Science, University of Tartu, Tartu, Estonia

Keywords:

Forensic Readiness, Forensic-Ready Software Systems, Modelling, BPMN, Software Design.

Abstract:

The design and development of secure systems is an important and challenging task. However, such systems

should also be prepared for eventual disputes or occurrences of a security incident. To solve this, forensic-

ready software systems are, by-design, prepared to assist in the forensic investigation and to provide on-point

data with high evidentiary value. However, software engineering support for the systematic development of

such software systems is rather sparse. This paper tackles the problem by introducing novel modelling nota-

tion, called BPMN for Forensic-Ready Software Systems (BPMN4FRSS), including its syntax and semantics.

The notation aims to capture the forensic-ready controls and enable reasoning over them, primarily focusing

on potential digital evidence. Importantly, it is made to support forensic readiness oriented risk management

decisions. The approach is then demonstrated in a scenario where the controls, which mitigate security and

business risks, are properly represented.

1 INTRODUCTION

The importance of security in software systems is

widely acknowledged. Consequently, the develop-

ment of systems secure by design (Geismann and

Bodden, 2020) is well established. However, the pos-

sibility of a cybersecurity incident cannot be ruled out

entirely, even in highly secure systems (Casey and

Nikkel, 2020). Once the incident occurs, it needs to

be thoroughly investigated to uncover the root cause

and possible culprit in a very reliable manner.

To meet the goals, digital forensics (Casey, 2011)

techniques are employed. However, such investiga-

tion is a costly, laborious, time-consuming, and deli-

cate endeavour, with uncertain success. The reason is

strict requirements on digital evidence, on which the

conclusions are built, to ensure a high level of reliabil-

ity. For example, the digital evidence must be found,

identiﬁed, collected, analysed, understood, and pre-

sented in a manner that does not compromise its in-

tegrity or meaning so it can be used in a potential legal

proceeding (McKemmish, 2008).

https://orcid.org/0000-0003-0853-2776

https://orcid.org/0000-0002-1829-4794

https://orcid.org/0000-0003-4205-101X

https://orcid.org/0000-0002-2933-2290

Forensic readiness (Tan, 2001) was formulated to

reduce the investigation cost and increase the value

of digital evidence. It is a set of proactive mea-

sures, primarily oriented on organisational prepared-

ness, including their systems for the possibility of

forensic investigation (Rowlingson, 2004; Grobler

and Louwrens, 2007). Recently, forensic readiness

was approached from a software engineering perspec-

tive (Pasquale et al., 2018), making systems foren-

sic by design, producing and handling the evidence

in a forensically sound way. That includes, among

others, ensuring the existence of useable digital ev-

idence, protecting its integrity, and making it easily

cross-referenceable (Sachowski, 2016).

While software systems generally produce a num-

ber of digital artefacts (e.g., logs (Studiawan et al.,

2019)), their quality and completeness are not gen-

erally assured (Daubner et al., 2020a). Furthermore,

if such ad-hoc artefacts are to be used, investigators

must spend a great amount of time to ﬁnd and un-

derstand them (Kävrestad, 2018). Also, digital evi-

dence might be ruled inadmissible or has its eviden-

tiary value reduced if it is based on unreliable data or

without integrity guarantees (Casey, 2011). Further-

more, misleading data admitted as digital evidence

can lead to miscarriage of justice (Henley, 2019).

This paper introduces a new approach to sup-

Daubner, L., Matulevi

cius, R., Buhnova, B. and Pitner, T.

Business Process Model and Notation for Forensic-Ready Software Systems.

DOI: 10.5220/0011041000003176

In Proceedings of the 17th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2022), pages 95-106

ISBN: 978-989-758-568-5; ISSN: 2184-4895

port the design of forensic-ready software systems,

enabling software engineers to build systems pro-

ducing on-point data with high quality. To this

end, we propose a novel modelling notation, an ex-

tension to Business Process Model and Notation

(BPMN), called BPMN for Forensic-Ready Software

Systems (BMPN4FRSS). It aims to capture the spe-

ciﬁc forensic-ready controls (i.e., implementation of

requirements) and allow reasoning over them, includ-

ing their validation and analysis. The primary con-

cern is the representation of data sources potentially

usable as digital evidence (i.e., potential digital evi-

dence) within the software system. Furthermore, the

BPMN4FRSS model captures mutual corroboration

of potential digital evidence to analyse its sufﬁciency

for an anticipated incident investigation. Lastly, the

model is aimed to serve as documentation when a

third-party investigator is required.

This paper is structured as follows: After the in-

troduction, Section 2 explores related work. Section 3

describes the forensic-ready requirements and the aim

of our effort. Then, Section 4 explains the syntax and

semantics of the BPMN4FRSS, followed by Section 5

demonstrating its application. Finally, Section 6 con-

cludes the paper and outlines future research steps.

2 RELATED WORK

Existing research on forensic readiness from a soft-

ware engineering perspective has focused on proac-

tive preservation of relevant and minimal evi-

dence (Alrajeh et al., 2017), automated logging in-

strumentation (Rivera-Ortiz and Pasquale, 2020), and

outlined their veriﬁcation (Daubner et al., 2020b).

There also exist frameworks focusing on broader

organization-wide perspective (Elyas et al., 2015) and

domain speciﬁcs (Grispos et al., 2017b). As for the

forensic-ready requirements, a study mapping their

understanding and approach in software engineering

practice was conducted (Grispos et al., 2017a).

Aiming to identify the speciﬁc requirements, risk

management is a viable strategy for forensic readi-

ness (Bajramovic et al., 2016). A parallel can be

found in the secure systems domain (Altuhhova et al.,

2013) where risk management is principal in formu-

lating security requirements (Matulevi

cius, 2017). In

fact, the security risk-based approach was extended to

cover the forensic-ready requirements as well (Daub-

ner and Matulevi

cius, 2021).

So far, modelling approaches of forensic-ready

software systems are scarce, describing code-level

scenarios based on UML Sequence Diagram (Rivera-

Ortiz and Pasquale, 2020) and incident investiga-

tion in cyber-physical systems, including their topol-

ogy (Alrimawi et al., 2017). On the other hand, the

situation in cybersecurity-focused modelling is differ-

ent as there exist a wide range of approaches (Van den

Berghe et al., 2017; Geismann and Bodden, 2020).

Notably, this paper extends an existing ad-hoc

BPMN extension for representing potential evidence

sources in forensic-ready software systems (Daubner

and Matulevi

cius, 2021). Although the publication

presents how such representation could assist in risk

management, it has gaps in both syntax and seman-

tics. Therefore, the main contribution of this paper

is a proper speciﬁcation of the extension’s syntax and

clariﬁcation of its concepts and scope to enable rea-

soning over forensic-ready software systems and al-

low further evolution of the approach.

Concerning the other BPMN approaches, several

extensions that partially overlap with forensic readi-

ness are focused primarily on cybersecurity. An ex-

ample is the modelling of security requirements, in-

cluding non-repudiation and attack detection (Ro-

dríguez et al., 2007; Chergui and Benslimane, 2018).

Another approach focuses on deﬁning security poli-

cies by annotating the BPMN model with new graph-

ical elements and predicates (Salnitri et al., 2014).

Similarly, a language for structured textual annota-

tions of a BPMN model aims for the model trans-

formation into security policies and composition with

pre-existing fragments (Mülle et al., 2011). Security

risk management is also addressed by a BPMN exten-

sion to describe risks and support decisions (Altuh-

hova et al., 2013; Matulevi

cius, 2017). Lastly, an ex-

ample of a privacy-focused BPMN extension includes

privacy-enhancing technologies into the model (Pul-

lonen et al., 2017) to allow an analysis of data leak-

age. It is supported by a tool enabling detailed analy-

sis of those models (Pullonen et al., 2019).

3 FORENSIC-READY SOFTWARE

SYSTEM REQUIREMENTS

With the coinage of the term forensic-ready software

systems, Pasquale et al. (Pasquale et al., 2018) for-

mulated a set of high-level requirements for such sys-

tems. The requirements are listed in Table 1, contain-

ing names and short descriptions. Furthermore, the

work also elicits the open software engineering chal-

lenges for forensic-ready systems. This paper explic-

itly focuses on one particular challenge: Representing

and reasoning about forensic-ready systems.

Tacking the challenge is a pivotal step in sup-

porting the development of forensic-ready software

systems. Proper representation aids in the mapping

ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering

Table 1: Requirements on forensic-ready software.

Availability

All useful potential evidence is

preserved, prepared and

retrievable if needed.

Relevance

Preserved potential evidence is

relevant to considered

incidents and scenarios.

Minimality

Potential evidence

unnecessary for the expected

investigation is not preserved.

Linkability

Preserved pieces of potential

evidence can be linked with

other pieces.

Completeness

Preserved potential evidence is

sufﬁcient to satisfy or refute

the considered investigation

hypothesis.

Non-

Repudiation

(Admissibility)

Preserved potential evidence

should conform as admissible

evidence. Its integrity and

authenticity are ensured.

Data

Provenance

The handling process of

potential evidence records all

operations made.

Legal

Compliance

The potential evidence

handling process is compliant

with laws and regulations.

of the high-level requirements to their instantiation

as forensic-ready control on a model of a software

system. Additionally, it is crucial for the veriﬁca-

tion (Daubner et al., 2020b). The importance and use-

fulness of modelling have been shown in a risk-based

approach for forensic-ready software systems (Daub-

ner and Matulevi

cius, 2021), where BPMN-based

models support the risk management process. We aim

to expand this idea further to enable a richer and more

detailed expression of forensic-ready controls.

For this paper, we formulate the following re-

search question to drive the effort: How to model the

forensic-ready software systems to support the risk

management decisions?

We further decompose the research question into

three goals to reﬂect the requirements in Table 1. No-

tably, this work does not explicitly consider the Legal

Compliance requirement, but the general good prac-

tice of digital forensics is reﬂected in the design.

G1: Model Incident Scenario and the Relevant Po-

tential Evidence. The aim is to model the Availabil-

ity and Relevance of the potential evidence by map-

ping its sources and types directly into a scenario in

question. Secondarily, with potential evidence explic-

itly elicited, Completeness and Minimality can be ad-

dressed by analyzing the model.

G2: Model Relationships between the Potential

Evidence. Represent relationships between the po-

tential evidence. Allow speciﬁcation of potential ev-

idence types to explore timing, mutual dependence,

and common data ﬁelds, addressing Linkability.

G3: Model the Lifecycle and Properties of Poten-

tial Evidence. By modeling the entire lifecycle of po-

tential evidence from the creation to the preservation,

as well as any operations performed, Data Prove-

nance can be established as needed. Additionally,

proofs on integrity or authenticity can be established

at a certain point within the lifecycle, which adds to

its Non-Repudiation.

4 BPMN EXTENSION FOR

FORENSIC-READY SOFTWARE

SYSTEMS

This section describes the syntax and semantics of

BPMN4FRSS based on BPMN 2.0 (OMG, 2010).

While designing the extension, we followed the ex-

isting deﬁnition of BPMN abstract syntax and seman-

tics and methodology utilised in related BPMN exten-

sions (Altuhhova et al., 2013; Pullonen et al., 2017).

However, the semantics of BPMN4FRSS is described

in textual form. While the formal deﬁnition of seman-

tics is essential to avoid ambiguity and allow for pre-

cise analytic methods (Harel and Rumpe, 2004), we

plan it as a part of future work, together with model

analysis discussed in Section 6.2.

The BPMN-based approach was chosen for three

main reasons. (1) The process models capture a dyna-

mic behaviour that allows inspecting the interplay be-

tween pieces of potential evidence and their lifecycle.

(2) A high level of abstraction for the process model

contributes to platform independence, in contrast to

a similar platform-dependent approach (Rivera-Ortiz

and Pasquale, 2020). (3) Interconnection with risk

management, as traditionally forensic readiness is es-

tablished by formulating and evaluating risk scenar-

ios (Rowlingson, 2004). In this regard, the BPMN

was motivated by the existing extension for security

risks (Altuhhova et al., 2013), which BPMN4FRSS

complements. The downside of this approach is the

difﬁcult mapping of potential evidence on the mod-

elled system’s broader context, namely high-level ar-

chitecture.

Business Process Model and Notation for Forensic-Ready Software Systems

4.1 Business Process Model and

Notation

BPMN is a language for constructing a business pro-

cess model, a standard controlled by Object Manage-

ment Group (Matulevi

cius, 2017). While syntactical-

ly similar to the ﬂow charts, it has a rich semantic

model (Dijkman et al., 2008; OMG, 2010), support-

ing even the model execution (Silver, 2011). Figure 1

contains an example BPMN diagram, which includes

the basic BPMN constructs relevant to this paper.

User Device

Send request for

registration

Store service

credentials

Registration

data

Service

credential

Credential

storage

Service

credential

received

Service Provider

Request for

registration

received

Generate service

credential

Send service

credential

Registration data Service credential

Figure 1: Example of BPMN diagram.

The diagram contains two Pools (User Device and

Service Provider), each containing a number of Flow

Objects connected by Sequence Flows within a single

pool and by Message Flows between the pools. The

most prominent Flow Object is Task (e.g., Send re-

quest for registration) representing an atomic activity.

An Event is a ﬂow object with multiple specialised

types, depending on its location and trigger condition.

In the example, Start Event denotes the start of a pro-

cess and Message Start Event, requiring a message

as a trigger condition. On the other hand, the end is

marked with an End Event. Inside the process, a Mes-

sage Intermediate Event (Service credential received)

requires “catching” a message for process continu-

ation. The two types of ﬂow objects not present

in the example are Gateway representing a control

point (e.g., branching) and Sub-Process representing

a composite activity.

Data exchanged between events and tasks are rep-

resented with a Data Object (e.g., Registration data),

which has its lifecycle tied to the process instance.

In contrast, persistent storage is denoted with a Data

Store (Credential storage). Associations of those con-

structs are called Data Associations.

4.2 Semantics

Planning the implementation of forensic readiness in-

cludes identifying scenarios where a digital foren-

sics approach could be required (Rowlingson, 2004).

These scenarios could originate from risk manage-

ment describing security risks (Daubner and Mat-

ulevi

cius, 2021) or incidents from past experi-

ence (Rivera-Ortiz and Pasquale, 2020) that foren-

sic readiness should cover. Such a scenario can be

described as a business process model using BPMN.

However, without the principal component – potential

digital evidence

. Hence, BPMN4FRSS allows the

expression of potential digital evidence, including its

origin, handling, storage, and corroboration with oth-

ers within a business process model (i.e., a scenario).

Potential evidence is naturally the core concept of

BPMN4FRSS. Because the potential evidence is es-

sentially a piece of data, it is represented as a BPMN

Data Object, although with a speciﬁc lifecycle. Each

potential evidence is considered an instance of a par-

ticular type, called Potential Evidence Type, that de-

scribes its content. Additionally, the notion of evi-

dence context regarding accessibility to potential ev-

idence during an investigation is captured. The mo-

tivation behind this is the difference between a co-

operative device that will surrender the evidence

(e.g., server under organization control) and a non-

cooperative device whose evidence will not be avail-

able (e.g., user’s phone). In the business process

terms, different devices correspond to different par-

ticipants, thus BPMN Pools.

The ﬁrst step of the potential evidence lifecycle

is to mark a point of origin, called the Potential Ev-

idence Source, which denotes a point in time (pro-

cess) where the potential evidence is created. Fur-

thermore, one Potential Evidence Source can denote

the origin of multiple Potential Evidence Types (e.g.,

sending a message generates log records on the ap-

plication and web server). Such simpliﬁcation allows

the process to be high-level view or focus on a partic-

ular detail, effectively splitting the source as needed.

Finally, the evidence needs to be persistently stored to

be used later during an investigation, which is a trait

of the BPMN Data Store.

No digital evidence is self-sufﬁcient to make con-

clusions. It must be corroborated with other pieces,

and there should be strong assurance about its in-

tegrity and authenticity. To that end, the BPMN4-

FRSS model captures relations between the Potential

Evidence Types to establish links between them and

their nature. The number of relations and their chain-

ing has a direct impact on expected evidentiary value.

A very speciﬁc relationship is formed with Proof,

which goal is to provide guarantees regarding other

Potential Evidence Types (e.g., a hash provides proof

Note the difference: potential digital evidence – poten-

tially useable for future investigation, and digital evidence

– used to satisfy or refute the investigation hypothesis.

ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering

of integrity for a log record). Naturally, the guarantees

depend on speciﬁc technologies, so BPMN4FRSS is

open for extensions, allowing to specify specialised

proofs while keeping the core semantical relation-

ships valid.

During its lifecycle, multiple factors can impact

the potential evidence in both a positive and nega-

tive manner. A simple example is a computation over

the potential evidence, which is represented as BPMN

Task. However, the nature of this computation must

be noted as it can inﬂuence the meaning of said po-

tential evidence. In BPMN4FRSS, we deﬁne three

core computation groups: integrity, authenticity, and

data transformation computation. Currently, they are

meant for documentation purposes but remain open

for extensions to represent concrete methods and pro-

tocols while ﬁtting to the overall lifecycle scheme.

In addition to the guarantees from internal sources

(w.r.t. modelled scenario), external sources could also

inﬂuence the potential evidence in the form of service.

A good example is Trusted Timestamping (

Cosi

c and

ca, 2010), a 3

party service testifying on integrity,

timeliness, and possibly authenticity. We included

support for such sources to BPMN4FRSS, as it al-

lows to express a wide range of mechanisms that es-

tablishes guarantees without the need to model them

in detail. As such, they are expressed by the combi-

nation of BPMN Pool and Potential Evidence Type.

Generally, however, the services are not required to

be 3

party but can be an integral part of the target

system, only abstracted for the scope of the scenario.

Similarly to the proofs, BPMN4FRSS is open to ex-

tensions representing concrete services. Explicitly in

this paper, extensions for PKI-based (

Cosi

c and Ba

ca,

2010) and blockchain-based (Weilbach and Motara,

2019) services are demonstrated.

4.3 Abstract Syntax

Figure 2 depicts how BPMN is extended by

BPMN4FRSS extension on BPMN abstract syn-

tax (OMG, 2010). It contains all the essential con-

cepts, as well as possible extension points. The model

is intentionally left incomplete to accommodate more

speciﬁc technologies relevant for forensic ready soft-

ware like integrity or non-repudiation controls.

The core syntactical constructs of BMPN4FRSS

are Potential Evidence Source and Potential Evidence

Type. The former can be applied on either BPMN

Task, Event, or Data Store, but only on one of those

simultaneously as the same point of origin cannot be

shared. Originating from a particular Potential Evi-

dence Source, multiple Potential Evidence Types can

be deﬁned. Furthermore, Data Relation relationships

can exist between the Potential Evidence Types, ei-

ther whole or its ﬁelds, with an expression specify-

ing it. A core construct denoting the locations (mul-

tiple are permitted) where Potential Evidence Types

are stored is the Evidence Storage, a specialization of

BPMN Data Store.

We deﬁned two types of extensions to BPMN

Pool. First, Evidence Context, as the name suggests,

speciﬁes the Pool where Potential Evidence Sources,

therefore also Potential Evidence Types can be de-

ﬁned with information regarding the cooperativeness

level of the context. The cooperativeness can be: (1)

Non-Cooperative: potential evidence is inaccessible

(e.g., personal device), (2) Cooperative: potential evi-

dence is accessible during every investigation, and (3)

Semi-Cooperative: potential evidence accessibility is

context-sensitive and is further speciﬁed in Cooper-

ativeness Context. The second extension, Proof Ser-

vice, is an abstract construct allowing the deﬁnition of

speciﬁc services, external from the modelled process

point of view, which provides proofs for Potential Ev-

idence Types.

The proofs themselves are organised under ab-

stract Proof, a special kind of Potential Evidence

Type. They can originate from within the system,

meaning a result of a Task in the modelled process,

but also form Proof Service by a Message Flow. Re-

gardless of origin, they deﬁne further assurance of

other Potential Evidence Types (e.g., corroborated

data, integrity).

Both the Proof Service and Proof are meant as ex-

plicit extension points for more concrete and technol-

ogy-dependent constructs. The formulation of exten-

sion points in BPMN4FRSS is motivated by stream-

lining the extensibility. For example, core BPMN-

4FRSS deﬁnes Hash Proof to represent the output of

a cryptographic hash algorithm commonly used as a

proof of integrity. Other possible extensions could be

constructs for digital signatures or hash structures.

Specialised Proof Service can also deﬁne a spe-

cialised and related Proof. An example is tuple BC

Timestamp Partial Proof and BC Timestamp Full

Proof, related to BC Timestamp Service, correspond-

ing to timestamping services based on blockchain.

It is particularly illustrating as it demonstrates the

support for different real services. For example,

ChainPoint (Liang et al., 2017) and OpenTimes-

tamps (Weilbach and Motara, 2019) require both par-

tial and full proof as the full proof will be commit-

ted with a time delay, so partial proof is generated

as a temporal receipt. On the other hand, Origin-

Stamp (Hepp et al., 2018) can generate full proof im-

mediately, if required.

The last group is three specializations of the

Business Process Model and Notation for Forensic-Ready Software Systems

ArtefactFlowObject

GraphicalObject

DataStore DataObjectAnnotation

PotentialEvidenceSource

{complete, disjoint}

Container

Pool Lane

{complete, disjoint}

EvidenceContext

- cooperativeness

ProofService

TimestampService

BCTimestampService

DataTransformation

- input

- output

- script

Gateway Task Event

{complete, disjoint}

{complete}

{complete, disjoint}

{incomplete}

{incomplete, disjoint}

{complete}

produces ►

stores ►

◄contains

TimestampProof HashProof

BCTimestampFullProofBCTimestampPartialProofPKITimestampProof

EvidenceDataRelation

- expression

{complete}

{incomplete, overlapping}

promiseOf ►

EvidenceStore

PKITimestampService

PotentialEvidenceType

- fields

Proof

IntegrityComputation

- input

- output

AuthenticityComputation

- input

- output

0..1

1..*

0..1

1..*

0..1 0..10..1

0..1

FRTask

{complete}

originatesFrom ►

{incomplete, overlapping}

{incomplete, disjoint}

Note: Classes highlighted in green represents the BMPN4FRSS constructs, and classes highlighted in orange are the

BMPN4FRSS extension points.

Figure 2: Abstract Syntax of BPMN4FRSS.

BPMN FRTask, which represents a Task relevant for

forensic readiness scope. These represent speciﬁc

computations related to establishing data integrity, au-

thenticity, and handling. Each of them speciﬁes input

and output data. Additionally, the Data Transforma-

tion deﬁnes a script for the transformation, allowing

for its documentation and validation to assert the im-

pact on the meaning of potential evidence. Again, it

is possible to extend either of them to address speciﬁc

schemes. Notably, the three specializations are not

disjoint to support schemes that address both authen-

ticity and integrity simultaneously.

4.4 Concrete Syntax

Realization of the BMPN4FRSS modelling notation

is done by introducing new visual elements and

stereotypes for existing BPMN constructs. More-

over, the stereotypes are further speciﬁed by param-

eters, which provide details regarding the application

of a particular stereotype. The stereotype-parameter

concept is rooted in the concept of proﬁles, stereo-

types, and tagged values used in UML (Arlow and

Neustadt, 2005). For the sake of clarity, we opt to use

green colour to highlight the constructs.

Table 2 contains a summary of the concrete syn-

tax and its mapping on the abstract syntax. Each ab-

stract syntax construct is mapped on either visual ele-

ment, stereotype, or parameter in the concrete syntax.

Therefore, some of the relationships are expressed as

parameters rather than visually. This choice was mo-

tivated by ﬁnding a balance between visual expres-

siveness and readability.

Core Concepts of the BPMN4FRSS deal with es-

tablishing the potential evidence, including its ori-

gin, context, and storage. Figure 3 describes a sim-

ple scenario, where both Business Data and Audit log

are marked as potential evidence. The difference be-

tween those two is that Business Data is an integral

part of the scenario, while the Audit log is its byprod-

uct but relevant for the possible investigation. Both

are organised under Evidence Context, which param-

eter Cooperativeness informing that the potential ev-

idence is always available if needed (e.g., under full

control of the responsible organization). Lastly, the

scenario deals with the persistent storage of Business

Data, so the Data Store is marked as such.

Device «EvidenceContext»

Compute

Business Data

Store

Business Data

«EvidenceType»

Business

Data Store

«EvidenceStore»

Audit Log

«EvidenceType»

Type: Cooperative Stored Potential Evidence: [Business Data]

Figure 3: Concrete syntax of BPMN4FRSS core concepts.

Proof speciﬁes an explicit corroboration of some

other potential evidence captured by the Evidence

Data Relation, which is visible in the Evidence View

(see Section 4.5). Figure 4 represents a scenario

where a digest was created for Business Data to prove

its integrity. The principal part is the Integrity Com-

ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering

100

Table 2: Concrete syntax of BPMN4FRSS.

Abstract Syntax Concrete Syntax Parameters

Potential

Evidence Source

Potential

Evidence Type

«EvidenceType»

Data Fields,

Lifecycle

Process

Produces

Evidence Data

Relation

Expression

Evidence

Context

«EvidenceContext» Cooperativeness

Evidence Store «EvidenceStore»

Stored Potential

Evidence

Hash Proof «HashProof»

PKI Timestamp

Proof

«PKITimestampProof» Originates From

BC Timestamp

Partial Proof

«BCTimestampPartialProof» Originates From

BC Timestamp

Full Proof

«BCTimestampFullProof» Originates From

Promise Of

<<promiseOf>>

PKI Timestamp

Service

«PKITimestampService»

BC Timestamp

Service

«BCTimestampService»

Authenticity

Computation

«AuthenticityComp» Input, Output

Integrity

Computation

«IntegrityComp» Input, Output

Data

Transformation

«DataTransformation»

Input, Output,

Script

putation Task which takes one Data Object as input

and produces a Hash Proof as an output. While not

included in the example, the storage of both the po-

tential evidence and proof greatly impacts its qualities

(e.g., storing them on separate devices). The same

input-output logic applies to other FRTasks as well,

and possible extensions might include additional in-

put or output (e.g., key).

Device «EvidenceContext»

Compute

Business Data

Compute Hash

«IntegrityComp»

Business Data

«EvidenceType»

Business Data

Digest

«HashProof»

Figure 4: Concrete syntax of BPMN4FRSS proof.

Proof Service establishes an external entity to

corroborate a Data Object. Figure 5 presents a sce-

nario of using a blockchain-based timestamping ser-

vice. To that end, a signed digest (output of Authen-

ticity and Integrity Computation) is sent to the service

to receive a partial proof. While some services of-

fer an instantaneous commitment to a blockchain, in

which the partial proof is skipped, we model a case

when the service ﬁrstly presents an acknowledgement

of receiving the data and the full proof at a later time,

when it is actually committed. In all cases, the full

proof is the desired and reliable guarantee. The PKI-

based timestamping service is modelled analogously,

as the Proof Service abstracts the inner mechanisms.

However, there are different guarantees from different

services and technologies in practice.

Device «EvidenceContext»

Potential Evidence

«EvidenceType»

Send to Blockchain

«AuthenticityComp»

«IntegrityComp»

Receive

Partial Proof

Store Partial Proof

Partial Proof

«BCTimestampPartialProof»

Timestamp

Proof Store

«EvidenceStore»

Potential

Evidence Store

«EvidenceStore»

Receive

Full Proof

Store Full Proof

Full Proof

«BCTimestampFullProof»

Blockchain Timestamping Service «BCTimestampService»

Figure 5: Concrete syntax of BPMN4FRSS proof service.

4.5 Model Views

PSP «EvidenceContext»

Request for

registration

received

Generate parking

service credential

Parking service

credential

Registration

data

Registration

request log

«EvidenceType»

PSP credential

storage

Send service

credential

Service

credential

reply log

«EvidenceType»

Credential

storage

audit log

«EvidenceType»

name,

email,

userId

Credential

storage

audit log

«EvidenceType»

requestId,

name,

Registration

request log

«EvidenceType»

Service

credential

reply log

«EvidenceType»

Figure 6: Scenario View (left) and Evidence View (right).

Visual presentation of every part of BPMN4FRSS,

speciﬁcally Evidence Data Relations, can be prob-

lematic, resulting in an overly complicated model di-

agram. A possible solution could be not to visualise

some relations and leave them in purely textual form.

Instead, we opted to provide two concurrent views on

a model, a well-known approach for software archi-

tecture modelling (Kruchten, 1995). Speciﬁcally, one

view focuses on the scenario and the other on the ev-

idence relationships.

Furthermore, we adopt the model view approach,

allowing us to combine several models into a single

goal-oriented view (Bruneliere et al., 2019). Speciﬁ-

cally, a separately modelled and reusable process de-

scribing the lifecycle of potential evidence is formu-

lated to supplement the main process model.

Scenario View is a default view displaying the

Business Process Model and Notation for Forensic-Ready Software Systems

101

core BPMN diagram enhanced by the BPMN4FRSS

visual elements and stereotypes. However, the Ev-

idence Data Relations between Potential Evidence

Types are omitted, as the clarity of the scenario is

favoured. An example is depicted in Figure 6 (left).

Evidence View is a specialised view focusing on

the relationships between Potential Evidence Types.

This includes annotated Evidence Data Relations and

timing information derived from the process repre-

sented with the direction arrow. An example is de-

picted in Figure 6 (right). The labels on each Ev-

idence Data Relation depicts expression parameter.

For brevity, the shared data ﬁelds are displayed, and

more complex functions are enlosed in curly brackets.

Lifecycle Process is a separate process, an exam-

ple depicted in Figure 5, capturing the lifecycle of

potential evidence. It also covers its processing and

strengthening (integrity and availability proofs). Al-

though the same can be expressed in the main pro-

cess, the separation promotes reusability and read-

ability. Furthermore, the Lifecycle Processes can be

shared among multiple Potential Evidence Types and

cascaded (i.e., new Potential Evidence Type in a Life-

cycle Process can have its own) but must be acyclic.

The Lifecycle Process cannot be used if the target Po-

tential Evidence Type is handled in the main process

apart from its creation.

5 APPLICATION OF BPMN4FRSS

To demonstrate the BPMN4FRSS, we apply the no-

tation to represent forensic-ready controls in the Au-

tomated Valet Parking (AVP) scenario (Nwaokolo,

2020). This particular scenario was previously utili-

sed to demonstrate a risk-based approach for forensic-

ready software systems (Daubner and Matulevi

cius,

2021), which discussed the risks and their mitigations

by forensic-ready controls. While the work provides

a good foundation for designing forensic-ready soft-

ware systems, the used BPMN modelling notation

aims for ad-hoc support of risk management deci-

sions, with only a basic syntax deﬁnition. Its major

shortcoming is the inability to support deeper reason-

ing and analysis of the scenario models due to a deﬁ-

ciency in both syntax and semantics. We expanded on

the results and ﬁlled the gap by introducing a properly

deﬁned notation with validation and analysis in mind.

Consequently, the scenario is ideal for validating our

approach, allowing a comparison to the current state

of the art in forensic-ready software design.

User device

Store parking

permit

Make payment

Payment

request

received

Parking

permit

storage

Payment

request

Parking permit

received

PSP

Parking request

Generate

parking

reservation

Send parking

reservation

Send parking

permit to user's

device

Payment

confirmation

received

Parking permit

received

Parking reservation Parking permit

PLT

Generate

parking permit

Send parking

permit

Parking permitPLT parking

permit storage

Parking

reservation

received

Parking reservation

Check access

right

Granted

Denied

Figure 7: Excerpt from Automated Valet Parking scenario:

Issuing a parking ticket.

5.1 Default Scenario

Figure 7 is an excerpt from the BPMN diagram de-

scribing a scenario of issuing a parking ticket. Con-

cretely, the presented part describes the process from

the payment made on an Autonomous Vehicle (AV)

to generating a parking permit by Parking Lot Termi-

nal (PLT), all facilitated by Parking Service Provider

(PSP), which sends the parking permit back to AV –

the user device.

In the default setting, numerous vulnerabilities

and a complete lack of sufﬁcient forensic-ready prop-

erties have been shown (Daubner and Matulevi

cius,

2021), giving malicious parties not only the possibil-

ity to attack but also making them hard-to-detect. To

enumerate the risks related to the scenario, a risk man-

agement process is employed (Matulevi

cius, 2017).

This demonstration assumes that risk management

was performed and the speciﬁc risks (including se-

curity and business) are known. Speciﬁcally, the fol-

lowing four risks are considered in the demonstration:

R1: A malicious insider injects a parking permit into

the PLT parking permit storage out-of-the-process

due to their capability to access it. Leading to a loss

of parking permit integrity.

R2: An attacker fabricates a fake Parking reservation

and sends it to PLT due to access control tampering.

Leading to the loss of Parking permit integrity.

R3: A dishonest customer repudiates a Parking per-

mit received from PSP, demanding a reimbursement,

leading to a ﬁnancial loss.

R4: An attacker uses zero-day vulnerability to fab-

ricate a Parking reservation. Leading to the loss of

ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering

102

parking permit integrity.

Reliable digital evidence is needed to detect and

prove the occurrence of the listed risks. To this end,

forensic-ready controls must be established, typically

in the form of new potential evidence sources and po-

tential evidence.

5.2 Forensic-ready Scenario

Figure 8 describes the scenario enhanced with foren-

sic-ready controls represented by BPNM4FRSS. It

explicitly covers all the listed risks by ensuring that

their occurrence can be detected and investigated.

Additionally, the relations between the potential evi-

dence, important for the risk treatment evaluation, are

visualised in Figure 9 depicting the evidence view of

the scenario.

The evaluation is performed manually by compar-

ing the potential evidence types produced in the parts

of the process describing the event of interest. Addi-

tionally, the evidentiary value of potential evidence is

determined based on relations with others. The risks

are addressed as follows:

R1: The actions of a malicious insider injecting

a parking permit into the PLT parking permit stor-

age are recorded as instances of the PLT permit stor-

age audit. Moreover, if the injection is performed

out-of-process, some evidence links will be missing

(PLT reservation incoming log) and thus detectable.

A possible issue involves tampering with potential ev-

idence, mitigable by adequate storage, e.g., remote

storage, representable in a lifecycle process.

R2: By itself, a fabricated parking reservation is in-

distinguishable for PLT, but it is detectable based on

the potential evidence introduced by forensic-ready

controls. Firstly, the instances of the PLT access audit

should record any modiﬁcations. Secondly, the fabri-

cation can be detected by reconstructing the evidence

links (e.g., PSP reservation outgoing log will be miss-

ing) and comparing the contents of PLT and PSP park-

ing permit stores.

R3: If a dishonest customer repudiates a parking

permit, any potential evidence on the user device is

unavailable due to the privacy and user’s unwilling-

ness (i.e., non-cooperating device). The overall goal

is to reinforce the timeliness, authenticity, and in-

tegrity of parking permits. This was achieved by

introducing the blockchain-based timestamping ser-

vice OpenTimestamps, which generates proofs of the

parking permit veriﬁable by 3

party. BPMN4FRSS

captures the proofs and their relationships within the

scenario.

R4: The forensic-ready controls assist in tackling the

zero-day vulnerability by proactively preserving po-

tential evidence in key areas. It is characterised as

"making the attacker noisy". Examples of such areas

are interfaces and storage as denoted on the model.

It could be argued that traditional security controls

could address the risks without the need for foren-

sic readiness. However, they do not fully mitigate

the risk in many cases. For example, the security

controls might not adequately cover business risks or

risks from insider threats, like R3 and R1. Forensic-

ready controls are in a sense complementing the se-

curity controls to provide means to detect and investi-

gate an occurrence of an incident.

6 CONCLUSION

Our work tackles the challenge of representing the

forensic-ready software system controls, and with the

combination of risk management, making reasoning

over them accessible also for software engineers with

only a basic knowledge of digital forensics. Addition-

ally, the intended use goes beyond software develop-

ment, promoting documentation of the systems use-

able during the investigation. Consequently, our re-

sult contributes to the evolving state-of-the-art in the

development of forensic-ready systems and is an en-

abler for evolution in this area.

6.1 Answers to Research Goals

The introduced BPMN extension can support the de-

velopment of forensic-ready software systems by en-

abling their modelling. We validated this claim by

enhancing an existing scenario with deﬁned risks to

model their mitigation using forensic-ready controls

systematically. Arguably, BPMN4FRSS met the set

goals in the following way:

G1: Modeling the scenario itself is possible using

plain BPMN, which is often the case in practice and

demonstrated in Figure 7. The BPMN4FRSS enables

enhancement of the scenario by marking the poten-

tial evidence and their points of origin within the sce-

nario. As a result, the scenario can be evaluated if it

is sufﬁciently covered with respect to the risks.

G2: BPMN4FRSS allows detailed documentation of

potential evidence in a textual way. However, to pro-

vide deeper insight into the relationships, we pro-

posed a specialised evidence view that visualises the

relationships in a tangible way. Consequently, non-

linked potential evidence and the clusters of related

or inadequately linked potential evidence are visually

detectable. Arguably, such presentation could be ben-

eﬁcial also during the investigation to communicate

the available data with an investigator.

Business Process Model and Notation for Forensic-Ready Software Systems

103

OpenTimestamps «BCTimestampService»

AV «EvidenceContext»

User Device

PSP «EvidenceContext»

PSP payment confirmation

incoming log

«EvidenceType»

Parking request

Generate

parking

reservation

Parking reservation

Store parking

permit proof

Payment

confirmation

received

Send parking

reservation

Send parking

permit to user's

device

PSP reservation

outgoing log

«EvidenceType»

PSP permit

incoming log

«EvidenceType»

PSP permit

outgoing log

«EvidenceType»

PSP permit proof

incoming log

«EvidenceType»

Parking permit

«Evidence Type»

Proof

received

Parking

permit

received

Parking permit BC proof (full)

«BCTimestampFullProof»

PSP parking

permit storage

«EvidenceStore»

PSP permit

storage audit

«EvidenceType»

PLT «EvidenceContext»

Send parking

permit

Send full proof

Granted

Parking permit

BC proof (part)

«BCTimestampPartialProof»

PLT permit

storage audit

«EvidenceType»

Store partial

proof

Partial proof

received

Full proof

received

Parking permit

BC proof (full)

«BCTimestampFullProof»

Generate

parking permit

«AuthenticityComp»

«IntegrityComp»

PLT permit

outgoing log

«EvidenceType»

Parking reservation

Denied

Check access

right

Parking

reservation

received

PLT

access audit

«EvidenceType»

PLT permit

proof

outgoing log

«EvidenceType»

PLT reservation

incoming log

«EvidenceType»

Parking permit

«Evidence Type»

PLT parking

permit storage

«EvidenceStore»

Figure 8: BPMN4FRSS model of enhanced AVP scenario (scenario view).

userID

userID,

reservationID

permitID

<<promiseOf>>

permitID

{hashIs(digest, "SHA-256")}

permitID, userID,

reservationID

{hashIs(digest, "SHA-256")}

permitID,

reservationID

permitID, userID,

reservationID

permitID, userID,

reservationID

permitID

accessToken

userID,

reservationID

permitID, userID,

reservationID

permitID

PSP payment

confirmation

incoming log

PSP reservation

outgoing log

permitID, userID,

reservationID

PSP permit

incoming log

PSP permit

outgoing log

PSP

permit

proof

incoming

log

PSP permit

storage audit

Parking permit

BC proof (part)

PLT permit storage audit

Parking permit

BC proof (full)

PLT permit

outgoing log

PLT

access audit

PLT permit

proof

outgoing log

Parking permit

reservationID

PLT reservation

incoming log

permitID

Figure 9: BPMN4FRSS model of enhanced AVP scenario

(evidence view).

G3: Establishing the potential evidence origin is not

sufﬁcient for a holistic representation of its lifecycle.

For that reason, BPMN4FRSS contains constructs to

express storage and handling of the evidence using

BPMN terms. A particular focus is given to strength-

ening the potential evidence by providing guarantees

on its authenticity, integrity, and timeliness, which is

a key task of forensic-ready software systems. We

provided support for both the internal creation of

guarantees and the involvement of an external service

to give as much ﬂexibility as possible. While it is un-

reasonable to elicit every possible method, we opted

to create extension points within BPMN4FRSS to in-

clude them once needed.

6.2 Future Work

The modelling notation is an important contribu-

tion in approaching forensic readiness from a soft-

ware engineering point of view. It is an enabler for

analysing forensic-ready risk scenarios, and in ex-

tension, forensic-ready software systems. While cur-

rently, the analysis is performed manually and infor-

mally, we build the BPMN4FRSS to support auto-

mated analysis, which is the objective for future work.

Furthermore, BPMN4FRSS models are a key compo-

nent in a bigger picture towards assurance methods

for forensic-ready software systems (Daubner et al.,

2020b), representing the manifestation of forensic-

ready requirements within the system for validation

and veriﬁcation.

Semantic Validity of the model must be estab-

lished in the ﬁrst place (Dijkman et al., 2008). While

the abstract syntax of BPMN4FRSS poses static re-

ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering

104

Table 3: Examples of BPMN4FRSS model semantic restrictions.

Rule Explanation

Data Objects and Data Stores with the same name in a single model

namespace are considered the same object for all intents and purposes.

This rule enables seamless linkability across multiple models into a

comprehensive view.

Non-Cooperative Evidence Context must not contain Potential Evidence

Sources nor Potential Evidence Types.

This rule forbids invalid deﬁnitions of potential evidence in contexts

where it would be inaccessible during an investigation.

Hash Proof must be an output of an Integrity Computation Task. This rule enforces the correct semantic of a cryptographic hash function.

PKI Timestamp Proof must be an output of Event, which has Message

Flow directed to it from a PKI Timestamp Service Pool.

This rule enforces the correct usage of PKI Timestamp Service.

Related BC Timestamp Partial Proof and Timestamp Full Proof must be

produced from the same BC Timestamp Service Pool.

This rule enforces the consistency of BC Timestamp Proofs.

strictions, the semantic ones are no less important.

Their examples are listed in Table 3. While the se-

mantic restrictions can be formulated in a textual way,

analogous to the catalogue of mistakes in UML di-

agrams (Chren et al., 2019), a formal deﬁnition of

semantics is desirable for automation and ambiguity

reduction. For example, ﬁrst-order logic could be

utilised, as shown on the inter-process communica-

tion in BPMN (Houhou et al., 2019).

Model-based Risk Analysis should automati-

cally investigate the effect of risk occurrence within

the modelled scenario. The goal is to determine

whether the employed forensic-ready controls are suf-

ﬁcient to detect the risk in question. For example, the

outcome would be sequences of potential evidence

generated under the default setting and under the risk,

which must be different. This approach would have

to combine additional modelling support to represent

a cybersecurity risk in BPMN, such as Security Risk-

Oriented BPMN (Matulevi

cius, 2017), which can be

employed side-to-side with BPMN4FRSS.

Toolset is needed for the effective creation, vali-

dation, and analysis of BPMN4FRSS-enhanced mod-

els. Besides being crucial for broader adoption of

BPMN4FRSS, the need for proper tool support has

been identiﬁed as a software challenge for forensic-

ready software systems (Pasquale et al., 2018).

ACKNOWLEDGEMENTS

This research was supported by ERDF "CyberSecu-

rity, CyberCrime and Critical Information Infrastruc-

tures Center of Excellence" (No. CZ.02.1.01/0.0/0.0/

16_019/0000822).

REFERENCES

Alrajeh, D., Pasquale, L., and Nuseibeh, B. (2017). On

evidence preservation requirements for forensic-ready

systems. In Proceedings of the 2017 11th Joint

Meeting on Foundations of Software Engineering,

ESEC/FSE 2017, page 559–569. ACM.

Alrimawi, F., Pasquale, L., and Nuseibeh, B. (2017). Soft-

ware engineering challenges for investigating cyber-

physical incidents. In 2017 IEEE/ACM 3rd Interna-

tional Workshop on Software Engineering for Smart

Cyber-Physical Systems (SEsCPS), pages 34–40.

Altuhhova, O., Matulevi

cius, R., and Ahmed, N. (2013). An

extension of business process model and notation for

security risk management. International Journal of

Information System Modeling and Design, 4:93–113.

Arlow, J. and Neustadt, I. (2005). UML 2 and the uni-

ﬁed process: practical object-oriented analysis and

design. Pearson Education.

Bajramovic, E., Waedt, K., Ciriello, A., and Gupta, D.

(2016). Forensic readiness of smart buildings: Pre-

conditions for subsequent cybersecurity tests. In 2016

IEEE International Smart Cities Conference (ISC2),

pages 1–6.

Bruneliere, H., Burger, E., Cabot, J., and Wimmer, M.

(2019). A feature-based survey of model view ap-

proaches. Software & Systems Modeling, 18(3):1931–

1952.

Casey, E. (2011). Digital evidence and computer crime.

Academic Press, 3rd ed edition.

Casey, E. and Nikkel, B. (2020). Forensic analysis as iter-

ative learning. In The Security of Critical Infrastruc-

tures, pages 177–192. Springer.

Chergui, M. E. A. and Benslimane, S. M. (2018). A valid

bpmn extension for supporting security requirements

based on cyber security ontology. In Model and Data

Engineering, pages 219–232. Springer.

Chren, S., Buhnova, B., Macak, M., Daubner, L., and

Rossi, B. (2019). Mistakes in uml diagrams: Analysis

of student projects in a software engineering course.

In 2019 IEEE/ACM 41st International Conference on

Software Engineering: Software Engineering Educa-

tion and Training (ICSE-SEET), pages 100–109.

Daubner, L., Macak, M., Buhnova, B., and Pitner, T.

(2020a). Towards veriﬁable evidence generation in

forensic-ready systems. In 2020 IEEE International

Conference on Big Data (Big Data), pages 2264–

2269.

Daubner, L., Macak, M., Buhnova, B., and Pitner, T.

(2020b). Veriﬁcation of forensic readiness in software

development: A roadmap. In Proceedings of the 35th

Annual ACM Symposium on Applied Computing, SAC

’20, page 1658–1661. ACM.

Daubner, L. and Matulevi

cius, R. (2021). Risk-oriented de-

sign approach for forensic-ready software systems. In

Business Process Model and Notation for Forensic-Ready Software Systems

105

The 16th International Conference on Availability, Re-

liability and Security, ARES 2021. ACM.

Dijkman, R. M., Dumas, M., and Ouyang, C. (2008).

Semantics and analysis of business process mod-

els in bpmn. Information and Software technology,

50(12):1281–1294.

Elyas, M., Ahmad, A., Maynard, S. B., and Lonie, A.

(2015). Digital forensic readiness: Expert perspec-

tives on a theoretical framework. Computers & Secu-

rity, 52:70–89.

Geismann, J. and Bodden, E. (2020). A systematic litera-

ture review of model-driven security engineering for

cyber–physical systems. Journal of Systems and Soft-

ware, 169:110697.

Grispos, G., García-Galán, J., Pasquale, L., and Nuseibeh,

B. (2017a). Are you ready? towards the engineer-

ing of forensic-ready systems. In 2017 11th Interna-

tional Conference on Research Challenges in Infor-

mation Science (RCIS), pages 328–333.

Grispos, G., Glisson, W. B., and Choo, K.-K. R. (2017b).

Medical cyber-physical systems development: A

forensics-driven approach. In 2017 IEEE/ACM In-

ternational Conference on Connected Health: Ap-

plications, Systems and Engineering Technologies

(CHASE), pages 108–113.

Grobler, C. P. and Louwrens, C. P. (2007). Digital foren-

sic readiness as a component of information security

best practice. In New Approaches for Security, Pri-

vacy and Trust in Complex Environments, pages 13–

24. Springer.

Harel, D. and Rumpe, B. (2004). Meaningful modeling:

what’s the semantics of "semantics"? Computer,

37(10):64–72.

Henley, J. (2019). Denmark frees 32 inmates over ﬂaws in

phone geolocation evidence. The Guardian.

Hepp, T., Schoenhals, A., Gondek, C., and Gipp, B. (2018).

Originstamp: A blockchain-backed system for decen-

tralized trusted timestamping. it - Information Tech-

nology, 60(5-6):273–281.

Houhou, S., Baarir, S., Poizat, P., and Quéinnec, P. (2019).

A ﬁrst-order logic semantics for communication-

parametric bpmn collaborations. In Business Process

Management, pages 52–68, Cham. Springer.

Kävrestad, J. (2018). Fundamentals of Digital Forensics.

Springer.

Kruchten, P. (1995). The 4+1 view model of architecture.

IEEE Software, 12(6):42–50.

Liang, X., Shetty, S., Tosh, D., Kamhoua, C., Kwiat, K.,

and Njilla, L. (2017). Provchain: A blockchain-

based data provenance architecture in cloud environ-

ment with enhanced privacy and availability. In 2017

17th IEEE/ACM International Symposium on Cluster,

Cloud and Grid Computing (CCGRID), pages 468–

477.

Matulevi

cius, R. (2017). Fundamentals of secure system

modelling. Springer.

McKemmish, R. (2008). When is digital evidence foren-

sically sound? In Advances in Digital Forensics IV,

pages 3–15. Springer.

Mülle, J., Stackelberg, S. v., and Böhm, K. (2011). A se-

curity language for bpmn process models. Technical

Report 9, Karlsruher Institut für Technologie.

Nwaokolo, A. O. (2020). A comparison of privacy enhanc-

ing technologies in internet of vehicle systems. Mas-

ter’s thesis, University of Tartu.

OMG (2010). Business process model and notation. https:

//www.omg.org/spec/BPMN/2.0/.

Cosi

c, J. and Ba

ca, M. (2010). (im)proving chain of custody

and digital evidence integrity with time stamp. In The

33rd International Convention MIPRO, pages 1226–

1230.

Pasquale, L., Alrajeh, D., Peersman, C., Tun, T., Nuseibeh,

B., and Rashid, A. (2018). Towards forensic-ready

software systems. In Proceedings of the 40th Inter-

national Conference on Software Engineering: New

Ideas and Emerging Results, ICSE-NIER ’18, page

9–12. ACM.

Pullonen, P., Matulevi

cius, R., and Bogdanov, D. (2017).

Pe-bpmn: Privacy-enhanced business process model

and notation. In Business Process Management, pages

40–56. Springer.

Pullonen, P., Tom, J., Matulevi

cius, R., and Toots, A.

(2019). Privacy-enhanced bpmn: Enabling data pri-

vacy analysis in business processes models. Software

and Systems Modeling, 18(6):3235–3264.

Rivera-Ortiz, F. and Pasquale, L. (2020). Automated mod-

elling of security incidents to represent logging re-

quirements in software systems. In Proceedings of the

15th International Conference on Availability, Relia-

bility and Security, ARES ’20. ACM.

Rodríguez, A., Fernández-Medina, E., and Piattini, M.

(2007). A bpmn extension for the modeling of se-

curity requirements in business processes. IEICE -

Trans. Inf. Syst., E90-D(4):745–752.

Rowlingson, R. (2004). A ten step process for forensic re-

adiness. International Journal of Digital Evidence, 2.

Sachowski, J. (2016). Implementing Digital Forensic

Readiness. Syngress.

Salnitri, M., Dalpiaz, F., and Giorgini, P. (2014). Modeling

and verifying security policies in business processes.

In Enterprise, Business-Process and Information Sys-

tems Modeling, pages 200–214. Springer.

Silver, B. (2011). BPMN Method and Style, with BPMN

Implementer’s Guide: A structured approach for

business process modeling and implementation using

BPMN 2.0. Cody-Cassidy Press Aptos, CA, USA.

Studiawan, H., Sohel, F., and Payne, C. (2019). A survey on

forensic investigation of operating system logs. Digi-

tal Investigation, 29:1–20.

Tan, J. (2001). Forensic readiness. Technical report,

@stake, Inc.

Van den Berghe, A., Scandariato, R., Yskout, K., and

Joosen, W. (2017). Design notations for secure soft-

ware: a systematic literature review. Software & Sys-

tems Modeling, 16(3):809–831.

Weilbach, W. T. and Motara, Y. M. (2019). Applying

distributed ledger technology to digital evidence in-

tegrity. SAIEE Africa Research Journal, 110(2):77–

93.

ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering

106