Christopher Humphries

Nicolas Prigent

Christophe Bidan

Frédéric Majorczyk

Combination, Organization and Reconstruction through Graphical Interactions

Keywords: Combination, Organization and Reconstruction through Graphical Interactions C.2.0 [Computer-Communication Networks]: General -Security and Protection, I.3.6 [Methodologies and Techniques]: Interaction Techniques, H.5.2 [Information Interfaces and Presentation]: [User Interfaces] Security, Visualization Visualization, Intrusion Detection, Forensics

published or not. The documents may come   L'archive ouverte pluridisciplinaire

INTRODUCTION

In the context of IT forensics, analysts rely on log files that record and describe what happens in various parts of the system (network segments, routers, servers, hosts, etc.). Log files exist in different formats and contain different information depending on the software that generated them and what the file describes. While they are invaluable sources of information, log files are often impractical to analyze both because of their human-oriented formats and because of their size (many gigabytes being not uncommon).

Many visualization tools (among which [START_REF] Eick | Graphical analysis of computer log files[END_REF][START_REF] Koike | SnortView: Visualization System of Snort Logs[END_REF][START_REF] Tricaud | Picviz: Finding a Needle in a Haystack[END_REF][START_REF] Oliner | Advances and challenges in log analysis[END_REF]) have been designed to help analysts better understand the content of log files. These tools often focus on a specific type of log file or a specific set of log files. Due to that fact, they do not allow the analyst to opportunistically benefit from other types of log files that could be available.

Furthermore, security-oriented visualization tools often aim to explain global trends or detect events that are symptomatic of a specific attack. It is often considered that the analysis is a drill down process and that the analyst is searching for a specific piece of information. However, even if detecting each malicious action is fundamental, it is also very important to understand the relations between security events so as to reconstruct the global scenario [START_REF] Lee | Henry Lee's crime scene handbook[END_REF]: once the analyst has found an interesting event, he or she must be able to discover any other related events, even if these events are stored in different log files generated by different sources therefore exhibiting different formats. What are, for example, the causal relations between the attacks in different parts of the system? Having compromised a web server, did the attackers then perform other malicious actions on the system? If so, what are the consequences? In reaction to this, we advocate that IT forensics is an iterative process and that an analyst must be able to easily use information stored in log files to search for related events in other log files, even if these are not explicitly related.

In this paper, we present CORGI (Combination, Organization and Reconstruction using Graphical Interactions), a web-based visualization tool that allows analysts to import various types of log files and to visualize their contents. Many log file formats can be exploited, and new ones can easily be added using a straightforward and consistant description of log file formats. CORGI also implements an iterative process inspired by those used for IT forensics by allowing the analyst to use the values of interest he or she has found in a given dataset to filter events in other datasets, thus implicitly relating these datasets.

This paper is organized as follows. First, we explain how CORGI manages the various log files. Then, we detail how relations can be efficiently created between log files based on values of interest. In section 3, we describe the representations and user interactions in CORGI. In section 4, we provide some information about implementation and experimentations. Finally, we discuss related work in section 5.

LOG FILES

CORGI uses log files as data sources. In this section, we first present how log files are organized. We then present the various operations that can be performed on a dataset obtained from a log file during an analysis. Finally, we present how relations can be made between a priori unrelated datasets.

Log File Organization

While exhibiting various contents and formats, log files are generally organized in a similar way. A log file is made of a set of entries, each of which corresponds to an event. These events are made of a set of fields. In CORGI, we reasonably hypothesize that all the entries in a given log file contain the same fields, which can of course assume different values. Since each entry in a given log file corresponds to an event, we also assume that all the log files used by the analyst contain a timestamp field which places the event in time. We should mention that a field can be assigned a default value if this field is not relevant to the entry. For instance, the apache standard log format uses the value '-' as a default placeholder.

In consequence, most log files can be seen as a table with as many lines as events and as many columns as fields, at least one of them being a timestamp. Figure 1 shows two lines from an apache-access log file extracted from a dataset made available by the Honeynet Project [START_REF]Forensic Challenge 10[END_REF]. This example contains two lines (and therefore two events). Every event in this log file is described with nine fields, each with a semantic meaning, in the following order: the IP address of the client which made the request to the web server, the identd of the client machine, the userid of the user if authenticated, the timestamp defining when the event occured, the first line of the HTTP request performed by the client, the HTTP status code returned by the server, the size of the answer, the client referrer and user agent.

In consequence, a type can be associated with each field. Types in CORGI are semantic types, in contrast with [START_REF] Humphries | Elvis: Extensible log visualization[END_REF] for instance: they provide information about the nature and meaning of the field. Currently we have identified many semantic types among which: IP Address, TCP Port, UDP Port, Timestamp, URL, CVE_ID, Size, HTTP Method, HTTP Status Code, FTP command, userid, City, Country. The analyst can create further types according to the current need. Types should be generic enough to be used in as many log files as possible while being specific enough to avoid ambiguity. For instance, a Status Code type is too generic since it could encompass HTTP Status Code and NNTP Status Code, which in fact do not have the same meaning.

In addition, a flag is associated with each type stating whether this type is categorical or not. A categorical type is a type for which identical values refer to the same meaning while different values refer to different meaning. For instance, the CVE_ID type is categorical: Two log entries having the same value for a CVE_ID field refer to the same vulnerability, while different CVE_ID values refer to different vulnerabilities. Similarly, identical values for an IP Address refer to the same network device, local addressing and NAT notwithstanding. In contrast, size and CPU usage for instance are not categorical: identical values may refer to different realities while similar events may be logged with different CPU usage and size values.

CORGI uses semantic types, and more specifically categorical types to create relations between datasets. This aspect will be described in section 2.3.

Operations on a Single Log File Contents

When he or she explores a log file for forensics purposes, an analyst is searching for events of interest, events that are of particular relevance for understanding and reconstructing what happened on the monitored system. During experiments we performed with a previous tool [START_REF] Humphries | Elvis: Extensible log visualization[END_REF], we observed that analysts have different approaches for exploring the same log file. For instance, they do not start by exploring the same fields. These differences can be explained by the attacks the analysts have been exposed to recently as well as the information they have been provided with.

While their ways of exploring a given log file are different, all analysts generally perform sequences of two basic operations: they choose specific fields to be considered and select events according to the values exhibited by these fields. In accordance with the terminology used in relational algebra [START_REF] Codd | A relational model of data for large shared data banks[END_REF], we call these operations projections and selections. Projections consist in choosing fields of interest (for instance, HTTP Status Code) so as to focus on the information they contain. Selections consist in choosing specific values for a given field. For instance, the analyst chooses all the events in an apache-access log file for which the HTTP Status Code is equal to 500, 501, 502, 503, 504 or 505 which correspond to types of server errors.

The exploration of a log file can be described as sequences of projections and selections which lead to events of interest, events which are considered particularly interesting for the analyst. We should mention that the differences between the different modi operandi of the analysts are linked to the order in which these operations are performed. However, if analysts reach the same conclusions, they will have obtained the same set of events of interest whatever order the projections/selections were in.

When an analyst obtains a set of events of interest, he or she can consider that the values of some of the fields are particularly relevant. We call them values of interest. For instance, it could be the IP Addresses of the hosts which caused the events of interest to be logged, the CVE_IDes of the vulnerabilities which were effectively exploited, etc. Values of interest are obtained by projecting the events of interest for a specific field of interest and therefore constitute a set of values the events of interest take for this field of interest associated with the type of the field.

In the next section, we show how values of interest are used to relate log files.

Relating Datasets

A given log file offers a local view of events on a specific part of the monitored system. As such, it allows the detection of malicious actions that were performed in its own specific context. However, the purpose of forensics is not only to detect unrelated malicious events but also to reconstruct the global scenario of the attacks which happened on the system as a whole. To that end, it is important to be able to relate the various log files. Since our objective is to allow the analyst to opportunistically use any log file available on the system, we also designed CORGI to offer him or her the ability to dynamically relate log files having no explicit a priori relation between them. This is done using both the values of interest and the Timestamp fields.

Relations Based on Values of Interest

Each log entry is made of fields which each have a specific type. Two log files which exhibit fields of the same type can be related semantically since they reference objects of the same nature. For instance, relations can be implied between log files that both have IP Address, TCP Port, HTTP Status Code or CVE_ID fields.

Following the idea that forensics is an iterative process (one discovery leading to another), CORGI relies on values of interest to relate log files. As stated in the previous section, an analyst who discovers events of interest can extract values of interest from chosen fields. Because these values are typed, it is possible to use them for filtering log files with at least one field of the same type, i.e., to select this field and only keep entries for with values listed in the provided values of interest. As a result, the new selection only contains events with values previously defined as being of interest in the first log file.

We should mention that if a log file more than one field of a given type, the analyst can apply the filter to any number of them. For instance, IP Addresses of interest obtained from an apache log can be used to select the source IP Address field of a snort log file, its destination IP Address or both. Relations can also be performed on the same log file. For instance, if some IP Addresses are indentified as victims (Destination IP Address) in a Snort log, it can be interesting to use these as filters on the Source IP Address of the same Snort log to discover compromised machines being used as stepping stones to launch attacks.

As explained, log files are related a posteriori in CORGI. Only elements considered of interest in one log file can be related to other log files by using them as filters. With this approach, we avoid combinatorial explosions which can occur when using natural joins1 between log files. While enforcing type constraints prevents the analyst from making mistakes by relating semantically different data, the proposed mechanism also allows more freedom regarding the possible relations that can be explored. We strongly believe that the analyst should have the last word for when it makes sense to relate two log files since he or she is better informed on analysis context.

