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?
No comments:
Post a Comment