Semantic Policy Enforcement and Reconciliation for Information Exchange in XMPP Brian Ulicny, Won Ng, Oleg Simakoff, Jakub Mieczyslaw M. Kokar Moskal Department of Electrical and Computer Engineering VIStology, Inc. Northeastern University Framingham, MA USA Boston, MA USA {bulicny, wng, osimakoff, jmoskal}@vistology.com m.kokar@neu.edu Abstract— Extensible Messaging and Presence Protocol (XMPP) ends of the connection are governed by different policies. is a popular open-standard protocol for instant messaging (IM) widely used in military and commercial applications. In military 1.1 Semantic and Non-Semantic Representations of contexts, as in commercial settings, it is often necessary to Policies regulate who may communicate with whom and how. The distributed nature of XMPP makes centralized information Policies can be implemented in a system via the hardware (e.g. exchange policy enforcement impossible, however. We report on this light will not turn on unless both of these switches are a technology we have developed, called PolVISor, in which we express information exchange policies in a natural language turned on); or in software. In software, a policy can be formalism (SBVR SE), automatically translate these policies into represented either syntactically or semantically. By a an executable rule language (BaseVISor rule language) and semantic representation, we mean a representation in which enforce and reconcile disparate policies among XMPP servers, inferences can be made on the basis of a policy instance using each with its own policies, using semantic technologies. a domain-generic inference engine. So, for example, a Windows Group Policy instance has a meaning that is clear to Keywords: XMPP; security policies; policy reconciliation; everyone who knows the semantics of the policy language. SBVR; ontologies; deontology; modality However, no generic reasoning engine can draw inferences from Windows Group Policy instances in their native format. I. INTRODUCTION The representation has no meaning to those engines. Policy authoring, representation and enforcement are A primary objective in our work is to develop the means essential components in security systems. As systems grow by which operations governing policies can be handled and collaboration becomes more ubiquitous (e.g. via grid automatically by a computer. For this reason it is important to computing, collaboration among coalitions), the set of security be able to describe policies in a formal, declarative way that policies grows larger. This leads to potentially undetected will permit them to be automatically processed by formal policy conflicts and the need for automated or semi-automated reasoning engines. policy reconciliation. Our work has resulted in PolVISor, A formal reasoner or inference engine is a system capable which uses ontological reasoning to determine security policy of applying the formal axioms of a language to a body of compliance and provide policy reconciliation when possible. data/facts/knowledge resulting in the derivation of additional We demonstrated the necessity, feasibility and flexibility of inferable facts. A rule-based system, for example, may be used PolVISor to constrain information sharing in an XMPP as a formal reasoner if it is provided with a set of axioms for (Extensible Messaging and Presence Protocol) environment. the language in which the data/knowledge is represented. Such axiom sets are available for a number of ontology languages as II. SECURITY, POLICIES AND RECONCILIATION discussed below. In this project we were concerned with the ability to use An important principle employed by many systems policies to ensure compliance during runtime as well as with including policy-based reasoners is the use of the closed world the ability to do policy reconciliation. Policy compliance assumption (CWA), which permits systems to assume that involves the run-time process of ensuring that all of the everything that is known to be true of the “world” is available conditions defined by a policy hold true; a common example is in the facts that have been provided about it; if a fact is not the checking of credentials required before granting access to explicitly stated it is assumed to be false. The closed world a document. In policy reconciliation, the goal is to take defined by a set of facts can be thought of as a “context” in multiple polices and, e.g., generate a policy instance that which reasoning is to occur. OWL-based systems, like simultaneously satisfies all of them; a typical example here is PolVISor, do not adopt the CWA. determining specific conditions under which a communication For reconciliation to be possible there should be an session can be established between nodes in a VPN where the explicit separation of policies and mechanisms that use the policies, and the policies should be first-class objects within university might want to avoid making such a policy known to the security system. In this way, policies will be objects that other users or systems in order not to disclose unwanted can be represented, stored and manipulated by the security information. We have not focused on such situations of policy system. Moreover, in this way policies will have their own reconciliation where trust is an issue since trust management is interpretation, or semantics. This has a very important impact beyond the scope of our current investigations. on the accreditation process in that mechanisms can be accredited and then policies can be added dynamically. 1.2.1 Information Exchange Policies 1.2 The Policy Reconciliation Problem In this paper, we examine enforcing and reconciling information exchange policies. Information exchange policies Two systems or elements of a system may impose are important in military and intelligence situations, where policies on certain operations. In this paper we define policy cross-organizational collaboration is required but strict reconciliation as the determination of a policy that implicitly policies restrict who can communicate with whom and what or explicitly satisfies both policies and governs the behavior of information they can exchange. For example, a military the interaction of the system(s). Provisioning policies, coalition might allow members of different national forces to authorization policies and information exchange policies are collaborate on some tasks within certain channels and with all types of policies that may require reconciliation. certain information, but not others. The same is true of In this project, we have bounded the problem of policy financial services and health care industries, which both reconciliation in several ways. First, we assume that all regulate information exchange. For example, in financial partners in the policy negotiation process are equals. services, so-called Chinese Wall policies regulate Therefore, we have chosen not to incorporate policy deference communication between analysts and traders. In health care, mechanisms saying that if System 1 and System 2 have privacy and confidentiality policies regulate what information different policies, then one of the system’s policies overrides can be shared between health care providers and patients. the other. While such meta-policies are widespread in practice, Information sharing between social networking sites and other they do not pose an interesting conceptual problem. sites is another current example, particularly where single Secondly, we have not dealt with preferences among sign-on schemes like OpenID (http://openid.net) are involved. policies. Thus, a system might allow distinct set of actions A In the military and intelligence community, information or B (distinguished by their participants, say, or by other exchange policies are labeled “Cross Domain Solutions”: parameter settings), but it would prefer one set to the other. “Cross Domain Solutions (CDS) are controlled interfaces that We have not addressed this issue because it essentially provide the capability to access or transfer information across involves a different kind of modal reasoning: reasoning that different security domains.” 1 The eXtensible Markup ranks some situations as more desirable than others, although Language (XML) Data Flow Configuration File (DFCF) each is permissible. This is the logic of “should” and “should format specification 2 was developed to provide a common not”, as opposed to the logic of “may (not)” and “must (not)” format for defining, validating, and approving XML data as described in the section on our deontic ontology of actions flows for use in XML cross domain solutions. DCDF is below. The considerations involved in modal reasoning about specified syntactically in XML in terms of information sharing ‘should’ involves a higher-order reasoning than the logic of system endpoints, where a complete policy specifies, for each ‘may’ and ‘must’, and we have not addressed this in this endpoint pair, what information can be sent from an endpoint, project. In particular, we have not addressed what might be and what information may be received by an endpoint. Such called “consequentialist” policies, where a policy is preferred comprehensive policies are difficult to set up, are likely to based on its outcome. For example, one might say, choose become obsolete as the contents of the endpoint systems policy A or policy B based on which one allows the most (or change, and are not flexible. Finally, they are not reconciled, fewest) users (perhaps meeting some other criteria) to access across all endpoints because one system cannot impose any some set of files. Such a system would require some kind of limitations on another system, only on itself. However, they modeling and simulation step to determine how many users can be implicitly reconciled at run time when two endpoints have access, and thus determine the policy choice. try to exchange information. Finally, we have not concerned ourselves with situations in which the policies to be reconciled cannot be completely III. POLICY LANGUAGES disclosed between the interested parties. There are In our project, we use SBVR Structured English (SE) for undoubtedly situations in which the policies that govern some authoring policies in an English-like formalism. SBVR SE action are themselves proprietary and sensitive in that they policies are then automatically translated into BaseVISor Rule reveal, with contextual information, proprietary information. Language (BVR) for execution and policy reconciliation. For example, suppose a University had a policy in which admitted students could sign up for a campus bulletin board 1 system. If prospective students learned about this policy, they Unified Cross Domain Management Office, What is a cross domain solution?, http://www.ucdmo.gov/faqs.html. could potentially find out who had been admitted to the 2 XML Data Flow Configuration File Format Specification Version 1.2.11 19 university before the official announcement had been made by December 2008 http://iase.disa.mil/cds/helpful_tools/dfcf-specification-1-2- trying to register on the bulletin board. In such a case, the 11.pdf 1.2.2 SBVR Structured English It is obligatory that a driver is qualified if the driver rents a car that is owned by EU-Rent Semantic of Business Vocabulary and Business Rules (SBVR) [1] is an OMG standard introduced in 2008 that aims at a more SBVR RuleSpeak® [4] is a proprietary variant developed natural format for expressing rules. Business rules are by Business Rule Solutions, LLC (BRS) [5]. RuleSpeak® expressed in a subset of natural language that is readily provides templates for business rules based on the category or understandable by business people, instead of at an subcategory that applies to the rule. We did not use the implementation level, such as rules that are processable by a RuleSpeak format and will not address it here. formal reasoning engine. The vocabulary represents the Like the other languages discussed, SBVR is domain and concepts used in the rules and can also express facts and application independent. The SBVR specification includes a relations between concepts (e.g. that Fido is a dog). The proposal relating SBVR concepts to equivalent OWL specification is based on first order modal logic and captures expressions, so clearly some consideration was given to how the semantics of implementation-independent business SBVR should work with semantic languages. Its main strength models. Figure 1 locates SBVR in the Business Model (also over the other languages is its user friendliness. Because called the Computation-Independent Model) level in OMG’s SBVR SE is an almost-natural language, it is suitable for Model Driven Architecture (MDA) [2] and is meant to be expressing high-level rules. Among available editors are translatable to a Platform-Independent Model (PIM) that SBVR-VE (SBVR Visual Editor) [7], a graphical drag-and- describes the structure and behavior of the model, and drop editor where attempts to create links between boxes subsequently to a Platform-Specific Model (PSM) that containing, say, a modality and a term, would often not work; includes all the platform dependent information necessary for Sepiax-Web [8], an Ajax-based web editor with WordNet and a developer to implement executable code, such as specific SBVR integration; SBeaVer [9], an Eclipse plugin that programming language packages. SBVR is mapped to the provides syntax highlighting for SBVR SE; and a proposed Meta-Object Facility (MOF) [3] metamodel – a useful feature SBVR tool component [10], including an editor, as part of for transformations of an SBVR model to other models. Eclipse’s Modeling Development Tools (MDT) [11] that has been in development for the past few years. There are also enterprise editors that support RuleSpeak®. SBVR is sufficiently expressive for representing high level rules but because SBVR is at the business model level, it suffers from the common problem that most business model level components do: translation to a PIM and especially to a PSM requires additional details about computations and platform-specific information, usually supplied by an IT person. The SBVR vocabulary can be expanded to include platform vocabulary, but SBVR is meant to be a high level Figure 1: SBVR in OMG’s MDA. language and is not executable, so SBVR is most useful when translated into a lower level executable language like SBVR distinguishes between alethic and deontic constraints. BaseVISor Rule Language (BVR), as we have done. Alethic rules are categorized as structural business rules, which are rules that must necessarily be true as part of the 1.2.3 BaseVISor Rule Language (BVR) business organization. Deontic rules are operative business rules that should be obeyed but which can be violated in BaseVISor (http://www.vistology.com/basevisor), a versatile practice. forward-chaining rule engine specialized for handling facts in SBVR has two common notations: Structured English the form of RDF triples (i.e., subject, predicate, and object), and RuleSpeak®. Structured English (SBVR SE) is a expresses rules in BaseVISor Rule language (BVR). The controlled English vocabulary and grammar that uses font BaseVISor engine implements OWL 2 RL inference rules in styling and color to indicate SBVR concepts. term represents a BVR and supports XML Schema Data Types. noun concept such as rule and action. Name is an individual Generally speaking, rules are expressed in the form of concept and usually is a proper noun, e.g. California. verb is if/then statements. The ‘if’ part of the statement is represented part of a SBVR construct called a fact type and is usually a by the ‘body’ or ‘antecedent’ of the rule; the ‘then’ part is verb, preposition or combination of preposition and verb. represented by the ‘head’ or ‘consequence’. In BVR the Lastly, SBVR SE defines a set of keywords that are reserved contents of rule heads and bodies are made up of triple words or phrases with special meaning. Examples of keywords patterns (i.e., triples that may contain variables) and are the articles a and the, modality phrases It is necessary that, procedural attachments, i.e. functions such as add, assert, and and quantifications every and at most one. An example of a println (print line). Users can add user-defined procedural SBVR SE rule is: attachments for use in rules. BaseVISor also supports queries, which are special cases of rules with empty heads, and are useful for retrieving information from the resulting fact base. BVR is domain and application independent, compatible necessity relation in the ontology directly. Ontologies, after with the semantic languages OWL and RDF, designed for all, express constraints on how the world can be. To say that formal reasoning and executable in the BaseVISor users may have a password is expressible by saying that the environment. It is very expressive, especially since the class of Users and the class of things that have a password are language is extensible via user-defined procedural not disjoint. attachments. A BVR editor is available as an Eclipse plugin to Deontic Logic [12] is the study of the logic of the aid in composing BVR rules. concepts “may” (or deontic ‘can’) and “must” and their duals Translation of SBVR SE into BVR makes use of “may not” and “must not”. These concepts are crucial in metamodels for both languages. First, SBVR SE expressions expressing policies: policies express what may or may not be of policies are saved as XMI, then a proprietary metamodel-to- done, under certain conditions, and what must and must not be metamodel mapping is used to translate the SBVR XMI into a done, again under certain conditions. May and must are modal corresponding BVR rule, preserving its semantics. notions. Sentences employing modal notions do not express the way the actual world is, but qualify the truth of the IV. SECURITY POLICY ONTOLOGIES proposition they modify, in this case expressing conditions on We developed two OWL ontologies to encapsulate our how possible worlds should be if they are to comply with the treatment of policies as classes and to represent concepts and policies our ontology encodes. That is, if I say that “John may their relations that we have determined to be essential for go to the store” or “John must (not) go to the store”, I do not security scenarios, including information exchange. These say anything about how the actual world is with respect to “core” ontologies are the basis for any domain-specific John’s going to the store. What I express has to do with the application of PolVISor, i.e. domain-specific scenarios should consistency of John’s going to the store with the ways in extend these ontologies with their domain-specific knowledge which John is permitted to act or with the ways in which John and rules. The design of the ontologies, such as treating must act. actions and operations as first-class entities, are grounded in In our inference engine, BaseVISor, propositions are our study and investigation of formal security models. expressed as triples (subject, predicate, object). BaseVISor does not allow for modal operators over triples. Therefore, 1.2.4 Representing Modal Notions in OWL rather than give modal operators their usual semantics as quantifiers over possible worlds or ways the world could be or PolVISor, as we have said, involves two kinds of modality, ways a person could act, we treat Actions as a class that can be deontic and alethic. Modal expressions qualify the truth of a subdivided into Permissible (may), Omissible (may not), statement. For example, to say that “John is possibly Optional (may and may not), Obligatory (must) and Prohibited dyslexic” is not to assert that “John is dyslexic”, but a more (must not) subclasses. qualified statement that the statement might be true. Modality The structure of the ontology is represented in Figure 2: is expressed logically as operators over propositions. Op(p) means that some modal operator Op is being asserted of the proposition p: It is Op that p. The operator identifies the way in which the truth of the bare proposition p is being qualified. Alethic modality is the logic of possibility (it is possible that p) and necessity (it is necessary that p). As specified by SBVR, alethic notions are encoded directly in the ontology. Necessity relations between classes are expressed in Figure 2. Classes and subclasses of Deontic Ontology terms of subclass relations that apply to all instances. Thus, to say that “necessarily, all bachelors are unmarried” or First, Actions are subclassified as Permissible or Omissible. “necessarily, all cats are mammals” is to say that the class An action is Permissible if it may be done. For example, Bachelor is a subclass of Unmarried Things and that Cat is a getting married is permissible, so the class of actions that is subclass of Mammal. Without such a subclass relation, it getting married could be represented as a subset of the class of might be that all of the instances of Bachelor are instances of permissible actions. Unmarried, but that would be a contingent coincidence, not a An action is Omissible if it is permissible not to do it. necessary truth, with respect to that ontology. We encode that For example, eating okra is omissible. One may abstain from it is possible that (some) Fs are Gs (e.g. that some File Clerks eating okra. The class of actions that is okra-eating could are Dyslexic) in the ontology by failing to have class F (File thus be represented as a subset of the Omissible actions. Clerk) and G (Dyslexic) as disjoint classes. If F and G are In fact, one both may and may not eat okra (and one marked as disjoint classes, then necessarily, no Fs are Gs, may or may not get married), so instances of both of these (and, necessarily, no Gs are Fs), according to that ontology. types of actions would be instances of the intersection of the “It is necessary that a user has a password” expresses Omissible and Permissible classes: the Optional actions. a necessity relation between the class of Users and the class of Obligatory actions (actions one must do) are a subset things that have a password. This necessity relation would be of the Permissible actions. If an action must be done, then it expressed by saying that the class of Users is a subclass of the may be done. The Obligatory actions and the Omissible class of things that have Passwords. This encodes the actions are disjoint: if an action must be done, it is not the case V. INFORMATION SHARING IN XMPP that it may not be done. Extensible Messaging and Presence Protocol (XMPP) [16] is a Similarly, Prohibited actions (actions one must not popular open-standard protocol for instant messaging (IM) do) are a subset of the Omissible actions (actions one may not widely used in military applications. There are a number of do). The Prohibited actions and the Permissible actions are extensions to the protocol that define protocols for other disjoint: if an action must not be done, then it is not the case functionality, like Voice Over IP (VoIP). Each user signs into that it may be done. his XMPP account identified by a jid, commonly of the form We have expressed these relations in an OWL name@domain.server, e.g. juliet@montague.net. Each jid has ontology. The ontology may be downloaded at a contact list called a roster. Figure 3 illustrates the process http://vistology.com/ont/2010/secpol/Deontic.owl. when a user signs on. The server hosting the user By means of this ontology, one can state that all automatically sends a presence to each of his contacts, except instances of actions of a certain type are, for example, for those he has blocked, to indicate that he is now online. The prohibited (e.g. theft, murder) or permissible (e.g. expressing contact’s server forwards the presence to the receiver, unless one’s opinion, forming associations) across the board. Policy she specified that she does not wish to receive presences from rules allow one to express conditions under which actions of a the sender. The contact’s server also sends back a presence to certain type are classified as permissible or prohibited or the sender if she has not blocked presence-outs to the sender. optional based on additional facts about them. For example, Now the two clients can start chatting with each other. Users one could express the policy that it is permissible to marry can also join chatrooms, participate in conversations as a only if one is at least a certain age, not already currently group, and send messages to individuals in the room. married, and so on. Privacy lists allow users to specify contacts with whom he wishes to restrict contact. However, there are currently no 1.2.5 Upper Policy Ontology methods for server to specify policies to restrict users’ chat, We developed a policy ontology to serve as the base of all except by name. Using Openfire [17], an open source XMPP application- or domain-specific ontologies, available at server available from Ignite Realtime [18], for our server, we http://vistology.com/ont/2010/secpol/UpperSecPolOnt.owl. It developed an Openfire plugin that intercepts incoming and was derived by starting with the Naval Research Laboratory’s outgoing XMPP stanzas. The stanzas of interest in our (NRL) Security Ontology [25]. The NRL ontology was scenarios are presences and messages, but all stanzas are primarily designed for annotating resources with security- intercepted so our implementation is extensible. Users connect related metadata in order to facilitate the discovery of to servers via Spark IM Client [19], an open source IM client resources that meet security requirements. application also provided by Ignite Realtime. In our ontology, a Policy consists of one or more The Openfire plugin plays the role of the context handler Rules, associated with a SecurityPurpose (e.g. Data Integrity, here. It invokes an XSLT script to translate the XMPP stanzas Confidentiality). Rules are expressed in SBVR SE and to RDF and passes the RDF version of the stanza to PolVISor. translated into BaseVISor rule language. Rules govern PolVISor analyzes the stanza and returns to the plugin a Operations (Actions), i.e. operations performed by an element decision to allow or deny the stanza. We chose to implement a in the system (e.g. reading a file). Each Operation has an agent deny-overrides approach, where if any applicable rule denies who originates the operation and an object that is the target of the stanza, the stanza is denied. If the stanza is allowed, the the operation. In the example of Bob reading a file foo.txt, the plugin forwards the original stanza to Openfire, which operation is a Reading with agent Bob and object foo.txt. processes it as usual. If the stanza is denied, the plugin drops These Operations are declared to be owl:sameAs the the stanza and the server does not see it. The behavior of the class of Actions in the Deontic ontology, and thus, plugin can be changed to modify the stanza instead, for subclassified as Permissible and Omissible, and so on. They example if dropped stanzas should be logged by the server. can also be equated to some other ontological representation We developed an XMPP ontology with the core concepts of operations. Here we assert our Operation class to be such as jid and presence. The scenarios below build upon this owl:sameAs the class of UCore-SL Acts, indicated by the base ontology. Because of our action-oriented approach in the namespace sl. UCore-SL is an OWL version of the UCore upper ontology, actions like Sends are subclasses of Operation. [13][14] messaging format adopted for information sharing BVR rules convert the stanza information to match the among the defense and intelligence communities. ontology, e.g. based on a presence stanza from For Security Markings, we have employed Richard Lee’s juliet@montague.net to romeo@capulet.com, a Sends instance ISM Ontology v. 0.7 [15]. This ontology is described as “a is generated that has agent the sender juliet@montague.net and rendering of the IC-ISM XML spec for security markings. It is has object the presence stanza, and the presence stanza has based on the IC-ISM v5 XSD, updated thru 2010-09-25. “to” romeo@capulet.com and “from” juliet@montague.net. Although this ontology provides a complete taxonomy of A. XMPP Presence Scenario security markings in use by US and Coalition partners, it does To demonstrate server policies that limit who can not generally order security markings from high to low within communicate with whom, based on facts about the persons a markup scheme. We have added axioms to encode these involved, we implemented rules and ontologies for one server facts as needed. that restricts chat based on gender and another server that B. XMPP Security Labels Scenario restricts chat based on the first letter of the jid. Gender is used CWID 2010 featured a Cross Domain Collaboration for simplicity, but any class of persons could be used here, for implementation [20]. The collaboration scenarios included example, filtering users by any combination of role or chatting and document sharing using security labels, access nationality or location. Because chatting depends on the initial control and authentication. Clients and servers were modified sending of presences to contacts, the rules analyze presence to support security labels, among other functionalities. Boldon stanzas and apply to incoming and outgoing presences. The James’s SAFE IM for XMPP [21] allows users to assign rules state: security labels to their one-to-one chats, group chats in rooms, and file transfers. It checks that receivers of labeled messages have sufficient clearance to read the message and that users who wish to join a chatroom with a security label have sufficient clearance to join. Isode’s M-link server [22] is a XMPP server with support for controlling message flow based on the security label of the message and the security clearance of the sender and recipient. We have implemented the same functionality of security labels by extending the ontologies and rules for the presence scenario outlined previously. Both sets of ontologies and rules for Server 1 and Server 2 have the same extensions and use the security levels from Intelligence Community Information Security Marking (IC-ISM) ontologies [23] for security labels and clearance levels. We added reflexivity and transitivity to the relevant properties so PolVISor can reason that someone with a clearance of TopSecret can send and Figure 3: XMPP sequence diagram for sign in and roster receive messages classified as TopSecret or any lower level retrieval. like Secret or Unclassified. This scenario considers one-to-one labeled chat messages but can be easily extended to group chat Server 1 Policies: messages sent to a labeled chatroom so that no messages with Allow presences to/from Males on Mondays, Wednesdays a label at a higher level than the chatroom’s maximum allowed and Fridays. label could be sent. Clients set the level by enclosing the label in brackets in the beginning of the message body, e.g. Allow presences to/from Females on Tuesdays, Thursdays [RESTRICTED]. and Saturdays. The rules state: Each user’s gender is encoded using the FOAF (Friend of a If a sender sends a labeled message to a recipient on a Friend) vocabulary, and the information is available to Server different server and the sender has equal or higher security 1. Because the FOAF gender is an untyped literal, a helper clearance than the security level of the message, then the BVR rule determines whether a jid is an instance of the class message is permitted to be sent. Male or Female accordingly. If a recipient of a labeled message from another server has Server 2 Policies: equal or higher security clearance than the security level of the Allow presences to/from contacts whose jid start with A-L message, the message is permitted. on Mondays, Tuesdays and Wednesdays. If the sender and recipient of a labeled message are on the Allow presences to/from contacts whose jid start with M-Z same server, and if the clearance of the sender and clearance of on Thursdays, Fridays and Saturdays. the recipient are equal or higher than the label’s level, the message is allowed. Server 2’s rules take advantage of BaseVISor’s built-in regular expression procedural attachments. If a message does not explicitly have a security label, the All other stanzas that are not allowed explicitly are message’s security label is Unclassified. denied, e.g. no one hosted on either Server 1 or Server 2 can All stanzas not explicitly allowed are denied. chat with others on Sundays. Here, policy reconciliation is implicit; a presence successfully sent from a user on Server 1 C. XMPP Chatroom Reconciliation Scenario to a user on Server 2 means that both Server 1 and Server 2 To demonstrate explicit reconciliation, we implemented allow the stanza. Therefore, amy@server1.com who is Female another scenario. If a client on Server 1 wants to join a on Server 1 can chat with brenda@server2.com who is Female chatroom hosted on Server 2 and both Server 1 and Server 2 on Tuesdays because of Server 1’s second rule and Server 2’s have security policies restricting who can join what chatroom, first rule. then their policies must be successfully reconciled and the attempt to join must satisfy the reconciled policy in order for the attempt to be allowed. By satisfying the reconciled policy, relation. Alignments can be used to generate various tools the request also satisfies each server’s policy. A client joins a used in further automated processing. For instance, a chatroom by sending a presence to the chatroom, so the rules translator can translate data instances expressed in one analyze presence stanzas. ontology to another, or a mediator that can translate queries The rules state: expressed in one ontology to another, and translate answers in Server 1 Policy: If the client is Male, he can join any the opposite direction. chatroom. Despite sophisticated methods from AI, ontology matching currently can rarely be fully automated beyond Server 2 Policy: Any client can join any chatroom. relatively simple correspondences, covering syntactic and Server 1’s policy is more restrictive than Server 2’s, and terminological heterogeneity. When the same concepts in lacking any other rules that concern clients joining chatrooms, different ontologies are defined using different axioms, ensure that only Males are allowed in chatrooms that involve matching algorithms often have difficulties identifying any any Server 1 clients. Figure 4 depicts the process. The plugin correspondences at all, or find ones that are irrelevant. When and PolVISor are not explicitly shown, but rather are matching is incomplete or incorrect, manual editing is subsumed as part of the server. The reconciled policy in this necessary. Matching systems typically allow the user to case is logically equivalent to Server 1’s policy since Server specify a threshold for confidence held in the 2’s policy subsumes Server 1’s. Therefore, reconciling the correspondences, which allows for eliminating matches that policies is equivalent to adopting the more restrictive policy. are most likely invalid. However, because the servers have their own In order to demonstrate the use of automated ontology extended ontologies with server-specific classes and matching in the process of policy reconciliation, we matched properties, ontology mapping could be needed for the request FOAF and vCard ontologies with the threshold of 0.9 (1 being to satisfy the reconciled policy. An ontology mapping scenario 100% confident) using an ontology matching API [24] and is discussed below. dynamically found the following relationships: Equivalent classes: Foaf:Organization and vcard:Organization Equivalent datatype properties: foaf:givenname and vcard:given-name foaf:givenName and vcard:given-name foaf:nick and vcard:nickname foaf:title and vcard:title foaf:family_name and vcard:family-name foaf:familyName and vcard:family-name Equivalent object properties: foaf:logo and vcard:logo Since vCard does not include gender information, we could not directly use this property to define policies. Instead, we used the nickname information, supported by both ontologies, in order to encode the gender of a user. We assumed that all Figure 4: XMPP chatroom reconciliation sequence. nicknames follow a pattern “g_Name”, where “g” can be either “F” or “M”, indicating the user’s gender. We designed a D. XMPP Ontology Matching Scenario scenario similar to the XMPP Chatroom Reconciliation Scenario, with the following rules: So far we assumed that both Server 1 and Sever 2 use the same ontology-based vocabulary to describe their clients. Server 1 Policy: If the client is Male (i.e. if his foaf:nick However, it is possible that the servers use facts expressed in starts with M_), he can join any chatroom. different ontologies, in which case before polices can be reconciled, ontology matching must be first performed. Server 2 Policy: Any client can join the chatroom. Ontology matching is the process of finding Reconciled Policy: If the client is Male (i.e. if his foaf:nick relationships between entities in two or more different or vcard: nickname starts with M_), he can join any chatroom. ontologies. The output of matching, called an alignment, is a set of correspondences that express the relationship between While the policies are similar to the previous scenarios, this different ontologies. Alignments include, but are not limited time Server 1 defines its policy using the FOAF vocabulary to, statements such as entity equivalence, sub-super and imports the client’s FOAF file, while Server 2 encodes relationship between entities, class intersection, or inverse user information in the vCard vocabulary. Thus, before the policies can be reconciled, FOAF and vCard need to be first matched in order to produce bridge axioms. Once matched, REFERENCES PolVISor reconciles the two policies, resulting in the [1] Semantics of Business Vocabulary and Business Rules v1.0. reconciled policy equivalent to that of Server 1. Figure 5 http://www.omg.org/spec/SBVR/1.0/ . May 2011. shows the process. [2] MDA Home Page. www.omg.org/mda/ . May 2011. [3] MOF Home Page. www.omg.org/mof/ . May 2011. [4] R. G. Ross. Basic RuleSpeak® Guidelines: Do’s and Don’ts in Expressing Natural-Language Business Rules in English. http://www.rulespeak.com/en/Basic%20RuleSpeak%20Dos%20and%20 Donts%20v2-2-5.pdf [5] Business Rule Solutions, LLC. Home Page. http://www.brsolutions.com/ . May 2011M. Young, The Technical Writer's Handbook. Mill Valley, CA: University Science, 1989. [6] P. McDaniel and A. Prakash. Methods and Limitations of Security Policy Reconciliation. ACM Transactions on Information and System Security (TISSEC), Association for Computing Machinery, 9(3):259- 291, 2006 [7] SBVR Visual Editor Home Page. http://sourceforge.net/projects/sbvrve/ . May 2011 [8] Sepiax-Web Page. http://www.sepiax.org/index.php?id=93 . May 2011 [9] M. De Tommasi, A. Corallo. SBEAVER: A Tool for Modeling Business Vocabularies and Business Rules. In Proc. 10th Int. Conf. on Figure 5: XMPP ontology matching. Knowledge-Based Intelligent Information and Engineering Systems (KES'06), LNCS Vol. 4253, 2006, 1083–1091 [10] MDT/SBVR Proposal Page. http://wiki.eclipse.org/MDT-SBVR- The alignment between FOAF and vCard was used to Proposal . May 2011. dynamically produce OWL bridge axioms, which allow for [11] Eclipse Model Development Tools (MDT) Home Page. reconciliation between policies using related, but differently http://www.eclipse.org/modeling/mdt/ . May 2011. named concepts. Thus, Server 2 can determine whether a [12] P. McNamara, Deontic Logic. The Stanford Encyclopedia of Philosophy client’s foaf:nick has the required prefix, and subsequently is (Fall 2010 Edition), Edward N. Zalta (ed.). http://plato.stanford.edu/archives/fall2010/entries/logic-deontic/ of the necessary gender, based on the “nickname” filed of his [13] UCore Specification Page. https://www.ucore.gov/ . May 2011. vCard. Although the scenario used a rather trivial example of [14] B. Smith, L. Vizenor, J. Schoening. Universal Core Semantic Layer. matching, our design and implementation can support more Ontologies in the Intelligence Community Conference, 2007. complex alignments, as long as the matcher can first [15] Lee, R. Using New Standards to Develop IC Ontologies. In Proc. of the automatically align the ontologies. Fifth International Conference on Semantic Technologies for Intelligence, Defense, and Security. (STIDS’10). Fairfax, VA, USA, VI. CONCLUSIONS October 27-28, 2010. [16] XMPP Standards Foundation. www.xmpp.org/ . May 2011. In this project, we have demonstrated that: [17] Openfire Home Page. http://www.igniterealtime.org/projects/openfire/ 1. Policies authored in a restricted natural language [18] Ignite Realtime Home Page. http://www.igniterealtime.org/ . May 2011. format (SBVR Structured English) can be automatically [19] Spark Home Page. converted to an executable formalism (BaseVISor rule http://www.igniterealtime.org/projects/spark/index.jsp . May 2011. language and OWL 2 RL) effectively. [20] CWID 2010 UK Cross Domain Chat. Enclosure 1 to Cross Domain Chat 2. Policies written in the ontology-based rule language Point Brief. July 2010. provide an effective and flexible way to specify expressive [21] Boldon, James – Military Messaging and Secure Information Exchange policies that can be automatically enforced using ontology- Software Page. http://www.army- based reasoning. The core ontologies used as the basis for technology.com/contractors/navigation/boldonjames/ . May 2011. domain-specific knowledge are grounded by our investigation [22] Isode Whitepaper: Using Security Labels to Control Message Flow in XMPP Services. http://www.isode.com/whitepapers/controlling- of established security models. message-flow.html . May 2011. 3. Policies written in the ontology-based rule language [23] Common Information Sharing Standard for Information Security can be effectively reconciled to allow for dynamic, policy- Marking: XML Implementation Implementation Guide. Office of the based information exchange between and an open set of Director of National Intelligence Chief Information Officer. Release XMPP servers. 2.0.3, February 2006. 4. While policy reconciliation typically requires the [24] J. Euzenat, F. Scharffe, and A. Zimmermann, “Expressive alignment language and implementation,” deliverable, Knowledge Web NoE, sharing of a common vocabulary, we have shown that 2007. Available at http:// ftp//ftp.inrialpes.fr/pub/exmo/reports/kweb- effective ontology matching can be implemented to allow 2210.pdf.. policy reconciliation across different (but similar) [25] Kim, J. Luo, and M. Kang, "Security Ontology for Annotating vocabularies. Resources," Proceedings of 4th International Conference on Ontologies, Databases, and Applications of Semantics (ODBASE'05), Agia Napa, ACKNOWLEDGMENT Cyprus, 2005. This work was performed under US Army contract W91260-09-C-0037 “Security Policy Reconciliation”.