If one can “Trust” data, and resources, then one can “Trust” the
process, which means, in BPM to be able to say that this is a “Trusted”
process, resources and data of this process should all be
“Trusted”.
Studying the BPM lifecycle showed that solving the problems of
‘data trustworthiness’ and ‘resource trustworthiness’ that would cover all
stages of BPM lifecycle except for the ‘Diagnoses stage’ which why it is
important to add a new question about the problem of ‘data mining of trust
related information’. This could be concluded in the following question:
-How to strengthen the
trust-aware systems by Mining Trust related information?
This
could be done at the beginning by mining any data related to trust as the first
step, then as a second step that could be enhanced by designing the log files
to be rich with Trust related information and that would help more in mining.
So to answer the question ‘How to strengthen the trust-aware systems by Mining
Trust related information?’ We have to answer the following Investigative
Questions:
a.How to mine trust related
information from typical log file?
b.How to enrich log files with
Trust related information?
An
idea to deal with ‘resources trustworthiness’ is to have a “trust profile”
related to each resource, the system should make use of available information
to build these profiles that can be used to analyze the resource trustworthiness,
which can be used in various ways (i.e. work allocation). To be able to use
such idea it is important to know how to build these profiles, and how to make
use of them. So, these are also important questions to answer to solve the
problem of ‘Resource trustworthiness’:
a.How to fill and update Trust
informed resource profile?
b.How to make use of these
Trust profiles in BPM systems (e.g. Trust base work allocation)?
Similar
idea could be used to solve the problem of ‘data trustworthiness’, as annotations
could be added to data to represent trust requirements for the data (wither it
is control data or object data), where a system could use these annotated data
to honor the trust requirements. To apply such solution we first must answer
the questions on how to annotate trust requirements within data, and how a BPM
system can exploit these trust annotated data. So, another two important
questions are:
a.How to build a trust
annotated data?
b.How to exploit Trust
annotated data in BPM systems?
Because
data do not behave on there own (non-behavioral entity), so, to trust data in
BPM will mean that data should resist
any malicious attack and stay as they are expected to be. For
example in a banking sector, if a transfer process was to ‘transfer $5,000 to
account number 12345’ if the data got maliciously manipulated and the attacker
changed the account number the process will end up not doing what it is
expected to do. Another example if the attacker changed the data of ‘transfer
to’ and made it ‘transfer from’ the client will end up loosing money instead of
getting money. So it is important for both ‘control data’ and ‘object data’ to
know if they are trustworthy r not, it is important for the resource and the system
to know the trustworthiness of the data. There are few ideas on how to solve
this problem, for example we can build trust-annotated data so system and
resources will use these annotations to analyze the trustworthiness of the
data.
Based on the definition of trust that we have
established, to trust the control-flow means to make sure that the workflow
will proceed as it suppose to and will resist being maliciously
modified. That means firstly, to
make sure that the design of the workflow was done according to the process
owner’s needs and satisfy all requirements (which is related to process
design). Secondly, to make sure that the system will correctly interpret the
model and will not modify it. Thirdly, to make sure that the system will
protect against any malicious modification
of the workflow, which depends mostly on the system configuration and security
settings. So first requirement is a real “Trust” requirement but it is related
to ‘Process design’ which is out of the scope. The other requirement on the
other hand is not a real requirement, because once a system is known to be
trusted doing such task, there is no need to be tested every time, and most
systems are used only after establishing that it is trustworthy and it would
not modify the model. Third requirement is a real requirement that is related
to process execution (process automation), for example if a bank is using an
automated process, even if the executed model was according to requirements and
it is working as it suppose to, there are no guarantee that the workflow will
not be maliciously modified and the new workflow will send
sensitive data to the public or allow untrusted resource to look in to classified
data. That’s might raise a question: how to design control-flow in a way that
resists any unauthorized modification?
The workflow concept has defacto become the standard paradigm for process modeling in business process management (BPM) systems. Workflows are typically looked from three perspectives:
1) the control perspective, describing the logical order of tasks;
2) the data perspective, describing the information exchange between tasks;
3) the resource perspective, describing the originators of tasks.
(Trˇcka et al, 2008)
Although it
is easy to recognize Trust and it’s manifestations in everyday life, it is
challenging to define trust. For example the definition by Kuntze et al (2008)
“trust means an entity always behaves in the expected manner for the intended
purpose” this definition would seem to the reader as a good holistic
definition, but the definition assumes that all entities behave, which is not
true, as we have non-behavioral entity such as data. Another example, the
definition by Jøsang (1997) he says trust means an entity “will resist attacks
from malicious agents”, this definition covers only one side of the trust
issue, as it is also important to trust entity even though it is known there
will be no attacks from malicious agents, which was neglected in this
definition.
In 2007
Jøsang recognized that trust could be seen as two types: “reliability trust”
and “decision trust”. Reliability
trust can be seen as trustworthiness of someone or something, for example in a
medical procedure how reliable is the surgeon (resource) who is doing this
procedure (is he trustworthy). Or how reliable is this procedure (process), how
many times was it success (is it trustworthy process). Gabetta in (1990)
defined trust in a way that can formulate ‘reliability trust’, he says: “Trust
is the subjective probability by which an individual, A, expects that another
individual, B, performs a given action on which A’s welfare depends”.
However
trust is not only about ‘reliability trust’, as Falcone & Castelfranchi
(2001) noted that even having a high reliability trust is not enough to depend
on this resource, or this process. They suggested introducing some
saturation-based method to influence the decision trust. They define ‘decision
trust’ as: “Trust is the extent to which a given party is willing to depend on
something or somebody in a given situation with a feeling of relative security,
even though negative consequences are possible” (Falcone & Castelfranchi,
2001). To illustrate the difference between the two types of trust lets go back
to the previous medical procedure example. If a Hart Rate Monitor device known
to be ‘not reliable’ (40% of the time gives faulty results), in a normal
scheduled surgery, the surgeon will avoid depending on such device (resource)
and would ask to replace it, but if there was an emergency situation that
require an immediate surgery and this device was the only one available, the
surgeon will likely use and depend on this devise even though it is known to be
unreliable. So even though the reliability trust in the resource is same on
both situations, decision trust was different within the same process. That
shows even though trustworthiness (reliability trust) is a very important
factor, but it is not the only factor affecting decision trust, and there are
other factors such as situation context, associated risk, environmental
factors, and possible outcomes, which might affect the decision trust.
Reliability trust could be represented in a discrete degree of reliability (i.e.
in percentage “%”), where decision trust is mostly represented in a binary
decision (i.e. trust, or do not trust) (for more on trust and how we reach this
definition please refer to the literature review).
So what is
Trust in terms of BPM. As it is obvious from the definition, to solve the
problem of ‘Trust’, we need to solve the problem of ‘Decision trust’, which
mainly depends on ‘Reliability trust’, plus other factors that might affect the
decision. So, to solve the problem of trust in BPM, first we need to define
‘Reliability trust’ (or trustworthiness) and how it would be solved in BPM, and
then we need to analyze what other factors that might affect ‘Decision trust’
beside the trustworthiness, and how to asses them and include them in a
mathematical way to be able to calculate the ‘Decision trust’ automatically.
Because
data do not behave on there own (non-behavioral entity), so, to trust data in
BPM will mean that data should resist
any malicious attack and stay as they are expected to be. For
example in a banking sector, if a transfer process was to ‘transfer $5,000 to
account number 12345’ if the data got maliciously manipulated and the attacker
changed the account number the process will end up not doing what it is
expected to do. Another example if the attacker changed the data of ‘transfer
to’ and made it ‘transfer from’ the client will end up loosing money instead of
getting money. So it is important for both ‘control data’ and ‘object data’ to
know if they are trustworthy r not, it is important for the resource and the system
to know the trustworthiness of the data. There are few ideas on how to solve
this problem, for example we can build trust-annotated data so system and
resources will use these annotations to analyze the trustworthiness of the
data.
Based on the definition of trust that we have
established, to trust the control-flow means to make sure that the workflow
will proceed as it suppose to and will resist being maliciously
modified. That means firstly, to
make sure that the design of the workflow was done according to the process
owner’s needs and satisfy all requirements (which is related to process
design). Secondly, to make sure that the system will correctly interpret the
model and will not modify it. Thirdly, to make sure that the system will
protect against any malicious modification
of the workflow, which depends mostly on the system configuration and security
settings. So first requirement is a real “Trust” requirement but it is related
to ‘Process design’ which is out of the scope. The other requirement on the
other hand is not a real requirement, because once a system is known to be
trusted doing such task, there is no need to be tested every time, and most
systems are used only after establishing that it is trustworthy and it would
not modify the model. Third requirement is a real requirement that is related
to process execution (process automation), for example if a bank is using an
automated process, even if the executed model was according to requirements and
it is working as it suppose to, there are no guarantee that the workflow will
not be maliciously modified and the new workflow will send
sensitive data to the public or allow untrusted resource to look in to
classified data. That’s might raise a question: how to design control-flow in a
way that resists any unauthorized modification?
Although Trust sounds like a known term, it is
not easy to define trust. The best definition found so far, is the definition
by Kuntze et al (2008) they say that trust means “an entity always
behaves in the expected manner for the intended purpose”. Although this definition
sounds like what it meant by trust, but it is not complete, as it would not
apply on a non-behavioral entities such as “data” as they do not “Behave”. So
it is important to add to the previous definition that, “trust” for
non-behavioral entities means that “it will resist attacks from malicious
agents” (Josang, 1997). So combining the two definitions we can define “Trust”
as that ‘an entity always behaves in the expected manner for the intended
purpose, and will resist attacks from malicious agents’.If trust were to be applied to a specific domain the definition should
satisfy the trust’s requirements in this domain, for example to know if the
previous definition would apply to trust for BPM, it is important to understand
what are trust requirements for BPM.
