DISSERTATION_40096050

40096050 SOC10101
Pamela Dempster - BEng (Hons) Computer Systems and Networks
Brute Force Attack
Detection and Mitigation
using a SIEM
Architecture
Pamela Dempster
Submitted in partial fulfilment of
the requirements of Edinburgh Napier University
for the Degree of Bachelor of Engineering with Honours in
Computer Systems and Networks
School of Computing
April 2015

40096050 SOC10101
Authorship Declaration
I, Pamela Dempster, confirm that this dissertation and the work presented in it are my own
achievement.
Where I have consulted the published work of others this is always clearly attributed;
Where I have quoted from the work of others the source is always given. With the exception
of such quotations this dissertation is entirely my own work;
I have acknowledged all main sources of help;
If my research follows on from previous work or is part of a larger collaborative research
project, I have made clear exactly what was done by others and what I have contributed
myself;
I have read and understand the penalties associated with Academic Misconduct.
I also confirm that I have obtained informed consent from all people I have involved in the
work in this dissertation following the School's ethical guidelines
Signed:
Date:
Matriculation no: 40096050

40096050 SOC10101
Data Protection Declaration
Under the 1998 Data Protection Act, The University cannot disclose your grade to an
unauthorised person. However, other students benefit from studying dissertations that have
their grades attached.
Please sign your name below one of the options below to state your preference.
The University may make this dissertation, with indicative grade, available to others.
The University may make this dissertation available to others, but the grade may not be
disclosed.
The University may not make this dissertation available to others.

40096050 SOC10101
Acknowledgements
Firstly, I would like to thank my Supervisor, Professor Bill Buchanan for providing me with
the opportunity to complete this project and for the continuous guidance and support he
offered throughout the year.
I would also like to thank Richard Macfarlane for being my Second Marker.
Finally, I would like to thank my family and friends for their never ending support and
encouragement.

40096050 SOC10101
Contents
AUTHORSHIP DECLARATION
DATA PROTECTION DECLARATION
ACKNOWLEDGEMENTS
ABSTRACT
1 INTRODUCTION ................................................................................1
1.1 Introduction.................................................................................................................. 1
1.2 Background .................................................................................................................. 1
1.3 Aims and Objectives.....................................................................................................2
1.4 Dissertation Structure ..................................................................................................3
1.5 Ethics ............................................................................................................................ 3
2 LITERATURE REVIEW ....................................................................4
2.1 Introduction.................................................................................................................. 4
2.2 Cyber Adversaries – A History.................................................................................... 4
2.3 Attack Taxonomy......................................................................................................... 7
2.3.1 Classification of Attacks......................................................................................... 7
2.3.2 Attack Patterns ..................................................................................................... 10
2.4 Defence in Depth ........................................................................................................ 14
2.5 Defence Mechanisms .................................................................................................. 15
2.5.1 Intrusion Detection Systems ................................................................................. 15
2.5.2 Big Data Analytics ............................................................................................... 16
2.5.3 SIEM.................................................................................................................... 19
2.6 Conclusion .................................................................................................................. 21
3 DESIGN ..............................................................................................22
3.1 Introduction................................................................................................................ 22
3.2 Design Methodology................................................................................................... 22
3.3 Threats – An Overview .............................................................................................. 24
3.3.1 Scanning/Information Gathering Attack – Portscan............................................... 24
3.3.2 Brute Force Dictionary Attacks............................................................................. 24
3.4 Requirements Analysis............................................................................................... 24
3.5 Attack Tools................................................................................................................ 26
3.5.1 Nmap.................................................................................................................... 26
3.5.2 Hydra ................................................................................................................... 27

40096050 SOC10101
3.6 Detection Methods – An Overview ............................................................................ 27
3.6.1 Intrusion Detection Systems (IDS)........................................................................ 27
3.6.2 SIEM.................................................................................................................... 27
3.7 Evaluation Metrics ..................................................................................................... 28
3.7.1 Brute Force Dictionary Attack – Rapid Speed....................................................... 28
3.7.2 Brute Force Dictionary Attack – ‘Low and Slow’ ................................................. 29
3.8 Conclusions................................................................................................................. 29
4 IMPLEMENTATION........................................................................30
4.1 Introduction................................................................................................................ 30
4.2 Configuration ............................................................................................................. 30
4.3 Attack Traffic............................................................................................................. 32
4.3.1 Scanning/Information Gathering Attack................................................................ 32
4.3.2 FTP Brute Force Dictionary Attack ...................................................................... 32
4.3.3 Telnet Brute Force Dictionary Attack ................................................................... 33
4.3.4 HTTP Brute Force Dictionary Attack ................................................................... 33
4.3.5 Brute Force Dictionary Attacks – ‘Low and Slow’................................................ 34
4.4 Detection Methods - IDS............................................................................................ 34
4.4.1 Snort Rules – Scanning/Information Gathering Attack.......................................... 34
4.4.2 Snort Rules - FTP Brute Force Dictionary Attack ................................................. 35
4.4.3 Snort Rules - Telnet Brute Force Dictionary Attack.............................................. 35
4.4.4 Snort Rules – HTTP Brute Force Dictionary Attack.............................................. 36
4.5 Detection Methods - SIEM......................................................................................... 36
4.5.1 Splunk Logs ......................................................................................................... 36
4.5.2 Splunk Rules ........................................................................................................ 36
4.6 Conclusion .................................................................................................................. 39
5 EVALUATION...................................................................................40
5.1 Introduction................................................................................................................ 40
5.2 Experiments................................................................................................................ 40
5.2.1 Information Gathering/Probing Attack.................................................................. 40
5.2.2 FTP Brute Force Dictionary Attack ...................................................................... 41
5.2.3 Telnet Brute Force Dictionary Attack ................................................................... 43
5.2.4 HTTP Brute Force Dictionary Attack ................................................................... 44
5.2.5 Brute Force Dictionary Attacks – ‘Low and Slow’................................................ 46
5.3 Results......................................................................................................................... 46

40096050 SOC10101
5.3.1 Scanning/Information Gathering Attack................................................................ 46
5.3.2 Brute Force Dictionary Attacks............................................................................. 47
5.4 Analysis....................................................................................................................... 49
5.5 Conclusions................................................................................................................. 50
6 CONCLUSIONS.................................................................................51
6.1 Introduction................................................................................................................ 51
6.2 Meeting the Objectives............................................................................................... 51
6.2.1 Objective 1 ........................................................................................................... 51
6.2.2 Objective 2 ........................................................................................................... 52
6.2.3 Objective 3 ........................................................................................................... 52
6.2.4 Objective 4 ........................................................................................................... 52
6.3 Critical Analysis ......................................................................................................... 53
6.4 Future Work............................................................................................................... 54
6.5 Personal Reflection..................................................................................................... 54
7 REFERENCES ...................................................................................56
APPENDIX 1 - Initial Project Overview………………………………………..……61
APPENDIX 2 – Week 9 Interim Report………………………………………..…….64
APPENDIX 3 – Diary Sheets…………………………..…………………………...…69

40096050 SOC10101
List of Tables
Table 1: Server/IDS logs and fields of interest for creating Splunk rules .............................. 28
Table 2: Configuration of Virtual Machines ......................................................................... 31
Table 3: Splunk Rules.......................................................................................................... 38
Table 4: Software used in Implementation ........................................................................... 39
Table 5: Detection Results ................................................................................................... 49

40096050 SOC10101
List of Figures
Figure 1: Security Breaches in 2012 – adapted from (PwC, 2012).......................................... 1
Figure 2: Hacker circumplex (Rogers, 2006).......................................................................... 6
Figure 3: Classes of Computer Misuse Techniques (Neumann & Parker, 1989).................... 8
Figure 4: Pattern of Attack - adapted from (Buchanan, 2011)............................................... 10
Figure 5: Typical Stages of an APT – adapted from (Giura & Wang, 2013) ......................... 12
Figure 6: Defending Against Targeted Attacks (The Five Styles of Advanced Threat Defense -
Gartner Presentation) (Orans, 2014)..................................................................................... 14
Figure 7: IDC’s Digital Universe Study, sponsored by EMC, December 2012 (Gantz &
Reinsel, 2012)...................................................................................................................... 16
Figure 8: The Three V’s of Big Data (Niemeijer, 2014) ....................................................... 17
Figure 9: Overall score for each Vendor’s product based on the non-weighted score for each
Critical Capability (Nicolett & Kavanagh, 2013).................................................................. 20
Figure 10: Structure Chart.................................................................................................... 23
Figure 11: Design Overview ................................................................................................ 25
Figure 12: Network Architecture – Design........................................................................... 26
Figure 13: Prototype Network Configuration........................................................................ 30
Figure 14: DMZ Firewall Rules ........................................................................................... 31
Figure 15: LAN/Private Network Firewall Rules.................................................................. 32
Figure 16: Nmap Port Scan command .................................................................................. 32
Figure 17: Hydra command - FTP Brute Force Attack ......................................................... 32
Figure 18: Hydra command - Telnet Brute Force Attack ...................................................... 33
Figure 19: Login form.......................................................................................................... 33
Figure 20: Hydra command - HTTP Brute Force Attack ...................................................... 33
Figure 21: Hydra command (slower speed) – FTP Brute Force Dictionary Attack................ 34
Figure 22: Snort Preprocessor for detecting Port Scan .......................................................... 34
Figure 23: Snort rule created to detect FTP failed login attempts.......................................... 35
Figure 24: Snort rule created to detect FTP successful login................................................. 35
Figure 25: Snort rule created to detect Telnet failed login attempts....................................... 35
Figure 26: Snort rule created to detect Telnet failed login attempts....................................... 35
Figure 27: Snort rule created to detect successful login to Telnet.......................................... 35
Figure 28: Snort rule created to detect HTTP failed login attempts....................................... 36
Figure 29: Snort rule created to detect successful login to Web login form........................... 36
Figure 30: Nmap Port Scan command .................................................................................. 40

40096050 SOC10101
Figure 31: Snort preprocessor to detect Port Scan................................................................. 40
Figure 32: Results of Port Scan ............................................................................................ 41
Figure 33: Snort Alert for Port Scan..................................................................................... 41
Figure 34: Hydra command - FTP Brute Force Dictionary attack ......................................... 41
Figure 35: Snort rule to detect FTP failed login attempts...................................................... 41
Figure 36: Result of FTP Brute Force Attack ....................................................................... 42
Figure 37: Snort Alert for FTP failed login attempts............................................................. 42
Figure 38: Snort rule to detect FTP successful login............................................................. 42
Figure 39: Successful login to FTP service........................................................................... 42
Figure 40: Snort Alert for FTP successful login.................................................................... 42
Figure 41: Hydra command – Telnet Brute Force Dictionary attack ..................................... 43
Figure 42: Snort rule to detect Telnet failed login attempts................................................... 43
Figure 43: Snort rule to detect failed login attempts.............................................................. 43
Figure 44: Result of Telnet Brute Force Attack .................................................................... 43
Figure 45: Snort Alert for Telnet failed login attempts ......................................................... 43
Figure 46: Snort rule to detect successful login via Telnet .................................................... 43
Figure 47: Successful login to Telnet service........................................................................ 44
Figure 48: Snort Alert for Telnet successful login ................................................................ 44
Figure 49: Hydra command – HTTP Brute Force Dictionary Attack .................................... 44
Figure 50: Snort rule to detect HTTP failed login attempts................................................... 44
Figure 51: Result of HTTP Brute Force Attack .................................................................... 45
Figure 52: Snort Alert for HTTP failed login attempts.......................................................... 45
Figure 53: Snort rule to detect successful login to Web login form....................................... 45
Figure 54: Successful login to Web Page.............................................................................. 45
Figure 55: Snort Alert for successful login to Web login form.............................................. 46
Figure 56: Hydra command (slower speed) – FTP Brute Force Dictionary Attack................ 46
Figure 57: Splunk – Detection of Port scan .......................................................................... 47
Figure 58: Splunk rule created to detect over 100 failed logins in 10 seconds ....................... 47
Figure 59: Splunk Timeline for FTP Brute Force Dictionary Attack..................................... 47
Figure 60: Splunk Timeline for Telnet Brute Force Dictionary Attack.................................. 48
Figure 61: Splunk Timeline for HTTP Brute Force Dictionary Attack.................................. 48
Figure 62: Splunk results for ‘Low and Slow’ FTP Brute Force Dictionary Attack............... 49

40096050 SOC10101
Abstract
Cyber security and how to combat a wide variety of threats is a topic that is in the forefront of
many organisations’ minds these days. As attacks grow in number and complexity, companies
are having to look to spend more on security and look at new ways of confounding attackers.
Research shows that although the traditional security measures of Intrusion Detection
Systems and Intrusion Prevention Systems are inadequate when it comes to detecting and
preventing Advanced Persistant Threats due to the ‘low and slow’ modus operandi of these
attacks, Big Data Analytics with the ability to collect and analyse data over a long period of
time offers a solution to this problem. According to Gartner (Orans, 2014), in order for
companies to successfully defend against targeted attacks, organisations’ defences must
incorporate firewalls, IDS/IPS and SIEM.
The aim of this project is to determine whether by analysing and filtering log data from a
variety of sources; Security logs, System logs, Server logs and IDS logs and looking for
specific patterns in the data, it is possible using a SIEM architecture to detect brute force
dictionary attacks and whether by identifying said patterns, it is therefore possible to block
these attacks prior to sensitive information being stolen or any damage being caused to the
system.
VMware vSphere Client is utilised to provide a virtual cloud environment in which to create
the prototype SIEM architecture. Three VMware instances are created, one of which is a
Windows Server 2008 machine which acts as the victim in the implementation, another, the
Kali Linux, acts as the attacker in the scenario and finally, pfSense which provides the routing
between the two aforementioned machines and a firewall. In order to detect the attacks, Snort
and Splunk were installed on the Windows Server 2008. So as to determine the efficacy of a
SIEM architecture for the purpose of detecting and mitigating brute force dictionary attacks,
two different experiments were performed. The first experiment saw the attack being carrried
out at rapid speed whereas for the second experiment the attack is carried out at a much
slower speed. Various Splunk rules are created in order to filter and analyse the log data,
however, so as to obtain accurate results across the board, a standard metric to detect over 100
failed logins in 10 seconds is used.
The results for the first experiment indicated 1,935 failed login attempts to the FTP service
within approximately 10 seconds. Therefore, it could be concluded that it is possible to detect
and mitigate these types of attacks using a SIEM architecture. However, when the attack was
carried out at a much slower speed with only one login attempt being made per minute and the
same filtering rule was applied, the attacks were in fact not detected. This does not however
mean that a SIEM architecture would not be an appropriate method for detecting ‘Low and
Slow’ attacks, it merely shows that for successful detection, data would have to be collected
and analysed over a much longer period of time than for attacks that are carried out at a much
faster rate.

40096050 SOC10101
Pamela Dempster – BEng (Hons) Computer Systems and Networks Page | 1
1 Introduction
1.1 Introduction
According to Gartner (2014), in order to achieve across-the-board protection, ‘an adaptive
protection process integrating predictive, preventative, detective and response capabilities’
was necessary and a shift in thinking was required, moving from ‘incident response’ to
‘continuous response’, ‘wherein systems are assumed to be compromised and require
continuous monitoring and remediation’. Gartner (Orans, 2014) concluded that in order for
incorporate firewalls, IDS/IPS and SIEM.
The aim of this project is to determine whether by analysing and filtering log data from a
variety of sources; Security logs, System logs, Server logs and Snort logs and looking for
specific patterns in the data, it is possible using a SIEM architecture to detect brute force
dictionary attacks and whether by identifying said patterns, it is therefore possible to block
these attacks prior to sensitive information being stolen or any damage being caused to the
system. Taking into account Gartner’s recommendations (Orans, 2014), the prototype
network architecture has been designed accordingly. In order to evaluate the effectiveness of
the SIEM architecture in detecting these types of attacks, the attacks have been carried out
under different conditions.
1.2 Background
many organisations’ minds these days. As attacks grow in number and complexity, companies
are having to look to spend more on security and look at new ways of confounding attackers.
According to a survey carried out by Infosecurity Europe, the results of which were analysed
and reported by PwC, the number of security breaches in 2012 was at an all time high with
91% of large organisations reporting that they had had a malicious breach in the last year.
The estimated costs incurred by these organisations for the worst incident they had suffered
were in the region of £110,000 - £250,000. Figure 1 shows that out of these breaches, 73%
were attacks carried out by unauthorised outsiders, 59% were infections by viruses or
malicious software and 53% related to theft or fraud (PwC, 2012).
Figure 1: Security Breaches in 2012 – adapted from (PwC, 2012)

