A
B Parallel Split (AND-split)
C
C A
Synchronization (AND-join)
B
A
Exclusive Choice (XOR-split) B
C
Simple Merge (OR-join)
A B
C
Figure 4.3.4UML representation of simple transition patterns
UML activity diagrams may be used as model checker by [26][27]
• verifying properties of the activity diagram itself, and
• verifying other (UML) models (diagrams) against an activity diagram
Several UML based CASE (computer aided software engineering) tools incorporate some form of model checking (e.g. IBM Rational Software Development Platform [28], Enterprise Architect [29], and others [30][31]), as well as offering both forward- and reverse engineering between code and UML model.
In the rest of this thesis, UML activity diagrams will be used to express workflow models.
4.3.3 Extending the Models
Both Petri Nets and UML activity diagrams can express simple transition patterns, but several other elements of a workflow, as defined in section 4.1 are not readily apparent. Specifically neither notation denote role to the activities and flow of production data.
In UML, object constraint language (OCL) [32] may be used to condition transitions, and by ex-tension may be used to express role. This addition is necessary in formal analysis of models, but is ill-suited for more informal visual model analysis.
The common approach to graphically representing roles is to partition the model in "swim-lanes", where each lane represents a distinct role [20], and this notation will also be used here.
Production data may be expressed by theobjectelement that is defined for UML activity dia-grams.
4.4 Document Workflow Support
The possible ways a document can be distributed between recipients are determined by the sup-ported transition patterns, hence theX-flowsystem need only support transition patterns typically required by a document workflow. TheX-flowsystem should
• allow specification of workflow (4.4-1)
• automate the workflow process (4.4-2)
• support simple transition patterns (4.4-3)
• have a well defined decision process (4.4-4)
CHAPTER 4. WORKFLOW SYSTEMS 4.4 Document Workflow Support
Specifying a workflow is a complex task that most companies have designated employees per-form, and the inflexibility, that a user cannot specify a workflow at will, means that specifications must be relatively static, hence a workflow must be
• well understood
• well defined
• static
By correlation, in most situations complex transition patterns are not necessary because
• users don’t understand the process
• business processes that would require them are too difficult to describe
– and such complex processes would change frequently, as things become done differ-ently
• workflows incorporating them become too error prone
Complex or large workflow specifications are more prone to changes due to external factors (re-organizations, doing things differently, etc.) making them less usable. If a user needs to create a document, and the workflow system isunavailable due to lack of workflow specification, the user will simply resort to other means, e.g. e-mail.
Disregarding scalability most workflows can be realized using the sequence pattern. AND-patterns improve scalability by allowing concurrent processing, and OR-AND-patterns by reducing the number of steps in the workflow.
4.4.1 Optimizing Workflow Specifications
One pattern that occurs frequently when many people collaborate to create a document, is the case where one person has authored a document thatmustbe approved bym >2, m∩nnumber of people, before the author can continue working on the document. This pattern can be realized using nested AND-split, but assuming that transitions cannot be cascaded, this construction will introduce a number of redundant activities.
A better approach would be to introduce a pattern that allows the current thread to branch into t > 2 threads, of which0 < x ≤ t must be executed. This would only require one transition to model the scenario, and would not halt the workflow, if a number of the branches were not visited. Likewise, a pattern is required that will merge this type of branch.
Summarizing, theX-flow system should support:
• Multi-choice transition pattern (4.4-5)
• Synchronizing merge transition pattern (4.4-6)
4.4.2 Document Aging
In a document workflow system, multiple different versions of the original document is created during the course of workflow execution which necessitates that a rank of the document versions is established.
In a workflow comprising only sequence transitions ranking documents is not a problem, as a newer versions directly precede their ancestors, but in a workflow with branches several different versions of a document may exist at any given time.
In theX-flowsystem, document aging should be performed according to the following rules:
X-Flow 29
CHAPTER 4. WORKFLOW SYSTEMS 4.4 Document Workflow Support
• concurrent modification of a document is not possible (4.4-7)
• a modification activity creates a new version of a document (4.4-8)
• a new version precedes all current and previous modifications and reviews (4.4-9)
• at any given time onlyone version of a document is valid (4.4-10) The workflow models covered in this chapter assume one start point and one end point, and the result of a workflow that results in multiple versions in the end point is ambiguous, hence multiple concurrent versions are disallowed.
The aging scheme does not prevent splits in a workflow, but it does prevent splits where modi-fication occurs in one or more of the branches. A split, where modimodi-fication only takes place in one branch, doesnot create multiple versions, as only a modification creates a new version, and is disallowed because of rule 4.4-9. As this case does not create multiple versions, it could be allowed without creating undefined states in the workflow, but negative impact on implementa-tion and data model outweighs the advantages that this branch optimizaimplementa-tion might carry.
Using the above mentioned rules ensures that when a modification activity is entered, there will be no review in a part of the workflow graph, that this modification activity does not precede or is ancestor of, which means that the backing data model does not have to support several branches.
On the other hand, allowing reviews to take place on different part of the workflow graph, would in some cases provide a nice optimization, where work can continue on a document, while formal approval is obtained e.g. for a project milestone draft.
4.4.3 Document Versioning
Content creation that takes place over a number of activities can be created by:
• Modify and delete
• Create and Append
In the first scheme, modifications are directly applied to the result of a previous activity, while in the second, the result isappended to the result of the previous activity. The latter is the principle of version control systems, as it maintains a copy of every version that has existed.
The intended workflow system should be self documenting, hence
• the workflow system should provide document versioning (4.4-11) Keeping a copy of all versions that have been created, ensures a complete transaction log of the workflow execution, which is also a required security objective of the system3
3Keeping a copy of all versions is also necessary in order to be able to verify a signature applied to a specific document version.
Security Analysis 5
System security should be based on an analysis of the threats the system will face. A system may have many weaknesses but if no corresponding threats exist, they have no impact on the overall system security.
This chapter presents a security analysis of a secure workflow system. It introduces the threats theX-flow system will likely face, and based on this, relevant security objectives of the system are defined. Chapter 7 decomposes these objectives into specific system security requirements.
Objectives that ensure that theworkflow isexecuted correctly are not covered in this chapter, although they may be described using properties of security objectives. Workflow objectives are described in section 7.2, where the security objectives are modified and extended to comprise workflow objectives.
The security analysis is organized as follows:
1. Section 5.1 states the preconditions that apply to theX-flow system. A system cannot just besecure, and defining necessary prerequisites and external requirements is fundamental to expressing what security objectives the systemshould ensure.
2. Threats may be directed towards a system from many directions, and section 5.2 defines what agents may represent threats towards the system. The section also describes the threat agents’ relations to the system, and the reason why certain threat agents are irrelevant as stated in section 5.1.
3. Based on the defined threat agents, section 5.3 states the possible threat macros that relate to the system. A threat macro constitutes a threat agent, the targeted security metric, and a description of the applicable scenario. The section also provides a qualitative description of reason for the identified threat macros.
4. Finally section 5.4 states the required security objectives of the system, in terms of the defined threat macros and system security policy.
5.1 Preconditions
TheX-flow will not be designed to counter any conceivable threat, hence a number of assump-tions about the system operating environment and implementation details are required.
In this analysis, as well as the rest of this thesis, physical security and operating system platform security will not be treated, nor will their impact on system security. Thus, if an attacker gains one of the following
• physical access to the hardware on which the system is running (5.1-1)