«Abstract. Security policies are rules aimed at protecting the resources of an organisation from the risks associated with computer usage. Designing, ...»
When asked a specific query about what a specific user can do, Otter also replied quickly. Our experiments confirm the theoretical results of . Otter has been made to run in automatic mode, applying binary resolution, unary resolution or URResolution, hyper-resolution, and binary paramodulation. Otter works searching for the empty clause, which, in the case of a verification task of type 3, is an evidence of contradiction amongst the security policies.
5 Using E-Policy Manager
The basic environment, E0, which is a conjunction of ground formulae, is usually built using a simple, three-view approach. In the first view, the organisation is characterised as a collection of employees. Each employee is described in terms of the standard attributes, e.g. name, surname, etc. In the second view, the organisation is characterised in terms of a structure, which usually consists of several departments and their relations. Relations, e.g. staff(X), post(Y), dpt(Z), post(X, Y, Z), etc., are used to baptised departments, employees, etc. At this point, each employee is affiliated with some department and given a role. In the third view, the organisation is described in terms of its resources, information in our case. Files, directories and all kinds of information resources are then incorporated into the environment.
Using the unique names assumption, we may express and prove simple properties of the basic environment. Proven properties include “every employee is affiliated to one and only one department”, “every employee has one and only one password”, etc.
5.1 Linking E-Policy Manager with a Database Management System
Mostly, the basic environment is captured through a database management system.
E-policy manager can be linked, so far, to read information from Access or SQL server. To fulfil the intended interpretation, the basic environment is assumed to come
from the following tables:
• Subjectidentifier, name, department of affiliation, position
• Objectidentifier, name, department this object belongs to, class
• Actionidentifier, action description, object this action is applied to
• Security_mechanismidentifier, access mechanism The second part of the environment, which is a conjunct of universally quantified formulae, together with the security policies, is captured via a GUI, which we described below. Notice, though, that security policies can be also by means of a collection of control access lists.
5.2 A Graphical User Interface
Writing, developing and maintaining security policies are all responsibilities of a security officer, who can not be assumed to be acquainted with formal methods.
Formal methods require both significant skill and time (and therefore money) to use.
To get around this problem, e-policy manager comes with a graphical user interface (GUI) that makes it easy to capture security policies by means of wizards and other graphical techniques. Also the GUI makes it easy both to correctly interpret the input security policies and to formalize them in FOL.
Through the GUI, a security officer can capture a set of security policies at a high,
level, by means of schemata. Although schemata restrict the expressiveness of our policy language, the output security policies contain the necessary ingredients for guaranteeing a simple but correct translation into our first-order language. Moreover, the GUI hides formal methods and knowledge representation out of the user, who no longer needs to be acquainted with these techniques.
To provide flexibility to the user, we maintain a database of action names synonymous. So a user may write (or select) “change”, “manipulate”, “alter”, etc. rather than the default “access”. To avoid slowing down the deduction process, we normalize all the synonymous of an action to a designated, default action name. This way, we do not perform additional, unnecessary applications of paramodulation or rewriting.
Using the capturing schema, each security policy is translated into both a first order formula and a semi-natural language expression. The formula is regarded as the formal model of the associated security policy. The expression is used for documentation purposes. It is part of the security policies manual of the associated organization.
Given that a policy specifies the conditions under which a subject is allowed (respectively forbidden) to perform an action on some object, the GUI portrays a schemata, based on wizards, through which the user conveys several pieces of information. This involves the subject, e.g. users, processes, etc., the action, e.g. reading, writing, creating, etc., the object, an information file, the restrictions under which the action is permitted, e.g. a user role, a user affiliation, etc., and whether the action should be denied or permitted. The subject of a security policy can be a specific individual or a group of individuals that are related by some condition.
The GUI also allows the introduction of a modifier, we call the purpose modifier.
If the purpose modifier is on, the interpretation of the security policy at hand is changed so that it now reads “only subject is allowed (respectively forbidden) to perform the associated action on the object under the given conditions”.
Using the GUI, a user is thus able to capture a security policy through a suitable schema. Schematically, the wizard enables the user to convey six pieces of information: i) the subject of the policy, ii) number of purposes (use only to denote exclusiveness, otherwise this field is left apart), iii) the type of policy (permitting or denying), iv) the action to be carried out, v) the object the action should be performed on, and vi) the constraints.
As an example policy capturing, consider that, after interacting with the wizard, the user has input the following information: subject =staff, condition on the subject = officer, department = sec, purpose modifier = on, policy type = permitting, action = read, object = passwords (the password file), and object constraints = none, then the policy manager records the following formulae
within the policy database:
∀X:staff. (post(X,officer, sec) → permitted(X, read(passwords))) ∀X:staff. (¬post(X,officer, sec) → ¬permitted(X, read(passwords))) As another example of security policy capturing, consider that, after interacting with the wizard, a security officer has input the following information: subject = staff, subject constraints = affiliated2(subject, it), purpose modifier = off,
policy type = permitting, object = information, object constraint = belongs2(object, it), action = read. Then, e-policy manager outputs:
∀X:staff, Y:dpt, F:info. (post(X, Y, it) ∧ blngs2(Y, it) → permitted(X, read(Y))) Each policy can be added or removed from the database by means of a wizard, which pops up a table containing all existing policies. A user only has to select an unwanted policy, by clicking on it, and then indicate policy removal or edition.
The design of both the interface and the security policy schemata of e-policy manager were largely inspired in LaSCO . LaSCO is an object oriented programming language which expresses a security policy by means of a constraint imposed on an object. Other policy languages were also considered, e.g. , but none of them provides as much a solid theoretical foundation as that of . We have more to say about related work in section 5.
6 Testing Psychological Validity
E-policy manager was used to capture a number of security policies found in books or gathered from practitioners. Although they impose severe constraints on the policy language, schemata were found to be enough to capture all these security policies. Our experiments show that the verification process may take a few milliseconds.
E-policy manager was also evaluated for psychological validity. We run a test on six security officers, who answered a survey and interacted with the tool prototype.
Our results from this experiment are encouraging. The answers provided by these security officers point that e-policy manager has achieved its two primary design goals, namely: i) to make it easy to capture a security policy while guaranteeing it is correct in the sense of interpretation, and ii) to provide a means for formally verifying the security policies are consistent. Rather than an adverse opinion, we got words urging us to include an account for policies about other resources.
E-policy manager is available upon request by sending e-mail to the first author. In the next section, we will review existing languages for the specification of security policies.
7 Related Work
A policy specification language aims at formalizing the intent of a policy designer into a form that can be read and interpreted by both people and machines . It is especially designed to specify the relations amongst system entities in terms of actions and the conditions upon which these actions are denied or performed. There exist several policy specification languages. In what follows, we review the main features of 4 policy specification tools and associated languages: i) Keynote, ii) SPSL , iii) LaSCO , and the General Computer Security Policy Model .
Keynote and SPSL  are used to specify security policies about network applications. Neither Keynote nor SPL provide a visual tool for policy capturing. However, they are both equipped with a policy compiler, which produces a user profile that the intended application can use for denying or permitting the execution of an action.
Keynote cannot be used to specify facts about the environment. Keynote does not scale properly, as it is difficult to foresee the state that results when enforcing a number of security policies. E-policy manager can be used to capture facts about the environment but was never thought as a mechanism for enforcing security policies.
LaSCO  is based on a model where a system consists of objects and events and works by conveying restrictions on objects. This language represents the policies by means of directed graphs which describe a specific state of the system (domain) and specific access constraints (requirements) and in mathematic logic. The nodes represent system objects and the edges represent system events. LaSCO  can be used to express a wide variety of standard and customised security policies, including access control and other history-based and context-dependent policies. Our work has been inspired in this language. For example, for the graphical user interface, we have adopted the use of graphs facilitating the security policies representation, as well as denoting information access control. LaSCO expressions can be translated into a lowlevel language for security policy enforcement. However, the tool does not involve the use of a mechanism to guarantee that the policies are consistent or that they meet certain properties.
Krsul, Spafford and Tuglualar  have presented a functional approach to the specification of security policies that allows policy stepwise refinement. The model makes the explicit assumption that policies and the value of the system objects are related. This model expresses policies as algorithmic and mathematical expressions.
The specification policy explicitly lists the objects and attributes that are needed to enforce the policy. The model helps identifying the components that are relevant to the policy and hence provides a better policy understanding.
These languages are all adequate for the specification of security policies. However, they are not this effective, since, except for , they do not have a formal semantics, with which to reason about the security policies. Also security policy capturing using no visual aid has proven to be error prone, making it necessary to verify the written policies.
Halpern and Weissman have shown that (a subset of) first order logic is enough to express and efficiently reason about security policies . They represent a security policy as a relation between three sorts, Actions (e.g. accessing a file), Subjects (the agents that perform actions) and Times. This contrasts with our work, where we denote a policy as a relation amongst Subjects, Objects and Actions. Halpern and Weissman are much more interested in using a user profile in order to enforce security policies; they argue that their security policy schema (which we have borrowed for our work) makes it easier for a user to write proper policies. They have not paid attention to checking policy consistency. As we can see, our work is also based on Halpern and Weissman’s. Indeed, in  it is mentioned these two researchers are working on developing a nice interface for security policy capturing, but no report has been published yet.
E-policy manager, as presented here, is a second-generation of that presented in . In particular, the newer e-policy manager has much better reasoning capabilities and, a nicer interface and more linking capabilities to interact with other systems.
8 Conclusions and Future Work To secure the most significant resources of an organization, it is necessary to have a set of appropriate policies. Managing security policies is not an easy task and currently it does not have computer support. The goal of our work is to provide a tool that supports this task and gives the bases for future research. The tool, called epolicy manager, includes a graphical user interface that makes it easy to capture security policies and a module that formalizes these policies to be verified by a first-order theorem prover, Otter, and a first-order model finder, Mace.
Further work includes using a natural language processor so as to allow a user to input security policies as he would in an informal document. This interface would significantly increment the acceptance of E-Policy manager from potential users.
Further work also considers expressing and reasoning about policies regarding resources other than information.
References  Joseph Y. Halpern and Vicky Weissman. Using first-order logic to reason about policies. In 16th IEEE Computer Security Foundations Workshop, Pacific Grove,
2003. IEEE Computer Society.
 William McCune. Otter 2.0 In Mark E. Stickel, editor, 10th Conference on Automated Deduction, volume 449 of Lecture Notes in Computer Science, pages 663-664.