40096050 SOC10101
Some of the biggest security breaches seen over the last few years have included a data breach
at Adobe which resulted in 38 million users having to reset their passwords after hackers
gained access to user account information. Theft of source code for various Adobe
applications was identified as a partial cause of the incident (Krebs, 2013).
J P Morgan Chase, America’s largest bank announced they had been on the receiving end of a
cyber attack which resulted in a vast number of customers’ accounts being compromised. It is
said that the breach affected 76 million households and 7 million small businesses and was
cited at the time as one or the largest ever intrusions. The company stated in their defence
that, although user contact details were compromised, there was insufficient evidence to show
that information pertaining to customers’ accounts such as account numbers, passwords and
Social Security numbers had been compromised (Silver-Greenberg, et al., 2013).
Another company experiencing a massive data breach was eBay. In May 2014, hackers stole
private information belonging to 145 million users. Then in June, StubHub, eBay’s event
ticket reseller platform was attacked allowing hackers to obtain and resell event tickets
resulting in a $1million profit. Unfortunately for Ebay, this was not the end of their troubles
as it later transpired that customers had been part of a phishing scam where they were
redirected to malicious sites thereby allowing hackers to obtain their passwords and other
personal information (Cozza, 2014).
With the rise in the number of attacks and the increase in complexity of these attacks, the
traditional layers of defence; Demilitarized Zones (DMZ), Firewalls (hardware or software),
Intrusion Detection Systems (IDS) and Intrusion Protection Systems (IPS) are no longer
enough to keep organisations systems and data secure. Implementing SIEM software with the
ability to collect and analyse large amounts of data from various sources, gives companies a
further layer of defence and the opportunity to detect and mitigate these attacks and future
attacks.
1.3 Aims and Objectives
The overall aim of this dissertation is to determine whether by using a SIEM architecture it is
possible to detect and block scanning/information gathering attacks and brute force dictionary
attacks prior to sensitive information being stolen or any damage being caused to the system.
In order to meet this aim, the following objectives must be met:
1. Research and review Attack Taxonomies covering topics such as Cyber Adversaries,
Classification of Attacks and Attack Patterns. Further research and review Defence in
Depth, Big Data Analytics and SIEM.
2. Design and implement a prototype SIEM architecture.
3. Simulate brute force dictionary attacks against multiple protocols and import log data
from a variety of sources into a SIEM software package and carry out an analysis of
the data.
4. Evaluate whether it is possible by identifying certain patterns in the data, to detect and
therefore block the attack and whether when carrying out the attacks at a much slower
speed, it is still possible to detect the attacks.

40096050 SOC10101
1.4 Dissertation Structure
This dissertation is divided into the following six chapters:
 Chapter 1 - Introduction: This chapter contains an overview of the project and
provides a background as to why SIEM software is now a necessity when it comes to
organisations detecting and mitigating today’s advanced attacks. The project aim and
objectives are also outlined as is the structure of the dissertation. Due to the nature of
the project, a section on the ethics surrounding brute force attacks is also covered.
 Chapter 2 - Literature Review: The Literature Review covers several different areas
of research. The initial research covers areas such as cyber adversaries, classifications
of attacks and patterns of attacks. The literature review then examines how a defence
in depth approach provides organisations with the best means of defending against
cyber threats and finally, there follows a review of defence mechanisms; Intrusion
Detection Systems, Big Data Analytics and SIEM.
 Chapter 3 - Design: Following on from the conclusion reached in the Literature
Review, this chapter presents a design for the prototype SIEM architecture with
justification for design choices made. An overview of the attacks and of the proposed
detection methods is also provided as are details of the attack tools that are necessary
to carry out the attacks.
 Chapter 4 - Implementation: This chapter examines in detail how the design was
implemented in a cloud environment using a series of virtual machines to create the
required network scenario. The commands used to carry out the attacks, the Snort
rules used to detect the attacks and the Splunk rules that will be used to analyse and
filter the log data will be further explained.
 Chapter 5 - Evaluation: A description and evaluation of the experiments carried out
in order to determine whether it is in fact possible to detect and mitigate brute force
dictionary attacks is provided in this chapter. The results of those experiments are also
provided along with an analysis of those results.
 Chapter 6 - Conclusion: This chapter provides a conclusion to the dissertation and
examines how the aim and objectives were met. There follows a critical analysis of
the project as a whole and finally, a section on future work surrounding the subject
area of this project is presented.
1.5 Ethics
Due to the nature of this dissertation and the attack tools that will be used to carry out the
information gathering attack and the brute force dictionary attacks, there are some ethical
concerns that must be taken into account. Due to these factors, the prototype architecture will
be created in a virtualised environment with no access to any other networks. In accordance
with the Code of Conduct for BCS Members (British Computer Society, 2011) the following
rules will be adhered to:
 have due regard for public health, privacy, security and wellbeing of others and the
environment.
 not claim any level of competence that you do not possess
 avoid injuring others, their property, reputation, or employment by false or malicious or
negligent action or inaction.

40096050 SOC10101
2 Literature Review
2.1 Introduction
The literature review initially provides the reader with research on cyber adversaries and the
motivation behind cyber attacks. Further research is then presented on the classification of
attacks which looks in detail at scanning/information gathering attacks and brute force attacks
and finally, the stages that an attack or intrusion will typically follow are investigated.
Additional research examines how a Defence in Depth approach provides a means of
defending against cyber threats and finally, there follows a review of defence mechanisms;
Intrusion Detection Systems, Big Data Analytics and SIEM. A conclusion is subsequently
reached which ascertains that in order to prevent, detect and predict today’s more complex
attacks a security strategy which incorporates Firewalls, Intrusion Detection Systems and
SIEM, with the ability to analyse large data sets, is required.
2.2 Cyber Adversaries – A History
According to Meyers et al. (2009) it was not until the early 1980’s when personal computers
became more readily available that any kind of study was undertaken with regards to cyber
adversaries and when the term ‘hacker’ was first introduced, it referred only to people who
were highly skilled at programming and manipulating operating systems. The works of
Raymond (2003) and Walleij (1998) indicate that the first hackers originated from MIT and
were simply a group of curious students who excelled at programming and who liked nothing
better than to experiment and explore the capabilities of computers and computer technology.
As per Murphy et al. (1983) however it was not until a few years later following an incident
involving six teenagers referred to as the ‘414 gang’ who broke into 60 computer systems and
were subsequently arrested, that the term ‘hacker’ came to mean ‘an individual engaging in
malicious activity’. Lawson (2001) observes that today, however, many people within the
computer science sector argue that this terminology is in fact incorrect and that a more
appropriate term for these individuals is ‘cracker’.
Meyers et al. (2009) state that in 1985, Landreth, himself a skilled hacker, was one of the first
to attempt to classify the cyber adversary community. Landreth & Rheingold (1985) proposed
dividing those belonging to the hacking community into the following five categories:
 Novices
 Students
 Tourists
 Crashers
 Thieves
Novices were defined primarily as youths, who were on the whole just interested in making
mischief, who lost interest after a short while and were prone to making mistakes. The
students’ category as defined by Landreth & Rheingold, is reminiscent of Raymond (2003)
and Walleij (1998) description of the first hackers, students from MIT who engaged in this
type of activity purely for the cerebral challenge, who had little or no criminal intent and who
simply aspired to accumulate information about infiltrated systems. Tourists were described

40096050 SOC10101
as individuals who saw hacking as a personal challenge, who were in it for the thrill of it.
Crashers, however, were seen as destructive individuals who deliberately set out to cause
damage to systems or information and egoists who wanted their exploits to be known about
and consequently derived pleasure from the recognition. Landreth & Rheingold’s final
category thieves, consists of as the name implies, criminals who generally seek to profit from
their malevolent behaviour. These hackers were recognised as the most treacherous, with
superior technical skills and a thorough knowledge of their intended target (Landreth &
Rheingold, 1985).
In 1996, a large-scale study of 164 known hackers of various ethnicities was carried out.
Chantler (1996) argued that hacking behaviour could be compartmentalised according to a
number of different characteristics, such as knowledge, motivation, prowess and length of
time spent carrying out an attack. From the results of this study, which were derived from
surveys and interviews, Chantler proposed dividing the hacking population into the following
three categories:
 Losers and lamers
 Neophytes
 Elites
According to Chantler’s research, the losers and lamers were of limited intellect and were
predominantly motivated by greed and vengeance. Neophytes in Chantler’s opinion however
were more intellectually advanced than the losers and lamers, wanting to follow in the
footsteps of the elites and further their knowledge. The final category proposed, the elites,
were identified as individuals with superior technical skills who found the test of their
abilities to be stimulating, who enjoyed the sense of exhilaration and derived pleasure from
their feats of accomplishment.
Meyers et al. (2009) cite the works of Rogers (1999), (2000), (2001) and (2006) as being ‘the
most comprehensive study of cyber adversaries and their motivations’. Rogers earliest work
(Rogers, 1999), proposed a new taxonomy of hackers. After having examined earlier research
that had previously been done in this area, some of which has been mentioned earlier in this
report, Rogers proposed the following seven categories:
 Newbie/tool kit
 Cyber-punks
 Internals
 Coders
 Old guard hackers
 Professional criminals
 Cyber terrorists
Rogers ordered these categories starting with those with the least technical ability to those
with the highest technical ability. The newbie/tool kit category, Rogers classified as hacking
novices, who had only basic coding skills and who had to depend on existing hacking tools to
enable them to carry out their attacks. The cyber-punks’ programming ability however was
slightly more advanced than the newbies in that they were able to write some of their own
code and were more knowledgeable about the systems they were attacking. They also
deliberately engaged in malicious activities including theft and fraud. The internals, consisted

40096050 SOC10101
of disgruntled or former employees, possibly from an IT background, who had the capactity
to carry out attacks due to the level of access they had been granted for their post. To this day,
this category accounts for a very large proportion of security breaches. Rogers’ definition of
old guard hackers is comparable to that of the student category defined by Landreth &
Rheingold (1985) in that these individuals were not criminally minded and were interested
purely in the intellectual challenges of hacking and furthering their knowledge, similar to the
first generation of hackers originating from MIT as described by Raymond (2003) and Walleij
(1998). The final categories of professional criminals and cyber terrorists Rogers cites as
being the most dangerous, classifying them as highly skilled criminals with access to high-
tech equipment. These categories as defined by Rogers, bear a close resemblance to that of
Landreth & Rheingold’s (1985) ‘thieves’.
Rogers more recent work (Rogers, 2006), proposes a more up to date taxonomy that draws
upon his earlier work (Rogers, 1999) and the works of Furnell (2002) and Gordon (Gordon,
2002). This revised version contains the following nine categories:
 Novice
 Cyber-punks
 Internals
 Petty thieves
 Virus Writers
 Old guard hackers
 Professional criminals
 Information Warriors
 Political activist
In Figure 2, Rogers shows the nine defined categories, their level of skill and the motivation
behind their various activities.
Figure 2: Hacker circumplex (Rogers, 2006)
Note: Novice (NV), Cyber-punks (CP), Petty Thieves (PT), Virus writers (VW), Old Guard hackers (OG),
Professional Criminals (PC), Information Warriors (IW), Political Activists (PA)

40096050 SOC10101
The final taxonomy of cyber adversaries this report will consider is one proposed by Meyers
et al. (2009) which suggests separating hackers into the following eight categories:
 Script kiddies, newbies, novices
 Hacktivists, political activists
 Cyber punks, crashers, thugs
 Insiders, user malcontents
 Coders, writers
 White hat crackers, old guard, sneakers
 Black hat hackers, professionals, elite
 Cyber terrorists
Although this is a more up to date study, the definitions for the eight categories provided by
Meyers et al. (2009) are in fact based heavily on Rogers’ works (Rogers, 2000), (Rogers,
2006) as well as other previously carried out studies some of which have already been
examined in this report (Chantler, 1996) and (Landreth & Rheingold, 1985). When
comparing the above taxonomies, in particular that of Landreth & Rheingold which dates
back to 1985 and the most recent work this report examines, that of Meyers et al., which was
proposed some fourteen years later, it can be seen that although Meyers et al. propose more
categories of hackers than Landreth & Rheingold, the definitions and skills of the various
individuals involved in hacking activities are in fact extremely similar with the exception of
the cyber terrorists whose goal according to Meyers et al. is to cause damage or destruction to
an enemy nation’s infrastructure or data. So, although some of the characteristics of hackers
remain unchanged from years ago, it is apparent that the motivation behind some attacks and
the goals of some hackers today, are far more sinister than in previous years.
2.3 Attack Taxonomy
2.3.1 Classification of Attacks
Various papers have been written over the years proposing taxonomies intended for
classifying attacks. Some papers concentrated on particular types of attack such as the works
of Collins et al. (2006) and Weaver et al. (2003), who studied various types of worms. Lough
(2001) provided an attack taxonomy specifically relating to the field of wireless networks and
Specht & Lee (2004) and Wood & Stankovic (2004) both proposed a classification system
which focussed on Distributed Denial of Service Attacks (DDoS) and the various ways to
defend against them.
One of the earliest general attack taxonomies was proposed by Neumann and Parker (1989) in
1989 which put forward nine different categories of attacks for consideration. These can be
seen in Figure 3 ‘Classes of Computer Misuse Techniques’.

40096050 SOC10101
Figure 3: Classes of Computer Misuse Techniques (Neumann & Parker, 1989)
Hansman and Hunt (2004) however, provide a different type of taxonomy focussing more on
specific types of attacks which would however for all intents and purposes fall under the
headings Neumann and Parker had initially proposed. These eight suggested categories are as
follows; Viruses, Worms, Buffer Overflows, Denial of Service Attacks, Network Attacks,
Physical Attacks, Password Attacks and Information Gathering Attacks. A more
comprehensive classification system is provided by Buchanan (2011), which although
primarily uses the same categories proposed by Neumann and Parker in 1989, includes an
additional class of ‘Pests’. Examples of attacks that fall into these categories are also
specified and defined. As it would not be possible to address every type of attack in this
report, for the purposes of this dissertation, Scanning/Information Gathering Attacks and
Brute Force Attacks will be examined in detail.
Scanning/Information Gathering Attacks
Attacks on networks are generally approached in several stages; this is further explored in
Section 2.3.2 Attack Patterns. During the first stage, an attacker may try to probe or scan a
network looking to find a vulnerability or point of entry. Valuable information can be gained
from scanning/information gathering attacks, such as the network topology, the kind of traffic
permitted through the firewall, which hosts are active on the network, which services are
running and details of the operating system being used. Shaikh et al. (2008) observe that the
more information an intruder has of their intended target, the higher the probability there is of
the intruder then being able to carry out an attack successfully and furthermore avoid
detection. Buchanan (2011) asserts that any sign of scanning or probing activities should be
seen as a sure sign of a forthcoming security breach. Shaikh et al. (2008) further suggest that
in order to avert security breaches, these information gathering/probing attacks must be
detected as early as possible. The works of de Vivo et al. (1999) identify many different types
of scanning techniques such as TCP SYN scanning, stealth scanning and indirect scanning. In
the case of TCP SYN scanning, the attacker sends a SYN to any number of ports on the
victim machine, if the port is open, a SYN ACK is returned, if the port is closed, a RST ACK
is returned. Stealth scanning differs from SYN scanning in that is uses FIN packets instead of
SYN segments. If the port is closed, as with SYN scanning, a REST ACK is returned,

40096050 SOC10101
however, if the port is open the FIN segment is merely dropped. Indirect scanning involves
the use of spoofed IP addresses with the sole intent of hiding the location of the intruder.
According to Bace & Mell (2001), many different tools can be used for the purpose of
scanning and information gathering such as network mappers, port mappers, network
scanners, port scanners or vulnerability scanners to gain valuable information about a
network. Nmap, a well-known and popular network mapper, is a free and open source utility
used by millions of people ranging from novices to highly skilled hackers. Nmap can be used
by attackers during the reconnaissance phase of an attack, to quickly scan a range of devices
in order to gain valuable information about the network and identify any potential
vulnerabilities or possible points of entry to the system (Lyon, 2009). Nmap can perform a
variety of scans including ping sweeps to identify which hosts are active on the network and
operating system scans which allow the attacker to glean details about the operating system
being used and port scans which will identify which ports are open and which services are
running on the network.
Brute Force Attacks
Tasevski (2011) suggests that the foremost method of controlling access to systems is by
means of passwords. Users must input passwords in order to identify themselves to the system
and to gain access to the required resources. Other research suggests however that passwords
are soon to be a thing of the past as they present a large security risk and that the use of
biometrics is becoming more prevalent as a standard authentication mechanism due to the fact
that biometric characteristics are unique to each individual (Chin-Chuan, 2003), (Brown,
2003). Whitman & Mattord (2012) note that in order for an attacker to gain entry to a system,
access to a valid user name and password must be acquired. Drasar’s research (2013)
intimates that attackers play on the fact that users are apt to select weak passwords, leaving
them open to attack. Vykopal (2013) agrees, stating that attackers presume users select
passwords that are either short or names or words from the dictionary. Whitman & Mattord
(2012) and Vykopal (Vykopal, 2013) note that acquiring a valid user name and password can
be achieved in one of two ways, either by carrying out a brute force attack which uses random
combinations of all characters and can be very time consuming or a dictionary attack which is
a variation of a brute force attack but which uses lists of commonly known user names and
passwords. Vykopal (2013) proposes two categories of brute force attacks, simple or
distributed. In simple attacks, all the authentication attempts come from a single host,
whereas with distributed attacks, many different hosts initiate a much smaller number of
authentication requests thus making the attack much more problematical to detect. Once an
attacker has gained a foothold on the system by accessing a user account, Buchanan (2011)
affirms that it is then possible by using those credentials to secure further information about
the system and advance up the privilege levels. If the attacker were then able to obtain the
Administrators credentials with the highest level of privileges, it would be possible for the
intruder to cause untold damage to the system or to steal confidential information.
An example of a tool which can be used to perform such attacks is Hydra. Hydra is an
extremely fast logon cracker that can be used to carry out brute force dictionary attacks
against many different protocols including FTP, Telnet, SMTP and HTTP (THC-Hydra,
2014). In order to carry out the attack, files containing well known user names such as
administrator, guest and root, and commonly used passwords must be provided to the utility
as well as the IP address of the target. Hydra will then endeavour to crack the user name and
password by trying every possible permutation. If successful, Hydra will discontinue the
attack and return the correct username and password.

