ITPolicy Tool

Overview

The main goal of PoSecCo project is the creation of a transparent, reliable and sustainable link between the high-level, abstract and declarative security policies on one side, and the low-level, imperative, and technical security configuration settings on the other side.

This goal will be achieved by creating and maintaining a policy chain. The PoSecCo project will develop models and tools that permit to refine high-level business security requirements into configurations of policy enabled devices and software, and to analyse for conflicts and anomalies each policy abstraction. In this way, PoSecCo will increase and prove system compliance and security at reduced costs. Security requirements for information systems are specified using a number of different levels of abstraction, with different tools and management approaches. At the business level, requirements are often specified using Service Level Agreements (SLA), guidelines, goal definitions; proofs of compliance with a variety of high-level Directives are often needed. Business level requirements have to be mapped to a variety of low-level device-specific configurations, responsible for the enforcement of the policy, and proofs of compliance have to refer to concrete features of the low-level implementation. In most application scenarios, configurations are manually derived by administrators, who are in charge for linking the different abstraction layers. This manual approach has many drawbacks, both in terms of security (incorrect security configurations were responsible for 80 percent of Air Force vulnerabilities) and in terms of the effort required to create the security configuration. Additionally, the integration of the different components and domains is limited and the security management is applied to a set of independent compartments.

The industry is looking for innovative automatic ways to configure security components in large heterogeneous scenarios, becoming able to easily react to changes, thus reducing the management costs (e.g., for new services, new customers, new policies). In PoSecCo the policy chain will be established by a set of refinement processes, that is, tasks able to transform a policy at a given abstraction level to another semantically equivalent policy at a lower abstraction level [20]. Together with the refinement processes PoSecCo will provide a set of techniques to check the correctness of the policy at each abstraction level. The component in charge to create the IT Policy and link it to (a) the business level and (b) the landscape level is the IT Policy Tool (see Figure below).

The main role of the IT Policy Tool is to assist the user during the specification of the IT Policy. It also provides an easy way to introduce a link between different elements located at different levels of the PoSecCo architecture.

The IT Policy Tool also permits to create an ontological representation of the IT Policy. Through this representation, the tool allows the user to execute checks thanks to the use of reasoning services.

The tool offers to the designer the possibility to efficiently describe large systems and rely on well understood and verifiable security properties for open, dynamic environments, which require coordination across multiple organizations and integration of different data formats.

Technology

Eclipse

Eclipse is the most significant open source application development framework, offering a high degree of flexibility and supporting the extension of its functionality through the implementation of plugins. The Eclipse platform encourages the reuse of the functions of other plugins and modules of the Eclipse framework, speeding up and improving the quality of the development process. The choice of an Eclipse plugin to support the creation of the IT Policies is due to the fact that the services offered by Eclipse to support the construction of a large software system can be immediately adapted to the design of a complex IT Policy. In both scenarios, there is the need to offer rich editing and exploration support over information that describes a multiplicity of instances that follow a prescribed syntax and have a number of relationships among them. Eclipse

Extension points

A modular software architecture requires a loose coupling between the components of the architecture itself. One of the ways in which the Eclipse platform aims at achieving this loose coupling is through the mechanism of extensions and extension points.

A plug-in that wants to allow other components to contribute to its functionalities can define an extension point. The plug-in that defines the extension point defines the contract, which usually consists of XML files and Java interfaces, that any contributing plug-in has to satisfy in order to contribute to the functionalities. The defining plug-in knows nothing about the plug-ins that relates with the functionalities, which guarantees a low level of coupling between the components.
The plug-in that wants to contribute with new functionalities has to define an extension point that satisfies the contract.

OWL API

The integration with the tools managing the ontological aspects is implemented within the plug-in through the latest version (3.2) of OWL API. OWL API has been designed to meet the needs of programmers developing OWL based applications, OWL editors and OWL reasoners. It is a high level API which is closely aligned with the OWL 2 specification. It includes first class change support, general purpose reasoner interfaces, validators for the various OWL profiles, and support for parsing and serializing ontologies in a variety of syntaxes. The API also has a flexible design that allows third parties to provide alternative implementations for all the major components.

The current version of OWL API provides a suite of interfaces along with a reference implementation that facilitates the use of OWL in a wide variety of applications. At its core, the OWL API consists of a set of interfaces for inspecting, manipulating and reasoning with OWL ontologies. The OWL API supports loading and saving ontologies in a variety of syntaxes. However, none of the model interfaces in the API reflect, or are biased to any particular concrete syntax or model. For example, unlike other APIs such as Jena, or the Protégé 3.X API, the representation of class expressions and axioms is not at the level of RDF triples. Indeed, the design of the OWL API is directly based on the OWL 2 Structural Specification.

Reasoner

A key benefit of the OWL representation is the ability to support reasoning. Reasoners are used to check the consistency of ontologies, check to see whether the signature of an ontology contains unsatisfiable classes, compute class and property hierarchies, and check to see if axioms are entailed by an ontology. The OWL API has various interfaces to support the interaction with OWL reasoners. A reasoner is a key component for working with OWL ontologies. In fact, virtually all querying of an OWL ontology (and its imports closure) should be done using a reasoner. This is because knowledge in an ontology might not be explicit and a reasoner is required to deduce implicit knowledge so that the correct query results are obtained. At the time of writing, FaCT++, HermiT, Pellet, and Racer Pro reasoners provide OWL API wrappers. In the PoSecCo IT Policy Tool we use HermiT as reasoner. HermiT is a publicly-available OWL reasoner based on a ”hypertableau” calculus, which provides more efficient reasoning than many other algorithms. This performance gain is important for PoSecCo, which may have to manage policies containing a large number of elements.

Semantic Web Rule Language

Semantic Web Rule Language (SWRL) was designed to be the rule language of the Semantic Web. SWRL is based on a combination of the OWL DL and OWL Lite sublanguages of the Web Ontology Language (OWL), the Unary/Binary Datalog sublanguages of the Rule Markup Language. SWRL allows users to write Horn-like rules expressed in terms of OWL concepts to reason about OWL individuals. The rules can be used to infer new knowledge from the existing OWL knowledge bases. The SWRL Specification does not impose restrictions on how reasoning should be performed with SWRL rules. In this way, SWRL provides a convenient starting point for integrating rule systems to work with the Semantic Web.
SWRL rules are written as antecedent / consequent pairs. In SWRL terminology, the antecedent is referred to as the rule body and the consequent is referred to as the head. The head and body consist of a conjunction of one or more atoms. The intended meaning is consistent with the classical semantics that characterizes most rule paradigms: whenever the conditions specified in the antecedent hold, then the conditions specified in the consequent must also hold. Thanks to the introduction of these rules, the verification process of the model can be automated. The use of SWRL offers interesting opportunities in the PoSecCo context and is well supported by the reasoners.

Simple Protocol And RDF Query Language - Description Logic

Another common extension to DL engines is the ability to execute queries against the semantic model. Simple Protocol And RDF Query Language - Description Logic (SPARQL-DL) is a graph-matching query language. Given a data source D, a query consists of a pattern which is matched against D, and the values obtained from this matching are processed to give the answer. The data source D to be queried can be composed of multiple sources. SPARQL-DL is a distinct subset of the most famous Simple Protocol And RDF Query Language (SPARQL).

SPARQL-DL supports two different types of query: ASK and SELECT. An ASK-query returns a Boolean result, whereas a SELECT-query returns all possible bindings of the provided variables. As within SPARQL, the DISTINCT keyword removes automatically all redundant bindings within the result set.