Re-utilised Technologies/Specifications

2.8Re-utilised Technologies/Specifications

MulVAL Attack Paths Engine

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

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:

The MulVAL Attack Paths Engine models elements in Datalog. The model elements are recorded as Datalog facts. The MulVAL Attack Paths 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 MulVAL Attack Paths Engine and their Datalog fact statements (Figure 9) sorted by the Dynamic Asset Protection (DAP) layer to which they belong.

Figure 9: Datalog facts.

The MulVAL Attack Paths Engine uses the NVD (National Vulnerability data base) when a vulnerability scanning has been operated. As a consequence, the attack Paths Engine can exploit the vulnerability effects.

How the MulVAL Attack Paths Engine Datalog facts interrelate is recorded as Datalog reasoning rules as shown in Figure 10.

Figure 10: Datalog rules.

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.

Figure 11 show the sequence diagram with the interaction between the other components. It should be noted that, while the MulVAL Attack Paths Engine provides a cumulative score for each of the nodes in an attack graph, the Scored Attack Paths on the hand, provides the scores for each attack path, which has a different meaning.

Figure 11: Sequence Diagram Risk Analysis.

-

-

-

Microsoft Windows 2000

Microsoft Internet Explorer

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.

>

Topological Data Network Interface Description

The reachability input is like:

<

"hacl(HOST1, HOST2, Protocol, Port)", where "hacl" means "host access control list".

>

In addition, the MulVAL Attack Paths Engine delivers Web Application access which aids users to interface and interact with the Attack Paths Engine. So, users can compute automatically an attack graph by providing a link to a file with topological description; this file is generated by a vulnerability scanner as, for instance, the Nessus scanner.

Figure 12 show the Web page presented to users.

Figure 12: Web page.

Scored Attack Paths

The interaction between Scored Attack Paths and MulVAL Attack Paths Engine is obvious, since the latter provides (i) the set of all the potential attack paths, and (ii) 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 calculating the risk score of an attack path.

Once the set of 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 Remediations in order to be employed for the objectives of the latter.

The relation between Scored Attack Paths and the other components that are required for the computation of the impact of a successful IT resource attack on related processes will be further defined once the components under scrutiny are clearly identified.

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

• 
  An internal interface with the ‘MulVAL Attack Paths Engine’ to obtain the attack graph.
  

• 
  An external interface to send the scored attack paths selected by security operators to the 'Remediations'.
  

Service Level SIEM

1. Sensors: deployed in the networks to monitor network activity. They usually include the low level detectors and monitors that passively collect data looking for patterns but they can also include active scanners that try to compile information about node vulnerabilities or agents which could receive data from other hosts of this network.

2. Management Server: this component is in charge of the main processing activities such as normalizing, prioritizing, collecting, risk assessment and correlating engines.

3. Database: where all events and information configuration for the management of the system are stored.

4. Frontend: where the operator can visualise the status of the system and configure the SIEM.

In the Service Level SIEM (Figure 14) included in the Security Monitoring GE:

1. Input events coming from different sensors are already normalized and received by the OSSIM agents. That normalization task is performed by the' Heterogeneous Event Normalization Service' component included in the Service Monitoring GE.

2. The Management Server integrates the OSSIM core engine and a high performance correlation engine.

3. The OSSIM database included in the Service Level SIEM is used to store all events received, configuration data and the alarms generated by the new correlation engine.

4. The dashboard is provided by the 'Visualisation Framework' component included in the Service Monitoring GE. This component will access the OSSIM database to recover the information about the alarms generated by the Service Level SIEM.

Figure 14: Service Level SIEM - Main elements.

Botnet Tracking System

• 
  Only the DNS domain names longer than 6 characters are proceeded, as short domain names have been exhausted since a while by generic web sites and cannot therefore be used for domain flux;
  

• 
  All the requests made on non-existing Top Level Domain (TLD) like ’.home’ and ’.local’ (mostly linked to Apple Bonjour protocol) and ’.arpa’ (reverse lookup which is rarely implemented) are discarded ;
  

The G.E components involved in the botnet quarantine application are the following:

• BT-MCP (Botnet Trap MCP): Ensures the quarantining of the bots inside a domain;

• BN (Blockmon Nodes): performs the detection and gather real-time information about the ongoing botnets;

• DNS-RW (DNS ReWriter): intercepts and rewrites malicious domains to the BT-MCP;

• IXP (InterDomain eXchange Gateway): Allows to exchange information about detected botnets with other domains;

• WPOC (Workflow Planning and Orchestration Controller): is responsible for the propagation of the detection and the mitigation policies.

• AUI (Application User Interface): Permits to define the workflow and to display the detection and mitigation results.

