We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Security.CyberSecurity - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.CyberSecurity

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Security.CyberSecurity
Chapter Security,
Catalogue-Link to Implementation CyberCAPTOR
Owner Thales, Olivier Bettan (THA)


Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.

Copyright

Copyright © 2012-2015 by Thales.

Legal notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

Cyber Security is the first step towards understanding the actual risk exposure of a future Internet environment and, hence, towards realizing the execution of services with desired security behavior and detection of potential attacks or non-authorized usage. This generic enabler deals with detection of Cyber Security risks on sensitive “assets” at large, up to proposing possible remediations. Cyber Security GE leverages on top of some of the features of former GE called Security Monitoring. It goes beyond today’s offers typically used by SMEs and/or citizens (e.g. Firewall, Anti-virus) as it not only enables complex attack detection, but also automatically computes possible countermeasures depending on the information about the sensitive data and IT system vulnerability. The target user for this GE is any organization willing to detect and manage the cyber-security risks of their information system or applications efficiently. This may include FIWARE infrastructure owners (e.g. FIWARE Lab) or SMEs using or building applications on top of the FIWARE platform. As opposed to the Security Monitoring GE of FIWARE (Phase I), which was provided as a suite of multiple separate services, we now make it a single GE integrating all those features and offering high-level functionalities easily deployable, configurable and usable by non-security experts. The main purposes of the Cyber Security GE can be summarized as follows:

  • 1.Collect the vulnerabilities and evaluate the potential threats,
  • 2.Identify most probable and impacting attacks,
  • 3.Assess risk and propose remediation solutions,
  • 4.Deliver a visualization service centered on risk/attrition level.
  • 5.Provide Data Crisis sharing capabilities that preserve the privacy of the organization.

To achieve these purposes, the Cyber Security GE includes the following main components:

  • Cyber Data Extraction: In charge of extracting and processing all the raw cybersecurity-relevant data input by the user about his information system: network topology, firewall rules, vulnerability scan results (e.g. by Nessus), scoring preferences, etc. The output of this component is then used as input to the Attack Path engine and Remediation engine (see below). More information in the dedicated sub-section Cyber Data Extraction of section Basic Concepts.
  • Attack Graph Engine (MulVAL): A Topological Vulnerability Analyser (TVA) able to generate, from the output of Cyber Data Extraction (the parts related to the network topology and vulnerabilities of the information system) the attack graph regrouping all possible attack paths. This engine also combines the attack graph with the Common Vulnerability Scoring System (CVSS), to provide a quantitative analysis of individual vulnerabilities. More information in the dedicated sub-section Mulval Attack Path Engine of section Basic Concepts.
  • Scored Attack Paths: Analyzes the main attack paths of the attack graph provided by the Attack Graph Engine and computes a score for each attack path based on its business impact and probability of occurrence. The score basically represents the risk level. More information in the dedicated sub-section Scored Attack Paths of section Basic Concepts.
  • Remediation engine, helping to mitigate the risks and take efficient actions in accordance with the security policy by computing the different means to break the attack graph (so-called remediations) according to the AND/OR graph formalism and estimating a cost for each one. Once a security operator can actually select a specific attack path that he/she wants to prevent and get all the relevant alternatives of remediation. More information in the dedicated sub-section Remediation of section Basic Concepts.
  • Visualization interface: Provides a user interface for an operator to pilot the aforementioned components and to analyze dynamically the risk of an Information System. A security operator can use this application to visualize the possible attack paths that can face his/her Information System with their attrition level and the remediations that can correct them. This application can also be used for the Dynamic Risk Analysis of the Information System by taking into account the alerts issued by the SIEM (Security information and event management ) of the Information System when it exists, and matching them on the attack graph. More information in the dedicated sub-section Visualization of section Basic Concepts.
  • Privacy-Preserving (Crisis) Data Sharing (P2DS): enables an organization to share data relative to a crisis (successful attack with major business impact) with others without exposing confidential information about their compromised information system. More information in the dedicated sub-section Privacy-Preserving Data Sharing of section Basic Concepts. .

Before going into the details of the Cyber Security GE the figure below shows its eco-system with possible interactions with the infrastructure of an information system like FIWARE Lab and other Security GEs of the chapter.

Deployment components and interactions with Cyber Security GE

If we consider that GE instances are deployed on the same infrastructure like the one of FIWare (FILAB), the Cyber Security GE is able to check the vulnerabilities of the servers where these GE instances are deployed, such as instances of the IdM GE and the PDP GE presented in the previous sections. The CyberSecurity GE may also check vulnerabilities of servers (e.g. application servers) used by any application project on the infrastructure. In both cases, the data exchange between the audited assets and the Cyber Security GE is performed mainly by sending two files as input to the GE: The vulnerability report and network topology, sent respectively to the NESSUS and Network Topology boxes in the above figure.

