ORKA – Organizational Control Architecture

Project structure and approach

ORKA Themenbereiche The ORKA project is organized in five subject areas CONTROL, SPEC, ENFORCE, VALID, and ADMIN. All subject areas have different emphases to meet ORKA's vision of a holistic dynamic and arganization-based control architecture.

CONTROL – Organizational Control

Control Logo The subject area CONTROL embraces the areas SPEC, ENFORCE, VALID, and ADMIN on an overall level playing a cross-context role. The work within CONTROL aims at coordinating the results of the other four subject areas, in order to achieve a consistent execution and outcome.

CONTROL covers for example the preparation of case studies. Among other things, these case studies provide the foundation for the other subject areas. Other CONTROL work packages tackle the continuous alignment of results from the different working areas. Another important point of focus is the specification, setup, and operation of an integration laboratory. Within this lab, the different software components from all subject areas are brought together for testing, evaluation, and assessment. As an integral part, the tests cover for example a security assessment of the created components.

The following items can be considered the main collaboration interdependencies between CONTROL and the other subject areas:

SPEC: CONTROL particularly delivers the results of the case studies, pointing out the requirements for the specification language that is developed within the SPEC package. During the project, the properties of the language will be checked against these requirements.
ENFORCE, VALID: For the areas ENFORCE and VALID, CONTROL delivers specification and implementation of adaptions to a workflow engine in order to generate organisational context information. The implementations that are subsequently created within ENFORCE and VALID are being assessed within the CONTROL integration laboratory.
ADMIN: The case studies from CONTROL are used for extracting requirements for policy administration.

SPEC – Specification of policies

Spec Logo The workpackages of SPEC deal with security policy specification and particularly authorization policy specification. For the time being, we consider only policies based on the role-based access control model. After analyzing and classifying existing approaches and policy languages, our goal is to develop an appropriate language for ORKA. It has to be decided whether this can be achieved by enhancing and refining an existing language or whether designing a new language is necessary. In particular, the language shall be able to express separation of duty, dynamic authorization constraints, delegation of rights, and a role-hierarchy. Furthermore it shall be capable of supporting workflows. Even though we strive for high expressiveness, applicability of policy validation techniques is an important requirement in the design of the language. Finally, in order to be able to create and handle complex policies easily and to provide some validation checks, the goal of SPEC is to develop a user-friendly interface for the policy administrator.

ENFORCE – Enforcement and integration

Enforce Logo The policy enforcement activity will focus on a broad inspection of existing policy enforcement mechanisms for integrated enterprise environments. Looking from a business process oriented point-of-view related access control paradigms, such as separation of duty, obligation of duty, cardinality, delegation, and revocation policies can be defined. Business processes are task-driven, which are realized by software applications implemented in legacy systems. Therefore, business process policies have to be translated and enforced in a consistent way from the layer of business processes to the applications and underlying legacy systems to guarantee enterprise wide access control without relying exclusive on access control enforced by the business process component. Therefore, existing enforcement technologies and policy specifications common in enterprise landscapes have to be able to apply to business process access control policies. These are characterized by dynamic and flexible assignments or changes to roles, groups, or single subjects (i.e., humans performing a manual task) during the process execution. Many existing policy enforcement mechanisms and architectures are not able to adapt to these rapid changes in access rights, determined by the business process.

The work packages assigned to the focus activity of policy enforcement address the development of a business process-driven architecture for access control policy enforcement in distributed environments as the centerpiece of ORKA. The analysis of existing access control mechanisms, such as used in operating systems, database systems, domain services, and custom applications written in Java and .NET is the scaffolding to identify which access control requirements for business processes can be realized with ease using existing access control mechanisms and which cannot or only with workarounds. Therefore, the inadequacies of existing enforcement mechanisms, with respect to dynamic changes due to process execution, have to be identified by an analysis of existing technologies.

Based on the analysis of existing technologies a new architecture for policy enforcement in distributed and heterogeneous environments is developed and implemented. ORKA’s enforcement architecture supports workflow management systems to provide access control on the different levels, starting from the business process level down to access control for the application logic and legacy systems. The system is capable to perform dynamic access control changes, such as needed to support delegation, separation of duty, or cardinality constraints, while process execution advances. The architecture is designed to support unobtrusive, orthogonal, and integrated policy enforcement based on an own policy specification language.

A policy administration system will be developed supporting the analysis of existing policies deployed in legacy systems and our access control architecture. This tool allows a deep analysis of defined access control policies. The results can be used to detect contravention of existing business or corporate access control policies and allows an easy alignment between corporate access control policies and their enforcement in the enterprise’s technical infrastructure.

VALID – Validation and verification

Valid Logo Due to the fact that more and more security-critical business processes are mapped to IT systems role-based access management becomes increasingly complex. This may lead to errors in the definition phase of RBAC policies and consequently to security holes. For example, inconsistent RBAC policies can arise when role hierarchies interfere with certain authorization constraints. To take an example, assume that in a banking environment the role "Cashier" inherits all the permissions of the role "Cashier Supervisor". On the other hand, there may be defined a separation of duty rule stating that no user may assume both the "Cashier" and the "Cashier Supervisor" role. Obviously, there is a contradiction between the separation of duty rule and the role hierarchy. The higher the complexity of the RBAC policy is, the more difficult it can be overlooked by a security officer/administrator. Therefore, unexpected and undesirable consequences of an RBAC policy may be incurred. Policy analysis in general helps to avoid such mistakes.

So, methods for a systematic and tool-supported analysis of RBAC policies are required. Specifically, correctness, consistency, and completeness (w.r.t requirements) properties of RBAC policies should be verified. This analysis should be carried out during the design process of the RBAC policy in question, i.e., before the deployment of the policy. Conceptual faults which become evident after the implementation of the RBAC policy are often hard to correct and can be expensive. Even if the implementation is sound, we cannot expect a correct system if the RBAC policy is incomplete and incorrect.

Hence, various validation tools which are based upon formal or semi-formal methods are examined within the VALID subproject of ORKA. Specifically, it will be investigated which of those tools are well-suited to the task of policy analysis. Among others, we take the following validation tools into consideration:

Theorem provers for the deduction-based formal validation,
Model checkers,
Constraint analyzers,
UML/OCL tools, and
Graph transformation engines.

It is envisioned to make available a tool-box for the analysis of RBAC policies. Depending on the concrete problem to be tackled, the appropriate validation tool can be selected by a security officer/administrator. Due to the fact that some of the aforementioned tools are hard to use in practice an appropriate graphical user interface should be provided.

ADMIN – Management of policies

Admin Logo The ADMIN subject area focuses on specification and administration of security policies in practice. Besides enforcement and verification of security policies, usability of policy management is of particular importance. Therefore, ORKA develops convenient user interfaces that allow administrators to get all relevant policy information anytime. Additionally, the user interface gives administrators access to all necessary operations with respect to the actual context. During policy changes redundancies and other sources of inconsistencies (e.g. superfluous permissions) are detected and eliminated.

Even if today models for role-based administration support administrators manifold, our impression is that administrators are often not aware of the implications of their current administrative operation to the full extent. They of course know the direct consequences of their acting; however, additional implied changes at other places of the policy may occur that an administrator might not notice nor even expect to happen. This is so much the worse, since in role-based access control a single change at one place of the security policy may entail a bunch of additional and possibly unwanted changes at other places. As a result, the policy may include redundancies, inconsistencies, and errors. ORKA will provide means for handling unexpected effects in role-based administration.