Ponder: An Object-oriented Language for Specifying Security and Management Policies Nicodemos Damianou, Naranker Dulay, Emil Lupu, Morris Sloman Department of Computing, Imperial College, London, SW7 2BZ E-mail:
[email protected]
Introduction Large-scale enterprise information systems require flexible and adaptable approaches to management. It is necessary to dynamically modify the management strategy without shutting down the system. However, many current systems embed policy within the automated management components. Having a separate specification of policy which can be interpreted by manager agents, allows the policy to be easily modified to change the management strategy. There is a need for security management policy to not only focus on access control, which is the case with most current approaches, but also the policies related to auditing, logging of events or the actions to be performed when security violations occur. We define policy to be a rule specifying the choices in the behaviour of a system. The dynamics of network environments are changing rapidly. Service-oriented paradigms, internet-based networking and management of large, multi-enterprise information infrastructures, all have their impact on making the task of managing such systems a very challenging one. Policy specifications have to cater for scalability to millions of objects, complex interacting organisations and should be easily mapped onto the heterogeneous security and management mechanisms found in such systems. Policy specification should also be analysable for conflicts and inconsistencies. This paper describes Ponder, a new language for specifying policies for security and management of Distributed Systems [1], resulting from the experience gained in policy-based management at Imperial College over the past 10 years [3-6]. Ponder is a declarative, object-oriented language which supports an extensible set of basic policy types and provides composite policy constructs the complex organisational structures founding modern enterprise systems. By making the language object-oriented, we support reuse of specifications through instantiation, and extension of existing specifications through inheritance to scale to very large systems. In addition, policies can be specified for groups of objects as it is impractical to specify policies for individual objects in very large systems. A declarative language aids analysis. Ponder Overview The Ponder language includes constructs for specifying the following basic policy types: authorisation policies that define permitted actions are used to specify access control; eventtriggered obligation policies that define actions to be performed by manager agents; refrain policies that define actions that subjects must refrain from performing; and delegation policies that define what authorisations can be delegated and to whom. Filtered actions extend authorisations and allow the transformation of input or output parameters to be defined. Composite policy constructs provide the ability to structure large specifications. Groups define a scope for related policies to which a common set of constraints can apply. Roles define a group of policies relating to positions within an organisation i.e. that have a common subject e.g. operator, security manager, nurse or physician. Relationships define a group of policies pertaining to the interactions between a set of roles and to any resources shared by the roles. Management structures define the configuration of instances of roles and relationships in organisational units such as a project, department or a company branch. 1
Constraints specify limitations on the applicability of basic policies based on time of day, or state of the objects to which policies apply. Meta-policies are semantic constraints on permitted policies within a composite policy – for example there must not be policies which allow the same person to authorise purchase and sign cheques. We have adopted the OMG’s Object Constraint Language to specify both constraints and meta-policies. Apart from the fact that Ponder is the only policy language that covers such a wide range of management requirements, probably its most important characteristic is object-orientation. Ponder policy types correspond to Java classes and can be instantiated with parameters to tailor the instances to the particular environment. Extensibility is achieved by allowing new policy types that may be identified in the future, to be defined as sub-classes of existing abstract policy classes. The language provides scalability by allowing users to define composite policy types, instantiate them and extend them with inheritance by specialisation at an infinite depth. Any policy element can be passed as a parameter to policy types. This makes the language flexible since it allows for greater reuse of policy specifications; multiple instances can be created for many different conditions and under a variety of circumstances. Example Policies The following is an example of a positive authorisation policy type called profileAccessT, specifying that administrators (subjects of the policy) can modify and remove target objects of type “userProfile” stored within the users domain passed in as a parameter. Subjects and targets of policies are specified in terms of domains (c.f. directories) as a means of grouping the objects to which the policy applies. This policy type is parameterised with the subject and the target of the policy so can be reused in different environments. type auth+ profileAccessT(subject administrators, target users) { action modify(), remove(); } Multiple instances of the policy can be created for the different administrators of the dse_domain and students domain. inst auth+ dseProfileAccess = profileAccessT(dse_administrators, dse_domain) inst auth+ studentProfileAccess = profileAccessT(student_administrators, /users/students) Alternatively, the dseProfileAccess policy could be specified directly as an instance. Note the use of a constraint in this case to limit the applicability of the policy to between 09:00am and 06:00pm. inst auth+ dseProfileAccess { subject dse_administrators action modify(), remove(); target dse_domain/ when time.between(0900, 1800) } Any type can inherit from another. When a type extends another, it inherits all of its attributes and can add new attributes. We call this inheritance by specialisation. Inheritance can be applied on composite policies to build organisational policy hierarchies. In the following example, the role Mobile-Station-Service-Engineer (MSServiceEngineer) extends the role ServiceEngineer to add more policies. The example is an extract from the mobile telecommunications scenario described in [3]. A service engineer is responsible for 2
investigating faults reported in a cellular network. The role ServiceEngineer contains two obligation policies. The first one (service_complaint) is triggered by a customer_complaint event, and obliges the service engineer to perform a series of actions related to the equipment involved in the complaint. The gray_list_grace obligation policy is triggered every time a subscriber uses an equipment that is gray-listed. This event initiates a trace of the equipment and the subscriber who used it. The ServiceEngineer role is parameterised with the Visitor Location Register (VLR), a database of visitors detected in the local network, which is the target of both policies. Note that all policies in a role apply to the same subject so this does not have to be defined explicitly. The operator ‘->’ is used to indicate sequencing of actions in obligation policies. Other operators are provided to indicate actions which can be performed in parallel. type role ServiceEngineer(VLR vlr) { inst oblig service_complaint { on customer_complaint(equipmentId) do checkSubscriberRadioConfirmation(equipmentId) -> checkSubscriberSsInfoList(equipmentId) -> checkSubscriberHandoverNumber(equipmentId) -> investigate_complaint(); target vlr // visitor location register } oblig grey_list_grace { on gray_list_use(equipmentId, subscriberId) do traceForeignSubscriberInVLR(equipmentId, subscriberId) target vlr } } An MSServiceEngineer role extends the ServiceEngineer, and adds a new policy triggered on a Mobile Station failure to update the record of the reported failed equipment. This new role thus inherits the two obligation policies of its superclass, ServiceEngineer. type role MSServiceEngineer(VLR, vlr, EIR eir) extends ServiceEngineer(vlr, eir) { inst oblig maintain_MobileStation_problems { on MS_failure(equipmentId) do updateRecord(equipmentId) target eir // equipment identity register } } A large organisation may contain many policy definitions with very few differences between them. Different branches/departments or regions for example, may require very similar sets of policies. A set of parameterised policy types can then be specified for all branch or departments with similar requirements and then be instantiated multiple times to specify the particular policies and roles for each branch. A management structure in Ponder can be used to group related basic and composite policies to form organisational units in terms of the required roles. This provides for enhanced policy structuring and reusability at the organisational level.
3
The hierarchical object model for the policy language also provides a convenient means of translating policies to structured representation languages such as XML. The XML representation can then be used for viewing policy information with standard browsers or as a means of exchanging policies between different security managers or security domains. Implementation A policy specification toolkit is under development for defining, analysing and interpreting policies. The toolkit contains a management console, which provides the ability to manage policies stored in a distributed policy service. The management console includes: a policy editor, an analysis tool, a domain browser and a policy structuring tool. The main part of the toolkit is the policy compiler. The front-end of the compiler is complete and work continues on the back-end. The compiler front-end is generated using SableCC, an object-oriented tool that generates compilers in the Java programming language [2]. The SableCC parser is an LALR(1) parser and the tool generates a strictly-typed, abstract syntax tree and tree walker classes using an extended version of the visitor design pattern. This makes it easy to add custom code to build the back-end of the compiler. The back-end consists of two phases. The first phase generates an intermediate code in the form of a complex data structure to represent the basic and composite policies being parsed. The final phase will use that data structure to generate a suitable object code. Multiple generators can be written to generate different types of code: filters and access control lists for implementing security policy on various security aware platforms, e.g. operating systems such as Windows NT and Linux, distributed programming environments such as CORBA and JAVA, and technologies such as firewalls. A generic runtime object-model is being designed to enforce Ponder policies on any objectbased platform. Ponder types will be compiled into Java classes which can then be instantiated multiple times as java objects. References [1]
[2] [3] [4] [5] [6]
Damianou, N., N. Dulay, E. Lupu, and M. Sloman. Ponder: A Language for Specifying Security and Management Policies for Distributed Systems. The Language Specification - Version 2.1. Research Report DoC 2000/1, Imperial College of Science Technology and Medicine, Department of Computing, London, 3 April, 2000. Gagnon, E. SableCC, An Object-Oriented Compiler Framework. Master of Science, School of Computer Science, McGill University, Montreal. Lupu, E.C. A Role-Based Framework for Distributed Systems Management. Ph.D. Thesis, Department of Computing, Imperial College, London, U. K. Marriott, D.A. Policy Service for Distributed Systems. Ph.D. Thesis, Department of Computing, Imperial College, London, U. K. Sloman, M. and K. Twidle, Domains: A Framework for Structuring Management Policy. Chapter 16 in Network and Distributed Systems Management (Sloman, 1994ed), 1994a: p. 433-453. Sloman, M.S., Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, 1994b. 2(4): p. 333-360.
4
