Security Policy Specification

Introduction

Information systems are incredibly growing nowadays becoming more and more complex to be administrated. Managing huge systems is a very complex problem and this issue has been focused in several research works during the last years proposing alternatives to tackle different aspects of system management. An approach is the management of systems based on policies. It enables the specification of high level business policies which are refined into low-level policies suitable to be directly applied into final devices to achieve the high-level behavior previous specified.

Security is a key aspect to be controlled in information systems and policy-based systems can help to control it. To this end, security policies can be described by administrators using a language designed for this purpose which enables the description of high level security policies. Researchers have proposed multiple approaches for policy specification that range from formal policy languages that a computer can directly process and interpret, to rule-based policy notation using an if-then-else format. The definition and the usage of high level policy languages ease the process of policy specification reducing significantly errors therein. In fact, high-level policies require less effort to be written and maintained since a lot of details are hidden to writers. Note that this kind of policies does not need training or deep knowledge to be used even by (maybe not so skilled) administrators. This is especially suitable in security field in which any specification error potentially may cause a security hole in the information system.

In the policy definition process, the task of a policy manager is to transform the business policies into implementable policies using a formal language for this purpose. To do so, the manager uses a high level policy language that assures that the representation of security policies will be unambiguous and verifiable. Moreover, other important requirements of any policy language are:

• •

  Clear and well defined semantics: The semantics of a policy language can be considered as well defined if the meaning of a policy written in this language is unambiguous at any time of its life-cycle.

• •

  Flexibility and extensibility: A policy language has to be flexible enough to allow new policy information to be expressed, and extensible enough to allow new semantics to be added in future versions of this language.

• •

  Independent of the administrative domain: where it will be used and, in particular, of manufacturers/providers of devices and services. A policy language is independent if a policy written in this language is independent of a specific deployment.

• •

  Readability: A policy language must be easy to understand when read by the administrator.

• •

  Amenable to combining: A policy language should include a way of grouping policies.

In addition, a policy language should facilitate the realization of functions related to policy framework. In this sense, other requirements are:

• •

  Access to policy information: A policy representation oriented to facilitate queries about policy information.

• •

  Conflict detection: A policy language which facilitates the process of conflict detection, either enabling a direct integration in conflict analysis tools, or having syntactic and semantics elements to facilitate the conflict analysis.

• •

  Policy distribution: The policy representation may support of multiple bindings that is to be possible to convey policy instances in a number of different protocols.

• •

  Policy refinement: A policy language may provide facilities or techniques to help in the policy translation process and to achieve policy and rules consistent at every level of abstraction.