Sonification of a network’s self-organized criticality for real-time situational awareness

TL;DR: A system is described that sonifies in real time an information infrastructure’s self-organized criticality to alert the network administrators of both normal and abnormal network traffic and operation.

About: This article is published in Displays.The article was published on 2017-04-01 and is currently open access. It has received 8 citations till now. The article focuses on the topics: Sonification & Network monitoring.

Summary

1. Introduction

• With the large volumes of traffic passing across networks it is important to know about the state of the various components involved (servers, routers, switches, firewalls, computers, network-attached storage devices, etc.) and the types and volume of the data traffic passing through the network.
• In military circles there is debate about whether cyberspace has become the fifth warfighting domain (the others being sea, land, air, and space) [4].
• Sonification is a process of computational perceptualisation which Vickers [5] suggested is well suited to the monitoring of time-dependent processes and phenomena such as computer networks.
• When network incidents occur experience shows that the speed and accuracy of the initial response are critical to a successful resolution of the situation.

1.1. Sonification for Network Monitoring

• Sonification has been applied to many different types of data analysis (for a recent and broad coverage see The Sonification Handbook [7]).
• One task for which it seems particularly well suited is live monitoring, as would be required in situational awareness applications [5].
• It has been suggested that understanding the patterns of network traffic is essential to the analysis of a network’s survivability [8].
• It remains to be determined how effective this deliberate approach to consider musical aesthetics was.
• Worrall’s NetSon project [18] is a network sonification tool that aims to “sonically reveal aspects of the temporal structure of computer network data flows in a relatively large-scale organization”.

2. Self Organized Criticality in Network Traffic

• In the case of the sandpile the external driving force is the addition of sand grains and the internal relaxation process is the avalanche.
• Since then, SOC has been demonstrated in other natural systems such as earthquakes (in which the relaxation process can take seconds compared to the years or decades involved in the external driving force) and forest fires and has subsequently been observed in artificial systems such as stock markets and, latterly, computer networks.
• In a wavelet analysis of the burstiness of self-similar computer network traffic Yang et al. [24] demonstrated that the avalanche volume, duration time, and the interevent time of traffic flow fluctuations obey power law distributions.
• This supports Fukuda et al. [25]’s suggestion that that self-organized criticality could be the origin of the fluctuation of burstiness in network traffic.

2.1. Identifying and Measuring the SOC

• SOC is not a discrete variable that can be identified and monitored directly.
• Again the characteristic burstiness can be seen in the residuals, this time slightly more intense and regular.
• Both figures plot the same data sets, but Figure 2(b) is a representation of the denoised residuals of normal traffic data that is also carrying malicious traffic data.
• Firstly, at approximately 500 (x-axis) in Figure 2(b), a small amount of SOC activity can be observed ).
• In the next section the authors describe a system for sonifying the SOC characteristics of network traffic.

3. The SOC Sonification System

• A prototype SOC sonification system, socs, was designed and constructed to facilitate the real-time auditory perception of the SOC properties of network traffic.
• For purposes of illustration, the example chosen here sonifies the log returns of the following time-dependent network traffic data items: number of bytes sent, number of packets sent, number of bytes received, number of packets received by the network which the authors call bs, ps, br, pr respectively.
• (5) This may result in negative values for the log return which can be used to indicate the direction of a SOC event’s change in level (i.e., an increase in value means a step up to the next level of steady state, whilst a decrease means a step down).
• In addition, all values can be squared with the sign retained or discarded.
• The Python script calculates the log return values and feeds them as input to the sonification engine.

3.1. Sonification Parameters

• There are many possible mappings between the input data values and the various parameters that affect the audio.
• This may be done by increasing/decreasing the amplitude, altering a sound’s position in a sound field (e.g., left-right pan in a stereo field, front/back/left/right in a surround-sound field, or front/back/left/right and azimuth in a full threedimensional sound field), altering the sound’s phase, or altering its spectral characteristics (e.g., by changing the parameters of a filter).
• The following sections describe the processes that were used in the system.

