A Formalised Approach to Designing Sonification Systems

for Network-Security Monitoring

Louise Axon, Jason R. C. Nurse, Michael Goldsmith, Sadie Creese

Department of Computer Science, University of Oxford,

Parks Road, Oxford, UK
Email: {louise.axon, jason.nurse, michael.goldsmith, sadie.creese}@cs.ox.ac.uk

Abstract—Sonification systems, in which data are represented (IDSs) and visualisations are general examples of classes of
through sound, have the potential to be useful in a number of tools that are widely used to convey information pertaining
network-security monitoring applications in Security Operations to network security in a form that can be easily understood
Centres (SOCs). Security analysts working in SOCs generally by analysts. The detection algorithms that usually underlie
monitor networks using a combination of anomaly-detection such tools have certain limitations, and can produce false-
techniques, Intrusion Detection Systems and data presented in
visual and text-based forms. In the last two decades significant
positive and false-negative results [2,3]. Detecting attacks, and
progress has been made in developing novel sonification systems recognising which risks must be prioritised over other attacks
to further support network-monitoring tasks, but many of these and malign activities is difficult, and the degree of inaccuracy
systems have not been sufficiently validated, and there is a in detection systems can make it even more so.
lack of uptake in SOCs. Furthermore, little guidance exists Sonification can provide a potential solution to the chal-
on design requirements for the sonification of network data. lenges of network-security monitoring in SOCs. Sonification
In this paper, we identify the key role that sonification, if is the presentation of data in an audio (generally non-speech)
implemented correctly, could play in addressing shortcomings form. Over the last two decades, the incorporation of sonifi-
of traditional network-monitoring methods. Based on a review of cation systems into the monitoring activity of SOCs has been
prior research, we propose an approach to developing sonification
systems for network monitoring. This approach involves the
considered [1]. A range of systems has been proposed in which
formalisation of a model for designing sonifications in this space; sonified data are presented to support security analysts in
identification of sonification design aesthetics suitable for real- their network-monitoring tasks. Some prior work has provided
time network monitoring; and system refinement and validation strong evidence of the role sonification could play in improving
through comprehensive user testing. As an initial step in this SOC monitoring capabilities. It has already been shown, for
system development, we present a formalised model for designing example, that using sonification techniques enables users to
sonifications for network-security monitoring. The application of detect false-positives from IDSs more quickly [4]. However,
this model is demonstrated through our development of prototype the use of sonification systems in this context has not been
sonification systems for two different use-cases within network- sufficiently validated, and there is a lack of uptake in SOCs.
security monitoring. Sonification has not yet been used operationally in SOCs to
Keywords–Sonification; Network Security; Anomaly Detection; our knowledge. Based on the current state of the art, there
Network Monitoring; Formalised Model; Situational Awareness.
are clear needs for further research and testing to validate the
usefulness of sonification for efficient network monitoring, and
I. I NTRODUCTION to develop appropriate and effective sonifications to enhance
The cybersecurity of enterprises crucially depends on the network-monitoring capabilities.
monitoring capabilities of the Security Operations Centres This paper is an extension of a survey paper by Axon et
(SOCs) operating on their behalf, aiming to maintain network al. [1]. In that paper, the major developments over the last two
and systems security; in particular, their ability to detect and decades in sonification and multimodal systems for network
respond to cyber-attack. Organisations today are frequently monitoring were reviewed, with particular focus on approaches
the target of cyber-attacks, the nature of which varies widely to design and user testing. That article also contributed a
from ransomware to denial-of-service (DoS) attacks to the research agenda for advancing the field. This agenda included
exfiltration of sensitive data by insiders, for example. These comprehensive user testing to assess the extent to which,
attacks can be highly damaging both financially, and in terms and ways in which, sonification techniques can be useful for
of the reputation of the organisation. In the face of a constantly network-monitoring tasks in SOCs; the development of aes-
evolving set of threats and attack vectors, and changing busi- thetic sonifications appropriate for use in continuous network-
ness operations, there is a constant requirement for effective monitoring tasks; and the formalisation of an approach to
monitoring tools in SOCs to both automatically and semi- sonifying network-security data. In this paper, we extend
automatically detect attacks. that work by proposing an approach to designing sonification
One of the key challenges that SOCs face in monitoring systems for network-security monitoring, and presenting a
large networks is the huge volume of data and metadata that formalised sonification model as part of that approach. We
can be present on the network. This consists of both the data illustrate the application of the model by using it to design
created by the day-to-day operations of the enterprise, and two different sonification-system prototypes.
the data created by security tools. For real-time monitoring, The remainder of this paper is structured in six sections:
tools that present this data in a form that can be processed in in Section II, we present traditional approaches to network
negligible time are essential [1]. Intrusion Detection Systems
monitoring and detail their shortcomings. Section III presents are compared against a defined acceptable range for deviation
a review of prior work in using sonification for network mon- [10, 11]; detection methods based on Knowledge Systems, in
itoring, and highlights outstanding challenges in the field. In which the current activity of the system is compared against a
Section IV, we propose an approach to developing sonification rule-based “normal” activity [12]; and detection methods based
systems for real-time network monitoring. We present our on Machine Learning, automated methods in which systems
initial work in a part of this approach – the formalisation of learn about activities and detect whether these are anomalous
a sonification design model – in Section V. In Section VI through supervised or unsupervised learning [7, 13].
we apply this model to develop prototype sonification systems Data-presentation techniques convey network-security
for two different use-cases within network-security monitoring. monitoring information to security analysts. Command-line
We conclude in Section VII, and indicate directions for future interfaces are commonly used mediums for presenting the
work. output of network-monitoring appliances such as IDSs and
network firewalls. Security visualisations are another widely-
II. T RADITIONAL A PPROACHES TO N ETWORK -S ECURITY used class of tool that convey the output of automated detec-
M ONITORING tion tools, and may also present information about the raw
Network-security monitoring is generally conducted by network data. While some security-visualisation systems are
security analysts, who observe activity on the network – very basic, there are a number of recent surveys of the state
usually using a variety of tools – in order to detect security of the art in visualising complex network data. Zhang et al.
breaches. According to the UK government’s Cyber Security [14] and Etoty et al. [15] present reviews as of 2012 and
Breaches Survey for companies across the UK, published in 2014 respectively, reporting research into improving graphical-
May 2016, two-thirds (65%) of large organisations reported layout and user-interaction techniques [16, 17]. Visualisations
that they had detected a security breach in the last twelve generally work by mapping network-data parameters to visual
months, with the most costly single breach experienced by parameters, such that analysts can observe the changes in
an organisation during that time purported to have cost £3 the visualisation presented and from this deduce changes in,
million [5]. In the face of such frequent and potentially costly and information about, the network. The design of effective
breaches, network-monitoring and attack-detection capabilities visualisation involves identifying mappings that represent the
are of extremely high importance. data in a way that can be understood by security analysts, in
A variety of tools are used in network monitoring: IDSs, SOCs for example, without inducing cognitive overload, and
Intrusion Prevention Systems (IPSs), visualisations, textual can clearly convey information pertaining to the security of
presentations, and firewalls are some of the tools with which the network.
analysts conduct their monitoring tasks. The subject of our There are certain drawbacks to current approaches to the
research is primarily detection, rather than prevention capa- monitoring and analysis of security data. Existing automated
bilities. We therefore focus on IDSs and anomaly-detection techniques can be unreliable or inaccurate. Signature-based
techniques. We also describe the data-presentation methods IDSs may suffer from poorly-defined signatures, and are
generally used to convey network-security monitoring infor- limited to detecting only those attacks for which signatures
mation to security analysts – security visualisation tools, and are known. The algorithms underlying anomaly-detection tech-
text-based interfaces. niques using Statistics or Machine Learning also produce
Network monitoring is largely based on alerts given by false-positives and false-negatives [2, 3]. There is, therefore,
IDSs. Many IDSs have been based on Denning’s model [6]. a requirement to identify improved anomaly-detection meth-
In general, there are two types of IDS. Anomaly-based IDSs ods. Alongside ongoing research into improving the accuracy
monitor network traffic, and compare it against an established of automated detection methods, one avenue that has been
baseline (based on bandwidth, protocols, ports, devices, and researched in security-visualisation work is the detection of
connections that are “normal”). Signature-based IDSs, on the anomalies by humans observing aspects of the network data
other hand, compare packets monitored on the network against [18].
a database of signatures or attributes from known malicious Given the potential inaccuracy of the alerts produced by
threats [2]. Leading SOCs typically craft their own signatures, the automated detection-system used, it is important that the
defined by analysts in the form of rules. Recent advances human analyst has situational awareness and an understanding
automate the collection and analysis of data from a range of the network state, in order that he can interpret alerts and
of sources such as logs and IDS alerts using novel Machine accurately decide their validity; this is one of the key roles of
Learning and Data Mining approaches. data-presentation techniques. A shortcoming of existing text-
Anomaly-detection techniques describe methods for the based and visualisation-based network-monitoring systems is
detection of changes in systems that may indicate the presence the requirement that operators dedicate their full attention to
of threat, and so be of interest from a monitoring perspective. the display in order to ensure that no information is missed
In contrast with signature- or rule-based detection, which – for real-time monitoring especially – which can restrict
relies on comparison with known attack signatures, in anomaly their ability to perform other tasks. Furthermore, the number
detection, the state of the network is monitored and compared of visual dimensions and properties onto which data can be
with a “normal” baseline. Anomalous activity is that which mapped is limited [19], and the presentation of large amounts
exceeds an acceptable threshold difference from this baseline. of information visually may put strain on the visual capacity
Anomaly detection often informs the output of IDSs and of security analysts.
visualisations. There are several reports reflecting on the state
of the art in anomaly-detection techniques [2, 7, 8]. In general, III. N ETWORK M ONITORING U SING S ONIFICATION
we can divide anomaly-detection methods into three categories Based on the shortcomings we identify in existing moni-
[2, 9]: detection methods based on Statistics, in which values toring techniques, we believe that sonification may have the
potential to improve monitoring capabilities in SOCs, in a scope. Furthermore, in this paper we propose an approach to
number of ways. While many promising advances have been designing and testing the utility of sonification systems for
made recently in novel data-analytics approaches in particu- network monitoring, and we go on to actually report on the
lar, we highlight that automated network-monitoring systems implementation of that research vision, namely our work on the
do not always produce reliable outputs. Presenting network- development of a formalised model for designing sonifications
monitoring information as a continuous sonification could im- for anomaly-based network monitoring.
prove analysts’ awareness of the network-security state, aiding
their interpretation of the alerts given by automated systems. Approach 1
Such awareness could also enable analysts to detect patterns,
recognise anomalous activity and prioritise risks differently Visualisation
from the way their systems do, acting as a human anomaly- or text-based
detector of sorts. Anomaly detection presentation
Sonification could also offer a solution to the shortcomings Raw
of current data-presentation techniques – in particular, text- network IDS Sonification
data
based presentation and security visualisations – as an extra
Firewall
interface that requires humans to use their sense of hearing
rather than vision. It is important to design representations of Network-monitoring Approach 2
large volumes of network data that are as easy as possible for appliances
analysts to use, understand and act on. A potential advantage Figure 1. A summary of the existing relationship between traditional
of using sonification in this context is that sound can be monitoring techniques and their potential relationship with sonification
presented for peripheral listening. This means that, if designed systems in SOCs.
correctly, sonification could enable analysts to monitor the
network-security state as a non-primary task, whilst performing
other main tasks. Furthermore, using sound offers another set Figure 1 shows the existing relationship between raw data,
of dimensions in addition to visual dimensions onto which anomaly-detection techniques, network-monitoring appliances
data can be mapped. The addition of sonification to existing such as IDSs, and data-presentation techniques, and the posi-
visualisation-based or text-based data presentation approaches tion we envisage sonification might take in this setup. The
could provide a useable method of monitoring highly complex, figure shows two approaches to sonifying network-security
multivariate network data. monitoring data. In Approach 1, the raw network data is
represented in the sonification – perhaps with some scaling or
A. Sonification: a Background
sampling methods applied. In Approach 2, the network data is
Sonification is the presentation of data in an audio (gen- not sonified in its raw form but is subject to some automated
erally non-speech) form. It is used in numerous fields, such detection procedure prior to sonification. This either means
as financial markets, medicine (Electroencephalography (EEG) that the output of some network-monitoring appliance – an
monitoring [20], image analysis [21]) and astronomy. User IDS, for example – is sonified, or that there is some detection
testing has validated that the presentation of sonified data algorithm involved in the sonification method itself prior to
can improve certain capabilities in a number of applications: the rendering of the data as sound.
improved accuracy in monitoring the movement of volatile
market indices by financial traders [22], and improved capa- TABLE I. EXAMPLES OF TYPES OF RAW NETWORK DATA
bilities for exploratory analysis of EEG data [23], for example.
A variety of techniques and guidelines have been developed Data Type Description
for the design and implementation of sonification [24–27]. Packet header The header information for individual packets on the
network (including timestamp, source/destination IP/port,
Throughout sonification literature there are three main ap- packet size, for example) from a network packet capture
proaches recognised: earcons/event-based sonification (discrete
Netflow Data on collected network flows – sequences of packets
sounds representing a defined event), parameter-mapping soni- sent over the same connection (including timestamp, flow
fication (PMSon – in which changes in some data dimen- duration, source/destination IP/port, for example)
sions are represented by changes in acoustic dimensions), and Machine Logs Data recorded at individual machines on the network. For
model-based sonification (in which the user interacts with a example, network packets received and sent; processes
running; central processing unit (CPU) usage
model and receives some acoustic response derived from the
data).
The current state of the art in sonification for network and In Table I, we clarify the meaning of “raw network data”
server monitoring is summarised by Rinderle-Ma et al. [19], as it is used in Figure 1, by illustrating examples of types of
who identify systems for the sonification of computer-security data. The list is not exhaustive, but gives some indication of
data, in various stages of maturity. It is concluded that there the network data to which we refer. These data are examples
is a lack of formal user and usability testing, even in those of the raw network data that is sonified directly in Approach
systems that are already fully developed [28–30]. Our survey 1 of Figure 1.
work differs from that of Rinderle-Ma et al.: while that survey
gives an overview of the design approaches taken in some B. Applications of Sonification to Network Monitoring
existing sonification systems, our survey provides much greater PEEP, a “network auralizer” for monitoring networks with
detail on the sonification design of existing systems in terms sound, is presented in [28]. PEEP is designed to enable
of sonification techniques, sound mapping types, the network system administrators to detect network anomalies – both
data and attack types represented and the network-monitoring in security and general performance – by comparing sounds
with the sound of the “normally functioning” network. The and sent) are used to modulate the amplitude, pan, phase or
focus of PEEP is on the use of “natural” sounds – birdsong, spectral characteristics of four sound channels, including the
for example – in sonifying network events. Recordings are sound of a running stream and rain. The aim of the system is to
mapped to network conditions (excessive traffic and email alert the system administrator to abnormal network behaviour
spam, for instance), and are played back to reflect these with regard to both performance and security; it is suggested,
conditions. Abnormal events are presented through a change for example, that a DDoS attack might be recognisable by the
in the “natural” sounds. PEEP represents both network events system’s representation of an increase in certain types of traffic.
(when an event occurs it is represented by a single natural There is, however, no evaluation of users’ ability to recognise
sound) and network state (state is represented through sounds such information using the system. Vickers et al. then extend
played continuously, which change when there is a change in that work to further explore the potential for using sonification
some aspects of the state, such as average network load). There for network situational awareness [37]. For this context, i.e.,
is no experimental validation of the performance of PEEP and continuous monitoring for network situational awareness – it is
its usefulness for monitoring networks, but the authors report argued that solutions based on soundscape have an advantage
the ability to hear common network problems such as excessive over other sonification designs, and that there is a need
traffic using the sonification. for sonifications that are not annoying or fatiguing and that
The Stetho network sonification system is given in [31]. complement the user’s existing sonic environment.
Stetho sonifies network events by reading the output of the A soundscape approach is also adopted in the InteNtion
Linux tcpdump command, checking for matches using regular system [29] for network sonification. Here, network traffic
expressions, and generating corresponding Musical Instrument analysis output is converted to MIDI and sent to synthesisers
Digital Interface (MIDI) events, with the aim that the system for dynamic mixing; the output is a soundscape composed
creates sounds that are “comfortable as music”. The aim of by the network activity generally rather than the detection of
Stetho is to convey the status of network traffic, without a suspicious activity specifically. It is argued that the system
specific focus on anomaly detection. The research includes an could be used to help administrators detect attacks; however
experimental evaluation of the Stetho system – users’ ability this is not validated through user testing. DeButts is a student
to interpret the traffic load from the sounds generated by project available online in which network data is sonified
Stetho is examined. The experiment shows that this monitoring with the aim of aiding security analysts to detect anomalous
information can be recognised by users from the sounds incidents in network access logs [38].
created by Stetho; however, only four users (subjects familiar Garcı́a-Ruiz et al. investigate the application of sonification
with network administration) are involved in the evaluation as a teaching and learning tool for network intrusion detection
experiment. [39, 40]. This work includes an exploratory piece in which
Network Monitoring with Sound (NeMoS) is a network information is gathered regarding the subjects’ preferred au-
sonification system in which the user defines network events, ditory representations of attacks. Sonification prototypes are
and the system then associates these events with MIDI tracks given for the mapping of log-registered attacks into sound. The
[32]. The system is designed to allow monitoring of different first uses animal sounds – auditory icons – for five different
parts of a potentially large network system at once, with a types of attack (“guess”, “rcp”, “rsh”, “rlogin”, “port-scan”);
single musical flow representing the whole state of the part of the second uses piano notes at five different frequencies as
the system the system manager is interested in. The focus is not earcons to represent the five types of attack. Informal testing
on network security but on monitoring network performance was carried out for these two prototypes, and suggested that
in general; printer status and system load, for example, can be the earcons were more easily identifiable, while the subjects
represented through two different sound channels. could recall the attack types more easily using the auditory
More recently, Ballora et al. look to create a soundscape icons. While this is a useful start to comparing approaches
representation of network state which aids anomaly detection to sonification design for network data, the mappings tested
by assigning sounds to signal certain types and levels of net- are limited, and further research is required into mappings
work activity such as unusual port requests [33] (“soundscape” involving other sound and data types.
definition given by Schafer [34]). The concept is a system Systems have been proposed to sonify the output of existing
capable of combining multiple network parameters through IDSs, and to act as additions to the function of these systems.
data fusion to create this soundscape. The fusion approach Gopinath’s thesis uses JListen to sonify a range of events
is based on the JDL Data Fusion Process Model [35], with in Snort Network Intrusion Detection System (a widely used
characteristics of the data assigned to multiple parameters of open-source network IDS for UNIX derivatives and Windows)
the sound. The authors aim, firstly, to map anomalous events to signal malicious attacks [4]. The aim is to explore the
to sound and, secondly, to represent the Internet Protocol usefulness of sonification in improving the accuracy of IDS
(IP) space as a soundscape in which patterns can emerge alert interpretation by users; usability studies indicate that
for experienced listeners. No user testing is carried out to sonification may increase user awareness in intrusion detection.
establish the usefulness of the system for anomaly-detection Experiments are carried out to test three hypotheses on the
tasks. However, the authors report being able to hear patterns usability and efficacy of sonifying Snort. The findings are:
associated with distributed denial-of-service (DDoS) and port- musical knowledge has no significant effect on the ability
scanning attacks (see Table III). of subjects to use the system to find intrusions; sonification
Vickers et al. sonify meta properties of network traffic decreases the time taken to detect false positives; immediate
data [36] as a countryside soundscape. In that system, the monitoring of hosts is possible with a sonified system. As
log returns of successive values of network traffic properties noted by Rinderle-Ma et al. [19], however, the comparison
(number of packets received and sent, number of bytes received is somewhat biased since the control group without auditory
 TABLE II. REVIEW OF APPROACHES TO AND USER TESTING IN EXISTING SONIFICATION SYSTEMS
FOR NETWORK MONITORING, ORDERED BY YEAR.

of

Network data

for
type mapped

monitoring?
User testing

participants

participants

Sonification

Multimodal
Sound type

Monitoring
Nature of

technique

Evaluates
Number

security
utility
scope
Author Year Sonification approach description
Gilfix 2000 “Natural” sounds mapped to network conditions 7 Raw data Natural PMSon Anomaly detection: 7 7
[28] (network (wildlife conditions such as
packet logs) and high traffic load
nature) and email spam are
sounds mapped to sound
Varner 2002 Multimodal system: visualisation conveys status of 7 Not Not Not Network attack 7 3
[41] network nodes; sonification conveys additional details specified speci- speci- detection
on network nodes selected by the user fied fied
Kimoto 2002 Maps parameters of sound to raw network data 3 4 Subjects Raw data Musical PMSon General network 3 3
[31] familiar (Linux activity and
with tcpdump network anomaly
network output) detection
adminis-
tration
Malandri- 2003 Associates MIDI tracks to user-defined network events 7 Raw data Musical Event- Network 7 7
no (printer based performance
[32] status,
server CPU,
file server
logs,
network
packet logs)
Gopinath 2004 Instrument and pitch mapped to IDS alert type 3 20 Computer IDS alerts Real- PMSon Intrusion detection: 3 7
[4] Science (Snort) world IDS logs sonified
students and to aid users
and staff musi- monitoring
cal intruders and
vulnerable hosts
Papado- 2004 Combines network events rendered as spatial audio 7 Raw data Real- PMSon Anomaly detection: 7 3
poulos with 3D stereoscopic visuals to form a multimodal (incoming world network data
[42] representation of network information. Sounds are network and presented for
created in response to changes in data patterns using flows) musi- pattern recognition
Gaussian Mixture Modelling cal
Qi [43] 2007 Maps traffic pattern (classified, queued and scheduled) 7 Raw data Musical PMSon Network attack 7 3
to audio; bytes and packet rate are mapped to (network detection (DoS,
frequency and intensity of audio respectively packet logs) port scanning)
El 2008 Auditory icons (non-instrumental) and earcons 3 29 Telematics Marked Real- Event- Network attack 7 7
Seoud (instrumental) mapped to attack type engineer- attacks from world based detection
[40] ing network log and
students musi-
cal
Brown 2009 Proposed system maps raw network traffic to sound to 7 Raw data Musical PMSon Network anomaly 7 3
[44] convey information on network status; current system (network detection (increase
maps properties of traffic classified as disruptive by packet logs) in traffic; HTTP
an IDS to properties of piano notes and IDS error messages;
output number of TCP
handshakes)
Ballora 2011 Parameter-mapping soundscape for overall IP space; 7 Raw data Musical PMSon Anomaly detection: 7 7
[33] obvious sound signals for certain levels of activity (network anomalous
packet logs) incidents sonified,
and network state
presented to human
to enable pattern
recognition
Giot 2012 MIDI messages mapped to data output by SharpPCap 7 Raw data Musical PMSon General network 7 7
[29] library network traffic analysis; MIDI messages mixed (network activity and attack
to produce a soundscape packet logs) detection
deButts 2014 Maps distinct notification tones to anomalous network 7 Raw data Musical Event- Anomaly detection: 7 3
[38] events; visualises network traffic activity (multimodal) (access (single based defined anomalous
logs) tones) incidents mapped
to sounds
Vickers 2014 Parameters of each sound generator (voice) mapped to 7 Raw data Natural PMSon Network 7 7
[36] the log return values for the network’s self-organised (network performance and
criticality packet logs) attack detection
Worrall 2015 Multimodal system for real-time sonification of 7 Raw data Musical PMSon General network 7 3
[30] large-scale network data. Maps data parameters and (sampled activity
events to sound; parameter-mapping sonification network
approach using melodic pitch structures to reduce packet
fatigue traffic)
Mancuso 2015 Multimodal system for representing data on military 3 30 Local Raw data Musical PMSon Network anomaly 3 3
[45] networks, in which each source and destination IP is popula- (network detection (packet
mapped to an instrument and pitch, and the loudness tion and packet logs) size threshold,
is increased when a packet size threshold is exceeded air force source and
base destination IPs
personnel sonified)
support had to conduct the tasks by reading log files, without performance and manage the workload of, and decrease the
access to the visualisation-based tools to which the group stress felt by, users conducting cyber-monitoring operations
tested with auditory support had access. on military networks. The testing results show that the use
Multimodal systems, that combine visualisation and soni- of sonifications in the task did not improve participants’
fication for network monitoring, have also been explored. performance, workload or stress. However, only one method
Varner and Knight present such a system in [41]. Visualisation of sonifying the data was tested, in which each possible source
is used to convey the status of network nodes; sonification and destination IP address was represented by a different
then conveys additional details on network nodes selected instrument and note, and the loudness increased if a threshold
by the user. This multimodal approach is useful because it packet size was exceeded. The results do not, therefore, show
combines advantages of the two modalities – the spatial nature that using sonification does not improve performance, stress
of visualisation, and the temporal nature of sonification – to and workload in this context, but demonstrate only that this
produce an effective and usable system. Garcı́a et al. describe particular method of sonifying the data is ineffective.
the benefits and pitfalls of using multimodal human-computer
interfaces for the forensic analysis of network logs for attacks. Approach 1: [28–33, 36, 42–45]
A sonification method is proposed for IDSs as part of a
multimodal interface, to enable analysts to cope with the Visualisation
large amounts of information contained in network logs. The or text-based
sonification design approach is not detailed, and the system is presentation
Anomaly detection
not tested with users. Raw
The CyberSeer [42] system uses sound to aid the presenta- network IDS Sonification
tion of network-security information with the aim of improving data
Firewall
network-monitoring capability. Sound is used as an additional
variable to data-visualisation techniques to produce an audio- Network-monitoring Approach 2: [4, 38, 40,
visual display that conveys information about network traffic appliances 44]
log data and IDS events. The requirement for user testing to Figure 2. A summary of the data types used in previous network data
establish the most effective audio mappings is recognised, but sonification approaches.
no testing is carried out. Garcı́a-Ruiz et al. describe the benefits
and pitfalls of using multimodal human-computer interfaces
for analysing intrusion detection [46]. A sonification method
is proposed for IDSs as part of a multimodal interface, to In Figure 2 we show the approaches taken in previous
enable analysts to cope with the large amounts of information work to designing network-data sonifications, in terms of the
contained in network logs. type of network data sonified. In this figure, we position the
existing sonification systems surveyed onto the monitoring
Qi et al. present another multimodal system for detecting
tool relationships diagram presented in Figure 1. Previously-
intrusions and attacks on networks in [43]; distinctive sounds
are generated for a set of attack scenarios consisting of proposed sonifications of network-security data can be divided
DoS and port scanning. The authors stipulate that the sounds into two sets: those that take Approach 1 (in which the
generated could enable humans to recognise and distinguish sonification system takes as input some raw network data,
between the two types of attack; however, user testing is with scaling functions applied such that the sonification is a
needed to validate this conclusion and investigate the extent to representation of the raw network data itself), and those that
which this approach is effective. A similar approach is adopted take Approach 2 (in which the systems sonifies the output of
by Brown et al. [44]: the bit-rates and packet-rates of a delay some network monitoring tool such as an IDS, or sonifies the
output of some inbuilt anomaly detection technique).
queue are sonified in a system for intrusion detection.
NetSon [30] is a system for real time sonification and In Table II, we summarise the sonification design tech-
niques used and user testing carried out in prior work. In Table
visualisation of network traffic, with a focus on large-scale
III we examine in greater detail those existing sonification
organisations. In this work, there are no user studies, but the
systems developed for enabling attack detection by sonifying
system is being used at Fraunhofer IIS, a research institution,
raw network data specifically (Approach 1 represented in
who provide a live web stream of their installation [47]. Mi-
crosoft have a multimodal system, Specimen Box, for real-time Figure 2). For each system, we present the types of attacks
retrospective detection and analysis of botnet activity. It has not targeted, and the network data features represented in the
yet been presented in a scientific publication, but a description sonification. We summarise the reported effectiveness of these
and videos of the functioning system are presented online [48]. systems for “hearing” cyber attacks.
The system has not been subject to formal evaluation, but is In summary, some prior work shows that sonification sys-
used in operations at the Microsoft Cybercrime Centre. tems have promising potential to enable network-security mon-
Mancuso et al. conducted user testing to assess the use- itoring capabilities. Previously-designed sonification systems
fulness of sonification of network data for military cyber have been reported to produce sonic patterns from which it is
operations [45]. Participants were tasked with detecting target possible to “hear” cyber attacks [28, 33, 36, 43]. In particular,
packets matching specific signatures (see Table III), using it is reported that DoS attacks and port-scanning attacks can
be heard in previous systems sonifying raw network data.
either a visual display (a visual interface that emulated network
User testing has shown that other sonification design attempts
packet analysis software such as Wireshark) only, or both
were not useful for network-security monitoring tasks [45];
visual and sonified displays. The aim of the testing was
to assess the extent to which sonification can improve the however, the sonification designs and applications tested in
this work were limited, and this result is not comprehensive
 TABLE III. ATTACK DETECTION AND NETWORK DATA FEATURE REPRESENTATION IN PREVIOUS SONIFICATION SYSTEMS.

Author Network data features sonified Can attacks be “heard”? Attacks targeted
Gilfix Incoming and outgoing mail; average traffic load; number Not assessed, but authors report ability to “easily Not specified
[28] of concurrent users; bad DNS queries; telnetd traffic; detect common network problems such as high load,
others unspecified excessive traffic, and email spam”
Varner Not specified Not assessed
[41]
Papado- Packet rate; others not specified Not assessed
poulos
[42]
Qi [43] Packet rate; byte rate No experimental assessment, but authors report that DoS; port scanning
the system produced sounds “notably” different
enough that distinguishing between DoS and port
scanning attacks is “relatively easy”, while no sounds
were produced under “normal” traffic conditions
Brown Prolonged increase in traffic volume; number of TCP Not assessed
[44] handshakes in progress; number of HTTP error messages
Ballora Source IP address; destination IP address; frequency of Not assessed, but authors report finding “that patterns Dataset used contains DoS and
[33] packets in ongoing socket connections; packet rate; associated with intrusion attempts such as port scans port-scanning attacks
requests to unusual ports; geographic location of sender and denials of service are readily audible”
(suggested but not implemented)
Giot [29] Packet size; Time-to-Live (TTL) of packet; bandpass of Not assessed
network; source IP address; destination IP address;
protocol (type of service); number of useless packets (e.g.
TCP ACK packet)
Vickers Data sonified are log returns of successive instances of the Changes in soundscape not noticeable under “normal” Not specified
[36] following values: number of bytes sent; number of packets network conditions; noticeable change occurs when
sent; number of bytes received; number of packets received log returns large (large log return for number of
packets received might indicate DDoS, for example)
Mancuso Source IP address (of packet); destination IP address (of Use of sonification alongside the visual interface did Not specific attacks – target packet
[45] packet); packet size not improve participants’ performance in detecting characterised by “signatures”: network
“target packets” compared with their performance transmissions originating from either of
using the visual interface alone two particular source IP addresses,
directed to either of two destination IP
addresses, using either of two
protocols, with packet size 500 bytes
or more

enough to suggest that further research in this area is futile. It is enabling users to detect packets matching specific signatures,
clear that variations in sonification design approach may affect but test only one sonification design. There is therefore a clear
the usefulness of the system for network-security monitoring, need to assess and compare the use of a number of sonification
and as such further research is required into appropriate designs for network anomaly detection. Extensive user testing
sonification designs for the context. is required to validate the usefulness of the approach and of
proposed systems, and to refine the sonification design.
C. Outstanding Challenges The systems listed vary in the data they represent. Some
Table II presents a summary of the sonification systems map raw network data to sound, some map the output of IDSs,
previously developed for network monitoring (solutions for while some aim to map attacks to sounds. However, there is
which full systems or prototypes have been developed). From no comparison of the efficacy of these approaches, or of the
this, we have identified the key areas in which research is usefulness of sonic representations of different attack types.
lacking: formalisation of a model for designing sonification Identification of the network-data sources and features that
systems for network monitoring, identification of data require- should be sonified in order to represent network attacks is
ments, investigation of appropriate sonification aesthetics, and needed. The sonification design approaches used (event-based,
validation of the utility of the approach through user testing. parameter-mapping, and soundscape-based) also vary, as do
the sound types (natural sounds, sounds that are musically
In general, a weakness in the articles is the amount of user
informed) but there is as yet no comprehensive investigation
testing carried out with the intended users – security analysts.
into, or comparison of, the usefulness of these methods.
Table II shows that little user testing has been carried out,
Based on this, we propose that comparative research into the
and of that which has, little has specifically targeted security
sonification aesthetics most appropriate for use in network
analysts – it is possible that some of the Air Force Base
monitoring is crucial, in order to inform sonification design.
personnel who participated in the user testing by Mancuso
We further identify a requirement for the development of a
et al. were security analysts, but this is not made clear in
formalised approach to designing sonifications in this field,
that paper [45]. Table II shows also that there has been little
to underpin developments and enable comparison. Next, we
(and no comprehensive) evaluation of the usefulness of existing
outline our proposed approach to sonification development and
sonification systems for network anomaly detection. Gopinath
testing, with which we aim to address these issues.
evaluates the usefulness of a sonification with a focus on
aiding users in monitoring the output of IDSs [4]. Mancuso
et al. evaluate the effectiveness of their sonification system in
 IV. P ROPOSED A PPROACH received from an IP address that is known to be malicious
We propose an approach to developing sonification systems (these two changes would generally be found by the statistical
in this space. The approach involves formalising a model for anomaly-based IDSs and signature-based IDSs, respectively,
designing sonifications for network monitoring, identifying described in Section II). This could be the result of a DoS
the network data representation requirements, investigating attack, and the sonification system should therefore attract
appropriate design aesthetics for the context, and assessing the attention of the analyst. Cross-field interference could be
the utility of the developed systems through comprehensive leveraged through the choice of data-sound mappings used in
user testing. We believe that these elements combine to form this case (with a mapping to higher pitch and increased tempo
a solution to the problem of designing and testing the utility – two sound parameters which interact such that each appears
of sonification systems for network-security monitoring. more increased that it really is – for the two data parameters
respectively) to ensure that the attack is highlighted by the
Data requirements sonification.
In order to prevent sonification designs from causing
listener fatigue, we propose that a rule-based approach to
aesthetic sound generation may be appropriate. In particular,
Formalised Aesthetics a sonification model should be non-prescriptive in terms of
sonification model Data– musical genre, and be applied to a variety of genres of music
sound to generate a set of different-sounding sonifications of the
Data mappings same network data. We hypothesise that with this approach,
Set of data–sound
mappings Scaling
users could be allowed to move between a set of musical
genres at choice, each of which would sonify the network
data according to the same grammar, and this could reduce the
Scaling functions Sound
fatigue caused by the sounds. Below, we give the key questions
design
to be addressed in building this model.
• Which are the requirements specific to the
network-security monitoring context for the map-
ping of data to sound? In general, huge quantities of
Software User testing multivariate and highly complex data move through
organisational computer networks. It is important that
Figure 3. Proposed approach to designing sonification systems for the model enables the sonification designer to reason
network-security monitoring. about the parts of the data to be sonified, the key
information about these parts that must be conveyed to
the sonification user, and the most appropriate method
Figure 3 shows the parts of our approach, and their of representing this information through sound. For
relationship with each other. The formalised network data example, an important task in SOCs is monitoring
sonification model takes as input aesthetic requirements and the security state of sensitive servers on the network
data requirements, and incorporates the results of iterative user – this could be those servers containing databases
testing. We now detail the research questions to be answered of customer records. Devising methods of mapping
for each part of the approach. required information about selected aspects of the
network to sound will be a key part of the model
A. Requirement for a Formalised Sonification Model development process.
To enable us to architect and experiment with sonifica- • What are the inputs and outputs of the sonifica-
tions in a flexible way, we need an underpinning sonifica- tion model? The sonification model should take as
tion model. This should enable us to utilise heterogeneous input both the data requirements for the represen-
sonifications alongside each other in order to compare per- tation, and the aesthetics derived: appropriate data-
formance. No such model currently exists, and we therefore sound mappings and sound design, and methods of
propose the development of a formalised model specifically scaling the data to the sound domain. The model
for developing sonification systems for network monitoring. should provide a method for mapping the required
This model should describe a grammar for the representation data to sound, following the aesthetic requirements
of network data through parameter-mapping sonification that input. The model should itself then produce the input
enables incorporation of and experimentation with appropriate to some sonification software. Adaptability of the
design aesthetics, techniques of musical composition, and the model according to differing aesthetic requirements is
science of auditory perception. It is important that the model important, particularly as we aim to compare multiple
encompasses prior art, and enables comparison with previous aesthetic approaches, and refine the aesthetic require-
approaches to designing sonifications in this space. ment specification through iterative user testing.
A model for designing sonifications for use in the network- • How can we verify that the sonification model is
monitoring context should tailor aspects of sonification design capable of addressing prior art approaches? In
such as cross-field interference to produce sonifications that order to enable comparison of new sonification system
are appropriate for network-monitoring tasks. A simple exam- designs with the approaches taken in prior work, it
ple is a simultaneous change in two network parameters: a is important that prior approaches can be replicated
statistically significant increase in traffic load, and messages through use of the sonification model developed. We
 can verify the correctness of the model for this task network anomaly detection, and for the detection of
by verifying that it has some representation of each particular classes of threat such as Advanced Persistent
relevant prior sonification approach. Threats (APTs) and Botnets [50–52]. Some of this
work involves interviews with security analysts to
B. Data Requirements
identify the properties of data analysts search for in
The data requirements include firstly the data sources used, network security monitoring to enable attack detection
since these produce different data types. For example packet [49, 53]. The findings from attack characterisation
capture header data might be represented – a different data type and prior work can be bolstered through interviews
to machine log data (including machine CPU, for example) or with security analysts, to gather their views on the
file access log data. The data requirements must also include importance of particular network data features for
the data features addressed. These are the properties of the network attack detection.
data that we choose to sonify, and may be low-level properties
(such as a representation of source IP address from which each C. Sonification Aesthetics
packet is received) or may be attack-detection features (such While there has been some work in aesthetic sonification,
as packet rate thresholds against which data are compared). as reported in Section III, it has not been heavily applied
The data requirements depend to a large part on the use- in the context of network monitoring. Prior work indicates
case. In developing sonification systems for anomaly detection that sonification aesthetic impacts on its effectiveness. In an
by humans, data requirements should be derived from infor- experiment comparing sonifications of guidance systems, for
mation about all data sources and features that enable network example, it was shown that sonification strategies based on
anomaly detection, and through which attacks are conveyed. pitch and tempo enabled higher precision than strategies based
On the other hand, for use in a multimodal system, which on loudness and brightness [54]. It was also shown in [55] that
conveys part of the network data sonically while other data particular sonification designs resulted in better participant per-
is conveyed visually, the sonification data requirements would formance in identifying features of Surface Electromyography
depend on which data had been selected to convey visually, data for a range of different tasks involved.
and which using the sonification. As another example, if the The aesthetics of the design are an important factor in
aim of sonification was to enable analysts to monitor network producing sonifications that are suitable for continuous pre-
security as a non-primary task, the data requirements should be sentation in this context. In particular, the sounds should be
informed by the data sources that analysts may be frequently unfatiguing [37, 56] and, if intended for use in non-primary
required to monitor while simultaneously conducting other task monitoring, should achieve a balance in which they are
tasks – these sources might include IDS alert logs, or the logs unobtrusive to the performance of other tasks while drawing
of critical servers on the network, for example. sufficient attention when necessary to be suitable for SOC
• Which data sources should be included in develop- monitoring. While there are other techniques that may be
ing sonifications for network-security monitoring useful, we propose an approach to this design that draws
purposes? It is important to identify those sources on techniques and theories of musical composition. We can
for which a sonified representation might add value draw on work in aesthetic sonification by Vickers [56], and
in network monitoring; these might be raw network on work in musification, i.e., the design of sonifications that
data sources such as packet captures, Netflow or are musical. Some key questions to be answered regarding
Domain Name System (DNS) logs, or the sources sonification aesthetics for network-security monitoring are
might be monitoring systems such as IDSs or network described below.
firewalls. Buchanan et al. categorised the potential 1) Which are the most appropriate mappings from
data sources used by security analysts in answering network-security data to sound? Prior work has indi-
a number of different analytical questions (for exam- cated preferred mappings from data to sound in certain
ple, in searching for the activities associated with a contexts; for mapping physical quantities such as speed
particular suspicious IP address) [49]. We hypothesise and size, for example [57]. Useful parallels can be drawn
that raw network packet capture data is most suitable between these previous experiments and the network-
for network attack detection, because this constitutes a monitoring context, and hypotheses can thus be made
full representation of traffic on the network. However, about appropriate data-sound mappings. However, it is
it would be valuable to identify the network data important to perform a context-specific assessment of
sources security analysts consider most useful for these mappings, in terms of their ability to convey the
network attack detection, and the methods by which required network-monitoring information in a way that
those sources are currently monitored. For example, users can comprehend. Associations formed through the
the information output of multiple such data sources previous experiences of users may affect the ease with
are often integrated in Security Information and Event which they can use certain mappings; for example, based
Management (SIEM) tools for monitoring by analysts. on prior work we might expect a mapping from packet
• Which data properties or features should be soni- rate to tempo of music to be intuitive. We propose that
fied to enable network anomaly detection by ana- user experiments should be carried out as part of the
lysts? In order to identify the data properties to be rep- sonification design process, to establish which mappings
resented, attack characterisation can be used to extract from data to sound are most appropriate. The results of
the ways in which classes of network attacks (flooding these user experiments will form an input to the sets of
attacks, for example) manifest in the network data data-sound mappings used in the sonification model, as
sources selected for representation in the sonification. shown in Figure 3.
Some prior work identifies network data features for 2) Which sonification aesthetics are suitable for use in
 network-security monitoring in SOCs? Comparison of monitoring, very few have conducted any user testing. None
