An innovative approach to the technical management harnessing modeling to support the
process has been presented by Lück et al. in [IKP+05], [IPK+06], [L¨06]. The approach
includes the concept as well as the corresponding tool for automated refinement of policies in multilevel hierarchies. The tool supports the user by the interactive graphical modeling which allows easy and intuitive handling.
Figure 6.2 shows the model structure which is the basis of the approach. The model represents the managed system as well as the associated control and policy elements. The modeling process includes creating the graph model and subsequent parametrization of nodes and edges of the graph. The backend functions allow automated refinement of policies from top to bottom through the hierarchy.
The horizontal allocation of the model in abstraction levels provides a framework for a three level hierarchy. Each policy element refers to a certain element of the managed system. These relationships are represented by edges between policy and managed system’s
1From the DMTF’s site: https://www.dmtf.org/standards/cim 2
6.2. Model-Based Management 59
Figure 6.2: Basic Model Structure. Adapted from [L¨06]
elements. Only intra-layer policy-managed element associations are allowed. The layers of the model have the following primary focus:
"Roles & Objects" (RO) The top layer of the model is devoted to the organizational
aspects of the model. The basic elements are the roles and abstract objects. The layer can also include further elements of the similar abstraction grade. However, this is up to the actual use case and field of application. In general, the control elements are not relevant for the specification on this abstraction layer.
"Subjects & Resources" (SR) The middle layer of the model is devoted to the
active elements of the model. These are subjects, the elements that take actions on behalf of certain users and in doing so use the resources of the system. The level of abstraction on this layer is dictated by the service-oriented aspect of the model. Thus, the services are also modeled by means of the corresponding elements on this layer.
"Processes & Hosts" (PH) The bottom layer of the model is devoted to the
technical aspects of the model. The basic elements are the processes, hosts as well as user
credentials, system resources, communication protocols and network structure. Since the
abstraction level of the layer is very technical, it is easy to derive the concrete configurations for the control elements of the actual system from the policy elements.
The proposed approach has been applied and validated in the field of security management, in particular configuration of security services. Thus, the focus of identified abstraction levels as well as the attribution of elements to the corresponding layers lies on the aspects specific to this application field. Each policy is presented in each layer by means of a certain policy element. Each policy element controls access to certain resources.
The access control is up to the following extended logic: not allowed access has to be prohibited and allowed access must in fact be provided by the system. These authorization policies are comparable with the positive authorization policies in Ponder presented in Section 5.5.2. The explicit access interdiction is not required, since according to the specified logic the access is implicitly denied until it’s explicitly allowed. Further, it is possible to define dynamic constraints for allowed access.
The process of model-based management includes multiple steps. Firstly, the modeling step is done: the managed system is modeled on the abstraction levels mentioned above. Each layer represents the system with the different level of abstraction. Thus, each abstract
model element of the higher-level has a corresponding concrete element on the lower-level. These associations are modeled also. Subsequently, the required policy is modeled by means of the policy elements on the top-level. The modeling process is performed bottom-up:
1. The components ans structures of the real system are modeled on the PH layer. The developed model presents the technical view of the managed system.
2. The services which are realized by the processes of the PH layer are modeled on the SR layer and associated with the corresponding elements of the bottom layer. The model presents the service-oriented view of the system.
3. The attendant roles and object are modeled on the RO layer and connected to the corresponding subject types and users of the SR layer. The model presents the organizational view of the system.
Secondly, the policy refinement step is performed in an automated way. Before each sub-step, the consistency check is done, in order to ensure that the model has no conflicts and the specified policy is feasible with regard to the modeled system.
On the basis of the system model and the identified abstract requirements, the policy refinement is performed in the top-down matter.
1. The authorization policies are presented in the RO layer as access permissions and associated with the corresponding roles, objects and access mode. Several arts of dynamic constraints can be defined: role cardinality constraint, exclusive role authorization, and exclusive role activation.
2. The access permissions on the SR layer are presented as service permissions. The corresponding model element allows a subject of a user by means of a service to access a certain resource. Access permissions and exclusive role activation elements of the RO layer are refined to the service permissions and exclusive subject activation elements on the SR layer.
3. The PH layer includes protocol permissions which allow a process, that can show a user credential, to communicate with another process by means of a protocol in order to access a certain system resource. A concurrent usage of certain user credentials can be prohibited by an exclusive user credential activation constraint. The service permissions and exclusive subject activation elements on the SR are refined to the protocol permission and exclusive user credential activation element of the PH layer having regard to the dependencies between the services. In order to ensure the service communication, the corresponding processes should be able to communicate with each other. Thus, the service associations of the SR layer are refined to the protocol permission elements of the PH layer.
4. For each security service the relevant protocol permission elements are estimated. For each protocol permission element of the PH layer all the communication paths are calculated. The paths which do not meet the security requirements are not considered further.
The derivation of the single configurations from the policy elements of the PH layer as well as the distribution of them to the corresponding control elements are not the subject of the policy refinement process. This is in general a syntactic adaption of generic rules on the PH layer to the specific interfaces of the control elements. At bottom of the step, the code generation and the distribution are performed.