Specification and Querying of Security Constraints in the EFSOC Framework Kees Leune
Mike Papazoglou
Tilburg University Infolab, Department of Information Systems and Management The Netherlands
Tilburg University Infolab, Department of Information Systems and Management The Netherlands
[email protected]
[email protected]
ABSTRACT Service-Oriented Computing is a new paradigm for the specification and deployment of distributed services in highly dynamic environments. The very nature of the context in which service oriented computing thrives imposes unique security requirements. Large scale interconnection of systems and services, rapidly changing service compositions and adhoc composition and invocation of services require a flexible security model that is able to adapt to these changes. In this paper, we present an approach to specification and querying of security (access control) constraints in the context of the event-driven framework for service-oriented computing. 1
1.
INTRODUCTION
Our research concentrates on associating authorization policies with events. Events are related to each other in a coherent and dynamic framework. This allows us to delegate the responsibility for specifying and maintaining authorization policies to the level of individual events, yet ensure the overall structure and overview on the framework level. This paper introduces EFSOC, an Event-driven Framework for Service-Oriented Computing. We will provide comprehensive overview of the framework and its main features and concentrate on its ability to specify and query security constraints. This ppaer is organized as follows. In section 2, we describe a case study in the field of Incident Response and Security that was performed at Tilburg University’s Computer Emergency Response Team (CERT), which is responsible for monitoring and managing roughly 5,000 systems spread over a large 1 This work has been partially funded by the Netherlands Organization for Scientific Research (NWO) as part of the PRONIR project.
Willem-Jan van den Heuvel Tilburg University Infolab, Department of Information Systems and Management The Netherlands
[email protected]
geographical area. The case study will be used to illustrate the concepts and constructs of the EFSOC framework, which is introduced in section 3. In section 4, we elaborate on the facilities that EFSOC offers for specification and querying security constraints, after which we introduce a prototype implementation and its architecture in section 5. Finally, in the last section, we present our conclusions and future work.
2. RUNNING EXAMPLE We will illustrate the concepts that we present in this paper by means of a running example. The running example is based on a case study that was performed at Tilburg University. The objective of the case study was to design an architecture for a computer system that supports the incident response and security team of the university. The very nature of incident response is a highly dynamic one: threats are difficult to predict and often develop quickly and without warning and there is no ’cook book’ approach for resolving them. The highly dynamic nature of incident response makes it very suitable for a service-based eventdriven approach. The Tilburg University Incident Response Team typically interacts with other CERT teams who operate world-wide, but also with end-users and internal support staff. To perform the work, the team has direct access to a large collection of information sources and has far-reaching authority to intervene in daily management of computer systems and networks. In this example, we focus on the following aspects of the work • Information gathering: the CERT team monitors information bulletins that are regularly issued by large vendors or by other security organizations and interprets them in the context of the local organization. In
Figure 2: EFSOC Event Life Cycle who will generate and/or monitor them. The security tier expands on the event tier to provide an access control mechanism which can be used to constrain the ability of subjects to send or receive events. Finally, the business process tier provides support for defining service-oriented business processes. Figure 1 shows a conceptual overview of the framework. In this paper, we will concentrate on the event tier and on the security tier.
3.1 The Event Tier
Figure 1: EFSOC Framework addition to reading bulletins, a number of sensors deployed around various areas of the network may trigger information to be sent to the control application. • Threat evaluation: Using information distilled from the information gathering process, the team member on duty needs to evaluate the current situation and associates a threat level. Depending on the current threat level, certain precautions may be taken. • Bulletin announcements: When there is a need, a number of key players in the organization needs to be notified. Bulletin announcements typically have a preventative nature and do not require instantaneous response. • Network management: In case of an abuse in progress, the CERT team has the authority to block networks, network segments, or individual users. In certain extreme cases, machines may be confiscated of physically isolated from the network. To support this diversity of tasks, an adequate architecture has been developed and is partially implemented. We will discuss the prototype in more detail later in this paper.
3.
THE EFSOC FRAMEWORK
The EFSOC framework can be roughly divided into three tiers, each of which addresses specific business requirements. The event tier provides the necessary constructs for defining events and event types and relates events to the subjects
In the service oriented computing paradigm, interoperability is achieved by using loosely coupled services. The EFSOC framework assumes that such interactions are not limited to point-to-point interactions. Instead, we assume that processes are shared by (large) groups of business partners. An event-driven approach is a very natural approach to modeling possibly unstructured and unrelated interactions. In line with the findings of [Luckham, 2002], we distinguish three aspects of an event. The first aspect is the form of an event. An event is typically associated with data structure which describes information about the context in which the event occurred. The second aspect is the significance of an event. An event signifies an activity in the real world. In EFSOC, this is represented by the fact that events are typed. The third aspect of an event is relativity, which represents the relationship in time or causality of one event to the other. In EFOSC, this is represented by the fact that an ordered list representing its predecessors is associated with each event. Events are modelled as consisting of an envelope and a body. The envelope contains meta-information which bay be used for routing the event and evaluating authentication rules. The relativity and the significance of an event are caught in the envelope by defining a number of headers which convey such information. The form of the event is modeled by the event body, which is a data structure which represents the context in which the event was generated. The top-left section of Figure 1 represents the event tier which provides the mechanisms for all event-related capabilities, such as defining and sending events, or the ability to subscribe or unsubscribe from events of a certain type. EFSOC distinguishes a limited number of basic operations
IntrusionDetection 20040514198 1084527169 snort_2 Portscan 192.168.1.2 10.0.3.1 Sasser.B
Figure 3: An XML representation of an Intrusion Detection Event which can be performed on events: they can be registered, subscribed to, generated and sent. Figure 2 shows the life cycle of an event. Before an event can be generated by a subject, the structure of the event body must be made known to the EFSOC framework. All events that are generated will have a known sender. However, generating an event is always implemented as a limited broadcast. In other words, events cannot be sent directly to one subject in particular. To receive events of a certain type, a subject must successfully subscribe to receiving that event. After a subject has successfully done so, the corresponding events will be sent to it when they are generated. In the next section, we described a number of constraints, e.g., authorization rules, which may prevent an event from being delivered to a subject. Referring to the running example, an intrusion detection event may be represented in XML as shown in Figure 3. The event was sent by subject snort 2 and represents a TCP port scan of a host with IP address 10.0.3.1, originating from host 192.168.1.2. The scan followed a typical pattern which suggests that the source IP has been infected with the Sasser.B worm.
3.2 The Security Tier Service oriented computing assumes that business processes are formed by invoking a variety of services from distributed heterogeneous sources. Interaction between business processes and services implies that business processes invoke services, which may be provided by providers anywhere in the world. Such service invocations take place in a highly dynamic and rapidly changing environment. To reduce the risks that are introduced by interacting with potentially unknown service providers, any approach that focusses on service integration in business processes must have strong security measures. The purpose of this is to ensure that all communication between service provider and consumer is adequately safeguarded against unauthorized disclosure or manipulation. In other words, confidentiality and integrity of message contents and message protocols must be ensured. In addition to these basic requirements, adequate authorization and authentication measures which enforce that each service provider can only interact with
Figure 4: Elements of the security tier business processes in exactly the way it needs to do to deliver its service, must be in place. The highly dynamic nature of a service-oriented environment imposes requirements on a security model which are typically not solvable by traditional access control systems, such as discretionary access control (DAC) [NCSC-TG-003, 1987], mandatory access control (MAC) [DoD 5200.28-STD, 1985] and role-based access control (RBAC) [Sandhu et al., 1996]. DAC and MAC suffer from a large management overhead and have a number of fundamental limitations. For example, implied in the definition of DAC is the fact that whoever is authorized to read a particular document may do with it as he sees fit, including delegating the right to read it to others, or use it for any purpose that he finds useful. MAC, in its traditional sense, provides poor facilities for implementing separation of concerns, does not address least privilege extensively and offers little support for message integrity. Combined, DAC and MAC address most of these issues. However, one of the issues that still remains unattended is the relatively large management overhead. The assumption that underlies the RBAC approach assumes that permissions are assigned to roles and roles are assigned to users. When the assumption that the assignment of permissions to roles is relatively stable, adopting RBAC will result in a significantly lower management overhead. However, when the concept of a role is relatively unstable, and the assignment of permissions to roles is not as static as desired, the added benefit of using role-based access control in its original form is limited. To address this problem, we propose a role-based approach where permissions are not static, like in RBAC, but rather are dynamically generated, using knowledge about the roles that subjects play and about other contextual factors. Using dynamic evaluation of authorization rules to deduce access control permissions allows for a better enforcement of least privilege, but also enables a near real-time active security implementation. The security tier, which is outlined in Figure 4 provides basic constructs which can be used to express authorization rules and policies. The security model of the EFSOC framework assumes that subjects are assigned to roles and that role assignments must be explicitly activated into role session before they may be used. Subjects are also generators or monitors of events. Associated with each event is an authoriza-
tion policy, which consists of one or more rules, which may be evaluated to determine if privileges are granted. Authorization rules are constructed by related privileges to roles and events. In other words, where classic RBAC models assume privilegerole-subject triples, the EFSOC framework assumes subjectevent-rule-privilege tuples. In the context of the running example, we can distinguish a number of roles. For example, we distinguish a DutyTeam role for the members of the incident response team, a role for members of the network operations team, which is labeled NOCRole, a HelpdeskRole for help desk employees, etc. Based on these roles, we can define authorization rules which get grouped into policies and become associated with events. For example, we can authorized DutyTeam members to generate BlockIPAddressRequest events, and we can allow NOCRole member to receive them. As a result, the EFSOC framework would disregard all BlockIPAddressRequests from Helpdesk members. One of the largest challenges of implementing security in a service-oriented environment is the fact that services may be discovered and invoked in an ad-hoc fashion. This results in the fact that it may not be possible to predict who service providers will be, and which authorizations they should have. To make this fact explicit, EFSOC distinguishes three states of authentication. Subjects may be unauthenticated, which implies that they are completely unknown. Unauthenticated subjects are typically restricted to accessing publicly available information. When a subject offers some form of credentials to the EFSOC framework which can be recognized and which are valid, the subject is considered to partially authenticated. Finally, when a partially authenticated users activates one or more roles, he is considered to be fully authorized. Depending on the level of authorization, subjects can be granted different permissions.
3.3 The Business Process Tier The business process tier, which is shown in Figure 5, provides the facilities to specify business processes and operational (web) services in terms of business rules and business interactions. As can be seen in the Figure, we distinguish three separate kinds of subjects: actors, business processes and operational services. Actors are typically employees, software agents, or other participants. Business processes are manifested in the form of a number of business rule and aim to realize business goals. Operational services are services provided by (external) service providers which are not provided by the EFSOC framework itself. Services which support the EFSOC framework are referred to as infrastructure services. Business rules are typically technology-independent descriptions of desired behavior. The subset of the business rules that applies to authorizations to send or receive events of certain types may be implemented in authorization rules. The remaining business rules are bound to heterogeneous implementations by explicit specifications.
Figure 5: Elements of the Business Process Tier
A business process consists of a group of one or more related business rules. EFSOC is restricted to representing the operational features which are directly relevant to interoperability. This includes features such as service invocations, business process initiations or service terminations. We assume that, within a context, business processes interact with other subjects exclusively by generating and monitoring events. As such, a business process must be uniquely identifiable within the context in which it operates. The events which are monitored by a business process may trigger business rules or authentication rules to activate and generate additional events in turn. Referring to the running example, we distinguish a number of processes and (operational) services. For example, the information gathering process is a long-running process which interacts with a number of information services that provide current news feeds about new worm outbreaks, disclose information about recently discovered vulnerabilities, etc. Like the information gathering process, we also distinguish an incident response process. The incident response process typically generated events which are monitored by services such as the network operations service.
4. SPECIFICATION AND QUERYING In the previous section, we introduced the basic concepts on which the EFSOC framework is based and we discussed the elements of which the model is comprised. This section represents the elements which are directly related to specifying and querying security constraints. We have developed a language for specifying and querying the elements of the EFSOC model named EDL (EFSOC Definition Language). BNF excerpts of this language are depicted in Figure 6. This figure illustrates that EDL distinguishes a number of different definition statements. We can define new queries, new (atomic) roles and new hierarchical roles. In addition, it is possible to assign roles to subjects and define new autho-
definitionStatement: roleDefinitionStatement | queryDefinitionStatement ;
Assume a rule which will allow a member of the duty team to request a block of a network address:
roleDefinitionStatement: basicRoleDefinitionStatement | hierarchicalRoleDefinitionStatement ;
allow blockRequestEvent from authenticated DutyTeamRole
basicRoleDefinitionStatement: DEFINE ROLE IDENTIFIER SEMICOLON ; hierarchicalRoleDefinitionStatement: DEFINE ROLE IDENTIFIER INHERITS IDENTIFIER SEMICOLON ; assignmentStatement: roleAssignmentStatement ; roleAssignmentStatement: ASSIGN ROLE IDENTIFIER TOSUBJECT IDENTIFIER SEMICOLON ; authRuleStatement: newAuthRuleStatement ; newAuthRuleStatement: PERMISSION IDENTIFIER FROM AUTHSTATUS IDENTIFIER SEMICOLON ; queryDefinitionStatement: DEFINITION QUERY IDENTIFIER IDENTIFIER OPENBRACE paramList CLOSEBRACE expression ;
The authorization rule refers to a positive authorization (allow), which is associated with a blockRequestEvent sent by a subject who has fully authenticated himself and is playing a DutyTeamRole. The response to such a request may only be sent by the network operations team, providing a request was issued earlier. This is represented by the rule allow blockResponseEvent in response to blockRequestEvent from authenticated NOCTeamRole To evaluate the rule, the current role sessions must be queried to determine which subjects have been fully authenticated and are currently acting as DutyTeam members, resp. as NOCTeam members. For the second rule, the event service must also be queried to determine if the event is being sent as a response to a previous event. If all conditions are met, the rules will evaluate positively and permission may be granted.
Figure 6: BNF notation of the EDL Grammar rization rules in the grammar as shows here. The grammar shown in the figure allows us to define new role (potentially hierarchical) and assign new roles to subjects. In addition, it allows us to define new authorization rules, assign roles to subjects and define queries. Referring to the running example, assume we want to introduce a new role DutyTeamRole. Representing this in EDL, the correct statement would be:
As mentioned earlier, in addition to enable defining new elements, EDL can also be used to query the current state of a model. Assume we would like to determine which subjects are currently active in the DutyTeamRole. To achieve this, we would define the following query: define query Subject activeDutyTeamMembers (String subjectname) { exists ra:RoleAssignment rs:RoleSession ($this name $subjectname) and ($ra subject $this) and ($ra role DutyTeamRole) and ($rs roleassignment $ra)
define role DutyTeamRole Furthermore, assume that we would like to define a new role for help desk staff. In our running example, all help desk staff members are also support staff members. We would represent this as define role HelpDeskRole -> SupportRole Note that similar to defining a new role, we can also undefine them: undefine role DutyTeamRole Authorization rules may refer to previously defined entities to determine the outcome of their evaluation. Authorization rules can also be represented using the EFSOC language.
} The above definition represents a query called “activeDutyTeamMembers” which takes a subject’s name as input. As the query returns subjects, processing will begin by restricting the potential result set to all subjects with the given name. Next, the role assignments of those subjects to the DutyTeam role will be retrieved. Finally, in the last step, the corresponding role sessions are checked. Summarizing, the query will retrieve all subjects with the provided name who currently have a role session of which the DutyTeamRole is part. Another possibility is to define a query which will query the runtime environment to determine which business process invoke a given service. Assume that a business process invokes a service by generating an event which is subsequently
monitored by that service. As event monitoring and generation may change from one moment to the next, a query like this will allow us to determine at any point in time which associations exist between business processes and service. The query may de defined as follows
define query String businessProcessesUsingService (String servicename) { exists s1:Subject s2:Subject e:Event
and and and and and
($s1 ($s1 ($s1 ($s2 ($s2 ($s2
name $servicename) instanceOf operationalService) receiveEvent $e) sendEvent $e) instanceOf businessProcess) name $this)
}
As can be seen in the query, first all subjects given the provided name are selected. The selection is than reduced to only contain operational services. Having the list of operational services of the provided name, all events that may be received by those services is retrieved. With that list of events, we retrieve the list of all subjects that may send this event. This list is reduced to only consists of business processes. Finally, of the remaining list of business processes, we match the name of the business process for the result output. Using EDL, we can therefore adjust the defintions in the EFSOC model, and also query them, runtime.
5.
ARCHITECTURE AND PROTOTYPE
The model, and its supporting EDL language, which was presented in the previous section has been partially implemented as a running prototype. Our efforts were focused at creating a basic infrastructure which allows us to specify and query security-related aspects. As such, the prototype implementation supports subject management, role management and authorization policy management. The core of the prototype implementation is a programmers interface built in Java which allows access to the underlaying infrastructure. We chose for ConceptBase [Jarke et al., 1995] as a solution to model the core elements of the EFSOC framework and to act as a data repository for events and role assignments. ConceptBase is a deductive object manager for meta databases which implements a language variation of Telos [Mylopoulos et al., 1990], a knowledge representation language which provides powerful facilities for constructing, querying and updating structured knowledge bases. Subject credentials and descriptive information are stored in a central directory which can be queried via the Lightweight Directory Access Protocol (LDAP) [LDAP]. Finally, we im-
Figure 7: EFSOC Prototype Architecture Overview plemented a rule repository, which is stored in the filesystem of the server. The EDL language has been implemented using flex [Flex] and cup [Hudson et al., 1999] and translates EDL statements into ConceptBase-compatible expressions. For example, the definition of a new role represented in Telos notation looks as follows: Individual edlrole1 in Role with name n: "DutyTeamRole" end Certain basic of the EDL language constructs are still easier to implement directly in ConceptBase. For example, a common requirement in role-based access control implementations is the ability to define static separations of duty. A static separation of duty between two roles means that at no time, those two roles may be assigned to the same subject. Using ConceptBase notation, we can implement such a static separation of duty between the DutyTeam role and the EndUser role as follows: Individual ar2 in AuthorizationRule with constraint ssepDutyTeamRoleEndUserRole: $ forall ra1/RoleAssignment ra2/RoleAssignment
In addition to calling the three infrastructure services directly interactively via the Java GUI, they can also be called directly as web services or via the programmers interface. This facilitates the embedding of the EFSOC approach in newly developed applications or in existing legacy systems. For each of the services, a WSDL description is available. For example, a section of the port type definition of the security service has been included below:
Figure 8: Role Assignment GUI
(ra1 role DutyTeamRole) and (ra2 role EndUserRole) ==> not exists s/Subject (ra1 subject s) and (ra2 subject s) $
Similarly to defining separations of duty, EDL queries can be translated to ConceptBase notation. The example query that we introduced in the previous section can be represented as:
Individual getActiveDutyTeamMembers in GenericQueryClass isA Role with attribute,parameter n: String attribute,constraint: c: $ exists ra:RoleAssignment rs:RoleSession (~this name ~n) and (ra subject $this) and (ra role "DutyTeamRole") and (rs roleassignment ra) $ end }
The API can be accessed by three web services which have also been implemented in the Java programming interface and which have been deployed via a Apache Tomcat server, or by a Java application which acts as a GUI for defining new roles, subjects and role assignments. Figure 8 shows a screenshot of the role assignment GUI. On the left hand side, is shows the roles that are currently assigned to subject kees, while on the right hand side the unassigned roles are listed.