a range of musical aesthetics (for example, a comparison have conducted testing to the extent required for an appropriate
between Classical Music and Jazz Music), should be understanding of the use of these systems and their suitability
carried out to identify those most suitable for the context. for actual deployment in security monitoring situations. As
In particular, aesthetics that are unfatiguing, unobtrusive such, we identify a requirement for significantly more in-
to other monitoring work, and able to attract the required context user testing of sonifications for network-monitoring
level of attention from analysts, should be chosen. It tasks, carried out with security analysts in SOCs, to inform the
may be that a suitable approach is to enable analysts design and investigate the advantages and disadvantages of the
to choose between a selection of musical aesthetics at approach. It is important that sonification systems are tested
will. It is important to assess the extent to which musi- in the SOC environment, in order to investigate how well they
cal experience affects the ability of security analysts to incorporate with the particular characteristics of SOCs – a va-
use musically-informed sonification systems in network- riety of systems running simultaneously, collaborative working
monitoring tasks. The effect of users’ musical experience practice, high levels of attention required from workers.
on their ability to understand and make use of the soni- We will conduct user testing to investigate the hypothesis
fication systems design will require investigation. Here, that sonification can improve the network-monitoring capabil-
musical experience refers to the level of prior theoretical ities of security analysts. This hypothesis is proposed in light
and aural musical training attained by the user. For this of prior work in other fields in which it is proven that certain
SOC monitoring context, analysts’ use of the systems capabilities can be improved by the presentation of sonified
should not be impaired by a lack of musical experience. data, as outlined in Section III, and of the limited experimental
3) What granularity of network-security monitoring in- evidence that shows that sonification can be useful for tasks
formation can we represent usefully using sonifica- involving network data specifically [4, 31].
tion? Given the huge volumes of network data observed For the validation of sonification as a solution to improving
on organisational networks, and the high speed of packet network-monitoring capabilities, there are certain key research
traffic on these networks, it should be assumed that questions that need to be answered through user testing.
some scaling or aggregation will be required in the sonic
representation of certain data sources. The amount of 1) To what extent, and in what ways, can the use of
information that can be conveyed through sound should sonification improve the monitoring capabilities of
be identified. This is both in the sense that sonification security analysts in a SOC environment? User testing is
software is actually capable of rendering the information, required to establish the extent to which sonification can
and that humans can usefully interpret the information aid security analysts in their network-monitoring tasks.
presented and hear the network data required for anomaly We theorise that there may be a number of use-cases for
detection, i.e. that the sound is not overwhelming. Meth- sonification of network data in SOCs. For example, inves-
ods for producing network data inputs that can be usefully tigation is needed to establish whether the presentation of
rendered as sound, such as aggregating packets over network data through sonification can enable analysts to
time intervals, or scaling quantities such as packet rate, “hear” patterns and anomalies in the data, and in this
should then be experimented with. Sampling packets is way detect anomalies more accurately than systems in
another possible approach; for example, Worrall uses any cases. Given the strong human capability for pattern
sampled network packets as the input to his network data recognition in audio representations [56, 58, 59], and for
sonification using the Sflow tool, which takes packets contextualising information, it is plausible that a system
from the traffic stream at a known sampling rate [30]. that presents patterns in network data may enable the
Comparative testing would be valuable at this stage to analyst to detect anomalies with greater accuracy than
assess the levels of granularity of data sonification at traditional rule-based systems. User testing should also
which network anomalies can be heard. The results of establish whether presenting sonified network data can
this assessment of appropriate data granularity will form enable analysts to monitor the network as a non-primary
an input to the scaling functions of the sonification model, task, maintaining awareness of the network-security state
as shown in Figure 3. while carrying out other exploratory or incident-handling
Besides aesthetics, aspects of human perception must in- tasks. Finally, we propose user testing to assess whether
fluence the design: the prior associations sounds may hold for multimodal systems, which fuse visualisations and soni-
users and the way in which this affects interpretation; the effect fications of complex data – which might usually be
of musical experience on perception. It is important that the presented visually across multiple monitors, for example
design takes into account factors in perception such as cross- – can aid analysts in their network-monitoring tasks.
field interference (in which different dimensions of sound – 2) Are there certain types of attack and threat that sonify
pitch and tempo, for example – interact in a way that affects more effectively than others, and what implications
perception of either) and does not induce cognitive overload does this have for the design of sonification systems
for the user. for network monitoring? It may be the case that certain
types of attacks are better-represented through sonification
D. Comprehensive User Studies than others, and that some attacks sound anomalous in a
As well as addressing sonification-aesthetic requirements way that is particularly easy for analysts to use while
through iterative user testing, we need to conduct user ex- others do not sonify well. Findings on this subject should
periments to investigate the utility of sonification systems for inform sonification system design by distinguishing the
network-security monitoring tasks. Section III indicates that attacks and threats in relation to which sonification per-
of the proposals made for sonification systems for network forms best, and the areas in which the technique therefore
 has the potential to be most effective. • Question 1: How many data points are required for
