Ontological Foundations of Modelling Security Policies for Logical Analytics

Abstract

Modelling of knowledge and actions in AI has advanced over the years but it is still a challenging topic due to the infamous frame problem, the inadequate formalization and the lack of automation. Some problems in cyber security such as logical vulnerability, risk assessment, policy validation etc. still require formal approach. In this paper we present the foundations of a new formal framework to address these challenges. Our approach is based on three-level formalisation: ontological, logical and analytical levels. Here we are presenting the first two levels which allow to model the security policies and provide a practical solution to the frame problem by efficient utilization of parameters as side effects. Key concepts are the situations, actions, events and rules. Our framework has potential use for analysis of a wide range of transactional systems within the financial, commercial and business domains and further work will include analytical level where we can perform vulnerability analysis of the model.

Introduction

In recent years there has been an increase in the interest of analysing the logical vulnerability and the security policies of cyber systems. The security policies cover a wide range of situations: how to prevent unauthorized access to the information, secure the operations, control the transactions, neutralize malicious activities, etc. Any gaps or inconsistencies in the security policies can open the door for logical vulnerabilities and leave the system exposed [3]. Logical analysis of the vulnerability requires modelling of the online operations with sufficient background information to cover the security - user credentials and profiles, needed for identification, authentication and authorisation, communication channels, physical connections and logical sessions for operations and transaction control, threat intelligence for security protection, etc. Our approach for addressing it is to represent the domain knowledge in the ontological model and to formulate the security policies as a system of rules, so that we can analyse them formally. For this purpose, we developed a theory of Situations and Actions in Description Logic (DL) and modelled the Security Policies in Clausal Logic (CL), which can be implemented using the standard languages of Semantic Web - Ontology Web Language (OWL) [5] and Semantic Web Rule Language (SWRL)[6]. We can model dynamic changes and synchronous actions with different security events asynchronously.

The paper is organized as follows. In Sect. 2 we will present the overall methodology which we follow. In Sect. 3 we will present logical foundations. In Sect. 4 we will introduce the ontological level. Section 5 will consider the security policies as rules on logical level. Section 6 we will conclude the paper and comment on the security policy analysis on Analytical Level.

Methodology

There are a number research projects being conducted that are developing ontological models for the different security purposes. They each use their own vocabulary, however, they use the same semantic web technologies (e.g., [4, 9]). We separate the model of the world (ontological level) from the model of the policies which govern the changes in the world (logical level) and the model of the dynamic changes as a result of decisions (analytical level) (see Fig. 1). For each of the three levels we will use different formal systems, suitable for modelling of an aspect of the problem in a manner, similar to the infamous “layered cake” of the Semantic Web [8].

Fig. 1.

Multi-level model for analysis

The Ontological Level models the world using the vocabulary presented in Sect. 4.1. The conceptualization is similar to the famous situation calculus (SitCalc) [7], but formulating it using the language of DL makes it more “object-oriented” and allows for a new solution of the frame problem [10]. Using DL on this level allows us to implement the model entirely using OWL.

The Logical Level models the policies, captures constraints and completeness. It reflects the expert knowledge in the domain, which can be formulated as logical rules in CL and can be represented in computer format using SWRL.

The Analytical Level will deal with the analysis of the policies on a directed graph, considering the situations as nodes and the actions as edges however it is beyond the scope of this paper and is left for the next publication.

Logical Foundations

For developing of the theory of situations and actions we consider DL called [13] which is not the most expressive but is expressive enough to support our needs without being too complicated beyond the necessity. More constructors can be added to extend if the modelling requires it. As we choose DL for comfortable implementation in OWL, similarly we choose CL as we can implement rules in SWRL. The following two logics can be glued together for modelling the domain ontology and the policies within that domain.

Description Logic as a Modelling Language

The syntax and the semantic interpretation is shown in Table 1. The interpretation I is a pair , where is a non-empty set (domain) and is a mapping function [12].

Table 1.

Syntax and semantics

Concepts		Roles
Syntax	Semantics	Syntax	Semantics
		R
		Domain(R, C)
A		Range(R, C)

where C, D are concepts, A is an atomic concept, R is a role.

Given interpretation I in model M with axiom , we say that M is a model of under I if M satisfies , written . We will be expressing the domain restrictions as and the range restrictions as [13]. By adding domain and range axioms we are able to have a fixed structure of the real world we are modelling without the necessity to use more expressive language or non-standard semantics.

Clausal Logic and SWRL

