A Semantic Approach to Reachability Matrix Computation Nicole Dalia Cilia Noemi Scarpato Marco Romano Dept. of Philosophy, University Telematica San Raffaele Sapienza University of Rome, Epistematica S.r.l. RomaVia di Val Cannuta,247 Rome, Via Carlo Fea 3, Rome, Italy, Via Ostiglia 10, 20133, Milano, Italy, Italy, nicole.cilia@uniroma1.it m.romano@epistematica.com noemi.scarpato@unisanraffaele.gov.it Abstract— The Cyber Security is a crucial aspect of networks generalized approach for cyber security domain. We propose management. The Reachability Matrix computation is one of the a semantic approach that applying the formalism of main challenge in this field. This paper presents an intelligent Description Logics [1] to the Cyber Security domain. solution in order to address the Reachability Matrix computational problem. Following we describe the Reachability Matrix Correlator (RMC) component, the Reachability Matrix Ontology (RMO) Keywords— CyberSecurity;Ontologies; Reasoning. and the reasoning task. RMC provides algorithms for computing reachability information. RMO describes the Cyber I. INTRODUCTION Security domain. Reasoning task uses the RMO ontology in In this paper we describe our contribute in the order to compute the Reachability Matrix. Our approach PANOPTESEC1 project. PANOPTESEC aims to deliver foresees that RMC populates the RMO with input data beyond-state-of-the-art prototype of a cyber defence decision provided by PANOPTESEC Data Collection and Correlation support system, demonstrating the benefit of a risk based system (see section II and III for more details) and applies a approach to automated cyber defence. PANOPTESEC takes set of SWRL rules and SPARQL queries to compute the into account of the dynamic nature of information and Reachability Matrix (see section IV for more details). communications technologies (ICT) and of the constantly Reachability Matrix is employed in PANOPTESEC to evolving capabilities of cyber attackers in order to propose a determine if a node can reach another node (via ISO/OSI layer solution based on knowledge representation and reasoning. protocols), this information is crucial to risk management. Recently, various studies provided progress in the Cyber II. REACHABILITY MATRIX CORRELATOR Defence domain with data models and methods to focus the As shown in Fig. 1 the PANOPTESEC architecture security problem in large networks. Morin et al. [1] have includes: Visualization System, data Collection and provided “a data model for security systems to query and Correlation System, Dynamic Risk Management System, assert knowledge about security incidents and the context in Integration Framework and Monitored System. The Data which they occur. This model constitutes a consistent and Collection and Correlation System (DCC) has the goal of formal that an organization implements with an ICT system”. providing suitable data to all other components required for In order to better assess the effect of countermeasures to building a cyber-security protection system. The Reachability cyber-attacks and better rank countermeasures, Matrix Correlator component is part of the Data Collection PANOPTESEC provides a list of requirements for a system and Correlation System. for mission impact assessment. Information about ICT assets The role of DCC in the PANOPTESEC project is to and their vulnerabilities is used in order to compute known develop a data collection and a correlation engine for building ways to attack a system (so-called attack graphs). Reachability an advanced cyber-security maintenance system. Matrix is the input for the Attack Graph Generator. The PANOPTESEC approach to cyber-security maintenance The Data Collection and Correlation System, which also support is based on a model of relations between business contains a model for describing the impact of cyber-attacks as services and the supporting ICT assets. Business services well as corresponding countermeasures (based on a mission represent the mission assessment. Information about ICT model), will provide the necessary input for other components assets and their vulnerabilities is used in order to compute of PANOPTESEC. DCC is composed by five main known ways to attack a system (so-called attack graphs). components: Data Collection Interface, Data Collection Reachability Matrix is the input for the Attack Graph Collector, Low-Level Correlator, Reachability Matrix Generator. Correlator and Mission Impact Module (see Fig. 1). The DCC module needs to avoid duplicate data handling and complex The scope of this paper encompasses data collection and synchronization principles. RMC provides the reachability correlation for the ACEA use case, but also provides a matrix, useful for the Attack Graph Generation component of 1 http://www.panoptesec.eu/ STIDS 2015 Proceedings Page 91 Fig. 1: PANOPTESEC global architecture and logical data flows. the Dynamic Risk Management Response System. The might be reachable, but this reachability does not reachability information are used to determine if a node can allow an adversary to progress further in a network. reach another node (via ISO/OSI layer protocols). - identify physical entities responsible for a RMC performs the reachability computation across the reachability. Identify hardware entities, e.g. Firewalls, monitored ICT network to deduct if two nodes are reachable Switches, Routers, that route a reachability on a from each other in the network, for all pairs of nodes physical level. A logically non-existing hardware, e.g. representing ICT devices. To achieve the RMC goal we need a switch, but itself be prone to vulnerabilities, which to produce an abstract machine-readable representation of the might allow an adversary to broaden a reachability. knowledge, the RMO (see next section for details). As shown in Fig. 2 RMO is imported from an external file and stored in - consider that a node might be known via multiple the Graph Database Sesame [2] by the T-Box Loader, this addresses To identify a reachability on a logical level operation happens once at the initialization of the RMC and between unique devices in a subnetwork, entities successively only if RMO is changed. Then A-Box Loader might be addressed (e.g. IP) in another way, than from outside the subnetwork. populates the RMO with the information regarding the Network Inventory, Deploy Access Control Policy and The requirements presented are secondary to: Mitigation Action. Finally the reachability correlation engine computes the Reachability Matrix using information stored a) Identifying and defining an adequate representation into Knowledge Base. of knowledge (ontology), the proper Knowledge Base and the appropriate Knowledge Repository [2] to store the Knowledge The RMC must: Base, - determine if a node is reachable from another node on b) Defining a proper mode to populate the Knowledge a logical level. To provide at a logical level if a node Base. can be reached from another node If in a network a node is reachable from another node, there is a Several tasks are needed to achieve the RMC goal: possibility that an adversary might be able to infiltrate a) To study and produce a correct representation of the a network further. Such information is gatherable problem, using the most suitable available methods. from, e.g., Firewall Rules, Mapping Rules, Firewall Logs and/or Traffic Captures. b) To perform applied research to determine the optimum methods to solve automatically the problem. - determine reachability in terms of Source-Port, Target-Port, Protocol to obtain a detailed view of c) To guarantee that the representation of the reachability in a network and provide the most knowledge, the representation of the problem and the solving available information if a node is reachable over a method are abstract enough to be independent of any specific specific port and protocol, there might exist commercial networking devices or applications. vulnerabilities in such a protocol. Further a node STIDS 2015 Proceedings Page 92 Fig. 2: Component View: Reachability Matrix Correlator (Internal Blocks Diagram) d) To integrate the available tools and methods into a • Able to represent Deployed Mitigation Actions. running prototype correlator that produces the correct Reachability Matrix. In order to design RMO used within the RMC component, we faced a thorough and deep study of IP networks in order to e) To guarantee that the IT services provided by the identify all objects that come into play in such a domain, with Correlator are be aligned to the needs of the Attack Graph all their characteristics, the relationships between them, and Generation component of the Dynamic Risk Management the role each element plays in successful communications over Response System . IP networks. This study has gone in parallel with the analysis of the Data Model that we have been provided with, with f) To guarantee the compatibility of the technical special regards for the schemas concerning the Network solution with the overall PANOPTESEC system Inventory and the Deployed Access Policies (which are g) To guarantee that the technical implementation of the basically the format of the data incoming into our component solution within PANOPTESEC system is performing at an as its input), and the schema for the Reachability Matrix which acceptable service level for a prototype within the project determines the format for the data that exits our component. scope and quality requirements. The resulting knowledge representation, which is an OWL III. THE KNOWLEDGE BASE [4] ontology, provides a reconciled vision of these partial Data Models, in such a way that the ontology has “room” enough to As mentioned above RMO ontology [3] represents receive all data from Network Inventory (and the other input connectivity, Network Inventory, Access Control Policy and files about routing tables, firewall rules and NAT rules) so as Mitigation Actions. RMO has the following characteristics: to compose a Knowledge Base (static T-box, plus the A-box • Capable of representing all kind of ICT devices, reloaded over time), and to re-model the data so as to fit the including terminal machines, output data format required by the Reachability Matrix data model. Of course, input and output formats described in the It • Able to represent connectivity including sub-netting, Data Model do overlap, since are different views of the same • Able to describe ICT devices grouping, according to matter. More precisely, the output that we produce contains a filtering rules in machines, subset of all the information which is in the input that we receive, but enriched with some “new” information. • Capable of representing gateways and firewalling rules, This is the information made explicit by automatic reasoning, thanks to the “logical embedding” of the additional • Having the capacity to represent connectivity knowledge about the functioning of IP networks (derived from between every kind of nodes in the ICT network, our initial study) that is recorded in the ontology (in particular • Able to represent Deployed Access Control Policy in the T-box). While designing the ontology, the classes Rules, described in the Data Model schemas, with all their attributes, needed to be re-modelled to fit the different representation STIDS 2015 Proceedings Page 93 paradigm of ontologies. The most typical cause of intervention The rules provided along with our ontology describe is the need to distinguish objects - and their relationships with all possible scenarios to be investigated in order to detect all other objects (possibly with different types of objects) - from the nodes that are reachable from any given couple made of a simple values that express attributes of the objects (sort of node (with its specific routing instructions) and any of its terminal, minimal points of information about which is not network interfaces (connected each to one particular network). possible to say anything else). Briefly, at the present stage of development, the ontology has an expressivity well within The first rule covers the case of all reachable nodes within OWL-DL [4] expressivity (allowing for good performance of the same domain to which a given node belongs. The second reasoning). It counts with 37 named classes (i.e. concepts in rule covers the case of all reachable nodes within some known the ontology T-box) that collect the objects accounted for in networks for which special routing instructions are given. The the Network Inventory and the other input files. There also 37 third rule covers the case of all other networks not known in different relationships (object properties according to the advance, yet reachable through a series of “hops” to default OWL terminology) to represent the possible relationships gateways. Though absolutely necessary, the fourth rules does among the objects of this classes, and other 55 (datatype) not cover any special case. It only enforces the reasoning in properties to account for all other characteristics of the such a way that the transitivity of the relevant relationships (object properties in the ontology describing the functioning of objects. “hopping” through gateways) is properly taken into account The most important part for the function of our module by the reasoner [6]. The execution of the reasoning based on (which at present is focused on reachability at the layer 3 of all the information within the Knowledge Base and the four the OSI model) is the part that accounts for: nodes SWRL rules, allows to produce the set of all pairs made of a identification, network interfaces, network they belong to, and network interface and the nodes it can reach (discovered by routing instructions to reach other networks, i.e. the routes and looking at every network interface of a node, its direct the complex information to describe them: the source connections and the routing instructions given to the node it (node&interface), the destination (network), and the gateway belongs to). Here we have all information needed to produce to pass through. Besides the classes that collect the objects of the reachability matrix (as it is at present stage, at layer 3 of these various types, a set of 12 object properties allow to the OSI model). logically model the reachability between nodes. These (object) properties deal with: Last step to produce our output – the Reachability Matrix – for use on the part of the other components is to explicitly - the network interfaces belonging to some node point out, for each network interface of any given node, the set of all and only the other nodes that it can reach. However, this - the network that each interface is connected to is not properly speaking reasoning, since it is just retrieval of - and, as a consequence, the networks that a node triples (the form in which data are declared in OWL), and it is belongs to. achieved by firing some SPARQL [7] queries (actually embedded in the APIs [8] of the persistence environment that But also they deal with the other networks that can be we adopt). Other similar queries retrieve the rest of reached by passing through one or more gateways, based on information that is available in the Knowledge Base and is routing instructions. Finally, a set of 4 SWRL [5] (Semantic expected in the Reachability Matrix according to the output Web Rule Language) rules “force” the reasoner [6] to format. compute, for every interface of a node, every other node it can reach to (further details on this regard in the next section). V. ACKNOWLEDGEMENTS IV. ABOUT THE REASONING This paper has been supported by Epistematica (http://www.epistematica.com/) within the PANOPTESEC The very first reasoning service used with regard to our project. ontology is the consistency check of the T-box, which is run at the design time of the ontology. Of course, the ontology REFERENCES passed this check. Subsequent check is the validation of the [1] Morin, B, L Mé, H Debar, M Ducassé (2009). A logic-based model to entire knowledged base. Once the A-box is loaded along with support alert correlation in intrusion detection . Information Fusion, 10 the T-box, and the whole KB is loaded into the framework of (4), 285-299. our component, this second service checks whether the A-box [2] Sesame (http://rdf4j.org/). – produced based on the input data (Network Inventory and [3] Gruber, T. R. (1995). Toward principles for the design of ontologies used for knowledge sharing?. International journal of human-computer other files) – is consistent with respect to the T-box. Normally, studies, 43(5), 907-928. a fail in this check would highlight an error in the way the [4] McGuinness, D. L., & Van Harmelen, F. (2004). OWL web ontology input data is translated into the A-box, hence still an error in language overview. W3C recommendation, 10(10), 2004. the ontology design. [5] Horrocks, I., Patel-Schneider, P. F., Boley, H., Tabet, S., Grosof, B., & Dean, M. (2004). SWRL: A semantic web rule language combining The most interesting part is the reasoning triggered by the OWL and RuleML. W3C Member submission, 21, 79. SWRL rules that rely on information stored in the Knowledge [6] Haarslev, V., & Müller, R. (2001). RACER system description. In Base. These rules are typical logical rules of the form: Automated Reasoning (pp. 701-705). Springer Berlin Heidelberg. IF condition1 and … condition N THEN consequence. [7] Prud’Hommeaux, E., & Seaborne, A. (2008). SPARQL query language for RDF. W3C recommendation, 15. [8] Stellato A. OWLART API (http://art.uniroma2.it/owlart/). STIDS 2015 Proceedings Page 94