3) How does the performance of the developed sonifica- patterns to emerge?
tion tools in enabling network attack detection com- The presentation of network data at a range of differ-
pare with the performance of other network attack ent resolutions may be required for different monitor-
detection tools? The performance of users in network ing applications – see Subsection IV.B:
attack detection using sonification alone, and using net- Requirement 1: the model should enable any
work monitoring setups incorporating sonification, should number of data points to be represented.
be compared to their performance using visualisation and • Question 2: What properties of data dimensions
text-based interfaces. Users’ performances in detecting should be represented?
network attacks using the sonification should also be The properties of data dimensions represented should
compared with the performance of automated systems be those through which indicators of attacks are
such as IDSs. It is important to compare the attack detec- shown. These may vary based on the network type
tion performance (in terms of accuracy and efficiency) and the source of the monitoring information:
of humans using the sonification to that of automated
Requirement 2: the model should enable the
systems, for particular classes of network attack.
inclusion of appropriate data dimensions for
Answers to these questions will provide a greater un- individual designs.
derstanding of the role sonification can play in improving Furthermore, these dimensions may be continuous
monitoring capabilities in SOCs, the limits of the approach, (for example, packet rate), or discrete (for example,
and the extent to which it can be reliable as a monitoring direction of packet flow – incoming/outgoing). Appro-
technique. In conducting this testing, we expect to draw from priate mapping of both continuous and discrete data
existing research on conducting user studies in general, and in dimensions should be enabled in order to prevent un-
a security context [60, 61]. necessary loss of resolution in the data representation
V. F ORMALISED M ODEL FOR THE S ONIFICATION OF (for example, there would be a loss of resolution in a
N ETWORK S ECURITY DATA representation in which data with continuous values,
In this section, we expand on our proposal in Section IV by such as packet rate, was mapped to a sound with
presenting a formalised approach for the musical parameter- a small number of discrete values, such as type of
mapping sonification of network-security data. In particular, instrument):
we focus on our formalised sonification model (as introduced Requirement 3: the model should provide a
in Section IV.A). We first identify requirements for sonifying systematic method of mapping continuous and
network-security data, and from these requirements, construct discrete data dimensions to continuous and discrete
a model for developing sonifications for network-security sound dimensions.
monitoring uses. • Question 3: How many sound streams should be
Some work in formalising the sonification of data has been present in the design?
presented previously. For parameter-mapping sonification, a This depends on the network type, use-case and mon-
formalised representation of the sonification mapping function itoring information source, but in general network
is given by Hermann [23]. That representation was the basis of data is multivariate, with many network elements, data
the parameter-mapping sonification model that we developed sources, and packet flows that require monitoring. We
for network-security monitoring. In Hermann’s representation, require a method of communicating which of these
the parameter-mapping function g : Rd → Rm describes the streams is represented by particular sounds: we need
mapping from a d-dimensional dataset hx1 , ..., xd i ∈ Rd to an to represent information about a number of different
m-dimensional vector of acoustic attributes which are param- channels of the network data. This means, we need
eters of the signal generator. The q-channel sound signal s(t) to know what is happening, and to which parts of the
is computed as a function f : Rm+1 → Rq of the parameter- data:
mapping function g applied to the dataset, and time t: Requirement 4: the model should allow the inclusion
of appropriate sound channels for individual designs,
s(t) = ∑di=1 f(g(xi ),t).
and provide a method for systematically identifying
In developing our model, we draw on de Campo’s Sonifica- the channels and the dimensions required in the
tion Design Space Map (SDSM), which describes the questions representation.
to be addressed in any sonification design process [62]. The The formalised model should also meet certain other
map presents, as axes, three key questions for reasoning about requirements, based on the observations that were made in
data aspects in sonification design. We also use the work of Section IV. These can be summarised as follows:
Hermann [23]; in particular, we extend Hermann’s parameter- • We argued that sonification aesthetics, and mappings,
mapping sonification formalisation, by addressing the design require testing for the context in which they are used.
questions indicated by the SDSM. The model should therefore facilitate the insertion
A. Requirements of the Model of those data-sound mappings selected, according to
In what follows, we describe the use of the SDSM design experimental results and user preferences:
questions to extract requirements for the model. We present Requirement 5: the model should not prescribe
each question, then consider context-specific answers. We thus data-sound mappings.
identify requirements particular to sonification for network- • We also argued that the problem of listening fatigue
security monitoring. may be reduced, if users can select their own music
 and change it at will. Furthermore, experimentation γ β1 , ..., γ βy , for each sound channel csi :