Relations Based on Time

Time is critical information when reconstructing attack scenarios. In point of fact, events belonging to the same attack scenario are linked by their time of occurrence. The knowledge that two events are simultaneous or that one happened after the other is particularly relevant for an analyst.

In log files, time is stored by the Timestamp field. In contrast with the data types we presented in the previous section, the Timestamp type is not categorical. Due to clock drifting in the machines and the time it takes to generate a log entry, two events stored in different log files and corresponding to the same observed event may not exhibit the same Timestamp, and two unrelated events may share the same Timestamp. Modifying Timestamp precision to compensate for this fact is dangerous. First, it is very difficult to arbitrarily estimate clock skews and imprecisions. Second, in busy systems, the produced datasets may be big. Finally, events which are part of an attack scenario may be spread over long periods. Such is the case with Advanced Persistant Threats for example.

For these reasons, CORGI uses visual correlation to help the analyst relate log files in time. As will be shown in more details in Section 3, CORGI offers a synthetic representation in which the various log files are presented on a shared time scale to enable a direct visual correlation allowing analysts to perceive simultaneity and possible causality.

In the next section, we present how these concepts are implemented in CORGI in terms of representations and user interactions.

VISUALIZATION AND USER INTERAC-TION

In this section, we describe the interface and the user interactions we designed to help explore logs using visualization tools. We first provide an overview of the interface, then some details about its different areas and how the analyst interacts with them.

Overview

The main interface in CORGI (see Fig. 2) is divided into 4 panels, each of which has a specific purpose linked to a step in the exploration process. We will describe these panels in a counter-clockwise fashion, following our general interaction procedure.

In the top left corner, the header panel houses the log import button. The analyst can either click this button to select log files for importing or drag and drop these files from a file explorer. When new log files are imported, they are parsed and appear in the leftmost timeview panel which displays the event time distribution for each log file. When log files are selected in the timeview panel, their fields appear in the adjacent fields summary view, which displays field distributions using sparkline type bar charts. When more than one dataset is selected in the timeview panel, the fields of every selected dataset are displayed. The full-sized chart view is the main panel. It contains all the full-sized charts with axes and labels. Finally, the values of interest box located in the header panel is designed both to collect the values of interest discovered during the analysis and to apply these values of interest as filters for other fields of the same type.

An analysis follows the same path as our tour of the interface: After the log files have been imported for exploration, the analyst is first given an overview of these to compare the event time distribution. He or she can then obtain more information about the value distribution for each field and compare these across log files. If some fields look particularly interesting, he or she may then explore them further and select specific values. When values of interest have been found, the analyst can store them and a new exploration cycle begins: these values of interest can be used to filter fields with the same type or new log files can be imported analysis. This design prevents the analyst from being lost during the exploration process and also removes any constraint on the order in which the log files and fields are explored.

CORGI's interface also follows one following key unifying rule: each log file is assigned a color which is applied to its visualizations in the entire interface to help distinguish between files. This helps analysts identify the source of fields, from which log files values of interest where collected and on which field(s) they have been applied.

We now provide more details about each of these components in the following sections.

Importing Logs

CORGI uses a slightly modified version of the importation mechanism designed for [START_REF] Humphries | Elvis: Extensible log visualization[END_REF]. A variety of log formats are available, among which apache standard, syslog and its variations, Snort alert logs and the 2012 VAST Challenge firewall log [START_REF]VAST Challenge[END_REF]. Adding new log file formats is straightforward: each log file type is handled by a specific parser which provides a regular expression matching valid log entries for this format, as well as the name and type for each field. In consequence, if new types of log file need to be imported, this requires nothing more than the right regular expression, with the names and semantic type for each field, as well as an indication of whether or not the field is categorical. The need for a semantic type for each field and an indication of whether they are categorical or not is the only difference with the ELVis log acquisition mechanism.

When importing a set of log files, the first entry of each of them is tested by each available parser until a match is found, in which case each entry is parsed and normalized2 , each field is mapped to its descriptors, the events are counted and the log time period is retrieved.

For each imported log file, a new representation is created in the timeview panel.

Timeview Panel

The timeview panel displays the distribution of events accross time for the imported log files. It is composed of two similar representations which both visualize the datasets using stacked charts sharing a scale to enable correlation by time.

The first representations cover a globally encompassing time scale and use a reduced size horizon chart [START_REF] Heer | Sizing the Horizon : The Effects of Chart Size and Layering on the Graphical Perception of Time Series Visualizations[END_REF]. The dates are displayed in a human-friendly format, which first provides the analyst with the knowledge of the period over which the events have been logged in each log file. In Fig. 2 for instance, the auth.log file spans the full period while the www-access.log and www-media.log files contain events within a shorted period. In this precise case, this is due to the fact that roll-overs are different for syslog files and apache log files. However, the absence of events over a given period could also mean that the intruder shut the log-ging system down temporarily, or that parts of the log file have been erased. The horizon-chart based representation allows the analyst to notice these patterns immediately.

This representation also provides an overview of the event distribution over time in a way similar to [START_REF] Fischer | Real-Time Visual Analytics for Event Data Streams[END_REF]. As such, macro-events such as DDoS or brute-force attacks for example are detected immediately. Because the representations of the log files are aligned, visual correlation is much easier: synchronized attacks over multiple systems, appearing in multiple log files, exhibit vertical alignment patterns while causally-related events exhibit delayed activity patterns.

While this representation provides the analyst with an interesting overview of the events, he or she can also zoom in to obtain more details about a specific period. A unified brush on the horizon charts allows for filtering the time period and controls the time scale for the second set of area charts underneath and enables the detailed inspection of our global timeline. This part provides complementary information about each log file: its name, the number of events contained within the selected time period, and a vertical axis for better evaluating the quantity of log entries for each period. The horizontal axis located at the top provides a more detailed timeframe for the selected period.

When the analyst clicks on the representation of a log file, its fields are displayed in the fields summary view, which we present in the next section. A second click removes the fields from the field summary view to avoid overwhelming the analyst.

Fields Summary View

The field summary view contains a summary chart representation of all the fields selected in the timeview panel. In order to help the analyst, each field exhibits the same color as the log file it belongs to.

The field summary view first informs the analyst about the available fields in a given log file. The name of each field is provided as well as the number of distinct values this field exhibits. Finally, the bar chart displays the distribution of the values for this field. By taking up little space on the screen, it allows the analyst to easily notice and compare unusual distributions.

Each chart reacts to the current time filter applied in the timeview panel and updates accordingly. An analyst can therefore inspect the evolution of the distributions for a given field by brushing and sliding the selection in the timeview panel.

This feature is very effective for detecting massive events happening on a very short period such as brute-force attacks, DDoS, etc. In this kind of situation, the distributions of the values in some of the fields change noticibly in a very short period. For instance, in the case of a brute force attack against the admin password on a web service, a single or a few IP addresses will perform a noticeable share of the requests for a very short time and will therefore be overrepresented, but only for a few minutes. Depending on the size of the analyzed log file and any eventual sampling, the share of these requests could stay undetected. In contrast, when the analyst brushes the timeview panel, he or she can observe modifications at certain times in the IP address distributions which require further investigations.

To obtain more information about some fields, the analyst can click on summary representations to trigger the display of full-sized charts.

Full-Sized Charts View

The full-sized charts view contains the complete representations of the fields the analyst selected for exploration in the field summary view. A full-sized chart (see Fig. 3) exhibits the same color as the log files it comes from. The values the field takes and the number of events with this values are provided. Representations are automatically selected according to the field chosen by the analyst and using the same approach presented in [START_REF] Humphries | Elvis: Extensible log visualization[END_REF]. For instance, Fig. 3 We should mention that CORGI only combines fields coming from the same log file into a single representation. Indeed, it would make no sense to combine different fields coming from different log files since their values cannot be safely related to shared single event.

Analysts can perform selections on the values of full-sized charts by clicking on them. The result of this selection is then applied to all the representations dealing with the same log file. For example, if the analyst selects the values 500 and 502 in the HTTP Status Code representation, all the representations for the same log file are modified to only display the events for which the HTTP Status Code is equal either to 500 or to 502. For instance, the IP chart only displays IP addresses linked to requests which generated 500 or 502 HTTP Status Code.

Additional information and interactions are proposed on the upper right of each full-sized representation. First, the names of the represented fields are displayed. Three small buttons are available:

• The cross button removes the representation. The selections that were made using it are dismissed.

• The flag button collects values of interest.

• The check button keeps this representation as is. If other fields that belong to the same log file are selected afterward in the same log file, they will not be added to this representation. It is however still possible to perform selections on it.

When values of interest have been found in a chart, the analyst can click the flag button to collect these. For example, if the analyst selected 500 and 502 values in the HTTP Status Code and wants to keep the IP addresses which caused these values to be logged, he or she can click on the flag button of the IP field representation. It is of course possible to generate values of interest for more than one field of the same log file.

In the next section, we show how values of interest are represented and how the analyst interacts with them.

Values of Interest Box

The values of interest box is located in the upper panel. It contains the values of interest which have been collected by the analyst. A given value of interest is represented as follows, left to right:

• The name of the field from which the values of interest were extracted, color coded for the log file it came from.

• the semantic type of that field.

• the values of interest, which can be individually toggled.

• the names of the fields the values of interest can be applied to as filters, color coded for the datasets they belong to.