3.1.1. Scaling

• Therefore, it was necessary to scale all incoming data so a scaler module was built that takes four arguments: the minimum and maximum values of the input range and the minimum and maximum of the desired output range.
• Any any value received on the scaler’s input is converted to a corresponding value in the specified output range.

3.1.2. Amplitude Control

• An amplitude control module was constructed that adjusts the amplitude, or level, of the output sound according to the value of the module’s input variable, in this case, the log return values.
• The lower the log return value the quieter the sound, the higher it is the louder the sound that is played back.
• Thus, the real-time monitoring of the network leads to constant fluctuations in the amplitude of the output, but only large changes in level are readily perceived.

3.1.3. Filtering

• There are several ways that the spectral characteristics of an audio signal may be processed, each of which will cause a change in the timbre of the audio.
• The advantage of a biquad filter is that it offers a richer set of filtering options than a single type of dedicated (e.g., band pass) filter and its coefficients can be altered in run time to changed the sound processing in real time.
• The higher the resonance the wider the band of frequencies that are allowed to pass through.
• The choice of filter depends on the kinds of sounds being loaded into the system.
• The filter’s initial parameters are hard-coded into the loopChannel3 sub patch to best fit the sonic material being used but ultimately it is intended to expose this functionality to the end user.

3.1.4. Sampled and Synthesized Voices

• Because the prototype system monitored four variables four voices or channels were used, one per variable.
• The loop playback method incorporates a sub patch designed by Farnell [29] which loads a wave audio file and plays it continuously, restarting it when it reaches the end.
• Thus, the log return value of each data stream is used to modulate the corresponding voice.
• In the version described here, the channels contained different sounds that combined to make a countryside soundscape.
• Any wave files can be loaded into the system.

3.2. System Architecture

• Figure 3 shows the architecture of the sonification design used for sonifying four data streams.
• Network traffic is captured from a log file or a live packet sniffer program by the custom Python script, also known as 1. Capture network traffic.
• Modulates the amplitude of the voice by the log return value, also known as 5. Amplitude control.
• The four audio channels are combined into a single stereo output which is then sent to the audio system of the host computer.
• The channel processing section contains four similar units: three for dealing with audio loop playback and one for dealing with synthesized tone playback.

4. Discussion

• The system was driven by a number of traffic data sets captured from live networks.
• Traffic data were aggregated over 1 s intervals and the number of bytes and packets sent and received per interval were fed to the socs application via the Python script.
• Each time a set of log return values is received the system uses the values to modulate the four respective audio channels.
• Using the mappings described above one hears a soundscape comprising the combination of sounds described above.
• When one or more very large log returns occur (such as would be expected during a dynamic system relaxation event) the corresponding soundscape experiences a very noticeable change: the amplitude varies greatly and the timbre alters as filters are adjusted .

4.1. Audio examples

• Audio files demonstrating the system output can be found in the project repository [28].
• Running the Python script at different playback rates and with signed, unsigned, and squared log return values leads to different auditory outputs.
• Running the system using signed log returns (the system default) reveals that the traffic spikes shown in Fig. 5 are both negative.
• This renders all large changes as positive spikes which results in all spikes being heard as large increases in amplitude and filtering effects.
• In the audio file multiSpike 1s.wav the negative spikes are clearly heard as gaps in the soundscape whilst the positive spike is very audible, particularly in the wind sound which represents the received bytes variable.

4.2. The Situational Awareness Loop

• On hearing an events such as described above (situational awareness level 1— Perception) the network aministrator would be drawn to inspecting the state of the network (situational awareness level 2 — Comprehension) to decide whether any action needs to be taken (situational awareness level 3 — Projection).
• After deciding what action to take (level 3) then comes the stage of managing the action, which itself requires situational awareness as actions are taken to address the situation.
• Some of these events may go unnoticed by the administrator (if, for example, they left the monitoring station for a short period of time) but individual events are not a matter of great concern.
• What will be of particular interest is when there is an extended series of repeated high log return values which might indicate growing instability in the network.

