Most current work on security policy concentrates only on authorisation policy which is essentially passive in that it is checked only when an operation is invoked to determine whether the operation should be permitted or forbidden. The active aspects of security policy, which define actions to be performed when events such as security violations are detected, are often specified as procedures to be followed by administrators or are coded into security components. A clear "formal" specification of security policy is needed that covers obligation policy (who is responsible for performing actions related to management and enforcement of security) as well as authorisation policy (what operations a subject is permitted to perform on a resource). There is also a need to specify policies about permitted information flow and required information transformation c.f. military style mandatory access control based on labels. Grouping the subjects or target objects into domains, so a policy applies to all members of the domain, and grouping policies into roles helps to cater for large scale systems.
The overall objective of this project is to provide a framework for managing security in large, multi-organisational distributed systems. This will include techniques and tools for specification of security policy by refining high level goals into implementable policies; analysis of policies for inconsistencies and conflicts; and example mappings onto modern security implementation mechanisms. It will build upon the Role based management framework developed during the EPSRC funded Roleman project and related work at Imperial College. This framework includes a notation and editor for defining obligation and authorisation policies plus some policy conflict analysis tools.
Obligation policies specify what actions subjects must or must not perform on target objects and Authorisation policies specify what actions subjects are authorised or forbidden to invoke on target objects. The mode of the policy distinguishes between positive authorisation (permitted: A+), negative authorisation (forbidden: A-), positive obligation (must: O+) and negative obligation (must not: O-). The general format of the policies is given below with optional arguments within brackets:
identifier mode [trigger] subject ‘{’ action ‘}’ target [constraint] [exception] [parent] [child] [xref] ‘;’The subject represents the set of managers assigned to carry out the actions on the set of target objects. Both sets are specified using domain scope expressions.in terms of domains of objects. This allows specification of policies for large numbers of objects and permits changes to domain membership, without modifying the policies applying to the domains. Positive obligation policies can be triggered by time or by composite events detected within the monitoring system . Constraints limit the applicability of the policy e.g. between the hours of 09.00 and 17.00. The policy format and use is further described in (Marriott 1996a). Examples of policies are:
O+ on rlogin_event AC_agent {enable_encryption()} */applications/transfer_protocolsComments can be used for the fields of a high-level abstract policy. A refinement hierarchy can therefore be built from the more abstract policies, which can only be interpreted by humans, to the enactable leaf level policies or rules which can be interpreted by automated components. The editor maintain references forward (child), backward (parent) and to related (xref) policies. A prototype policy editor and policy storage and dissemination service have been implemented (Marriott 1996 a&b). However there is no real methodology or tools support for refining high-level goals into a set of consistent implementable policies. We have experience in requirements engineering methodology and tool support which should be adaptable for this.
This positive obligation policy is triggered by a remote login event and results in the access control (AC) agent enabling encryption on all transfer protocol objects.A+ *domain_administrators {"user_profile": modify(); remove(); reset()} *dse_domain
when (time< 08:00) && (time > 20:00)
Domain administrators are permitted to modify, remove or reset objects of type user profile in the dse domain outside office hours.
The main advantage of this notation is that it integrates the specification of both obligation and authorisation policies with explicit specification of responsibility for performing actions – the active obligation policies. The explicit subject and target specification in authorisation policy permits analysis of who can access a resource as well as what resources a user can access, although no support for this has been implemented in the current system. Policies and domains are currently implemented as objects in a CORBA compliant environment and can be distributed across the system.
High level policies can be specified by giving an abstract description of the various fields of a policy. The policy can be subsequently refined by specifying more concrete policies which implement the abstract description. Some policies will eventually be fully specified and relate to operations which can be performed by automated components, while some other policies will specify abstract activities which need to be performed by a human manager. The refinement of a policy from a high level security goal to the enactable leaf level policies which can be interpreted by automated components forms a hierarchy which can be navigated for policy analysis. A prototype policy editor and policy storage and dissemination service have been implemented (Marriott 1996 a&b). For each policy the editor maintains references forward (child), backward (parent) and to related (xref) policies. However there is no real methodology or tool support for refining high-level goals into a set of consistent implementable policies. We have experience in requirements engineering methodology and tool support which should be adaptable for this.
The policy notation does not cater for military security policy based on the Bell-LaPadula model with security levels where subjects and targets each have labels (e.g. unclassified, confidential, secret, top-secret) relating to an information category (nuclear submarines, fighter planes). This type of security is now also being used in Compartmented Mode Workstations (CMW) within the financial sector to establish "Chinese walls" to prevent the flow of information between particular categories of employees (Allen, 1996). Another problem is that the notation does not permit the specification of some application level security policies related to filtering of information where the data values returned by a transaction depends on subject identity, subject location or values of internal data fields of the target object being accessed. There is also a need to cater for (legal) policies about disclosure, e.g. group X customer data must not leave the UK jurisdiction.
We also have meta-policies to define application specific constraints to prevent conflicts in the permitted policies. An example constraint relates to separation of duties in many organisations – the same person must not approve payments and sign cheques. Other cases such as self-management and conflicts for resources also fall into this category of application specific conflicts. Meta-policies are currently specified using Prolog, but it is desirable to have a single notation for constraints about a set of policies (meta-policies), constraints on the activities of a policy (specified within a policy) and constraints which apply to roles e.g. a person may not activate role A and role B at the same time.
There is no support for semantic analysis of obligation policies to detect invalid event specification which will never trigger a policy or invalid constraints which may result in null subjects or targets for a policy.
Roles permit users to be assigned or removed from a position without respecifying policies and they provide a scope for checking policies for conflicts and consistency. Basic tools for the editing of roles have been implemented and an object oriented extension permits instanciationinstantiation of role instances from role classes. Further work is needed in order to analyse the use of roles in conjunction with the policy refinement process. Many questions remain unanswered e.g. if a role contains a high-level policy do the refinements of this policy necessarily belong to the same role ?
The relationship between authorisation policies and multi level security mechanisms such as CMW also needs further study and may result in modifications to the policy notation. While it is possible to formalise multilevel security using policies and domains, the implementation of policies in CMW encounters problems due to the transitivity aspect of labelling. If a policy grants A read access on B and another policy grants B read access on C then in the current policy semantics A does not have read access on C whereas security labelling assumes this transitivity.
Initial proposals for notations will be applied to various scenarios to test its applicability. We hope to use security scenarios from banking applications plus telecommunication management from a related project.
Deliverables:
Month 6: Initial Policy Notation Proposals
Month 12: Policy Notation specification
Month 36: Final revised policy notation
Of particular relevance, requirements engineering has produced a body of research tools and techniques for goal specification and decomposition (Dardenne 1993, Anton 1996), which could also be used in the context of security policy specifications (where high level policies are similar to goals). For example, the KAOS method and associated GRAIL environment (van Lamsweerde 1997), facilitate the progressive identification and refinement of goals until constraints can be assigned to individual agents. Conceptual taxonomies, well-formedness rules and elaboration tactics guide the goal elaboration process.
The processes of policy decomposition, refinement and analysis (WP3) generate policy descriptions that have complex relationships and that may be at different levels of abstraction. In software engineering, this has also resulted in tools and techniques for requirements traceability - tracking the life of a requirement backwards from its source and forwards to its realised implementation. This goes beyond simply expressing the relationships between artefacts in the development process (Nuseibeh 1994), it also deals with "contribution structures" (Gotel 1995) that model the dynamic structure of individuals and groups in the development process and their relationships to the development artefacts. Such work may be useable in the context of changing security policies. Certainly, an understanding and modelling of the organisational setting from which (policy) requirements are derived is essential (Yu 1995).
Finally, there is a need to caterWe have done some initial work on an object oriented approach to specifying roles (Lupu 1997c) which caters for role classes (e.g. nurse class) from which specific instances of nurses for particular wards can be created. These role classes have policies with the same actions but different manager position domains and different target domains. It is also useful to derive a new role class from an existing one e.g. for a theatre nurse We have done some initial work on an objectgroup policy templates which are policy specifications independent of the subject and/or target domain. A policy template is therefore a constrained form of oriented approach to role classes and policy templates (Lupu 1997e). It is however necessary to investigate thean abstract policy which is refined by specifying the subject and target domains in each of the role instances. The relationship between role sub-classing (implementing specialisation) and the refinement of policies needs further investigation.
Deliverables:
Month 12: Report on evaluation of refinement approaches and specification of our approach
Month 24: Prototype Refinement tools
Month 36: Final Refinement tools.
Current tools for analysis of modality conflicts establish precedence between policies on the basis of the their scope of application i.e. a policy which applies to a subset of users will take precedence over a more general one. The use of a precedence relationship is useful because it is not always desirable to eliminate conflicts by changing policies or modifying domain membership. However since this precedence depends on the nesting of domains and since domain membership evolves dynamically within the system there is a need for establishing policy precedence at the moment of invocation. Since flattening the domain structure and checking for set/subset inclusion is a very costly operation the run-time precedence evaluation has to perform symbolic membership calculations on the domain structure.
Current meta-policy specification is done in Prolog and requires the translation of policies into a Prolog understandable form. A higher level notation for meta-policies and for constraints in general must be developed. The problems relating to the scoping of applicability of these constraints which may apply to the attributes of a policy, to a set of policies or to a set of roles must also be taken into account. In particular an analysis tool examining a policy must be able to determine all the meta-policies to which the policy must conform. This could be achieved by introducing the concept of a jurisdiction i.e. a domain and a set of constraints (meta-policies) which apply to policy and role objects in that domain. A policy which is specified within a jurisdiction has to conform to the constraints of that jurisdiction. Further, compatibility between the policies of two jurisdictions could be determined by analysing conformance of the policies in one jurisdictions to the constraints of the other.
The software engineering community has also studied inconsistency in software development products and processes. A growing body of work has begun to move the focus of research from inconsistency detection and resolution, towards approaches that manage inconsistency (Nuseibeh 1996), by analysing it (Hunter 1997, Easterbrook 1996) and handling it in various ways (Balzer 1991, Schwanke 1988; Cugola 1995). Thus approaches that treat inconsistency as a logical contradiction (Hunter 1997) may be used to analyse static conflicts between security policy specifications, while others that treat inconsistency as any deviation from normative behaviour (Cugola 95) may be used to handle conflicts of implemented policies.
We will investigate the work done by (Koch 1996) who uses a policy notation based on ours and establishes a semantic graph model to detect ill-behaved policy sets with unsatisfiable pre-conditions. This can also be used to perform "what if" analysis to determine what chain of policies will be triggered by an event under particular constraints.
Deliverables:
Month 12: Applicability of software engineering techniques
for inconsistency management.
Month 18: Specification of Analysis Tools
Month 30: Prototype Analysis Tools
Although currently only offering C2 level security, Windows NT is a particularly appealing target environment to investigate. It's security model includes components to control who accesses which objects (such as files and shared printers), which action an individual user can take on an object (such as write access to a file), and which events are audited. The model also employs a rich variety of security mechanisms that can be controlled by external policy agents via API calls e.g. account policies, audit policies, trust relationship policies, user rights policies, inheritable non container objects, security descriptors and access control lists.
Secure CORBA ORB's can provide authentication, access control, auditing and message protection. The CORBA philosophy is to protect objects that are not security-aware in such a way that security policy enforcement can be performed automatically by the ORB. Two "interceptors" the access control function and the secure invocation, are the means which the ORB can invoke security mechanisms (e.g. our policy agent) on behalf of CORBA objects.
Another possible target environment for the security notation would be Firewalls, e.g. for generating and installing packet filtering tables and for enforcing policies within a Firewall architecture's application-level and circuit-level gateways. Howeverit we will not have the resources within the project to investigate this environment. We also do not have access to an implementation environment for mulit-levelmulti-level Military security such as CMW so we will only investigate specification of Military security policies.
Our current tools have been implemented in a CORBA environment in order to distribute the policy and role objects across multiple servers and multiple platforms. The executable policy agents will be implemented in this environment, allowing security administrators to control their operation remotely and change the set of policies they enforce at run-time.
We will define a number of scenarios from Banking and Telecommunications, based on requirements we hope to elicit from industrial contacts. These will be used as demonstrators for our policy specification and analysis toolset.
Deliverables:
Month 18: NT Target
Month 30: CORBA security services target.
Month 36: Example scenario showing integration of all
tools
Figure 2 Workplan Overview
Our concept of domain nesting precedence is based on that of Miró (Heydon, 1990), but they only deal with authorisation policy for file system security. Sandhu (1996)indicates the need for constraints for RBAC which are similar to our meta-policies, but the notation used is not described.
There is the Oasis project at Cambridge University (Hayton 96) which specifies access control policies in terms of axioms in proof system and processes apply these axioms to prove their eligibility to enter a set of roles. This does not include any form of obligation policy and there has not been much work on policy analysis. Most of the other security work at Cambridge and other places relates to specification and analysis of security rather than policies, although their work on trust relationships is relevant to or policy work.
There are various forms of Deontic Logic which have operators that denote obligation and permission, which at first sight seem very similar to our obligation and authorisation policy (Ong 93). In most of these, obligation implies permission or sometimes permission for an action means not being obliged to refrain from an action. In our approach obligation and authorisation policies can be specified independently, although obligation without authorisation can lead to conflicts.
We will make the toolset available to academic and industrial partners in other projects (Fujitsu, HP, BT and possibly SBC Warburg) to evaluate within their environments.
Allen, S. (1996). Introduction to CMW, Draft 0.6 SBC internal report no. DP-0004, 1996.
Antón A,Antón, A. (1996). Goal-Based Requirements Analysis, 2nd International Conference on Requirements Engineering (ICRE '96), Colorado Springs, Colorado, pp. 136-144, 15-18 April 1996, IEEE CS Press.
Balzer R.,Balzer, R. (1991). Tolerating Inconsistency; Proc. of 13th Int. Conf. on Software Engineering (ICSE-13), Austin, Texas, USA, 13-17th May 91, 158-165; IEEE CS Press.
Cugola G. Di Nitto E,Cugola, G., E. Di Nitto, C. Ghezzi and M. Mantione (1995);(1995). How To Deal With Deviations During Process Model Enactment; Proc. of 17th Int. Conf. on Software Engineering (ICSE-17), Seattle, USA, 23-30 April 95, 265-273; ACM Press.
Dardenne, A, A. van Lamsweerde and S Fickas,S. Fickas (1993). Goal-Directed Requirements Acquisition, Science of Computer Programming, vol 20, 3-50, 1993.
Distributed Systems Engineering Journal Special Issue on Management Vol3, No. 2, June 1996.
Easterbrook S.,Easterbrook, S., and B. Nuseibeh B;(1996). Using ViewPoints for Inconsistency Management, Software Engineering Journal, 11(1): 31-43, January 1996, IEE/BCS.
Gotel O,Gotel, O. and A. Finkelstein A,(1995). Contribution Structures, Proceedings of 2nd International Symposium on Requirements Engineering, (RE 95), York, UK, March 1995, 100-107, IEEE CS Press.
Hayton R., Moody K.Hayton, R. and K. Moody (1997). An Open Architecturer for Secure Interworking Services, IEEE 17th Int. Conf. on Distributed Computing Systems, Baltimore May 1997, pp. 315-321.
Heydon, A. et al. (1990). Miró: Visual Specification of Security. IEEE Transactions on Software Engineering, 16(10), 1185-1197.
Hunter A,Hunter. A. and B. Nuseibeh B,(1997), Analysing Inconsistent Specifications, Proc. of 3rd International Symposium on Requirements Engineering, 78-86, Annapolis, MD, USA, Jan. 1997.
Koch, T. et al. (1996). Policy Definition Language for Automated Management of Distributed System. IEEE 2nd. Int. Workshop on Systems Management, Toronto (Canada).
Lupu, E. C., D. Marriott, M. Sloman and N. Yialelis (1995). A Policy Based Role Framework for Access Control, First ACM/NIST Role Based Access Control Workshop, Gaithersburg, ACM Press, pp. II15-II24.
Lupu, E. and M. Sloman (1997a). Conflict Analysis for Management Policies. IFIP Integrated Network Management V, San Diego, Chapman & Hall, pp 430-443.
Lupu, E. and M. Sloman (1997e) A Policy Based Role Object Model, First IEEE International Enterprise Distributed Computing Workshop (EDOC’97), Gold coas, Australia, Oct. 1997.
Lupu, E. C. and M. Sloman (1997b). Towards a Role Based Framework for Distributed Systems Management, Plenum Press Journal of Network and Systems Management, 5(1), March 1997, pp 5-30.
Lupu, E. C., D. Marriott, M. Sloman and N. Yialelis (1995). A Policy Based Role Framework for Access Control, First ACM/NIST Role Based Access Control Workshop, Gaithersburg, ACM Press, pp. II15-II24.and M. Sloman (1997c). A Policy Based Role Object Model, First IEEE International Enterprise Distributed Computing Workshop (EDOC’97), Gold coast, Australia, Oct. 1997.
Mansouri-Samani M., M. Sloman (1997). GEM: A Generalised Event Monitoring Language for Distributed Systems, IEE/BCS/IOP Distributed Systems Engineering, 4(2), June 1997, pp. 96-108.
Marriott, D. andSloman M. (1996b) Implementation of a Management Agent for Interpreting Obligation Policy. IEEE/IFIP Distributed Systems Operations and Management (DSOM 96), L’Aquila (Italy).
Marriott, D. and Sloman, M. (1996a),M. Sloman (1996a). Management Policy Service for Distributed Systems, IEEE Third Int. Workshop on Services in Distributed and Networked Environments (SDNE’96), June 1996, Macau, pp. 2-9.
Marriott, D. and M. Sloman (1996b). Implementation of a Management Agent for Interpreting Obligation Policy. IEEE/IFIP Distributed Systems Operations and Management (DSOM 96), L’Aquila (Italy).
Mylopoulos J, L Chung, and B Nixon,Mylopoulos, J., L. Chung and B. Nixon (1992). Representing and Using Non-Functional Requirements: A process-Oriented Approach, IEEE Trans. on Software Engineering, vol 18, June 1992..
Nuseibeh B, To Be And Not To Be: On Managing Inconsistency in Software Development, Proc. of 8th Int. Workshop on Software Specification and Design (IWSSD-8), 164-169, Scloss Velen, Germany, 22-23 March 1996, IEEE CS Press.
Nuseibeh B,Nuseibeh, B., J. Kramer and A. Finkelstein (1994), A Framework for Expressing the Relationships Between Multiple Views in Requirements Specification, IEEE Trans. on Software Engineering, 20(10): 760-773, Oct. 1994.
Nuseibeh, B. (1996). To Be And Not To Be: On Managing Inconsistency in Software Development, Proc. of 8th Int. Workshop on Software Specification and Design (IWSSD-8), 164-169, Scloss Velen, Germany, 22-23 March 1996, IEEE CS Press.
Nuseibeh B, Robertson,Nuseibeh, B. and Robertson (1997). Making Requirements Measurable, Proc. IEEE 19th International Conference on Software Engineering (ICSE '97), Boston, USA, May 1997.
OMG CORBA Security Service Specification, Chapter 15, CORBA services: Common Object Services Specification, Nov. 1996.
Ong, K. L. and Lee, R. M. (1993). A Logic Model for Maintaining Consistency of Bureaucratic Policies. Proc. IEEE 26th Annual Hawaii International Conference on System Sciences, Hawaii, Vol. III, 503–512
Putter P, Bishop J, Roos J,Putter, P., J. Bishop and J. Roos (1995). Towards Policy Driven Systems Management, IFIP Integrated Management IV, eds. Sethi et al, Chapman Hall, 1995, pp. 69-80.
Sandhu, R. S. et al. (1996) Role-Based Access Control Models. IEEE Computer, 29(2), 38–47.
Schwanke R,R. and G. E. Kaiser (1988);(1988). Living With Inconsistency in Large Systems; Proc. of the Int. Workshop on Software Version and Configuration Control, Grassau, Germany, 27-29 January 1988, 98-118; B. G. Teubner, Stuttgart.
van Lamsweerde A., R Darimont and P. Massonet,Massonet (1995). Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt, IEEE 2nd International Symposium on Requirements Engineering, (RE 95), York, UK, March 1995, 194-203.
Yialelis, N. and M. SlomanM. (1996a), A Security Framework Supporting Domain-Based Access Control in Distributed Systems, IEEE ISOC Symposium on Network and Distributed Systems Security, San Diego, pp. 26-34, Feb. 1996.
Yialelis, N., E. Lupu and M. Sloman (1996b),(1996b). Role-Based Security for Distributed Object Systems, IEEE WET-ICE, Stanford, June 1996.
Yu E., P. Du Bois, E. Dubois, and J. Mylopoulos,Mylopoulos (1995). From Organizational Models to System Requirements: A 'Cooperative Agents' Approach, Proc. 3rd Int. Conf. on Cooperative Information Systems (CoopIS-95), Vienna, Austria, 194-202, May 1995.