40096050 SOC10101
2.3.2 Attack Patterns
Whitman and Mattord (2012) define an attack as ‘an intentional or unintentional act that can
cause damage to or otherwise compromise information and/or the systems that support it’. An
attack or intrusion typically follows a pattern consisting of several stages. Barnum et al.
(2007) write that attack patterns make it is possible to classify attacks in a way that can assist
in the design of appropriate security solutions and that armed with the knowledge of how
specific attacks are carried out, what stages an attack will go through and the motivation
behind the attack, it is possible to implement measures to prevent these attacks. Mohay et al.
(2003) suggest that this pattern is made up of three stages; the reconnaissance phase, the
attack phase and the ‘pay off and exit’ phase. The reconnaisance phase defined by Mohay et
al. involves gathering information that will enable the attacker to identify a vulnerability in
the system. The attack phase subsequently involves exploiting that vulnerability thereby
allowing the attacker to gain access to the system. Depending on motive, the final stage, the
‘pay off and exit’ phase could see the attacker accessing, corrupting or destroying information
resulting in a breach of confidentiality, integrity or availability. The work of Buchanan
(2011) provides a more detailed account of attack patterns and proposes five attack phases
colour coded from yellow to red according to level of severity. Figure 4, shows the five
attack phases as identified by Buchanan with additional information as to what could be
expected during each phase of an attack.
Outside
Reconnaissance
Inside
Reconnaissance
Exploit
FootholdProfit
Attacker gathers information
already in public domain
such as domain names or IP
addresses
Using network scanning tools such as Nmap, attacker
attempts to gain more detailed information eg.
network topology, active hosts on the network (ping
sweep), location of devices and open ports (TCP/UDP
scans) and account scans (scanning user IDs for weak
passwords)
Attacker finds a weakness
such as cracking a password
(brute force attack,
dictionary attack) or
breaching a firewall
Once inside, attacker can
then advance up the
privilege levels
Data stealing, system damage,
user abuse, fraud, terrorism,
financial gain, political gain,
resource utilisation (DoS)
Figure 4: Pattern of Attack - adapted from (Buchanan, 2011)

40096050 SOC10101
In relation to the above diagram, the outside reconnaissance phase sees the attacker gathering
information about the intended target that is already in the public domain, such as domain
names or IP addresses. During the inside reconnaissance phase, the attacker attempts to gain
more information such as the network topology, the kind of traffic permitted through the
firewall, which hosts are active on the network and details of the operating system being
used. Various scanning tools can be used during the reconnaissance phase of an attack, to
quickly scan a range of devices in order to gain valuable information about the network and
identify any potential vulnerabilities or possible points of entry to the system. Once an
attacker has discovered a weakness that they can exploit, such as cracking a password, they
can then gain entry to the system and once inside, gather more information that will allow
them to advance up the privilege levels.
Barnum et al. (2007) however take a different approach and suggest that in addition to the
chain of events an attacker will follow to carry out a specific type of attack, an attack pattern
should consist of the following information:
 Pattern Name and Classification
 Attack Prerequisites
 Description
 Related Vulnerabilities or Weaknesses
 Method of Attack
 Attack Motivation-Consequences
 Attacker Skill or Knowledge Required
 Resources Required
 Solutions and Mitigations
 Context Description
 References
It can be deduced from the above works, that attack patterns most definitely have a place in
the field of security and that by identifying attack specific information, such as why and how
different types of attack are carried out and the skills and goal of the attacker, it should then
be possible to implement the correct security measures in order to detect or even prevent
certain attacks.
Advanced Persistent Threat
According to an RSA Security Brief (Curry, et al., 2011), Advanced Persistent Threats
(APTs) are one of the most dangerous and rapidly growing threats to information security that
organisations are being confronted by today. The term Advanced Persistent Threat is defined
by The National Institute of Standards and Technology (NIST) as ‘an adversary that possesses
sophisticated levels of expertise and significant resources which allow it to create
opportunities to achieve its objectives by using multiple attack vectors’ (Ross, et al., 2010).
Curry et al. (2011) indicate that although in the past, these attacks were generally aimed at
military and political targets, it would appear now, that more and more, attackers are directing
these attacks at enterprise targets for monetary reward. Thomson (2011) however states that
the motivation behind some of these attacks is to highlight security problems or purely for the
purpose and pleasure of causing chaos. Schwartz (2011) point out that RSA was recently on
the receiving end of one of these targeted attacks. RSA later stated however that after a
thorough investigation, the attackers were not targeting their customers financial details, but

40096050 SOC10101
that the intended targets were more than likely the defence sector and other government
related departments. Whatever the attackers motive in this instance, the attack subsequently
cost the organisation in the region of $66 million in direct costs alone.
Advanced Persistent Threats are regarded as ‘low and slow’. ‘Low’ meaning that the attacks
are carried out in a covert manner in order to avoid detection and ‘slow’ referring to the
measured and unhurried way in which the attacks are carried out (Giura & Wang, 2013),
(Tankard, 2011). Giura & Wang (2013) state that although each attack is individually tailored
and adapted for the specific target, the phases they go through are analogous, however, it
would appear that there are varying opinions as to how many stages there actually are and
what each of these stages entails. Smith (Smith, 2013) suggests that APT attacks go through
three specific stages; Access Expansion, Persistence and Asset Targeting and Exfiltration.
Thonnard et al. (2012) however propose the following four phases; Incursion, Discovery,
Capture and Exfiltration. Whereas, Guira & Wang (2013) and Dalal (2012) take this even
further, specifying six stages; Reconnaissance, Delivery, Exploitation, Operation, Data
Collection and Exfiltration.
Figure 5 illustrates the typical stages, as defined by Guira & Wang (2013), that an Advanced
Persistent Threat will follow.
EXFILTRATION
DATA COLLECTION
OPERATION
EXPLOITATION
DELIVERY
RECONNAISSANCE
Select drop servers
Establish large C&C channels
Initiate external connections
Exfiltrate data
Select intermediary staging servers
Move sensitive data
Pack and compress data
Encrypt data
Locate target data
Target most privileged users
Elevate access privileges
Access sensitive data
Deliver spear-phishing email
Exploit employee user machine
Collect user credentials
Scan internal network
Craft targeted email
Create malware (RAT)
Set up malicious URL
Send spear-phishing email
Network scan
Network mapping
Employee profiling
Search zero day exploits
Figure 5: Typical Stages of an APT – adapted from (Giura & Wang, 2013)
There follows a short description of what each of these stages actually entails as defined by
Giura & Wang (2013) and Dalal (2012).

40096050 SOC10101
 Reconnaissance Phase: The attacker gathers information about the network and specific
employees, determining who to target and how.
 Delivery Phase: The attacker composes and sends an email to particular individuals
which contains a malicious attachment or directs them towards an infected website.
 Exploitation Phase: The spear-phishing email is delivered allowing attack tools to be
installed thereby enabling the attacker to gain more information about the internal network
such as security configurations, usernames and passwords.
 Operation Phase: The attacker maintains a continuing presence in the network trying to
identify where the organisation’s sensitive information is stored, who has access to it and
how they can gather the information and then transport it out of the network.
 Data Collection Phase: Using credentials obtained in the Exploitation and Operation
phases, the attacker accesses the targeted information, divides it up, compresses it and
encrypts it in readiness for exporting it out of the network to a predefined location.
 Exfiltration Phase: During the final phase of the attack, the information is moved out of
the network via encrypted channels to one or more ‘drop points’. Once the information is
in the hands of the attacker, it can be sold or used for the purposes of extortion.
Virvilis et al. (2013) suggest that APT attacks cannot be detected merely by using normal
security measures such as Intrusion Detection Systems (IDS) and Intrusion Prevention
Systems (IPS) as these tend to operate in real time and will only generate alerts for attacks
taking place over a short window of time. As APTs are generally carried out over a longer
period of time, it is quite possible for them to go undetected. Virvilis et al. propose that rather
than focussing on trying to detect these attacks with tools that concentrate on real-time
incidents, Big Data Analytics are essential for preventing such attacks. Tankard (2011) also
notes that by analysing data collected from a variety of sources over a much longer period of
time, it is deemed possible to detect less obvious attack indicators such as an increase in failed
login attempts, excessive network traffic and unusual resource utilisation (Virvilis, et al.,
2013), (Tankard, 2011). Smith (2013), suggests that only a defence in depth approach to
security will help to prevent these more sophisticated forms of attack and that there is not one
single solution and that it is not only network security that needs to be continuously assessed
but that educating staff in order to prevent them from opening unsolicited emails or clicking
on links is also a crucial factor in maintaining secure systems. Thomson (2011) agrees that
additional security measures are required in order to detect and hopefully prevent these types
of attacks and that a layered approach to security is a necessity. Thomson also notes that
particular attention should be paid to those staff that are most likely to be targeted.
It can be concluded from the above research that although the traditional security measures of
Intrusion Detection Systems and Intrusion Prevention systems are inadequate when it comes
to detecting and preventing Advanced Persistant Threats due to the ‘low and slow’ modus
operandi of these attacks, Big Data Analytics with the ability to collect and analyse data over
a long period of time offers a solution to this problem.

40096050 SOC10101
2.4 Defence in Depth
The term defence in depth originates from the military perspective of positioning multiple
layers of defence in the path of an attacker for the purpose of slowing them down (Buchanan,
2011), (Andress & Winterfield, 2014) . Andress & Winterfield (2014) note that it is not
viable for organisations to presume to create a situation where their defences are in fact
impassable, however, through employing numerous security strategies, it should be possible
to hamper attackers’ efforts for long enough in order to be able to detect their actions or even
deter them altogether. The National Security Agency (2014) proposes that in order for
organisations to successfully defend against attacks, it is imperative that possible adversaries
and their motivations are identified as well as the types of attack that may be carried out
against them. Whitman & Mattord (2012) suggest that these layers of defence should be
structured to include; security policy, an ongoing staff training and education programme and
technology. The NSA (National Security Agency, 2014) suggest that in order for
organisations’ assets to be adequately protected, the defence in depth approach needs to
incorporate the following three entities; people, technology and operations.
Virvilis et al. (2013) emphasise that with cyber attacks becoming more and more prevalent
and where the consequences of such attacks, particularly in relation to the military and
government, can result in the loss of life, it is essential to recognise the challenges and
limitations faced by existing technologies in relation to today’s more complex attacks. In
2013, Gartner stated that “Prevention is futile in 2020. Advanced targeted attacks make
prevention-centric strategies obsolete” (Gartner, 2013). In a subsequent report published in
2014, Gartner suggested that in order to achieve across-the-board protection, ‘an adaptive
protection process integrating predictive, preventitive, detective and response capabilities’
was necessary and that a shift in thinking was required, moving from ‘incident response’ to
continuous monitoring and remediation’ (Gartner, 2014). Figure 6, taken from a Gartner
Presentation entitled ‘The Five Styles of Advanced Threat Defense’ (Orans, 2014) looks at
the technologies required for defending against targeted attacks and shows what stage
mainstream enterprises are at when it comes to implementing these strategies.
Figure 6: Defending Against Targeted Attacks (The Five Styles of Advanced Threat Defense - Gartner
Presentation) (Orans, 2014)

40096050 SOC10101
It can be determined from the above research that with cyber attacks becoming more
prevalent and with the emergence of Advanced Targeted Attacks, although it is not possible
for organisations to hope to create a situation where their defences are impenetrable, by
employing numerous security strategies and taking a new approach to security whereby
systems must be presumed to be compromised and require continuous monitoring and
remediation it should be possible to achieve comprehensive protection.
2.5 Defence Mechanisms
2.5.1 Intrusion Detection Systems
Bace & Mell (2001) define intrusions as “attempts to compromise the confidentiality,
integrity or availability, or to bypass the security mechanisms of a computer or network.”
Whitman & Mattord (2012) make the presumption that most often; intrusions are carried out
by outsiders, however Scarfone & Mell (2007) dispute this stating that although many
security intrusions come from outside the organisation, many incidents are actually the result
of authorised users abusing their privileges and some threats may in fact be the result of
human error. According to the works of Scarfone & Mell (2007) and Bace & Mell (2001), in
order to detect intrusions, computer system and network events must be continuously
monitored and analysed.
As indicated by Bace & Mell (2001), there are three main working components that are
fundamental to the makeup of an Intrusion Detection System. These are as follows:
 Information Sources: The computer system and network events which are monitored in
order to ascertain whether an intrusion has occurred.
 Analysis: The component of the IDS that analyses the computer system and network
event information in order to determine whether an intrusion is currently taking place or
has already occurred.
 Response: Relates to the actions that are carried out by the IDS once an intrusion has
been detected and are classified as either active responses or passive responses. In the
case of active responses, the IDS automatically deals with the intrusion. Whereas, in the
case of passive responses, the IDS relays its responses, generally in the form of an alarm
or notification, to a user, oftentimes an Administrator in order that a decision on how to
react may be made (Bace & Mell, 2001).
Ruiz-Martinez, et al. (2014) note that there are four ways that an IDS can respond to event
information:
 True Positive: The IDS generates an alarm and an intrusion has taken place
 False Positive: The IDS generates an alarm, but the events detected are in fact legitimate
 True Negative: The IDS does not generate an alarm and no intrusion has taken place
 False Negative: The IDS does not generate an alarm although an intrusion has occurred
Intrusion Detection Systems (IDS) fall into two categories; signature based or anomaly based.
According to Scarfone & Mell (2007), signature based intrusion detection systems which use
pattern matching, provide the most accurate method for detecting known attacks. Whitman &
Mattord (2012) note however that one disadvantage of signature based detection is that since
previous knowledge of an attack is necessary, unless new signatures are constantly added,
new attacks may go undetected. One example of a signature based IDS is Snort. Snort is an
open source IDS/IPS that is capable of real-time traffic analysis. Martin Roesch (1999) refers

40096050 SOC10101
to Snort as a “lightweight network intrusion detection tool” suited to monitoring smaller scale
networks. Snort is preconfigured with a set of built in pre-processor rules that will detect
many forms of attack, however, it is also relatively easy to create new rules in order to be able
to adapt to new forms of attack.
Scarfone & Mell (2007) observe that anomaly based IDS monitor the behaviour of users,
hosts or network connections. Information is gathered with regards to normal system or user
activity and used to set a baseline. If the behaviour then deviates from that norm, the change
can thus be seen as suspicious activity and logged. Whitman & Mattord (2012) note that one
advantage of this anomaly based approach is that new attacks can be detected, however, this
type of detection does have its limitations, in that one, it is still possible for a user to carry out
malicious activities without deviating from their normal behaviour pattern and two, due to the
erratic behaviour of networks and users, it generally produces a lot of false positives.
It can be concluded from the above research that both signature based IDS and anomaly based
IDS have their place when it comes to detecting intrusions, both have advantages and both
have disadvantages.
2.5.2 Big Data Analytics
According to a study carried out by IDC (International Data Corporation), Gantz and Reinsel
(2012) report that between the start of 2005 and the end of 2020 the amount of ‘digital data
created, replicated and consumed’ will increase three hundred fold from 130 exabytes to
40,000 exabytes which is equal to 5,200GB per person. Figure 7 shows that from the start of
2010 to the end of 2020, the total amount of digital data will increase by a factor of 50.
EXABYTES
2009 20202010 2011 2012 2013 2014 2015 2016 2017 2018 2019
40,000
10,000
20,000
30,000
THE DIGITAL UNIVERSE: 50-Fold Growth from the Beginning
of 2010 to the End of 2020
DigitalData
Years
Figure 7: IDC’s Digital Universe Study, sponsored by EMC, December 2012 (Gantz & Reinsel, 2012)
In 2001, Doug Laney of the Meta Group (now known as Gartner) defined big data with the
three dimensions; volume, velocity and variety (Laney, 2001):

40096050 SOC10101
 Volume: The first V referred to in the context of big data refers to Volume. Buchanan
(2014) notes that the amount of data being generated is constantly increasing and states
that 90% of all the data in the Cloud has been created within the last 2 years, with 2.5
quintillion bytes of data being produced daily which is the equivalent of 1 billion hard
disks. According to McNulty (2014), 100 terabytes of data are uploaded on a daily basis
to Facebook alone, whilst Buchanan (2014) states that 12 terabytes of tweets are generated
daily. Russom (2011) states that although the majority of people refer to terabytes or
petabytes in relation to quantifying big data, it can also be measured by counting records,
transactions, tables or files.
 Variety: The second V referred to in the context of big data refers to Variety. Russom
(2011) states that what causes big data to be big is that the sources of data generated are
far more diverse now than in previous years. Russom notes that many of the more recent
sources are Web related such as clickstreams and social media, but also mentions text data
from call centres, geospatial data and RFID data. Niemeijer (2014) also notes that the
variety of data being generated has expanded, changing from simply plain text to images,
audio, video, locations and sensor data. Russom (2011) goes on to say that it is not just
the sources of data that have evolved, but also the type of data being collected. Mark van
Rijmenam (2014) writes that whereas previously all data generated was structured, 90% of
the data created today is unstructured and comes in a wide variety of formats. Russom
(2011) gives some examples of unstructured data as being human language and semi-
structured data such as XML and RSS feeds and also notes that some data such as from
audio and video and other devices does not fall into any particular category.
 Velocity: The third V referred to in the context of big data refers to Velocity. Velocity
according to van Rijmenam (2014) and McNulty (2014) relates to the speed at which
data is currently being created and how fast the data can be processed, stored, analysed
and visualised. McNulty (2014) and van Rijmenam (2014) also state that every minute of
every day, 200 million emails and 300,000 tweets are sent and 100 hours of video are
uploaded to YouTube. van Rijmenam (2014) writes, that where previously it took time
for data to be processed and databases to be updated, now data is being created in real-
time and can be collected from a variety of sources and processed immediately.
Figure 8 defines the three V’s of big data; Volume, Velocity and Variety.
Figure 8: The Three V’s of Big Data (Niemeijer, 2014)

40096050 SOC10101
Mark van Rijmenam (2014) expands on the above in an article ‘Why The 3V’s Are Not
Sufficient To Describe Big Data’ and proposes a further four V’s, namely, Veracity,
Variability, Visualisation and Value. These additional categories are:
 Veracity: Veracity in the context of big data refers to the accuracy or correctness of the
