control-flow trust, from a technical security point of view

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?

ideas ..

• benefit of the group is above the benefit if the person.
• avoiding problems more important than gaining benefit.

Workflow Perspectives

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)

Reliability trust & Decision trust

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.

Trust & data in BPM

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.

Trust & Control-Flow

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? 

Trust ..

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.