Contract No.: 285248 Strategic Objective

Security Monitoring Architecture

Download 1.78 Mb.

Page	4/54
Date	28.01.2017
Size	1.78 Mb.
	#8871

1 2 3 4 5 6 7 8 9 ... 54

2.6Security Monitoring Architecture

We detail in the following the interactions between the components of the Security Monitoring Architecture, as well as their respective connections to the FI-WARE framework.

We start with the potential events at the front of the Heterogeneous Event Normalization Service. In order to be correlated by the Service Level Security Information and Event Management (SIEM), the security events must be normalized (if they are heteogeneous) and pertinent for the risk analysis.

The Heterogeneous Event Normalization Service is also able to provide inputs for the Complex-Event Processing GE, in charge of the early detection of attacks.

The Service Level SIEM provides ability to consolidate and correlate monitored data and generate reports and alerts, exploited by the Visualisation Framework.

The MulVAL Attack Paths Engine is a topological Vulnerability Analyser (TVA) able to generate automated attack graph and thus possible attack paths. It exploits vulnerabilities reported in the National Vulnerability Database (NVD). The MulVAL Attack Paths Engine includes in its entries the Vulnerability Scanners operating on the network. It combines attack graph and Common Vulnerability Scoring System (CVSS), providing a quantitative property of individual vulnerabilities. The MulVAL Attack paths Engine exploits also topological data and vulnerabilities collection coming from a vulnerability scanner, as NESSUS scanner or as an OVAL compatible scanner (Open Vulnerability Assessment Language. It is also possible to input manually the Fire rules in the "Pivot File". An automatic extraction is scheduled for a future version.

A Scored Attack Paths tool, based on the Attack Graph provided by MulVAL, yields the possible attack paths, along with a score associated to each one of the paths.

A Fuzzer, that allows to assess the robustness of IoT protocol implementations and applications. In the future, it is considered to visualize the results of the Fuzzer in the visualization Framework.

An Android Vulnerability Assessment Tool, that detects the presence of known vulnerabilities on mobile devices, and a Botnet Tracking System, dedicated to abnormal DNS traffic error rates detection and tracking of the underlying botnet, complete the Risk Analysis. in the future, it is considered to visualize the results of the Analysis Reporting System in the visualization Framework. Otherwise, it is envisaged to exploit the identifyed vulnerabilities by the Mulval Attack Paths Engine, through the "import" function.

The decision making support provides Remediation component to security operators for proposing cost-sensitive remediations to attack paths. To facilitate the decision making processes, the man-machine interfaces ensure that solutions are effectively designed for end-users, providing them with increased efficiency.

The outputs of the Remediation are taken into account in a "Pivot file» enabling so to compute the new attack paths and to evaluate the impact of remediation solutions.

The Security monitoring GE Chapter meets the requirements of ISO 27001 (Section 4.2 Establishing and managing the ISMS).

Among others things, it provides an answer to paragraph “c” (...Identify a risk assessment methodology that is suited to the ISMS); to paragraph “d” (identify the risks); to paragraph “e” (Analyse 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.)

In conclusion, the security monitoring enabler is composed of the following functionalities:

Normalization of heterogeneous events and correlation covering the normalization and correlation of heterogeneous security events.
Risk analysis assessing the level of risk and measuring the impact of potential threats, whether they appear.
Decision making support helping to mitigate the risks and take efficient actions in accordance with the security policy.
Visualisation and reporting providing a dynamic, intuitive and role-based User System Interface for the various stakeholders to use in order to understand the current security situation, to make decisions, and to take appropriate actions.

The GE will address security monitoring and beyond, up to pro-active cyber-security i.e. protection of “assets” at large. Figure 1 provides a high-level initial architectural sketch of the Security Monitoring GE as envisaged in FI-WARE.

$c:\documents and settings\t0030011\bureau\d8-1-3\d813_wp8_v1_generated\d813_wp8_v1_pictures\860px-security_monitoring-architecture_22-01-14-1.png$

Figure 1: Security Monitoring Architecture.

2.7Basic Design Principles

MulVAL Attack Paths Engine

Interactions among multiple network components shall be considered in order to determine the security impact software vulnerabilities have on a FIWARE architecture instantiation. The model used in the vulnerability analysis is able to automatically integrate formal vulnerability specifications from the bug-reporting community, but also from various vulnerability databases, specific to the cloud hosting, the internet of things, l2N.. Also, the analysis is able to scale to networks with thousands of machines.

To achieve these two goals, the Attack path Engine, composed of an end-to-end framework and a reasoning system, conducts multihost, multistage vulnerability analysis on a FI-WARE architecture. MulVAL Attack Paths Engine adopts 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 easily leverages existing vulnerability databases and scanning tools by expressing their output in Datalog and feeding it to the Attack Path reasoning engine.

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 multihop network access. The rules are carefully designed so that information about specific vulnerabilities are factored out into the data generated from OVAL (Open Vulnerability and Assessment Language-MITRE)and ICAT (Categorization of Attacks Toolkit-NIST ). 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 Paths Engine uses an exploit 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.

Scored Attack Paths

Mainly, the considered attack paths that are included in the list are selected based on the target node selected in the attack graph from the security expert. 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 Paths Engine. The risk metric scores are used for computing the score of each path that will include a second scoring component which will in its turn account for the impact on the processes linked to the IT resource(s) being located on the attack path.

The Scored Attack Paths employs the following Enumeration:

Confidentiality:
Availability:
Authorization:
Authentication:
Accountability:
Implemented controls for assessing a threat’s severity:

In addition, Scored Attack Paths makes use of Impact criteria values for the aforementioned enumeration elements, based on either quantitative (strongly preferred), or at least qualitative values obtained from the Functional Model at the Business Layer.

Service Level SIEM

The Service Level SIEM is built on top of the open source OSSIM SIEM but will overcome its limitations, mainly in performance and scalability, with a high performance correlation engine.

From a functional point of view, the Service Level SIEM stack could be illustrated as showed in Figure 21, where also the bypass of the OSSIM correlation engine is depicted.

$c:\documents and settings\t0030011\bureau\d8-1-3\d813_wp8_v1_generated\d813_wp8_v1_pictures\mainitersiemfunt.jpg$

Service Level SIEM functional view

Figure 21: Service Level SIEM functional view.

The OSSIM agent receive normalized event. The fields of which the standardised event consists are:

type: Type of event, Detector or Monitor.
date: date on which the event is received from the device.
sensor: IP address of the sensor generating the event
plugin_id: Identifier of the type of event generated
plugin_sid: Class of event within the type specified in plugin_id
priority: Possible deprecated (agent can't decide priority, just server)
protocol: Three types of protocol are permitted in these events. Should a different one reach the server, the event will be rejected:: TCP, UDP or ICMP
src_ip: IP which the device generating the original event identifies as the source of this event
src_port: Source port
dst_ip: IP which the device generating the original event identifies as the destination of this event
dst_port: Destination port
log: Event data that the specific plugin considers as part of the log and which is not accommodated in the other fields. Due to the Userdata* fields, it is used increasingly less.
data: Normally stores the event payload, although the plugin may use this field for anything else
username: User who has generated the event or user with whom it is identifying, mainly used in HIDS events
password: Password used in an event
filename: File used in an event, mainly used in HIDS events
userdata1: These fields can be defined by the user from the plugin. They can contain any alphanumeric information, and on choosing one or another, the type of display they have in the event viewer will change. Up to 9 fields can be defined for each plugin.
userdata2
…
userdata9

The correlation engine included in the Service Level SIEM integrates a distributed real-time computation system that consumes streams of data and processes them in a scalable and fault-tolerant way, re-partitioning the streams between each stage of the computation however needed and ensuring the data will be processed. The processing of the data is performed with a complex event processing that allows the definition of correlation rules to raise service level alarms.

IoT Fuzzer

The IoT Fuzzer is built around the following principles:

the fuzzer engine itself uses the Scapy packet manipulation framework, to ease the process of packet analysis and creation;
the fuzzing process is driven by scenarios written in XML, that define sequences of exchanged packets:
- outgoing messages defined in these scenarios will be altered by the fuzzing algorithms before being sent;
- upon reception of the related response, it will be checked against the one defined in the scenario, to determine whether the tested device behaved properly;
to be able to inject crafted 6LowPAN packets onto the network, it uses an Atmel RZUSBstick (a 802.15.4 USB dongle) running a modified version of the Contiki OS that allows the hardware to relay packets without altering them.

Android Vulnerability Assessment Tool

The Vulnerability Assessment Tool is an Android application that mostly behaves as an Android Service:
- most of the time, it stays idle in the background, listening to system events;
- it periodically polls a remote OVAL definition database, using a web service.
Only when one of those two activities detect changes, does the Vulnerability Manager become active:
- when it detects that one or more OVAL definition needs to be tested, it invokes the OVAL checker;
- the OVAL checker then interprets the definition, tries to match it against the current system configuration and state, and sends back a report;
- the Vulnerability Manager then writes the report to the Internal Result Database and goes back to sleep.
The Analysis Reporting System only gets active when it needs to send some reports to a remote database, through a second web service.

Remediation

To compute the appropriate remediations and the hosts on which they can be deployed, the remediation application uses several techniques, according to the type of remediation. For the patches, thanks to the information contained in the MulVAL attack paths Engine, it is very simple to know on which machine the patch must be deployed to correct the vulnerability (it is in the same node: the leaf containing the vulnerability information).

But it is less simple for the deployment of snort or firewall rules, because the attacker packets route must be known to determine on which machine the remediation can be deployed. To know the route of the packets of the attacker, the topological information is used to recreate a simulated topology. With this route, the remediation tool just has to propose the remediation on the hosts containing a firewall or an intrusion prevention system, according to the type of remediation.

The topological information and a dependency graph are also used to estimate the impact costs of the remediation, especially for firewall rules deployment. Indeed, the system has to know which service will be interrupted in order to compute these costs. To know that, all the dependencies, that are present in the dependency graph, are checked in a simulated topology containing the remediation and are compared to the topology without remediation. If a service is disrupted due to the remediation, the corresponding cost is added to the remediation impact costs. The operational costs depends mainly of the type of remediation and on costs parameters that must be provided by the security operators, but their calculation is quite easy once these informations are known.

Visualisation framework

Decoupling of data from visualisations. Transforms are used to format the data in a suitable way for a particular visualisation. This allows each visualisation to work with multiple different data sets. There is a set of generic visualisations that are able to work with any data set.

Botnet trap mitigation

The mitigation mechanism by itself is handled by the MCP, using a dedicated functional layer handling the infected hosts connections (which will be referred to as the data plane hereafter). This layer will accept all connections attempts coming from the infected hosts. It differs however from a classical passive sinkhole, as the connections will be completed by the MCP (so not only recorded). This difference is important, as it will avoid a connection timeout which will make the bot to jump to another C&C server. Such choice means however that the MCP data layer will be directly exposed to the malicious activity, thus will be clearly separated from the control plane (communications with BlockMon and the WPOC) using a virtualized layer. The steps represented on the figure 21 summarize the interactions handled by the MCP during the quarantine process:

1. When a bot tries to reach its C&C server, the MCP will accept this connection and reference the incoming host as infected. Meanwhile, the MCP will analyse the sent requests to try toidentify the type of underlying malware (Zeus, SpyEye, Conficker,..) and extract potential commands.

2. The MCP will complete the connection with the bot, but by sending packets at a minimal rate. This will allow to maintain the connection open as long as possible, so the bot does not try to connect to another C&C server if the data returned by the MCP is meaningless for it. In case of a known malware, and according to the domain policies, the MCP could try to reply by disinfection commands in order to sanitize the infected computers.

3. Beside bots connections, the MCP can attempt (again, according domain policies) to connect to the initially requested C&C server, by using some commands learned from the bot and known to be harmless.

4. If such connection attempt succeeds, then the responses from the C&C server will again be used to get deeper knowledge about botnet characteristics and discover new commands. The BT-MCP will therefore be able to reference infected devices and analyse C&C channel traffic. Such investigation of the botnet's activity permits ideally the identification of the disinfection commands, which could then be used to sanitize the infected computers. If the disinfection command is not identified yet, we can keep the connections open with the bots and the C&C while ongoing investigation is still active, and eventually send meanwhile infection's notification to the infected clients.

In the case where no information can be learned from the botnet, because of the use of strong encryption, the botnet trap drops botnet's packets in the two directions. In that case, notifications could be sent to the clients to remove the malware. As a feedback loop, the BT-MCP will return to the AUI the learned information about the investigated botnets.

The Botnet Trap is divided in several modules as illustrated in Figure 22. Each module performs the tasks described below: • DNS rewriter: monitor the DNS requests done by the customers. It modifies the DNS answers by substituting malicious domain IP addresses with the botnet trap IP address when a domain name under monitoring is requested. According to the architecture deployed by the ISP, it could be an external module plugged for example near the DNS service platforms or near the customers access POPs. The DNS rewriter exchanges data with other modules through the Configuration Module.

• Network Layer: performs a first filtering stage and delivers the network packets received to the relevant module.

• Traffic Logger: logs the traffic received from the botnet trap to allow further analysis by the botnet behavior analyser module and the statistics manager module.

• Bot manager: handles the communication between the botnet trap and the infected devices which try to reach a C&C. It reacts according to the policies enforced by the configuration manager.

• C&C manager: handles the communication between the botnet trap and the C&C. It replays some traffic intercepted from a bot to a C&C to obtain traffic patterns from the C&Cs. Those patterns will be use in order to learn traffic sequences and the different available commands of the analysed C&C. It reacts according to the policies enforced by the configuration manager.

• Botnet Behavior Analyzer: computes the different logs and feedbacks obtained from the different modules to model the behavior of the detected botnet. These information are used by the bot manager and C&C manager to answer properly to the bots and the C&Cs. It also provides some information about the botnets to the G.E users through the reporting manager.

• Statistics manager: creates statistics based on the available logs of the botnet trap. For example, it provides insight of the botnets size, their volume and kind of activity, etc.

• Configuration manager: enforces the G.E policies received from the WPOC into the relevant botnet trap modules. It also allows the DNS rewriter to communicate with the botnet trap.

• Reporting Manager: provides information to the AUI regarding mitigation progress.

$c:\documents and settings\t0030011\bureau\d8-1-3\d813_wp8_v1_generated\d813_wp8_v1_pictures\botenettraparchi.jpg$

BotnetTrap software architecture

Figure 22: Botnet Trap software architecture.

Download 1.78 Mb.

Share with your friends:

1 2 3 4 5 6 7 8 9 ... 54