# Ontological Foundations of Modelling Security Policies for Logical Analytics

Karolina Bataityte, Vassil Vassilev, Olivia Jo Gill

► To cite this version:

Karolina Bataityte, Vassil Vassilev, Olivia Jo Gill. Ontological Foundations of Modelling Security Policies for Logical Analytics. 16th IFIP International Conference on Artificial Intelligence Applications and Innovations (AIAI), Jun 2020, Neos Marmaras, Greece. pp.368-380, 10.1007/978-3-030-49161-1_31. hal-04050596

HAL Id: hal-04050596

https://inria.hal.science/hal-04050596

Submitted on 29 Mar 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Ontological Foundations of Modelling Security Policies for Logical Analytics*

Karolina Bataityte<fnref n="1" />, Vassil Vassilev<fnref n="2" />, and Olivia Jo Gill<fnref n="1" />

**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.

**Keywords:** Security Policies, Modelling, Ontologies, Knowledge Representation, Situations and Actions, Frame Problem

## 1 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,

<footnote n="1">¹ School of Computing, London Metropolitan University, London, UK</footnote>

<footnote n="2">² Cyber Security Research Centre, London Metropolitan University, London, UK
{k.bataityte,v.vassilev,o.gill}@londonmet.ac.uk</footnote>

<footnote>* This research is partially funded by Lloyds Banking Group in London, UK. However, no actual data from the bank has been used, the results and the opinions formulated in the paper are the author's and the examples are for illustration purpose only, without any resemblance to the actual banking policies and practices.</footnote>
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 Section 2 we will present the overall methodology which we follow. In Section 3 we will present logical foundations. In Section 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.

## 2 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., [9], [4]). 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].

<figure><img src="image_2.png" /><figcaption>Fig. 1. Multi-level Model for Analysis</figcaption></figure>

The Ontological Level models the world using the vocabulary presented in Section 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.
# 3 Logical Foundations

For developing of the theory of situations and actions we consider DL called *ALC* [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 *ALC* 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.

## 3.1 Description Logic *ALC* as a Modelling Language

The syntax and the semantic interpretation is shown in Table 1. The interpretation *I* is a pair *I* = (Δ<sup>*I*</sup>, ⋅<sup>*I*</sup>), where Δ<sup>*I*</sup> is a non-empty set (domain) and ⋅<sup>*I*</sup> is a mapping function [12].

<table><caption>**Table 1.** Syntax and Semantics</caption><thead><tr><th colspan="2">Concepts</th><th colspan="2">Roles</th></tr><tr><th>Syntax</th><th>Semantics</th><th>Syntax</th><th>Semantics</th></tr></thead><tbody><tr><td>⊤</td><td>Δ<sup>I</sup></td><td>R</td><td>R<sup>I</sup> ⊆ Δ<sup>I</sup> × Δ<sup>I</sup></td></tr><tr><td>⊥</td><td>∅</td><td>Domain(R, C) &lt; a, b &gt; ∈ R<sup>I</sup> → a ∈ C<sup>I</sup></td><td></td></tr><tr><td>A</td><td>A<sup>I</sup> ⊆ Δ<sup>I</sup></td><td>Range(R, C) &lt; a, b &gt; ∈ R<sup>I</sup> → b ∈ C<sup>I</sup></td><td></td></tr><tr><td>¬C</td><td>Δ<sup>I</sup> \ C<sup>I</sup></td><td></td><td></td></tr><tr><td>C ∩ D</td><td>C<sup>I</sup> ∩ D<sup>I</sup></td><td></td><td></td></tr><tr><td>C ∪ D</td><td>C<sup>I</sup> ∪ D<sup>I</sup></td><td></td><td></td></tr><tr><td>∀R.C {a ∈ Δ<sup>I</sup> | ∀b.(< a, b &gt; ∈ R<sup>I</sup> → b ∈ C<sup>I</sup>))}</td><td></td><td></td><td></td></tr><tr><td>∃R.C {a ∈ Δ<sup>I</sup> | ∃b.(< a, b &gt; ∈ R<sup>I</sup> ∧ b ∈ C<sup>I</sup>))}</td><td></td><td></td><td></td></tr></tbody></table>

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 *I* |= α. We will be expressing the domain restrictions as ∃R.⊤ ⊑ C and the range restrictions as ⊤ ⊑ ∀R.C [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.

## 3.2 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: K = (Σ, R) where Σ is KB of *ALC* and R is set of rules. The rule is composed of *body* and *head* which is represented as following: *body* → *head*. It consists of a conjunctions of atoms
which are classes *C(i)* (concepts in *ALC*) and object properties *R(i,j)* (roles in *ALC*) [6].

# 4 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.

## 4.1 Terminological Vocabulary

In our ontology the semantic domain, Δ, is a non-empty set, split into three disjoint subdomains: **Entities**, **Events** and **Situations** (plural) as Δ<sub>Entities</sub>, Δ<sub>Events</sub> and Δ<sub>Situations</sub> 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 *ALC* concepts in the domain are as follows: *Entity*<sup>I</sup> ⊆ Δ<sub>Entities</sub><sup>I</sup>, *Event*<sup>I</sup> ⊆ Δ<sub>Events</sub><sup>I</sup> and *Situation*<sup>I</sup> ⊆ Δ<sub>Situations</sub><sup>I</sup>. Our terminology (Table 2) will also include some predefined roles, one of them is *Action* (*Action*<sup>I</sup> ⊆ Δ<sub>Situations</sub><sup>I</sup> × Δ<sub>Situations</sub><sup>I</sup>), 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 *Entity<sub>x</sub>*), *Situation<sub>y</sub>*), *Event<sub>e</sub>*), *Action<sub>z</sub>*), with the intended meaning and interpretations in the semantic subdomains introduced above in accordance with the syntax and semantics of *ALC* as presented in Section 3.1. Concepts from three subdomains must be disjoint as follows:

$$ \text{Situation} \sqcap \text{Event} \sqsubseteq \perp, \text{Situation} \sqcap \text{Entity} \sqsubseteq \perp, \text{Entity} \sqcap \text{Event} \sqsubseteq \perp. \quad (1) $$

<table><caption>**Table 2.** Vocabulary of the Domain Ontology</caption><thead><tr><th>Term</th><th>DL Category</th><th>Use in modelling</th><th>Condition</th></tr></thead><tbody><tr><td>Situation</td><td>concept</td><td>partial static description of the world</td><td>axiom 1</td></tr><tr><td>Event</td><td>concept</td><td>asynchronous activity</td><td>axiom 1</td></tr><tr><td>Entity</td><td>concept</td><td>qualitative descriptor</td><td>axiom 1</td></tr><tr><td>Action</td><td>role</td><td>synchronous activity</td><td>axiom 2</td></tr><tr><td>occur-in</td><td>role</td><td>event occurrence</td><td>axiom 4</td></tr><tr><td>present-at</td><td>role</td><td>situation description</td><td>axiom 6</td></tr><tr><td>part-of</td><td>role</td><td>event description</td><td>axiom 5</td></tr><tr><td>describe</td><td>role</td><td>describing entities and specifying dependencies</td><td>axiom 7</td></tr><tr><td>chain</td><td>role</td><td>connecting events causally</td><td>axiom 3</td></tr></tbody></table>

On the ontological level we are using the *ALC* TBox for formulating the terminological axioms and the RBox for the relational axioms, while the ABox will incorporate the assertions later on.
## 4.2 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:

$$ \exists Action. \top \sqsubseteq Situation, \top \sqsubseteq \forall Action.Situation \quad (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 occur-in 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.

$$ \exists chain. \top \sqsubseteq Event, \top \sqsubseteq \forall chain.Event \quad (3) $$

$$ \exists occur-in. \top \sqsubseteq Event, \top \sqsubseteq \forall occur-in.Situation \quad (4) $$

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

$$ \exists part-of. \top \sqsubseteq Entity, \top \sqsubseteq \forall part-of.Event \quad (5) $$

$$ \exists present-at. \top \sqsubseteq Entity, \top \sqsubseteq \forall present-at.Situation \quad (6) $$

$$ \exists describe. \top \sqsubseteq Entity, \top \sqsubseteq \forall describe.Entity \quad (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

## 4.3 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:

$$T := \{Entity_x \sqsubseteq Entity, Situation_y \sqsubseteq Situation\} \qquad (8)$$

and Entity_x describe Situation_y, T is extended as follows:

$$T' := T \cup \{Entity_x \sqsubseteq \exists present-at.Situation_y\}. \qquad (9)$$

*Example 1.* Let's consider the situation LoggedIn and the entity User. For this scenario the TBox T is as follows:

$$T := \{User \sqsubseteq Entity, LoggedIn \sqsubseteq Situation, User \sqsubseteq \exists present-at.LoggedIn\}$$

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 G = {⟨Entity_x, Action_z⟩, ⟨Action_z, Entity_y⟩} is a set of pairs of actions and entities, representing the action parameters where pair ⟨Entity_x, Action_z⟩ is for input parameters and pair ⟨Action_z, Entity_y⟩ 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. $\exists Action_z. T \sqsubseteq Situation_x$,

2. $Entity_x \sqsubseteq \exists present-at.Situation_x$.

If both conditions hold, we can say GBox G = {⟨Entity_x, Action_z⟩}. It can be formalized as the following axiom:

$$Entity_x \sqsubseteq \exists present-at.(Situation_x \sqcap \exists Action_z. T) \qquad (10)$$

which says that Entity_x is connected to a Situation_x via present-at and there is an Action_z starting at Situation_x 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. $T \sqsubseteq \forall Action_z.Situation_y$,

2. $Entity_x \sqsubseteq \exists present-at.Situation_y$.

If both conditions hold, we can say GBox G = {⟨Action_z, Entity_x⟩}. It can be formalized as follows:

$$Entity_x \sqsubseteq \exists present-at.\exists Action_z.Situation_y \qquad (11)$$

which says that Entity_x describes Situation_y via present-at and Action_z leads to Situation_y after it executes.
*Example 2.* In Fig. 2 we have a scenario which starts in situation *Situation*₁ and finishes in *Situation*₃ after executing *Action*₁ and *Action*₂. The two actions have parameters amongst the entities which are present in the corresponding situations. In this case *G* = {*⟨Entity*₂, *Action*₁⟩, *⟨Action*₁, *Entity*₃⟩*, *⟨Action*₁, *Entity*₄⟩*, *⟨Entity*₄, *Action*₂⟩*}. Amongst the parameters *Entity*₄ is both input and output parameter of *Action*₂. *Entity*₁ and *Entity*₅ simply describe the situations without being needed for actions.

<figure><img src="image_3.png" /><figcaption>Fig. 2. A graphical representation of two-step journey</figcaption></figure>

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é.

# 5 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.

## 5.1 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:
$$ 
\begin{array}{l}
Entity \sqsubseteq \exists part-of.Event \\
Event \sqsubseteq \exists occur-in.Situation \\
\therefore Entity \sqsubseteq \exists present-at.Situation
\end{array}
$$

**Derived Inference Rule 1 (Entity Triangulation).** Let the following TBox T be given:

$$ T := \{Entity \sqsubseteq \exists part-of.Event, \quad (12a) $$

$$ Event \sqsubseteq \exists occur-in.Situation \} \quad (12b) $$

Then the following holds:

$$ T' := T \cup \{Entity \sqsubseteq \exists present-at.Situation\}. \quad (13) $$

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

## 5.2 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*:

$$ 
\begin{array}{l}
Entity_y \sqsubseteq \exists describe.Entity_x \\
Entity_x \sqsubseteq \exists present-at.Situation_x \\
\therefore Entity_y \sqsubseteq \exists present-at.Situation_x \quad \therefore Entity_x \sqsubseteq \exists present-at.Event_z
\end{array}
$$

**Derived Inference Rule 2 (Entity Transitivity).** Let the following TBox T be given:

$$ T := \{Entity_y \sqsubseteq \exists describe.Entity_x, \quad (14a) $$

$$ Entity_x \sqsubseteq \exists present-at.Situation_x \} \quad (14b) $$

Then the following holds:

$$ T' := T \cup \{Entity_y \sqsubseteq \exists present-at.Situation_x\}. \quad (15) $$

*Proof.* The TBox T holds since it states the domain and range of *describe* (14a) and *present-at* (14b) roles which satisfy the axioms 7 and 6 respectively. The same concept *Entity_x* is used as range of *describe* (14a) and domain of *present-at* (14b). Therefore, we can substitute *Entity_x* in 14a by the right-hand side of 14b to derive *Entity_y* $\sqsubseteq \exists describe.\exists present-at.Situation_x$. As we can see, *Entity_y* is connected to *Situation_x* via two roles. Therefore *Entity_y* is connected to *Situation_x* and we can simply rewrite it as *Entity_y* $\sqsubseteq \exists present-at.Situation_x$ (15). □
## 5.3 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.

$$ \begin{array}{ccc} \text{Situation}_y \sqsubseteq \exists \text{Situation}_x & \text{Event}_y \sqsubseteq \exists \text{Event}_x & \\ \underline{\text{Entity}_x \sqsubseteq \exists \text{present-at}.\text{Situation}_x} & \underline{\text{Entity}_x \sqsubseteq \exists \text{present-at}.\text{Event}_x} & \\ \therefore \text{Entity}_x \sqsubseteq \exists \text{present-at}.\text{Situation}_y \quad \therefore \text{Entity}_x \sqsubseteq \exists \text{present-at}.\text{Situation}_y & & \\ \end{array} $$

**Derived Inference Rule 3 (Entity Inheritance).** Let the following TBox T be given:

$$ T := \{\text{Situation}_y \sqsubseteq \text{Situation}_x, \qquad (16a) $$

$$ \underline{\text{Entity}_x \sqsubseteq \exists \text{present-at}.\text{Situation}_x} \qquad (16b) $$

Then the following holds:

$$ T' := T \cup \{\text{Entity}_x \sqsubseteq \exists \text{present-at}.\text{Situation}_y\}. \qquad (17) $$

*Proof.* The TBox T holds since it states that Situation_y is a sub-concept of Situation_x (16a) and Entity_x is related to Situation_x via present-at (16b). Therefore, Entity_x is also related to sub-concept of Situation_x, which is Situation_y (17). □

## 5.4 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.

## 5.5 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 (Section 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. $situation_i(?sa) \wedge entity_k(?ia) \wedge present-at(?ia, ?sa) \wedge \dots \wedge action_n(?sa, ?sb) \rightarrow situation_j(?sb) \wedge entity_l(?ib) \wedge present-at(?ib, ?sb) \wedge \dots$

2. $situation_i(?sa) \wedge entity_k(?ia) \wedge present-at(?ia, ?sa) \wedge event_l(?ea) \wedge occur-in(?ea, ?sa) \wedge \dots \wedge entity_k(?ib) \wedge part-of(?ib, ?ea) \wedge \dots \wedge action_n(?sa, ?sb) \rightarrow situation_j(?sb) \wedge entity_k(?ic) \wedge present-at(?ic, ?sb) \dots$

In the templates above $situation_i(?s)$, $entity_k(?en)$, $event_l(?ev)$ are SWRL classes (which correspond to *ALC* concepts), $action_n(?sa, ?sb)$ is an SWRL object property (which corresponds to *ALC* 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 ($present-at(?ib, ?sb)$, $occur-in(?ea, ?sa)$, etc.)

## 5.6 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.

Lets consider the case when transaction is requested: we start in the initial situation *S_TransactionRequested*; then there are three possible events which may or may not happen: *E_AccountIn Overdraft*, *E_MaxOverdraftReached*, *E_AccountOverloaded*. Reaching the final situation will depend on the policy rules expressed in SWRL. Fig. 3 shows the interpretation fragment of ontological vocabulary from Ontological Level where yellow arrows represents some of the derived inference rules from Logical Level. Fig. 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:

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Example Visualization of Ontological and Logical Levels</figcaption></figure>
<figure><img src="image_5.png" /><figcaption>Fig. 4. Example Visualization of Logical and Analytical Levels</figcaption></figure>

- $S\_TransactionRequested(?sa) \land Balance(?ix) \land present\_at(?ix, ?sa) \land TransactionAmount(?it) \land present\_at(?it, ?sa) \land E\_AccountInOverdraft(?ea) \land occur - in(?ea, ?sa) \land OverdraftAmount(?io) \land part\_of(?io, ?ea) \land present\_at(?io, ?sa) \land A\_TransactionApproved(?sa, ?sb) \rightarrow Balance(?iy) \land S\_TransactionExecuted(?sb) \land present\_at(?iy, ?sb)$

- $S\_TransactionRequested(?sa) \land Balance(?ix) \land TransactionAmount(?it) \land present\_at(?ix, ?sa) \land present\_at(?it, ?sa) \land E\_MaxOverdraftReached(?eb) \land occur\_in(?eb, ?sa) \land A\_TransactionDeclined(?sa, ?sb) \rightarrow S\_TransactionRejected(?sb)$

- $S\_TransactionRequested(?sa) \land Balance(?ix) \land present\_at(?ib, ?sa) \land TransactionAmount(?it) \land present\_at(?it, ?sa) \land E\_AccountOverloaded(?eb) \land occur\_in(?eb, ?sa) \land A\_AccountSuspended(?sa, ?sb) \rightarrow S\_AccountBlocked(?sb)$

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.

## 6 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.

References

1. Baader, F., Lutz, C., Miličic, M., Sattler, U., Wolter, F.: Integrating description logics and action formalisms: First results. In: Proc. of the 20th National Conference on Artificial Intelligence. pp. 572–577. AAAI’05, AAAI Press (2005)

2. Chang, L., Lin, F., Shi, Z.: A dynamic description logic for representation and reasoning about actions. In: KSEM (2007)

3. Eric Jizba, Yan Chen, F.S.G.P.: Web logic vulnerability, https://users.cs.northwestern.edu/~ychen/classes/cs450-s14/lectures/Web%20Logic%20Vulnerability.pdf, [Online; accessed January-2020]

4. Granadillo, G., Ben Mustapha, Y., Hachem, N., Debar, H.: An ontology-driven approach to model siem information and operations using the swrl formalism. International Journal of Electronic Security and Digital Forensics 4, 104–123 (2012)

5. Hitzler, P., Krötzsch, M., Rudolph, S.: Foundations of Semantic Web Technologies. Chapman & Hall/CRC (2009)

6. Lawan, A., Rakib, A.: The semantic web rule language expressiveness extensions-a survey (03 2019)

7. McCarthy, J., Hayes, P.: Some philisophical problems from the standpoint of artificial intelligence. In: Machine Intelligence, vol. 4, pp. 463–502. Edinburgh University Press, Edinburgh, UK (1969)

8. Passin, T.B.: The Explorer's Guide to the Semantic Web. Manning Publications (2004)

9. Pereira, T., Santos, H.: An ontology based approach to information security. pp. 183–192 (01 2009)

10. Reiter, R.: Knowledge in Action: Logical Foundations for Specifying and Implementing Dynamical Systems. MIT Press (2001)

11. Sánchez, D., Cavero, J.M., Marcos Martnez, E.: The Road Toward Ontologies, vol. 14, pp. 3–20. Springer US (2007)

12. Szeredi, P., Lukácsy, G., Benkő, T.: The Semantic Web Explained: The Technology and Mathematics Behind Web 3.0. Cambridge University Press, New York, NY, USA (2014)

13. Tsarkov, D., Horrocks, I.: Efficient reasoning with range and domain constraints. In: Proc. of the 2004 International Workshop on Description Logics (DL2004) (2004)

14. Vassilev, V., Sowinski-Mydlarz, V., Gasiorowski, P., Ouazzane, K., Phipps, A.: Intelligence graphs for threat intelligence and security policy validation of cyber systems. In: Proc. Int. Conf. on Artificial Intelligence and Applications (ICAIA2020). Advances in Intelligent Systems and Computing, Springer (2020)