data. According to van Rijmenam (2014) and McNulty (2014) although there are huge
possibilities for organisations through the analysis of big data, unless the data is accurate,
it holds no value. McNulty (2014) goes on to point out that what organisations have to
understand about big data is that a huge amount of work must be carried out in order to
clean up the data and to ensure the accuracy of it before the process of analysis can
commence.
 Variability: Variability in the context of big data refers to the constant shifting in
meaning of the data. McNulty (2014) explains that in relation to data that is dependent
on language processing, the same word can have different meanings when used in
different contexts. The solution to this problem according to both McNulty (2014) and
van Rijmenam (2014) is that organisations will have to create complex programmes that
are capable of deciphering context in order to be able to define the intended meaning of
words.
 Visualisation: Visualisation in the context of big data refers to the ability to present
huge quantities of raw data in a format that is simple to understand and easy to look at
(van Rijmenam, 2014), (McNulty, 2014). These visualisation techniques take the form of
images, diagrams and animations and according to a report by The McKinsey Global
Institute (Manyika, et al., 2011) form an essential part of the data analysis process in
enabling people to compute large amounts of numerical or text data.
 Value: Value in the context of big data refers to the financial benefits organisations stand
to gain through the analysis of big data. According to McKinsey’s report (Manyika, et
al., 2011) big data has an estimated value of $300 billion to the US Health Care system
and 250 billion Euros to Europe’s public sector administration. van Rijmenam (2014)
points out however, that data alone holds no value, that it is the analysis of the data and
the resulting knowledge that can be gained from that analysis that is of huge value to
many organisations.
According to Russom (2011), “Big Data Analytics is where advanced analytic techniques
operate on big data sets.” Taft (2012), notes that a wide range of industries such as the
financial sector, retail industry, the physical sciences and life sciences are now generating and
analysing huge amounts of data. The financial sector is using data analytics to enable them to
devise trading strategies and to aid in the creation and development of new financial products.
The retail sector is using data analytics in order to determine what products customers are
looking at and subsequently purchasing in order to give them some insight into customers’
buying habits. In the case of life science, Brust (2012) suggests that with the use of data
analysis tools such as Hadoop, not only is there the possibility to alter lives for the better;
there is also the potential to save lives. Tankard (2012), pronounces that outside of
commercial organisations, big data analytics can be used in a variety of other ways, for
example in enhancing Governments’ capacity to detect and even prevent threats from foreign
countries. Tankard quotes the United States Department of Homeland Security as having
stated that by analysing data from various sources such as the Internet and social media sites
and by examining and monitoring the sites individuals were viewing and what was being
communicated, it would have been possible to foresee the Arab Spring revolutions.

40096050 SOC10101
It can be seen from the above, that a wide range of sectors from commercial organisations to
Governments to medical research facilities can benefit in a variety of different ways from the
use of data analytics.
2.5.3 SIEM
Gartner reported in 2011 (Nicolett & Kavanagh, 2011) that although Security Information
and Event Management systems (SIEMs) are often implemented in order to deal with
regulatory compliance reporting requirements that once deployed however, organisations
were also then looking to take the opportunity to improve upon their capacity for dealing with
security incidents. According to Karlzen (2009), there are several reasons organisations
implement SIEM systems; compliance, insider threats and the costs organisations can incur as
a result of a security breach. Gartner (Nicolett & Kavanagh, 2013) expand on this by stating
that SIEM technology is often implemented for the purposes of detecting external and internal
threats, monitoring the actions of users in particular those with a high level of privileges,
monitoring server and database access, behaviour profiling and for the purpose of offering
analytic capabilities in order to improve upon the management of incident responses.
The works of Afzaal, et al. (2012) and Garofalo, et al. (2014) affirm that SIEMs are
extensively used to monitor and protect critical infrastructures. Afzaal, et al. (2012) stress
that when a security breach takes place, the forensic analysis of stored events is of vital
importance in tracking and subsequently identifying attackers. Afzaal, et al. go on to say that
once the attacker has been identified, results of the forensic analysis can then be taken to
Court and used as evidence in order to secure a conviction. Grzinic, et al. (2013) agree that
analysing data for the purpose of detecting security incidents is invaluable, but raise concerns
as to the intelligence of commercial SIEM products suggesting that due to the basic statistical
techniques employed by these products, the detection of threats or intrusions falls mainly to
the data analysts. Hernando (2014) agrees, pointing out that as rules must be expressly
designed for each new attack, that at present, correlation modules are not capable of detecting
new types of threat or even existing threats where the behaviour of the threat deviates from
the norm. Hernando does believe however that as network infrastructures have become more
complex and the amount of event information has increased, it is no longer feasible for
security personnel to manually examine the amount of data that is currently being generated
and that therefore, SIEMs whatever their limits are a welcome solution to this problem.
There are various SIEM products available on the market from different vendors such as
Hewlett Packard who offer ArcSight, IBM who offer Q1 Labs, AlienVault and Splunk all of
which differ slightly; however, the basic functions are the same (Karlzen, 2009). Hollows
(2002) quotes Gartner as stating that SIEM technologies must be able to provide the following
five services, otherwise known as the ‘five Cs’:
 Collection: log data is collected from a diverse range of sources such as network devices,
security devices, servers, databases and applications.
 Consolidation: log data is normalised and aggregated.
 Correlation: separate log events are linked together in order to try to identify and
construct an imminent threat or an attack as a whole.
 Communication: once a potential threat or an attack has been identified during the
correlation phase, an alert is generated.

40096050 SOC10101
 Control – relates to how the data is stored, whether that be whilst the data is being
analysed and is available online or once the data is no longer required to be readily
available (Karlzen, 2009), (Hollows, 2002).
In 2013, Gartner rated SIEM technologies according to their ability for delivering real-time
monitoring, threat intelligence, behaviour profiling, data and user monitoring, application
monitoring, analytics, log management and reporting and deployment and support simplicity.
The highest scoring products according to Gartner’s calculations are HP ArcSight, IBM Q1
Labs, McAfee ESM, LogRhythm and Splunk (Nicolett & Kavanagh, 2013). Figure 9 shows
the overall score for each vendor’s product according to Gartner.
Figure 9: Overall score for each Vendor’s product based on the non-weighted score for each Critical
Capability (Nicolett & Kavanagh, 2013)
It can be concluded from the above research that although SIEM systems are often
implemented in order to deal with regulatory compliance reporting requirements, that more
and more, organisations are turning to SIEMs that offer analytic capabilities to improve upon
the management of responses to security incidents.

40096050 SOC10101
2.6 Conclusion
The aim of this chapter was to initially provide some background research on cyber
adversaries, the motivation behind cyber attacks and the different classes of attacks being
faced by organisations, as according to The National Security Agency (2014) in order for
organisations to successfully defend against attacks, it is imperative that possible adversaries
and their motivations are identified as well as the types of attack that may be carried out
against them.
Section 2.4 examined how a Defence in Depth approach provides organisations with a means
of defending against cyber threats and that although according to Andress & Winterfield
(2014) it is not viable for organisations to presume to create a situation where their defences
are in fact impassable, through employing numerous security strategies, it should be possible
to hamper attackers’ efforts for long enough in order to be able to detect their actions or even
deter them altogether.
Finally, Section 2.5 provided a review of defence mechanisms; Intrusion Detection Systems,
Big Data Analytics and SIEM where it was shown that although the traditional security
measures of Intrusion Detection Systems and Intrusion Prevention Systems are inadequate
when it comes to detecting and preventing Advanced Persistant Threats due to the ‘low and
slow’ modus operandi of these attacks, Big Data Analytics with the ability to collect and
analyse data over a long period of time offers a solution to this problem. Further research
showed, that in order to achieve across-the-board protection according to Gartner (2014), ‘an
adaptive protection process integrating predictive, preventative, detective and response
capabilities’ was necessary and a shift in thinking was required, moving from ‘incident
response’ to ‘continuous response’, ‘wherein systems are assumed to be compromised and
require continuous monitoring and remediation’. It is therefore concluded that in order to
prevent, detect and predict today’s more complex attacks a security strategy which
incorporates Firewalls, Intrusion Detection Systems and SIEM, with the ability to analyse
large data sets, is required.
The overall aim of this dissertation is to determine whether by using a SIEM architecture it is
possible to detect and block scanning/information gathering attacks and brute force dictionary
Based on the conclusion reached in the Literature Review and in order to meet this aim, it is
apparent that the network architecture that is to be created should incorporate the following
three elements; a Firewall, an Intrusion Detection System and SIEM software.

40096050 SOC10101
3 Design
3.1 Introduction
The aim of this dissertation is to determine whether by analysing and filtering log data from a
specific patterns in the data, it is possible using a SIEM architecture to detect
scanning/information gathering attacks and FTP, Telnet and HTTP brute force dictionary
attacks and whether by identifying said patterns, it is therefore possible to block these attacks
prior to sensitive information being stolen or any damage being caused to the system.
According to Gartner (2014), in order to achieve across-the-board protection, ‘an adaptive
protection process integrating predictive, preventative, detective and response capabilities’
was necessary and a shift in thinking was required, moving from ‘incident response’ to
continuous monitoring and remediation’. Gartner (Orans, 2014) concluded that in order for
incorporate firewalls, IDS/IPS and SIEM. This is therefore the approach that has been taken
when designing the prototype network architecture for this project.
Section 3.2 gives an outline of the design methodology used. Section 3.3 presents an
overview of the threats that will be simulated, further information about which can be found
in the Literature Review. Section 3.4 outlines the design of the network architecture that will
be created and looks at the various options that were considered in order to create the best
prototype testing environment and gives a brief summary as to why various design choices
were made. In addition, a diagram providing an overview of the design is included. Section
3.5 provides details of the attack tools that are necessary to carry out the attacks. Section 3.6
looks at Intrusion Detection Systems and SIEM software and provides details of the various
logs that will be monitored and the fields of interest for creating the rules to filter the data and
detect the attack. Section 3.7 defines the evaluation metrics and finally, Section 3.8 affords a
conclusion to this chapter.
3.2 Design Methodology
In order to design and create the required prototype SIEM architecture, a Top Down Design
methodology will be used. This approach is used throughout computing and in many other
fields as well. This process of breaking larger, complicated problems down into smaller,
easier-to solve ones is known as Top Down Design for the obvious reason that the designer
starts at the top, with the problem as a whole, and works downwards (Pelchat, 2004). One
other advantage of this methodical approach is that it also provides a structure for the
solution. In structured analysis, structure charts are often used to specify the high-level
design, or architecture, of a computer program or network. As a design tool, structure charts
assist the designer in dividing and conquering a sizeable problem, that is, recursively breaking
a problem down into parts that are small enough and simple enough to be understood
(Yourdon & Constantine, 1979).
Figure 10 shows a Structure Chart that has been created to show all the components required
to create the prototype framework.

40096050 SOC10101
Figure 10: Structure Chart

40096050 SOC10101
3.3 Threats – An Overview
3.3.1 Scanning/Information Gathering Attack – Portscan
Attacks on networks are generally approached in several stages. During the first stage, an
attacker may try to probe or scan a network looking to find a vulnerability or point of entry to
the system. Valuable information can be gained from scanning/information gathering attacks,
such as the network topology, the kind of traffic permitted through the firewall, which hosts
are active on the network, which services are running and details of the operating system
being used. Further information about this type of attack can be found in Section 2.3.1 of the
Literature Review. In the case of this project, a portscan will be carried out using Nmap, in
order to determine which ports are open and which services are running on the victim
machine.
3.3.2 Brute Force Dictionary Attacks
In order for an attacker to gain entry to a system, access to a valid user name and password
must first be acquired. This can be achieved in one of two ways, either by carrying out a
brute force attack which uses random combinations of all characters and can be very time
consuming or a dictionary attack which is a variation of a brute force attack but which uses
lists of commonly known user names and passwords (Whitman & Mattord, 2012), (Czagan,
2013). Further information about this type of attack can be found in Section 2.3.1 of the
Literature Review. In this instance, a dictionary attack will be carried out using Hydra against
the FTP, Telnet and HTTP protocols on the victim server.
3.4 Requirements Analysis
In order to carry out the aforementioned experiments, a network architecture will be created in
a cloud environment using different virtual machines. The victim server will have many open
services running on it including FTP, Telnet and HTTP and will be located in the DMZ. The
attacking machine will be located in the Private Network. Both machines will be configured
on different VLANs. In order to provide routing between the two machines and a firewall, a
virtual router will also be implemented. The attack tools required to carry out the information
gathering/probing attack and the brute force dictionary attacks will be installed on the
attacking machine. In order to detect the various threats, SIEM software will be installed on
the victim server for the purposes of real-time monitoring of various logs. An Intrusion
Detection System will also be installed on the victim server. Various tools, packages and
operating systems have been investigated and the most appropriate choices for the design
have now been selected.
Figure 11 provides an overview of the design and the steps that will be followed in order to
carry out the various experiments.

40096050 SOC10101
Figure 11: Design Overview
Various operating systems were considered for the victim server prior to the final selection
being made, however, as the majority of the logs that Splunk has the ability to monitor are
Windows logs such as Performance logs and Event Logs, it was decided that a Windows
Server would be the best option for the prototype implementation. Windows Server 2003 was
selected initially as the victim machine in the network architecture as it has many open
services; however, when attempting to download the SIEM software, it transpired that the
2003 Server was not of an adequate specification for it to be installed. Therefore, for the
purposes of these experiments, Windows Server 2008 is deemed to be the most appropriate
choice.
Again, different options were investigated in relation to the selection of the attacking
machine, including Metasploit and Kali Linux. Metasploit is open source penetration testing
software that is employed for the purposes of verifying vulnerabilities and to manage security
assessments (Metasploit, 2015). Kali Linux is an open source Linux distribution that is
designed for digital forensics, advanced penetration testing and security auditing and is
preinstalled with numerous penetration testing tools (Offensive Security, 2013). These tools
are divided into various categories such as Information Gathering which includes tools like
Nmap and Password Attacks which includes tools for online attacks like Hydra and Hydra
GTK. These tools make it an appropriate choice for the attacking host in the network
architecture.

40096050 SOC10101
In order to provide routing between the virtual machines and to provide a firewall for the
prototype implementation again, different options were considered. Vyatta is a virtual router
which provides advanced routing and security functionality for physical, virtual, and cloud
networking environments (Brocade, 2015). pfSense is an open source Firewall/Router
distribution which includes a web interface giving users the option to either configure it
through the command line or the GUI (pfSense, 2015). With both options, filtering can be
implemented using a variety of parameters such as source and destination IP address, IP
protocol and source and destination port (pfSense, 2015), (Brocade, 2015). As pfSense also
provides the option to log traffic, it has been decided that for the purposes of the dissertation,
it would be the most appropriate product to implement.
Following on from the above research, a design of the basic architecture required to facilitate
the various experiments has been created, as can be seen in Figure 12.
DMZ
Private Network
Kali
VLAN 205
Windows Server 2008
VLAN 206
VLAN 200Public Network eth0
eth1
eth2
Figure 12: Network Architecture – Design
3.5 Attack Tools
3.5.1 Nmap
According to Bace & Mell (2001), many different tools can be used for the purpose of
scanning and information gathering such as network mappers, port mappers, network
scanners, port scanners or vulnerability scanners to gain valuable information about a
network. Nmap, a well known and popular network mapper, is a free and open source utility
used by millions of people ranging from novices to highly skilled hackers. Nmap can be used
by attackers during the reconnaissance phase of an attack, to quickly scan a range of devices
in order to gain valuable information about the network and identify any potential
vulnerabilities or possible points of entry to the system (Lyon, 2009). Nmap can perform a
variety of scans however, for the purposes of this dissertation a port scan will be carried out in
order to identify which ports are open and which services are running on the victim machine.
Further information about Nmap can be found in Section 2.3.1 of the Literature Review.

40096050 SOC10101
3.5.2 Hydra
Hydra is an extremely fast logon cracker that can be used to attack many different protocols
including FTP, Telnet and HTTP and is therefore the tool of choice for carrying out the
dictionary attack. Further information about Hydra can be found in Section 2.3.1 of the
Literature Review. Both Hydra and Hydra GTK are installed on the Kali Linux virtual
machine and although Hydra GTK has a GUI that requires limited input from the user, it has
been decided that for the purposes of this dissertation, Hydra will be operated from the
command line. In order to carry out the dictionary attack, a file containing various common
usernames will be created as well as a password file containing the top most commonly used
passwords.
3.6 Detection Methods – An Overview
3.6.1 Intrusion Detection Systems (IDS)
‘Intrusion detection is the process of monitoring the events occurring in a computer system or
network and analysing them for signs of intrusions’ (Scarfone & Mell, 2007). In order to
detect the various threats that will be simulated as part of this project, one of the tools that
will be used is Snort. Snort is an open source IDS/IPS that is capable of real-time traffic
analysis, any suspicious activity detected by Snort is logged in an alerts file. Martin Roesch
(1999) refers to Snort as a “lightweight network intrusion detection tool” suited to monitoring
smaller scale networks. Snort is based on a set of rules that use pattern matching (signature
based detection) and comes preconfigured with a set of built in pre-processor rules that will
detect many forms of attack, however, it is also relatively easy to create new rules in order to
be able to adapt to new forms of attack. A combination of specifically created rules and pre-
processor rules will be implemented in order to detect the various threats.
3.6.2 SIEM
There are various SIEM products available on the market from different vendors such as
Hewlett Packard who offer ArcSight, IBM who offer Q1 Labs, AlienVault and Splunk all of
which differ slightly; however, the basic functions are the same (Karlzen, 2009).
As it is possible however to get an academic licence for Splunk and it has the capacity to
monitor a large variety of sources in real time, as can be seen from the following list of
options, it is the chosen SIEM for this dissertation:
 Local Event Logs – this option provides the ability to monitor Windows Event Logs