Here, Fig. 5 shows a set of two values of interest obtained from the IP field in the blue dataset (in this case, an apache access log file), with the IP semantic type. It contains two values (208.80.69.69 and 65.88.2.5) and can be applied to the field named IP in the green log file. This last box is filled, which indicates that the filter is currently applied, but only for the currently selected address, which is 208.80.69.69. In order to remember from where these values of interest originate, the analyst can hover over the value of interest. A tool tip then displays the selections that led to obtain these values (in this case, HTTP Status Code = 500 or 502).

Because the values of interest box is located in the upper panel, it allows the analyst to keep an eye on these values at all times. This helps to guide the selections that can be performed based on the values in the various fields of the displayed log files.

After this presentation of the interface and interactions used by CORGI, we provide details on their implementation and cases studies in the next section.

IMPLEMENTATION AND CASE STUDY

CORGI is implemented as a web tool using HTML5, Javascript, CSS and SVG. It uses React [START_REF]React -A JavaScript library for building user interfaces[END_REF] to manage the user interface and is built upon the Flux application architecture [START_REF]React | Flux Application Architecture[END_REF]. These projects follow the fundamental premise that a unidirectional flow of data is central to the application. Using this foundation helped us build CORGI around data pipeline models [START_REF] Fry | Visualizing Data: Exploring and Explaining Data with the Processing Environment[END_REF][START_REF] Wilkinson | The Grammar of Graphics[END_REF]. Although the SVG markup for our visualizations is generated using React, the d3.js library [START_REF] Bostock | D3: Data-Driven Documents[END_REF] is used to directly generate axes and paths as well as managing layouts and scales. Fast filtering is implemented using the Crossfilter library [START_REF] Crossfilter | Fast Multidimensional Filtering for Coordinated Views[END_REF] which provides an OLAP server for interfacing with datasets as n-dimensional data cubes. As it inherits its log parsing and chart selection capabilities from ELVis [START_REF] Humphries | Elvis: Extensible log visualization[END_REF], CORGI can both parse multiple log formats and select charts automatically with minimal effort.

We used CORGI to explore the 2012 HoneyNet Visualization Challenge [START_REF]Forensic Challenge 10[END_REF] and the 2012 VAST Challenge [START_REF]VAST Challenge[END_REF] datasets on a MacBook Pro with 4GB of memory, a 2.5GHz Intel Core i5 processor and a GeForce GT 330M graphics card with 512MB of memory. We used Google Chrome version 36.

The 2012 Honeynet Visualization challenge dataset contains log files that were gathered on a real compromised machine. In this dataset, there are about 10 different log files: auth.log, dpkg.log, kern.log, www-access.log, www-error.log, etc. For this case study, we will inspect the www-access.log and www-media.log files, which are logs from an apache web server, and the auth.log file, which is the authentication log for the host. The www-access.log and www-media.log files are consistent with the description given in Subsection 2.1. The latter logs the requests related to media such as images, CSS and Javascript files, while the first one logs the main requests. The auth.log file contains different fields: timestamp, host, application, process id and the authentication message from which we can often extract an action, a user name and an IP address when the authentication is remote. Once the files are imported into CORGI, we first notice inconsistencies between the www-media.log and wwwaccess.log files. There is a burst of requests in the wwwaccess.log file at a specific time while there are only a few requests at the same time in the www-media.log file. There are also two bursts in the auth.log files, the latter seemingly synchronized with one in the www-access.log file.

We first address the www-access.log file activity by inspecting the HTTP status codes, especially the server errors (5xx codes). We notice that only two IP addresses are responsible for these errors (65.88.2.5 and 208.80.69.69), and mark these IP addresses accordingly, as values of interest. We then decide to track them in the three files using the values of interest box. In the www-access.log file, there are many other requests that do not seem harmful. Both the IP adresses are present in the www-media.log file. The second one generates several client errors by requesting a javascript URL not present on the server. By tracking these values of interest in the auth.log dataset, we notice that there were eight SSH authentication successes and one failure from both these IP addresses. For the second one, there are logged warnings of failed reverse DNS mappings. Two user names were used in these SSH connections: user1 and user3. These kinds of user names seem strange on a host, although they could very well be due to the anonymization process. We collect these as values of interest to continue the exploration of the logs. Using CORGI, we were able to easily track activity for both these IP addresses accross all three log files.

For our second case study, we inspected log files from the 2012 VAST Challenge. The second mini-challenge provides us with four log files. According to the described scenario, these logs come from the computer networks of a regional bank. Two files are 24-hour logs from a Snort IDS, while the others are firewall logs covering the same period. Due to space contraints, we cannot describe the full analysis of the VAST challenge and we will focus on part of our analysis of the IDS log covering the first 24 hours.

Thanks to the possibility of selecting and excluding values, we discovered that 9 external IP addresses were the source of IRC traffic directed towards 314 different destination IP addresses in the internal network, and marked these 9 IP addresses as values of interest accordingly, refered to as A from now on. We also discovered 5 IP addresses in the internal network which are sources of scans of different services on the firewall. Again, we marked these 5 IP addresses as values of interest, refered to as B from now on. Our last discovery is more concerning: client hosts in the internal network scanned the firewall of the bank. We pursue our exploration by applying the IP addresses in B as a filter for the source IP address field. This allows us to know whether they are the source of other alerts. As this is not the case, we then apply these values as a filter for the destination IP addresses. This allows us to know whether these IP addresses were the target of attacks. This time we find that this is the case for 4 of the 5 IP addresses in B: they are implicated in the IRC traffic with the 9 source IP addresses in A. We hypothesize that the hosts in B may be part of a botnet controlled via IRC by the hosts in A.

In this use case, we show how the ability to select and exclude different field values, mark some as values of interest and use these values to filter the same dataset can quickly and easily provide clues about what happened in log files.

RELATED WORKS

CORGI is based partly on concepts already used in ELVis, such as generating visualizations based on selected typed fields. This automatic selection is based on principles close to those used in Autovis [START_REF] Wills | AutoVis: Automatic visualization[END_REF]. We use the nature of the content, statistical analysis of the data aspects and rules from the Grammar of Graphics [START_REF] Wilkinson | The Grammar of Graphics[END_REF] to select and generate visualizations. ELVis was designed using the same principles but was optimized for security data. CORGI takes this logic and security tuned design further. For example, we assume that network events can all be correlated and compared in time and have designed a chart to better exploit that.

For effective visual exploration of logs we consider certain functions essential such as filtering, annotation and support for multiple datasets. As explained previously, the interface in CORGI relies heavily on reactive filtering and synchronization for elements of the interface. PortVis [START_REF] Mcpherson | PortVis: A Tool for Port-Based Detection of Security Events[END_REF] displays multiple synchronized time charts to allow for both global and detailed visualization, and Muelder et al. use a global view synchronized with a detailed view [START_REF] Muelder | A Visualization Methodology for Characterization of Network Scans Workshop on Visualization for Computer Security[END_REF]. The time view in CORGI uses the same approach with two linked time charts, one global and one filtered, in an effort to help to provide both context and detail in one component simultaneously for multiple datasets.

To provide exploration using a drill-down approach, we rely on synchronized update and filtering in charts. NVi-sionIP [START_REF] Lakkaraju | NVisionIP: NetFlow Visualizations of System State for Security Situational Awareness[END_REF] follows a similar approach using multiple charts to provide this drill-down interaction cycle as does Clock-View [START_REF] Kintzel | Monitoring Large IP Spaces with ClockView[END_REF] on a larger scale using four synchronized visualizations designed for successive and progressive filtering. Harrison et al. designed a tool [START_REF] Harrison | Interactive Detection of Network Anomalies via Coordinated Multiple Views[END_REF] in which each visualization is designed to provide access to the different features of networks: spatial disposition using graphs, time histograms for network events and a scatterplot visualization for spectral data analysis. Tools linked to real world forensics such as the Analysts Notebook [START_REF] Analysis | Analyst ' s Notebook 8 Increase the depth of intelligence for effective resource utilization[END_REF] also use combinations: maps for localizing forensic data and graphs to then visualize links in this data. We follow the same approach without a predefined set of visualizations, instead letting the operator decide to create visualizations best suited for that point of the exploration.

Increasing its similarity to CORGI, improvements to NVi-sionIP add the capacity for recording and reusing effective search patterns [START_REF] Lakkaraju | Closing-the-Loop in NVisionIP: Integrating Discovery and Search in Security Visualizations[END_REF] based on features often found in certain anomalies. Further improvements also add sparkline charts [START_REF] Yurcik | Tool Update: NVisionIP Improvements (Difference View, Sparklines, and Shapes)[END_REF] for increased data density.

Aiming to improve the reactivity and available options for corporate security operators, Hertzog [START_REF] Hertzog | Visualizations to Improve Reactivity Towards Security Incidents Inside Corporate Networks[END_REF] proposes building visualisations by first reducing the data to those members deemed most important, and then to group these events by meta-application, e.g. web applications. We reason that by comparing and relating datasets using their fields and values, we implicitely group data by importance and feature.

The two tools that seem closest to this project are Polaris [START_REF] Stolte | Polaris: a system for query, analysis and visualization of multi-dimensional relational databases[END_REF] and FlowTag [START_REF] Lee | FlowTag: A Collaborative Attack-Analysis, Reporting, and Sharing Tool for Security Researchers[END_REF]. Polaris takes a similar approach to statistical typing, choosing to identify fields as either ordinal or quantitative, and then using these to assist the user in creating visualizations. These are produced by combining the fields of multiple sources of data into different layers of visualization. Filtering is made possible using a data cube which directly maps a database schema. The authors then describe the direct link between this progressive filtering and the progressive creation of relational queries to a database, and hypothesize that the tuples selected graphically and used for queries can themselves be exported as a further dataset. FlowTag adopts a less direct approach to extracting relevant information, and uses filtering to exclude irrelevant dataflows combined with tagging to identify and characterize relevant flows. This approach aims to improve the quality of reports and automatic report generation.