with different musical aesthetics is required to deter-
mine those most suitable for the SOC environment. Γ i = hγγi1 , ..., γ iz i = hγγαi1 , ..., γ αix , γ βi1 , ..., γ βiy i.
Therefore: We now explain how this model meets the requirements we
Requirement 6: the model should not prescribe identified. Since the sound channels and sound dimensions
musical genre, and should allow for choice in its are left as an abstraction, Requirements 5 and 6 are met.
selection. Requirement 1 is also met through the use of abstract functions
to describe the mappings themselves, meaning the resolution
B. Formalised Sonification Model of the data presentation (number of data points presented) can
In Tables IV and V we present a formalised sonification be addressed through the choice of a function appropriate to
model for designing musical parameter-mapping sonifications any particular use of the model.
for use in network-security monitoring, developed to meet the Requirement 4 is addressed by the division of the
requirements identified. parameter-mapping into channels and dimensions; the channel
To construct the model, we divided Hermann’s formal- mapping function addresses Requirement 4, while the dimen-
isation for the parameter-mapping sonification of a dataset sion mapping function addresses Requirement 2. Requirement
[23] into individual mapping functions for data channels 3 is met by the division of the dimension mapping function
(corresponding to the channels identified in Requirement 4), into a continuous and a discrete mapping function.
continuous data dimensions and discrete data dimensions
(corresponding to the dimensions identified in Requirements
2 and 3). In Table IV, we define these data channels and
data dimensions. Our approach is well-suited to this particular
context because it allows us to reason about the channels of
information to be presented for each particular use-case. More-
over, we can systematically identify continuous and discrete
data, and their most appropriate mappings to sound. At the
end of this section, we discuss how the model we develop
meets the requirements identified.
The model comprises components (individual parts of the
data and the sound to be mapped, which we present in Table
IV), and relations (by which components are associated with
one another, which we present in Table V). The relations are
described by mapping functions.
A sonification is described by the tuple of its components
and relations (the meaning of each of these is explained in
Figure 4. Data Sound Mappings Space of the Model
Tables IV and V):
hCDR , DDR ,V DR , Relc , Reldα , Reldβ , Relv i.
In Figure 4, we illustrate the space of data-sound
The relations presented in Table V are described by parameter-mappings produced by the model. This shows the
the channel-mapping function (which describes the channel mappings from the sets of data channels and data dimensions
relation Relc ) and the dimension-mapping function (which (continuous and discrete) to possible sound channels and sound
describes both the dimension relation Reld and the value dimensions. We devised the list of sound channels and sound
relation Relv ). We also treat sound dimensions ds as functions dimensions by drawing on sonification design literature such as
of sound channels cs, which have values in the tuple of sound a survey by Dubus et al. of sonification mappings used in prior
values of each sound dimension, vs. work [57]; many of the items presented in Figure 4 are further
The channel-mapping function ψ :Rn → Rm describes the described in that work. We also considered aspects of musical
mapping from a tuple of n data channels CD = hcd1 , ..., cdn i composition in creating these lists, which are not necessarily
to a tuple of m sound channels CS = hcs1 , ..., csm i. The q- exhaustive, and can be added to.
dimensional sound signal s(t) is computed as the sum over
m sound channels cs of the dimension-mapping function Γ : VI. A PPLICATION OF THE M ODEL TO FACILITATE
Rm+1 → Rq , P ROTOTYPE D ESIGN
s(t) = ∑m To illustrate the application of the model, this section
i=1 Γ i (csi ,t),
shows how we used it to design two prototype sonifications of
where csi is the output of the channel-mapping function ψ : network packet capture data, aimed at two different potential
Rn → Rm applied to the data channel cd j and time t: use-cases of sonification within network-security monitoring.
csi = hψ
ψi (cd j ,t)| j ∈ {1, ..., n}i, We begin by presenting the two use-cases we considered. This
is followed by an outline of the network attack characterisation
and Γ i is the tuple of dimension-mapping functions γ ik , which that we used to derive the attack indicators to be represented
are applied to the z data dimensions ddik of the data channels for a defined network-monitoring scope. We demonstrate how
cd j that were mapped by ψ i to sound channel csi , and time the formalised model was applied, using these attack indica-
t. The functions γ ik describe the x continuous dimension tors, to generate prototype sonification systems for the two use-
mappings γ α1 , ..., γ αx , and the y discrete dimension mappings cases, and we describe the implementation of the prototypes.
 TABLE IV. DESCRIPTION AND FORMAL NOTATION OF MODEL COMPONENTS

