CHAPTER 7. REQUIREMENTS CAPTURE 7.3 Security
sumed that that role will always have access to that data (e.g. through a copy), and is a necessary restriction to ensure valid authentication to current data.
Because roles are required to include the result of the previous activity as part of their own signature, it is important that a user is able to verify the state of the workflow execution which property 7.3.2-7 ensures.
7.3.2.1 Signature Scheme
A primary requirement of the workflow system is that activities have legal significance, hence the chosen signature schememustbe encompassed by [3] and by extension [4].
This imposes the following requirements on the system implementation:
• It must be possible to use X.509 (7.3-9)
Because of the difficulty in graphically reproducing content the same way across different sys-tems, this is cannot be required of the supported system, hence:
• The system need not support what-you-see-is-what-you-sign (7.3-10) 7.3.3 Access Control (Authorization)
Access control can be divided into controls that can be enforced only when the container is stored in a physical machine to which a role does not have access, and those that can be en-forced even if the role has physical access to the machine.
It is not possible to prevent4a role from changing a container when the role has control over the container, even if the access controls specify that the role is not allowed to do so. However, it is possible to prevent a role from reading a document in a container by encrypting it.
Requirements for authorization is summarized by the following
• Any role must be able to confirm the authorization of all previous roles (7.3-11)
• A role must not be able to effect any loss of data other than the data that role has cre-ated during the current activity
(7.3-12)
• A role must not be able to effect loss of data that role has created during a previous activity
(7.3-13)
• A role must be authorized to perform an activity (signature) (7.3-14)
7.3.4 System Availability
It stands to reason, that availability requirements for a given system depend solely on the purpose of that system, and the requirements for system availability should be evaluated in terms of the effect, that an unavailable system has on the organization employing this system.
Requirements for availability is summarized by the following
• System unavailability has negligible impact on the surrounding organization (7.3-15)
• Complementary security technologiescanthwart attacks by unauthenticated users (7.3-16)
• Implementation should allow transparent redundancy or fail-over (7.3-17)
• Implementation may allow limited operation without infrastructure (7.3-18)
4The problem of enforcing access control on digital content in the (complete) control of a user, can be likened to the problem of enforcing DRM on other digital content such as music and films, which so far has proven futile. The system design will assume that a user is able to performanyaction on digital content in the user’s control, but the user will not be able to read encrypted content,the user is not nor has been allowed to read.
CHAPTER 7. REQUIREMENTS CAPTURE 7.3 Security
7.3.4.1 Impact of Unavailability
A document workflow system in which each role is a person, and where the work implied in each activity takes much longer to complete than the role-system interaction of that activity itself, does not carry any special requirements for system availability (assuming the domain description of 2).
If each activity involve work that takes one or more people an average of several hours to com-plete, a system unavailability of a few hours will be insignificant compared to unexpected delays that execution of a given activity may involve. One activity in a workflow may e.g. involve reg-istration of results of a lab experiment, however this experiment may fail thus delaying theentire workflow for the duration of this experiment.
It may further be assumed, that the system will be operated in the context of a modern IT-infrastructure, employing operational procedures and monitoring intended to register system er-rors and alert system operators.
This means, that system resilience to attacks aimed at system resources and system availability is not aprimaryrequirement as
• system availability doesn’t have any noticeable effect on the surrounding organization
• compensating controls in the general IT-infrastructure will detect this 7.3.5 Document Confidentiality
Document confidentiality controls who can read the versions of a document a workflow exe-cution accumulates. Most companies use e-mail for communicating confidential information, butvery few actually use encrypted e-mail, hence using that as a baseline for requirements for confidentiality, would indicate that requirements are limited.
A more realistic baseline requirement is:
• An unauthenticated or unauthorized rolemustnot be able to access any workflow data
(7.3-19)
Document confidentiality can also be extended to implement reader access authorization, in which case the following apply
• A role may only access production data for explicitly defined activities (7.3-20)
• A role may only access control data for explicitly defined activities (7.3-21)
• A role may only know the identity of explicitly defined roles (7.3-22) If document confidentiality is ensured by encrypting each unit of content, regardless of who gains access to a container, they would still require the proper key(s) to access the content.
7.3.6 System Auditing
The main requirement for system auditing is:
• Workflow execution must be self documenting (7.3-23)
System auditing facilitates debugging, and ensures a complete audit- and transaction log5which is a requirement.
The following properties apply to system auditing:
5Maintaining complete audit- and transaction log is required by law for systems that process data that affects a company’s financial statement.
X-Flow 55