4.3. Timescales

• The system was run with log return intervals of 1 s and 20 ms.
• The running of the socs system at a higher rate than the traffic data’s initial sample rate allowed historical feeds to be listened to post-hoc in a manner analogous to spooling quickly through an audio tape (the main difference being that there is no consequent alteration of pitch).
• This means that logs can be auditioned quickly and interesting areas of activity spotted.
• This is useful for post-incident investigations and means that the system can be used for more than live monitoring.
• The Python script can be supplied with run-time arguments to focus on certain sections of the traffic data, and/or to slow down playback once a particular point is reached.

5. Concluding Remarks

• The combination of using a system’s self-organized criticality as the underlying data set for situational awareness and a tool for sonifying this SOC offers a number of potential advantages.
• While the work described here focused on the traditional traffic metrics of bytes and packets sent and received, it is important to explore what other variables and characteristics are implicated in a network’s SOC and this is the subject of ongoing work.
• The underlying system architecture promotes interactivity by letting the user select the combination of incoming data streams to be sonified and the sonic balance of the auditory streams.
• A tangible user interface object (e.g., a cube) with a fiducial marker on its bottom surface is placed above the router.
• In this way the administrator can gain intelligence about the state of the network in a hands-on way.

Figures

Figure 2: (a) Shows a Daubechies wavelet analysis of DDoS traffic data while (b) presents the denoised traffic residuals. 14

Table 1: Example sound files

Figure 1: (a) shows a Daubechies wavelet analysis of normal traffic data while (b) shows the denoised traffic residuals. 13

Figure 5: This screen grab shows the double spike in the sent bytes and received bytes variables. The log returns are negative jumps as shown by the descending peaks. The sound files spike2 1s a.wav and spike2 1s.wav demonstrate how this sounds at playback speeds of 1 s per record, using the absolute and signed log returns respectively. spike2 20ms a.wav is the same traffic segment but played back at 20 ms per record and using absolute (unsigned) values.

Figure 6: This screen grab shows shows a series of spikes in the sent bytes and received bytes variables.The audio file multiSpike 1s.wav demonstrates how this sounds at a playback speed of 1 s per record using signed log return values. There is an audible difference between the positive and negative traffic changes. However, notice how the peaks are not salient when playing back signed values at the faster rate of 20 ms as in multiSpike 20ms.wav — the peaks occur at around the 1.5 s mark in the audio file.

Figure 8: This screen shot of the voice channel section shows log return spikes occurring on all four channels with the largest values occuring in the sent bytes and sent packets streams. These spikes generate a noticeable increase in the amplitude and brightening of the timbre of the soundscape.

Figure 7: This screen grab shows the same series of spikes as Fig 6 but this time using the unsigned log returns. The sound files multiSpike 1s a.wav and multiSpike 20ms a.wav are recordings of this traffic segment played back at 1 s and 20 ms per record respectively. In both cases the traffic peaks are quite noticeable. The file multiSpike 20ms as.wav demonstrates how squaring the log return values leads to an even more marked effect.

Figure 4: The socs application. Section A deals with reading the network traffic from the capture device. Section B contains the voice definitions to which each traffic variable is mapped. Section C is a mixer to convert the four separate audio streams into a single stereo feed. Section D is a graphical display of the combined variables being monitored. The channel graph plots are updated more frequently than the aggregate graph plot.

Figure 3: Schematic view of the SOC sonification system for four network traffic variables: number of bytes sent (bs), number of packets sent (ps), number of bytes received (br), number of packets received (pr).

Frequently asked questions

Q1. What contributions have the authors mentioned in the paper "Sonification of a network’s self-organized criticality for real-time situational awareness" ?

This article focuses on the combination of two dissimilar research concepts, namely sonification ( a form of auditory display ) and self-organized criticality ( SOC ). Implications for how such a system may support real-time situational awareness and posthoc incident analysis are discussed.