Component Description Formal Notation

Data channels Parts of the network-security monitoring information, about which The tuple CD of data channels cd
information should be presented, e.g., individual packets, IDS
alerts, sensitive IP addresses on the network
Data dimensions Types of information we can present about data channels, e.g., The tuple DD of data dimensions dd. The tuple of data dimensions DD is
amount of activity (at network IPs, for example), protocol used (in the concatenation DDα_ DDβ of the tuple DDα of continuous data
packet transmission), CPU usage (of network machines). These can dimensions ddα, and the tuple DDβ of discrete data dimensions ddβ
have continuous or discrete values
Data values The values data dimensions can take. These can be continuous or The tuple V Ddd of data values vddd of the data dimension dd
discrete, e.g. a continuous scale from low to high (for packet rate,
for example); discrete names (of protocols)
Sound channels Streams of sound which we can vary sonically, e.g., individual The tuple CS of sound channels cs
note events, or separate melodic/instrumental lines
Sound dimensions Types of sonic variations we can make to sound channels, e.g. The tuple DS of sound dimensions ds. The tuple of sound dimensions DS
varying the tempo or loudness at which they are presented, or the is the concatenation DSα_ DSβ of the tuple DSα of continuous sound
harmonic structure they follow. These can have continuous or dimensions dsα, and the tuple DSβ of discrete sound dimensions dsβ
discrete values
Sound values The values sound dimensions can take. These can be continuous or The tuple V Sds of sound values vsds of the sound dimension ds
discrete, e.g. a continuous scale from slow to fast (tempo); discrete
names of instruments

TABLE V. DESCRIPTION AND FORMAL NOTATION OF MODEL RELATIONS

Relation Description Formal Notation

Channel relation Data channels are mapped to sound channels Channel relation Relc : CD ↔ CS is a total relation between the tuple of
data channels and the tuple of sound channels
Dimension relation Data dimensions are mapped to sound dimensions (which can be Dimension relation Reld : DD ↔ DS is a total relation between the tuple of
discrete or continuous) data dimensions and the tuple of sound dimensions
• Continuous dimension relation, in which continuous • Continuous dimension relation Reldα : DDα ↔ DSα is a total
data dimensions are mapped to continuous sound relation between the tuple of continuous data dimensions and
dimensions the tuple of continuous sound dimensions
• Discrete dimension relation, in which discrete data • Discrete dimension relation Reldβ : DDβ ↔ DSβ is a total
dimensions are mapped to continuous or discrete sound relation between the tuple of discrete data dimensions and the
dimensions tuple of discrete sound dimensions

Value relation Values of data dimensions are mapped to values of sound For each data dimension dd, mapped to sound dimension ds, value
dimensions relation Relvdd : V Ddd ↔ V Sds is a total relation between the tuple of data
values of dd and the tuple of sound values of ds

Finally, we show how the model can be used to capture prior- Use-Case 1: high-granularity sonification of network data
art approaches to the sonification of network data. to enable attack detection through pattern recognition by
human security analysts: Humans have used sound in the past
to detect anomalies with very high levels of resolution; an
A. Use-Cases example is human sonar operators, who classify underwater
In Section II we highlighted potential advantages of using sources by listening to the sound they make [63, 64]. Further-
sonification for network monitoring. Here, we extend that more, sonification systems have been successfully designed
discussion to create two different use-cases for sonification for pattern recognition [58], and anomaly detection [59], for
for network monitoring in SOCs. The first case focuses on example, in prior work involving complex datasets.
enabling anomaly detection by security analysts deliberately The motivation for this use-case is that, as described in Sec-
listening to low-level network data, while the second case tion II, automated systems such as IDSs do not always detect
focuses on enabling peripheral monitoring of network-security attacks effectively or accurately, producing false-positives and
information by security analysts as a non-primary task. false-negatives [2,3]. Presentation of data to humans in a visual
The two use-cases have different design requirements, since form, using security visualisations, can enable detection of
they target different modes of monitoring. Vickers differenti- malicious network activity that is undetected by automated sys-
ates between modes of auditory monitoring [56]. We associate tems. Given the human ability for pattern recognition through
Use-Case 1 (as described below) with Vickers’ description of listening, it should not be assumed that vision is the most
the direct monitoring mode, in which the user deliberately effective medium for this in all cases without first comparing
listens to an audio interface as their main focus of attention, performances using vision and hearing experimentally [65].
aiming to extract information or identify salient characteristics. To enable anomaly detection by humans, we aim to rep-
Use-Case 2 is associated with Vickers’ peripheral monitoring resent low-level network data with the highest granularity and
mode, in which the user focuses attention on another primary resolution of information possible, such that patterns in the
task, while indirectly monitoring required information relating data may emerge naturally.
to another non-primary task, which is presented through a Use-Case 2: high-level sonification of network data for
peripheral auditory display. monitoring aspects of the network-security state as a non-
primary task: Analysts are required to carry out multiple hardware components during manufacture and transporta-
tasks while monitoring the network for security breaches, tion).
maintaining an awareness of the security of the network [37].
With this scope in mind, we considered attacks in the
This may mean, for example, continuing to monitor real-time
Mitre Common Attack Pattern Enumeration and Classification
network or IDS logs, while exploring or handling a potential
(CAPEC) list (https://capec.mitre.org). This is a comprehensive
security incident [66]. The aim of sonification in this use-
listing and classification of computer attacks for use by,
case is to represent sonically the information that analysts
amongst others, security analysts. From this list, we selected
need to maintain an appropriate awareness of the network-
attacks that fell within the defined scope. Excluding packet
security state, in such a way that the information can be
contents especially enabled us to narrow the scope of attacks
effectively monitored as a non-primary task. To produce a
considered initially to a list of around twenty types of attack,
sonification suitable for use in peripheral monitoring tasks,
including reconnaissance such as port scanning, and threat
we aim to present a higher level of information than in Use-
realisation such as service flooding. This is because many
Case 1: summaries of the data to enable comprehension of
of the attacks listed in CAPEC could not be detected by
network-security state, rather than perception of anomalies and
monitoring only packet header information without packet
deviations from the normal.
contents.
Vickers argues that visual monitoring methods are not
We characterised the attacks in terms of the way they
well suited to situations in which users are required to focus
are indicated through the network data monitored, i.e. packet
attention on a primary task, while monitoring other informa-
header information. After completing this work, we were able
tion directly, because of the demands this places on visual
to produce a summary of the data features needed to capture
attention [56]. He summarises why sonification is well suited
indicators of the attacks within the network monitoring scope.
to monitoring peripheral information: “...the human auditory
The data features we selected are defined as follows.
system does not need a directional fix on a sound source
in order to perceive its presence”. Experimental work has • Packets: the flow of packets into, out of or within the
shown that sonification is an effective method of presenting network.
information for monitoring as a secondary task. Hildebrandt ◦ Rate: the amount of traffic.
et al. compared participants’ performances in monitoring a ◦ Direction: The direction in which network
simulated production process as a secondary task in three traffic is moving (entering network, leaving
conditions – visual only, visual with auditory alerts, and visual network, moving within network).
with continuous sonification – while solving simple arithmetic ◦ Size: the byte count of a packet.
problems as a primary task [67]. The results showed that ◦ Protocol: the protocol with which traffic is
participants performed significantly better in the secondary associated.
monitoring task using the continuous sonification than in the
visual, or auditory alert, conditions. Furthermore, secondary Rate: the amount of traffic transmitted
monitoring using the continuous sonification had no significant using a particular protocol.
effect on participants’ performances in the primary task. ◦ Source IP: the IP from which packets are sent,
B. Data Requirements: Network Attack Characterisation within or outside the network.
Despite the differences in the levels of information required Rate: the amount of traffic associated with
for the two prototypes, the underlying data requirements are a source IP address.
the same: for both cases, we require network data to be Range: the number of source IP addresses
represented such that attacks are signalled by the sonification. as which traffic is observed.
We therefore used the same attack characterisation as the ◦ Destination IP/port: the IP and port to which
basis for both prototypes, enabling us to identify the network packets are sent, within or outside the network.
data that should be monitored to indicate the attacks within a
defined network and monitoring information sources scope. We Rate: the amount of traffic associated with
varied the treatment of the resulting data requirements in the a destination IP address or port.
application of the formalised model, taking into consideration Range: the number of destination IP ad-
the purpose of the prototype, and the required resolution of dresses or ports at which traffic is ob-
data presentation. In particular, for Prototype 1, we aimed to served.
represent all attack indicators derived, while in Prototype 2 we The derived data features are shown in Table VI. In the
focused on representing one particular attack indicator derived table, the leftmost three columns display the data features,
– the traffic rate at destination IP addresses on the monitored while the rightmost three columns show the characterisation
network, such that the amount of traffic received at each of of three examples of attacks (TCP SYN scan, data exfiltration
these IPs may be monitored as a non-primary task. and DDoS) in terms of these features. The data features entered
We characterised the data requirements for representing in each column are characteristics of those in the preceding
indicators of attacks that can be detected within a network- column. For example, rate (third column) is a characteristic
monitoring scope; the scope was defined as follows: of source IP, (second column), which is itself a characteristic
1) The network is a local area network (LAN). of packet (first column). The attack characterisation columns
2) The network data monitored is packet header information, show how we used the data features to characterise three
excluding packet contents. different network attacks. For example, given a data exfiltration
3) Network data is monitored in real-time only (we, there- attack, the data features listed in the second attack characteri-
fore, excluded aspects such as supply chain attacks on sation column of Table VI are required.
 TABLE VI. NETWORK ATTACK CHARACTERISATION EXAMPLES AND DERIVED DATA PRESENTATION REQUIREMENTS

Required Data Attack characterisation

Features Features Features Attack type: TCP SYN scan Data exfiltration DDoS
(Characteris- (Characteris-
tics of First tics of Second
Column) Column)
Attack TCP protocol, SYN packets Data exfiltrated from network Network is flooded by a high
description: sent to a range of destination to external wide of
ports on a host address traffic sent from
multiple hosts
Packet
Rate High
Direction Inbound Outbound Inbound
Size
Protocol FTP
Rate High
Source IP Single IP outside Single IP inside Multiple IPs outside network
network network
Rate High High High
Range Wide
Destination IP Single IP inside Single IP outside One or more IPs inside
network network network
Rate High High High
Range
Destination Ports on single host IP inside
port network
Rate
Range Wide (all ports targeted –
scan)

C. Prototype 1: Low-Level Network Data Sonification for source IP dimension for each individual packet).
Anomaly Detection by Humans For this prototype, the sonification is described by the tuple
The aim of Prototype 1 is to sonically represent network hCDR , DDR ,V DR , Relc , Reldα , Reldβ , Relv i:
data through which an attack might be signalled with as • CDR = hcdR1 i = hpacketsi
high a resolution as possible, in order to enable anomaly • DDR = DDα_
detection through emerging sound patterns. We show how R DDβR = hddαR1 , ddαR2 , ddαR3 ,
ddαR4 , ddαR5 i_ hdβdR1 , dβdR2 i = hSource IP,
we applied the model in the design of the sonification by Destination IP, Destination Port, Rate,
considering appropriate data channels, dimensions and values. Sizei_ hDirection, Protocoli
We develop a prototype design, and highlight challenges in the
• V DdR =hvddR1 , vddR2 , vddR3 , vddR4 , vddR5 , vddR6 ,
implementation.
vddR7 i = h{1, ..., 232 }, {1, ..., 232 }, {1, ..., 216 },
Here we seek to present prototype designs. The purpose {low,normal,high},{small,normal,large},
is not to develop final system designs, but to illustrate the {incoming,outgoing,internal},(the protocols present
use of the sonification model for designing sonifications for in the dataset)i
particular use-cases within network-security monitoring, and
• Relc is described by the function ψ i : R1 → Rm ,
to demonstrate how the application of the model can be varied
csi = ψ i (cd1 )
depending on the use for which the sonification is intended.
1) Applying the Sonification Model: We derived the data • Reld and Relv are described by the function
channels, data dimensions and data values for the prototype Γ : Rm+1 → Rq , Γ i =hγγαi1 , ..., γ αix , γ βi1 , ..., γ βiy i
using the data requirements presented in Table IV. In this ∀i ∈ {1, ..., m}
case, in order to achieve the highest possible resolution in the We assume that the IP version is IPV4 in the above descrip-
sonification of these data requirements, we aimed to present, as tion of source and destination IP values. Although source and
closely as possible, each packet captured, and to represent as destination ports and IPs are not technically continuous they
much information about each packet as possible as dimensions have such a high number of possible values (232 for IPV4)
of the packet channel. We therefore let the entries in the first that we treat them as such. In describing some data values,
column (a single entry: packets) of Table VI be the tuple of we used a notion of “normal”. This is left as an abstraction
data channels, and all entries in the second column be the in the model, and describes some expectation for the observed
tuple of data dimensions. The entries in the third column are behaviour of the data dimensions. We discuss how this normal
then conveyed naturally, through the mapping of the selected abstraction might be implemented in sonification designs in
data channels and dimensions (for example, range of source Section VI.E.
IPs – third column – does not have a defined mapping, but To simplify the design process, we describe data values
is presented through the cumulation of the presentation of the for rate and size as discrete points of interest (for example,
low, high, narrow, wide). This description does not exclude the • size NOT → pitch, tempo.
possibility of mapping continuously in the representation, but We thus arrived at the following set of relations for the
allows indication of the polarity required in dimension map- prototype design.
ping. In sonification, polarity is the direction of the mapping
from data to sound. For example, positive mapping polarity • Data channels:
from the data dimension rate to the sound dimension amplitude ◦ Packet → individual tone (cs1 = ψ 1 (cd1 ,t))
would be described: • Data dimensions (continuous):
• rate: high → amplitude: loud; ◦ Rate → tempo (positive polarity)
• rate: low → amplitude: soft. (ds11 = γ α1 (dd11 ,t))
◦ Destination IP → spatialisation (pan from left
In Figure 5, we present the sonification mapping space
to right headphone) (dsα12 = γ α2 (ddα12 ,t))
introduced in Figure 4, applied to Prototype 1. This shows
◦ Source IP → pitch (dsα13 = γ α3 (ddα13 ,t))
the data channels, continuous data dimensions and discrete
◦ Destination port → articulation
data dimensions with all possible mappings to sound channels
(dsα14 = γ α4 (ddα14 ,t))
and sound dimensions.
◦ Size → amplitude (positive polarity)
(dsα15 = γ α5 (ddα15 ,t))
• Data dimensions (discrete):
◦ Protocol → instrument
(dsβ11 = γ β1 (ddβ11 ,t))
◦ Direction → register (dsβ12 = γβ2 (ddβ12 ,t))
Figure 6 shows the prototype design developed from these
relations. In this sonification, each packet observed triggers
an individual note event; these events shown as musical notes
in Figure 6. The above dimension mappings are represented:
the sonification maps data dimensions to the sound dimensions
(including instrument, for example) of each note. The sound
is panned on a continuous scale between left and right,
corresponding to the continuous destination IP dimension. The
rate of traffic at each destination IP is represented by the
tempo of the notes played at that pan location; source IPs
Figure 5. Data Sound Mappings Space: Prototype 1 map continuously to frequency such that source IP range is
represented by the range of frequencies played. As shown in
Figure 6, destination ports map to articulation on a continuous
To determine the mappings from data to sound for the scale. The instrument by which each note is played represents
prototype, we selected sound channels, continuous sound di- the protocol in which the packet is transmitted, and the
mensions and discrete sound dimensions from the sets CS, DSα direction of traffic is conveyed by differentiating between low,
and DSβ respectively. We have not yet carried out testing of medium and high registers of music.
appropriate mappings for the data dimensions, as described
in Section IV; this is left to future work. Instead, we made D. Prototype 2: High-Level Network-Data Sonification for
predictions about appropriate mappings at this stage, drawing Monitoring Network-Security Information as a Non-Primary
on a survey of mappings used in the sonification of physical Task
quantities in prior sonification work [57]. In that paper, prior The aim of Prototype 2 is to enable security analysts to
work in which physical quantities are sonified is surveyed, and monitor network data for indicators of attacks as a non-primary
it is noted whether data-sound mappings were: assessed as task. The sonification must represent aspects of the network
good; assessed as poor; implemented but not assessed; or not data that might signal an attack, in a way that is unobtrusive
implemented but mentioned as future work. We applied those usually, but draws analysts’ attention to aspects of the data
assessed as good for quantities we considered representative when required (when a potential attack indicator arises). The
of our data dimensions (for example, for the data dimension use-case is different to an alert system: the goal here is to
rate, we considered the physical quantities velocity, activity be informative about which data has changed, and how it has
and event rate from [57]). From this, we derived the following changed.
information, which was then incorporated into the prototype Our design approach for this use-case is to sonify a subset
design. of the data through which attacks are indicated – the traffic
• Rate. Good mappings described for velocity: pitch, rate at the destination IP addresses on the network. The
brightness, tempo, rhythmic duration. Good mappings rationale for this approach is that to be suitable for periph-
described for activity: tempo, rhythmic duration [57]. eral monitoring, the sonification should be uncomplicated to
• Size. Bad mappings described for size: pitch, tempo understand. We therefore elect not to sonify all indicators
[57]. derived in our network-attack characterisation, as in Prototype
1, but to produce a simpler representation of a subset of these
Applied to our sound mappings space, this generated the indicators. Our network-attack characterisation showed that
following rules. high traffic rates at particular destination IP addresses on the
• rate → pitch, tempo, rhythmic duration network were frequently indicators of attacks (see Table VI).
 Figure 6. Prototype Diagram: Prototype 1

Monitoring the amount of activity at sensitive machines on the sonification for Prototype 1, hold for this case also: the
network such as those on which databases containing sensitive “normal” packet rate for each IP could be prescribed by a
information are stored is important, and we selected this as human, set as an average calculated statistically, or calculated
the aim of this peripheral-monitoring sonification prototype. using Machine Learning.
In the remainder of this section we show how this difference In Figure 7, we present the sonification mapping space
in approach influences the application of the model and leads introduced in Figure 4, applied to Prototype 2. This shows
to differing prototype designs. the data channels and continuous data dimensions (there are
1) Applying the Sonification Model: We derived the data no discrete data dimensions in this case) with all possible
channels, data dimensions and data values for the prototype mappings to sound channels and sound dimensions.
by considering the data requirement: present the traffic rate at
destination IP addresses on the network. Given the purpose
of the sonification is to be suitable for use in peripheral
monitoring, we aim to present sonified information such that
data changes judged significant (in this case, large increases in
traffic rate at any destination IP represented) draw attention,
and the sonification is otherwise unobtrusive. We let 10 indi-
vidual destination IP addresses be the data channels, and the
packet rate be the data dimension.
For this prototype, the sonification is described by the tuple
hCDR , DDR ,V DR , Relc , Reldα , Reldβ , Relv i:
• CDR = hcdR1 i = hDestination IP addressesi
• DDR = DDα_ R DDβR = hddαR1 , ddαR2 ,
ddαR3 i_ hdβdR1 i = hRatei
• V DdR = hvddR1 i = h{low,normal,high}i
• Relc is described by the functions ψ i : R10 → Rm , Figure 7. Data Sound Mappings Space: Prototype 2
csi = hψ
ψi (cd j )| j ∈ {1, ..., n}i, where n is the number
of network destination IP addresses represented
• Reld and Relv are described by the function As described for Prototype 1, we drew on prior work [57]
Γ : Rm+1 → Rq , Γi =hγγαi1 , ..., γαix , γβi1 , ..., γβiy i to select from the set of sound channels and continuous sound
∀i ∈ {1, ..., m} dimensions. The relations we arrived at are as follows.
The notes on the prescription of a “normal” value, and • Data channels
representations of polarity, following the presentation of the ◦ 10 destination IP addresses → 10
 instrumental lines these challenges, and hence identify directions for future devel-