Furthermore, the GE is able to process security information and events about the infrastructure (and GEs deployed on it) published by a SIEM. The SIEM is not provided by the Cyber Security GE anymore in FIWARE. However, it is likely that an information system will already include its own SIEM or other security monitoring capabilities. Otherwise, infrastructure owners can get one from various vendors or as open source like the OSSIM project. In any case, the Cyber Security GE provides an interface where the SIEM can push events to the Cyber Security GE for further analysis. Then it is important to deploy SIEM probes in the critical places as shown on the picture above (e.g. firewall, infrastructure service VMs), including the Security GEs such as the IdM and the Authorization PDP GE, so that access control events can be monitored, typically by parsing the GE logs.

Concerning the Remediation flows, the Remediation can advise the change of rules which would be applied to the firewall of the Infrastructure Service or the local firewall. It can also propose a set of patches. The Cyber Security GE follows the best practices from ISO 27001 (Section 4.2 Establishing and managing the ISMS (Information Security Management System). For example, the security analysis process is inspired by the Plan-Do-Check-Act cycle: Attach path analysis, Selection of remediation, Simulation of remediation, and Application of remediation. Among others things, it provides an answer to paragraph “c” of that document (Identify a risk assessment methodology that is suited to the ISMS); to paragraph “d” (identify the risks); to paragraph “e” (Analyze and evaluate the risks); to paragraph “f” (Identify and evaluate options for the treatment of risks) and to paragraph “g” (Select control objectives and controls for the treatment of risks.)

Basic Concepts

The figure below provides an initial architectural sketch of the components inside the Cyber Security GE and their main interactions, as envisaged in FIWARE. The figure is explained in the following subsections.

Building blocks of Cyber Security GE


Cyber Data Extraction

Two types of data are used as data sources for the Cyber Data Extraction: The report of a vulnerability scanner (e.g. NESSUS) and a unique file describing the topology of the Information System. This XML file describes machines of the Information System, with their network interfaces, IP addresses, VLAN belonging, listening network services, and firewall and routing configurations. This file may be generated automatically from the already available topology management tools of the information system, or using scripts provided by the Cyber Security Generic Enabler package, that build it from CSV files describing the hosts, the services and the VLANS. The vulnerability scanner automates the testing and discovery of services and known security weaknesses. The Cyber Data Extraction component handles the vulnerability scanner reports generated by Nessus for example. Nessus is a vulnerability scanner designed to automate the testing and discovery of known security issues. Nessus uses a client-server technology. Servers can be placed at various strategic points on a network allowing tests to be conducted from various points of view. A central client or multiple distributed clients can control all the servers. Nessus has the ability to detect the flaws of the hosts on the network remotely but it can also detect flaws and missing patches by scanning locally if it is given the credentials to log in and run commands on the host itself. Nessus has the ability to test SSL-enabled services such as https, smtps, imaps, and more. The report generated by the Nessus scanner helps to have an overview of the status of the network and its vulnerabilities, which is the first step to prevent vulnerabilities. It detects only known vulnerabilities for which a detection plugin has been provided by Nessus. Although most of the vulnerabilities that can be exploited by a medium-level attacker have a corresponding Nessus detection plugin, very high-level attackers may know zero-days (unpublished vulnerabilities) that are not addressed by any of those plugins. In order to give access to the vulnerability and topological information to the other components, the Cyber Data Extraction can generate two types of inputs. The first one is the Datalog file needed by the MulVAL Attack Graph Engine to generate the attack graph. This file contains both vulnerability and topological information. The second file that can be generated by the Cyber Data Extractor is an XML file aggregating all vulnerabilities and topological information needed by the Remediation application, in order to simulate remediations in the network topology.

MulVAL Attack Graph Engine

The interactions among multiple network elements must be considered in order to determine which security impact software vulnerabilities have on a particular network. The model used in the vulnerability analysis must be able to automatically integrate formal vulnerability specifications from heterogeneous vulnerability sources. The MulVAL Attack Graph Engine is an end-to-end framework and reasoning system that conducts multi-host, multi-stage vulnerability analysis on a network. The MulVAL Attack Graph Engine adopts Datalog (a query and rule language for deductive databases) as the modeling language for the elements in the analysis (bug specification, configuration description, reasoning rules, operating-system permission and privilege model, etc.). It has leveraged existing vulnerability database and scanning tools by expressing their output in Datalog to feed the Attack Path Engine. The rules can be modeled according the security expertise and skills. In other terms, the normal users do not need to modify these rules and just need to update the database with all published vulnerabilities from NIST(http://www.nist.gov/itl/csd/stvm/nvd.cfm). The inputs to the MulVAL Attack Graph Engine’s analysis are:

  • Advisories: What vulnerabilities have been reported and do they exist on my machines?
  • Host configuration: What software and services are running on my hosts, and how are they configured?
  • Network configuration: How are my network routers and firewalls configured?
  • Principals: Who are the users of my network?
  • Interaction: What is the model of how all these components interact?
  • Policy: What accesses do I want to allow?

The Cyber Security Data Extraction allows to generate automatically such inputs, from automatically generate data (such as the vulnerability scanner) or easily to understand data (description of hosts, with their importance on a scale Negligible/Minor/Medium/Severe/Catastrophic). This allows non-expert users such as SMEs to use this tool, without high technical knowledge. The current MulVAL Attack Graph Engine data model relies on the exploit range (local or remote) and the privilege escalation consequence data that are stored in NIST NVD (National Vulnerability Database). The figure below shows an extract of a logical attack graph computed by the MulVAL Attack Graph Engine. This logical graph explains how an attacker on the Internet (attackerLocated(internet)) can succeed to exec arbitrary code on a webserver (execCode(webserver,apache)) using the vulnerability CAN-2002-0392.

A logical attack graph

The MulVAL Attack Graph Engine uses Datalog (a subset of Prolog) to produce logical attack graphs. It takes as input a set of first-order logical configuration predicates and produces the corresponding attack graph. These configuration predicates include network-specific security policies, binding information and vulnerability data gathered from vulnerability databases. These are automatically generated from the NIST NVD, or from the topological configuration, thanks to the Cyber Data Extraction Component. The MulVAL Attack Graph Engine identifies possible policy violations through logical inference.

An attack graph presents a qualitative view of security discrepancies:

  • It shows what attacks are possible, but does not tell you how bad the problem is.
  • It captures the interactions among all attack possibilities in your system.

CVSS (Common Vulnerability Scoring System (https://nvd.nist.gov/cvss.cfm)) provides a quantitative property of individual vulnerabilities:

  • It tells you how bad an individual vulnerability could be.
  • But it does not tell you how bad it may be in your system.

The idea is to use CVSS to produce a component metric, i.e. a numeric measure on the conditional probability of success of an attack step. The MulVAL Attack Graph Engine aggregates the probabilities over the attack-graph structure to provide a cumulative metric, i.e. the probability of attacker success in your system. Suppose there is a “dedicated attacker” who will try all possible ways to attack your system. If one path fails, he/she will try another. The cumulative metric is the probability that he/she can succeed in at least one path.

Scoring the Attack Paths

Scored Attack Paths represents the next step, following the metrics provided by the MulVAL Attack Graph Engine. Based on the Attack Graph provided by the MulVAL Attack Graph Engine, and the individual scores of each step, the objective is to yield the possible attack paths, along with a score associated to each one of the paths.

The considered attack paths that will be included in the list are selected based on the target node selected in the attack graph. The score of each path reflects the risk associated to the path as a whole, based on the individual scores of each step that have been previously calculated by the MulVAL Attack Graph Engine.

Additionally to the risk score metric, the score of each path includes a second scoring component that takes into account the business impact of all IT resource(s) impacted by such attack path. Next section will elaborate on how the business impact is entered.

The main idea of scoring attack paths (see figure below) is to consider paths independently from one another, as opposed to the approach of the MulVAL Attack Graph Engine, composed of individual scores, the latter being computed by taking into account all the connections existing in the attack graph.

Flow diagram of scoring attack paths

Scoring User Preferences

One other main improvement in this architecture, in comparison to the one of previous releases is the addition of the support of user preferences for scoring, that allows security operators to set scoring preferences (for example business importance of assets) independently of the attack graph. Indeed, until now, it was necessary to specify in an XML file the score of each node of the attack graphs, to take into account the business impact in the scoring. And this file was specific to an attack graph. Thanks to this new feature, the user’s scoring preferences can be given directly as input to the Generic Enabler (Cyber Data Extraction) and they will be given automatically to the scored attack path engine.

Recommendation

For use cases where the sensitive assets are directly reachable from Internet, the attack graph engine is not very useful and not recommended. For instance, if you are analyzing possible attacks from Internet or from a private VLAN (insider attack) to a public website (in DMZ), the attack graph will not bring much value as there is no bounce attack exploiting vulnerabilities of multiple hops to reach the asset. Therefore, the attack graph is reduced to one or two nodes.

Remediation

The Remediation application provides tools to security operators for proposing cost-sensitive remediations to attack paths. The attack paths are shown to a security operator, ordered by their scores, which allow to easily understand the severity of the consequences of the attack paths. To calculate remediation (see figure below) to the chosen attack path, the tool first extracts the necessary information from the attack path to be corrected. Then, it computes several lists of remediations that could reduce / cut this attack path. Finally, it estimates the cost of each list of remediations and proposes all the lists of remediations, ordered by cost, to security operators. Operators can choose one remediation list and, thanks to the remediation validation, check whether or not the system is more secure after applying this remediation.

Remediation process

Remediations using a remediation database

To compute remediations, a remediation database is needed. This database makes a connection between vulnerabilities (for example thanks to a Common Vulnerabilities and Exposures identifier - CVE ID) and a possible adapted remediation. Several types of remediation could be used, for example a patch (it corrects a vulnerability). A new type of remediation will be added to the remediation database, comparing to former project: Virtual Patching (a signature of known attacks which prevents the exploitation of a vulnerability). To build the remediation database, information about patches can be extracted from publicly available sources of data (for example the National Vulnerability Database), or in Security Advisories (for example, coming from CERT-EU). Information about signatures and the related vulnerability could be extracted from the signatures database that contains the CVE ID. Python scripts are given together with the tool, in order to populate or update automatically the remediation database, from such open sources. The only action needed by the user, in order to do that, is to launch the script, which will download the files from the Internet, and populate the database.

Network remediations

The other types of remediations provided by the Remediation application cannot be stored in the remediation database, because they are network remediations, such as firewall or routing configuration change. The network configuration feature needs the simulation of the network topology obtained after modifying the network configuration, in order to confirm that it removes the vulnerability and reduces the risk to attacks. To sort the list of remediations, a cost function is applied to compute an estimate cost of each list. This cost contains two main components: operational costs and impact costs. The operational costs represent the costs caused by the deployment of the remediations (length of the deployment, maintenance costs, tests costs, …) whereas the impact costs represents the negative impact (side effects) that could happen following a remediation deployment.

Remediation Automation

One main feature of this Remediation application is the proposition to highlight automatically the best remediation to some risks through an adaptive tuning and machine learning. This is done with a learning of the responses that have been applied by operators on similar attack paths. A similar attack path can be, for example, an attack path targeting the same machines, but using a different vulnerability. When a remediation is applied by an operator, the server learns what has been done by the operator. When a new attack path is detected, if it is similar to an attack path already corrected, and has a remediation similar to the one that has been applied before, the remediation that will be the first to be proposed to the operator is the similar remediation.

Visualization

The visualization is the main component of the Generic Enabler to manage the computation of attack paths and remediations, and to display them. Systems that evaluate the security of a network, such as the Attack Graph or Scored Attack Paths Engines, can generate a large amount of data. The Visualization aims to find ways to display such big graphs, in order to present to an operator something that he/she can understand. This can for example be done thanks to the display of an attrition level associated to attack paths. A simplified visualization is proposed, corresponding to the needs of Phase 3 projects mainly targeting SMEs. The Risk Visualization is performed genuinely by attrition level.

The visualization interface also describes the different remediations that can correct attack paths, in order to help a security operator to make a choice.

The visualization is also used for Dynamic Risk Analysis, by depicting the elements of the attack graphs that have been detected in SIEM alerts and are currently being attacked.

Privacy Preserving Data Sharing

Cyber Security features enable organizations to comprehend a situation and react appropriately, in particularly during crisis phases. During these phases, it is crucial for them to be able to share crisis data in order to get support from institutions and private consulting companies. The Privacy-Preserving Data Sharing feature completes other Cyber Security features. It enables organizations to share crisis data without disclosing their private data.

Privacy-Preserving Data Sharing (P2DS) allows organizations to do computations on aggregated data without revealing that data. For example, if there are three organizations A, B, and C, which want to collaborate, each organization could contribute the number of attacks seen per hour during the last 24 hours, and receive back the *total* number of attacks per hour seen by all three organizations. This summation is done without revealing each organization’s individual contribution. While P2DS cannot do an arbitrary computation on the data values, it can do vector addition, or compute the maximum. These should suffice for the most common scenarios.

More formally, P2DS consists of a number n of Participating Organizations (POs), each of which supplies one Data Peer (DP) and at least one Privacy Peer (PP). POs agree on a computation to be performed (addition or maximum) and on the length L of the vectors to be used in the computation. At some point, the computation is centrally initiated, and eventually, all POs receive (identical) copies of the result. In our example, n = 3, and each of A, B, and C would contribute one DP and let's say that each contributes two PPs. Since we want to add the number of attacks per hour over the last 24 hours, we have L = 24.

Once the computation starts, each DP would send an encrypted version of the 24 measurements to its two PPs. The PPs, knowing what the other PPs are, would start a multi-round protocol in which they compute the encrypted sum of all the measurements. After the computation is finished, the encrypted result is sent back to the DPs, which can decrypt it. The privacy peers never see the clear text version of any data contribution and hence do not need to be trusted. (They need to be trusted to carry out their computation faithfully, though.)

The implementation of P2DS in FIWARE will consist of three web services:

  • A Data Peer service, to be instantiated once per PO.
  • A Privacy Peer service, to be instantiated at least once per PO
  • A group management service to be instantiated once per PO group.

The Data and Privacy Peer services are merely implementations of the DP and PP functionalities. Since the PPs need to communicate among each other, it is necessary to open any firewalls along the way.

The Group Management service is more complex. Its functions include:

  • Create/delete group
  • Membership management
  • Add/delete/edit PO
  • Add/delete privacy peers
  • Add/delete data peers
  • Computation management
  • Choose computation (addition, maximum)
  • Vector size
  • Computation initiation

Main Interactions

Cyber Data Extraction

The Cyber Data Extraction component provides the following interfaces:

  • An external input interface to get the vulnerability scanner report. The scanner can run asynchronously on each host and results can be centralized on one host whenever new information arrives from the scanners.
  • An external input interface to get the network topology file.

These external interfaces will operate via file input/output with a defined data structure for the file content (XML schema).

MulVAL Attack Graph Engine

The first action of this component is to generate the attack graph using MulVAL, thanks to the input file generated by the Cyber Data Extractor. In this process, for example, the results of the vulnerability scanner are converted into Datalog clauses like the following:

vulExists(webServer, ’CAN-2002-0392’, httpd).

Namely, it identifies a vulnerability with CVE id CAN-2002-0392 on machine webServer. The vulnerability involved the server program httpd. However, the effect of the vulnerability — how it can be exploited and what its consequences are — is not contained directly in the results of the vulnerability scanner. The National Vulnerability Database (NDV) developed by the National Institute of Standards and Technology (NIST), provides the information about a vulnerability’s effect through CVSS Impact metrics. The relevant information is converted from CVSS into Datalog clauses such as:

vulProperty(’CAN-2002-0392’, remoteExploit,privilegeEscalation).

The MulVAL Attack Graph Engine models elements in Datalog. The model elements are recorded as Datalog facts. The MulVAL Attack Graph Engine requires all Datalog facts to be defined prior to performing any analysis. Missing or incorrect facts will result in a misleading analysis of the system being modeled.

Scored Attack Paths

Scored Attack Paths interacts with two components, namely the MulVAL Attack Graph Engine, and Remediation engine.

The interaction between Scored Attack Paths and MulVAL Attack Graph Engine is obvious, since the latter provides:

  • The potential attack graph;
  • The probability scores of each attack graph node, translating the probability of success to each step in the attack graph. These probability scores are the basis for computing the risk score of an attack path.

Once the attack paths related to a given target is obtained, altogether with the score for each of the attack paths, the result will be output to the Remediation engine and Visualization component, in order to be employed for the objectives of the latter. Besides the internal interactions with the Attack Graph Engine and the Remediation engine, the Scored attack paths component provides one external interface to get the user preferences for attack path scoring. Mainly, the internal and external interfaces will operate via file input/output with a defined data structure for the file content (XML schema).

Remediation

The remediation application interacts mainly with three components: the Cyber Data Extraction, the Scored Attack Paths, and the Visualization. The interactions between the Scored Attack Paths and the remediation are necessary because attack paths are the starting point of the remediation process. Security operators need to select an attack path for remediation in the list provided by the Scored Attack Paths. On the other hand, the attack path engine is also useful to validate the remediations selected by the security operators. This feedback is necessary to compare the security state of the system before and after deploying a remediation.

The interactions between the remediation tool and the Cyber Data Extraction are necessary because the network topology (hosts, routes, deployed firewall rules, …) is necessary to compute the topological related remediation (attack signature deployment and firewall rules). The remediation tool provides also a means to apply automatically some of the remediations chosen by the security operators. To do that, this tool needs to change some parameters (e.g. a firewall rule) in the Cyber Data Extraction.

Besides the internal interactions between the Remediation engine and the Cyber Data Extraction and Scored Attack Paths, the Remediation engine especially interacts with the Visualization interface to display to the user the possible remediations for the risks on his/her information system.

Visualization

The Visualization offers a visualization service that allows users to visualize data, such as the Scored Attack Path engine or the Remediation engine. The user accesses the visualization service through a standard web browser connected to the web application server using some network connection (such as the Internet). The user will experience a single integrated application. Behind the scenes, the browser will get access to the information generated by the other components.

Besides the internal interactions between the visualization component provides an external interface for receiving alerts from the SIEM (if there is one that is already deployed) and display those security alerts in relationship to the nodes of the attack graph.

Privacy Preserving Data Sharing

The user interacts with the Privacy Preserving Data Sharing (P2DS) through the following web services already described in details in previous section:

  • A Data Peer service, to be instantiated once per PO.
  • A Privacy Peer service, to be instantiated at least once per PO
  • A group management service to be instantiated once per PO group.

Since the PPs need to communicate among each other, it is necessary to open any firewall along the way. The Privacy Preserving Data Sharing uses the Scored Attack paths and Remediation plan outputs to share data about the Cyber context of an Organization.

Basic Design Principles

The design of the Cyber Security GE is aligned with FICORE project and FIWARE scope, stressing on characteristics such as usability, new features, packaged solutions and solutions that scale.

Another key requirement is the compliance to industrial standards.

Therefore, the following transverse design principles have been applied for the Cyber Security GE:

  • Standard data formats for exchange between the different components.
  • Use asynchronous process
  • Proper error handling: to prevent any wrong analysis due to incorrect use the tools or incorrect input data (non accurate or incomplete topology information shall be rejected).
  • Flexibility and modularity: use a script programming language (such as Python) to develop the Cyber Data Extractor, to make it easy the plug new connectors in to the component, if a user of the GE wants to use another input format, while keeping the same outputs, adapted to each components. For example, if the vulnerability scanner used in a company is OpenVAS, rather than Nessus, it is easily possible, in few lines of code, to develop a connector to OpenVAS, which can be used in addition to the one to Nessus, while keeping the same outputs for MulVAL Attack Graph Engine.
  • Datalog as the modeling language for the elements in the analysis (bug specification, configuration description, reasoning rules, operating-system permission and privilege model, etc.). It leverages existing vulnerability databases and scanning tools easily by expressing their output in Datalog and feeding it to the Attack Graph reasoning engine. MulVAL Attack Graph Engine adopts this modeling language[1].

Design principles for the visualization are presented in more details below.

Attack paths and attrition level visualization

The main design principle of the visualization of attack paths and attrition level is to try to present a complete, but also simple representation of attack paths, in order for the tool to be accessible for non-security experts, while being still accurate. In order to do that, two different representations of attack paths are given, a logical one, more complete, the one generated thanks to MulVAL, and a topological one, which give a higher representation of an attack path. This representation is much easier to understand for a non-security expert and that is why it is the default representation of an attack path that can be visualized. However, the logical view of the same attack path is far more complete and may be necessary to understand exactly what can happen. So, this representation is proposed as an alternative to operators with a higher level of expertise.

Remediation visualization

In the visualization of a remediation, an emphasis is put on the operational actions to deploy the remediation and on its cost. Indeed, both these elements will allow an operator to decide whether or not he/she will actually deploy this remediation rather than another.

Dynamic Risk Analysis

The Dynamic Risk Analysis part of the visualization tool is designed to receive data in real time from the connected SIEM (if it already exists in the infrastructure). However, it is not the alerts that will be presented to the operator, in this Dynamic Risk Analysis view, but rather the attack graph with dynamic nodes or edges. Indeed, most SIEM tools already propose an interface to visualize the incoming logs dynamically, but the true added value of this Dynamic Risk Analysis view, is to see which attacks of the attack graph are really happening in the Information System, according to these dynamic alerts.

References

  1. The reasoning engine consists of a collection of Datalog rules that captures the operating system behavior and the interaction of various components in the network. Thus, integrating information from the bug-reporting community and off-the-shelf scanning tools in the reasoning model is straightforward. Reasoning rules specify semantics of different kinds of exploits, compromise propagation, and multi-hop network access. The interaction rules characterize general attack methodologies (such as “Trojan Horse client program”), not specific vulnerabilities. Thus the rules do not need to be changed frequently, even if new vulnerabilities are reported frequently. MulVAL Attack Graph Engine uses a dependency graph to represent the pre and post conditions for exploits. Then a graph search algorithm can combine individual exploits and find attack paths involving multiple vulnerabilities. This algorithm is adopted in Topological Vulnerability Analysis (TVA), a framework that combines an exploit knowledge base with a remote network vulnerability scanner to analyze exploit sequences leading to attack goals. Compared with a graph data structure, Datalog provides a declarative specification for the reasoning logic, making it easier to review and augment the reasoning engine when necessary. The reasoning engine scales well with the size of the network. Once all the information is collected, the analysis can be performed in seconds for networks with thousands of machines.

Detailed Specifications

Following is a list of Open API Specifications linked to this Generic Enabler. These Specifications are presently delivered directly on the APIARY platform which is followed from the API Blueprint process recommendations.

Open API Specifications

The CyberCAPTOR server API Open Specification can be found at the following link:

http://docs.cybercaptor.apiary.io

The Cybersecurity GE P2DS API Open Specification can be found at the following link:

http://docs.p2dsgroupmanager.apiary.io

Re-utilised Technologies/Specifications

Attack Path Engine

The Attack Path Engine uses the report of vulnerability scanners. Scanners can run asynchronously on each host and which adapts existing tools such as OVAL to a great extent—and an analyzer, run on one host whenever new information arrives from the scanners.

An OVAL scanner takes such formalized vulnerability definitions and tests a machine for vulnerable software. The result is converted into Datalog clauses like the following:

vulExists(webServer, ’CAN-2002-0392’, httpd).

Namely, the scanner identified a vulnerability with CVE id CAN-2002-0392 on machine webServer. The vulnerability involved the server program httpd. However, the effect of the vulnerability—how it can be exploited and what is the consequence — is not formalized in OVAL. NVD the vulnerability database developed by the National Institute of Standards and Technology (NIST), provides the information about a vulnerability’s effect through CVSS Impact metrics. The relevant information is converted from CVSS into Datalog clauses such as:

vulProperty(’CAN-2002-0392’, remoteExploit,privilegeEscalation.

The Attack Path Engine models elements in Datalog. The model elements are recorded as Datalog facts. The Attack Path Engine requires all Datalog facts to be defined prior to performing any analysis. Missing or incorrect facts will result in a misleading analysis of the system being modelled. The following table shows the elements modelled by the Attack Path Engine and their Datalog fact statements sorted by the DAP layer to which they belong.

How the Attack Path Engine Datalog facts interrelate is recorded as Datalog reasoning rules that are shown in the following table.

With the occurrence of new vulnerabilities, assessment of their security impact on the network is important in choosing the right countermeasures: patch and reboot, reconfigure a firewall, dismount a file-server partition, and so on.

The next figure show the sequence diagram with the interaction beetwen thhe other components:


Vulnerability Data Interface Description

-<definition class="vulnerability" id="oval:org.mitre.oval:def:99" version="4">

 -<metadata>
   -<title>
     IE v6.0 Content Disposition/Type Arbitrary Code Execution
    </title>

-<affected family="windows">

  <platform>Microsoft Windows 2000</platform>
  <product>Microsoft Internet Explorer</product>

</affected> <reference ref_id="CVE-2002-0193" ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0193" source="CVE"/> -<description>

  Microsoft Internet Explorer 5.01 and 6.0 allow remote attackers to execute arbitrary code via malformed Content-Disposition and  Content-Type header fields that cause the application for the spoofed file type to pass the file back to the operating system for handling rather than raise an error message, aka the first variant of the "Content Disposition" vulnerability.
</description><

-oval_repository>

 -<dates>
   -<submitted date="2004-01-27T05:00:00.000-04:00">
      <contributor organization="The MITRE Corporation">Andrew Buttner</contributor>
    </submitted>
   -<modified comment="modified wrt-222 - changed pattern match" date="2005-03-07T05:00:00.000-04:00">
     <contributor organization="The MITRE Corporation">Christine Walzer</contributor>
    </modified>
    <status_change date="2005-03-09T05:00:00.000-04:00">INTERIM</status_change>
    <status_change date="2005-03-29T05:00:00.000-04:00">ACCEPTED</status_change>
   -<modified comment="Changed IE registry test to wrt-18" date="2005-09-20T04:00:00.000-04:00">
       <contributor organization="The MITRE Corporation">Christine Walzer</contributor>
    </modified>
    <status_change date="2005-09-21T01:27:00.000-04:00">INTERIM</status_change>
    <status_change date="2005-10-12T05:49:00.000-04:00">ACCEPTED</status_change>
   -<modified comment="Added negate=true attribute to criteria sub-block to fix conversion error from OVAL 4.2 to OVAL 5.0" date="2006-07-03T12:56:00.000-04:00">
     <contributor organization="The MITRE Corporation">Matthew Wojcik</contributor>
   </modified>
   <status_change date="2006-07-03T12:56:00.000-04:00">INTERIM</status_change>
   <status_change date="2006-09-27T12:29:41.221-04:00">ACCEPTED</status_change>
  -<modified comment="Multiple corrections and update to POSIX compatibility for ste:2878" date="2010-11-29T16:13:00.904-05:00">
     <contributor organization="G2, Inc.">Shane Shaffer</contributor>
   </modified>
   <status_change date="2010-11-29T16:14:04.414-05:00">INTERIM</status_change>
    </dates><status>INTERIM</status></oval_repository> </metadata><criteria comment="Software section" operator="AND"><criterion comment="the version of mshtml.dll is less than 6.0.2716.2200" negate="false" test_ref="oval:org.mitre.oval:tst:3086"/><criterion comment="the patch q321232 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3119"/><criterion comment="the patch q323759 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3118"/><criterion comment="the patch q328970 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3117"/><criterion comment="the patch q324929 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3116"/><criterion comment="the patch q810847 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3115"/><criterion comment="the patch q813489 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3114"/><criterion comment="the patch q818529 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3113"/><criterion comment="the patch q822925 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3112"/><criterion comment="the patch q828750 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3111"/><criterion comment="the patch q824145 is installed (Installed Components key)" negate="true" test_ref="oval:org.mitre.oval:tst:3110"/><criteria comment="Windows 2000 Service Pack 4 (or later) is installed" negate="true" operator="AND"><criterion comment="Windows 2000 is installed" negate="false" test_ref="oval:org.mitre.oval:tst:3085"/><criterion comment="SP4 or later Installed" negate="false" test_ref="oval:org.mitre.oval:tst:3073"/></criteria><criterion comment="Internet Explorer 6 is installed" negate="false" test_ref="oval:org.mitre.oval:tst:3090"/></criteria> 
>

Topological Data Network Interface Description

<
 The reachability input is like "hacl(HOST1, HOST2, Protocol, Port)", where "hacl" means "host access control list". 
>


Scored Attack Paths

Scored Attack Paths utilizes the following technologies:

  • Berkeley XML Database

The Berkeley DB XML database specializes in the storage of XML documents, supporting XQuery via XQilla. It is implemented as an additional layer on top of (a legacy version of) Berkeley DB and the Xerces library.

  • JDOM

JDOM is an open source Java-based document object model for XML that was designed specifically for the Java platform in order to exploit its language features.

  • Apache Commons

Commons Math is a library of lightweight, self-contained mathematics and statistics components addressing the most common problems not available in the Java programming language or Commons Lang.

Attack graph data interface description

<attack_graph>
 <arcs>
 <arc>
 <src>4</src>
 <dst>5</dst>
 </arc>
<arc>
 <src>3</src>
 <dst>4</dst>
 </arc>
<arc>
 <src>9</src>
 <dst>10</dst>
 </arc>
<arc>
 <src>8</src>
 <dst>9</dst>
 </arc>
<arc>
 <src>8</src>
 <dst>14</dst>
 </arc>
</arcs>
 <src>8</src>
 <dst>15</dst>
 </arc>
<arc>
<vertices>
<vertex>
 <id>49</id>
 <fact>hacl('172.17.5.51','172.17.5.51',tcp,'80')</fact>
 <metric>1</metric>
 <type>LEAF</type>
 </vertex>
<vertex>
 <id>50</id>
 <fact>RULE 4 (multi-hop access)</fact>
 <metric>1</metric>
 <type>AND</type>
 </vertex>
<vertex>
 <id>51</id>
 <fact>RULE 5 (direct network access)</fact>
 <metric>1</metric>
 <type>AND</type>
 </vertex>
<vertex>
 <id>52</id>
 <fact>hacl(internet,'172.17.5.51',tcp,'80')</fact>
 <metric>1</metric>
 <type>LEAF</type>
 </vertex>
<vertex>
 <id>53</id>
 <fact>networkServiceInfo('172.17.5.51',http_server,tcp,'80',someUser)</fact>
 <metric>1</metric>
 <type>LEAF</type>
 </vertex>
<vertex>
 <id>54</id>
 <fact>cvss('CVE-2010-2068',l)</fact>
 <metric>1</metric>
 <type>LEAF</type>
 </vertex>
 </vertices>
</attack_graph>


Remediation

The decision-making support interacts mainly with three components: the Scored Attack Paths, the MulVAL Attack Graphs Engine, the Topological Data Extraction, and the Visualisation Framework. To these are added all the information from other components, that are required for the Remediation computational purposes.

The interactions between the Scored Attack Paths and the remediation are necessary because attack paths are the starting point of the remediation process. Security operators need to select an attack path to remediate in the list provided by the Scored Attack Paths. On the other hand, the attack path engine is also useful to validate the remediations selected by the security operators. This feedback is necessary to compare the security state of the system before and after deploying a remediation.

The interactions between the remediation tool and the topological data extraction are necessary because the network topology (hosts, routes, deployed firewall rules…) is necessary to compute the topological related remediation (attack signature deployment and firewall rules). The remediation tool provides also a mean to apply automatically some of the remediations chosen by the security operators. To do that, this tool needs to change some parameters (for example add a firewall rule) in the topological data extraction.

That is why the decision making support provides the following interfaces:

  • An internal interface with the ‘Scored Attack Paths’ to receive the attack paths to be reduced.
  • An external interface to send back the remediations selected by security operators to the Attack Path Engine, that allows to validate this remediation.
  • An internal interface with the Topological Data Extraction to get the network topology
  • An external interface with the Topological Data Extraction to apply some of the remediations selected and validated by security operators
  • A GUI, interacting with the Visualisation Framework, to allow security operators to select attack path to correct, browse remediations and there estimated cost, select a list of remediations to deploy and, when necessary, to validate this list.



Privacy preserving data sharing

The main issue is the following: when organisations are asked to share data about security, they are naturally reluctant to do so, because revealing this data may lead to loss of trust or it may reveal details of the organisation's business that a competitor could use to its advantage. On the other hand, sharing data could be mutually beneficial. For example, when an organisation is the victim of a denial-of-service attack, it is useful to know whether other organisations are also a victim. This is where privacy-preserving data sharing comes in.

The subject of Privacy preserving data sharing is fully richer. Although it's part of CyberCaptor GE, we prefere to detail these specifications in the following link:

https://forge.fiware.org/plugins/mediawiki/wiki/fiwaresecurity/index.php/FIWARE.OpenSpecification.Security.Cybersecurity.P2DS


Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FIWARE level, please refer to FIWARE Global Terms and Definitions

Personal tools
Create a book