such as Application, Security, Setup and System
 Remote Event Logs - allows for the collection of event logs from remote hosts
 Files and Directories – ability to continuously monitor local files or entire directories
such as IDS logs or FTP and HTTP logs
 TCP/UDP – this option provides the ability to listen on any TCP or UDP port to
capture data sent over the network such as Syslog
 Local Performance Monitoring – ability to monitor Windows performance counters
such as CPU, Memory, Threads, FTP Service and HTTP Service
 Remote Performance Monitoring – gives the ability to collect performance metrics
on remote Windows machines

40096050 SOC10101
 Registry Monitoring – gives the ability to capture Windows Registry settings and
monitor the changes
 Active Directory – ability to watch for changes to the Active Directory and to collect
user and machine metadata such as user Additions, host changes and logins
 Local Windows host monitoring – gives the ability to collect up-to-date hardware
and software (computer, operating system, Processor etc) information about the local
machine
 Local Windows Network Monitoring – capture statistics about network activity
 Local Windows Print Monitoring – gives the ability to capture information about
printers, drivers, print jobs, and so on.
In order to see whether it is possible to detect the portscan and the brute force dictionary
attacks using a SIEM architecture, the following logs and fields were identified as being of
interest for the creation of the Splunk rules (Table 1).
Server/IDS Logs Fields of interest
Security Log Audit Failure, Audit Success
System Log Logon failure
FTP Log IP address
Response code 530 – failed login attempt
Response code 230 – successful login
Web Log (W3SVC1) POST
Snort Logs IP address
Port 21, Port 23, Port 80
Good login, Bad login
Table 1: Server/IDS logs and fields of interest for creating Splunk rules
3.7 Evaluation Metrics
As was ascertained by the literature review, in order for companies to successfully defend
against targeted attacks, organisations’ defences must incorporate firewalls, IDS/IPS and
SIEM (Orans, 2014). So as to determine the efficacy of a SIEM architecture for the purpose
of detecting and mitigating brute force dictionary attacks, two different experiments will be
performed.
3.7.1 Brute Force Dictionary Attack – Rapid Speed
The first experiment will see the brute force dictionary attacks being carried out at a rapid
speed. Hydra which is already installed on the Kali Linux virtual machine will be used to
carry out the brute force attacks. In order to detect the attacks, Snort and Splunk will be
installed on the Windows Server 2008 virtual machine. Splunk will be configured to actively
monitor Security logs, System logs, FTP logs, HTTP logs, FTP Service logs, HTTP service
logs and Snort logs. Snort will be run for the duration of the attacks using various rules that
will be created to detect both failed and successful login attempts to the FTP, Telnet and

40096050 SOC10101
HTTP services running on the Windows Server. Various Splunk rules will be created in order
to filter and analyse the log data, however, so as to obtain accurate results across the board, a
standard metric to detect over 100 failed logins in 10 seconds will be used.
3.7.2 Brute Force Dictionary Attack – ‘Low and Slow’
The implementation of the second experiment will be exactly the same as for the first,
however, as many brute force attacks are now being carried out at much slower speeds, with
highly experienced hackers spreading attacks over many hours, weeks or in some cases even
months (Lampe, 2011), in this instance the dictionary attacks will be carried out over a much
longer period of time, in effect, one password crack attempt will be made per minute. The
same standard metric will then be used in order to determine whether when these forms of
attack are carried out at a much slower speed, a SIEM architecture would still be effective.
3.8 Conclusions
The design of the network architecture required to carry out the experiments as outlined above
has been presented in this chapter, along with a brief summary as to why various design
choices were made. An overview of the attacks that will be simulated and a description of the
attack tools that are necessary to facilitate the experiments have also been provided. As the
aim of the dissertation is to determine whether it is possible to detect and therefore mitigate
scanning/information gathering attacks and brute force dictionary attacks using a SIEM
architecture, details of Intrusion Detection Systems and SIEM software have also been
supplied. Information has also been provided with regards to the various logs that will be
monitored and a number of fields of interest from said logs have also been identified for the
purposes of creating rules to filter and analyse the log data.
The final section of this chapter outlines the experiments that will be carried out in order to
determine the effectiveness of using a SIEM architecture to detect and mitigate both
scanning/information gathering attacks and brute force dictionary attacks. In order to afford a
comprehensive investigation, in the case of the brute force attacks, three different protocols
will be attacked at two different speeds. Finally, so as to obtain accurate results across the
board, a standard metric to detect over 100 failed logins in 10 seconds will be used in each
instance.

40096050 SOC10101
4 Implementation
4.1 Introduction
The design of the prototype SIEM architecture required to carry out and detect the
scanning/information gathering attack and the brute force dictionary attacks has been
illustrated in Chapter 3. Chapter 4 will examine in detail how the design was implemented in
a cloud environment using a series of virtual machines to create the required network
scenario. The Nmap and Hydra commands used to carry out the attacks, the Snort rules used
to detect the attacks and the Splunk rules that will be used to analyse and filter the log data
will be further explained.
4.2 Configuration
For the purposes of this implementation, VMware vSphere Client has been utilised to provide
a virtual cloud environment in which to create the prototype architecture. Three VMware
instances have been created, one of which as can be seen from the Figure 13 is a Windows
Server 2008 machine which will act as the victim in the implementation, another, the Kali
Linux, will act as the attacker in the scenario and finally, pfSense will provide the routing
between the two aforementioned machines and provide a firewall. The Windows Server has
been installed on VLAN 206 in the DMZ and the Kali Linux has been installed on VLAN 205
in the Private Network. In order to detect the attacks, Snort and Splunk have been installed on
the Windows Server 2008. Kali already comes complete with the attack tools necessary for
carrying out the various attacks; therefore, there was no requirement to download any
additional software to this instance. Figure 13 shows the configuration of the Prototype
Network.
Internet
DMZ
(VLAN 206)
Private (VLAN 205)
eth0
eth1
eth2
192.168.55.7/24 (Kali)
192.168.56.9/24
(Windows Server
2008)
192.168.56.254/24
192.168.55.254/24VLAN 200
Snort Logs
FTP Server Logs
Web Logs
Security Logs
System Logs
Performance Logs
Figure 13: Prototype Network Configuration

40096050 SOC10101
The configuration of the virtual machines is specified in Table 2.
Private Network
(Kali Linux)
DMZ
(Windows Server 2008)
IP Address
192.168.55.7 192.168.56.9
Subnet Mask
255.255.255.0 255.255.255.0
Default Gateway
192.168.55.254 192.168.56.254
Preferred DNS Server
10.200.0.1
Software Nmap
Hydra
Wireshark
Snort
Splunk
Table 2: Configuration of Virtual Machines
To enable routing between the above two virtual machines, the interfaces on pfSense were
configured as follows:
 WAN Interface (eth0) – DHCP
 LAN Interface (eth1) – 192.168.55.254
 DMZ Interface (eth2) – 192.168.56.254
So as to permit certain types of traffic between the Private Network and the DMZ, various
Firewall rules were created. In order to configure these rules, the pfSense GUI was accessed
via the browser on the virtual machine located in the Private Network by inputting the address
of the gateway (192.168.55.254). As can be seen in Figure 14, for the DMZ, ICMP traffic has
been permitted in order to check connectivity between the machines. TCP/UDP packets for
Port 53 (DNS) and TCP packets for port 80 (HTTP), 443 (HTTPS), 21 (FTP) and 23 (Telnet)
have also been allowed. It was necessary to permit traffic on ports 80 and 443 in order to gain
access to the Internet. For the purposes of the brute force dictionary attacks, it was also
necessary to permit traffic through ports 80, 21 and 23.
Figure 14: DMZ Firewall Rules

40096050 SOC10101
In the case of the LAN/Private Network, as can be seen in Figure 15, ICMP packets have also
been allowed to check connectivity. TCP packets for port 21 (FTP), port 80 (HTTP), port 443
(HTTPS) and port 23 (Telnet) have also been permitted to facilitate access to the Internet and
also for the purposes of the brute force dictionary attacks.
Figure 15: LAN/Private Network Firewall Rules
4.3 Attack Traffic
4.3.1 Scanning/Information Gathering Attack
Nmap is a network mapper that can be used by attackers during the reconnaissance phase of
an attack, to quickly scan a range of devices in order to gain valuable information about the
network and identify any potential vulnerabilities or possible points of entry to the system
(Lyon, 2009). Nmap can perform a variety of scans however, for the purposes of this
dissertation a port scan will be carried out in order to identify which ports are open and which
services are running on the victim machine. Figure 16 shows the command used to perform
the Nmap scan.
nmap 192.168.56.9
Figure 16: Nmap Port Scan command
4.3.2 FTP Brute Force Dictionary Attack
Hydra is an extremely fast logon cracker that can be used to attack many different protocols
including FTP, Telnet and HTTP. Prior to performing the FTP brute force dictionary attack,
two files were created, one containing various common user names such as Administrator,
Admin and Root and the other containing a list of the top most commonly used passwords.
Figure 17 shows the hydra command used to carry out the attack:
hydra -L /home/users.txt -P /home/passwords.txt -V -f 192.168.56.9 ftp
Figure 17: Hydra command - FTP Brute Force Attack

40096050 SOC10101
The Hydra syntax is broken down as follows:
-L denotes the use of a file containing a list of usernames
-P denotes the use of a file containing a list of passwords
-V specifies that the output of each attempt should be shown
-f specifies that the attack should stop once the correct user name and password has been
found
The IP address is that of the victim machine and FTP is the protocol that is being attacked.
4.3.3 Telnet Brute Force Dictionary Attack
In order to carry out the Telnet brute force dictionary attack, the same two files, users.txt and
passwords.txt are once again used. The Hydra syntax is also the same with the exception of
the protocol which in this instance is Telnet.
hydra -L /home/users.txt -P /home/passwords.txt -V -f 192.168.56.9 telnet
Figure 18: Hydra command - Telnet Brute Force Attack
4.3.4 HTTP Brute Force Dictionary Attack
To facilitate the HTTP dictionary attack, it was necessary to create a simple login form which
can be seen in Figure 19.
Figure 19: Login form
The hydra command used to carry out the brute force dictionary attack against the Web login
form is as follows:
hydra -l Administrator -P /home/passwords.txt -V -f 192.168.56.9 http-post-form
“/2.asp:username=^USER^&password=^PASS^:S=Welcome”
Figure 20: Hydra command - HTTP Brute Force Attack
The hydra syntax is broken down as follows:
-l denotes the user name in this case Administrator
-P denotes the use of a file containing a list of passwords in this passwords.txt
-V specifies that the output of each attempt should be shown

40096050 SOC10101
-f specifies that the attack should stop once the correct user name and password has
been found
Host 192.168.56.9 (victim server)
Method http-post-form
URL /2.asp (login page)
Form parameters - username=^USER^&password=^PASS^
Successful response – Welcome
4.3.5 Brute Force Dictionary Attacks – ‘Low and Slow’
In order to determine whether when carrying out the brute force dictionary attacks at a much
slower speed, it is still possible to detect the attacks using a SIEM architecture, the following
Hydra command has been created:
hydra -t 1 -L /home/users.txt -P /home/passwords.txt -V -f 192.168.56.9 ftp
Figure 21: Hydra command (slower speed) – FTP Brute Force Dictionary Attack
4.4 Detection Methods - IDS
4.4.1 Snort Rules – Scanning/Information Gathering Attack
One of the logs that will be directly monitored by Splunk is the IDS log, in this case, Snort.
Snort is capable of real-time traffic analysis and of detecting different types of attacks being
made on a network. Any suspicious activity detected by Snort will be logged in an alerts file.
Snort is based on a set of rules that use pattern matching (signature based detection) and
comes with a set of built in pre-processor rules that will suit many purposes. For the purposes
of detecting the Nmap portscan, the following preprocessor rule will be used:
preprocessor sfportscan: proto { all }
scan_type { all }
sense_level { high }
logfile { portscan.log }
Figure 22: Snort Preprocessor for detecting Port Scan
This rule is designed to detect all protocols (TCP, UDP, ICMP and IP) and all scan types;
portscan, portsweep, decoy portscan and distributed portscan. The final line of the rule
dictates that the results should be logged in the file portscan.log. In order to detect the
scanning/information gathering attack, Snort will be run on the Windows Server 2008
instance at the same time as the Nmap scan is being carried out by the attacking machine.

