Behavioral-Based Feature Abstraction from Network Traffic 1
1
1,2
1,2
Gaseb Alotibi , Fudong Li , Nathan Clarke and Steven Furnell 1 Centre for Security, Communications and Network Research (CSCAN) Plymouth University, Plymouth, United Kingdom 2 Security Research Institute, Edith Cowan University, Western Australia
[email protected] Abstract: Information security breaches cost organizations collectively billions in lost intellectual property and business. To mitigate this threat, a whole host of countermeasures have been devised to detect, monitor and respond to network-based attacks and compromise. These include: incident management teams operating 24/7, network forensic tools, Security Incident and Event Management (SIEM) systems, insider misuse detection, intrusion detection and intrusion prevention systems. A fundamental limitation of all these approaches however is the reliance upon analyzing network traffic based upon the computer node, which itself is derived from a dynamically allocated IP address, rather than being able to identify network traffic based upon the user. Identifying the user rather than IP provides a more complete and accurate set of data to be utilized within existing countermeasures. For example, in an organization, a user might have access to a desktop, laptop, tablet and mobile phone that all utilize and access the corporate network and who’s IPs are different and vary against time. Currently understanding and identifying that user in such an environment is extremely challenging and time consuming. Whilst research has attempted to achieve this level of abstraction to the user, results are poor due to the volume and variability of data at the network-level. This paper describes a research study into the identification and extraction of high-level behavioural features from low-level network traffic. Having identified application-level services and derived sets of typical use cases, this research presents a set of experiments to demonstrate how user behaviours within internet-enabled applications can be determined through analysis of low-level network traffic metadata. The enhanced features that are derived not only inform us of which services a person is using but also how they use it. For example, from our social networking experiment it has been shown that it is possible to identify whether a person is reading, posting an image or using instant messenger. This feature-rich userfocused approach to metadata analysis of network traffic will provide the underlying information required for profiling and modelling user activity. Keywords: Behavioural Profiling, Authentication, Identification, Network Traffic 1 Introduction Organisations rely heavily upon various types of information regarding their customers, employees, suppliers and products to maintain smooth daily operations. However, information systems and its data are constantly under vast quantities of threats, such as malware infections, Denial of Service (DoS) attacks, incidents caused by staff – both accidental and deliberate, and attacks by unauthorised outsiders. As a result, the cost both financial and reputational can be huge if information security is not managed properly. Indeed, according to the 2014 Information Security Breaches Survey conducted by PricewaterhouseCoopers (PwC), 70% of the UK businesses experienced information security breaches in 2013. Furthermore, the cost of individual breaches has almost doubled since previous year despite the number of attacks reducing (PwC, 2014). Hence, it is mission critical to detect, prevent and respond to security breaches within corporate environment – key to this is the ability to identify individuals who are accountable for the attacks. Attackers always leave their footprints on the communication network no matter how careful they are. Traditionally, analysing already captured network traces can reveal details of the incident but this is a painstaking, laborious and costly exercise. Within a corporate environment identifying relevant traffic amongst the organisation’s traffic becomes an increasingly challenging task for many reasons, such as, the introduction of secured communication (SSL/TLS), the use of Dynamic Host Control Protocol (DHCP) on corporate networks, the complexity of attacks, the involvement of internal users (i.e. insider misuse) (PwC, 2013), and the sheer amount of data exhibited on the network (Cisco, 2014). As a result, sophisticated tools are required for supporting the investigation of network security incidents. Indeed, a whole host of countermeasures have already been devised to detect, monitor and respond to network-based attacks and compromise. These include: incident management teams operating 24/7, network forensic tools, Security Incident and Event Management (SIEM) systems, insider misuse detection, intrusion detection and intrusion prevention systems. It is well known that these
approaches are reliant upon analysing network traffic based upon the computer node, which itself is derived from an IP address. However, the IP is not a reliable source due to the use of DHCP on corporate networks, shared computer environments (e.g. a library), and the possibility of IP spoofing attack (Hastings and McLean, 1996). For example, in an organization, a user might have access to a desktop, laptop, tablet and mobile phone that all utilize and access the corporate network and who’s IPs are different and vary against time. Therefore, outputs of existing tools may not be reliable for identifying actual attacker(s) but merely the computer node(s) which the attacker(s) utilised in an attack. It is envisaged that identifying the user rather than IP could provide a more complete and accurate set of data to be utilized within existing countermeasures. However, currently understanding and identifying that user within a corporate environment is extremely challenging and time consuming. Whilst research has attempted to achieve this level of abstraction to the user, results are poor due to the volume and variability of data at the network-level. To this end, this paper describes a research study into the identification and extraction of high-level behavioural features from low-level network traffic. The remainder of the paper is structured in the following manner: Section 2 reviews existing network security incident and event management tools. Section’s 3 and 4 present an analysis of user’s application level activities and an experimental study into identifying user’s activities and behaviours from network traffic. A discussion of the findings and the how such an approach could operate is presented in section 5, with the conclusions and future work presented in Section 6. 2 Network Security Incident Analysis Tools With the aim of identifying attacks, a wide range of tools have been developed in the area of network security incident analysis. Based upon how these tools are utilised, they can be categorised as either reactive or proactive. When incidents are reported, security managers utilise reactive tools, such as network forensic tools, to identify potential evidence from existing network traffic logs. In comparison, proactive tools are employed to constantly analyse network traffic looking for incidents and security analysts are notified when possible attacks are identified. 2.1 Network Forensic Tools When a security incident occurs, a forensic investigator can utilise network forensic tools to recover evidence by analysing traffic data that are logged through appliances (e.g. an intrusion detection system and network traffic dump) on the corporate network (Pilli et al, 2010). Indeed, details of the security incident can be studied by replaying the captured attack traffic within network forensic tools (Corey et al, 2002). A better understanding of the packet content can be obtained by organising network packets as individual connections – effectively abstracting the data to a higher level to aid an investigators understanding (Pilli et al, 2010). Obviously, the more insights about the attack that the network forensic tool can offer the easier it is to locate evidence and build a case. Therefore, desirable network forensic tools should have the following functionalities, including read-only data collection and examination, data reduction and recovery, reliable protocol identification and reconstruction, keyword search capabilities and documentation (Casey, 2004). Based upon the aforementioned requirements, more than a dozens of network forensic tools have been developed either commercially or under an open-source license. These tools include InfiniStream (Netscout, 2012), NetResident (TamoSoft, 2014), NetworkMiner (NETRESEC, 2013), OmniPeek (WildPackets, 2012), PyFlag (Cohen, 2008), SilentRunner (AccessData, 2014), Solera DeepSee 5150 (Solera Networks, 2009) and Xplico Open Source Network Forensic Analysis Tool (Xplico, 2007). By utilising these tools, security analysts can be assisted at various levels in finding attack evidences. Nonetheless, it is well known that commercial products are expensive while opensource applications have significant limited functionality. But all of these tools also face two major challenges: dealing with enormous volumes of network data and to interpret the raw data into meaningful information (Merkle, 2008). Whilst abstracting the data to connection level is highly useful over a packet-based inspection, it fails to abstract any further (i.e. from the computer node to the user). 2.2 Security Incident and Event Management (SIEM) systems SIEM systems are formed by the combination of Security Information Management systems (SIMs) and Security Event Management systems (SEMs). Therefore, by correlating and analysing data from
disparate network sources (e.g. firewalls or IDS systems) in real-time and historical analysis of security events together, SIEM systems are deemed to be capable of providing threat detection, security incident response and incident investigation on large scale corporate networks (Gartner, 2012). As SIEM systems work in a proactive manner, they constantly analyse and correlate data from various sources (e.g. firewalls) to identify attacks. If an attack is detected, SIEM systems can alert security analyst and even initiate counter measures (e.g. block traffic from malicious IP sources). SIEM systems were first introduced in the early 2000s. Since then many SIEM products have been commercialised by well-established vendors, including IBM/Q1, Novell, HP/ArcSight, Quest Software, Symantec, Splunk, NetIQ and Tripwire. By using these tools, a security analyst can obtain a centralised perspective on corporate networks and identify malicious activities. Nevertheless, many SIEM systems failed to execute real-time correlation due to the huge amount of data they need to process and thereby are unable to produce a true image of risk (McAfee, 2013). They are also incapable of detecting an attack that is well hidden under legitimate user credentials or under normal network traffic (Splunk, 2012). As demonstrated above, existing incident analysis tools play a significant role in the network security domain. Nonetheless, a fundamental limitation of these approaches is the reliance upon analysing network traffic based upon the IP address that is an unreliable source for linking to a user/attacker who has compromised a user’s credentials. Therefore, these tools could only identify the computer node that is utilised in an attack but not the actual attacker. It is argued that identifying the user rather than IP could provide a more complete and accurate set of data to be utilized within existing network security incident analysis tools. In this way, the attacker and the computer that he used could both be identified when a security incident happens. Also, existing behavioural based research shows that users can be identified by their activities (e.g. the duration of a call and the applications they use) with a good level of accuracy in the mobile communication environment (Gosset, 1998; Samfat and Molva, 1997; Boukerche and Nitare, 2002; Li et al, 2014). 3 Analysis of Application Level User Activities via Network Metadata A user can carry out various activities in different internet-enabled applications (as illustrated in Table 1) and they will all result in network traffic signals being generated between the client and sever. By utilising a combination of metadata parameters such as time, protocol and payload size, a picture of how user application activities are carried out can be obtained. For example, a user logs into an instant message application at 8:05 am, then chats with a friend at 8:30 am, followed by sending a file to the friend 5 minutes later. However, due to the vast volume of internet-enabled applications available and the increasing implementation of Transport Layer Security (TLS/SSL), it can be an extremely challenging and time consuming task to collect user’s activities within each application. Based upon the 7-layer Open Systems Interconnection (OSI) reference model, user activities at the application layer are encapsulated into various signals at the data transport layers. If these user activities could be learnt via their corresponding network signals, it would be possible to identify not only which application a person used but also how it was used. Table 1: Examples of selected Internet-enabled applications and user actions Applications Cloud Emails Information gathering Instant messenger Online banking Social networking
User actions Edit, share, upload, download, remove Compose, attachment, read, delete Information browsing, watch video clips, listen to online clips Chat, voice call, video conference, file transfer View bank statement, money transfer Posting, viewing wall, uploading photos/videos, chatting, comment
At the data transport layers of the OSI model, a rich amount of metadata are available for describing various characteristics of a network signal; these include information stored in a 14-field IP header, a 10-field TCP header and a 4-field UDP header. Some of the metadata can be utilised to associate user’s activities directly while others may require additional analysis. For example, by utilising the combination of the TCP SYN and FIN flags, the start and end of a communication flow can be identified; hence the beginning and ending of a user’s activity. In comparison, the length of a datagram itself does not provide definitive information; but it could be utilised to analyse user actions.
For instance, when users chat via an instant messenger application, a longer datagram could indicate a larger amount of characters being sent in the conversation. A summary of several user application level activities and their (potential) network metadata indicators is demonstrated in Table 2. Table 2: A summary of user application level activities and their network metadata indicators Activities identifiers Starting time Finishing time Name of the application Type of services Actions
Network metadata indicators TCP SYN flag TCP FIN flag Destination IP Port number Payload length of a datagram
In order to obtain a better view of how user application activities could be represented by their network metadata, three popular internet-based services were chosen for further analysis, namely web surfing, instant messenger and social networking. When user surfs the Internet, his computer (i.e. the client) initially communicates with a DNS server for the IP address of a webserver (indicated by UDP port 53 traffic). Then the client establishes a three way TCP handshake with the webserver (indicated by the SYN flag), followed by information being sent from the webserver to the client (indicated by the TCP PUSH flag) with the client merely confirms the receipt of data (shown by the TCP ACK flag). It is envisaged that the amount of traffic being sent to the client depends upon the complexity of the website and user’s actions. For instant, reading text, viewing images and watching videos would represent a small, medium and large amount of traffic on the network respectively. The communication will be terminated (designated by the FIN flag) when the page rendering process is completed. In comparison with normal web surfing, network signals could be more complicated when user utilises the instant messenger and social networking services as both user authentication and secured communication are needed. After the initial TCP handshake, the client and the server (either for the instant messenger or social networking services) perform an SSL handshake to establish a secured communication (indicated by TCP port 443 traffic); also the secured channel remains active until the user logouts from the service due the overhead of the SSL setup process. Therefore, it is difficult to analyse user activities at the traffic flow level. Nonetheless, it is assumed that the traffic length (represented by the total length field of the IP header) could be utilised as an indicator for identifying user actions if similar patterns occur when certain user activity is carried out. For instance, large size of packets (i.e. Maximum Transmission Unit (MTU) alike) sent from the social networking server to the client in a continuous manner for 2 minutes could be a sign of online streaming service being utilised. Another example, various lengths of packets being sent from the client to the instant messenger server in a short-burst fashion could indicate that a user is chatting. Based upon the aforementioned analysis, it is argued that user activities at the application level could be identified by their corresponding network traffic signals. However, the effectiveness of network metadata is still unknown. To this end, a number of experimental studies have been conducted and details of these studies are described in the next section. 4 Behavioural-Based Feature Abstraction from Network Traffic With the aim of establishing the extent to which network metadata could be utilised for identifying user application level activities, experiments have been conducted on the three analysed internet-enabled services. For each service, various user activities were performed and all corresponding network signals were collected via Wireshark at the same time, permitting further analysis upon them. Also, this process was carried out for multiple times by three individual researchers to ensure the validity of this experimental study and to account for any variation that might exist within the signals base upon account details and network infrastructure. 4.1 Web surfing To analyse what user interactions are possible with general web surfing, it was decided to focus upon the BBC website as its representative of an information portal (and a particularly popular one). It is also an example of a non-encrypted site (in comparison to the other two services which are being analysed). As the service is unencrypted it is possible to analyse the traffic at the TCP flow level
rather than the network packet level. Being a dynamic (rather than simple static website) each request made to the site generated a number of TCP connections but it is possible to identify specific user interactions. Figure 1 illustrates a user loading a page.
Figure 1: Surfing BBC News It is possible to derive a number of user interaction signals from web surfing BBC news that provides more information than simply that a user accessed the site (as illustrated in Table 3). It is possible to understand how many pages they accessed – whether this was merely a home page or a new story – how long they spent on each page and on the site overall. It is also possible to identify whether they watched any video content. Table 3: User Interactions derived from BBC News Actions View page View video
Protocol TCP TCP
Destination Port Random port Random port
Total length (bytes) Various MTU (Almost)
Number of packets Various Many
Directions Server>Client Server>Client
4.2 Instant messenger Skype was chosen for the voice and IM chatting application as it is amongst the most popular. Skype based traffic is encrypted but an analysis of the network traces – at packet rather than flow level does reveal a number of user interactions. A number of user activities were tested against their corresponding network metadata signals, including chatting, video conferencing, clicking contacts and file sharing. The analysis shows that chatting is handled directly from the client to the Skype server (IP 157.56.192.26 via TCP port 443) – as illustrated in Figure 2. The baseline for sending characters was 794 bytes on the network. For example, a 19-character sentence the corresponding network signal was one 813-byte frame (indicated by marker 1). Upon repeating this experiment, it was noticed that the baseline did vary between users and thus a threshold will need to be identified on a per-user basis in order to identify this interaction.
Figure 2: IM via Skype Both the video-conference and file sharing were set up directly between two clients via UDP ports (i.e. not via the Skype server). For the video conference, one client was sending video frames with larger size packets (e.g. 1166-1360 bytes) while the other was sending audio in smaller packets (e.g. 129149 bytes) as only the former client had the camera turned on while the latter did not (as illustrated in Figure 3).
Figure 3: Video conferencing via Skype
Regarding file sharing, an analysis of the subsequent network traces identify (as illustrated in Figure 4) that packets sizes reflexed the maximum packet size that the network can handle (the MTU) (i.e. 1412 bytes in this example) and these were sent by the sender while receiving little traffic from the receiver (merely replying with acknowledgments) (i.e. 69 bytes Ethernet frames). Furthermore, both traffic flows for video-conferencing and file sharing were sent in a continuous manner - thus would manifest themselves as a series of packets lasting more than a few seconds.
Figure 4: File Sharing via Skype Based up these observations it is possible to derived signatures for the network traffic that would identify the user interactions within Skype. As illustrated in Table 3, even though the service is completely encrypted it is still possible to identify a range of interactions – providing information about how many times the user uses Skype for instant messaging, video/audio calling and file uploads. Table 4: User Interactions Derived from Skype Actions
Protocol
Destination Port 443 Random port
Frame length ( bytes) 794+ MTU (Almost)
Number of packets 1 Many
Chat File sharing
TCP UDP
File sharing Video conference Audio call Idle Click on contacts
Directions
UDP
Random port
69
Many
UDP
Random port
1165-1365
Many
Client>Server Sending client> receiving client Receiving client> Sending client Both clients
UDP TCP TCP
Random port 443 443
129-147 572 731
Many 1 1
Both clients Client>Server Client>Server
4.3 Social Networking Facebook was chosen for the social network analysis. A number of user activities were performed and compared against their corresponding network signals. The network signals that are created when accessing the site are large in number and also encrypted which results in a more complex analysis. With more dynamic and complex web services, it is clear a significant degree of additional traffic is generated – which serves to complicate the analysis. For example, Facebook has an idle signal that is sent periodically – this is functionality that helps to ensure the webpage is up to date. Without care, this signal could be misrepresented as a user interaction. When the typing activity started in the chatting dialog box, a network signal with a total of 1502 bytes (i.e. 1434+68) was sent from client to the Facebook server; the same pattern also occurred directly after a message being sent. Moreover, the baseline for chatting in Facebook is a total of 2,625 bytes (i.e. 1434+1191). For example, when a 4-character word is sent to the server, a total of 2,629 bytes appeared on the network. These patterns are illustrated in the analysis presented in Figure 5, indicated by red and blue boxes respectively.
Figure 5: Chatting on Facebook An examination of the photo uploading activity (as illustrated in Figure 6), shows a stream of almost full size Ethernet frames (i.e. the MTU which in this example 1434 bytes) were sent from the client to the Facebook server while the Facebook server simply acknowledged the receiving of the data (indicated by TCP ACK flag).
Figure 6: Photo uploading on Facebook From this signals analysis, the Table 5 presents a series of user interactions and the subsequent information required to detect the interaction from network traffic. Table 5: User Interactions Derived from Facebook Actions
Protocol
Destination Port
Chat Typing File uploading Idle Page load / viewing wall
TCP TCP TCP TCP TCP
443 443 443 443 Random port
total length (bytes) 2,625+ 1502 MTU (Almost) 149 Various
Number of packets 2 2 Many 2 Various
Directions Client>Server Client>Server Client>Server Client>Server Server>Client
5 Discussions Based upon the experimental results, it demonstrates that user behaviours or interactions within internet-enabled applications can be determined through analysis of their corresponding network traffic metadata. The enhanced features that are derived from network metadata not only inform us of
which services a person is using but also how they use it. For example, users’ chatting activity was identified in both the instant messenger and social networking applications. This feature-rich userfocused approach to metadata analysis of network traffic provides far more discriminative information that current approaches and will provide more opportunity to classify and identify users. Furthermore, with the increasing popular of Google Chrome book and other internet-enabled devices, it is anticipated users will be utilising more internet-based services and applications rather than local installed applications – providing further user interaction data (Gartner, 2014). Nevertheless, a number of challenges were also observed during the study, including the complexity of dynamic websites, user dependent network signals and machine generated network traffic. When a BBC page was viewed, connections were set up not only for the BBC servers but also to other links, such as servers of comScore which is employed by the BBC to monitor their visitors (BBC, 2014); this could create a false impression that a user also visited websites of comScore which they did not. Interestingly, user moves from one page to another within the BBC could be identified by studying the traffic of comScore alone as it manages the cookies for the BBC. During the Skype experiment, the baseline for chatting did vary between users and thus a user dependent threshold is required for identifying this interaction. Nonetheless, it is envisaged that users could be discriminated by their chatting activity alone if the difference between their baselines was significant. Regarding machine generated network traffic, extra care should be given to them as they can be easily interpreted as a user interaction; hence, increasing noises into the feature identification process. Due to this complexity within the network traffic, applications currently need to be analysed on an individual basis so that valid interaction signatures can be extracted. Whilst this is feasible for a small number of popular applications, a more dynamic approach would be required longer-term so that the system is able to learn new signatures and adapt to changes in application services. A feature identification and extraction system is required that can intelligently decipher the traffic signals and resolve them back to the user interactions. 6 Conclusion and future research The paper has presented a study into the ability to derived user interactions at the application level from low-level network metadata. A series of experiments were performed across three popular services and in each case a set of interactions were successfully derived. As this approach only deals with meta-data, there will always be a limitation on what can be extracted. For example, whilst it is possible to detect an instant message chat, it is not possible to identify who the user is chatting with nor the number of simultaneous chats they are participating in. Future research will focus upon applying these user interaction signatures to real network traffic to determine how successfully individuals can be fingerprinted from their network traces. This work will be based upon applying biometric-based design methodologies to the problem of feature extraction and classification. Further research also needs to be undertaken on the development of an automated feature identification process to identify the initial user interaction signatures. References AccessData (2014) “SilentRunner Sentinel”, [Online], http://accessdata.com/solutions/cybersecurity/silentrunner-sentinel BBC (2014) “Cookie information: how does the BBC use cookies”, [online], http://www.bbc.co.uk/privacy/cookies/bbc/performance Boukerche, A. and Nitare, M.S.M.A. (2002) “Behavior-Based Intrusion Detection in Mobile Phone Systems”, Journal of Parallel and Distributed Computing, vol. 62, Issue 9, pp 1476-1490, Academic Press, Inc. Orlando, FL, USA Casey, E. (2004) “Tool review: Network traffic as a source of evidence: tool strengths, weaknesses and future needs”, Digital Investigation: The International Journal of Digital Forensics & Incident Response, Vol. 1, Issue 1, pp 28-43 Cisco (2014) “Cisco Visual Networking Index: Forecast and Methodology, 2013-2018”, [online], http://www.cisco.com/c/en/us/solutions/collateral/service-provider/ip-ngn-ip-next-generationnetwork/white_paper_c11-481360.html Cohen, M. I. (2008) “PyFlag – An advanced network forensic framework”, Digital Investigation: The International Journal of Digital Forensics & Incident Response, Vol. 5, pp112-120 Corey, V., Peterman, C., Shearin, S., Greenberg, M.S. and Van Bokkelen, J. (2002) "Network forensics analysis," Internet Computing, IEEE, vol. 6, no. 6, pp.60-66
Gartner (2012) “Security Information and Event Management 2012”, [Online], http://www.gartner.com/it-glossary/security-information-and-event-management-siem Gartner (2014) "Gartner Says Chromebook Sales Will Reach 5.2 Million Units in 2014", [Online], https://www.gartner.com/newsroom/id/2819917 Gosset, P. (1998) “ASPeCT: Fraud Detection Concepts: Final Report”. Doc Ref. AC095/VOD/W22/DS/P/18/1 Hastings, N.E.; McLean, P.A. (1996) "TCP/IP spoofing fundamentals," Computers and Communications, Conference Proceedings of the 1996 IEEE Fifteenth Annual International Phoenix Conference on, vol., no., pp.218,224, 27-29 Mar 1996 Li F., Clarke N.L., Papadaki M. and Dowland P.S. (2014) "Active authentication for mobile devices utilising behaviour profiling", International Journal of Information Security, Vol. 13, Issue 3, pp 229-244, ISSN:1615-5262 McAfee (2013) “SIEM: Keeping Pace with Big Security Data”, [Online], http://www.mcafee.com/uk/resources/reports/rp-siem-keeping-pace-big-security-data.pdf Merkle, L.D. (2008) “Automated Network Forensics”, Proceedings of the conference on genetic and evolutionary computation (GECCO 2008), pp 1929-1932 NETRESEC (2013) “NetworkMiner”, [Online], http://www.netresec.com/?page=NetworkMiner Netscout (2012) “nGenius InfiniStream Appliance”, [Online], http://www.netscout.com/library/Data%20sheets/NetScout_DS_nGenius_InfiniStream_Appliance_SP. pdf Pilli, E.S. Joshi, R.C. and Niyogi, R. (2010) ‘Network Forensic Frameworks: Survey and research challenges’, Digital Investigation: The International Journal of Digital Forensics & Incident Response, Vol. 7, Issue 1-2, pp 14-27 PwC (2013) “2013 Information Security Breaches Survey”, [online], https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/200455/bis-13-p1842013-information-security-breaches-survey-technical-report.pdf PwC (2014) “2014 Information security breaches survey”, [online], http://www.pwc.co.uk/auditassurance/publications/2014-information-security-breaches-survey.jhtm Samfat, D. and Molva, R. (1997) “IDAMN: an Intrusion Detection Architecture for Mobile Networks”, IEEE Journal on Selected Areas in Communications, vol. 15, pp1373--1380 Solera Networks (2009) “DeepSee 5150 – Comprehensive Network Forensics Appliance”, [Online], http://www.soleranetworks.co.jp/resources/datasheet5150_web.pdf Splunk (2012) “Splunk, Big Data and the Future of Security – whitepaper 2012”, [Online], http://pspinfo.us/wp-content/uploads/2013/07/Splunk_Big_Data_and_the_Future_of_Security.pdf TamoSoft (2014) “NetResident”, [online], http://www.tamos.com/products/netresident/ WildPackets (2012) “OmniPeek Network Analyzer”, [Online], http://www.wildpackets.com/elements/omnipeek/OmniPeek_Network_Analyzer_datasheet.pdf Xplico (2007) “Xplico Features”, [Online], http://www.xplico.org/about