In most logical languages it is possible to formulate rules, which are necessary for modelling structural constraints and dynamic changes. We have chosen a version of the first order clausal logic similar to the horn-clause predicate logic because its serialized version SWRL refers directly to the terms of OWL.

SWRL Knowledge Base (K) is defined as follows: where is KB of and R is set of rules. The rule is composed of body and head which is represented as following: . It consists of a conjunctions of atoms which are classes C(i) (concepts in ) and object properties R(i, j) (roles in ) [6].

Ontological Level: The Domain Model

The term ontology in a narrow logical sense provides the terminology, which can be used for building the domain model, together with its interpretation in the semantic domain [11]. The cyber security operations require accounting of both static and dynamic semantic considerations, in order to have an adequate and semantically rich ontology for the analysis.

Terminological Vocabulary

In our ontology the semantic domain, , is a non-empty set, split into three disjoint subdomains: Entities, Events and Situations (plural) as , and respectively. In our theory we will use three terms with predefined meaning: Entity, Event and Situation (singular), which will be three separate taxonomies representing the static model of the world. The interpretation of concepts in the domain are as follows: , and . Our terminology (Table 2) will also include some predefined roles, one of them is Action (), which can be used as a top of the hierarchy of actions. The ontology can have as many specific named concepts and named roles as needed, (noted as , , , ), with the intended meaning and interpretations in the semantic subdomains introduced above in accordance with the syntax and semantics of as presented in Sect. 3.1. Concepts from three subdomains must be disjoint as follows:

1

Table 2.

Vocabulary of the domain ontology

Term	DL category	Use in modelling	Condition
Situation	Concept	Partial static description of the world	axiom 1
Event	Concept	Asynchronous activity	axiom 1
Entity	Concept	Qualitative descriptor	axiom 1
Action	Role	Synchronous activity	axiom 2
	Role	Event occurrence	axiom 4
	Role	Situation description	axiom 6
	Role	Event description	axiom 5
describe	Role	Describing entities and specifying dependencies	axiom 7
chain	Role	Connecting events causally	axiom 3

On the ontological level we are using the TBox for formulating the terminological axioms and the RBox for the relational axioms, while the ABox will incorporate the assertions later on.

Static Modelling of the World

Here we are defining a fix static structure of the modelling world using terms above. A Situation is a concept, which represents a partial description of the world in a specific moment of time. Two Situation concepts can be connected via Action roles to model the potential change:

2

The events are asynchronous activities which are modelled using Event concepts, linked through the predefined role chain in a causal chain (axiom 3). The intended meaning of Event is to represent a real-world events which can occur in the situations through the predefined role with domain Event and range Situation (axiom 4). This way we can formulate security policies with regard to planned and unexpected activities (events), which may or may not happen in the situations.

3

4

The Entity concepts are used to describe situations and events using the predifined roles from the vocabulary: with domain Entity and range Event (axiom 5); with domain Entity and range Situation (axiom 6); describe with domain Entity and range Entity (axiom 7).

5

6

7

It is important to note that the events do not change the situations in our theory, they can only occur in them; the changes can be caused only by actions. So that events are described as asynchronous activities while actions are purely synchronous activities.

World Dynamics

In state-based dynamic theories which uses DL, the actions are represented as pre-condition, occlusion, post-condition triplets [1, 2]. Unfortunately, there is no easy implementation of such a formalism since it has additional syntactic structure.

We have adopted the view that the dynamic changes are possible only through actions, similar to the original SitCalc from the early days of AI [10]. This logic formalism encounters the infamous frame problem, caused by the propositional treatment of the situations which require them to incorporate their parameters as arguments.

However, in our approach the definition of the actions (as relations between the situations) looks almost identical to SitCalc approach. The partitioning of our ontology has interesting and unexpected characteristics with practical importance for applications. We define the parameters of the actions contextually. In our approach the actions can change the situations only through their parameters, which are entities, but the action parameters are no longer attributed to the actions – they are attributed to the situations which the actions relate instead. This completely eliminates the need for heavy “frame axioms" because the complete absence of any “side effect" of the actions.

If we have TBox T with situations and entities as follows:

8

and describe , T is extended as follows:

9

Example 1

Let’s consider the situation LoggedIn and the entity User. For this scenario the TBox T is as follows:

Each situation can be described by a number of entities. Since the actions change the situations, they will affect these entities but not directly. So, we can consider the entities which describe all situations in which a given action applies as its input parameters and similarly, entities which describe the situations to which the action leads as its output parameters. NB: not all entities are input and/or output parameters, some of them just describe the situation without being needed for an action. To specify the parameters of all actions, we can create a GBox G as follows:

Definition 1

A GBox is a set of pairs of actions and entities, representing the action parameters where pair is for input parameters and pair is for output parameters.

The action parameters will be important on the Analytical Level since the input parameters are binding the actions, making them executable, while the output parameters are producing the effect, determining the changes in the situations.

In order for an entity to be an input parameter, it must meet the following conditions:

1. ,

2. .

If both conditions hold, we can say GBox . It can be formalized as the following axiom:

10

which says that is connected to a via and there is an starting at and leading to another unknown Situation. This gives us the first criteria for analysing the descriptive completeness of the security policies with respect to the possibility of binding the input parameters of the applicable actions to the descriptions of the situations in which they apply.

In order for an entity to be an output parameter, it must meet the following conditions:

1. ,

2. .

If both conditions hold, we can say GBox . It can be formalized as follows:

11

which says that describes via and leads to after it executes.

Example 2

In Fig. 2 we have a scenario which starts in situation and finishes in after executing and . The two actions have parameters amongst the entities which are present in the corresponding situations. In this case , , , . Amongst the parameters is both input and output parameter of . and simply describe the situations without being needed for actions.

Fig. 2.

A graphical representation of two-step journey

The ontological considerations we have presented so far can be constructed in any variation of DL. Since such a theory can be serialized directly in OWL, the process of developing the ontology can be done entirely interactively using any standard ontology editor, such as Protégé.

Logical Level: Constraints, Dependencies and Domain Policies

In order to describe the logical characteristics of the model, as well as to represent adequately the domain policies controlling the execution of the actions, we can use axioms, rules of inference and heuristic rules. Although DL and CL, as theoretical base of our framework, have well-defined inference mechanisms for practical purposes, it is more convenient to work with derived inference rules rather than the rules of inference within the underlying logic. In this section we will discuss some derived rules of our framework which allow us to automate this process.

Parameter Binding and Entity Completion

To make sure that our KB is descriptively complete, we need to guarantee that it contains all needed information in the TBox (the ontology model) to match the SWRL rules (the policies) so that the policy rules which prescribe actions actually lead to executable actions. In practice this means that all parameters of the actions in the head of the rules must be bound to the situations in which the rules apply. This can be implemented using an algorithm which uses the ontology in the TBox to check if the parameters of the actions prescribed by the rules are defined.

The following derived rule captures the parameters of various events in the situations to prevent the loss of bindings. It is used to implement a “reasoner” which performs a secondary logical inference according to the following schema: Derived Inference Rule 1 (Entity Triangulation). Let the following TBox T be given:

12a

12b

Then the following holds:

13

Proof

The TBox T holds since it states the domain and range of (12a) and (12b) roles which satisfy the axioms 5 and 4 respectively. The same concept Event is used as range of (12a) and as a domain of (12b). Therefore, we can substitute Event in 12a by the right-hand side of 12b to derive . As we can see, Entity is connected to Situation via two roles. We know from Sect. 4.2, this can be done via (axiom 6), therefore, it can be expressed as (13).

   

Transitivity of the Roles and Entity Propagation

The next derived rule reflects the abstract “transitivity” of the logical descriptions within one and the same situation. It can be accounted by another “reasoner” which performs secondary inference according to the following schemas against concept Situation or Event: Derived Inference Rule 2 (Entity Transitivity). Let the following TBox T be given:

14a

14b

Then the following holds:

15

Proof

The TBox T holds since it states the domain and range of describe (14a) and (14b) roles which satisfy the axioms 7 and 6 respectively. The same concept is used as range of describe (14a) and domain of (14b). Therefore, we can substitute in 14a by the right-hand side of 14b to derive . As we can see, is connected to via two roles. Therefore is connected to and we can simply rewrite it as (15).

   

Conceptual Taxonomies and Entity Inheritance

Although the DL allows to automate the subsumption of concepts, we can extend our framework with additional inheritance mechanisms to allow full “parameter inheritance” in the style of object-oriented programming. This is possible because the entities, which are connected to situations or to events, are like the class attributes in object-oriented parlance. It is relatively straightforward to construct algorithmic reasoners which tackle more complex inheritance of entities, along the taxonomic hierarchies of situations and events. Derived Inference Rule 3 (Entity Inheritance). Let the following TBox T be given:

16a

16b

Then the following holds:

17

Proof

The TBox T holds since it states that is a sub-concept of (16a) and is related to via (16b). Therefore, is also related to sub-concept of , which is (17).

   