40096050 SOC10101
4.4.2 Snort Rules - FTP Brute Force Dictionary Attack
With the aim of creating a Snort rule that will detect the FTP brute force dictionary attack,
Wireshark was run at the same time that the attack was carried out. On examining the
network trace, it could be seen that response code 530 denoted a failed login attempt. This
information was then used to create the following Snort rule:
alert tcp any 21 -> any any (msg:”FTP Bad login”; content:”530 User”; nocase;
flow:from_server,established; sid:491;rev:5;)
Figure 23: Snort rule created to detect FTP failed login attempts
With the purpose of detecting the attacker logging in via FTP after having successfully
cracked the user name and password, the rule below was created. The rule in this instance
incorporates the 230 response code which denotes a successful login.
alert tcp any 21 -> any any (msg:”FTP Good login”; content:”230 User”; nocase;
Figure 24: Snort rule created to detect FTP successful login
4.4.3 Snort Rules - Telnet Brute Force Dictionary Attack
In order to create a Snort rule that will detect the Telnet brute force dictionary attack,
network trace, it could be seen that two different rules would need to be created to detect
failed login attempts, one that contains ‘logon failure’ and the other ‘No more connections’
which is the response generated by the server when too many connection attempts have been
made. Using this information, the following rules were created:
alert tcp any 23 -> any any (msg:”Telnet Failed Login attempt”; content:”Logon failure”; nocase;
sid:493;rev:5;)
Figure 25: Snort rule created to detect Telnet failed login attempts
alert tcp any 23 -> any any (msg:”Telnet Failed Login attempt”; content:”No more connections”;
nocase; sid:494;rev:5;)
Figure 26: Snort rule created to detect Telnet failed login attempts
To detect whether the attacker, on successfully having cracked the user name and password
logs in via Telnet, the following Snort rule was created:
alert tcp any 23 -> any any (msg:”Telnet login successful”; content:”Welcome”; nocase;
sid:495;rev:5;)
Figure 27: Snort rule created to detect successful login to Telnet

40096050 SOC10101
4.4.4 Snort Rules – HTTP Brute Force Dictionary Attack
In order to create a Snort rule that would detect the HTTP brute force dictionary attack,
network trace, it could be seen that all the failed login responses were PUSH ACKS
containing POST, being the attacker trying all different user names and passwords in the web
login form. Using this information, the following rule was created:
alert tcp any any -> any 80 (flags:PA; content:”POST”; msg:”HTTP failed login attempt”; sid:496;)
Figure 28: Snort rule created to detect HTTP failed login attempts
With the aim of detecting whether the attacker subsequently logs in to the Web form, the
following Snort rule was created:
alert tcp any 80 -> any any (msg:"HTTP successful username and password combination";
content:"Welcome "; nocase; flow:from_server,established; sid:497; rev:5;)
Figure 29: Snort rule created to detect successful login to Web login form
4.5 Detection Methods - SIEM
4.5.1 Splunk Logs
In order to determine whether by analysing and filtering log data from a variety of sources
and looking for specific patterns in the data, it is possible using a SIEM architecture to detect
information gathering attacks and FTP, Telnet and HTTP brute force dictionary attacks and
whether by identifying said patterns, it is therefore possible to block these attacks prior to
sensitive information being stolen or any damage being caused to the system, Splunk, the
chosen SIEM for this dissertation has been installed on the Windows Server virtual machine.
Splunk has the ability to monitor a large variety of sources in real time all of which were
mentioned in the Design Chapter. For the purposes of detecting the aforementioned attacks,
Splunk has been configured to actively monitor the following logs:
 Windows Event Logs – Security log and System log
 Windows Performance Monitor - FTP Service and HTTP Service
 Files and Directories – IDS logs, FTP logs and HTTP logs
4.5.2 Splunk Rules
In the Design Chapter, various fields from the above logs were identified as being of interest
for the purposes of detecting the above attacks. On the basis of those fields, the following
Splunk rules have been created:

40096050 SOC10101
Log Splunk Rules Expected Result
Security sourcetype="wineventlog:security" audit failure An account failed to logon
sourcetype="wineventlog:security" audit failure 4625 An account failed to logon
sourcetype="wineventlog:security" audit success
An account was successfully logged
on
sourcetype="wineventlog:security" audit success 4624 An account was successfully logged
on
System sourcetype="wineventlog:system" logon failure 100 Server unable to logon Administrator
FTP
sourcetype=iis c_ip=* sc_status=530 Returns failed logon attempts from
any IP address
sourcetype=iis c_ip=* sc_status=530 | stats count by c_ip Returns total number of failed logons
and IP address
sourcetype=iis c_ip=* sc_status=230 Returns good logons
sourcetype=iis c_ip=* sc_status=230 | stats count by c_ip Returns number of successful logons
and IP address
sourcetype=”perfmon:ftp service” total logon attempts Returns the total number of logon
attempts to the FTP service
HTTP
sourcetype="iis" cs_method=POST Shows all attempts to try to login to
Web login form
Snort
sourcetype=portscan-too_small portscan src_ip=* Detects portscan and returns source
ip address
sourcetype="snort" bad login src_ip=* Returns any IP addresses generating
failed logins
sourcetype="snort" bad login src_port=21 Returns bad login attempts for port
21

40096050 SOC10101
sourcetype="snort" bad login sourceip =* | stats count by sourceip | search
count >100 Returns any IP addresses generating
over 100 failed login attempts
count >100 | bucket span=10s _time
Returns any IP addresses generating
over 100 failed login attempts within
10 seconds
count >20 | bucket span=10s _time
over 20 failed login attempts within
10 seconds
sourcetype="snort" good login sourceip=* Returns good logins from any IP
address
sourcetype="snort" src_port=23 failed login src_ip=* | stats count by src_ip
Returns IP addresses and number of
failed login attempts to port 23
sourcetype="snort" dest_port=80 HTTP failed login attempt | stats count by
dest_ip | search count>100 | bucketspan=10seconds_time
over 100 failed login attempts in 10
seconds to port 80
Table 3: Splunk Rules

40096050 SOC10101
4.6 Conclusion
As can be seen from the above, a prototype SIEM architecture has now been successfully
created using VMware vSphere client and a selection of virtual machines. A list of all the
software used in the implementation is shown in Table 4. Nmap and Hydra commands have
been created in order to carry out the attacks, Snort rules have been created to detect the
attacks and Splunk has been configured to monitor in real-time the Security logs, System logs,
Server logs and IDS logs.
The aim of this dissertation is to determine whether by analysing and filtering log data from a
specific patterns in the data, it is possible using a SIEM architecture to detect
attacks and whether by identifying said patterns, it is therefore possible to mitigate these
attacks. As the Implementation chapter has now shown, with the implementation of the SIEM
architecture and the creation of the Nmap and Hydra commands and the Snort and Splunk
rules, the aim of this project has therefore now been met in part. However, so as to
completely satisfy the dissertation aim, the attacks must now be carried out and the log data
analysed and filtered using the Splunk rules in order to determine whether it is in fact possible
to detect and therefore block these attacks. The next chapter will provide an evaluation of the
experiments carried out.
Software Purpose
Splunk SIEM product used to collect and analyse log
data
Snort Used to detect Information Gathering/Probing
Attack and Brute Force Dictionary Attacks
Nmap Used to carry out Information
Gathering/Probing Attack
Hydra Used to carry out Brute Force Dictionary
Attacks
Table 4: Software used in Implementation

40096050 SOC10101
5 Evaluation
5.1 Introduction
Following on from the implementation of the network architecture and the creation of the
attack commands, Snort rules and Splunk rules, this chapter will see various experiments
being carried out with the intention of establishing whether it is possible using a SIEM
architecture to detect and therefore mitigate scanning/information gathering attacks and brute
force dictionary attacks. In relation to the brute force attacks, two different experiments will
be performed. The first experiment will see the brute force dictionary attacks being carried out
at a rapid speed; whereas for the second experiment, the attacks will be simulated at a much
slower speed. In order to afford a comprehensive investigation, in the case of the brute force
attacks, three different protocols will be attacked; FTP, Telnet and HTTP. Finally, so as to
obtain accurate results across the board, a standard metric to detect over 100 failed logins in
10 seconds will be applied in each instance.
5.2 Experiments
For the purpose of these experiments, Splunk is set to monitor in real time the Security log,
System log, FTP Service, HTTP Service, IDS log, FTP logs and HTTP logs on the Windows
Server virtual machine. Snort is also run on the Windows Server VM for the duration of the
attacks using the rules as previously identified in the Implementation chapter.
5.2.1 Information Gathering/Probing Attack
The first attack to be carried out is the information gathering/probing attack which is run
using the following command:
nmap 192.168.56.9
Figure 30: Nmap Port Scan command
In order to detect the attack, Snort is run at the same time using the following preprocessor
rule:
preprocessor sfportscan: proto { all }
scan_type { all }
sense_level { high }
logfile { portscan.log }
Figure 31: Snort preprocessor to detect Port Scan

40096050 SOC10101
As can be seen from Figure 32, the Nmap portscan has identified various open ports and a
number of services running on the Windows Server 2008 virtual machine, including FTP,
Telnet and HTTP. Figure 33 shows that the portscan was detected by Snort and the result
subsequently logged.
Figure 32: Results of Port Scan
Figure 33: Snort Alert for Port Scan
5.2.2 FTP Brute Force Dictionary Attack
In order to carry out the FTP brute force dictionary attack, the following command is run:
hydra -L /home/users.txt -P /home/passwords.txt -V -f 192.168.56.9 ftp
Figure 34: Hydra command - FTP Brute Force Dictionary attack
In order to detect the attack, Snort is run in parallel using the following rule where response
code 530 denotes a failed login attempt:
alert tcp any 21 -> any any (msg:”FTP Bad login”; content:”530 User”; nocase;
Figure 35: Snort rule to detect FTP failed login attempts

40096050 SOC10101
It can be seen from Figure 36 that the hydra attack was successful and that a valid user name
(Administrator) and a valid password (Admin2015) were indeed found.
Figure 36: Result of FTP Brute Force Attack
As can be seen from the alerts file in Figure 37, it can be determined that unsuccessful login
attempts were in fact detected by Snort and subsequently logged.
Figure 37: Snort Alert for FTP failed login attempts
In order to determine whether the attacker subsequently logs in to the FTP service, the
following snort rule was used where response code 230 denotes a successful login:
alert tcp any 21 -> any any (msg:”FTP Good login”; content:”230 User”; nocase;
Figure 38: Snort rule to detect FTP successful login
The screenshot below shows the attacking machine (Kali) successfully logging into the FTP
service on the victim machine (Windows Server 2008).
Figure 39: Successful login to FTP service
In the final screenshot, it can be seen that a successful login for user Administrator was in fact
detected by Snort and subsequently logged.
Figure 40: Snort Alert for FTP successful login

40096050 SOC10101
5.2.3 Telnet Brute Force Dictionary Attack
So as to simulate the Telnet brute force dictionary attack, the following command is run:
hydra -L /home/users.txt -P /home/passwords.txt -V -f 192.168.56.9 telnet
Figure 41: Hydra command – Telnet Brute Force Dictionary attack
In order to detect the attack, Snort is run in parallel using the following rules:
alert tcp any 23 -> any any (msg:”Telnet Failed Login attempt”; content:”Logon failure”; nocase;
sid:493;rev:5;)
Figure 42: Snort rule to detect Telnet failed login attempts
alert tcp any 23 -> any any (msg:”Telnet Failed Login attempt”; content:”No more connections”;
nocase; sid:494;rev:5;)
Figure 43: Snort rule to detect failed login attempts
It can be seen from Figure 44 that the Hydra attack was once again successful and that a valid
user name (Administrator) and a valid password (Admin2015) were found.
Figure 44: Result of Telnet Brute Force Attack
As can be seen from the screenshot below, failed logon attempts to the Telnet server were
detected by Snort and logged accordingly. It was determined however upon investigating the
alerts file that only the Snort rule containing “No more connections” actually worked which
potentially means that many more login attempts were actually made but not logged.
Figure 45: Snort Alert for Telnet failed login attempts
In order to determine whether the attacker subsequently logs in via Telnet, the following Snort
rule was used:
alert tcp any 23 -> any any (msg:”Telnet login successful”; content:”Welcome”; nocase;
sid:495;rev:5;)
Figure 46: Snort rule to detect successful login via Telnet

40096050 SOC10101
As can be seen from Figure 47, the attacking machine (Kali) successfully logs into the Telnet
service on the victim machine.
Figure 47: Successful login to Telnet service
In the final screenshot, it can be seen that a successful login for user Administrator was in fact
detected by Snort and subsequently logged.
Figure 48: Snort Alert for Telnet successful login
5.2.4 HTTP Brute Force Dictionary Attack
In order to carry out the HTTP brute force dictionary attack, the following command is run
where /2.asp is the location of the Web login page:
hydra -l Administrator -P /home/passwords.txt -V -f 192.168.56.9 http-post-form
“/2.asp:username=^USER^&password=^PASS^:S=Welcome”
Figure 49: Hydra command – HTTP Brute Force Dictionary Attack
In order to detect the attack, Snort is run at the same time using the following rule:
alert tcp any any -> any 80 (flags:PA; content:”POST”; msg:”HTTP failed login attempt”; sid:496;)
Figure 50: Snort rule to detect HTTP failed login attempts
As can be seen from the screenshot below, the dictionary attack was successful; one valid
password was found (Administrator). It should be noted however that prior to obtaining this
result, the password file had to be altered to remove ‘Welcome’ as this was previously also
found to be a valid password. This suggests that there is either something wrong with the
code that was used to create the Web login form or something amiss with the format of the
hydra command. At this point, it has not been possible to identify the exact nature of the
problem.

40096050 SOC10101
Figure 51: Result of HTTP Brute Force Attack
As can be seen from the screenshot below, failed attempts to login to the Web page were
detected by Snort and logged accordingly.
Figure 52: Snort Alert for HTTP failed login attempts
In order to determine whether the attacker subsequently logs in to the Web login form, the
following Snort rule was used:
alert tcp any 80 -> any any (msg:"HTTP successful username and password combination";
content:"Welcome "; nocase; flow:from_server,established; sid:497; rev:5;)
Figure 53: Snort rule to detect successful login to Web login form
Figure 54 shows the attacker successfully logging in to the Web login page as Administrator.
Figure 54: Successful login to Web Page
In the final screenshot, it can be seen that a successful user name and password combination
was detected by Snort and subsequently logged. The message ‘Welcome Administrator’ can
be seen in the content of the logged packet.

40096050 SOC10101
Figure 55: Snort Alert for successful login to Web login form
5.2.5 Brute Force Dictionary Attacks – ‘Low and Slow’
According to Lampe (2011), many brute force attacks are now being carried out at slower
speeds, with highly experienced hackers spreading attacks over many hours, weeks or in some
cases even months. In order to determine whether when carrying out the brute force
dictionary attacks at a much slower speed, it is still possible to detect the attacks using a
SIEM architecture, the following Hydra command was considered:
hydra -t 1 -L /home/users.txt -P /home/passwords.txt -V -f 192.168.56.9 ftp
Figure 56: Hydra command (slower speed) – FTP Brute Force Dictionary Attack
The above command however, does not provide a reasonable comparison to an attacker
attempting for example a single password crack in a minute. In order to do this, it was
necessary to manually try different passwords at a rate of one per minute.
5.3 Results
5.3.1 Scanning/Information Gathering Attack
Once all the attacks had been carried out, the Splunk rules that had been created in the
Implementation chapter were applied to the data in order to attempt to detect the attacks and
identify the attacker.
Figure 57, shows that it was possible to detect the portscan using a simple filtering rule and
that the IP address of the attacking machine is identified as 192.168.55.7.

40096050 SOC10101
Figure 57: Splunk – Detection of Port scan
5.3.2 Brute Force Dictionary Attacks
For the purposes of detecting the rapid speed and ‘Low and Slow’ brute force dictionary
attacks and to provide accurate results across the board, the following rule was created to
search for any IP address generating over 100 failed login attempts within a 10 second time
period:
sourcetype="snort" failed login src_ip =* | stats count by src_ip | search count >100 | bucket
span=10s _time
Figure 58: Splunk rule created to detect over 100 failed logins in 10 seconds
The Splunk Timeline below indicates that there were 1,935 failed login attempts to the FTP
service within approximately 10 seconds. It is possible to identify the IP address of the
attacking machine (192.168.55.7) by opening the Statistics tab.
Figure 59: Splunk Timeline for FTP Brute Force Dictionary Attack

40096050 SOC10101
As can be seen from Figure 60, when the same filtering rule is applied, this time stating the
source port as 23 (Telnet), 2,080 failed login attempts were identified within approximately
10 seconds.
Figure 60: Splunk Timeline for Telnet Brute Force Dictionary Attack
Once again, the same filtering rule is applied to the data, this time stating destination port 80
(HTTP). The Timeline below indicates in this instance 327 failed login attempts over an
approximate time period of 10 seconds.
Figure 61: Splunk Timeline for HTTP Brute Force Dictionary Attack

40096050 SOC10101
In order to see if it was possible to detect a brute force dictionary attack that was carried out
over a much longer period, the same filtering rule was applied to the data to search for over
100 failed login attempts over the course of a 10 second time span. As can be seen from
Figure 62, no results were found, indicating that it is possible for ‘Low and Slow’ attacks to
go undetected if the same principles are applied.
Figure 62: Splunk results for ‘Low and Slow’ FTP Brute Force Dictionary Attack
To summarise the above, Table 5 provides a synopsis of the detection results for both the
‘Rapid Fire’ attacks and the ‘Low and Slow’ attacks.
Protocol and Speed of Attack Detection Results
FTP – Rapid Fire 1,935 failed login attempts detected
Telnet – Rapid Fire 2,080 failed login attempts detected
HTTP – Rapid Fire 327 failed login attempts detected
FTP – ‘Low and Slow’ Zero failed login attempts detected
Table 5: Detection Results
5.4 Analysis
Figure 58 shows that it was in fact possible to detect the scanning/information gathering
attack; however, as it was only in fact detected in the IDS logs, it would not be necessary to
implement a SIEM architecture in this instance. It can be seen from Figure 59, 60 and 61 that
when carrying out the brute force dictionary attacks at a rapid speed and using a standard
metric to detect over 100 failed logins in 10 seconds, that by using a SIEM architecture it is in
fact possible to detect the attacks. Moreover, once the Splunk rule has been created, it is
possible to set up an alert thereby making it possible to mitigate these forms of attack prior to
sensitive information being stolen or damage being caused to the system. However, when the
attacks are carried out at a much slower speed, as in one password try per minute and the
same rule is applied, as can be seen from Figure 62, it was not possible to detect the attacks by
carrying out a real-time analysis of the data. This does not however mean that a SIEM

40096050 SOC10101
architecture would not be an appropriate method for detecting ‘Low and Slow’ attacks, it
merely shows that for successful detection, data would have to be collected and analysed over
a much longer period of time than for attacks that are carried out at a much faster rate. One
issue that should be noted in relation to the experiments is that as only attack traffic was being
generated, the scenario itself is not altogether realistic. In a real life environment, normal
users would also at times generate failed logins, so for example if a rule was used to search
for in the case of FTP, response code 530, all failed logins would be identified not just those
from an attacker, leading to false positives being generated.
5.5 Conclusions
As can be seen from the diagrams in Section 5.3, it was possible to detect brute force
dictionary attacks against FTP, Telnet and HTTP protocols by analysing the data and applying
various filtering rules. Therefore, it could be concluded that it is possible to detect and
mitigate these types of attacks using a SIEM architecture. However, when the attack was
carried out at a much slower speed with only one login attempt being made per minute and the
same rule was applied to search for over 100 failed logins in 10 seconds, a standard metric for
detecting brute force attacks, the attacks were in fact not detected. This does not however
mean that a SIEM architecture would not be an appropriate method for detecting ‘Low and
Slow’ attacks, it merely shows that for successful detection, data would have to be collected
and analysed over a much longer period of time than for attacks that are carried out at a much
faster rate.

40096050 SOC10101
6 Conclusions
6.1 Introduction
The aim of this dissertation was to determine whether by analysing and filtering log data from
a variety of sources; Security logs, System logs, Server logs and Snort logs and looking for
specific patterns in the data, it was possible using a SIEM architecture to detect
attacks and whether by identifying said patterns, it would therefore be possible to block these
The results presented in the previous chapter have shown that it is in fact possible to detect
and mitigate these attacks using a SIEM architecture, therefore, the aim of this dissertation
has been met.
Section 6.2 of this chapter will examine how the six main objectives of this dissertation were
met. There follows in Section 6.3 a critical analysis of the network architecture and the
experiments that were carried out and finally in Section 6.4, future work that could be carried
out in relation to the subject covered in this dissertation is covered.
6.2 Meeting the Objectives
Chapter 1 outlined the six main objectives that were required to be met in order to complete
this dissertation. These objectives are listed below:
1. Research and review Attack Taxonomies covering topics such as Cyber Adversaries,
Classification of Attacks and Attack Patterns. Further research and review Defence in
Depth, Big Data Analytics and SIEM.
2. Design and implement a prototype SIEM architecture.
3. Simulate brute force dictionary attacks against multiple protocols, and import log data
from a variety of sources into a SIEM software package and carry out an analysis of
the data.
4. Evaluate whether it is possible by identifying certain patterns in the data, to detect and
therefore block the attack, and whether when carrying out the attacks at a much slower
speed, it is still possible to detect the attacks.
6.2.1 Objective 1
The first objective of this dissertation was met by initially presenting an Attack Taxonomy
which reviewed several topics including; a history of cyber adversaries, classification of
attacks which incorporated information on scanning/information gathering attacks and brute
force attacks and attack patterns which showed the various stages one can expect an attack to
go through. The literature review then examined how a defence in depth approach provides
organisations with the best means of defending against cyber threats and finally, there
followed a review of defence mechanisms; Intrusion Detection Systems, Big Data Analytics
and SIEM. Here it was shown that although the traditional security measures of Intrusion
Detection Systems and Intrusion Prevention Systems are inadequate when it comes to
detecting and preventing more complex attacks, big data analytics with the ability to collect

40096050 SOC10101
and analyse data over a long period of time provides a solution to this problem. It was
subsequently concluded that in order to prevent, detect and predict today’s more complex
attacks a security strategy which incorporates Firewalls, Intrusion Detection Systems and
SIEM, with the ability to analyse large data sets, is required.
6.2.2 Objective 2
The second objective to be met was to design and implement a prototype SIEM architecture
which based on the conclusion reached in the literature review should incorporate a Firewall,
an Intrusion Detection System and SIEM software. This was achieved by using VMware
vSphere Client which provided a virtual cloud environment in which to create the prototype
architecture. Three VMware instances were subsequently created, one of which was a
Windows Server 2008 machine which acted as the victim in the implementation, another, the
Kali Linux, which acted as the attacker in the scenario and finally, pfSense which provided
the routing between the two aforementioned machines and a firewall. In order to detect the
attacks, Snort which was the chosen IDS for the dissertation and Splunk which was the
chosen SIEM product were installed on the Windows Server 2008. As Kali already comes
complete with the attack tools that were necessary to carry out the various attacks, there was
no requirement to download any additional software to this instance.
6.2.3 Objective 3
The third objective to be met was to simulate brute force dictionary attacks against multiple
protocols and import log data from a variety of sources into a SIEM software package and
carry out an analysis of the data. To achieve this objective, initially, two files were created,
one containing various common user names such as Administrator, Admin and Root and the
other containing a list of the top most commonly used passwords. Different Hydra commands
were then created in order to carry out the attacks against the FTP, Telnet and HTTP
protocols. The attacks were then carried out, with Hydra successfully cracking the user
names and passwords in each instance. In relation to importing the log data, various logs had
been examined in order to identify which would be the most appropriate for detecting the
brute force dictionary attacks and it was determined from this investigation that real-time
monitoring of the following logs would be necessary:
 Windows Event Logs – Security log and System log
 Windows Performance Monitor - FTP Service and HTTP Service
 Files and Directories – IDS logs, FTP logs and HTTP logs
Various fields from the above logs were identified as being of interest for the purposes of
detecting the brute force attacks and on the basis of those fields, a number of Splunk rules
were created in order to analyse and filter the data.
6.2.4 Objective 4
The final objective to be met in order to fulfil the requirements of the dissertation was to
evaluate whether it is possible by identifying certain patterns in the data, to detect and
therefore block the attacks, and whether when carrying out the attacks at a much slower
speed, it is still possible to detect the attacks. In order to achieve the first part of this
objective, it was decided that a standard metric would be applied to the data which was to
detect over 100 failed logins in 10 seconds. This filtering rule was then applied to the data
with slight modifications in order to make it applicable to each of the three protocols; FTP,

40096050 SOC10101
Telnet and HTTP. In each instance, the attacks were detected. Once it had been identified
that the attacks could be detected using Splunk, it was then possible to set up an alert whereby
a message would be sent to the Administrator stating that a brute force attack was in progress
whereupon action could be taken to block the attack prior to sensitive information being
stolen or any damage being caused to the system.
In order to meet the second part of this objective, Hydra was considered to once again
simulate the attacks, however, it was established that this did not provide a reasonable
comparison to an attacker attempting for example a single password crack in a minute. It was
decided therefore that in order to accomplish this, it was necessary to manually try different
passwords at a rate of one per minute. Again, in order to obtain accurate results across the
board, the same metric was applied, to detect over 100 failed logins in 10 seconds. When the
same filtering rule was applied to the data, however, no results were found indicating that it is
possible for ‘Low and Slow’ attacks to go undetected if the same principles are applied.
6.3 Critical Analysis
As can be seen from the above, the aim and objectives of this dissertation have been met.
This section will provide a critical analysis of the prototype SIEM architecture and the
experiments that were carried out.
One issue associated with the experiments themselves, is that only attack traffic was being
generated, therefore, the scenario itself is not altogether realistic. In a real life environment,
normal users would also at times generate failed logins, so for example if a rule was used to
search for in the case of FTP, response code 530, all failed logins would be identified not just
those from an attacker, leading to false positives being generated. It would therefore be
imperative that when looking for this type of attack that a baseline was set as to how many
failed logins were acceptable and a filtering rule created accordingly. Also, in a real life
environment, users would normally be locked out of a system after a certain number of
attempts to login had been made. This in itself would prevent a ‘rapid fire’ attack, however,
would not work in the event that the attacker carried out the brute force attack over a much
longer period of time.
Another limitation to the experiments in relation to the ‘Low and Slow’ brute force attacks is
that it was not possible to determine fully whether in fact using a SIEM architecture would
actually be beneficial in detecting this form of attack. As attackers are now taking weeks and
even months to carry out these forms of attack, it was simply not feasible given the length of
time available for the dissertation to simulate this type of attack. This does not however mean
that a SIEM architecture would not be an appropriate method for detecting ‘Low and Slow’
attacks, it merely shows that for successful detection, data would have to be collected and
analysed over a much longer period of time than for attacks that are carried out at a much
faster rate.
Another issue with the experiments is that in the case of the Telnet attack and the portscan,
the only logs that were in fact used to identify the attacks were IDS logs, this was down to the
fact that no other logs from the Windows Server 2008 virtual machine could be identified that
would provide information that would be relevant to detecting these forms of attack. As Snort
itself has a built in preprocessor to detect scanning attacks, SIEM software is not in fact
necessary in this case.

40096050 SOC10101
There are also strengths that should be mentioned in relation to the prototype architecture and
the experiments. In order to provide a comprehensive study, three different protocols were
attacked. Each of these attacks was subsequently detected by applying a standard filtering
rule to detect over 100 failed logins within 10 seconds to the data. Also, different filtering
rules containing response codes in the case of FTP and methods in the case of HTTP were
created in order to ensure that it was possible to detect the brute force dictionary attacks using
log data from a variety of sources such as Security logs, System logs and Server logs, thereby
proving that an architecture incorporating a Firewall, an Intrusion Detection System and
SIEM software does in fact offer the capability to detect these forms of attack.
6.4 Future Work
According to Lampe (2011), many brute force attacks are now being carried out at slower
speeds, with highly experienced hackers spreading attacks over many hours, weeks or in some
cases even months, further research into this subject area is therefore essential in order to
simulate this form of attack and to furthermore analyse the data over a much longer period of
time in order to prove that SIEM does have the capacity to detect these ‘Low and Slow’ forms
of attack.
In order to prove that a SIEM architecture offers protection from all types of brute force
attacks, further research is also required with regards to botnets being used to carry out these
forms of attack. Vykopal (2013) proposes two categories of brute force attacks, simple or
distributed. In simple attacks, all the authentication attempts come from a single host,
whereas with distributed attacks, many different hosts initiate a much smaller number of
authentication requests thus making the attack much more problematical to detect. Anon
(2013) goes on to say that brute force attacks are now being carried out where not only are the
IP addresses of the attackers different, but that individual password crack attempts are also
coming from different countries. This would certainly be a much more complex scenario to
implement, however, certainly one that should be investigated.
6.5 Personal Reflection
This was the first time I had ever had to read a lot of peer reviewed research papers and at
times, I found some of them difficult to understand, however, the more I read and the more I
learned about each topic, the easier I found it and the more interested I became in the subject
as a whole. Also, when I initially started to write the Literature Review, I found it difficult to
put another person’s work into my own words, however, as time progressed, I found it much
easier and I think my writing has much improved since the start of my dissertation.
I completed various practical labs from the Security Testing and Advanced Network
Forensics module which were extremely useful when it came to designing and implementing
the SIEM architecture. Having completed the Security and Forensics module the previous
year, where we had covered IDS and in particular Snort, also proved to be extremely
beneficial when it came to creating the Snort rules to detect the various attacks. One area I
knew absolutely nothing about initially, was Splunk, however, through research and carrying
out the Splunk tutorials, I found it relatively easy to design the rules that were required to
analyse the data.
The final area to be discussed in this section is with regards to Project Management. I
consider that on the whole, I managed the project extremely well. A Gantt chart was created
at the beginning of the project and although there were a few deviations from the time plan,

40096050 SOC10101
the dissertation was completed within the time frame originally indicated. Diary sheets were
initially created on a regular basis, giving me a clear indication of what needed to be done
each week, however, it has to be said that laterally this process fell by the wayside as the
project progressed. I also ensured throughout the project to either meet with my Supervisor or
to speak over Skype on a regular basis in order to keep him up to date with my progress and
to get advice with regards to any improvements that could be made to my work.

40096050 SOC10101
7 References
Afzaal, M. et al., 2012. A Resilient Architecture for Forensic Storage of Events in Critical
Infrastructures. In High-Assurance Systems Engineering (HASE) - IEEE 14th International
Symposium. s.l., IEEE.
Andress, J. & Winterfield, S., 2014. Computer Network Defense. In: C. Katsaropoulos & B.
Rearick, eds. Cyber Warfare (Second Edition). Waltham, MA: Elsevier Inc, pp. 193-205.
Anon., 2013. FTP Brute Force Attacks?. [Online]
Available at: http://blog.unmaskparasites.com/2013/06/26/ftp-brute-force-attacks/
[Accessed 4 April 2015].
Bace, R. & Mell, P., 2001. NIST Special Publication on Intrusion Detection Systems, s.l.:
NIST.
Barnum, S. & Sethi, A., 2007. Attack Patterns as a Knowledge Resource for Building Secure
Software, s.l.: Citital Inc.
British Computer Society, 2011. Code of Conduct for BCS Members. [Online]
Available at: http://www.bcs.org/upload/pdf/conduct.pdf [Accessed 11 November 2014].
Brocade, 2015. Brocade - Vyatta 5400 vRouter. [Online]
Available at: http://www.brocade.com/products/all/network-functions-virtualization/product-
details/5400-vrouter/index.page [Accessed 9 March 2015].
Brown, T. J. R. R. N. D., 2003. System and method for authenticating users in a computer
network. Washington DC, United States of America, Patent No. 6,618,806.
Brust, A., 2012. Cloudera and Mount Sinai: The structure of a Big Data Revolution. [Online]
Available at: http://www.zdnet.com/cloudera-and-mount-sinai-the-structure-of-a-big-data-
revolution-7000000354/ [Accessed 14 October 2014].
Buchanan, W. J., 2011. Introduction to Security and Network Forensics. s.l.:Auerbach
Publishers Inc..
Buchanan, W. J., 2014. SIEM. s.l.:s.n.
Chantler, N., 1996. Profile of a Computer Hacker, Queensland: Faculty of Law, Queensland
University of Technology.
Chin-Chuan, H., 2003. Personal authentication using palm-print features. Pattern recognition,
36(2), pp. 371-381.
Collins, M. P., Gates, C. & Kataria, G., 2006. Proceedings of the Fifth Workshop on the
Economics of Information Security: A Model for Opportunistic Network Exploits: The Case of
P2P Worms, Cambridge: s.n.
Cozza, J., 2014. Top Tech News: Network Security. [Online]
Available at: http://www.toptechnews.com/article/index.php?story_id=010000CF3AV4
[Accessed 5 October 2014].

40096050 SOC10101
Curry, S. et al., 2011. RSA Security Brief: Mobilizing Intelligent Security Operations for
Advanced Persistent Threats. [Online] Available at: http://www.emc.com/collateral/industry-
overview/11313-apt-brf.pdf [Accessed 16 October 2014].
Czagan, D., 2013. Infosec Institute: Online Dictionary Attack with Hydra. [Online]
Available at: http://resources.infosecinstitute.com/online-dictionary-attack-with-hydra/
[Accessed 23 February 2015].
Dalal, A., 2012. Advanced Persistent Threat (APT): A Buzzword or an Immenent Threat?. Las
Vegas: ISACA.
de Vivo, M., Carrasco, E., Isern, G. & de Vivo, G. o., 1999. A review of port scanning
techniques. ACM SIGCOMM Computer Communication Review , 29(2), pp. 41-48.
Drasar, M., 2013. Protocol-Independent Detection of Dictionary Attacks. In: Advances in
Communication Networking. Heidelberg: Springer, pp. 304-309.
Furnell, S., 2002. Cybercrime: vandalizing the information society. Boston: Addison-Wesley.
Gantz, J. & Reinsel, D., 2012. The Digital Universe in 2020: Big Data, Bigger Digital
Shadows, and Biggest Growth in the Far East, s.l.: IDC IVIEW: IDC Analyze the Future.
Garofalo, A. et al., 2014. Closing the loop of SIEM analysis to Secure Critical Infrastructures,
s.l.: arXiv:1405.2995.
Gartner, 2013. Prevention is Futile in 2020: Protect Information Via Pervasive Monitoring
and Collective Intelligence. [Online] Available at:
http://www.gartner.com/document/2500416 [Accessed 3 January 2015].
Gartner, 2014. Designing an Adaptive Security Architecture for Protection From Advanced
Attacks. [Online] Available at: http://www.gartner.com/doc/2665515/designing-adaptive-
security-architecture-protection [Accessed 3 January 2015].
Giura, P. & Wang, W., 2013. Using Large Scale Distributed Computing to Unveil Advanced
Persistent Threats. SCIENCE, 1(3), pp. pp-93.
Gordon, S., 2002. Virus writers: the end of innocence, s.l.: s.n.
Grzinic, T., Kisasondi, T. & Saban, J., 2013. Detecting anomalous Web server usage through
mining of access logs in Central European Conference on Information and Intelligent
Systems. s.l., s.n.
Hansman, S. & Hunt, R., 2004. A taxonomy of network and computer attacks. Computers &
Security, 24(1), pp. 31-43.
Hernando, S., 2014. Method and System for Improving Security Threats Detection in
Communication Networks. United States, Patent No. US 2014/0223555 A1.
Hollows, P., 2002. eSecurity Planet: Security Threat Correlation: The Next Battlefield.
[Online] Available at: http://www.esecurityplanet.com/views/article.php/1501001/Security-
Threat-Correlation-The-Next-Battlefield.htm [Accessed 9 January 2015].
Karlzen, H., 2009. An Analysis of Security Information and Event Management Systems, s.l.:
s.n.
Krebs, B., 2013. Krebs on Security: In-depth security news and investigation. [Online]
Available at: http://krebsonsecurity.com/2013/10/adobe-breach-impacted-at-least-38-million-
users/ [Accessed 5 October 2014].

40096050 SOC10101
Lampe, J., 2011. How to Detect and Prevent "Low and Slow" Brute Force Attacks. [Online]
Available at: http://www.filetransferconsulting.com/how-to-detect-and-prevent-low-and-
slow-brute-force-attacks/ [Accessed 4 April 2015].
Landreth, B. & Rheingold, H., 1985. Out of the Inner Circle: a Hacker's Guide to Computer
Security. Bellevue, Washington: Microsoft Press.
Laney, D., 2001. 3D Data Management: Controlling Data Volume, Velocity, and Variety,
Stamford: Meta Group Inc.
Lawson, L., 2001. You say cracker; I say hacker: a hacking lexicon. [Online]
Available at: http://www.techrepublic.com/article/you-say-cracker-i-say-hacker-a-hacking-
lexicon/ [Accessed 8 October 2014].
Lough, D. L., 2001. A taxonomy of computer attacks with applications to wireless networks,
s.l.: s.n.
Lyon, G., 2009. Nmap Security Scanner. [Online]
Available at: http://nmap.org/ [Accessed 23 February 2015].
Manyika, J. et al., 2011. Big data: The next frontier for innovation, competition, and
productivity, s.l.: McKinsey Global Institute.
McNulty, E., 2014. Understanding Big Data: The Seven V's. [Online]
Available at: http://dataconomy.com/seven-vs-big-data/ [Accessed 9 February 2015].
Metasploit, 2015. Metasploit - World's most used penetration testing software. [Online]
Available at: http://www.metasploit.com/ [Accessed 9 March 2015].
Meyers, C., Powers, S. & Faissol, D., 2009. Taxonomies of Cyber Adversaries and Attacks: A
Survey of Incidents and Approaches, s.l.: Lawrence Livermore National Laboratory.
Mohay, G. et al., 2003. Computer and Intrusion Forensics. Massachusetts: Artech House,
Inc..
Murphy, J., Elmer-Dewitt, P. & Krance, M., 1983. Computers: The 414 gang strikes again.
s.l.:Time Magazine.
National Security Agency, 2014. Defense in Depth. [Online] Available at:
https://www.nsa.gov/ia/_files/support/defenseindepth.pdf [Accessed 2 January 2015].
Neumann, P. G. & Parker, D. B., 1989. 12th National Computer Security Conference - A
Summary of Computer Misuse Techniques. Baltimore, Maryland, s.n.
Nicolett, M. & Kavanagh, K. M., 2011. Magic Quadrant for security information and event
management, s.l.: Gartner.
Nicolett, M. & Kavanagh, K. M., 2013. Critical Capabilities for Security Information and
Event Management, s.l.: Gartner Inc.
Niemeijer, K., 2014. The ABC's of Big Data. [Online] Available at:
http://foresightinvestor.com/articles/411823-the-abc-s-of-big-data [Accessed 9 Feburary
2015].
Offensive Security, 2013. Kali Linux Documentation. [Online] Available at:
http://docs.kali.org/introduction/what-is-kali-linux [Accessed 22 February 2015].
Orans, L., 2014. The Five Styles of Advanced Threat Defense. s.l.:Gartner.
Pelchat, E., 2004. A Brief Introduction to Structured Design. s.l.:s.n.

40096050 SOC10101
pfSense, 2015. pfSense Features. [Online] Available at: https://www.pfsense.org/about-
pfsense/features.html [Accessed 22 Feburary 2015].
PwC, 2012. Information Security Breaches Survey: Technical Report. [Online]
Available at: http://www.pwc.co.uk/en_UK/uk/assets/pdf/olpapp/uk-information-security-
breaches-survey-technical-report.pdf [Accessed 4 October 2014].
Raymond, E., 2003. The Art of Unix Programming. s.l.:Addison-Wesley Professional
Computing Series.
Roesch, M., 1999. Snort - Lightweight Intrusion Detection for Networks. LISA, 99(1), pp.
229-238.
Rogers, 2006. A two-dimensional circumplex approach to the development of a hacker
taxonomy, s.l.: Elsevier.
Rogers, M., 1999. A new hacker taxonomy, s.l.: University of Manitoba.
Rogers, M., 2000. Psychological Theories of Crime and "Hacking", s.l.: University of
Manitoba.
Rogers, M., 2001. A Social Learning Theory and Moral Disengagement Analysis of Criminal
Computer Behavious: An Exploratory Study, s.l.: University of Manitoba.
Ross, R. et al., 2010. Managing Risk from Information Systems: An Organizational
Perspective, s.l.: NIST.
Ruiz-Martinez, A., Pereniguez-Garcia, F. & Marin-Lopez, R., 2014. Architectures and
Protocols for Secure Information Technology Infrastructures. USA: Information Science
Reference (an imprint of IGI Global).
Russom, P., 2011. Big Data Analytics, s.l.: TDWI (The Data Warehousing Institute).
Scarfone, K. & Mell, P., 2007. Guide to Intrusion Detection and Prevention Systems (IDPS),
s.l.: NIST.
Scarfone, K. & Mell, P., 2007. Guide to Intrusion Detection and Prevention Systems (IDPS),
s.l.: NIST.
Schwartz, M. J., 2011. Information Week: RSA SecurID Breach Cost $66 Million. [Online]
Available at: http://www.darkreading.com/attacks-and-breaches/rsa-securid-breach-cost-$66-
million/d/d-id/1099232? [Accessed 16 October 2014].
Shaikh, S. A. et al., 2008. Network Reconnaissance. Network Security 2008, Volume 11, pp.
12-16.
Silver-Greenberg, J., Goldstein, M. & Perlroth, N., 2013. The New York Times: DealB%k.
[Online] Available at: http://dealbook.nytimes.com/2014/10/02/jpmorgan-discovers-further-
cyber-security-issues/?_php=true&_type=blogs&_php=true&_type=blogs&_r=1&
[Accessed 5 October 2015].
Smith, D., 2013. Life's certainties: death, taxes and APTs. Network Security, 2013(2), pp. 19-
20.
Specht, S. M. & Lee, R. B., 2004. Proceedings of the 17th International Conference on
Parallel and Distributed Computing and Systems: Distributed Denial of Service: Taxonomies
of Attacks, Tools and Countermeasures. Cambridge, MA, ACTA Press.
Taft, D. K., 2012. Big Data Offers Big Opportunities for Retail, Financial, Web Companies.
[Online]

40096050 SOC10101
Available at: http://www.eweek.com/enterprise-apps/big-data-offers-big-opportunities-for-
retail-financial-web-companies/ [Accessed 14 October 2014].
Tankard, C., 2011. Advanced Persistent threats and how to monitor and deter them. Network
Security, 2011(8), pp. 16-19.
Tankard, C., 2012. Big data security. Network Security, 2012(7), pp. 5-8.
Tasevski, P., 2011. Password Attacks and Generation Strategies, s.l.: Tartu University:
Faculty of Mathematics and Computer Sciences.
THC-Hydra, 2014. THC-Hydra. [Online] Available at: https://www.thc.org/thc-hydra/
[Accessed 23 February 2015].
Thomson, G., 2011. APTs: a poorly understood challenge. Network Security, 2011(11), pp. 9-
11.
Thonnard, O. et al., 2012. Industrial Espionage and Targeted Attacks: Understanding the
Characteristrics of an Escalating Threat. In: D. Balzarotti, S. Stolfo & M. Cova, eds. Research
in Attacks, Intrusions, and Defenses. s.l.:Springer-Verlag Berlin Heidelberg, pp. 64-85.
van Rijmenam, M., 2014. Why the 3V's Are Not Sufficient To Describe Big Data. [Online]
Available at: https://datafloq.com/read/3vs-sufficient-describe-big-data/166 [Accessed 9
February 2015].
Virvilis, N., Serrano, O. & Dandurand, L., 2013. Big Data Analytics for Sophisticated Attack
Detection, s.l.: s.n.
Vykopal, J., 2013. Flow-based Brute-force Attack Detection in Large and High-speed
Networks, s.l.: s.n.
Walleij, L., 1998. Copyright Does Not Exist. s.l.:s.n.
Weaver, N., Paxson, V., Staniford, S. & Cullingham, R., 2003. Proceedings of the 2003 ACM
workshop on Rapid malcode: A taxonomy of computer works. Washington, ACM Press.
Whitman, M. E. & Mattord, H. J., 2012. Principles of Information Security. 4th ed. s.l.:Course
Technology, Cengage Learning.
Wood, A. D. & Stankovic, J. A., 2004. A taxonomy for denial-of-service attacks in wireless
sensor networks. In: Handbook of Sensor Networks: Compact Wireless and Wired Sensing
Systems. s.l.:s.n., pp. 739-763.
Yourdon, E. & Constantine, L. L., 1979. Structured Design: Fundamentals of a Discipline of
Computer Program and System Design. s.l.:Prentice-Hall.

40096050 SOC10101
Appendix 1 Initial Project Overview
Title of Project: “Threat Detection and Mitigation using a SIEM
Architecture”
Overview of Project Content and Milestones
Cyber security and how to combat a wide variety of threats is a topic that is in the forefront of many
organisations’ minds these days. The research and the literature review for this project will cover the
following subject areas; Taxonomies of Attacks, Classification of Attacks, Patterns of Attacks, Goals of
Attacks, SIEM and Big Data Applications/Analysis.
The aim of this project is to design and create a network infrastructure taking a defence in depth
approach, to replicate Brute Force/Rainbow Table attack(s) against said network using open source
attack tools and by analysing and filtering the log data collected from various sources and looking for
specific patterns in the data, look at the effectiveness of using a SIEM Architecture for detecting and
mitigating against attacks and for the prediction of possible future attacks.
Main Milestones:
 Creation of Literature Review covering above topics
 Design and create a network infrastructure using pfSense or Vyatta
 Carry out simulation of Brute Force/Rainbow Tables attack(s) using open source attack tools
 Gather log data from various sources and import it into Splunk
 Analyse and filter the log data using SIEM software to look for any patterns that would
identify the attack
 Evaluate the effectiveness of using a SIEM Architecture to detect, mitigate and predict future
attacks.
The Main Deliverable(s):
 A Literature Review covering many aspects of attacks, SIEM and Big Data
Applications/Analysis.
 The design and creation of a network infrastructure using open source software
 The replication of an attack using open source attack tools
 Collecting and importing of log data from various sources into a SIEM product
 A thorough analysis of the data, visually presented in an easy to understand format
 An evaluation and discussion of the results – was the attack detected, can attack patterns be
identified and if so, used to help prevent/predict future attacks.

40096050 SOC10101
The Target Audience for the Deliverable(s):
The target audience for this Project is Network and Security Professionals, CIOs, CEOs and Network
Administrators within organisations where network security and information security is a priority for
their business.
The Work to be undertaken:
 An investigation into various aspects of Threats/Attacks, SIEM and Big Data
Applications/Analysis
 The creation of a Literature Review covering the above subject areas
 Design and implementation of a prototype network architecture using pfSense or Vyatta
 Simulation and detection of Brute Force/Rainbow Tables attack(s)
 Collection of log data from various sources
 Analysis of log data
 Evaluation and discussion of results
Additional Information / Knowledge Required:
 Broadening my knowledge on Threats/Attacks
 Broadening my knowledge of SIEM and Big Data Applications/Analysis
 Learning how to use pfSense or Vyatta to create a network architecture
 Learning how to use open source attack tools
 Learning how to collect log data from various sources and import it into SIEM software
 Learning how to use SIEM software for data analysis
Information Sources that Provide a Context for the Project:
Neumann, P. G. & Parker, D. B., 1989. A Summary of Computer Misuse Techniques. Maryland, 12th
National Computer Security Conference.
Simmonds, A., Sandilands, P. & Van Ekert, L., 2004. An Ontology for Network Security Attacks. In:
Applied Computing. s.l.:Springer Berlin Heidelberg, pp. 317-323.
Hansman, S. & Hunt, R., 2004. A taxonomy of network and computer attacks. Computers & Security,
24(1), pp. 31-43.
Nicolett, M. K. M. K., 2013. Critical Capabilities for Security Information and Event Management,
s.l.: Gartner, Inc..
Carasso, D., 2012. Exploring Splunk. 1st ed. New York: CITO Research.

40096050 SOC10101
Splunk Inc., 2014. Splunk for Security - Supporting a Big Data Approach for Security Intelligence.
[Online]
Available at: http://www.splunk.com/web_assets/pdfs/secure/Splunk_for_Security.pdf
[Accessed 20 September 2014].
The Importance of the Project:
Cyber security and how to combat a wide variety of threats is a topic that is in the forefront of many
organisations’ minds these days. With the rise in the number of attacks and the increase in complexity
of these attacks, the traditional layers of defence; Demilitarized zones (DMZ), Firewalls (hardware or
software), Intrusion Detection Systems (IDS) and Intrusion Protection System (IPS) are no longer
enough to keep organisations systems and data secure. Implementing SIEM software with the ability
to collect and analyse large amounts of data from various sources, gives companies a further layer of
defence and the opportunity to detect and mitigate these attacks and future attacks.
The Key Challenge(s) to be overcome:
The key challenges to be overcome will be learning how to use pfSense or Vyatta, learning how to use
open source attack tools required for the replication of the attack, learning how to collect log data from
various sources and import it into Splunk, learning how to write Splunk rules in order to best analyse
and filter the data.

40096050 SOC10101
Appendix 2 Week 9 Interim Report (including Time
Plan)
Interim Report
Name: Pamela Dempster
Title: Threat Detection and Mitigation using a SIEM Architecture
Matriculation No: 40096050
1 Introduction
This document provides an overview of the work done to date and will also outline the key
literature surrounding the topic. The first part of the Literature Review will look at creating a
Taxonomy of Attacks covering areas such as Cyber Adversaries, their skills and what
motivates them, Classification of Attacks, Attack Patterns and APTs. The Literature Review
will then go on to review areas such as Big Data Analytics (including the amount of data
currently being generated); SIEM and how SIEM architectures are being used to detect and
mitigate cyber threats and finally how taking a Defence in Depth approach to security gives
organisations the best chance of protection against attackers.
The motivation for the project came from completing a Security and Forensics coursework
on IDS. The detection and prevention of attacks was an area I found to be extremely
interesting and that I wanted to learn more about. I also developed an interest in the different
types of attacks organisations were facing and what kind of people were behind these attacks
and what motivated them.
1.1 Context
many organisations’ minds these days. With the rise in the number of attacks and the increase
in complexity of these attacks, the traditional layers of defence; Demilitarized zones (DMZ),
Firewalls (hardware or software), Intrusion Detection Systems (IDS) and Intrusion Protection
System (IPS) are no longer enough to keep organisations systems and data secure.
Implementing SIEM software with the ability to collect and analyse large amounts of data
from various sources, gives companies a further layer of defence and the opportunity to detect
and mitigate these attacks and future attacks. (Aguirre & Alonso, 2012),(Granadillo, et al.,
2012).
1.2 Aim and Objectives
The aim of this project is to determine whether by analysing and filtering log data from
various sources such as Firewall Logs, Snort Logs etc and looking for specific patterns in the

40096050 SOC10101
data, it is possible using a SIEM architecture to detect brute force password attacks and
whether through the use of data analytics it would be possible to predict what future attacks
would look like and therefore mitigate such attacks.
The objectives are as follows:
 Create a Literature Review to investigate key areas of Attacks, Big Data Analytics and SIEM
 Design and implement a network architecture using pfSense
 Simulate brute force password attack (scan for live hosts, OS scan, scan for open ports using
Nmap, password attack using Hydra, login via FTP, download file)
 Import log data into Splunk and carry out an analysis of the data
 Evaluate whether it is possible to detect the attack using a SIEM architecture
 Evaluate whether through the use of data analytics it is possible to predict what future attacks
would look like
 Evaluate whether through the use of data analytics it is therefore possible to mitigate such
attacks
1.3 Overview of Project
The aim of this project is to create a Literature Review that will essentially create a
Taxonomy of Attacks, covering areas such as Cyber Adversaries, their skills and what
motivates them, Classification of Attacks, Attack Patterns and APTs. The Literature Review
will then go on to review areas such as Big Data Analytics (including the amount of data
currently being generated); SIEM and how SIEM architectures are being used to detect and
mitigate cyber threats and finally how taking a Defence in Depth approach to security gives
organisations the best chance of protection against attackers.
On the practical side, the aim of this project is to design and create a network infrastructure
using PfSense, to replicate brute force password attacks, to collect log data from various
sources and import it into Splunk and determine, by looking for specific patterns in the data,
whether it is possible using a SIEM architecture to detect the intrusions and whether through
the use of data analytics it would be possible to predict what future attacks would look like
and therefore mitigate such attacks.
2 Work done to date
To date, research has been carried out on various aspects of attacks, SIEM, Big Block Data
Analytics and Defence in Depth. The research carried out on cyber adversaries has given me
an insight into when hacking first became a security issue, the types of people who carry out
these attacks and what motivates them. The research into APTs has given me an insight into
how attacks have increased in sophistication over the years and how only a layered approach
to defence and continual monitoring can hope to detect or deter these targeted attacks. The

40096050 SOC10101
research into Big Block Data Analytics has given me an insight into how much machine data
is actually generated and how collecting the data from a variety of sources and analysing it,
can help aid in the detection and mitigation of many attacks. The papers I have read in
relation to SIEM have furthered my knowledge on the various SIEM products available on the
market and how they are being used and adapted to suit different circumstances.
In relation to the writing of the Literature Review, part of the Introduction Chapter has been
written outlining the background for the Project. Sections on Cyber Adversaries, Attack
Patterns, Advanced Persistent Threats, Classification of Attacks, Big Data Analytics and
SIEM have been written.
On the practical side, I have completed the Splunk tutorials on Buttercup Games although as
this was some time ago, I intend to repeat them. Snort has been run locally to detect an FTP
Brute Force attack using PCap files, response codes have been looked at and some rules have
been written in Snort to detect bad and good logins. The Vyatta Firewall Integration Lab has
been completed which allowed me to familiarise myself with the Napier Cloud environment
and gave me more experience with virtual machines. Lab 2, Creating Secure Architectures has
been completed which allowed me to familiarise myself with the PfSense firewall, create
some rules and helped me to plan the design of the network to be used in the implementation.
The network to be used in the implementation has now been configured and an FTP brute
force password attack has been carried out successfully. I have also started to research
Tcpreplay for the generation of background traffic.
4 Work plan (Gantt Chart)
Table 1: Work plan

40096050 SOC10101
5 Evaluation
The evaluation will look at the following:
 Evaluate whether it is possible to detect the attacks using a SIEM architecture
 Evaluate whether through the use of data analytics it is possible to predict what future
attacks would look like
 Evaluate whether through the use of data analytics it is possible to mitigate such
attacks

40096050 SOC10101
Figure 1: Time plan

40096050 SOC10101
Appendix 3 Diary Sheets
EDINBURGH NAPIER UNIVERSITY
SCHOOL OF COMPUTING
PROJECT DIARY
Student: Pamela Dempster Supervisor: Bill Buchanan
Date: 17/09/2014 Last diary date:
Objectives:
 Continue research re Taxonomy of Threats/Vulnerabilities
 Start draft of IPO
Progress:
 Various papers (including Conference Proceedings) identified as well as several books
covering: Ontology of Security Attacks, Taxonomies of Attacks, Classification of
Attacks, Patterns of Attacks and Definitions of Attacks
 Initial notes drafted as to what Chapters in Dissertation will be headed up and
what will be covered in each Chapter.
 Draft of IPO almost complete
Supervisor’s Comments:

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Date: 24/09/2014 Last diary date: 17/09/14
Objectives:
 Continue research re Taxonomy of Threats/Vulnerabilities
 Complete IPO
 Start Lit Review
Progress:
 Papers identified re Taxonomies of Cyber Adversaries
 IPO complete
 Part of Introduction (Background) written

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Start Lit Review
 Research papers on Advanced Persistent Threat
Progress:
 Several pages of Lit Review written re Taxonomy of Cyber Adversaries
 Papers and articles identified re APT

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Carry on with Lit Review
 Research papers on SIEM Applications
Progress:
 Section written covering Attack Patterns
 Section started re APT
 Still researching papers for SIEM

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Research papers on SIEM Applications
 Research papers on Defence in Depth
 Research Big Block Data
Progress:
 Section written on APT
 Section started on Classification of Attacks
 Still researching papers for SIEM applications

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Do Vyatta Firewall Lab
Progress:
 Vyatta Firewall Lab completed
 Section written on Big Block Data

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Install Snort and look at detecting FTP attack using PCap files
 Write some basic Snort rules
 Write Week 9 Interim Report
Progress:
 Snort installed, FTP attack detected and basic rules written to detect good and bad
logins
 Week 9 Report completed

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Revise Week 9 Interim Report if necessary
 Research PfSense and Vyatta
 Research different SIEM products
 Do PfSense Lab(s)
Progress:
 Week 9 Interim Report revised
 PfSense Lab (Creating Secure Architectures) completed
 Some investigation into SIEM products and SIEM applications carried out

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Write Section on Defence in Depth
 Add to APT section
 Carry out more research into SIEM
 Start section on SIEM
Progress:
 Section written on Defence in Depth
 Additional information added to section on APTs
 Some further research carried out re SIEM
 Section on SIEM started
 Additional information added to Big Data Analytics

40096050 SOC10101
SCHOOL OF COMPUTING
PROJECT DIARY
Objectives:
 Configure network and carry out FTP brute force password attack
 Add to section on Attack Patterns
 Add conclusions to various sections
Progress:
 Network configured and FTP brute force password attack carried out
 Additional information added to section on Attack Patterns
 Conclusions added to some sections

DISSERTATION_40096050

More Related Content

Viewers also liked (16)

Similar to DISSERTATION_40096050 (20)

DISSERTATION_40096050