(csi = ψ i (cdi ,t)∀i ∈ {1, ..., 10}) opment. The most significant challenge in the implementation
• Data dimensions (continuous): of Prototype 1 arose as a result of the sheer number of packets
◦ Rate → tempo (positive polarity) logged in the dataset, and the small times between their arrival.
(dsαi1 = γ α1 (ddαi1 ,t)∀i ∈ {1, ..., 10}) Because of this, it was challenging to implement the channel
relation ψ 1 – to render each packet observed as individual
notes without overloading the sound engine, or creating sounds
Packet rate at IP → tempo of instrumental line
too complicated to be of use to human listeners.
Destination IP 1 → We sampled randomly every 1 in 10 packets in the
instrumental line 1 dataset to address this challenge; however, as future work it
is important to investigate the most appropriate methods of
aggregation, sampling and scaling. For example, a solution
might be to aggregate the packets sent in each individual
Destination IP 10 → connection (between the same two IP addresses and ports,
instrumental line 10
and using the same service) over time intervals (for example,
Figure 8. Prototype Diagram: Prototype 2 every 0.1 seconds), and represent the aggregation over this time
interval with a single note, whose amplitude varies depending
on the number of packets aggregated in this time. This would
Figure 8 shows the prototype design developed from these be a potential way of addressing the problem of packet rates
relations. In this sonification, the individual instrumental lines too fast to sonify, without losing the granularity of information
that form the musical piece each present information about an provided by the representation of each individual packet.
individual destination IP address on the network (in the figure, Grond and Berger write that sonification mapping functions
we present an example in which 10 destination IP addresses are may sometimes be linear, but other forms may be more suitable
monitored). The lines each follow the base tempo of the musi- depending on the data [56]. Scaling exponentially, or using
cal piece when the packet rate at the destination IP addresses methods such as step-change analysis or Fourier Transforms,
they represent is at its “normal” value. When the packet rate at are examples of avenues worth exploring. Establishing the
an individual destination IP address exceeds its “normal” value, resolution with which we can represent each of the listed
note repetition is introduced in the corresponding instrumental data channels and data dimensions will be a key part of the
line, and the speed of note repetition is scaled to convey the development and testing process.
size of the increase in packet rate. As such, a destination IP The destination IP representation approach of Prototype 2
with a high traffic rate is represented in the sonification as an may become challenging on large networks. The aim of the
instrumental line with fast note repetition. prototype is to represent monitoring information in a relatively
simple fashion suitable for peripheral monitoring. However, the
E. Implementation of Prototypes
number of instrumental lines required to represent the many
We implemented both prototypes and used them to sonify destination IP addresses on a large organisational network
the Centre for Applied Internet Data Analysis (CAIDA) would likely introduce complexity to the sonification and make
“DDoS Attack 2007” dataset [68]. We describe our processes extracting information about individual IP addresses difficult
for, and the challenges that arose during, implementation of for the user. It is important to investigate experimentally
this dataset. The dataset contains a DDoS attack in which a how much information we can represent – in this case, how
large flood of incoming traffic is observed, sent from a wide
many destination IP addresses we can represent information
range of source IP addresses to destination IP addresses on
about simultaneously in a way that is useful, and whether
the network. We reflect on the sounds produced by the two this can match the monitoring requirements of SOCs in large
sonifications of this dataset; in particular, the sounds produced organisations.
at the time when the flooding begins compared with the sounds
prior to the flooding. F. Addressing Prior-Art Approaches Using the Sonification
We implemented the prototypes by reading the dataset in Model
Python, and parsing the data values according to the mapping We describe the use of our formalised sonification model in
functions presented in Tables VII and VIII. These parsed representing previously-published sonification system designs.
values were then rendered as sound using Supercollider (http: In particular, we verify that our model can address all previous
//supercollider.github.io/), a platform for audio programming systems (those in which the sonification design is specified
and synthesis frequently used in prior sonification work. The completely) that use a musical parameter-mapping sonification
sound rendering was controlled by Open Sound Control (OSC) method to represent raw network data (these aspects of the sys-
messages sent from Python to Supercollider. tems are presented in Table II) [29, 33, 43–45]. Other relevant
Although we have not yet conducted user testing for these systems which use a musical parameter-mapping approach to
prototypes, our initial assessment from listening to the sonifica- represent raw network data are presented in [30, 31, 42], but
tions ourselves is that there is a significant change in sound in the sonification designs for these works are not specified in
both prototypes at the time that the dataset shows flooding from enough detail to include.
multiple source IPs. We invite the reader to listen to audio clips In Table IX we present the relevant pre-existing soni-
of each of the two network-security monitoring prototypes run- fication systems in terms of the data channels and data
ning on this dataset (https://soundcloud.com/user-71482294). dimensions, and the sound channels and sound dimensions
We encountered some challenges during the implementa- of our model. In Table X we present the channel relations
tion phase; in the following, we reflect on possible solutions to and dimension relations for each prior sonification approach
 TABLE VII. IMPLEMENTATION OF PROTOTYPE 1

Relation Addressed Description of Implementation Mapping Function

Channel relation: cs1 = ψ 1 (cd1 ,t) Individual packets observed are mapped to individual tones The function ψ 1 can be described: for the pth packet cd1p
observed at time t, play a single tone cs1p at time t
Dimension relation: Destination IP is mapped to spatialisation (pan from left to right headphone). The function γ α2 can be described: for a note cs1p played
dsα12 = γ α2 (ddα12 ,t) Here, the possible destination IP addresses take values in the range [0, 232 ], we at time t, and IP conversion function IPVal, the pan value
IPVal(ddα12p )×2
converted destination IP addresses to values in this range using a function such is dsα12p = −1
that IP address 0.0.0.0 → 0, and 0.0.0.1 → 1. The pan value varies 232

continuously in the range [−1, 1]

Dimension relation: Source IP is mapped to pitch. Here, the possible source IP addresses take For a source IP hotlist tuple Hs , and tuple Mn of musical
dsα13 = γ α3 (ddα13 ,t) values in the range [0, 232 ] and the frequencies vary in the chosen range notes hC, E, G, Bi, the function γ α3 can be described: for
[261.63, 2093]. Frequency 261.63Hz corresponds to C4 – middle C – while note cs1p at time t, and IP conversion function IPVal, the
frequency 2093Hz corresponds to C7, three octaves higher. We also use a pitch value is ddα13p ∈ Hs =⇒ dsα13p ∈ Mn , ddα13p 6∈
hotlisting method: the top 50 source IPs we expect to observe are mapped to IPVal(ddα13p )×(2093−261.63)
Hs =⇒ dsα13p = 232
+ 261.63
harmonic tones (the notes of a C major 7th chord), while source IPs outside
this hotlist are mapped on a continuous scale to frequencies in the selected
range
Dimension relation: Destination port is mapped to articulation. Here, the possible destination ports The function γ α4 can be described: for a note cs1p played
dsα14 = γ α4 (ddα14 ,t) take values in the range [0, 216 ], and the articulation takes values in the range ddα14p ×0.9
at time t, the articulation value is dsα14p = 16 + 0.1
[0.1, 1]. Many packets observed in this dataset did not have destination port 2

values; in these cases we set the sound articulation value to be 0.5 in

Supercollider.
Dimension relation: Size is mapped to amplitude (positive polarity). Here, for the dataset we The function γα5 can be described: for a note cs1p played
dsα15 = γα5 (ddα15 ,t) implemented the average packet size was 60 bytes, while occasional packet at time t, the amplitude value is
ddα
sizes were very large. We mapped the size values of the packets to the dsα15p = 12 (log10 ( 6015p × 100))
amplitude values of the sound using a logarithmic function, in which the
average packet size, 60, mapped to an amplitude value we judged
“comfortable” – the amplitude value 1 in Supercollider.
Dimension relation: Protocol is mapped to instrument. Here, a hotlisting method is used again. The The function γ β1 can be described: for a note cs1p played
dsβ11 = γ β1 (ddβ11 ,t) two protocols most frequently seen in this dataset are mapped onto two at time t, the instrument value is
different instruments; the remaining protocols are mapped to another ddβ11p ∈ Hp =⇒ dsβ ∈ hMi1 , Mi2 i,
instrument. For this dataset, the tuple of hotlisted protocols is: Hp = hICMP, ddβ11p 6∈ Hp =⇒ dsβ = Mi3
TCPi, and the tuple of instruments selected was: Mi = hstrings, saxophone,
pianoi

TABLE VIII. IMPLEMENTATION OF PROTOTYPE 2

Relation Addressed Description of Implementation Mapping Function

Channel relation: Destination IP addresses within a hotlist of 10 addresses Hd = hdst1 , ..., dst10 i The function ψ i can be described: at any time t, play all
csi = ψ i (cdi ,t)∀i ∈ {1, ..., 10} are mapped to 10 musical lines in the tuple M = hm1 , ..., m10 i musical lines mi ∈ M
Dimension relation: dsα11 = Rate is mapped to tempo (positive polarity), scaled such that the average rate The function γ α1 can be described: for a musical
γ α1 (ddαi1 ,t)∀i ∈ {1, ..., 10} for a particular destination IP is mapped to the base tempo of the music. The instrumental line mi ∈ M played at time t, where the
rate is measured by aggregating the number of packets observed at each IP per average rate for the corresponding destination IP address
second, and comparing this with the average number to derive the tempo for dsti is avratei and the base tempo of the music is
ddα
the corresponding second of music avtempo, the tempo value is dsαi1 = avratei1 × avtempo
i

TABLE IX. APPLYING THE FORMALISATION TO CAPTURE PREVIOUS MUSICAL PARAMETER-MAPPING SYSTEMS FOR THE SONIFICATION
OF RAW NETWORK DATA: COMPONENTS

Author Data Channels Data Dimensions Sound Channels Sound Dimensions

Qi [43] Traffic queue 16 (cd1 ) Continuous: byte rate (ddα11 ); packet rate Piano notes (cs1 ) Continuous: frequency (dsα11 ); amplitude
Mapping 1: (ddα12 ) (dsα12 )
Qi [43] Traffic queues 1–16 Continuous: byte rate (ddα11 ); packet rate 16 groups of piano notes Continuous: frequency (dsα11 ); amplitude
Mapping 2: (cd1 , ..., cd16 ) (ddα12 ) (cs1 , ..., cs16 ) (dsα12 )
Brown [44] Network traffic (cd1 ) Continuous: packet rate (ddα11 ; number of Existing musical piece (cs1 ) Continuous: number of sharp notes
TCP handshakes (ddα12 ); number of HTTP (dsα11 ); pitch (dsα12 ); rhythm (dsα13 )
error messages (ddα13 )
Ballora [33] Socket exchanges (cd1 ); Continuous: source IP (ddα11 ); destination An individual strike of a Continuous: rumble’s timbre (dsα11 );
requests to unusual ports IP(ddα12 ); frequency of packets in ongoing gong (cs1 ); humming sound sizzle’s timbre (dsα12 ); stereo pan position
(cd2 ); traffic in 5 different socket connections (ddα13 ); traffic rate (cs2 ); 5 distinct whooshing (dsα13 ); force of strike (dsα14 ); timbre (of
monitoring locations (within (ddα34 ) sounds (cs3 ) humming sound) (dsα25 ); amplitude (of
2 subnets; between subnets; Discrete: port number (ddβ21 ) whooshing sound) (dsα36 )
external traffic going to each
subnet) (cd3 )
Giot [29] Packets (cd1 ); useless packets Continuous: packet size (ddα11 ); Individual note events Continuous: frequency (dsα11 ); note
(e.g. ACK packets) (cd2 ) time-to-live (TTL) (ddα12 ); rate/bandpass (MIDI) (cs1 ); noise (cs2 ) duration (dsα12 ); bandpass of resonant filter
(ddα13 ); number of useless packets (ddα21 ) (dsα13 ); amount of noise (dsα24 )
Discrete: Protocol (ddβ11 ) Discrete: sound synthesiser (dsβ11 );
Mancuso [45] Individual packets (cd1 ) Continuous: source IP (ddα11 ); destination String note (cs1 ); wind note Continuous: pitch (dsα11 , dsα21 );
IP (ddα12 ) (cs2 ) amplitude (dsα12 , dsα22 )
Discrete: packet size (ddβ11 )
TABLE X. APPLYING THE FORMALISATION TO CAPTURE PREVIOUS MUSICAL PARAMETER-MAPPING SYSTEMS FOR THE SONIFICATION
OF RAW NETWORK DATA: RELATIONS

Author Channel Relations Dimension Relations

Qi [43] Single traffic queue → all piano notes Byte rate → frequency (dsα11 = γα1 (ddα11 ,t)); packet rate → amplitude (dsα12 = γα2 (ddα12 ,t))
Mapping 1: (cs1 = ψ(cd1 ))
Qi [43] Traffic queue i → piano notes group i Byte rate → frequency (dsαi1 = γα1 (ddαi1 ,t)∀i ∈ {1, ..., 16}); packet rate → amplitude
Mapping 2: (csi = ψ(cdi )∀i ∈ {1, ..., 16}) (dsαi2 = γα2 (ddαi2 ,t)∀i ∈ {1, ..., 16})
Brown [44] Network traffic → existing musical piece Traffic rate → number of sharp notes (dsα11 = γα1 (ddα11 ,t)); number of TCP handshakes → pitch
(cs1 = ψ(cd1 )) (dsα12 = γα2 (ddα12 ,t)); number of HTTP error messages → rhythm (dsα13 = γα2 (ddα13 ,t))
Ballora [33] Socket exchange → individual strike of gong Source IP → gong rumble’s timbre (dsα11 = γα1 (ddα11 ,t)); destination IP → gong sizzle’s timbre
(cs1 = ψ(cd1 )); request to unusual port → (dsα12 = γα2 (ddα12 ,t)); source IP, destination IP → stereo pan position (dsα13 = γα3 (ddα11 , ddα12 ,t));
humming sound; traffic in five different frequency of packets → force of strike (dsα14 = γα4 (ddα13 )); port number → timbre of humming sound
monitoring locations → five distinct whooshing (dsα25 = γβ1 (ddβ21 )); traffic rate → amplitude of whooshing sound (dsα36 = γα4 (ddα34 ))
sounds
Giot [29] Packets → individual note events (cs1 = ψ(cd1 )); Packet size → frequency (dsα11 = γα1 (ddα11 ,t); TTL → note duration (dsα12 = γα2 (ddα12 )); rate →
useless packets → noise (cs2 = ψ(cd2 )) bandpass of resonant filter (dsα13 = γα3 (ddα13 )); protocol → sound synthesiser (dsβ11 = γβ1 (ddβ11 ));
number of useless packets → amount of noise (dsα24 = γα4 (ddα21 ))
Mancuso [45] Individual packets → string note, wind note Source IP → pitch of string note (dsα11 = γα1 (ddα11 ,t)); destination IP → pitch of wind note
(cs1 = ψ(cd1 ), cs2 = ψ(cd1 )) (dsα21 = γα2 (ddα12 ,t)); packet size → amplitude (of string note and wind note) (dsα12 = γβ1 (ddβ11 )),
(dsα22 = γβ1 (ddβ11 ))

addressed. This shows that the systems addressed can all be mensions. A challenge in the implementation of the prototypes
represented in our model, which allows for comparative testing lies in determining appropriate meanings of this “normal”,
of newly-developed sonification systems against pre-existing which is left as an abstraction in the model. The normal might
approaches. in practice be defined, or calculated using Statistics or Machine
Learning for a particular network. The normal could also be
VII. C ONCLUSION AND F UTURE W ORK defined not by the system itself, but discerned by the humans
using the system, based on what they expect to be, or have
We conclude that there is a growing requirement for the
become accustomed to, hearing. The former approach is likely
validation of sonification as a means of improving certain
to be more appropriate for enabling the peripheral monitoring
monitoring capabilities in SOCs. The current state of the art
capability targeted in Use-Case 2, while the latter (in which
provides evidence of the potential of sonification in advancing
humans learn to “hear” some normal) may apply to Use-Case
network-security monitoring capabilities. Systems proposed
1, given the aim to enable humans to detect anomalies.
and in use have been shown to be as effective as, or more
effective than, other network monitoring techniques insofar as Alternative methods of extracting the data requirements for
a limited amount of testing has been performed [19]. network-attack detection should be explored. The attack char-
acterisation approach taken here could be extended, and vali-
As future work, we intend to perform proof-of-concept
dated, through security analysts’ input on their real network-
experiments for the sonification prototypes. For Prototype 1,
data monitoring requirements. This should explore both how
we will sonify a number of network packet capture datasets
analysts detect anomalies indicating attacks through network
containing instances of network attacks using the prototype,
data, and which aspects of network data they may realistically
and assess whether “patterns” appear, or deviations from the
be required to monitor as a non-primary task (for addressing
“normal” sound of the sonification are heard, at the time of
Use-Case 2 in particular).
the attacks. For Prototype 2, we will assess experimentally
whether the sonification conveys the packet rate at individual Also left to future work is the exploration of the potential
destination IP addresses on the network, in a way suitable for interactions between sonification and visualisation, and of
monitoring as a non-primary task. how multimodal system designs can be leveraged for the
context. In Prototype 1, for example, we envisage that, while
As described in Section IV, a key stage in the sonifica-
sonification is used here for the perception of anomalous events
tion development is experimental identification of appropriate
on the network – the recognition by humans that “something
aesthetics: intuitive mappings from data to sound, for exam-
is wrong” – visualisation could complement the system by
ple. We have applied mappings in both presented prototypes
enabling comprehension of the nature of the events perceived,
based on our own intuition, and relevant aspects of prior
directed by the sonification. Similarly, Prototype 2 could be
work [57]. A direction for future work is conducting design
complemented by a visualisation that conveys exactly which
experiments to determine the optimal mapping aesthetics, and
destination IP address has experienced an increase in packet
incorporating these mappings into the formalised sonification
rate, following the event that the listening analyst’s attention
model to generate final system designs. To assess the effec-
is drawn to some change in the sonification.
tiveness of our sonification model and aesthetic approach, we
need to contrast our approach with pre-existing approaches Further work should be carried out, as highlighted in
to parameter-mapping sonification for network-security moni- Section IV, in user testing of the system, in order to assess
toring [28, 33, 36, 43, 45], by comparing their performance in whether users (in particular, the intended users: security an-
highlighting network attacks. alysts) can hear the patterns generated in the sonification at
the time of the attacks. We intend to research the potential
During the presentation of prototypes, we highlighted our
for sonification to match, or improve on, the performance of
use of a “normal” in describing the values of certain data di-
existing monitoring systems in the SOC environment such as [22] P. Janata and E. Childs, “Marketbuzz: Sonification of real-time financial
security visualisations and IDSs. At this stage, usability aspects data,” in Proceedings of the International Conference on Auditory
such as integration of sonification into the SOC environment Display, 2004.
should also be addressed. [23] T. Hermann, “Sonification for Exploratory Data Analysis,” Ph.D. dis-
sertation, 2002, Bielefeld University.
R EFERENCES [24] G. Kramer, Auditory display: Sonification, audification, and auditory
interfaces. Perseus Publishing, 1993.
[1] L. Axon, S. Creese, M. Goldsmith, and J. R. C. Nurse, “Reflecting on
the use of sonification for network monitoring,” in Proceedings of the [25] A. de Campo, “Toward a data sonification design space map,” in
International Conference on Emerging Security Information, Systems Proceedings of the International Conference on Auditory Display, 2007,
and Technologies (IARIA), 2016, pp. 254–261. pp. 342–347.
[2] P. Garcia-Teodoro, J. Diaz-Verdejo, G. Maciá-Fernández, and [26] S. Barrass and C. Frauenberger, “A communal map of design in auditory
E. Vázquez, “Anomaly-based network intrusion detection: Techniques, display,” in Proceedings of the International Conference on Auditory
systems and challenges,” computers & security, vol. 28, no. 1, 2009, Display, 2009, pp. 1–10.
pp. 18–28. [27] S. Barrass et al., “Auditory information design,” Made available in
[3] S. Axelsson, “The base-rate fallacy and its implications for the difficulty DSpace on 2011-01-04T02: 37: 33Z (GMT), 1997.
of intrusion detection,” in Proceedings of the 6th ACM Conference on [28] M. Gilfix and A. Couch, “Peep (the network auralizer): Monitoring your
Computer and Communications Security. ACM, 1999, pp. 1–7. network with sound.” in Proceedings of the Large Installation System
[4] M. Gopinath, “Auralization of intrusion detection system using Jlisten,” Administration Conference, 2000, pp. 109–117.
Development, vol. 22, 2004, p. 3. [29] R. Giot and Y. Courbe, “Intention–interactive network sonification,”
in Proceedings of the International Conference on Auditory Display.
[5] Klahr, Rebecca and Amili, Sophie and Shah, Jayesh Navin and Button,
Georgia Institute of Technology, 2012, pp. 235–236.
Mark and Wang, Victoria, “Cyber Security Breaches Survey 2016,”
2016. [30] D. Worrall, “Realtime sonification and visualisation of network meta-
data,” in Proceedings of the International Conference on Auditory
[6] D. Denning, “An intrusion-detection model,” IEEE Transactions on
Display, 2015, pp. 337–339.
Software Engineering, no. 2, 1987, pp. 222–232.
[31] M. Kimoto and H. Ohno, “Design and implementation of
[7] A. Lazarevic, L. Ertöz, V. Kumar, A. Ozgur, and J. Srivastava, “A
stetho—network sonification system,” in Proceedings of the
comparative study of anomaly detection schemes in network intrusion
International Computer Music Conference, 2002, pp. 273–279.
detection.” in Proceedings of SIAM International Conference on Data
Mining, 2003, pp. 25–36. [32] D. Malandrino, D. Mea, A. Negro, G. Palmieri, and V. Scarano,
“Nemos: Network monitoring with sound,” in Proceedings of the
[8] V. Chandola, A. Banerjee, and V. Kumar, “Anomaly detection: A
International Conference on Auditory Display, 2003, pp. 251–254.
survey,” ACM Computing Surveys (CSUR), vol. 41, no. 3, 2009, p. 15.
[33] M. Ballora, N. Giacobe, and D. Hall, “Songs of cyberspace: an update
[9] V. Kumar, J. Srivastava, and A. Lazarevic, Managing cyber threats:
on sonifications of network traffic to support situational awareness,” in
issues, approaches, and challenges. Springer Science & Business
SPIE Defense, Security, and Sensing. International Society for Optics
Media, 2006, vol. 5.
and Photonics, 2011, pp. 80 640P–80 640P.
[10] D. E. Denning and P. G. Neumann, “Requirements and model for
[34] R. Schafer, The soundscape: Our sonic environment and the tuning of
ides—a real-time intrusion detection expert system,” Document A005,
the world. Inner Traditions/Bear & Co, 1993.
SRI International, vol. 333, 1985.
[35] O. Kessler et al., “[functional description of the data fusion process],”
[11] N. Ye, S. Emran, Q. Chen, and S. Vilbert, “Multivariate statistical analy-
1991, Office of Naval Technology Naval Air Development Center,
sis of audit trails for host-based intrusion detection,” IEEE Transactions
Warminster PA.
on Computers, vol. 51, no. 7, 2002, pp. 810–820.
[36] P. Vickers, C. Laing, and T. Fairfax, “Sonification of a network’s self-
[12] D. Anderson, T. F. Lunt, H. Javitz, A. Tamaru, and A. Valdes, De- organized criticality,” arXiv preprint arXiv:1407.4705, 2014.
tecting unusual program behavior using the statistical component of
the Next-generation Intrusion Detection Expert System (NIDES). SRI [37] P. Vickers, C. Laing, M. Debashi, and T. Fairfax, “Sonification aesthetics
International, Computer Science Laboratory, 1995. and listening for network situational awareness,” in Proceedings of the
Conference on Sonification of Health and Environmental Data, 2014.
[13] C. Tsai, Y. Hsu, C. Lin, and W. Lin, “Intrusion detection by machine
learning: A review,” Expert Systems with Applications, vol. 36, no. 10, [38] B. deButts, “Network access log visualization & sonification,” Master’s
2009, pp. 11 994–12 000. thesis, Tufts University, Medford, MA, US, 2014.
[14] Y. Zhang, Y. Xiao, M. Chen, J. Zhang, and H. Deng, “A survey [39] M. Garcia-Ruiz, M. Vargas Martin, B. Kapralos, J. Tashiro, and
of security visualization for computer network logs,” Security and R. Acosta-Diaz, “Best practices for applying sonification to support
Communication Networks, vol. 5, no. 4, 2012, pp. 404–421. teaching and learning of network intrusion detection,” in Proceedings
of the World Conference on Educational Multimedia, Hypermedia and
[15] R. E. Etoty and R. F. Erbacher, “A survey of visualization tools assessed Telecommunications, 2010, pp. 752–757.
for anomaly-based intrusion detection analysis,” DTIC Document, Tech.
Rep., 2014. [40] S. El Seoud, M. Garcia-Ruiz, A. Edwards, R. Aquino-Santos, and
M. Martin, “Auditory display as a tool for teaching network intrusion
[16] R. F. Erbacher, K. L. Walker, and D. A. Frincke, “Intrusion and misuse detection,” International Journal of Emerging Technologies in Learning
detection in large-scale systems,” Computer Graphics and Applications, (iJET), vol. 3, no. 2, 2008, pp. 59–62.
IEEE, vol. 22, no. 1, 2002, pp. 38–47.
[41] P. Varner and J. Knight, “Monitoring and visualization of emergent
[17] B. Shneiderman, “Dynamic queries for visual information seeking,” behavior in large scale intrusion tolerant distributed systems,” Technical
IEEE Software, vol. 11, no. 6, 1994, pp. 70–77. report, Pennsylvania State University, 2002.
[18] J. Nicholls, D. Peters, A. Slawinski, T. Spoor, S. Vicol, J. Happa, [42] C. Papadopoulos, C. Kyriakakis, A. Sawchuk, and X. He, “Cyberseer:
M. Goldsmith, and S. Creese, “Netvis: a visualization tool enabling 3d audio-visual immersion for network security and management,” in
multiple perspectives of network traffic data,” 2013. Proceedings of the ACM workshop on Visualization and data mining
[19] S. Rinderle-Ma and T. Hildebrandt, “Server sounds and network noises,” for computer security. ACM, 2004, pp. 90–98.
in Cognitive Infocommunications (CogInfoCom), 2015 6th IEEE Inter- [43] L. Qi, M. Martin, B. Kapralos, M. Green, and M. Garcı́a-Ruiz, “To-
national Conference on. IEEE, 2015, pp. 45–50. ward sound-assisted intrusion detection systems,” in On the Move to
[20] Z. Halim, R. Baig, and S. Bashir, “Sonification: a novel approach Meaningful Internet Systems 2007: CoopIS, DOA, ODBASE, GADA,
towards data mining,” in Proceedings of the International Conference and IS. Springer, 2007, pp. 1634–1645.
on Emerging Technologies, 2006. IEEE, 2006, pp. 548–553. [44] A. Brown, M. Martin, B. Kapralos, M. Green, and M. Garcia-Ruiz,
[21] T. Hinterberger and G. Baier, “Parametric orchestral sonification of EEG “Poster: Towards music-assisted intrusion detection,” 2009, poster pre-
in real time,” IEEE MultiMedia, no. 2, 2005, pp. 70–79. sented at IEEE Workshop on Statistical Signal Processing.
[45] V. F. Mancuso et al., “Augmenting cyber defender performance and [56] T. Hermann, A. Hunt, and J. Neuhoff, The sonification handbook.
workload through sonified displays,” Procedia Manufacturing, vol. 3, Logos Verlag Berlin, GE, 2011.
2015, pp. 5214–5221. [57] G. Dubus and R. Bresin, “A systematic review of mapping strategies
[46] M. Garcı́a-Ruiz, M. Martin, and M. Green, “Towards a multimodal for the sonification of physical quantities,” PloS one, vol. 8, no. 12,
human-computer interface to analyze intrusion detection in computer 2013, p. e82491.
networks,” in Proceedings of the First Human-Computer Interaction [58] E. Yeung, “Pattern recognition by audio representation of multivariate
Workshop (MexIHC), Puebla, Mexico, 2006. analytical data,” Analytical Chemistry, vol. 52, no. 7, 1980, pp. 1120–
[47] “Fraunhofer IIS Netson,” 2016, URL: http://www.iis.fraunhofer.de/en/ 1123.
muv/2015/netson.html [accessed: 24/02/2017]. [59] M. Ballora, R. Cole, H. Kruesi, H. Greene, G. Monahan, and D. Hall,
[48] “Specimen Box, The Office for Creative Research,” 2014, URL: “Use of sonification in the detection of anomalous events,” in SPIE
http://ocr.nyc/user-focused-tools/2014/06/01/specimen-box/ [accessed: Defense, Security, and Sensing. International Society for Optics and
24/02/2017]. Photonics, 2012, pp. 84 070S–84 070S.
[49] L. Buchanan, A. D’Amico, and D. Kirkpatrick, “Mixed method ap- [60] J. Rubin and D. Chisnell, Handbook of usability testing: how to plan,
proach to identify analytic questions to be visualized for military cyber design and conduct effective tests. John Wiley & Sons, 2008.
incident handlers,” in Visualization for Cyber Security (VizSec), 2016
[61] J. R. C. Nurse, S. Creese, M. Goldsmith, and K. Lamberts, “Guidelines
IEEE Symposium on. IEEE, 2016, pp. 1–8.
for usable cybersecurity: Past and present,” in Proceedings of the Third
[50] T.-F. Yen, A. Oprea, K. Onarlioglu, T. Leetham, W. Robertson, A. Juels, International Workshop on Cyberspace Safety and Security (CSS).
and E. Kirda, “Beehive: Large-scale log analysis for detecting suspi- IEEE, 2011, pp. 21–26.
cious activity in enterprise networks,” in Proceedings of the 29th Annual
[62] A. de Campo, “A data sonification design space map,” in Proc. of
Computer Security Applications Conference. ACM, 2013, pp. 199–
the 2nd International Workshop on Interactive Sonification, York, UK,
208.
2007.
[51] D. Zhao, I. Traore, B. Sayed, W. Lu, S. Saad, A. Ghorbani, and
D. Garant, “Botnet detection based on traffic behavior analysis and [63] F. Briolle, “Detection and classification of the audiophonic sonar signal:
flow intervals,” Computers & Security, vol. 39, 2013, pp. 2–16. perspectives of space simulation under headphones,” Undersea Defense
Technology, 1991.
[52] D. Acarali, M. Rajarajan, N. Komninos, and I. Herwono, “Survey
of approaches and features for the identification of http-based botnet [64] R. Mill and G. Brown, “Auditory-based time-frequency representations
traffic,” Journal of Network and Computer Applications, vol. 76, 2016, and feature extraction techniques for sonar processing,” Speech and
pp. 1–15. Hearing Research Group, Sheffield, England, 2005.
[53] A. D’Amico, K. Whitley, D. Tesone, B. O’Brien, and E. Roth, “Achiev- [65] M. Ballora and D. Hall, “Do you see what I hear: experiments in multi-
ing cyber defense situational awareness: A cognitive task analysis of channel sound and 3D visualization for network monitoring?” in SPIE
information assurance analysts,” in Proceedings of the human factors Defense, Security, and Sensing. International Society for Optics and
and ergonomics society annual meeting, vol. 49, no. 3. SAGE Photonics, 2010, pp. 77 090J–77 090J.
Publications, 2005, pp. 229–233. [66] A. D’Amico and K. Whitley, “The real work of computer network
[54] G. Parseihian, C. Gondre, M. Aramaki, S. Ystad, and R. K. Martinet, defense analysts,” in VizSEC 2007. Springer, 2008, pp. 19–37.
“Comparison and evaluation of sonification strategies for guidance [67] T. Hildebrandt, T. Hermann, and S. Rinderle-Ma, “Continuous sonifi-
tasks,” IEEE Transactions on Multimedia, vol. 18, no. 4, 2016, pp. cation enhances adequacy of interactions in peripheral process moni-
674–686. toring,” International Journal of Human-Computer Studies, 2016.
[55] S. C. Peres, D. Verona, T. Nisar, and P. Ritchey, “Towards a systematic [68] “The CAIDA UCSD DDoS Attack 2007 dataset,” URL:
approach to real-time sonification design for surface electromyography,” https://www.caida.org/data/passive/ddos-20070804 dataset.xml
Displays, 2016. [accessed 24/02/2017].