CONCLUSION AND FUTURE WORK

We have presented CORGI, a web based tool for the simultaneous exploration and semantic relating of multiple log files. CORGI is built upon the assistive visualization capabilites of ELVis, implements synchronized views, fast data cube type filtering and guided exploration using points of interest. These values of interest can then be used to filter and link multiple logs.

We have many plans for extending this system. The current state of the tool relies on local files and the processing capabilities of browsers. Extending this model to a server backend for log collection and aggregation would let us explore larger files spanning multiple systems using more complex data operations, including real time updates. We are already experimenting with UI state serialization, and using a server backend would also open-up new possibilites for collaboration and sharing forensic analysis sessions.

Once values of interest are collected and verified they can be stored and exported as new datasets. In the long term one of our goals is to use these to help generate reports and improve future exploration assistance. As this information can be imported and then directly reused in CORGI these reports could themselves be analysed and related, essentially starting a new interactive session and using the same advantages provided during the initial exploration.

Figure 1 :

 1 Figure 1: Two apache standard log entries

Figure 2 :

 2 Figure 2: An overview of CORGI.

Figure 3 :

 3 Figure 3: The full-sized chart of an HTTP Status code field.

  corresponds to the selection of a single HTTP Status Code which is categorical while Fig.4shows the representation produced for the selection of an HTTP Status Code and IP field, both being categorical in nature.

Figure 4 :

 4 Figure 4: The full-sized chart of HTTP Status Code and IP fields.

Figure 5 :

 5 Figure 5: Two IP addresses selected as values of interest.

We use the term natural join in the relational algebra sense, i.e., each entry in a log file is associated with every entry in the other if they have the same value for the selected fields.

While IP addresses often look the same, timestamps for instance exhibit very different formats, e.g., some of them do not contain the year.

ACKNOWLEDGEMENTS

The authors would like to thank the DGA-MI for financing this research project.


Adrien Lammoglia
email: adrien.lammoglia@etd.univ-avignon.fr

Keywords: Simulation, SMA, dimension fractale, forme, flux Simulation, MAS, fractal dimension, form, flux

Évolution de la dimension fractale pour un modèle de trafic.

Évolution de la dimension fractale pour un modèle de trafic

Une méthode alternative pour l'appréhension morphogénique d'un flux, simulé en système multi-agent ?

I. Introduction

Dans un premier temps, nous allons présenter les méthodes et les outils utilisées,en précisant leur intérêt et leur cadre d'application. Nous posons ensuite le problème et nous expliquerons la démarche utilisée pour réaliser l'étude.

A. Systèmes Multi-Agents

Un système multi-agents est un outil informatique de modélisation composé d'agents. Les agents sont des entités virtuelles autonomes, capables d'interagir avec d'autres entités et d'agir sur leur environnement. Selon leur comportement, ils peuvent se déplacer, communiquer et apprendre. Néanmoins, ils possèdent une connaissance toujours limitée de leur environnement et des ressources qui leur sont propres (Ferber J. 1995, p.13).

Au sein des sciences cognitives et sociales, les SMA offrent la possibilité de programmer simplement un monde artificiel à base d'agents, à partir de théories, de lois et d'hypothèses (Daudé E. 2003). Il est alors possible d'observer le comportement du système dans son environnement, et sa réaction à la variation de certains paramètres. Tout l'enjeu de cette approche est de concevoir, selon le principe de parcimonie, des règles de fonctionnement simples de nos agents, mais précisément choisies pour répondre à une problématique clairement identifiée. Connaissant toutes les composantes et tous les paramètres du système, l'outil permet alors d'observer et de comprendre un comportement global, avec des effets de structuration, de transition, d'émergence, etc. (M. [START_REF] Vidal | Fundamentals of Multiagent Systems with NetLogo Examples[END_REF]).

Les SMA, bien que disposant d'un très large spectre applicatif, se prêtent particulièrement bien à la simulation de la mobilité car le mouvement, c'est à dire le « changement de position dans l'espace en fonction du temps, par rapport à un système de référence » (Le Grand Robert, Version numérique), est une propriété intrinsèque de l'outil.

-2 -Évolution de la dimension fractale pour un modèle de trafic.

B. Dimension fractale

La géométrie fractale a été définie par Benoît Mandelbrot en 1975 comme « la géométrie de l'irrégulier, du fragmenté, du fractionné » en opposition à la géométrie euclidienne [START_REF] Martin | Quelle est la dimension du massif karstique de la Sainte Baume ?[END_REF]. La dimension fractale permet de décrire l'irrégularité de forme d'un objet à travers les échelles. En géographie, on est souvent confronté à des objets multi-fractale, c'est-à-dire avec une irrégularité de la dimension fractale en fonction de ses résolutions d'observation (Dauphine A. 2004).

De nombreux travaux montrent que la géométrie fractale est une approche pertinente, ou du moins complémentaire à d'autres méthodes, telle que la théorie des graphes, pour analyser et caractériser des réseaux. En effet, « des réseaux topologiquement identiques peuvent être spatialement distincts et desservir le territoire de façon différente » (Genre-Grandpierre C. 1999). La dimension fractale va donc décrire l'hétérogénéité du réseau sur un espace délimité, sachant qu'une dimension (théorique) égale à deux signifierait que le réseau dessert tout point de l'espace, et à l'inverse, une dimension égale à un correspondrait à un réseau rectiligne et mono scalaire.

C. Réseaux et mobilités

Dans ce travail, nous avons calculé la dimension fractale d'un réseau de transport simulé. L'épaisseur des traits que nous visualisons à l'écran et que nous avons mesurée reflète la fréquentation de chaque arc. Nous avons décidé de prendre en compte seulement la fréquentation, et non la densité d'utilisation qui correspond à un flux mesuré (ou simulé) rapporté à la longueur d'un arc (Genre-Grandpierre C. 2000), car nous nous intéressons seulement au chemin emprunté par les taxis et à la récurrence des trajets. Notre méthode est assez similaire à des calculs de dimension fractale d'un réseau routier dont la taille des arcs dépend de la typologie des axes (par exemple, une autoroute correspondrait à l'arc le plus épais). Sauf que, dans notre cas, la hiérarchie du réseau émerge du modèle au lieu d'être définie comme un paramètre initial. Cette émergence va dépendre de la topologie du réseau, de la localisation des points de dessertes, de la densité de la demande de mobilité, mais aussi des principes de déplacement des véhicules pour lesquels nous avons implémenté une procédure d'optimisation des tournées.

D. Questions

E. Démarche

Voici les différentes étapes que nous avons suivies pour réaliser ce travail :  Simuler un service de transport non régulé théorique en SMA ;

 Calculer la dimension fractale de différents moments de la simulation grâce à un export d'images cadencé toutes les 20 itérations logicielles (ou ticks) ;

 Observer l'évolution de la dimension fractale en comparant avec les images exportées ;

 Interpréter les résultats et critiquer la méthode.

-3 -Évolution de la dimension fractale pour un modèle de trafic.

II. Le modèle

Dans cette partie, nous allons fournir des explications précises sur le modèle simulé, puis nous décrirons les modifications que nous y avons apporté pour cette étude.

A. Le modèle initial 1. Contexte

Le modèle utilisé a été extrait d'un premier travail [START_REF] Lammoglia | Simulation d'un transport spontané non régulé, par un système multiagents[END_REF]. Il a été développé dans l'optique de simuler différents degrés d'optimisation pour un service de transport non régulé et très peu contraint. Il s'agissait d'observer, grâce à une analyse statistique exploratoire, différents indicateurs permettant de décrire l'efficacité du transport (nombre de clients total, taux de remplissage par tournée, etc.). Au cours des simulations, nous avons pu observer l'évolution du trafic graphiquement, mais aucune analyse morphologique quantitative des tournées n'a été réalisée. Nous avons choisi de réutiliser le modèle car il intégrait déjà des indicateurs de trafic et vu son caractère purement théorique, il était facile de l'adapter pour ce travail. La méthode présentée ici nous permet donc d'analyser notre service de transport selon une autre approche et de préciser ou de réfuter les hypothèses dégagées au cours des observations.

Composition

Nous modélisons ici les déplacements de deux catégories d'agents mobiles : des villageois qui se déplacent à destination des marchés les plus attractifs grâce à des taxis. Le territoire virtuel de la simulation est constitué de stations qui permettent de prendre en charge des clients à destination de marchés définis selon un potentiel gravitaire [START_REF] Lammoglia | Simulation d'un transport spontané non régulé, par un système multiagents[END_REF]. Les stations se situent aux intersections des routes comme des points de rencontre entre les taxis et les villageois. Elles correspondent aux sommets d'un graphe complet non planaire sur lequel se déplacent les véhicules avec ou sans client(s) dans un espace isotrope, mais non continu. Appliquant le principe de parcimonie, chaque agent a une fonction relativement limitée qui lui est propre.

Les villageois apparaissent aléatoirement (loi random) sur le territoire au début de la journée et en même quantité. Ils choisissent leur marché de destination et si celui-ci est trop éloigné, ils se déplacent vers une station pour prendre un taxi qui les déposera au marché. Les marchés et les stations acquièrent un potentiel d'attractivité selon le nombre de clients captés et de véhicules passés. Une fois arrivés à destination, les villageois disparaissent du modèle. La figure 1 montre comment est structuré l'environnement.

Les taxis prennent les clients et choisissent un itinéraire pour réaliser leur tournée. Une tournée correspond au déplacement d'un taxi à partir de la prise en charge d'un ou plusieurs villageois jusqu'à destination du marché. Selon nos observations antérieures, leur forme dépend du processus d'optimisation utilisé, de la répartition des villageois et surtout de la topologie du réseau. Elles varient plus ou moins en fonction du temps de la simulation. C'est cette évolution qui sera l'objet de cette étude.

Fonctionnement

Nous ne rentrerons pas dans les détails techniques des procédures de nos agents dans cet article. Il est néanmoins important de préciser les processus permettant l'optimisation des tournées.

L'optimisation consiste à maximiser le potentiel gravitaire des stations par le villageois et par le taxi. En effet, le villageois se déplace en fonction du potentiel d'attractivité des stations rapporté à la distance. Les véhicules sont capables de reconnaître les stations possédant la plus forte demande de mobilité, c'est-à-dire les stations où il y a eu le plus de clients embarqués. Les deux agents ont donc une capacité de cognition mais avec une connaissance toujours limitée de leur environnement. Dans ce modèle, nous avons à la fois l'effet de distance qui joue un rôle dans l'organisation des tournées, mais surtout, le comportement plus rationnel des agents.

B. Évolution du modèle

Le modèle que nous avons simulé pour les calculs de dimension fractale est similaire, dans le fond, au modèle initial. Nous avons néanmoins apporté un certain nombre de modifications sur la forme. En effet, le modèle n'est plus adapté pour une analyse visuelle des déplacements des agents, mais il a été modifié pour pouvoir effectuer des calculs de dimensions fractales à un pas de temps prédéfinis.

Dans cette présentation, nous ne nous intéressons plus à l'efficacité du service de transport, mais plutôt à la -4 -Évolution de la dimension fractale pour un modèle de trafic. morphogenèse des déplacements (trajets et tournées confondus). Plus concrètement, nous avons fait en sorte que tous les objets de la simulation (routes, stations, villageois et taxis) soient cachés pendant l'exécution du modèle (à noter que nous pouvons les faire réapparaître à tout moment). Sur l'écran de la simulation, il ne reste plus que la trace des déplacements des taxis. Chaque fois qu'un taxi parcourt un axe, un trait se forme. L'épaisseur de la trace est proportionnelle à la fréquentation de l'axe par chaque taxi. On parlera alors de trafic routier des taxis. Notre indice de trafic correspond au nombre de passages effectués sur chaque arc du réseau, normalisé par la fréquentation de l'arc possédant le plus grand nombre de passages. Le fait de normaliser l'indice nous permet d'avoir un grossissement proportionnel des axes tout en limitant l'épaisseur des traits pour une meilleure lisibilité. Sur les images extraites, nous visualisons les axes en blancs sur un fond noir comme nous pouvons le voir sur les figures 2 et 3.

III. Le calcul des dimensions fractales

Nous allons maintenant préciser la méthode de calcul de dimension fractale, puis nous expliquons comment nous avons utilisé l'information.

A. La méthode et les outils utilisés

Après avoir simulé notre modèle et exporté les captures d'écran, nous avons importé et traité les images sur Mathematica de manière automatique. Il a été nécessaire de convertir les images qui étaient par défaut en niveaux de gris, en points noirs ou blancs.

Les calculs de dimensions fractales ont été réalisés par Maxime Forriez en suivant un algorithme initialement développé par Laurent Nottale, permettant l'estimation d'une dimension fractale par le comptage des boîtes carrées (Forriez M. 2010). Le coté de la plus petite boîte mesure 1 pixel et celui de la plus grande 523 pixels (l'étendue de notre image).

Les algorithmes de calcul ont également été développés sur Mathematica et les graphiques de dimension fractale ont été automatiquement générés à partir du logiciel. Le temps nécessaire pour effectuer tous ces calculs a été d'environ 30 minutes, ce qui est relativement court vu le nombre d'images qui a été traité. La méthode est donc efficace d'un point de vue technique.

-5 -Évolution de la dimension fractale pour un modèle de trafic.

B. L'information extraite

A partir de nos calculs, deux types de graphique de dimension fractale ont été tracés : un avec un ajustement linéaire et un autre avec un ajustement polynomial. En effet, au début de la simulation, les points forment une courbe non linéaire alors qu'ils tendent vers une droite en fin de simulation. Pour chaque pas de temps, c'est-à-dire pour chaque image extraite, deux graphiques ont été créés : 1 080 au total.

Un tableau récapitulatif a été exporté. Nous pouvons y lire pour chaque image :

 le nombre de points comptés (ln N) en fonction de la résolution (ln E) ;

 les coefficients de la droite de régression linéaire avec l'erreur statistique et et la variable t de Student ;

 le coefficient de corrélation de la régression linéaire ;

 les trois coefficients des polynômes du second degré, avec toujours l'erreur statistique et la variable t de Student ;

 le coefficient de corrélation et de détermination du polynôme.

Ainsi, nous avons pu construire un graphique représentant l'évolution des coefficients de la droite de régression linéaire et surtout le graphique de l'évolution de la dimension fractale qui est la valeur absolue du coefficient a de l'équation y = ax + b.

IV. Résultats

Dans une dernière partie, nous allons présenter les résultats que obtenus. Nous essayons, ensuite, de les interpréter en distinguant les principales informations de ce travail à retenir.

A. Observations a) Fonctions d'ajustement

En observant les graphiques, on se rend compte que l'on passe d'une courbe non linéaire (Figure 4) à une droite au début de la simulation, d'où l'intérêt de calculer l'ajustement polynomial en plus de l'ajustement linéaire. L'équation de la courbe pour la première image est ln N = 6,7 -2,29(ln E) + 0,21(ln E)², mais, dès la deuxième image, on se rend compte que la courbure s'atténue. On observe sur la figure 5 une droite, aux alentours des 600 itérations, alors que le coefficient de second degré est égale à 0 à partir des 1 400 itérations. Notre simulation se faisant sur 9 000 itérations et la transition étant relativement rapide, nous pensons que cela ne remet pas en cause la pertinence de la méthode. Il est néanmoins important d'interpréter et de comprendre cette observation (cf. IV. B. a)). A l'aide des exports d'images, nous avons pu comparer différentes phases de la simulation et aller plus loin dans nos observations :  0 -80 ticks : les trajets sont très concentrés autour des deux marchés du bas (cf. Figure 2). Les déplacements des taxis sont minimes car ils vont chercher les villageois les plus proches du marché polarisant, afin d'optimiser leurs tournées ;

-6 -Évolution de la dimension fractale pour un modèle de trafic.

 80 ticks : il apparait une forte concentration de déplacements sur un petit axe entre les deux marchés du bas. On est en présence d'un arc qui semble jouer un rôle de centre, ou du moins, de passage obligé pour la desserte des deux marchés voisins. Cet arc, bien que plus discret, se distingue tout au long de la simulation ;

 1 300 -5 880 ticks : les tournées se dispersent et le troisième marché, qui jusqu'alors, était desservi par un seul taxi isolé, se rattache au réseau (cf. Figure 6). Sur cette période, les taxis ont commencé à s'éloigner de l'aire d'attraction de leur marché privilégié ;

 5 880 -9 000 ticks : la forme du réseau ne semble plus trop évoluer. On a l'impression que les taxis ont exploré les stations les plus intéressantes (cf. Figure 3), même si, de temps en temps, il apparaît de nouveaux arcs. La hiérarchie des arcs se structure et la différence de taille entre les traits s'atténue (à cause de la normalisation par l'arc le plus fréquenté).

c) L'évolution de la dimension fractale

En analysant la courbe (cf. Figure 7), nous pouvons repérer des seuils et des étapes que nous comparerons avec ceux qui ont été observés précédemment :  0 -80 ticks : la dimension fractale évolue beaucoup ( 1,2 D n 1,3 ), avec une croissance soudaine. Cependant, comme nous l'avons vu précédemment, cette partie de la simulation ne peut pas être prise en compte puisque nous utilisons un ajustement linéaire alors que, sur cette période, nous sommes en présence d'une polynomiale ;

 80 -800 ticks : la dimension fractale augmente toujours considérablement avec des oscillations très courtes et assez prononcées ;

 800 -2 600 ticks : la croissance commence à s'amortir et l'on observe beaucoup moins de variations. On voit bien que les flux se structurent, et que la hiérarchie et l'étalement de ses derniers commencent à se stabiliser ;

 2 600 -9 000 ticks : pour les trois quart de temps de la simulation, on observe que la dimension fractale varie très peu ( 1,47 D n 1,51 ). La forme du trafic est donc structurée et notre modèle peut être considéré comme stable.

Globalement, on se rend compte que la dimension fractale augmente de 0,3 au cours de la simulation pour arriver un maximum de 1,5. L'emprise spatiale de la desserte s'est donc rapidement améliorée, et elle paraît correcte sachant que la dimension d'un réseau est théoriquement bornée entre 1 et 2. Le passage d'une polynomiale à une droite et l'augmentation importante de la dimension fractale, témoigne d'une meilleure emprise spatiale des trajets sur l'environnement. Il y a une optimisation de la forme des flux dessinés, à la fois en termes de taille et d'homogénéité spatiale, par rapport à l'environnement. En effet, au fur et à mesure que la simulation progresse, on voit que les taxis élargissent leur tournées, en explorant des arcs du réseau de plus en plus éloignés des marchés.

-7 -Évolution de la dimension fractale pour un modèle de trafic.

b) Le phénomène d'attracteur

Mis à part les 2000 premières itérations, nous avons vu que la dimension fractale évoluait très peu au cours de la simulation. Les flux semblent donc se structurer rapidement en début de simulation, et atteindre une forme relativement stable. La structure semble être stable, aussi bien en termes de hiérarchie de fréquentation (épaisseur des traits) qu'en termes d'étalement spatial. Les taxis répètent les mêmes trajets puisqu'ils privilégient les tournées les plus attractives. Nous pouvons alors parler de phénomène d'attracteur car, même si de temps en temps, les taxis découvrent de nouvelles stations, la structure du système est tellement forte que la dimension fractale du réseau n'évolue quasiment plus.

La méthode présentée dans cet article ne permet pas de vérifier quel paramètre détermine le plus la mise en place de l'attracteur. Néanmoins, nous avons vu que les flux étaient fortement structurés par la topologie du réseau et par le comportement des taxis. En effet, les taxis desservent en priorité les stations proches des marchés : procédure d'optimisation de nos agents. Et ils s'éloignent peu à peu en explorant des stations non desservies, ou des villageois attendent d'être pris. La topologie joue alors un rôle important.

V. Conclusion

In fine, nous pouvons dire que le calcul de dimension fractale est un véritable plus pour analyser la forme et la hiérarchie des flux simulés. L'analyse d'image et l'approche fractale sont complémentaires puisque l'une nous permet de voir comment évolue spatialement les flux, en mettant en relation la localisation des marchés, la topologie du réseau, etc. ; alors que l'autre nous permet de définir des seuils et d'observer des tendances globales, comme la structuration du système, sa stabilisation, etc. L'évolution de la dimension fractale permet donc d'analyser quantitativement l'évolution morphologique du système à travers sa gamme scalaire, et indépendamment de l'observation visuelle. L'attention peut ainsi être portée sur les phénomènes spatiaux et territoriaux, ce qui permet finalement d'observer et d'expliquer plus précisément l'interaction entre les agents et l'environnement au cours de la simulation.

Cependant, certains points restent à être éclaircis. Nous avons vu qu'en début de simulation, la dimension fractale observée à partir de la droite de régression linéaire n'était pas bien adaptée. Il serait alors intéressant de se concentrer sur cette étape pour comprendre plus précisément comment se met en place le système et quel est l'influence des premières itérations du modèle sur le reste de la simulation. De plus, tout au long du travail nous avons mis en relation les observations avec nos connaissances sur le fonctionnement du modèle (comportement des agents, topologie du réseau, etc.) mais nous n'avons pas pu tester précisément qu'elle était l'influence de chaque paramètre sur l'évolution morphologique des flux.

Globalement, ce travail montre non seulement que l'analyse multi-dimensionnelle d'un flux peut être utilisée pour comprendre et expliquer la structuration d'une desserte, mais il montre aussi que la méthode employée est relativement facile à mettre en place. Elle nous semble plutôt reproductible et applicable pour d'autres modèles. Nous prévoyons d'ailleurs de la réutiliser, et de la développer pour des simulations ultérieures.

VI. Perspectives

Ce travail a eu l'avantage d'éveiller un certain nombre de perspectives pour nos recherches sur la simulation de systèmes de transport.

Dans un premier temps, il serait intéressant d'utiliser la dimension fractale comme un indice supplémentaire de comparaison entre différents scénarios de simulation. La mise en comparaison nous permettrait-elle de mieux comprendre l'influence de nos procédures ? Est-elle un moyen efficace de distinguer les conséquences morphologiques et spatiales de différents scénarios de simulation ?

Concernant les indices, il serait intéressant de voir s'il existe des relations entre les indices déjà observés et calculés (indices orientés transport) et la dimension fractale. Nous avons, par exemple, remarqué que la courbe d'évolution de la dimension fractale ressemblait étroitement à la courbe obtenue avec l'indice d'efficacité qui le nombre de stations traversées, avec prise en charge de clients, rapporté au nombre total de stations traversées. Il est possible qu'il y ait une forte ressemblance entre les deux indices, l'un étant peu être plus pertinent que l'autre pour observer la morphogenèse des flux simulés ? Il serait aussi intéressant de programmer une petite interface de visualisation de la simulation (dessin des flux) combinée à l'évolution de la dimension fractale. Cela nous permettrait de comparer l'information de manière beaucoup plus intuitive. La visualisation serait alors animée, avec la possibilité de mettre en pause le défilement des séquences, de revenir en arrière etc., pour une observation précise et approfondie de nos données.

Enfin, concernant l'influence des paramètres du modèle sur la morphogénèse des flux et sur la dimension fractale, il serait intéressant de pouvoir intégrer directement dans le programme de simulation, un algorithme de calcul de dimension fractale. Cela nous permettrait de tester dynamiquement l'influence de chaque paramètre sur la structuration du système.

Figure 1 :

 1 Figure 1 : Écran de simulation à l'initialisation.

Figure 2 :

 2 Figure 2 : Écran de simulation à 220 ticks

Figure 4 :Figure 5 :

 45 Figure 4 : Courbe de dimension fractale avec ajustement polynomial ( 20 ticks)

Figure 6 :

 6 Figure 6 : Raccordement du troisième marché (5 880 ticks)

Figure 7 :

 7 Figure 7 : Évolution de la dimension fractale des flux simulés B. Interprétations a) Effet de taille L'ajustement polynomial, en début de simulation, nous montre que les points recensés sont répartis de manière très hétérogène sur l'environnement. Les flux sont fortement concentrés à certains endroits et leur taille est très petite comparée à la taille de l'espace d'étude. Ce point concorde avec nos observations puisque nous avons vu qu'en début de simulation, les taxis vont chercher les villageois à proximité des marchés. Leurs tournées sont donc concentrées autour de ces points.

Ils permettent de suivre statistiquement et très précisément l'évolution d'un système, et la structuration des formes s'y observe de manière intuitive. Pourtant, ce sont des outils beaucoup moins pertinents lorsqu'il s'agit de quantifier l'évolution de ces formes. Le calcul de dimension fractale étant une méthode reconnue pour analyser la forme des réseaux à travers les échelles (Genre-Grandpierre C. 2010), nous proposons dans cet article de l'articuler avec un modèle de trafic simulé en SMA. L'étude essayera, en complément de l'analyse visuelle classique sur l'interface de simulation, de quantifier et de mieux comprendre la structuration des flux sur un réseau, à travers plusieurs niveaux d'observation. Dans notre cas purement théorique, il est difficile de parler d'échelles. Nous essayerons, néanmoins, d'évaluer l'apport d'une approche multiscalaire, ou du moins multi-dimensionnelle, pour la simulation d'un service de transport en SMA. La capacité descriptive de la méthode, ainsi que sa facilité d'application et son caractère reproductible seront jugés. ******


Jean-François Girard
email: jf.girard@brgm.fr

Nicolas Coppo
email: n.coppo@brgm.fr

Pierre Wawrzyniak
email: p.wawrzyniak@brgm.fr

Bernard Bourgeois
email: b.bourgeois@brgm.fr

Jean-Michel Baltassat
email: jm.baltassat@brgm.fr

Alain Gadalia
email: a.gadalia@brgm.fr

Resistivity Imaging for Geothermal Exploration, using Controlled-Source EM where Magneto-Telluric is Not Applicable: Model and Field Study

Keywords: CSEM, Resistivity Imaging, Borehole Casing, Martinique, Geothermal Exploration

Resistivity imaging is a key parameter in most geothermal exploration programs, and particularly in volcanic environment. It is assumed that resistivity variations allow imaging the caprock, but also hydrothermal weathering or preferential water flow. The geothermal fluid is generally brine water which drastically decreases the electrical resistivity and the temperature increase also decreases resistivity. The resistivity signatures for several conceptual geothermal reservoirs can be found in the literature.

Magneto-telluric (MT) is generally used to image resistivity variations down-to a relevant investigation depth of several kilometers. Based on natural source signal, MT prospection efficiency depends on the Sun activity during the survey but moreover depends on the noise conditions. In many cases, because industrial activities have been developed close to the geothermal resource, the noise conditions make it difficult to obtain reliable MT tensors and hence a good resistivity image. Generally, the only way to counter is recording longer time series, to apply robust noise filtering and combining with a remote filtering. The noise issue in MT prospection is even more drastic in Island context.

We investigated the substitution of controlled-source EM instead of MT measurements close to urbanized area. The distance constraints to respect the far field conditions are so challenging that they are often logistically not possible. Indeed, when it is possible to measure the receiver stations far enough from the source, the distortion due to the controlled-source disappear. But when the conditions for applying standard processing of CSAMT are not fulfilled, it is necessary to consider the source effect to interpret properly the EM response.

We have studied and performed EM imaging in the near field, using a pair of pre-existing boreholes to inject high current into the ground through metallic casings. Based on numerical modeling, we propose a methodology to obtain maps and section of apparent resistivity. The results obtained were confronted to previous geophysical campaign results performed in the 1980's and recent shallow prospection. This measuring protocol was applied to prospect the Lamentin area (Martinique, Lesser Antilles, France). This survey was performed in 2013 within the framework of a large exploration program founded by the FEDER, ADEME, Regional Council and SMEM designed to explore the geothermal potential of Martinique.

INTRODUCTION

Resistivity imaging is a key parameter in most geothermal exploration programs, and particularly in volcanic environment. It is assumed that resistivity variations allow imaging the caprock, but also hydrothermal weathering or preferential water flow. The geothermal fluid is generally brine water which drastically decreases the electrical resistivity and the temperature increase also decreases resistivity. One can find a snapshot in the use of geophysics in the "Geothermal Exploration Best Practices -Geology, Exploration Drilling, Geochemistry, Geophysics", published by the IGA Academy (2013). Based on a European initiative, in the framework of the I-Get European project, a review has been published [START_REF] Baltassat | Integrated Geophysical exploration technologies for deep fractured geothermal systems (I-GET) -Review of geophysical exploration methods applied to deep fractured geothermal reservoir[END_REF].

Several organizations, and dedicated workshops have proposed to hierarchize the needs to improve the exploration methods, and one could quote the "Roadmap for strategic development of geothermal exploration technologies" after the 38th workshop on geothermal reservoir engineering in Stanford [START_REF] Philips | A ROADMAP FOR STRATEGIC DEVELOPMENT OF GEOTHERMAL EXPLORATION TECHNOLOGIES[END_REF]. Resistivity imaging has been particularly used in geothermal exploration, because of the strong link of the electrical resistivity with fluid content, weathering signature, large depth of investigation and logistically easier than seismic for large depth. Progress in EM prospection have benefited from the seabed logging (or marine CSEM) which quickly developed since 2000 [START_REF] Edwards | Marine Controlled Source Electromagnetic: principles, methodologies, future commercial applications[END_REF], at least in terms of imagery, and management of large dataset [START_REF] Commer | Three-dimensional controlled-source electromagnetic and magnetotelluric joint inversion[END_REF] and combined use with dense seismic and borehole data. A recent review of EM use in geothermal exploration has been done by [START_REF] Munoz | Exploring for Geothermal Resources with Electromagnetic Methods[END_REF]. He gives a list of progress, many field applications all over the world. He underlines successes but also failures in rare documented case studies. Major success rely on the strong correlation of the resistivity with the key geothermal parameters, but equivalent solutions, lack of knowledge of the local geological signature may lead to severe errors.

In the first part of this paper, we present the basic principle of CSEM and the specific way we applied it. Indeed, we injected electrical current using the metallic casing of boreholes to enhance the EM response. We explain the data processing and illustrate the performance of the array with a numerical synthetic example.

The second part of this paper deals with a field application. The geothermal potential of Martinique Island (Lesser Antilles, France) has been extensively investigated since more than 50 years. The first exploration started in the 60' in the Plaine du Lamentin (south of Fort-de-France) and has been extended in this area in the 80's and orientated towards the southeastern flank of the Montagne Pelée. Then, the southwestern flank of the Montagne Pelée and the Anses d'Arlet were identified of potential interest and explored in the 2000's. Finally, three exploration wells were drilled in the Plaine du Lamentin in 2001 and confirmed the presence of a medium temperature geothermal resource. In 2013, resistivity imaging was chosen to map this later area, in order to estimate the extent of the reservoir. Combined with the borehole geological logs, a new geological and geochemical survey, other available geophysical results (gravity, magnetic, shallow resistivity) the goal was to get a better evaluation of the geothermal resource of the Lamentin area. This campaign provided useful results for the geothermal exploration but thanks to a previous deep DC electrical resistivity campaign in the 80's along a profile crossing the area, it has been possible to validate the proposed the methodology at depth. An airborne TEM survey performed over all Martinique in 2013 allowed validating shallow CSEM results. In the second part of the paper, we compare the apparent resistivity maps and sections with the TEM and deep ERT.

CONTROLLED SOURCE ELECTROMAGNETISM

The Controlled Source Electro-Magnetism (CSEM) is a geophysical method based on the imagery of electrical resistivity. Unlike MT method, the signal source is not passive but generated by a transmitter. The first interest is that it is less sensitive to man-made electromagnetic noise due to powerlines, electrical plants, etc…which make EM passive methods such as MT difficult or almost impossible in noisy area. The duration for 6 to 8 frequencies, starting from 0.125 Hz to 1 kHz, is generally 1 hour. Depending on site conditions (current intensity, noise) these parameters should be adapted to obtain sufficient signal to noise ratio as in Figure 1. If the controlled source is far enough, several kilometers from the survey area for frequencies > 1 Hz, the far field approximation is fulfilled and the CSEM data can be processed as audio MT data (controlled source audio magneto-telluric) corresponding to the shallowest response of MT. Considering a targeted investigation depth of 2000 m or more, the far field assumption cannot be reached sometimes and especially in islands. Then, the controlled-source EM data should be processed with another protocol than in MT.

The depth of investigation is controlled both by the signal frequency and by geometry of the transmitter. Particularly, if instead of using surface current injection, metallic casing of boreholes are used to enhance de contact resistance but also inject current closer to the targeted depth (see Figure 2). In this latter case, the geometry of the well and the length of the metallic casing should be considered to estimate the source effect and remove it. Using borehole metallic casing as a long electrode was already used, and for instance one could refer to [START_REF] Hatanaka | Threedimensional modelling and inversion of the Mise-à-la-Masse data using a steel-casing borehole[END_REF] for a recent use for geothermal energy, but this advantages of this array was discussed by [START_REF] Bourgeois | First modelling results of the EM response of a CO2 storage in the Paris basin[END_REF] for monitoring CO2 injection in a limestone deep aquifer. Nowadays, we provide the results as apparent resistivity map and sections (corrected from frequency and geometrical factors, topic discussed in this paper). Note that, if it is possible to derive geometrical information from a single MT sounding (strike direction, dipping, etc…), a single CSEM station should be considered as a deep electrical sounding and do not provide geometrical information by it-self. When used along profiles or with a homogeneous density over a surface, the resistivity maps and sections provide geometrical information.

Because the resistivity is estimated from the electric field components, it is not necessary to measure magnetic field at stations for CSEM use only. That makes the logistic easier and thanks to shorter recording duration, several CSEM soundings could be performed the same day with the same equipment.

For the sake of demonstration, we simulate the electric field measured at surface of a 2 layers ground (5 Ohm.m then 100 Ohm.m deeper) with a conductive anomaly in the vicinity. We consider a current injection via a pair of boreholes 2.5 km apart and connected by a cable (see Figure 3). This scenario is directly suggested by the field experiment discussed in the next part. As in DC electrical imaging, one can convert the in-phase electric field in apparent resistivity considering the transmitter point injection and the location of the receivers. This well-known transformation is straightforward and classicaly used to normalized data before inversion and electrical resistivity tomography (ERT). This is the classical way of using arrays like rectangle or gradient, popular in mining exploration: the resistivity map highlight the anomalies below the area covered by receivers. As depicted in Figure 4, this approach is not suitable for measurements over a several kilometers area, in a 5 Ohm.m environment at 8 Hz. Numerous artifacts appears with a high dynamic range, larger than the anomaly in a homogeneous ground. If one considers the use of normalizing the measured field by the synthetic response at 8 Hz, over a homogeneous medium with 5 ohm.m.resistivity, one gets a far better resistivity image (Figure 4, right). It is important to compute the frequency dependent normalizing field above a ground resistivity with value close to the field to take into account phase rotation:

This normalization aims to attenuate 2 effects: a geometrical effect (due to the proper transmitter geometry) and a frequency effect link with the phase rotation and attenuation in the ground. Figure 5 shows a comparison of these two terms. The interesting fact is that in a quite conductive environment (5 Ohm.m here) and considering frequencies > 2 Hz, the exact borehole equipment and the uncertainty in the resistance contact all along the casing are of secondary importance in comparison with the frequency effect which creates phase rotation and attenuation of the electric field. The stronger effect being computable, this is the approach we have used in the field survey keeping in mind the limitation of the apparent resistivity approach, as illustrated below in Figure 6. At 0.1 Hz, the skin depth is more than 3500 m and the response of the conductive bodies (2 metallic boreholes + northern anomaly located in the first 400m) merge and dominate the EM response. Despite the resistivity below 700 m is homogeneous equal to 100 Ohm.m, the apparent resistivity is not at all a direct image of the ground. When the distance between the boreholes (or point injections) are similar or greater than skin depth, the "source" effect cannot be suppressed so easily and a full inversion is needed to overcome this difficulty. This is a current topic of development in our team and is out of the scope of this paper. Nevertheless, the suitable depth and frequency range was in agreement with the needs for the survey in the Lamentin area.

CSEM FIELD SURVEY IN THE LAMENTIN AREA

The Lamentin area is partly urbanized (including housing and commercial centers close to Fort-de-France) and is equipped with an international airport. The remaining zone is whether densely cultivated whether in the mangrove. Considering the high anthropic noise (powerlines and various installations) it was then proposed to investigate at depth using a Controlled-Source Electro-Magnetism approach (CSEM).

The conditions for applying standard processing of CSAMT being not fulfilled, it was necessary to compute a specific normalization to correct the source effect. Indeed, when it is possible to measure the receiver stations far enough from the source, the distortion due to the controlled-source disappear. But the geography of the area of interest and the pre-existing exploration boreholes used to inject current at depth make it impossible in this case.

EXPLORATION RESULTS

45 receiver stations were measured over a 10x10 km area during 6 days. 35 stations were measured on-shore, with electric dipoles and magnetic coils. 10 stations were measured off-shore, in shallow water (1 to 5 meters depth) in the Lamentin bay. The frequency band was covered using 7 fundamental frequencies ranging from 0.125 up to 512 Hz with a factor 4 between two adjacent frequencies. The signal waveform was a square wave generating many harmonics allowing to double records. GPS positioning and time synchronization was used. Resistivity maps at single frequency were converted using the normalization described before. An estimation of the investigation depth is based on the skin depth ():

√ √ For frequencies higher than 4 Hz, the general pattern is quite similar (see Figure 7, left). It reveals a very conductive anomaly (< 3 Ohm.m in apparent resistivity) centered on the borehole LA101. This anomaly is clearly limited laterally and migrate in the NW direction with decreasing frequency. The general shape of this conductive zone is de-correlated from the coast line and the offshore stations do not appear as outliers. The sea water intrusion being important in all the western part of the covered area, this continuity is in agreement with the known hydrogeological context.

A drastic change appears for frequencies equal or lower than 2 Hz (see Figure 7, right). Apparent resistivity appear then higher, contrasts are smoother and the boundary of the basement with less sea water intrusion is well correlated with existing boreholes and the few older geophysical surveys results. A less resistive trend appear going N/N-W but only 4 stations (33,34,35,36) along a straight profile was measured in this zone and it is not possible yet to speak about a channeling of deep brine coming from the northern topography associated to the volcanic system of the Carbets. Despite all the limitations, we extracted several profiles, using the frequency along the Y-axis, and we depict in Figure 8 the apparent resistivity pseudo-section along a profile crossing the 4 boreholes drilled in the early 2000. On the north-western side, a shallow resistive zone correspond well with the topographic end of the Carbet (no topographic is applied here, but it flatten the top of the conductive zone. At the abcisse 3000 m, a clear change in resistivity pattern is well correlated with a major fault [START_REF] Westercamp | Carte géologique de la France (1/50 000[END_REF]. When one overlay the isotherms curves derive from temperature logs, it follows closely the conductive anomaly which is also well correlated with the kaolinite dominating clay considered as the more permeable medium [START_REF] Mas | Clay-mineral signatures of fossil and active hydrothermal circultions in the geothermal system of the Lamentin Plain, Martinique[END_REF] The Lamentin plain has known at least two periods of geothermal activity and the classical conceptual model of a reservoir rich in illite covered by a caprock rich in smectite. The issue involving petrology, geology and water geochemistry in this complicated context is out ot the scope of this article, but it is striking that the deepening of the isotherm between absciss 4000-5000m, which do not rely on any in-situ temperature measurement is, at first look, not compatible with the geophysical result. It would suggest a lateral arrival of the geothermal fluid more probable than a vertical root. To enlarge the CSEM measurement westward (and Fortde-France, the island largest city) was not considered during this short survey (10 days in total) but given the coherent results obtain when mixing on-shore and off-shore measurements, and the signal to noise ratio obtained with the used of the boreholes Carrere and Desgras as current injectors up to 8 km away, it would suggest to densifiate the measurement in the north and north-west part of the area.

CSEM RESULTS VALIDATED

The Lamentin plain has a rich exploration history, started in the 1980's, for geothermal resource but also on hydrological point of view. Especially, an airborne survey using skyTEM system over all Martinique Island has been performed in 2013, coordinated by BRGM, the French geological survey. It is straightforward to compare high frequency CSEM response with TEM mapping. Figure 9 shows the good correlation between apparent resistivity at 128 Hz (investigation depth~70m) and the resistivity layer at 60m. The white line delineate the CSEM area, based on the interpolation of 45 stations. The black dashed line delineate the resistivity mapping using airborne TEM. One should keep in mind that investigation depth is limited to 200 m maximum in this low resistive environment, and the dense housing prevent from using helicopter in may places. Moreover, powerlines drastically deteriorate TEM response, particularly at depth. It is a good combination to fill the holes in the TEM map with CSEM results, and a constant factor 3 was applied to surimpose TEM and CSEM results in Figure 9. The correlation is very good, even if the distance between CSEM stations is around 400 m compared to airborn TEM 10m along flight lines (100m or 200m generally in between, except in area studied for hydrology with denser data).

Another comparison, at depth, was possible with the results of DC electrical imaging performed in 1984 (Puviland and Doré). Data sheets were copied and inverted in 2D along the profile named DD2 on the maps. A dipole-dipole profile, using MN spacing 500m was performed before the airport was built. The comparison if depicted in Figure 10. A constant factor of nearly 10 is observed (gross estimation) but eh general pattern is in good agreement. Thanks to these 2 comparisons, it was demonstrated that in such an environment, CSEM resistivity imaging can be applied successfully and provide useful insight for geothermal resource exploration.

CONCLUSIONS

A variant of on-shore CSEM method application using boreholes is presented. The processing is demonstrated first on numerical example then compared in the field to independent results (deep ERT and shallow TEM). It proved to be logistically interesting and efficient to map resistivity in such anthropic area for geothermal exploration.

Known limitation in the use of apparent resistivity is recalled and limits were calculated in the studied environment. Nevertheless, the way to overcome it is clear: 3D CSEM inversion. It is currently developed in our team and this case study will be especially interesting to apply it thanks to the a priori knowledge and local validation that exists from previous surveys and boreholes.

Bridge between clay mineralogy and electrical resistivity is also a subject of research currently under investigation.

Figure 1 :

 1 Figure 1: Example of CSEM data processing for an electric channel: a) time serieof injected current (7 A) and recorded signal for a 200 m length dipole, b) frequency spectrum for Current c) modulus of ratio E/I. Black dots indicate data at measuring frequencies (here : 0.5 Hz, 1.5 Hz, etc…)

Figure 2 :

 2 Figure 2: Electrical current density (log scale, A/m²) below a surface injection (left) and when using a metallic casing (right side, downto 1300 m here) for 2 Hz current injection. The current flows preferably at depth all along the borehole and particularly in the conductive layer. The ratio target response versus primary source is more favorable with the casing injection.

Figure 3 :

 3 Figure 3: In-phase Electric field (8 Hz) measured at surface, in black the cable between two boreholes and to the north, the extension of a conductive anomaly. Right, a resistivity cross-section: ground is 5 Ohm.m downto 700 m then 100 Ohm.m deeper. A targeted tilted conductive anomaly (0.3 Ohm.m) is displayed.

Figure 4 :

 4 Figure 4: Left, 8 Hz in-phase electric field amplitude converted in a highly distorted apparent resistivity map (in Ohm.m) using a pure geometric factor (DC assumption). Right after a normalization based on the computation of the EM field at 8 Hz over a homogeneous medium at 5 Ohm.m, the anomaly is well resolved with few artifacts.

Figure 5 : 8

 58 Figure 5: 8 Hz in-phase electric field converted in apparent resistivity map (no anomaly here, only homogeneous medium at 5 Ohm.m). Left, error introduced when normalizing with the exact geometry but with a DC assumption at 5 Ohm.m. Right, error introduced when normalizing by surface electrode response (instead of 450 m long boreholes) calculated at 8 Hz over a 5 Ohm.m ground.

Figure 6 :

 6 Figure 6: 0.1 Hz in-phase electric field converted in apparent resistivity map (anomaly + 2 layers ground): DC assumption geometric factor correction and the normalization using frequency computation provide almost the same result.

Figure 7 :

 7 Figure 7: Left, apparent resistivity map (CSEM 2013), from the in-phase Electric field component, TX Frequency 32 Hz, (/2 = 141 m) and right TX frequency 2 Hz (/2 = 562 m), both normalization by MAMx2-400m, 5 .m, at corresponding frequency.For frequencies higher than 4 Hz, the general pattern is quite similar (see Figure7, left). It reveals a very conductive anomaly (< 3 Ohm.m in apparent resistivity) centered on the borehole LA101. This anomaly is clearly limited laterally and migrate in the NW direction with decreasing frequency. The general shape of this conductive zone is de-correlated from the coast line and the offshore stations do not appear as outliers. The sea water intrusion being important in all the western part of the covered area, this continuity is in agreement with the known hydrogeological context.

  and location of geothermal fluid up-flow corresponding with known geothermal spring traces in surface. On the south/south-Apparent Resistivity map at 32 Hz Apparent Resistivity map at 2 Hz Apparent Resistivity map at 32 Hz Apparent Resistivity map at 2 Hz est side, the abrupt change is well correlated with the dry wells Carrere and and Desgras (this later, a bit apart from the profile P5) and absence of surface springs indications.

Figure 8 :

 8 Figure 8: On P5 are surimposed isotherms, from Traineau et Négrel (2012). Boreholes locations are indicated by black squares CLF= Californie, DSG=Pointes-Desgras, CAR=Carrère. Horizontal arrows below CLF indicate the main water flow, Traineau et Négrel (2012). The black vertical dashed line are resistivity discontinuities coincident with 2 known faults.

Figure 9 :

 9 Figure 9: Apparent resistivity map (csem 2013 -128 Hz ~ 70 m) jointly presented with Airborne TEM -60m -(MarTEM survey, 2013)

Figure 10 :

 10 Figure 10: Left, Dipole-Dipole profile n°2 reprocessed (Puvilland et Doré, 1984) in log10 of inverted (2D) resistivity, and pseudo-sections of apparent resistivity from CSEM data for profiles P2 (partly along DD profile n°2).

ACKNOWLEDGEMENTS

The authors wish to thank the FEDER and ADEME institutions, the Conseil Régional and the Syndicat Mixte d'Electricité de la Martinique (SMEM) for funding this project. The numerical modeling of CSEM synthetic case was performed in the framework of the Integrated Methods for Advanced Geothermal Exploration -IMAGE project, which has received funding from the European Union's Seventh Programme for research, technological development and demonstration under grant agreement No: 608553.