Frame Problem

In our dynamical model the situations change as a result of the actions. The only way the change from one situation to another situation can affect the descriptions (entities) of the latter situation, is through the output parameters of the actions causing the transition. The specific changes caused by the actions must be specified by the corresponding rules of the security policy. The following two principles allow us to avoid the frame problem by formulating rules according to those principles. They will also guide the changes on the Logical Level.

Principle of Preservation: Any description of the situations within the domain of the action in terms of input parameters remains unchanged.

Principle of Propagation: Any description of the situations within the range of the action in terms of output parameters may change as a result of the action.

Policy Rules

The policies on the Logical Level are rules which link the concepts and roles from the Ontological Level. Such rules have clausal form and can be represented as SWRL expressions (Sect. 3.2). This makes possible the use of the ontological editors like Protégé for modelling of the policies as well.

The policy rules can be modelled as SWRL rules using different templates which combine Situation, Event, Entity and Action atoms in the body and the head of the rule to serve different purposes - for analysis of the situations, making decisions for continuation of the journey, or responding to events. Two such templates are shown below, which can be finely tuned to the particular need of the analysis.

1. 

2. 

In the templates above , , are SWRL classes (which correspond to concepts), is an SWRL object property (which corresponds to role) and they have to be adopted to the specific scenario. Other classes/concepts and object properties/roles do not have to be adopted to the scenario and can be used as it is (, , etc.).

Detailed Example

In this section we will present a more detailed example of the use of our framework for the analysis of a typical online banking transaction. The fragment was built in Protégé 5.1.0 with FaCT++ 1.6.5 reasoner. WebVOWL 1.1.7 was used for visualization of Fig. 3 and Fig. 4 was created using a drawing tool since software to generate these graphs is still in the development stage. Some specifications such as TBox, RBox and some of the named concepts are omitted for the sake of clarity and brevity. The purpose of this example is to illustrate our framework as well as show the interpretation and understanding of it.

Fig. 3.

Example visualization of ontological and logical levels

Fig. 4.

Example visualization of logical and analytical levels

Lets consider the case when transaction is requested: we start in the initial situation ; then there are three possible events which may or may not happen: Overdraft, , . Reaching the final situation will depend on the policy rules expressed in SWRL. Figure 3 shows the interpretation fragment of ontological vocabulary from Ontological Level where yellow arrows represents some of the derived inference rules from Logical Level. Figure 4 visualises SWRL rules on the Logical Level which will be used on the Analytical Level for the analysis. Some of the SWRL rules are as follows:

• 

  

  

  

  

• 

  

  

  

• 

  

  

Although some of the rules may look too complex, most of the literals in it are type checking conditions which can be eliminated from the formulation by adopting a separate type checking algorithm.

Conclusion and Further Work

In this paper we presented ontological and logical considerations of knowledge representation for security analysis of the cyber systems operating in a workflow manner. As well as the processing of transactions in dynamic systems, which involve synchronous and asynchronous activities such as events and actions have been described. We outlined a multi-level framework for representing the ontology and modelling the security policies which enables analysing of some logical problems such as vulnerability analysis and risk assessment. It is entirely based on the use of standard modelling languages of the Semantic Web, which greatly simplifies the implementation, makes it transparent and efficient. Our framework provides a theoretical basis for solving some of the hard problems in modelling dynamic behaviour such as the infamous frame problem. We utilize the concept of state, to provide a proper distinction between the static characteristics of the situations and the possible side effect of the actions on them. We have a pilot implementation, of the framework, written in Java, which makes use of the APIs for OWL and SWRL available in Jena for processing the ontological representation and the security policies in symbolic form [14]. It allows us to perform various logical analytics related to logical vulnerability, risk assessment and policy validation. We are currently use this framework to cross–channel transaction processing, in digital banking, for preventing social engineering fraud.

The semantic and logical considerations discussed above provide the formal ground for formalizing the concepts of accessibility, logical vulnerability and risks. Within our framework this can be done by simulating different scenarios for execution of the actions, under the conditions imposed on the situations and with possibility for events happening in them. Although such an analysis is beyond the scope of this paper, the experiments we conducted using our prototype implementation, have demonstrated that this approach is both transparent and convenient to be used for practical purposes[14].

Currently, we are working on an extension of the framework (to equip it) with risk analysis capabilities, based on the naive Bayesian theory. We are also exploring the potential use of the same framework in other areas, related to workflow control such as production line fault recovery and safety management, like evacuation in the event of fire or other disastrous situations.