The Botnet Trap Mitigation Control Point supports a control plane interface, and a data plane interface. The control plane is responsible for the communication with other components: reception of mitigation policies, communication with the DNS Rewriter and BlockMon nodes. The data plane interacts with the infected computers and the C&C servers. It also performs the analysis of the botnet.

IoT Fuzzer

Architecture

Figure 15: Fuzzer architecture.

The fuzzer (Figure 15) communicates with IoT devices, through a 802.15.4 network interface connected to the fuzzing platform, which must be in range of the devices, and must be capable of relaying raw Link Layer frames.

The fuzzer is driven by XML scenarios that define the sequence of packets to be sent, and how the fuzzed system is expected to reply to these packets.

Use Case

The developer first has to define at least one XML scenario that corresponds to the normal use case of the application running on the tested IoT device. The scenario will define what messages to send, and which fields to check in the corresponding replies received from the tested device.

She then has to specify which of the provided fuzzing policies to apply, or to create new ones that fit her needs, and to define when and where to apply them on the XML scenario.

The fuzzing process can then be launched, and it will start replaying the scenario, using the fuzzing policies to alter messages before sending them to the device, and reporting whether the device replies to these messages in accordance with the scenario or not.

Android Vulnerability Assessment Tool

Architecture

Figure 16: Android Vulnerability Architecture.

The Android Vulnerability Assessment Tool (Figure 16) is an Android client application that connects to two different web services:

• 
  the first one allows the tool to retrieve OVAL definitions from a remote database, through its Database Updater component, which then stores them locally;
  
• 
  the second one allows the tool to publish its reports to a remote database, through its Analysis Reporting System.
  

The Vulnerability Manager process can be triggered in two different ways:

• 
  by the Database Updater process, which periodically connects to the web service, and sends an event to the Updater Listener when new OVAL definitions have been downloaded;
  
• 
  by the Android Event Bus, on which system configuration and state changes are transmitted, and sent to the Event Bus Listener.
  

It will then select which OVAL definitions to test, and send them to the OVAL Checker component.

Vulnerability Assessment

Figure 17: Android Vulnerability Sequence.

In the scenario depicted here (Figure 17), the Vulnerability Manager is triggered by an event sent by the Database Updater process, upon reception of new OVAL definitions.

The Vulnerability Manager will then send these to the OVAL Checker:

• 
  first, the OVAL Definition Analyzer will gather the list of system characteristics that need to be tested;
  
• 
  then the OVAL Characteristics Collector will get the current system values for these characteristics;
  
• 
  finally, the OVAL Characteristics Analyzer will compare the collected values with the ones known to be vulnerable, and generate a report, to be sent back to the Vulnerability Manager.
  

The Vulnerability Manager will then write this report into the Internal Result Database, and when triggered, the Analysis Reporting System will connect to the second web service, to publish the report.

Remediation

The Remediation interacts mainly with three components: the Scored Attack Paths, the Pivot, and the Visualization 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 module are necessary because the scored 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 interactions with the Pivot file and consequently with the Attack Paths Engine are useful to get a feed-back on 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.

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 with the 'Pivot' to make the feed-back loop
  

• 
  A GUI, interacting with the Visualisation Framework, to allow security operators to select attack paths to correct, browse remediations and there estimated cost, select a list of remediations to deploy and, when necessary, to validate this list.
  

Visualisation framework

The Visualisation Framework offers a visualisation service that allows users to visualise data from multiple network components, such as the MulVAL Attack Paths Engine and the Service-Level SIEM. The user accesses the visualisation 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 showing multiple visualisations. Behind the scenes, the browser will compliment the information from the visualisation server with data and functionality directly from the Internet.

Users of the framework will follow a similar pattern of creating, interacting with, modifying and eventually removing visualisations. There are therefore three main interactions between users and the Visualisation Framework: adding a new visualisation; modifying an existing visualisation; removing a visualisation.

Add new visualisation enables a user to view a new visualisation. The user selects the visualisation and data type from a list of available options. External visualisations that support the existing data formats can also be added. The user can customise the visualisation, e.g. by choosing the size of the window. A sequence diagram (Figure 18) for the interaction is shown below (Figure 18).

Figure 18: Addition Visualisation sequence diagram.

Modify visualisation enables a user to modify an existing visualisation. The user can change the type of data displayed, the size of the window, how often the visualisation is updated. The interactions for modifying a visualisation are shown in the sequence diagram below (Figure 19).

Figure 19: Modify Visualisation sequence diagram.

Remove visualisation enables a user to remove a window containing a visualisation from the display. A sequence diagram for the interaction is shown below (Figure 20).

Figure 20: Remove Visualisation sequence diagram.

Download 1.78 Mb.

Share with your friends: