\subsection*{Pixel Carpet}
Pixel Carpet is a result from a collaboration between data visualization researchers and computer security engineers. The idea behind this collaboration is to take the best knowledge from both fields to develop through a user oriented approach a solution to represent multi-dimensional data sets, specifically log files. The types of logs for which the application was designed are SSH logs, given that they are a crucial part in the post-attack analysis, and Apache access logs, to allow identifying and understanding possible traces of security breaches. The main purpose of pixel-oriented visualization techniques is to represent as many data objects as possible on the screen at the same time by mapping each data value to a pixel of the screen and arranging the pixels in a suitable way \cite{PixelOriented_paper}.

\begin{figure}[h]
    \centering
    \includegraphics[scale=.3]{Figures/chapter4/PixelCarpet/description.png}
    \caption{Pixel Carpet multipixels construction \cite{PixelCarpet_paper} }
    \label{fig:PixelCarpet_desc}
\end{figure}

Among the various possibilities, the developers have chosen to use a pixel map in order to graphically represent parameters such as IP, source country and request or message, grouped together in a single column (figure \ref{fig:PixelCarpet_desc}). In this way there are many small columns, each representing a row of the file, which produce a denser visualization and allow the patterns to be recognized.
Besides the subdivision in pixels, the most important parameter is the colouring. Within the application there are various shades from which it is possible to choose but the most important concept is that the range of colors and not fixed colors has been chosen to represent the frequency that that single entry has within the log file. So, for example, the pixel corresponding to the country will be of a color that represents a higher percentage, the more that entry is present in the inserted file, as well as for the IP address and the message or request.

Although the type of data chosen is widespread on a large scale, the requested input file is in .json format and not .csv or .log and therefore a conversion process is required before being able to use the visualization. Furthermore, the required JSON formatting is specific (\ref{json_example}) and a different formatting causes the script not to work.

\begin{lstlisting}[language=json,caption={JSON format example}, label={json_example},firstnumber=1]
{   
    "Host": "200.120.190.33",
    "Log Name": "-",
    "Time": "23:18:40",
    "Time Zone": "GMT+0100",
    "Method": "GET",
    "URL": "/wp-content/uploads/the-legend-of-zelda-skyward-sword-boxart.jpg",
    "ResponseCode": 200,
    "Bytes Sent": 217935,
    "Referer": "http://ba-k.com/threads/3605485-MEGA-POST-JUEGOS-DE-WII-POR-TORRENT",
    "UserAgent": "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36",
    "Country": "Chile"
}
\end{lstlisting}

Unfortunately, given the nature of the research project, the tool should be considered a prototype. The only ways available to try its features are through the demo available online \cite{pixel_carpet_demo} and by downloading the source code \cite{pixel_carpet_github} and then launching it on your machine. The differences between the two versions, demo and offline, are minimal and are mainly a different arrangement within the menu, and for the demo version a smaller choice of options for the color range. However, having the source code available allows you to modify the input files that the tool must display. In addition to the code for the tool, the developers provide two log files, one with geographic data and one without, containing an attack attempt, to provide an overview of the use of the application. The other types of logs with which it was developed and tested have not been made available for privacy reasons. 

Using the log file containing the suspicious behavior, the display below is reproduced (figure \ref{fig:PixelCarpet_attack}). From a first glance, the patterns present among the various requests present in the file are evident. Trying to analyze the longer pattern below, we can see how the series of requests highlighted in a similar way and close in time can be traced back to a series of requests, or to an attempt of Local File Inclusion attack. LFI is an attack technique in which attackers trick a web application into either running or exposing files on a web server. The following image (figure \ref{fig:PixelCarpet_menu}) shows the various options that can be activated via the Controls menu. For example, in the proposed image it was chosen to mark the entries with the same URL as the selected one, all highlighted by the green box, and not to apply any filter. Furthermore, by opening the Key menu it is possible to have a better view of the graphical representation of the selected entry and to compare it alongside the frequencies within the file through the gradation of the colors represented.

Given the nature of a prototype, unfortunately there are many limitations. The tool is not optimized and there are no specifications regarding the maximum supported size of the files to be analysed, even if with a simple test conducted with a generic 30MB file it was found that the current version does not allow the start of the visualization. Then, in the case of readable files but in any case with a large number of entries, the visualization could not be easy to understand due to the large amount of data to be represented. All these assessments are a consequence of the fact that the main purpose of the research was not to develop a product but to demonstrate the validity of the visualization approach which can turn raw unlabeled data into an image that makes easier to survey and inspect.

\begin{figure}[h]
    \centering
    \includegraphics[scale=.55]{Figures/chapter4/PixelCarpet/pixelcarpet_Attacck.png}
    \caption{Pixel Carpet usage example}
    \label{fig:PixelCarpet_attack}
\end{figure}

\begin{figure}[h]
    \centering
    \includegraphics[scale=.55]{Figures/chapter4/PixelCarpet/pixelcarpet_Menu.png}
    \caption{Pixel Carpet Menu example }
    \label{fig:PixelCarpet_menu}
\end{figure}
\FloatBarrier

From a development analysis point of view, given the mode of cooperation between teams of different skills, in the \emph{Visualization Goals} definition phase we can see a combination of different elements such as interviews, single observations and an ideation workshop. All these different interactions have led to the definition of well-defined objectives including, for example, Display raw data, and Encourage explorative analysis. Subsequently, for the \emph{Data Preparation}, the files already in their possession are mentioned due to a previous analysis but no technical details are provided on the cleaning and conversion part of these data. In their \emph{Exploration} phase the developers have not limited themselves to a theoretical research \cite{PixelOriented_paper}, provided by publications on pixel representation, but have integrated the ideas obtained through the group workshops reaching the conclusion of opting for a solution that would allow them to have the best ``data to space ratios" by using the smallest building block on a computer screen. Within their paper, a large space is dedicated to the corresponding \emph{Visualization} phase and the choices that have been made. Summarizing them in this brief summary would not be sufficient, therefore, for further information, please refer to their publication. However, the constant presence in the choices, such as the mapping of colors and related patterns or filtering and highlighting effects, of the objectives set in the previous phases in a context of cooperative work should be mentioned. Finally, also for the final part of the process, identifiable and synonymous with the \emph{feedback and fine-tune} phase, a great effort is made in the cooperation area. Several groups of different organizations, again with different skills and knowledge, were gathered to get feedback about the prototype, producing a positive result as the prototype and its visualization was generally evaluated as valid and suited for the inspections of log files.

