Projects - User contributions [en]

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:29:28Z

A1645994: /* 7 Appendices */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.

'''3.1 Background Theory'''

This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.

'''3.1.1 Simulation Method'''

A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.

'''3.1.2 Wireshark'''

Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).

'''3.1.3 Matlab'''

Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.

'''3.1.3 Internet Protocol Packet Information'''

Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]

Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''

The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers

'''3.3 Method 1: Time to Live Fingerprinting'''

TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.

'''3.3.1 Time to Live Characteristics'''

Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.

It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].

'''3.3.2 Design'''

The network will be set up as follows for a normal operating condition:

[[File:2a.png|x200px|200px]]

Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:

[[File:3a.png|x200px|200px]]

Figure 3: Client's network location changed

'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.

This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.

A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.

'''3.3.4 Results'''

The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.

'''3.3.5 Discussion'''

Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.

'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''

The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.

'''3.4.1 Internet Protocol Identification Numbers'''

The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.

'''3.4.2 Method'''

Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''

The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.

Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)

[[File:4a.png|x200px|200px]]

Figure 4: Difference in IPID under normal conditions

'''Test 2: IPID change under higher data transfer rate'''

The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]

Figure 5: Difference in IPID when a file is being transferred over network

'''Test 3: IPID values with two client devices'''

The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.

[[File:6a.png|x200px|200px]]

Figure 6: IPID numbers received from two clients

'''Test 4: Long term IPID characteristics for fingerprinting'''

The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.

[[File:7a.png|x200px|200px]]

Figure 7: Difference in IPID numbers over a five-hour time period

'''3.4.3 Results'''

The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.

Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.

Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.

Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.

'''3.4.4 Discussion and future work'''

The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.

'''3.5 Method 3: Transmission Time Fingerprinting'''

The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.

'''3.5.1 Factors Affecting Transmission Time'''

RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.

The following formula summarises these delays:

dRTT = dprop + dqueue + dproc + dresp

dRTT – RTT

dprop – Propagation delay over medium

dqueue – Queuing delay at switch depending on how busy it is

dproc – Total processing delay of interconnecting routers and switches

dresp – Response time of device being pinged

'''3.5.2 Method'''

The initial setup involved connecting two PCs via a switch.

Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.

Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.

Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)

'''3.5.3 Results'''

[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]

Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions

The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.

[[File:10a.png|x200px|200px]]

'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''

It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.

'''3.5.4 Discussion'''

It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.

'''3.6 Kullback-Leibler divergence and DRTT'''

Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.

As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.

A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)

𝛼 > 0

N(𝜃,𝜎)- Random extra delay

The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].

[[File:11a.png|x200px|200px]]

Figure 11: DRTT in fingerprint vs same device over different period

[[File:12.png|x200px|200px]]

Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.

The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.

In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.

'''3.7 CDF of Client RTT'''

In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]

Figure 13: Histogram of device RTTs over 2 different time periods

[[File:14.png|x200px|200px]]

Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions

A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]

Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.

[[File:15.png|x200px|200px]]

Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)

The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.

The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.

[[File:eq1a.png|x200px|200px]]

Equation 1: Finding the difference between two CDFs

'''3.8 Sample window size and costs of making a decision'''

The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.

A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.

It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.

'''4.1 Method'''

In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.

Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.

Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.

These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.

The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change

Trigger multiple device access alarm

Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint

If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured

Trigger topography changed alarm

Else If (absolute(CDFdiff¬) > 1.5%)

Trigger programming changed alarm

The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.

Picture of set up

[[File:16a_copy.jpg|x200px|200px]]

Figure 16: Equipment set up

'''4.2 Results'''

Case 0: Normal conditions (No-alarm)

The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.

Test 1

The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.

[[File:17.png|x200px|200px]]

Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]

Figure 18: Histogram of device RTTs over two time periods

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 3102μs

Difference in RTT CDF 1.05%

Table 2: Case 0, test 1 results

The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.

Test 2

The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.

[[File:19.png|x200px|200px]]

Figure 19: Histogram of device RTTs at two different times

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 2572μs

Difference in RTT CDF -0.09%

Table 3: Case 0, test 2 results

The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.

Case 1: Malicious switch inserted (Alarm)

Test 1

The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.

[[File:20.png|x200px|200px]]

Figure 20: Layout with extra malicious switch inserted (SB)

[[File:21.png|x200px|200px]]

Figure 21: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 4348μs

Difference in RTT CDF 3.43%

Table 4: Case 1, test 1 results

In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.

Test 2

A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.

[[File:22.png|x200px|200px]]

Figure 22: Layout with extra malicious switch inserted (SA)

[[File:23.png|x200px|200px]]

Figure 23: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 5807μs

Difference in RTT CDF 2.80%

Table 5: Case 1, test 2 results

Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)

The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.

[[File:24.png|x200px|200px]]

Figure 24: Layout with extra PC polling PLC

The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)

This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.

[[File:25.png|x200px|200px]]

Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 3181μs

Difference in RTT CDF 2.351%

Table 6: Case 3 results

It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.

Case 4: Two switches with high load on one switch (No-alarm)

This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).

[[File:26.png|x200px|200px]]

Figure 26: Normal layout for new fingerprint case

[[File:27.png|x200px|200px]]

Figure 27: Normal layout with extra devices transferring data – No alarm

[[File:28.png|x200px|200px]]

Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm

Distribution 1 maximum RTT 3183μs

Distribution 2 maximum RTT 2794μs

Difference in RTT CDF 0.360%

Table 7: Case 4 results

The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.

'''4.3 Discussion'''

From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.

Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.

Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.

'''4.4 Future Work'''

For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.

Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.

These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.

It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.

These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''

'''7.1.1 Work Breakdown'''

The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.

Introduction and literature review

Understand IP characteristics

Plan how software will be used to aid analysis

Explore different methods that could be used for fingerprint creation

TTL fingerprinting

IP Identification numbers

Transmission times

Developing final software tool

3.1 Combine methods into one fingerprint creation tool

3.2 Analyses traffic to check fingerprint

3.3 Test on larger scale systems

3.4 Conclusion of findings

'''7.1.2 Timeline'''

The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.

Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.

Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.

Table 1: Project Timeline (dates)

Research existing authentication methods (29/02/2016-11/04/2016)

Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)

MILESTONE: Draft 1 of Thesis due on 22/04/2016

Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)

Time to Live characteristics

IP identification number characteristics

Transmission time characteristics

Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)

Build and test fingerprint creation tool

Build and test traffic monitoring tool

Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)

Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)

Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)

MILESTONE: Draft 2 of Thesis due on 04/06/2016

Update Thesis as required from feedback (20/06/2016-20/10/2016)

MILESTONE: Final Thesis due on 21/10/2016

10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)

MILESTONE: Exhibition (24/10/2016-28/10/2016)

MILESTONE: Final seminar (31/10/2016-04/11/2016)

'''7.1.3 Budget'''

Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.

'''7.1.4 Risk Analysis'''

The following risks may affect the project:

Loss of work

This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)

Not completing work in time

This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.

Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''

'''7.2.1 IP address conversions'''

Conversion from dotted decimal to integer:

splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))

Conversion from integer to dotted decimal:

strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))

MATLAB ping

[[File:30.png]]

'''7.2.3 IP ID analyser'''

[[File:31.png]]

'''7.2.4 Round Trip Time analyser'''

[[File:32.png]]

'''7.2.5 CDF difference calculator'''

[[File:33a.png]]

'''7.3 Output'''

7.3.1 Section 3.4.2 Test 1 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:34.png]]

7.3.2 Section 3.4.2 Test 2 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:35.png]]

'''7.4 Estonia Tour Report'''

During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.

'''7.4.1 Introduction'''

The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.

'''7.4.2 Positives'''

The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.

A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.

'''7.4.3 Personal Highlights'''

My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.

We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.

'''7.4.4 Recommendations'''

I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:28:41Z

A1645994: /* 4 Implementing Fingerprinting Techniques */

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:26:54Z

A1645994: /* 4 Implementing Fingerprinting Techniques */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.

'''3.1 Background Theory'''

This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.

'''3.1.1 Simulation Method'''

A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.

'''3.1.2 Wireshark'''

Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).

'''3.1.3 Matlab'''

Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.

'''3.1.3 Internet Protocol Packet Information'''

Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]

Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''

The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers

'''3.3 Method 1: Time to Live Fingerprinting'''

TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.

'''3.3.1 Time to Live Characteristics'''

Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.

It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].

'''3.3.2 Design'''

The network will be set up as follows for a normal operating condition:

[[File:2a.png|x200px|200px]]

Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:

[[File:3a.png|x200px|200px]]

Figure 3: Client's network location changed

'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.

This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.

A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.

'''3.3.4 Results'''

The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.

'''3.3.5 Discussion'''

Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.

'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''

The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.

'''3.4.1 Internet Protocol Identification Numbers'''

The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.

'''3.4.2 Method'''

Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''

The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.

Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)

[[File:4a.png|x200px|200px]]

Figure 4: Difference in IPID under normal conditions

'''Test 2: IPID change under higher data transfer rate'''

The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]

Figure 5: Difference in IPID when a file is being transferred over network

'''Test 3: IPID values with two client devices'''

The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.

[[File:6a.png|x200px|200px]]

Figure 6: IPID numbers received from two clients

'''Test 4: Long term IPID characteristics for fingerprinting'''

The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.

[[File:7a.png|x200px|200px]]

Figure 7: Difference in IPID numbers over a five-hour time period

'''3.4.3 Results'''

The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.

Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.

Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.

Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.

'''3.4.4 Discussion and future work'''

The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.

'''3.5 Method 3: Transmission Time Fingerprinting'''

The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.

'''3.5.1 Factors Affecting Transmission Time'''

RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.

The following formula summarises these delays:

dRTT = dprop + dqueue + dproc + dresp

dRTT – RTT

dprop – Propagation delay over medium

dqueue – Queuing delay at switch depending on how busy it is

dproc – Total processing delay of interconnecting routers and switches

dresp – Response time of device being pinged

'''3.5.2 Method'''

The initial setup involved connecting two PCs via a switch.

Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.

Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.

Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)

'''3.5.3 Results'''

[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]

Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions

The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.

[[File:10a.png|x200px|200px]]

'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''

It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.

'''3.5.4 Discussion'''

It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.

'''3.6 Kullback-Leibler divergence and DRTT'''

Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.

As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.

A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)

𝛼 > 0

N(𝜃,𝜎)- Random extra delay

The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].

[[File:11a.png|x200px|200px]]

Figure 11: DRTT in fingerprint vs same device over different period

[[File:12.png|x200px|200px]]

Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.

The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.

In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.

'''3.7 CDF of Client RTT'''

In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]

Figure 13: Histogram of device RTTs over 2 different time periods

[[File:14.png|x200px|200px]]

Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions

A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]

Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.

[[File:15.png|x200px|200px]]

Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)

The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.

The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.

[[File:eq1a.png|x200px|200px]]

Equation 1: Finding the difference between two CDFs

'''3.8 Sample window size and costs of making a decision'''

The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.

A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.

It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.

'''4.1 Method'''

In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.

Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.

Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.

These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.

The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change

Trigger multiple device access alarm

Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint

If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured

Trigger topography changed alarm

Else If (absolute(CDFdiff¬) > 1.5%)

Trigger programming changed alarm

The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.

Picture of set up

[[File:16a copy.png|x200px|200px]]

Figure 16: Equipment set up

'''4.2 Results'''

Case 0: Normal conditions (No-alarm)

The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.

Test 1

The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.

[[File:17.png|x200px|200px]]

Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]

Figure 18: Histogram of device RTTs over two time periods

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 3102μs

Difference in RTT CDF 1.05%

Table 2: Case 0, test 1 results

The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.

Test 2

The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.

[[File:19.png|x200px|200px]]

Figure 19: Histogram of device RTTs at two different times

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 2572μs

Difference in RTT CDF -0.09%

Table 3: Case 0, test 2 results

The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.

Case 1: Malicious switch inserted (Alarm)

Test 1

The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.

[[File:20.png|x200px|200px]]

Figure 20: Layout with extra malicious switch inserted (SB)

[[File:21.png|x200px|200px]]

Figure 21: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 4348μs

Difference in RTT CDF 3.43%

Table 4: Case 1, test 1 results

In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.

Test 2

A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.

[[File:22.png|x200px|200px]]

Figure 22: Layout with extra malicious switch inserted (SA)

[[File:23.png|x200px|200px]]

Figure 23: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 5807μs

Difference in RTT CDF 2.80%

Table 5: Case 1, test 2 results

Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)

The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.

[[File:24.png|x200px|200px]]

Figure 24: Layout with extra PC polling PLC

The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)

This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.

[[File:25.png|x200px|200px]]

Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 3181μs

Difference in RTT CDF 2.351%

Table 6: Case 3 results

It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.

Case 4: Two switches with high load on one switch (No-alarm)

This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).

[[File:26.png|x200px|200px]]

Figure 26: Normal layout for new fingerprint case

[[File:27.png|x200px|200px]]

Figure 27: Normal layout with extra devices transferring data – No alarm

[[File:28.png|x200px|200px]]

Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm

Distribution 1 maximum RTT 3183μs

Distribution 2 maximum RTT 2794μs

Difference in RTT CDF 0.360%

Table 7: Case 4 results

The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.

'''4.3 Discussion'''

From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.

Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.

Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.

'''4.4 Future Work'''

For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.

Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.

These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.

It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.

These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''

'''7.1.1 Work Breakdown'''

The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.

Introduction and literature review

Understand IP characteristics

Plan how software will be used to aid analysis

Explore different methods that could be used for fingerprint creation

TTL fingerprinting

IP Identification numbers

Transmission times

Developing final software tool

3.1 Combine methods into one fingerprint creation tool

3.2 Analyses traffic to check fingerprint

3.3 Test on larger scale systems

3.4 Conclusion of findings

'''7.1.2 Timeline'''

The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.

Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.

Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.

Table 1: Project Timeline (dates)

Research existing authentication methods (29/02/2016-11/04/2016)

Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)

MILESTONE: Draft 1 of Thesis due on 22/04/2016

Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)

Time to Live characteristics

IP identification number characteristics

Transmission time characteristics

Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)

Build and test fingerprint creation tool

Build and test traffic monitoring tool

Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)

Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)

Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)

MILESTONE: Draft 2 of Thesis due on 04/06/2016

Update Thesis as required from feedback (20/06/2016-20/10/2016)

MILESTONE: Final Thesis due on 21/10/2016

10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)

MILESTONE: Exhibition (24/10/2016-28/10/2016)

MILESTONE: Final seminar (31/10/2016-04/11/2016)

'''7.1.3 Budget'''

Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.

'''7.1.4 Risk Analysis'''

The following risks may affect the project:

Loss of work

This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)

Not completing work in time

This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.

Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''

'''7.2.1 IP address conversions'''

Conversion from dotted decimal to integer:

splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))

Conversion from integer to dotted decimal:

strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))

MATLAB ping

[[File:30.png]]

'''7.2.3 IP ID analyser'''

[[File:31.png]]

'''7.2.4 Round Trip Time analyser'''

[[File:32.png]]

'''7.2.5 CDF difference calculator'''

[[File:33a.png]]

'''7.3 Output'''

7.3.1 Section 3.4.2 Test 1 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:34.png]]

7.3.2 Section 3.4.2 Test 2 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:35.png]]

'''7.4 Estonia Tour Report'''

During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.

'''7.4.1 Introduction'''

The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.

'''7.4.2 Positives'''

The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.

A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.

'''7.4.3 Personal Highlights'''

My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.

We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.

'''7.4.4 Recommendations'''

I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:25:07Z

A1645994: /* 3 Finding characteristics and creating fingerprints */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.

'''3.1 Background Theory'''

This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.

'''3.1.1 Simulation Method'''

A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.

'''3.1.2 Wireshark'''

Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).

'''3.1.3 Matlab'''

Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.

'''3.1.3 Internet Protocol Packet Information'''

Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]

Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''

The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers

'''3.3 Method 1: Time to Live Fingerprinting'''

TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.

'''3.3.1 Time to Live Characteristics'''

Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.

It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].

'''3.3.2 Design'''

The network will be set up as follows for a normal operating condition:

[[File:2a.png|x200px|200px]]

Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:

[[File:3a.png|x200px|200px]]

Figure 3: Client's network location changed

'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.

This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.

A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.

'''3.3.4 Results'''

The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.

'''3.3.5 Discussion'''

Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.

'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''

The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.

'''3.4.1 Internet Protocol Identification Numbers'''

The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.

'''3.4.2 Method'''

Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''

The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.

Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)

[[File:4a.png|x200px|200px]]

Figure 4: Difference in IPID under normal conditions

'''Test 2: IPID change under higher data transfer rate'''

The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]

Figure 5: Difference in IPID when a file is being transferred over network

'''Test 3: IPID values with two client devices'''

The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.

[[File:6a.png|x200px|200px]]

Figure 6: IPID numbers received from two clients

'''Test 4: Long term IPID characteristics for fingerprinting'''

The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.

[[File:7a.png|x200px|200px]]

Figure 7: Difference in IPID numbers over a five-hour time period

'''3.4.3 Results'''

The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.

Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.

Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.

Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.

'''3.4.4 Discussion and future work'''

The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.

'''3.5 Method 3: Transmission Time Fingerprinting'''

The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.

'''3.5.1 Factors Affecting Transmission Time'''

RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.

The following formula summarises these delays:

dRTT = dprop + dqueue + dproc + dresp

dRTT – RTT

dprop – Propagation delay over medium

dqueue – Queuing delay at switch depending on how busy it is

dproc – Total processing delay of interconnecting routers and switches

dresp – Response time of device being pinged

'''3.5.2 Method'''

The initial setup involved connecting two PCs via a switch.

Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.

Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.

Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)

'''3.5.3 Results'''

[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]

Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions

The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.

[[File:10a.png|x200px|200px]]

'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''

It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.

'''3.5.4 Discussion'''

It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.

'''3.6 Kullback-Leibler divergence and DRTT'''

Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.

As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.

A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)

𝛼 > 0

N(𝜃,𝜎)- Random extra delay

The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].

[[File:11a.png|x200px|200px]]

Figure 11: DRTT in fingerprint vs same device over different period

[[File:12.png|x200px|200px]]

Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.

The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.

In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.

'''3.7 CDF of Client RTT'''

In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]

Figure 13: Histogram of device RTTs over 2 different time periods

[[File:14.png|x200px|200px]]

Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions

A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]

Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.

[[File:15.png|x200px|200px]]

Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)

The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.

The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.

[[File:eq1a.png|x200px|200px]]

Equation 1: Finding the difference between two CDFs

'''3.8 Sample window size and costs of making a decision'''

The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.

A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.

It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.

'''4.1 Method'''

In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.

Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.

Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.

These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.

The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change

Trigger multiple device access alarm

Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint

If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured

Trigger topography changed alarm

Else If (absolute(CDFdiff¬) > 1.5%)

Trigger programming changed alarm

The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.

Picture of set up

[[File:16a_copy.png|x200px|200px]]

Figure 16: Equipment set up

'''4.2 Results'''

Case 0: Normal conditions (No-alarm)

The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.

Test 1

The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.

[[File:17.png|x200px|200px]]

Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]

Figure 18: Histogram of device RTTs over two time periods

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 3102μs

Difference in RTT CDF 1.05%

Table 2: Case 0, test 1 results

The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.

Test 2

The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.

[[File:19.png|x200px|200px]]

Figure 19: Histogram of device RTTs at two different times

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 2572μs

Difference in RTT CDF -0.09%

Table 3: Case 0, test 2 results

The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.

Case 1: Malicious switch inserted (Alarm)

Test 1

The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.

[[File:20.png|x200px|200px]]

Figure 20: Layout with extra malicious switch inserted (SB)

[[File:21.png|x200px|200px]]

Figure 21: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 4348μs

Difference in RTT CDF 3.43%

Table 4: Case 1, test 1 results

In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.

Test 2

A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.

[[File:22.png|x200px|200px]]

Figure 22: Layout with extra malicious switch inserted (SA)

[[File:23.png|x200px|200px]]

Figure 23: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 5807μs

Difference in RTT CDF 2.80%

Table 5: Case 1, test 2 results

Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)

The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.

[[File:24.png|x200px|200px]]

Figure 24: Layout with extra PC polling PLC

The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)

This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.

[[File:25.png|x200px|200px]]

Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 3181μs

Difference in RTT CDF 2.351%

Table 6: Case 3 results

It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.

Case 4: Two switches with high load on one switch (No-alarm)

This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).

[[File:26.png|x200px|200px]]

Figure 26: Normal layout for new fingerprint case

[[File:27.png|x200px|200px]]

Figure 27: Normal layout with extra devices transferring data – No alarm

[[File:28.png|x200px|200px]]

Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm

Distribution 1 maximum RTT 3183μs

Distribution 2 maximum RTT 2794μs

Difference in RTT CDF 0.360%

Table 7: Case 4 results

The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.

'''4.3 Discussion'''

From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.

Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.

Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.

'''4.4 Future Work'''

For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.

Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.

These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.

It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.

These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''

'''7.1.1 Work Breakdown'''

The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.

Introduction and literature review

Understand IP characteristics

Plan how software will be used to aid analysis

Explore different methods that could be used for fingerprint creation

TTL fingerprinting

IP Identification numbers

Transmission times

Developing final software tool

3.1 Combine methods into one fingerprint creation tool

3.2 Analyses traffic to check fingerprint

3.3 Test on larger scale systems

3.4 Conclusion of findings

'''7.1.2 Timeline'''

The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.

Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.

Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.

Table 1: Project Timeline (dates)

Research existing authentication methods (29/02/2016-11/04/2016)

Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)

MILESTONE: Draft 1 of Thesis due on 22/04/2016

Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)

Time to Live characteristics

IP identification number characteristics

Transmission time characteristics

Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)

Build and test fingerprint creation tool

Build and test traffic monitoring tool

Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)

Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)

Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)

MILESTONE: Draft 2 of Thesis due on 04/06/2016

Update Thesis as required from feedback (20/06/2016-20/10/2016)

MILESTONE: Final Thesis due on 21/10/2016

10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)

MILESTONE: Exhibition (24/10/2016-28/10/2016)

MILESTONE: Final seminar (31/10/2016-04/11/2016)

'''7.1.3 Budget'''

Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.

'''7.1.4 Risk Analysis'''

The following risks may affect the project:

Loss of work

This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)

Not completing work in time

This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.

Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''

'''7.2.1 IP address conversions'''

Conversion from dotted decimal to integer:

splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))

Conversion from integer to dotted decimal:

strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))

MATLAB ping

[[File:30.png]]

'''7.2.3 IP ID analyser'''

[[File:31.png]]

'''7.2.4 Round Trip Time analyser'''

[[File:32.png]]

'''7.2.5 CDF difference calculator'''

[[File:33a.png]]

'''7.3 Output'''

7.3.1 Section 3.4.2 Test 1 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:34.png]]

7.3.2 Section 3.4.2 Test 2 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:35.png]]

'''7.4 Estonia Tour Report'''

During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.

'''7.4.1 Introduction'''

The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.

'''7.4.2 Positives'''

The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.

A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.

'''7.4.3 Personal Highlights'''

My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.

We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.

'''7.4.4 Recommendations'''

I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:22:18Z

A1645994: /* 7 Appendices */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.

'''3.1 Background Theory'''

This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.

'''3.1.1 Simulation Method'''

A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.

'''3.1.2 Wireshark'''

Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).

'''3.1.3 Matlab'''

Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.

'''3.1.3 Internet Protocol Packet Information'''

Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]

Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''

The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers

'''3.3 Method 1: Time to Live Fingerprinting'''

TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.

'''3.3.1 Time to Live Characteristics'''

Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.

It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].

'''3.3.2 Design'''

The network will be set up as follows for a normal operating condition:

[[File:2a.png|x200px|200px]]

Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:

[[File:3a.png|x200px|200px]]

Figure 3: Client's network location changed

'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.

This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.

A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.

'''3.3.4 Results'''

The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.

'''3.3.5 Discussion'''

Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.

'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''

The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.

'''3.4.1 Internet Protocol Identification Numbers'''

The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.

'''3.4.2 Method'''

Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''

The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.

Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)

[[File:4a.png|x200px|200px]]

Figure 4: Difference in IPID under normal conditions

'''Test 2: IPID change under higher data transfer rate'''

The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]

Figure 5: Difference in IPID when a file is being transferred over network

'''Test 3: IPID values with two client devices'''

The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.

[[File:6a.png|x200px|200px]]

Figure 6: IPID numbers received from two clients

'''Test 4: Long term IPID characteristics for fingerprinting'''

The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.

[[File:7a.png|x200px|200px]]

Figure 7: Difference in IPID numbers over a five-hour time period

'''3.4.3 Results'''

The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.

Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.

Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.

Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.

'''3.4.4 Discussion and future work'''

The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.

'''3.5 Method 3: Transmission Time Fingerprinting'''

The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.

'''3.5.1 Factors Affecting Transmission Time'''

RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.

The following formula summarises these delays:

dRTT = dprop + dqueue + dproc + dresp

dRTT – RTT

dprop – Propagation delay over medium

dqueue – Queuing delay at switch depending on how busy it is

dproc – Total processing delay of interconnecting routers and switches

dresp – Response time of device being pinged

'''3.5.2 Method'''

The initial setup involved connecting two PCs via a switch.

Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.

Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.

Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)

'''3.5.3 Results'''

[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]

Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions

The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.

[[File:10a.png|x200px|200px]]

'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''

It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.

'''3.5.4 Discussion'''

It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.

'''3.6 Kullback-Leibler divergence and DRTT'''

Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.

As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.

A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)

𝛼 > 0

N(𝜃,𝜎)- Random extra delay

The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].

[[File:11a.png|x200px|200px]]

Figure 11: DRTT in fingerprint vs same device over different period

[[File:12.png|x200px|200px]]

Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.

The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.

In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.

'''3.7 CDF of Client RTT'''

In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]

Figure 13: Histogram of device RTTs over 2 different time periods

[[File:14.png|x200px|200px]]

Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions

A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]

Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.

[[File:15.png|x200px|200px]]

Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)

The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.

The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.

[[File:eq1a.png|x200px|200px]]

Equation 1: Finding the difference between two CDFs

'''3.8 Sample window size and costs of making a decision'''

The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.

A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.

It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.

'''4.1 Method'''

In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.

Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.

Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.

These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.

The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change

Trigger multiple device access alarm

Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint

If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured

Trigger topography changed alarm

Else If (absolute(CDFdiff¬) > 1.5%)

Trigger programming changed alarm

The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.

Picture of set up

[[File:16a_copy.png|x200px|200px]]

Figure 16: Equipment set up

'''4.2 Results'''

Case 0: Normal conditions (No-alarm)

The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.

Test 1

The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.

[[File:17.png|x200px|200px]]

Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]

Figure 18: Histogram of device RTTs over two time periods

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 3102μs

Difference in RTT CDF 1.05%

Table 2: Case 0, test 1 results

The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.

Test 2

The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.

[[File:19.png|x200px|200px]]

Figure 19: Histogram of device RTTs at two different times

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 2572μs

Difference in RTT CDF -0.09%

Table 3: Case 0, test 2 results

The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.

Case 1: Malicious switch inserted (Alarm)

Test 1

The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.

[[File:20.png|x200px|200px]]

Figure 20: Layout with extra malicious switch inserted (SB)

[[File:21.png|x200px|200px]]

Figure 21: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 4348μs

Difference in RTT CDF 3.43%

Table 4: Case 1, test 1 results

In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.

Test 2

A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.

[[File:22.png|x200px|200px]]

Figure 22: Layout with extra malicious switch inserted (SA)

[[File:23.png|x200px|200px]]

Figure 23: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 5807μs

Difference in RTT CDF 2.80%

Table 5: Case 1, test 2 results

Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)

The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.

[[File:24.png|x200px|200px]]

Figure 24: Layout with extra PC polling PLC

The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)

This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.

[[File:25.png|x200px|200px]]

Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 3181μs

Difference in RTT CDF 2.351%

Table 6: Case 3 results

It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.

Case 4: Two switches with high load on one switch (No-alarm)

This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).

[[File:26.png|x200px|200px]]

Figure 26: Normal layout for new fingerprint case

[[File:27.png|x200px|200px]]

Figure 27: Normal layout with extra devices transferring data – No alarm

[[File:28.png|x200px|200px]]

Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm

Distribution 1 maximum RTT 3183μs

Distribution 2 maximum RTT 2794μs

Difference in RTT CDF 0.360%

Table 7: Case 4 results

The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.

'''4.3 Discussion'''

From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.

Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.

Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.

'''4.4 Future Work'''

For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.

Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.

These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.

It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.

These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''

'''7.1.1 Work Breakdown'''

The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.

Introduction and literature review

Understand IP characteristics

Plan how software will be used to aid analysis

Explore different methods that could be used for fingerprint creation

TTL fingerprinting

IP Identification numbers

Transmission times

Developing final software tool

3.1 Combine methods into one fingerprint creation tool

3.2 Analyses traffic to check fingerprint

3.3 Test on larger scale systems

3.4 Conclusion of findings

'''7.1.2 Timeline'''

The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.

Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.

Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.

Table 1: Project Timeline (dates)

Research existing authentication methods (29/02/2016-11/04/2016)

Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)

MILESTONE: Draft 1 of Thesis due on 22/04/2016

Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)

Time to Live characteristics

IP identification number characteristics

Transmission time characteristics

Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)

Build and test fingerprint creation tool

Build and test traffic monitoring tool

Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)

Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)

Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)

MILESTONE: Draft 2 of Thesis due on 04/06/2016

Update Thesis as required from feedback (20/06/2016-20/10/2016)

MILESTONE: Final Thesis due on 21/10/2016

10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)

MILESTONE: Exhibition (24/10/2016-28/10/2016)

MILESTONE: Final seminar (31/10/2016-04/11/2016)

'''7.1.3 Budget'''

Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.

'''7.1.4 Risk Analysis'''

The following risks may affect the project:

Loss of work

This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)

Not completing work in time

This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.

Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''

'''7.2.1 IP address conversions'''

Conversion from dotted decimal to integer:

splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))

Conversion from integer to dotted decimal:

strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))

MATLAB ping

[[File:30.png]]

'''7.2.3 IP ID analyser'''

[[File:31.png]]

'''7.2.4 Round Trip Time analyser'''

[[File:32.png]]

'''7.2.5 CDF difference calculator'''

[[File:33a.png]]

'''7.3 Output'''

7.3.1 Section 3.4.2 Test 1 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:34.png]]

7.3.2 Section 3.4.2 Test 2 output

First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID

[[File:35.png]]

'''7.4 Estonia Tour Report'''

During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.

'''7.4.1 Introduction'''

The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.

'''7.4.2 Positives'''

The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.

A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.

'''7.4.3 Personal Highlights'''

My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.

We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.

'''7.4.4 Recommendations'''

I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:19:12Z

A1645994: /* 5 Conclusion */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.

'''3.1 Background Theory'''

This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.

'''3.1.1 Simulation Method'''

A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.

'''3.1.2 Wireshark'''

Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).

'''3.1.3 Matlab'''

Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.

'''3.1.3 Internet Protocol Packet Information'''

Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]

Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''

The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers

'''3.3 Method 1: Time to Live Fingerprinting'''

TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.

'''3.3.1 Time to Live Characteristics'''

Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.

It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].

'''3.3.2 Design'''

The network will be set up as follows for a normal operating condition:

[[File:2a.png|x200px|200px]]

Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:

[[File:3a.png|x200px|200px]]

Figure 3: Client's network location changed

'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.

This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.

A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.

'''3.3.4 Results'''

The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.

'''3.3.5 Discussion'''

Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.

'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''

The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.

'''3.4.1 Internet Protocol Identification Numbers'''

The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.

'''3.4.2 Method'''

Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''

The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.

Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)

[[File:4a.png|x200px|200px]]

Figure 4: Difference in IPID under normal conditions

'''Test 2: IPID change under higher data transfer rate'''

The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]

Figure 5: Difference in IPID when a file is being transferred over network

'''Test 3: IPID values with two client devices'''

The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.

[[File:6a.png|x200px|200px]]

Figure 6: IPID numbers received from two clients

'''Test 4: Long term IPID characteristics for fingerprinting'''

The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.

[[File:7a.png|x200px|200px]]

Figure 7: Difference in IPID numbers over a five-hour time period

'''3.4.3 Results'''

The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.

Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.

Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.

Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.

'''3.4.4 Discussion and future work'''

The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.

'''3.5 Method 3: Transmission Time Fingerprinting'''

The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.

'''3.5.1 Factors Affecting Transmission Time'''

RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.

The following formula summarises these delays:

dRTT = dprop + dqueue + dproc + dresp

dRTT – RTT

dprop – Propagation delay over medium

dqueue – Queuing delay at switch depending on how busy it is

dproc – Total processing delay of interconnecting routers and switches

dresp – Response time of device being pinged

'''3.5.2 Method'''

The initial setup involved connecting two PCs via a switch.

Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.

Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.

Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)

'''3.5.3 Results'''

[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]

Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions

The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.

[[File:10a.png|x200px|200px]]

'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''

It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.

'''3.5.4 Discussion'''

It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.

'''3.6 Kullback-Leibler divergence and DRTT'''

Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.

As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.

A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)

𝛼 > 0

N(𝜃,𝜎)- Random extra delay

The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].

[[File:11a.png|x200px|200px]]

Figure 11: DRTT in fingerprint vs same device over different period

[[File:12.png|x200px|200px]]

Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.

The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.

In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.

'''3.7 CDF of Client RTT'''

In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]

Figure 13: Histogram of device RTTs over 2 different time periods

[[File:14.png|x200px|200px]]

Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions

A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]

Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.

[[File:15.png|x200px|200px]]

Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)

The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.

The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.

[[File:eq1a.png|x200px|200px]]

Equation 1: Finding the difference between two CDFs

'''3.8 Sample window size and costs of making a decision'''

The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.

A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.

It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.

'''4.1 Method'''

In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.

Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.

Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.

These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.

The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change

Trigger multiple device access alarm

Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint

If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured

Trigger topography changed alarm

Else If (absolute(CDFdiff¬) > 1.5%)

Trigger programming changed alarm

The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.

Picture of set up

[[File:16a_copy.png|x200px|200px]]

Figure 16: Equipment set up

'''4.2 Results'''

Case 0: Normal conditions (No-alarm)

The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.

Test 1

The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.

[[File:17.png|x200px|200px]]

Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]

Figure 18: Histogram of device RTTs over two time periods

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 3102μs

Difference in RTT CDF 1.05%

Table 2: Case 0, test 1 results

The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.

Test 2

The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.

[[File:19.png|x200px|200px]]

Figure 19: Histogram of device RTTs at two different times

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 2572μs

Difference in RTT CDF -0.09%

Table 3: Case 0, test 2 results

The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.

Case 1: Malicious switch inserted (Alarm)

Test 1

The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.

[[File:20.png|x200px|200px]]

Figure 20: Layout with extra malicious switch inserted (SB)

[[File:21.png|x200px|200px]]

Figure 21: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 4348μs

Difference in RTT CDF 3.43%

Table 4: Case 1, test 1 results

In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.

Test 2

A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.

[[File:22.png|x200px|200px]]

Figure 22: Layout with extra malicious switch inserted (SA)

[[File:23.png|x200px|200px]]

Figure 23: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 5807μs

Difference in RTT CDF 2.80%

Table 5: Case 1, test 2 results

Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)

The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.

[[File:24.png|x200px|200px]]

Figure 24: Layout with extra PC polling PLC

The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)

This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.

[[File:25.png|x200px|200px]]

Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 3181μs

Difference in RTT CDF 2.351%

Table 6: Case 3 results

It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.

Case 4: Two switches with high load on one switch (No-alarm)

This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).

[[File:26.png|x200px|200px]]

Figure 26: Normal layout for new fingerprint case

[[File:27.png|x200px|200px]]

Figure 27: Normal layout with extra devices transferring data – No alarm

[[File:28.png|x200px|200px]]

Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm

Distribution 1 maximum RTT 3183μs

Distribution 2 maximum RTT 2794μs

Difference in RTT CDF 0.360%

Table 7: Case 4 results

The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.

'''4.3 Discussion'''

From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.

Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.

Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.

'''4.4 Future Work'''

For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.

Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.

These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.

It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.

These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''
'''7.1.1 Work Breakdown'''
The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.
Introduction and literature review
Understand IP characteristics
Plan how software will be used to aid analysis
Explore different methods that could be used for fingerprint creation
TTL fingerprinting
IP Identification numbers
Transmission times
Developing final software tool
3.1 Combine methods into one fingerprint creation tool
3.2 Analyses traffic to check fingerprints
3.3 Test on larger scale systems
3.4 Conclusion of findings

'''7.1.2 Timeline'''
The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.
Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.
Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.
Table 1: Project Timeline (dates)
Research existing authentication methods (29/02/2016-11/04/2016)
Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)
MILESTONE: Draft 1 of Thesis due on 22/04/2016
Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)
Time to Live characteristics
IP identification number characteristics
Transmission time characteristics
Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)
Build and test fingerprint creation tool
Build and test traffic monitoring tool
Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)
Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)
Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)
MILESTONE: Draft 2 of Thesis due on 04/06/2016
Update Thesis as required from feedback (20/06/2016-20/10/2016)
MILESTONE: Final Thesis due on 21/10/2016
10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)
MILESTONE: Exhibition (24/10/2016-28/10/2016)
MILESTONE: Final seminar (31/10/2016-04/11/2016)
'''7.1.3 Budget'''
Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.
'''7.1.4 Risk Analysis'''
The following risks may affect the project:
Loss of work
This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)
Not completing work in time
This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.
Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''
'''7.2.1 IP address conversions'''
Conversion from dotted decimal to integer:
splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))
Conversion from integer to dotted decimal:
strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))
MATLAB ping

'''7.2.3 IP ID analyser'''
[[File:30.png]]
'''7.2.4 Round Trip Time analyser'''
[[File:31.png]]
'''7.2.5 CDF difference calculator'''
[[File:32.png]]
'''7.3 Output'''
7.3.1 Section 3.4.2 Test 1 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:33a.png]]

7.3.2 Section 3.4.2 Test 2 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:34.png]]

'''7.4 Estonia Tour Report'''
During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.
'''7.4.1 Introduction'''
The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.
'''7.4.2 Positives'''
The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.
A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.
'''7.4.3 Personal Highlights'''
My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.
We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.
'''7.4.4 Recommendations'''
I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:18:22Z

A1645994: /* 4 Implementing Fingerprinting Techniques */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.

'''3.1 Background Theory'''

This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.

'''3.1.1 Simulation Method'''

A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.

'''3.1.2 Wireshark'''

Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).

'''3.1.3 Matlab'''

Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.

'''3.1.3 Internet Protocol Packet Information'''

Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]

Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''

The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers

'''3.3 Method 1: Time to Live Fingerprinting'''

TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.

'''3.3.1 Time to Live Characteristics'''

Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.

It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].

'''3.3.2 Design'''

The network will be set up as follows for a normal operating condition:

[[File:2a.png|x200px|200px]]

Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:

[[File:3a.png|x200px|200px]]

Figure 3: Client's network location changed

'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.

This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.

A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.

'''3.3.4 Results'''

The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.

'''3.3.5 Discussion'''

Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.

'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''

The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.

'''3.4.1 Internet Protocol Identification Numbers'''

The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.

'''3.4.2 Method'''

Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''

The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.

Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)

[[File:4a.png|x200px|200px]]

Figure 4: Difference in IPID under normal conditions

'''Test 2: IPID change under higher data transfer rate'''

The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]

Figure 5: Difference in IPID when a file is being transferred over network

'''Test 3: IPID values with two client devices'''

The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.

[[File:6a.png|x200px|200px]]

Figure 6: IPID numbers received from two clients

'''Test 4: Long term IPID characteristics for fingerprinting'''

The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.

[[File:7a.png|x200px|200px]]

Figure 7: Difference in IPID numbers over a five-hour time period

'''3.4.3 Results'''

The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.

Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.

Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.

Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.

'''3.4.4 Discussion and future work'''

The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.

'''3.5 Method 3: Transmission Time Fingerprinting'''

The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.

'''3.5.1 Factors Affecting Transmission Time'''

RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.

The following formula summarises these delays:

dRTT = dprop + dqueue + dproc + dresp

dRTT – RTT

dprop – Propagation delay over medium

dqueue – Queuing delay at switch depending on how busy it is

dproc – Total processing delay of interconnecting routers and switches

dresp – Response time of device being pinged

'''3.5.2 Method'''

The initial setup involved connecting two PCs via a switch.

Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.

Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.

Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)

'''3.5.3 Results'''

[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]

Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions

The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.

[[File:10a.png|x200px|200px]]

'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''

It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.

'''3.5.4 Discussion'''

It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.

'''3.6 Kullback-Leibler divergence and DRTT'''

Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.

As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.

A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)

𝛼 > 0

N(𝜃,𝜎)- Random extra delay

The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].

[[File:11a.png|x200px|200px]]

Figure 11: DRTT in fingerprint vs same device over different period

[[File:12.png|x200px|200px]]

Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.

The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.

In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.

'''3.7 CDF of Client RTT'''

In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]

Figure 13: Histogram of device RTTs over 2 different time periods

[[File:14.png|x200px|200px]]

Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions

A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]

Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.

[[File:15.png|x200px|200px]]

Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)

The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.

The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.

[[File:eq1a.png|x200px|200px]]

Equation 1: Finding the difference between two CDFs

'''3.8 Sample window size and costs of making a decision'''

The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.

A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.

It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.

'''4.1 Method'''

In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.

Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.

Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.

These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.

The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change

Trigger multiple device access alarm

Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint

If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured

Trigger topography changed alarm

Else If (absolute(CDFdiff¬) > 1.5%)

Trigger programming changed alarm

The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.

Picture of set up

[[File:16a_copy.png|x200px|200px]]

Figure 16: Equipment set up

'''4.2 Results'''

Case 0: Normal conditions (No-alarm)

The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.

Test 1

The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.

[[File:17.png|x200px|200px]]

Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]

Figure 18: Histogram of device RTTs over two time periods

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 3102μs

Difference in RTT CDF 1.05%

Table 2: Case 0, test 1 results

The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.

Test 2

The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.

[[File:19.png|x200px|200px]]

Figure 19: Histogram of device RTTs at two different times

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 2572μs

Difference in RTT CDF -0.09%

Table 3: Case 0, test 2 results

The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.

Case 1: Malicious switch inserted (Alarm)

Test 1

The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.

[[File:20.png|x200px|200px]]

Figure 20: Layout with extra malicious switch inserted (SB)

[[File:21.png|x200px|200px]]

Figure 21: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 4348μs

Difference in RTT CDF 3.43%

Table 4: Case 1, test 1 results

In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.

Test 2

A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.

[[File:22.png|x200px|200px]]

Figure 22: Layout with extra malicious switch inserted (SA)

[[File:23.png|x200px|200px]]

Figure 23: Histogram of device RTTs under normal and attack cases

Distribution 1 maximum RTT 3347μs

Distribution 2 maximum RTT 5807μs

Difference in RTT CDF 2.80%

Table 5: Case 1, test 2 results

Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)

The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.

[[File:24.png|x200px|200px]]

Figure 24: Layout with extra PC polling PLC

The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)

This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.

[[File:25.png|x200px|200px]]

Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed

Distribution 1 maximum RTT 3253μs

Distribution 2 maximum RTT 3181μs

Difference in RTT CDF 2.351%

Table 6: Case 3 results

It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.

Case 4: Two switches with high load on one switch (No-alarm)

This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).

[[File:26.png|x200px|200px]]

Figure 26: Normal layout for new fingerprint case

[[File:27.png|x200px|200px]]

Figure 27: Normal layout with extra devices transferring data – No alarm

[[File:28.png|x200px|200px]]

Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm

Distribution 1 maximum RTT 3183μs

Distribution 2 maximum RTT 2794μs

Difference in RTT CDF 0.360%

Table 7: Case 4 results

The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.

'''4.3 Discussion'''

From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.

Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.

Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.

'''4.4 Future Work'''

For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.

Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.

These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.

It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.
These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''
'''7.1.1 Work Breakdown'''
The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.
Introduction and literature review
Understand IP characteristics
Plan how software will be used to aid analysis
Explore different methods that could be used for fingerprint creation
TTL fingerprinting
IP Identification numbers
Transmission times
Developing final software tool
3.1 Combine methods into one fingerprint creation tool
3.2 Analyses traffic to check fingerprints
3.3 Test on larger scale systems
3.4 Conclusion of findings

'''7.1.2 Timeline'''
The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.
Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.
Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.
Table 1: Project Timeline (dates)
Research existing authentication methods (29/02/2016-11/04/2016)
Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)
MILESTONE: Draft 1 of Thesis due on 22/04/2016
Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)
Time to Live characteristics
IP identification number characteristics
Transmission time characteristics
Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)
Build and test fingerprint creation tool
Build and test traffic monitoring tool
Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)
Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)
Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)
MILESTONE: Draft 2 of Thesis due on 04/06/2016
Update Thesis as required from feedback (20/06/2016-20/10/2016)
MILESTONE: Final Thesis due on 21/10/2016
10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)
MILESTONE: Exhibition (24/10/2016-28/10/2016)
MILESTONE: Final seminar (31/10/2016-04/11/2016)
'''7.1.3 Budget'''
Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.
'''7.1.4 Risk Analysis'''
The following risks may affect the project:
Loss of work
This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)
Not completing work in time
This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.
Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''
'''7.2.1 IP address conversions'''
Conversion from dotted decimal to integer:
splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))
Conversion from integer to dotted decimal:
strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))
MATLAB ping

'''7.2.3 IP ID analyser'''
[[File:30.png]]
'''7.2.4 Round Trip Time analyser'''
[[File:31.png]]
'''7.2.5 CDF difference calculator'''
[[File:32.png]]
'''7.3 Output'''
7.3.1 Section 3.4.2 Test 1 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:33a.png]]

7.3.2 Section 3.4.2 Test 2 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:34.png]]

'''7.4 Estonia Tour Report'''
During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.
'''7.4.1 Introduction'''
The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.
'''7.4.2 Positives'''
The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.
A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.
'''7.4.3 Personal Highlights'''
My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.
We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.
'''7.4.4 Recommendations'''
I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:15:07Z

A1645994: /* 3 Finding characteristics and creating fingerprints */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.

'''3.1 Background Theory'''

This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.

'''3.1.1 Simulation Method'''

A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.

'''3.1.2 Wireshark'''

Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).

'''3.1.3 Matlab'''

Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.

'''3.1.3 Internet Protocol Packet Information'''

Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]

Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''

The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers

'''3.3 Method 1: Time to Live Fingerprinting'''

TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.

'''3.3.1 Time to Live Characteristics'''

Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.

It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].

'''3.3.2 Design'''

The network will be set up as follows for a normal operating condition:

[[File:2a.png|x200px|200px]]

Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:

[[File:3a.png|x200px|200px]]

Figure 3: Client's network location changed

'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.

This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.

A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.

'''3.3.4 Results'''

The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.

'''3.3.5 Discussion'''

Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.

'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''

The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.

'''3.4.1 Internet Protocol Identification Numbers'''

The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.

'''3.4.2 Method'''

Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''

The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.

Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)

[[File:4a.png|x200px|200px]]

Figure 4: Difference in IPID under normal conditions

'''Test 2: IPID change under higher data transfer rate'''

The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]

Figure 5: Difference in IPID when a file is being transferred over network

'''Test 3: IPID values with two client devices'''

The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.

[[File:6a.png|x200px|200px]]

Figure 6: IPID numbers received from two clients

'''Test 4: Long term IPID characteristics for fingerprinting'''

The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.

[[File:7a.png|x200px|200px]]

Figure 7: Difference in IPID numbers over a five-hour time period

'''3.4.3 Results'''

The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.

Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.

Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.

Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.

'''3.4.4 Discussion and future work'''

The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.

'''3.5 Method 3: Transmission Time Fingerprinting'''

The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.

'''3.5.1 Factors Affecting Transmission Time'''

RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.

The following formula summarises these delays:

dRTT = dprop + dqueue + dproc + dresp

dRTT – RTT

dprop – Propagation delay over medium

dqueue – Queuing delay at switch depending on how busy it is

dproc – Total processing delay of interconnecting routers and switches

dresp – Response time of device being pinged

'''3.5.2 Method'''

The initial setup involved connecting two PCs via a switch.

Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.

Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.

Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)

'''3.5.3 Results'''

[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]

Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions

The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.

[[File:10a.png|x200px|200px]]

'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''

It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.

'''3.5.4 Discussion'''

It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.

'''3.6 Kullback-Leibler divergence and DRTT'''

Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.

As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.

A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)

𝛼 > 0

N(𝜃,𝜎)- Random extra delay

The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].

[[File:11a.png|x200px|200px]]

Figure 11: DRTT in fingerprint vs same device over different period

[[File:12.png|x200px|200px]]

Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.

The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.

In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.

'''3.7 CDF of Client RTT'''

In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]

Figure 13: Histogram of device RTTs over 2 different time periods

[[File:14.png|x200px|200px]]

Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions

A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]

Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.

[[File:15.png|x200px|200px]]

Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)

The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.

The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.

[[File:eq1a.png|x200px|200px]]

Equation 1: Finding the difference between two CDFs

'''3.8 Sample window size and costs of making a decision'''

The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.

A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.

It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.
'''4.1 Method'''
In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.
Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.
Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.
These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.
The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change
Trigger multiple device access alarm
Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint
If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured
Trigger topography changed alarm
Else If (absolute(CDFdiff¬) > 1.5%)
Trigger programming changed alarm
The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.
Equipment key
SA – Samsung CY-SWR1100 switch (Switch A)
SB – Allen Bradley Stratix 2000 switch (Switch B)
PLC – Allen Bradley Micrologix 1100 (Programmable Logic Controller)
Picture of set up
[[File:16a_copy.png|x200px|200px]]
Figure 16: Equipment set up
4.2 Results
Case 0: Normal conditions (No-alarm)
The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.
Test 1
The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.
[[File:17.png|x200px|200px]]
Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]
Figure 18: Histogram of device RTTs over two time periods
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 3102μs
Difference in RTT CDF 1.05%
Table 2: Case 0, test 1 results
The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.
Test 2
The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.
[[File:19.png|x200px|200px]]
Figure 19: Histogram of device RTTs at two different times
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 2572μs
Difference in RTT CDF -0.09%
Table 3: Case 0, test 2 results
The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.
Case 1: Malicious switch inserted (Alarm)
Test 1
The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.
[[File:20.png|x200px|200px]]
Figure 20: Layout with extra malicious switch inserted (SB)
[[File:21.png|x200px|200px]]
Figure 21: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 4348μs
Difference in RTT CDF 3.43%
Table 4: Case 1, test 1 results
In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.
Test 2
A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.
[[File:22.png|x200px|200px]]
Figure 22: Layout with extra malicious switch inserted (SA)
[[File:23.png|x200px|200px]]
Figure 23: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 5807μs
Difference in RTT CDF 2.80%
Table 5: Case 1, test 2 results
Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)
The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.
[[File:24.png|x200px|200px]]
Figure 24: Layout with extra PC polling PLC
The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)
This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.
[[File:25.png|x200px|200px]]
Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 3181μs
Difference in RTT CDF 2.351%
Table 6: Case 3 results
It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.
Case 4: Two switches with high load on one switch (No-alarm)
This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).
[[File:26.png|x200px|200px]]
Figure 26: Normal layout for new fingerprint case
[[File:27.png|x200px|200px]]
Figure 27: Normal layout with extra devices transferring data – No alarm
[[File:28.png|x200px|200px]]
Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm
Distribution 1 maximum RTT 3183μs
Distribution 2 maximum RTT 2794μs
Difference in RTT CDF 0.360%
Table 7: Case 4 results
The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.
'''4.3 Discussion'''
From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.
Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.
Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.
'''4.4 Future Work'''
For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.
Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.
These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.
It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.
These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''
'''7.1.1 Work Breakdown'''
The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.
Introduction and literature review
Understand IP characteristics
Plan how software will be used to aid analysis
Explore different methods that could be used for fingerprint creation
TTL fingerprinting
IP Identification numbers
Transmission times
Developing final software tool
3.1 Combine methods into one fingerprint creation tool
3.2 Analyses traffic to check fingerprints
3.3 Test on larger scale systems
3.4 Conclusion of findings

'''7.1.2 Timeline'''
The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.
Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.
Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.
Table 1: Project Timeline (dates)
Research existing authentication methods (29/02/2016-11/04/2016)
Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)
MILESTONE: Draft 1 of Thesis due on 22/04/2016
Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)
Time to Live characteristics
IP identification number characteristics
Transmission time characteristics
Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)
Build and test fingerprint creation tool
Build and test traffic monitoring tool
Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)
Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)
Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)
MILESTONE: Draft 2 of Thesis due on 04/06/2016
Update Thesis as required from feedback (20/06/2016-20/10/2016)
MILESTONE: Final Thesis due on 21/10/2016
10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)
MILESTONE: Exhibition (24/10/2016-28/10/2016)
MILESTONE: Final seminar (31/10/2016-04/11/2016)
'''7.1.3 Budget'''
Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.
'''7.1.4 Risk Analysis'''
The following risks may affect the project:
Loss of work
This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)
Not completing work in time
This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.
Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''
'''7.2.1 IP address conversions'''
Conversion from dotted decimal to integer:
splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))
Conversion from integer to dotted decimal:
strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))
MATLAB ping

'''7.2.3 IP ID analyser'''
[[File:30.png]]
'''7.2.4 Round Trip Time analyser'''
[[File:31.png]]
'''7.2.5 CDF difference calculator'''
[[File:32.png]]
'''7.3 Output'''
7.3.1 Section 3.4.2 Test 1 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:33a.png]]

7.3.2 Section 3.4.2 Test 2 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:34.png]]

'''7.4 Estonia Tour Report'''
During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.
'''7.4.1 Introduction'''
The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.
'''7.4.2 Positives'''
The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.
A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.
'''7.4.3 Personal Highlights'''
My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.
We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.
'''7.4.4 Recommendations'''
I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:11:17Z

A1645994: /* 2 Background */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

'''2.1 Technical Background'''

The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].

Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].

Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].

One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].

Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].

'''2.2 Project Aims'''

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.

'''2.3 Literature Review'''

Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.

Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.

Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.

In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.

Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.

Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.
'''3.1 Background Theory'''
This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.
'''3.1.1 Simulation Method'''
A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.
'''3.1.2 Wireshark'''
Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).
'''3.1.3 Matlab'''
Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.
'''3.1.3 Internet Protocol Packet Information'''
Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]
Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''
The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers
'''3.3 Method 1: Time to Live Fingerprinting'''
TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.
'''3.3.1 Time to Live Characteristics'''
Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.
It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].
'''3.3.2 Design'''
The network will be set up as follows for a normal operating condition:
[[File:2a.png|x200px|200px]]
Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:
[[File:3a.png|x200px|200px]]
Figure 3: Client's network location changed
'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.
This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.
A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.
'''3.3.4 Results'''
The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.
'''3.3.5 Discussion'''
Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.
'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''
The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.
'''3.4.1 Internet Protocol Identification Numbers'''
The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.
'''3.4.2 Method'''
Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''
The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.
Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)
[[File:4a.png|x200px|200px]]
Figure 4: Difference in IPID under normal conditions
'''Test 2: IPID change under higher data transfer rate'''
The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]
Figure 5: Difference in IPID when a file is being transferred over network
'''Test 3: IPID values with two client devices'''
The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.
[[File:6a.png|x200px|200px]]
Figure 6: IPID numbers received from two clients
'''Test 4: Long term IPID characteristics for fingerprinting'''
The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.
[[File:7a.png|x200px|200px]]
Figure 7: Difference in IPID numbers over a five-hour time period
'''3.4.3 Results'''
The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.
Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.
Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.
Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.
'''3.4.4 Discussion and future work'''
The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.
'''3.5 Method 3: Transmission Time Fingerprinting'''
The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.
3.5.1 Factors Affecting Transmission Time
RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.
The following formula summarises these delays:
dRTT = dprop + dqueue + dproc + dresp
dRTT – RTT
dprop – Propagation delay over medium
dqueue – Queuing delay at switch depending on how busy it is
dproc – Total processing delay of interconnecting routers and switches
dresp – Response time of device being pinged
'''3.5.2 Method'''
The initial setup involved connecting two PCs via a switch.
Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.
Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.
Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)
'''3.5.3 Results'''
[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]
Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions
The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.
[[File:10a.png|x200px|200px]]
'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''
It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.
'''3.5.4 Discussion'''
It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.
'''3.6 Kullback-Leibler divergence and DRTT'''
Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.
As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.
A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)
𝛼 > 0
N(𝜃,𝜎)- Random extra delay
The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].
[[File:11a.png|x200px|200px]]
Figure 11: DRTT in fingerprint vs same device over different period
[[File:12.png|x200px|200px]]
Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.
The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.
In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.
'''3.7 CDF of Client RTT'''
In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]
Figure 13: Histogram of device RTTs over 2 different time periods
[[File:14.png|x200px|200px]]
Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions
A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]
Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.
[[File:15.png|x200px|200px]]
Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)
The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.
The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.
[[File:eq1a.png|x200px|200px]]
Equation 1: Finding the difference between two CDFs
'''3.8 Sample window size and costs of making a decision'''
The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.
A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.
It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.
'''4.1 Method'''
In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.
Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.
Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.
These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.
The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change
Trigger multiple device access alarm
Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint
If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured
Trigger topography changed alarm
Else If (absolute(CDFdiff¬) > 1.5%)
Trigger programming changed alarm
The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.
Equipment key
SA – Samsung CY-SWR1100 switch (Switch A)
SB – Allen Bradley Stratix 2000 switch (Switch B)
PLC – Allen Bradley Micrologix 1100 (Programmable Logic Controller)
Picture of set up
[[File:16a_copy.png|x200px|200px]]
Figure 16: Equipment set up
4.2 Results
Case 0: Normal conditions (No-alarm)
The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.
Test 1
The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.
[[File:17.png|x200px|200px]]
Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]
Figure 18: Histogram of device RTTs over two time periods
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 3102μs
Difference in RTT CDF 1.05%
Table 2: Case 0, test 1 results
The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.
Test 2
The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.
[[File:19.png|x200px|200px]]
Figure 19: Histogram of device RTTs at two different times
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 2572μs
Difference in RTT CDF -0.09%
Table 3: Case 0, test 2 results
The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.
Case 1: Malicious switch inserted (Alarm)
Test 1
The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.
[[File:20.png|x200px|200px]]
Figure 20: Layout with extra malicious switch inserted (SB)
[[File:21.png|x200px|200px]]
Figure 21: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 4348μs
Difference in RTT CDF 3.43%
Table 4: Case 1, test 1 results
In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.
Test 2
A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.
[[File:22.png|x200px|200px]]
Figure 22: Layout with extra malicious switch inserted (SA)
[[File:23.png|x200px|200px]]
Figure 23: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 5807μs
Difference in RTT CDF 2.80%
Table 5: Case 1, test 2 results
Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)
The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.
[[File:24.png|x200px|200px]]
Figure 24: Layout with extra PC polling PLC
The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)
This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.
[[File:25.png|x200px|200px]]
Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 3181μs
Difference in RTT CDF 2.351%
Table 6: Case 3 results
It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.
Case 4: Two switches with high load on one switch (No-alarm)
This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).
[[File:26.png|x200px|200px]]
Figure 26: Normal layout for new fingerprint case
[[File:27.png|x200px|200px]]
Figure 27: Normal layout with extra devices transferring data – No alarm
[[File:28.png|x200px|200px]]
Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm
Distribution 1 maximum RTT 3183μs
Distribution 2 maximum RTT 2794μs
Difference in RTT CDF 0.360%
Table 7: Case 4 results
The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.
'''4.3 Discussion'''
From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.
Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.
Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.
'''4.4 Future Work'''
For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.
Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.
These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.
It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.
These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''
'''7.1.1 Work Breakdown'''
The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.
Introduction and literature review
Understand IP characteristics
Plan how software will be used to aid analysis
Explore different methods that could be used for fingerprint creation
TTL fingerprinting
IP Identification numbers
Transmission times
Developing final software tool
3.1 Combine methods into one fingerprint creation tool
3.2 Analyses traffic to check fingerprints
3.3 Test on larger scale systems
3.4 Conclusion of findings

'''7.1.2 Timeline'''
The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.
Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.
Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.
Table 1: Project Timeline (dates)
Research existing authentication methods (29/02/2016-11/04/2016)
Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)
MILESTONE: Draft 1 of Thesis due on 22/04/2016
Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)
Time to Live characteristics
IP identification number characteristics
Transmission time characteristics
Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)
Build and test fingerprint creation tool
Build and test traffic monitoring tool
Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)
Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)
Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)
MILESTONE: Draft 2 of Thesis due on 04/06/2016
Update Thesis as required from feedback (20/06/2016-20/10/2016)
MILESTONE: Final Thesis due on 21/10/2016
10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)
MILESTONE: Exhibition (24/10/2016-28/10/2016)
MILESTONE: Final seminar (31/10/2016-04/11/2016)
'''7.1.3 Budget'''
Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.
'''7.1.4 Risk Analysis'''
The following risks may affect the project:
Loss of work
This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)
Not completing work in time
This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.
Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''
'''7.2.1 IP address conversions'''
Conversion from dotted decimal to integer:
splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))
Conversion from integer to dotted decimal:
strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))
MATLAB ping

'''7.2.3 IP ID analyser'''
[[File:30.png]]
'''7.2.4 Round Trip Time analyser'''
[[File:31.png]]
'''7.2.5 CDF difference calculator'''
[[File:32.png]]
'''7.3 Output'''
7.3.1 Section 3.4.2 Test 1 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:33a.png]]

7.3.2 Section 3.4.2 Test 2 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:34.png]]

'''7.4 Estonia Tour Report'''
During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.
'''7.4.1 Introduction'''
The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.
'''7.4.2 Positives'''
The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.
A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.
'''7.4.3 Personal Highlights'''
My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.
We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.
'''7.4.4 Recommendations'''
I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:10:20Z

A1645994: /* 1 Introduction */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.

Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.

This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.

The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

2.1 Technical Background
The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].
Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].
Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].
One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].
Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].
2.2 Project Aims
The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.
2.3 Literature Review
Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.
Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.
Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.
In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.
Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.
Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.
'''3.1 Background Theory'''
This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.
'''3.1.1 Simulation Method'''
A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.
'''3.1.2 Wireshark'''
Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).
'''3.1.3 Matlab'''
Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.
'''3.1.3 Internet Protocol Packet Information'''
Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]
Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''
The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers
'''3.3 Method 1: Time to Live Fingerprinting'''
TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.
'''3.3.1 Time to Live Characteristics'''
Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.
It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].
'''3.3.2 Design'''
The network will be set up as follows for a normal operating condition:
[[File:2a.png|x200px|200px]]
Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:
[[File:3a.png|x200px|200px]]
Figure 3: Client's network location changed
'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.
This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.
A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.
'''3.3.4 Results'''
The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.
'''3.3.5 Discussion'''
Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.
'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''
The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.
'''3.4.1 Internet Protocol Identification Numbers'''
The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.
'''3.4.2 Method'''
Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''
The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.
Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)
[[File:4a.png|x200px|200px]]
Figure 4: Difference in IPID under normal conditions
'''Test 2: IPID change under higher data transfer rate'''
The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]
Figure 5: Difference in IPID when a file is being transferred over network
'''Test 3: IPID values with two client devices'''
The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.
[[File:6a.png|x200px|200px]]
Figure 6: IPID numbers received from two clients
'''Test 4: Long term IPID characteristics for fingerprinting'''
The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.
[[File:7a.png|x200px|200px]]
Figure 7: Difference in IPID numbers over a five-hour time period
'''3.4.3 Results'''
The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.
Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.
Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.
Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.
'''3.4.4 Discussion and future work'''
The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.
'''3.5 Method 3: Transmission Time Fingerprinting'''
The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.
3.5.1 Factors Affecting Transmission Time
RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.
The following formula summarises these delays:
dRTT = dprop + dqueue + dproc + dresp
dRTT – RTT
dprop – Propagation delay over medium
dqueue – Queuing delay at switch depending on how busy it is
dproc – Total processing delay of interconnecting routers and switches
dresp – Response time of device being pinged
'''3.5.2 Method'''
The initial setup involved connecting two PCs via a switch.
Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.
Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.
Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)
'''3.5.3 Results'''
[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]
Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions
The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.
[[File:10a.png|x200px|200px]]
'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''
It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.
'''3.5.4 Discussion'''
It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.
'''3.6 Kullback-Leibler divergence and DRTT'''
Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.
As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.
A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)
𝛼 > 0
N(𝜃,𝜎)- Random extra delay
The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].
[[File:11a.png|x200px|200px]]
Figure 11: DRTT in fingerprint vs same device over different period
[[File:12.png|x200px|200px]]
Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.
The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.
In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.
'''3.7 CDF of Client RTT'''
In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]
Figure 13: Histogram of device RTTs over 2 different time periods
[[File:14.png|x200px|200px]]
Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions
A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]
Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.
[[File:15.png|x200px|200px]]
Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)
The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.
The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.
[[File:eq1a.png|x200px|200px]]
Equation 1: Finding the difference between two CDFs
'''3.8 Sample window size and costs of making a decision'''
The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.
A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.
It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.
'''4.1 Method'''
In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.
Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.
Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.
These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.
The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change
Trigger multiple device access alarm
Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint
If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured
Trigger topography changed alarm
Else If (absolute(CDFdiff¬) > 1.5%)
Trigger programming changed alarm
The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.
Equipment key
SA – Samsung CY-SWR1100 switch (Switch A)
SB – Allen Bradley Stratix 2000 switch (Switch B)
PLC – Allen Bradley Micrologix 1100 (Programmable Logic Controller)
Picture of set up
[[File:16a_copy.png|x200px|200px]]
Figure 16: Equipment set up
4.2 Results
Case 0: Normal conditions (No-alarm)
The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.
Test 1
The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.
[[File:17.png|x200px|200px]]
Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]
Figure 18: Histogram of device RTTs over two time periods
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 3102μs
Difference in RTT CDF 1.05%
Table 2: Case 0, test 1 results
The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.
Test 2
The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.
[[File:19.png|x200px|200px]]
Figure 19: Histogram of device RTTs at two different times
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 2572μs
Difference in RTT CDF -0.09%
Table 3: Case 0, test 2 results
The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.
Case 1: Malicious switch inserted (Alarm)
Test 1
The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.
[[File:20.png|x200px|200px]]
Figure 20: Layout with extra malicious switch inserted (SB)
[[File:21.png|x200px|200px]]
Figure 21: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 4348μs
Difference in RTT CDF 3.43%
Table 4: Case 1, test 1 results
In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.
Test 2
A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.
[[File:22.png|x200px|200px]]
Figure 22: Layout with extra malicious switch inserted (SA)
[[File:23.png|x200px|200px]]
Figure 23: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 5807μs
Difference in RTT CDF 2.80%
Table 5: Case 1, test 2 results
Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)
The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.
[[File:24.png|x200px|200px]]
Figure 24: Layout with extra PC polling PLC
The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)
This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.
[[File:25.png|x200px|200px]]
Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 3181μs
Difference in RTT CDF 2.351%
Table 6: Case 3 results
It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.
Case 4: Two switches with high load on one switch (No-alarm)
This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).
[[File:26.png|x200px|200px]]
Figure 26: Normal layout for new fingerprint case
[[File:27.png|x200px|200px]]
Figure 27: Normal layout with extra devices transferring data – No alarm
[[File:28.png|x200px|200px]]
Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm
Distribution 1 maximum RTT 3183μs
Distribution 2 maximum RTT 2794μs
Difference in RTT CDF 0.360%
Table 7: Case 4 results
The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.
'''4.3 Discussion'''
From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.
Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.
Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.
'''4.4 Future Work'''
For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.
Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.
These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.
It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.
These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''
'''7.1.1 Work Breakdown'''
The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.
Introduction and literature review
Understand IP characteristics
Plan how software will be used to aid analysis
Explore different methods that could be used for fingerprint creation
TTL fingerprinting
IP Identification numbers
Transmission times
Developing final software tool
3.1 Combine methods into one fingerprint creation tool
3.2 Analyses traffic to check fingerprints
3.3 Test on larger scale systems
3.4 Conclusion of findings

'''7.1.2 Timeline'''
The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.
Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.
Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.
Table 1: Project Timeline (dates)
Research existing authentication methods (29/02/2016-11/04/2016)
Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)
MILESTONE: Draft 1 of Thesis due on 22/04/2016
Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)
Time to Live characteristics
IP identification number characteristics
Transmission time characteristics
Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)
Build and test fingerprint creation tool
Build and test traffic monitoring tool
Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)
Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)
Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)
MILESTONE: Draft 2 of Thesis due on 04/06/2016
Update Thesis as required from feedback (20/06/2016-20/10/2016)
MILESTONE: Final Thesis due on 21/10/2016
10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)
MILESTONE: Exhibition (24/10/2016-28/10/2016)
MILESTONE: Final seminar (31/10/2016-04/11/2016)
'''7.1.3 Budget'''
Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.
'''7.1.4 Risk Analysis'''
The following risks may affect the project:
Loss of work
This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)
Not completing work in time
This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.
Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''
'''7.2.1 IP address conversions'''
Conversion from dotted decimal to integer:
splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))
Conversion from integer to dotted decimal:
strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))
MATLAB ping

'''7.2.3 IP ID analyser'''
[[File:30.png]]
'''7.2.4 Round Trip Time analyser'''
[[File:31.png]]
'''7.2.5 CDF difference calculator'''
[[File:32.png]]
'''7.3 Output'''
7.3.1 Section 3.4.2 Test 1 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:33a.png]]

7.3.2 Section 3.4.2 Test 2 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:34.png]]

'''7.4 Estonia Tour Report'''
During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.
'''7.4.1 Introduction'''
The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.
'''7.4.2 Positives'''
The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.
A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.
'''7.4.3 Personal Highlights'''
My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.
We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.
'''7.4.4 Recommendations'''
I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T06:07:51Z

A1645994: /* 3 Finding characteristics and creating fingerprints */

==Michael Bassi - Engineering Change Management for Industrial Control System Security.==

'''Group Members:''' Adrian Daniele, Prescient Kannampuzha

'''Project supervisor:''' Matthew Sorell

'''Aims:'''

This research project will outline the security issues arising from the incorporation of inherently insecure industrial control networks with corporate IT networks. MiniCPS software will be used to simulate real Cyber-Physical Systems (CPS) at varying levels of hierarchy, while demonstrating security flaws and preventative measures [7]. Lastly, this project will outline the logistics involved in realistically and economically implementing these solutions throughout a variety of industries in the form of engineering change management documentation.

'''Full proposal:'''[[https://www.dropbox.com/s/bl9uix21ddkz6pv/Michael%20Bassi%20-%20Research%20Proposal%20160403.docx?dl=0]]

== Prescient Kannampuzha - Security Investigation of CAN Bus IoT network implementation and its interface to the Internet==

'''Group Members''': Adrian Daniele, Michael Bassi

'''Project supervisor''': Matthew Sorell

'''Aims''':

* Extensive literature review completed on preliminary research surrounding CAN Bus protocol security.
* Identify potential security flaws pre-existing or Discover new potential security flaws.
* Create a simulation model that can be used to evaluate the extent of flaws and level of impact on system.
* Propose possible solutions to flaws (existing) or Propose new solutions to flaws

'''Full Proposal''': [LINK]

Section last edited by [[User:A1647873|A1647873]] ([[User talk:A1647873|talk]]) 11:26, 7 April 2016 (ACST)

== '''Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint''' ==

== Abstract ==

The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. The project will primarily be looking at simple devices such as Ethernet connected Programmable Logic Controllers. The use of digital fingerprints will be explored to build up a known characteristic profile of each device’s Ethernet traffic. This will include looking at characteristics such as time to live, round trip times and Internet Protocol Identification numbers of the received packets. Once reliable methods have been established, a process will be developed that can create the fingerprint for each device and monitor it for malicious activity. In a real-life application, processes can be built into a software package that would run on a central computer and monitor devices on its local network, alerting an administrator if an anomaly is detected.

== 1 Introduction ==

The Internet of Things (IoT) involves connecting sensing and output devices to the Internet via a gateway. IoT devices are a relatively new concept and the security and authentication of these devices is rapidly developing. These devices usually aren’t in secure places and can be compromised. Hackers could trick the system into thinking these ‘things’ are still active, or providing false data. Spoofing is when a device imitates the characteristics of another device which can be used to gain control or change how a system operates. The easiest way for this to be done is called internet protocol (IP) address spoofing, where the false device takes on the IP address of the original device. This means, there is a need to find a means of device identification which can’t be easily replicated or falsified.
Current security methods involve using security certificates and challenge-response methods that are used in standard computer networks. In industrial networks, security is usually an afterthought. Allowing access to critical equipment from the internet opens up a major vulnerability in these systems. The same applies for personal Internet of Things (IoT) devices, although the consequences of a hack may not be as severe.
This project aims to find a way to identify these devices by creating a digital fingerprint that is unique to each one. This would allow devices already deployed to be monitored, whereas most research is directed to new devices and assumes they can be updated. Cost is an important factor when building IoT devices. Reducing the processing power each device needs to identify itself results in it being built more cost effectively and consuming less power.
By analysing patterns in the data transmitted over Ethernet channels, models can be built to define each device. There will be statistical models or models to simply observe how close a reading is to the device’s ‘average’ which will be used as its fingerprint. These fingerprints will then be used to monitor live devices and continually check whether they are the same device, or if they have been tampered with.
The outcome will be a process that could be implemented into IoT software packages or run in parallel, monitoring devices in real time. Devices connected in industry now link to the outside world, usually through a computer (Industrial Internet of Things). Usually these devices are simple sensor devices that are connected via Ethernet. Home PCs have much more variable traffic and it becomes more difficult to create an accurate fingerprint for them based on network characterstics.
The process will be developed by first creating a basic reference network with two devices and a router. The device’s Ethernet traffic will be monitored to create a fingerprint based on its traffic characteristics. Test cases will then be developed and executed to test for different attacks. The captured data during each attack will be analysed to see if the system can detect the anomaly.
The project will explore a range of methods to identify devices that don’t rely on certificate/key based systems. The concepts found may also apply to other digital transfer mediums such as wireless, which is increasingly being used in IoT applications. Once a device is identified, it will be monitored to determine if it has been tampered with. Where tampering is detected, a system administrator will be alerted to conduct further testing to determine the cause of the alert. This method would be effective on small scale systems, but not as effective on a large-scale system, as it would add a large amount of additional administrative burden to monitor alarms.

== 2 Background ==

2.1 Technical Background
The most common form of IoT security is public-key infrastructure (PKI) which is a system that uses certificates and allows the data traffic to be encrypted. The concept works by sharing a secret key between the two parties that want to communicate. This key is bound to a public key and a third party who can validate the connection. The issue with this method is that the key may not be stored securely on the devices. If one of the devices is accessed while the system is offline, the key can be compromised. This leads to a hacker being able to ‘impersonate’ the original device by using its key. Once keys are compromised, new keys must be issued for the devices which is another cost to businesses and a nuisance for consumers [1].
Other systems involve using a password to authenticate, but this again has many issues. Passwords can be extracted from the device, or it can be stolen by listening to the Ethernet communication channel. This can be done by software on a PC or by connecting a device in the middle of the communication channel to monitor it (man in the middle attack). Passwords can also be guessed by brute force, going through all combinations, unless other measures are in place. There are many other alternatives such as using a code book, longer codes and time based access codes, however, these still can be compromised [2].
Automation is another industry that is moving IIoT (Industrial IoT) where security is not given as much consideration. In the past, most of these systems were closed and had no access to the outside world. By making them Internet connected there are many benefits, however, a large security risk is opened up. Communication channels can be monitored by outsiders and devices can be remotely accessed or modified. Many of these devices are using old technology with small computing resources and limited bandwidth. It is common for industry to use Ethernet as the communication channel, while consumer IoT devices are moving towards wireless. The concepts found in this project may also be extended to wireless communications, however authentication over Ethernet will be the major topic of investigation [3].
Machine-to-machine (M2M) communication is another local form of communication that IoT devices will engage in. In this situation, a third party cannot be used to verify the transaction, making authentication harder. One way of authenticating these devices is using a challenge-response system. This works by one party asking a ‘question’ to the other party and the response is then verified against the expected reply. The method can also be compromised by monitoring these initial handshakes. Many of these authentication protocols add overhead to the data being transmitted, decreasing the network’s efficiency [4].
One example of how the proposed fingerprinting techniques have already been used is called “Passive OS Fingerprinting,” a form of passive network traffic monitoring. This system works by monitoring TCP packets for the Time to Live (TTL) and TCP window size values. It then compares these to known values for different operating systems (fingerprints) to identify which operating system the packets came from. This is an example of fingerprinting a device, however, when spoofing a system using a device with the same operating system, it will not be useful [5] [6].
Methods have also been found to identify spoofed IP packets using active and passive methods. An active method would involve sending packets across the network and analysing responses. Passive methods work by observing existing network traffic. Using the TTL field in the IP packet, it can be determined if the Ethernet route has changed. More testing on this can be done in a local network, as most examples are over an internet connection with many more routers in between. This means that changes in routes may occur at a higher frequency compared to a small local area network which would be static in the case with only one router to the outside world [7].
Looking at the IP Identification Number is proposed to provide another way to authenticate devices. It is associated with the devices IP and changes as packets are broken into smaller fragments. The information is then used to link the fragments and recreate the original packets. Checking the window size in the TCP header is another method but not as useful when a device is swapped with and identical device running the same operating system with similar software [8].
2.2 Project Aims
The aim of this project is to find methods of determining whether a device on a network is the one that is expected and hasn’t been tampered with. One possible attack is where a device in a network has malicious code loaded onto it, changing how it functions. The second is via a remote attacker gaining access and polling the device periodically to gain information from sensors. This could expose a system or even allow a remote attacker to control outputs of a system. The third type of attack to be tested is moving a sensor device to a different location in the network, resulting in the device providing incorrect information. Another attack would be a man-in-the-middle attack by inserting another switch which could listen in or modify data flowing through it.
Methods to build up a digital fingerprint of the device’s Ethernet traffic characteristics in a fingerprint creation phase will be explored. Once the fingerprint has been created, a network’s traffic will then be monitored and analysed for any inconsistencies. The outcome will be a process in which a fingerprint can be created and used to monitor Ethernet traffic from a particular device. The system will have applications in the home environment, with IoT devices, or industrial setups with Ethernet controllers and sensors.
2.3 Literature Review
Li and Trappe provide some methods of detecting spoofing from network traffic similar to what will be explored in this project [9] [10]. It also investigates alternative methods to cryptographic keys for authentication, although it is directed towards wireless networks. This is done by using “forge” resistant relationships, such as sequence numbers and traffic statistics. The paper states they are forge resistant, however, this will be further researched in the current project. In a normal scenario, with one device transmitting, the sequence numbers would show a monotonic pattern. If another device was added to the network to spoof the IP of the initial device, the sequence number shows a rapidly fluctuating pattern, as they are likely not to be synchronised. In the case of custom firmware being used to modify the sequence numbers to receive a monotonic pattern, duplicate sequence numbers could still be detected. Gaps between the sequence numbers were also analysed as a varying gap size is another method of detecting a spoofed device. A similar process will be used and tested on the IP identification numbers further in this report.
Packet loss is another metric used to determine if a device has been spoofed. Due to wireless transmission characteristics, devices at different locations will have different packet loss probabilities associated with them. This may not be very useful for the current project as LAN connections have much smaller packet loss probabilities, which are harder to detect.
The next method that is explored is interarrival times which is the difference in time between packets that are received from a source. The sources are sending packets out at a constant bitrate and the difference in bitrates can be observed and analysed. From this, an extra or modified source device can be detected. This would be similar to the transmission time method explored in this project where the round trip time (RTT) to each device is checked.
Another way of defending against spoofed IP traffic is examined using hop count filtering in [11]. A technique is devised to create an IP-to-hop-count mapping table. It can be used to check whether a device with a certain IP has a consistent hop count. A similar table would be devised in this project with a hop count field along with others. Factors such as stability of hop-counts, and its effectiveness are explored and could be built upon in this project. It also implements a learning state and a filtering state which would be similar to the fingerprint creation state and monitoring state of the final system in this project. Methods of how an attacker could fool the system are explained such as finding out the hop-count of a client to server and modifying their hop count so it will match once it reaches the server. The paper is focussed on Internet servers whereas this project is directed to LANs which may have different characteristics.
Source [22] looks more specifically into hop-count filtering to detect spoofed traffic. The main purpose of this is to prevent Distributed Denial of Service (DDoS) attacks. An interesting situation arises when one device changes operating system. There is the possibility that the initial TTL, set by the operating system, is different and may raise a false alarm. The possibility of this occurring in this project is eliminated by only monitoring simple Ethernet devices which are usually only capable of running a single operating system, unlike general computers. It is determined that for the purpose of defending against DDoS attacks, the hop count filtering method is effective and hop count spoofing would be hard for an attacker. This is because outside attackers can’t easily determine the end TTL value at the server. In a smaller LAN, this may be easier to determine and the effects of TTL spoofing will be explored. Two running states are explained, alert and action states. The monitoring state is when the system is monitoring for spoofed packets and action state is where spoofed packets are detected and discarded. This project will create similar states, however, instead of discarding packets, the system would be required to create an alert to notify of the attack. The TTL values for each client are determined by the value on the first time it connects to the server. This process would be similar to the fingerprint creation phase of the proposed system. Both systems assume the user is legitimate in this phase, otherwise incorrect TTL values may be recorded.
An investigation on how RTT can be used to improve hop count filtering (which is a method of determining where packets originated) can be found in [12]. Attackers are able to spoof the hop count number. It alone is not enough to identify a device, as it is not reliable. The investigation was able to verify that RTT could be used in conjunction with hop counts to further narrow down where packets came from. The study focussed more on large inter-country networks whereas this project will be directed at smaller LAN. It was stated that “further work is required to derive and test and algorithm that utilizes both RTT and HC to detect IP spoofing”. The aim of this project is to conduct some work in this area and test the viability of this method.
In [13] a method to check TTL values at each router, instead of at the end hosts is investigated. Although this is a viable method and has been proven to be more effective than using standard hop-count filtering, it requires modified router software and may not be practical for a small LAN setup. This would also reduce the routing speed, which may be critical in some router applications.
The use of hop-count and an identification number (PID) to detect spoofed packets and prevent DDoS attacks is shown in [7]. The PID contains information about the router path and the hop count in an encrypted form. The PID is stored in the header in the place of the normal IPID and to decrypt it, each party needs a shared secret key. The use of a key and modified headers makes this method impractical for this project, due to the inability to modify the target devices to achieve this. It is also stated that this method also works for IPv6 protocol, which will be useful in future applications.
Source [14] further extends the hop count detection methods by checking IPID fields to detect spoofed packets. It has more of a focus on the Darknet, a smaller harder to access subset of the public Internet. Some graphical ways of showing the two fields of information were shown and patterns could be seen, allowing anomalies to be easily detected. The source acknowledges that the two fields can be forged (changed by the sender), however, the network may not operate as expected, defeating the purpose of forging the data. This project aims to go further by combining these two data fields with transmission time to see if forging can be detected.
Fingerprinting a remote physical internet connected device using clock skew is also possible [15]. Clock skews are dependent on how a device’s components are constructed and is unique to each device. Similar to the techniques being explored in this project, clock skew makes use of information already made known from the device and requires no modification to its software. Although it may not detect changes in software, this technique has been shown to accurately determine whether a device is the same physical device.

== 3 Finding characteristics and creating fingerprints ==

The first steps in this project involve capturing and analysing network traffic. Some possible methods to build up characteristics for devices have been found to be useful in the literature review [9] [14] [12]. These methods will be explored to see if they can be used to characterise each device and whether the characteristics are unique to each device.
'''3.1 Background Theory'''
This section covers the software tools that will be used during the project and how they will help to create the end result. Packet information theory will be explained to give some understanding of the source of characteristics.
'''3.1.1 Simulation Method'''
A range of device arrangements will be utilised to conduct tests for the project. The least complex set up will use two computers and a router. One will monitor the traffic (server) to the other computer (client) that is connected via the router. The captured Ethernet traffic will then be analysed to look for patterns that are unique to that particular client.
To test the case where a device is moved in the network, two routers will be connected and the client computer’s connection will be moved from the original to the new. This would simulate someone possibly maliciously moving the device around an industrial network, leading it to possibly provide false information (e.g. a temperature sensor).
PLCs will replace the computers to conduct final tests on transmission time. It is expected that the transmission time for computers will vary due to the rapidly changing requests a user initiates, making the monitoring system unreliable. The PLCs will be swapped, have their connection points changed and see whether modifying the logic they execute raises an alarm in the monitoring software.
'''3.1.2 Wireshark'''
Wireshark is a packet capturing tool that was used to save the Ethernet traffic to a file which could later be analysed. It is a free and open source tool, with a graphical interface, making it a suitable option for this project. It also gives detail into what is contained within the packets, providing an initial way to look for patterns and characteristics within subsequent packets. As it captures all traffic that the computer receives, filters had to be implemented to only view packets that are relevant to the testing, otherwise the amount of data displayed can be overwhelming (observed in initial tests).
'''3.1.3 Matlab'''
Matlab is a computing environment with a graphical interface and a programming language that can be used to perform calculations. It works well with large matrix manipulations and allows data to be plotted. The data from Wireshark can be fed into Matlab to generate matrices that hold the contents of the captured packets. Data can be extracted from the matrices and plotted to look for common characteristics. Algorithms can also be written and tested to check captured data to see if an attack has occurred.
'''3.1.3 Internet Protocol Packet Information'''
Each Ethernet packet transmitted over the local network contains information that can be exploited to provide characteristics about the sending device which can be used to create a fingerprint. Within each Ethernet packet is an IP packet which contains information that will be analysed in this project. There are cases where there is no IP packet inside the Ethernet packet, although this is rare in the traffic generated from the devices that will be tested. Figure 1 shows the breakdown of an IP packet and its contents. From Figure 1, it can be seen that the TTL value is within the IP packet. The TTL value is created by the sending device and is a counter that is decreased by one each time the packet crosses a network router. The IP identification number is also contained within the IP packet and its function will be explained in section 3.4.1 [16].

[[File:1a.png|x200px|200px]]
Figure 1: IP packet contents with bit offsets shown at the top [17]

'''3.2 Requirements'''
The aim of this project leads to the creation of the following requirements that would provide a useful device identification and monitoring system:
Detect when a device has been moved to a different part of the network
Detect when the programming of a device has been modified
The system must not add excessive amounts of load to the device or significantly add to network traffic.
Detect when multiple computers are accessing a device
A simple method to create the fingerprint for the device
Be able to operate under changing network conditions such as high loads on routers
'''3.3 Method 1: Time to Live Fingerprinting'''
TTL is a value assigned to each packet specifying the maximum number of routers a packet can traverse before being discarded. By checking the TTL number of the packets transmitted by a device, some insight into the path that its packets take can be observed. A change in this number usually suggests the device has changed position on the network which could be due to malicious activity. Another reason for a change is the packet is forced to take a different route if a connection becomes congested or a device is busy. The effect of this would also have to be explored and see how it limits the TTL fingerprinting approach.
'''3.3.1 Time to Live Characteristics'''
Every module that processes the packet, such as a router, must decrease the value by one, even if it processes the packet in less than a second. Once this value reaches zero, the network discards the packet, resulting in it not reaching its destination.
It is proposed that the TTL could be used to monitor devices on a network (with two or more routers) to determine if they have been moved and alert the user. This is a relatively simple test, but may provide a second check for further testing methods to see if a device has been correctly identified [16].
'''3.3.2 Design'''
The network will be set up as follows for a normal operating condition:
[[File:2a.png|x200px|200px]]
Figure 2: Initial server-client setup
The network will be set up as follows to simulate the device being moved to a different location on the network:
[[File:3a.png|x200px|200px]]
Figure 3: Client's network location changed
'''3.3.3 Method'''
The initial test involved one PC connected via a router to another PC, with no other devices on the network and no internet connection. Using Windows Command Prompt, a ping command was executed at the host to the client PC. Wireshark showed it was using Internet Control Message Protocol (ICMP). A filter was created to only show packets from the required IP addresses and with the ICMP types for a ping request and response, then the selected packets were exported. This made the analysis simpler by only showing packets that were relevant to the tests.
An external library was used to read the packets into Matlab to plot data and analyse results [18]. A library called TracesPlay was found and gave the basic tool to import packet capture data into Matlab. Once the library was imported into Matlab, the following command could be used to bring the results into a matrix. Each row represents a single packet with the columns showing the sending IP, receiving IP, capture time, IP ID and TTL respectively.
This worked well, however, the IP addresses were in decimal format and another function would be required to interpret them. Integer format (i.e. 3409667082) may be useful for sorting the data, although IP addresses are commonly displayed in dotted decimal (i.e. 192.168.0.1). Refer to Appendix 7.2.1 to see how conversion to and from these formats was done.
Steps that are undertaken to create the fingerprint characteristic:
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run.
Once the pings had stopped, the packet capture was stopped.
A filter was applied in Wireshark to show only relevant packets and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
From here, the mean of the row containing the TTL value was taken. This is the fingerprint value of TTL that would be associated with the client device.
'''3.3.4 Results'''
The device was moved to the same router as the monitoring PC and the same test was repeated. It was found that the TTL was incremented by one, validating that the network is functioning as expected. This change could be detected in Matlab and raised an alert as the value was different to the characteristic recorded for that device.
'''3.3.5 Discussion'''
Finding a mean value of the TTL for a device can be useful to help build a fingerprint. Using a mean would reduce the effect of packets occasionally taking a different route through the network, due to congestion at times. However, if the device was maliciously moved to another part of the network, the mean TTL is likely to change.
This method could be circumvented by using a router with custom firmware installed on it [19]. Custom firmware can be used to force the router to increase or decrease the TTL of each packet by a certain amount. For example, if a device had a TTL of 126 and was moved to a position behind another router the TTL may be reduced to 125. With the help of an extra custom router after the device, the TTL of the packets could be increased to 126. One way of detecting this would be observing the transmission time, which will be discussed later. The effect of adding an extra router would increase the transmission time, as it introduces more processing delay and queuing delay if it is close to capacity.
It is also important to note that in a home system with one router, the TTL would be the same for all devices. Small industrial networks usually operate on the same sub network, running through switches instead of routers. The switches do not decrease the TTL, making this method ineffective. Analysing the TTL would be more useful in wide area networks where there is more variance in the TTL.
'''3.4 Method 2: Internet Protocol Identification Number Fingerprinting'''
The IP identification number changes with each packet sent and the frequency of its change can be observed. Any deviation from the predicted value could suggest the device isn’t operating as it was originally, or was reset or modified in some way.
'''3.4.1 Internet Protocol Identification Numbers'''
The Internet Protocol Identification Number (IPID) field provides a way to distinguish fragments that belong to one datagram to those of another. This changes over time and could be used to determine some characteristics about how it changes relative to each device (i.e. a device that sends more data would have a faster changing identification number). This method examines the IPID to extract patterns that will be used to build a fingerprint for each device [16]. One factor to take into account when using the change in IPID is that it will reset to zero once it reaches its maximum.
'''3.4.2 Method'''
Description of system setup. Use two devices that are sending out different amounts of information to the network and try to distinguish the difference from the IP identification number.
Creating the analyser script (code in 7.2.3):
The analyser script loops through each group of four ping requests. It finds the difference in IPID from the first ping response in the group compared to the IPID of the first ping response in the next group. It then graphs them so the change in IPID number can be observed.
For example, the table below shows two groups of ping requests where the difference in IPID number between Ping 0 and Ping 4 is 19 (120-101). The jump in IPID number between Ping 3 and Ping 4 happens because during the delay until the next ping group started, the device transmitted other data.
Ping 0 1 2 3 4 5 6 7
IPID number 101 102 103 104 120 121 122 123
Table 1: Ping response IPID for two groups of four pings

'''Test 1: Initial IPID test'''
The purpose of this test is see how the IPID number varies under normal conditions. The setup is two PCs connected together via a switch.
A simple loop was created in Matlab to ping the remote computer four times in a row and repeat five times after waiting a three second delay each time.
The Wireshark packet capture was enabled and the script was allowed to run. This is in addition to limiting it to packets to and from the switch and client computer (ip.addr). Limiting the icmp.type to 0 or 8 then shows only the ping request and response packets.
Once the pings had stopped, the packet capture was stopped, the filter was applied and the packets exported as a .pcap file.
The TracesPlay script was executed to import the packet capture to Matlab.
The analyser script was run producing the following graph. (Refer to Appendix 7.3.1 for packet information)
[[File:4a.png|x200px|200px]]
Figure 4: Difference in IPID under normal conditions
'''Test 2: IPID change under higher data transfer rate'''
The purpose of this test is to see how the IPID number varies if the device is sending more data over the network compared to its normal rate. The same setup and packet capture process as Test 1 was used. A large (1GB) file copy was initialised from the client computer to the host computer. The ping script was then initialised within 5 seconds, producing the following graph. (Refer to Appendix 7.3.2 for packet information)

[[File:5a.png|x200px|200px]]
Figure 5: Difference in IPID when a file is being transferred over network
'''Test 3: IPID values with two client devices'''
The purpose of this test is to see how the IPID number varies if two devices are connected via the same switch. The same setup was used as Test 1, with an extra PC connected at the switch. The same packet capturing process was completed and allowed to capture for five hours. Figure 7 shows the difference between subsequent ping groups over this period.
[[File:6a.png|x200px|200px]]
Figure 6: IPID numbers received from two clients
'''Test 4: Long term IPID characteristics for fingerprinting'''
The purpose of this test is to see how a fingerprint could be established from a device operating under normal conditions. The same setup was used as Test 1.
[[File:7a.png|x200px|200px]]
Figure 7: Difference in IPID numbers over a five-hour time period
'''3.4.3 Results'''
The three main attacks that could be detected using this technique are; an identical device being added to the network, the device being accessed via the network more often, or the device sending out extra data due to changed programming.
Test 1 shows under normal conditions, the difference in IPID number should remain around 5 for the particular device tested. Test 2 shows that once a device is sending more data over the network, the difference rapidly jumps to a number above 1000 for the extreme case of a large file being transferred. It can be seen that the difference falls back to zero in Figure 5 which corresponds with the file transfer completing.
Test 3 shows the effect of connecting two devices to the network with similar properties. Figure 6 clearly shows the IPID numbers increasing to their maximum values, before resetting back to zero. The peaks occurring at different times shows that two devices are transmitting.
Test 4 shows how the difference in IPID numbers vary over a larger period of time. The peaks are associated with the device reaching its maximum IPID and falling back to zero. A fingerprint for the device could be created by taking the average of the IPID difference. To increase the accuracy of the fingerprint creation, IPID difference values above 50 could be removed in this case, reducing the effect of IPID number resets on the mean. From Test 2, it would be expected this mean would change if the device is accessed more frequently or sending more data than usual. This still needs to be tested on a real PLC which has more stable traffic compared to a PC.
'''3.4.4 Discussion and future work'''
The benefits of this method are that it does not heavily depend on network congestion; how busy the router is, or how long either computer takes to process requests. It is purely dependent on how much data is being sent by the client device. Malicious activity could involve someone outside of the local network accessing a device, causing it to send more data. Another situation could be the device is changed with one that executes processes in a different order or sends out extra data, however, more testing is required for these scenarios. Either of these attacks would be reflected in a faster changing IPID and are likely to be detected. An IP address spoofing attack could be detected by looking at the IPID numbers. This attack is unlikely as switches have trouble managing two devices with the same IP, resulting in them being disconnected at random times.
'''3.5 Method 3: Transmission Time Fingerprinting'''
The RTT for each device can be measured by ‘pinging’ the device and calculating how long it takes to receive the device’s response. RTT can be affected by many factors, such as how busy the device is, how busy the network is and at what time this measurement is taken. Looking for correlations between these factors may provide a higher degree of accuracy in monitoring for anomalies in devices.
It is proposed that by looking at the RTT from the device and its nearest switch may provide information that can be used to identify devices. The reason the RTT to the nearest switch is also measured is to allow the effect of variable network traffic on a device’s RTT to be minimised.
3.5.1 Factors Affecting Transmission Time
RTT will be monitored to create a fingerprint and monitor devices. There are four main delays that affect the transmission time [20]. The first is the propagation delay of the signal across the network medium, usually a wire. This value is very small as the signal propagates close to the speed of light and over a short distance, 1km for example. Propagation delay would have the smallest effect on the RTT in a local network and changes in location would also have a negligible effect. Queuing and processing delays are also added as the packets pass through each router or switch in a network. These delays usually have a minimum value and will increase as the load on the network increases. The final delay is the processing time of the device that is being pinged. This delay would be dependent on the processing load it is under, which is related to how many tasks it is performing. For example, a PLC that is executing malicious code as well as the code it usually executes changes the load on the PLC, hence its response time to ping requests may change.
The following formula summarises these delays:
dRTT = dprop + dqueue + dproc + dresp
dRTT – RTT
dprop – Propagation delay over medium
dqueue – Queuing delay at switch depending on how busy it is
dproc – Total processing delay of interconnecting routers and switches
dresp – Response time of device being pinged
'''3.5.2 Method'''
The initial setup involved connecting two PCs via a switch.
Wireshark packet capture was initiated using a filter. This was done so that only ping requests and responses were shown. This is in addition to limiting packets to and from the switch and client computer.
Four ping requests were executed to the switch. This is quickly followed by four ping requests to the client PC. This process was repeated at twenty second intervals and was allowed to continue for five hours.
Wireshark packet capture was stopped and packet data was exported
The Matlab Tracesplay library was used to import the packet data
The host, client and switch IP addresses were entered into a script. The dotted decimal IP addresses were converted to integers for easy comparison to the packet data.
The RTT for each ping request was calculated
The average switch RTT, average client RTT and difference in RTTs (DRTT) between these was calculated and output. (Refer to Appendix 7.2.4 for code)
'''3.5.3 Results'''
[[File:8a.png|x200px|200px]] [[File:9a.png|x200px|200px]]
Figure 8: Client RTT under normal conditions Figure 9: Nearest switch to client RTT under normal conditions
The output above shows the RTT for each the client and switch over the testing period. A small amount of correlation is visible between the two. This would be due the fact that the switch was sometimes taking longer, resulting in the switch taking longer to return packets for each ping reply from itself or the client PC. This could also be extended to larger networks which have variable loads. Using the difference value of RTT (DRTT) from the client and switch at a point in time aims to reduce this effect which is discussed in section 3.7.
Looking at just the RTT to the end device also gives some insight to if an attack has occurred. The histogram below shows a plot of the fingerprint characteristic Acl vs an attack RTT distribution, Bcl.
[[File:10a.png|x200px|200px]]
'''Figure 10: Histogram of RTTs under normal (Acl) and attack (Bcl) cases'''
It can be seen in Figure 10 that most RTTs are under 3500μs, however there is an outlier at 5900μs. This suggests another method of detecting an attack is by setting a limit on the maximum allowable RTT.
'''3.5.4 Discussion'''
It is also important to note that these methods increase network traffic which may be undesirable in some systems. The effect of this could be minimised by increasing the checking interval. Another option would be to analyse data that is already coming from devices as it will contain the same information. This would mean that that the software would have to be tailored for each system, as devices will send packets at different rates, depending on the application. Setting the limit on RTT may also be a way to initially detect an anomaly, then the system could increase the sampling frequency to conduct further testing before raising an alarm. Due to the high variability in RTTs as seen in Figure 8, using the mean and standard deviation will not provide much information as to whether the device is under attack. This is also a result of the histogram without an attack overlapping the attack histogram, making it hard to find differences. Other methods of analysing the data will be discussed in the following sections.
'''3.6 Kullback-Leibler divergence and DRTT'''
Differences outside of tolerance ranges could be used to deduce certain changes in the network or device. For example, if the DRTT increased by a large amount or reduced below zero, it could be determined that the device is busier, or its position in the network has changed. Another case is a man in the middle attack, where an extra router is added between the device and the closest switch. This could increase the DRTT, creating an alert in the system. In all scenarios, an alarm could be raised to allow an administrator to determine the cause.
As the DRTT and sequence rate of change values are not normally distributed, using mean and standard deviation is not accurate enough to determine if two sets of observed data are sufficiently different to infer an attack has occurred. This is because the data sets are truncated at 0 and the effects of a constantly changing network environment. KL divergence is a measure of the distance that the measured distribution is from the true (fingerprinted) distribution. If the KL is zero, the measured distribution can be determined to be the same as the fingerprinted distribution. As the KL value increases, the measured distribution is moving further away from the fingerprinted distribution. It is proposed that a limit on the KL value is set, and once that limit is exceeded, an attack alert could be raised.
A simulation was conducted in Matlab using the normal device DRTT and then adding an extra delay to it. The extra delay was to simulate an extra ‘malicious’ switch being inserted in between the device and its closest switch. The delay function added a fixed delay and a normally distributed random delay to each time sample.
Simulation delay formula: delay = 𝛼+N(𝜃,𝜎)
𝛼 > 0
N(𝜃,𝜎)- Random extra delay
The first test is the device against itself at a different time without an attack. It is expected that a small amount of variance occurs and this is simulated by adding the delay function with 𝛼=20, 𝜃=1, 𝜎=5. The second test is the device against itself at a different time with a man-in-the-middle attack. The simulation is done by increasing 𝛼, as a longer delay is expected and increasing the normal distribution parameters as more variance is expected. The parameters used were a=200, 𝜃=2, 𝜎=20. The Matlab KL divergence calculator script used was from source [21].
[[File:11a.png|x200px|200px]]
Figure 11: DRTT in fingerprint vs same device over different period
[[File:12.png|x200px|200px]]
Figure 12: DRTT in fingerprint vs DRTT with device under attack

It can be seen in the first non-attack case (Figure 11), the distributions largely overlap which indicates there should be no alarm raised. The KL value for this case is 0.0050. The second case shows the attack has caused the DRTT to increase compared to the fingerprint (Figure 12), resulting in the blue distribution moving to the right. The KL value increases to 0.1595. This is a large difference in KL, so a possible way to detect attacks would be to set a limit on the KL value for each device.
The method of checking both the switch and device RTT does help to some degree, however, it is impossible to ping the two devices at the exact same time. The delay between pinging each device means that network traffic may change, affecting the results. To avoid this, it would be recommended to use these techniques on networks with simple Ethernet devices connected where the network load is relatively stable.
In actual tests, the two distributions overlapped almost completely, even under attack cases. Therefore, there was only a very little difference in KL between the fingerprint and a no alarm case, compared to the fingerprint with an alarm case. This method would be more useful if the switches added a significant delay or a long transmission medium was introduced. These cases would likely shift the distribution to be similar to the simulation.
'''3.7 CDF of Client RTT'''
In testing, the DRTT did not change as much as expected, due to the high speed of the switches. However, the switches increased the frequency at which certain RTTs occurred. Figure 1 shows a histogram of a normal scenario (Scenario A) against itself at a different time which should not create an alarm. The two distributions are a similar shape, with some variance over the range of RTTs. Figure 2 shows a histogram of Scenario A against Scenario B (an attack). B has larger peaks around 1500μs and 2400μs which can be used to create an alarm.

[[File:13.png|x200px|200px]]
Figure 13: Histogram of device RTTs over 2 different time periods
[[File:14.png|x200px|200px]]
Figure 14: Histogram of device RTTs under normal (Acl) and attack (Bcl) conditions
A cumulative distribution function (CDF) was chosen to gain a better view of the difference. The CDF gives the probability that some variable X takes values less than or equal to x:
F(x)=Pr⁡[X≤x]
Translating this to the current scenario, the CDF gives the probability that a new RTT measurement will take a value less than or equal to a value in the range of possible RTTs.
[[File:15.png|x200px|200px]]
Figure 15: CDF of normal device RTTs (Acl) vs attack RTTs (Bcl)
The two green arrows show where the peaks in Scenario B have shifted the CDF to the right compared to the normal scenario where there were peaks in the histograms. Overall the two CDFs are quite similar, as both distributions have a similar mean. Therefore, the mean value does not give an accurate indication of whether an attack has occurred.
The method used to detect this variance is to integrate each CDF for RTTs from 0μs to 6000μs and take the difference (Equation 1). This gives a measurement of the yellow shaded area as a percentage of the area under the fingerprint CDF (Matlab code in Appendix 7.2.5). For this example, the area below Scenario B’s CDF is less than Scenario A. A percentage limit can then be set on how much the difference can be before raising an alarm. The difference in this example is 2.80%. This is compared to the difference of the normal case, Acl(1:200) against itself Acl(201:400) which is 1.05%. The results suggest a limit of +/-1.5% on this value would mean man-in-the-middle attacks could be detected with a small rate of false alarm. Further testing of this will be conducted in the next section to verify the results.
[[File:eq1a.png|x200px|200px]]
Equation 1: Finding the difference between two CDFs
'''3.8 Sample window size and costs of making a decision'''
The optimal window size has been found to be 15 minutes of data with four consecutive pings every 20 seconds which equates to about 200 ping-response groups. This gives enough information to build up a CDF that can be used to distinguish attacks from normal operation and outlier longer RTTs will usually occur in this interval under attack conditions. In practice, pinging a device every 20 seconds would add too much unnecessary load to the network which may slow down other information transfers. Using the default MSDOS ping function from Matlab also gives four consecutive pings, however this could be changed to single pings by adding [-n 1] to the end of the command (Where 1 is the number of pings). This would also mean that the sampling time would have to be increased four times, to an hour to yield similar results.
A possible option in a real-time system would be to ping the device periodically and look for outlier longer RTTs. At this point the sampling rate could be increased, so an accurate CDF could be constructed. A sliding window of 200 samples could be used to compare against the fingerprint characteristic. If the CDF difference remains above 1%, it could continue taking samples and sliding the window, otherwise the outlier can be ignored and it would go back to sampling at the slower rate. If an attack occurs, it would be likely that the CDF difference rises above 1.5% in which case an administrator could be alerted.
It is also important to look at the costs involved in making a decision and detecting attacks. If the system says there is no attack when there is, the result may be catastrophic. This could involve another remote computer reading the inputs and changing outputs of a critical PLC in a manufacturing plant or power production facility. The cost of waiting for more samples from a device would be quite minimal as a man in the middle attack would take some time to set up and modify transmitted data. If an extra computer was connected to the PLC, the increase in IPID difference could be detected within about 10 samples at the slower rate (From testing the IPID difference almost doubles when another device is connected).
There is a cost associated with the system saying that an attack has occurred when there hasn’t (false-positive). This cost would be much lower than the cost of missing an attack, as it would just involve an administrator doing some further checks to see what has caused the anomaly and the device would continue to function as normal.

== 4 Implementing Fingerprinting Techniques ==

The following tests involve applying the concepts and methods found in Section 3 to create a fingerprint and monitor devices under different scenarios. Various attacks will be set up and the device’s response will be checked against the fingerprint characteristics to see whether an alarm is produced.
In the earlier stages of this project, IPID numbers and transmission time were used to develop a fingerprint for a device. Using a combination of both techniques, a wider range of attacks can be detected from analysing captured data.
'''4.1 Method'''
In this section, three attack types under varying network conditions will be tested and the results will be analysed. Attack 1 (Case 1) will be observing the system once a switch has been inserted between the device and its originally connected switch. This simulates a man in the middle attack where the inserted switch observes all traffic that passes through it and may have the capability to modify packet data. The attacker could then provide false data to controller devices on the network, which would appear to come from the original device. They could also modify or block information from passing to and from the device. It is expected that the DRTT will increase in this scenario and the cut-off for when the system should raise an alarm will be explored.
Attack 2 (Case 2) involves setting up another computer on the same LAN to access the device and read its measured values on a regular basis. This simulates an attacker connecting to a network point and reading values from any of the PLCs on the network. From here, they could easily change the outputs of the PLCs which could lead to catastrophic consequences, such as overheating a chemical process. It is expected that this attack will be detected by seeing the IPID increase at a greater rate as the device is sending out more packets.
Attack 3 (Case 3) will look at whether changing the program that the PLC executes changes its RTT characteristics. It is hypothesized that if a device’s programming is changed, the time taken to respond to ping requests may vary. This may not be the case if the device handles ping requests at the network interface, without any input from the main processor.
These attacks will be simulated initially using nothing other than the required switches, PCs and a PLC. However, in real life scenarios there are many other devices on the network transmitting data which has an effect on how fast the switches respond. This can have an effect on the RTTs, making it harder to detect attacks. The effect of this will be explored using a test on Attack 1 with an extra load on the switch. A robustness test will be transmitting a large amount of data between two other PCs connected to the same switch as the monitoring PC. This simulates a large file being copied over the network and gives the switch a much greater load to deal with.
The algorithm for detection is shown below:
If (IPID¬ave > IPIDfp*1.3) where IPID¬ave is the measured average IPID number change and IPIDfp is the fingerprinted average IPID number change
Trigger multiple device access alarm
Else If (RTT > RTT¬fpMax) where RTT is the measured single RTT and RTT¬fpMax is the maximum RTT observed in the fingerprint
If the (absolute(CDFdiff¬) > 1.5%) where CDFdiff¬ is the percentage difference of CDF of fingerprint vs measured
Trigger topography changed alarm
Else If (absolute(CDFdiff¬) > 1.5%)
Trigger programming changed alarm
The algorithm shows three different alarms the monitoring system would be able to trigger. The set value for the maximum IPID change is 30% higher than the average of the fingerprint. If this is exceeded, a multiple device access alarm would be triggered. This indicates another computer is accessing the device through the network. The topography change alarm indicates the device has moved position in the network or a man-in-the-middle attack has occurred. This is triggered when a high RTT is observed in the sample time and the CDF difference is greater than 1.5%. The third alarm is a programming change which is triggered by just the CDF difference going higher than 1.5%. A very high RTT is not expected in this case as the network topography would remain unchanged, but the device would take a different amount of time to respond to ping requests.
Equipment key
SA – Samsung CY-SWR1100 switch (Switch A)
SB – Allen Bradley Stratix 2000 switch (Switch B)
PLC – Allen Bradley Micrologix 1100 (Programmable Logic Controller)
Picture of set up
[[File:16a_copy.png|x200px|200px]]
Figure 16: Equipment set up
4.2 Results
Case 0: Normal conditions (No-alarm)
The goal of the initial tests is to check that the characteristics of the device do not vary widely at different times. If the IPID or RTT changed too much under normal conditions, false alarms would be triggered. The blue distributions in the histogram represent the fingerprinted characteristic of the PLC under each particular network set up.
Test 1
The first test involved connecting the PLC to the PC through SA (Figure 17). The Matlab pinging function was run for 1 hour, pinging the device every 10 seconds while capturing all packets sent and received. The first fifteen minutes of data was used as the fingerprint which was tested against the results from the next fifteen minutes (200 samples), which shouldn’t cause an alarm, as nothing had been changed.
[[File:17.png|x200px|200px]]
Figure 17: Initial layout (No-Alarm)

[[File:18.png|x200px|200px]]
Figure 18: Histogram of device RTTs over two time periods
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 3102μs
Difference in RTT CDF 1.05%
Table 2: Case 0, test 1 results
The difference between the CDF of the fingerprint interval against the next interval showed a difference of 1.05%. The average IPID change was 90.41 for the fingerprint and 90.41 for the next interval. The maximum RTT in both intervals was below 3500μs for all ping requests. This information is used to set limits on when an alarm is raised in the case of an attack.
Test 2
The test above was repeated with SA swapped for SB. A new fingerprint was created in the first half hour and tested against the next half hour interval. This was done to verify the results found and make sure the limits to be used would be applicable under different network set ups.
[[File:19.png|x200px|200px]]
Figure 19: Histogram of device RTTs at two different times
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 2572μs
Difference in RTT CDF -0.09%
Table 3: Case 0, test 2 results
The difference in the fingerprint CDF against the next interval was -0.09%. This is relatively low which was to be expected as nothing was changed in the network set up. All RTTs were again under 3500us. This is similar to the first test as the packets are only traversing one switch, so the delay should not be too different with other switches. Therefore, a maximum RTT limit of 3500μs and a CDF limit of +/-1.5% would be set to detect attacks if measured values fall out of this range. Under the proposed algorithm, neither of the above situations would cause an alarm.
Case 1: Malicious switch inserted (Alarm)
Test 1
The attack to be tested is a man in the middle attack using the fingerprint with just SA to compare against. This was simulated by inserting another switch (SB) between the PLC and monitoring PC (Figure 20). A hostile switch may be able to directly modify data within the packets. This could involve changing the values of inputs and outputs at the PLC, which could result in significant damage in industrial systems.
[[File:20.png|x200px|200px]]
Figure 20: Layout with extra malicious switch inserted (SB)
[[File:21.png|x200px|200px]]
Figure 21: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 4348μs
Difference in RTT CDF 3.43%
Table 4: Case 1, test 1 results
In this attack case, the histogram shows two distinct peaks around 1400μs and 2300μs which have been introduced with the addition of the extra switch. This has translated to a higher CDF difference of 3.43%. An RTT outlier also appears at 4348μs which is higher than any of the values in the non-attack case which were under 3500μs. The outlier would be detected as there is a RTT outside the 3500μs limit and the CDF limit of +/-1.5% would be exceeded, resulting in a TopographyChangedAlarm.
Test 2
A similar attack was simulated by swapping the switches around and using the fingerprint that only used SB to compare against.
[[File:22.png|x200px|200px]]
Figure 22: Layout with extra malicious switch inserted (SA)
[[File:23.png|x200px|200px]]
Figure 23: Histogram of device RTTs under normal and attack cases
Distribution 1 maximum RTT 3347μs
Distribution 2 maximum RTT 5807μs
Difference in RTT CDF 2.80%
Table 5: Case 1, test 2 results
Two peaks on the histogram are also more pronounced, similar to the first man-in-the-middle case. This again results in a larger CDF difference of 2.80%. A RTT outlier also appears at 5807μs which would be due to having the extra switch. Again, the maximum RTT and CDF difference limits would be exceeded, causing the TopographyChangedAlarm.
Case 2: 2 PCs accessing PLC simultaneously (Alarm)
The next scenario is that an intruder is able to connect to the network and access the PLC at the same time as the monitoring PC. Once connected, the intruder could change outputs or monitor PLC data, compromising the system which could result in serious damages. Early testing has shown that if a device is sending more data, its IPID will change at a greater rate which is what will be tested. The characteristics from the test using just SA were used as the fingerprint.
[[File:24.png|x200px|200px]]
Figure 24: Layout with extra PC polling PLC
The average IPID change of the fingerprint characteristic was 90.41 compared to 147.23 in this attack case. This is a large increase which is caused by the PLC sending extra data to the hostile PC. Under all other tests the average IPID values remained in the range of 85-95. As 147.23 is more than 30% greater than 90.41, this anomaly would trigger the MultipleDeviceAccessAlarm.
Case 3: Code changed on PLC (Alarm)
This attack was done to see whether changing the code on the PLC had any effect on its RTT characteristics. The fingerprint created using SA was used (Case 0, Test 1). The initial code executed 10 ladders (blocks of code), 8 of these were removed to simulate the attack.
[[File:25.png|x200px|200px]]
Figure 25: Histogram of device RTTs under normal conditions and when the programming has been changed
Distribution 1 maximum RTT 3253μs
Distribution 2 maximum RTT 3181μs
Difference in RTT CDF 2.351%
Table 6: Case 3 results
It appears that this attack changes the device’s response time to ping requests, as the difference in RTT is relatively large compared to the no-alarm cases. All RTTs remain under 3500μs which means that the TopographyChangedAlarm would not be raised. In this case, the Programming Change Alarm would be triggered as the CDF difference is greater than 1.5%. Further testing would be required to determine the extent to which the code needs to change before an alarm case could be detected.
Case 4: Two switches with high load on one switch (No-alarm)
This case tests how robust checking the CDF distributions is with loads on the switches in the network. Generally, loads on a switch would slow down the speed at which it can switch packets, however its effect on the alarming system will be investigated. Figure 26 shows the normal case with two interconnecting switches that was used to create the fingerprint. From here, two PCs were connected to SB and a large file was copied from PC 1 to PC 2 at 10MB/s (Figure 27).
[[File:26.png|x200px|200px]]
Figure 26: Normal layout for new fingerprint case
[[File:27.png|x200px|200px]]
Figure 27: Normal layout with extra devices transferring data – No alarm
[[File:28.png|x200px|200px]]
Figure 28: Histogram of device RTTs under normal conditions and when extra PCs are transferring data on network - no alarm
Distribution 1 maximum RTT 3183μs
Distribution 2 maximum RTT 2794μs
Difference in RTT CDF 0.360%
Table 7: Case 4 results
The difference in the CDF distributions was 0.360% which is in line with other no-alarm cases. This suggests that varying network loads do not greatly affect the speed at which ping packets travel through the network. All RTTs are below 3500μs which is also consistent with other no-alarm cases and the CDF difference is below the limit, hence no alarm would be raised.
'''4.3 Discussion'''
From the above results, it can be seen that looking at a device’s network characteristics can be useful to detect attacks. Setting a limit of +/-1.5% would result in all man-in-the-middle attacks being detected. It would also mean that no false alarms would be triggered under normal operating conditions. However, sending a ping request to multiple devices on the network every 10 seconds in larger systems introduces undesirable loads on switches. It was found that with man-in-the-middle attacks, much larger RTTs started appearing. This suggests it may be sufficient to poll the devices at a lower rate and look for RTTs above a threshold. Once this is detected, the device could be polled at a faster rate for half an hour to build up enough data to check its CDF against the fingerprint. If the CDF difference was over the specified threshold, an alarm would be raised.
Changing the code that the PLC was executing also changed its RTT characteristics and could be detected by the detection algorithm. The fact that no abnormally large RTTs were observed in this case suggests that a separate alarm could be raised to notify an administrator that a device had been modified, instead of the man-in-the-middle attack alarm.
Observing the average IPID change proves to be effective in detecting if another device is accessing a PLC. A limit of 30% above the average IPID difference of the fingerprint would give an alert of attack. This limit also allows some flexibility in normal operation as the device may send out more data for small periods of time. A separate alarm could be raised in this case, notifying an administrator that a device was being accessed without authorisation, either by interference on the local network or remotely.
'''4.4 Future Work'''
For a commercial solution, the methods found would have to be implemented in a real-time detection system. All tests were done by pinging the device periodically using Matlab and MSDOS to execute the ping, capturing the data in Wireshark, then analysing in Matlab. To perform this in real time, another programming language would have to be used such as C# that could perform the ping, capture and analysis. A visual user interface would be useful to manage the fingerprints, alarms and set limits for each device.
Further testing would have to be done with different network loads, in larger networks and real-life environments to ensure the methods are still effective. The limits on each fingerprinted characteristic would have to be analysed to measure how accurately the system detects anomalies. More research into the sample size is needed to improve accuracy and decrease the network load of implementing a detection mechanism.
These concepts could be built into existing industrial IoT packages or a system could be built to monitor home IoT devices. The polling rate is likely to vary depending on the application, however, further research would be required.
It would be relatively difficult to ‘trick’ this system which is a possibility that hackers explore. To fool the IPID detection, a man-in-the-middle switch would have to be inserted that synchronizes to the IPID change rate under normal conditions and maintains the IPID change rate for packets destined for the monitoring PC. However, this attack would be detected by the RTT monitoring. More research and investigation into methods that hackers could use to fool this system would be required to implement techniques making it more robust against attacks.

== 5 Conclusion ==

Throughout this project, methods were explored that could be used to detect attacks on network connected devices. Monitoring TTL values has been effective with Internet servers in other studies, however, they do not provide much information in a local network. It was found that IPID numbers and RTTs could be used to detect three main types of attacks. The attacks were man-in-the-middle or a change in network topography, change in programming and a device being accessed by another computer. These could be detected by setting limits on the IPID change between pings, maximum RTTs and looking at the difference in RTT CDF distributions from a fingerprinted characteristic. Each device on a network would need to be fingerprinted under normal operating conditions and monitored, so alarms could be raised. IP address spoofing could also be detected by looking at the IPID numbers, however this attack is unlikely in modern networks which don’t function properly when a device with the same IP is connected.
Future investigations would involve building a real-time monitoring system and testing it on larger scale networks. The limits on CDF differences and IPID differences may need to be varied depending on the application. Some environments may naturally have higher variability in these values, or may require a quicker response to attacks. All of the requirements from section 3.3 were met, except the requirement regarding excessive amounts of load on the network. Further research is required in this area to minimise the effect of the increased load from the monitoring system. The process found was to create a fingerprint based on a device’s response time and IPID numbers from ping requests. The device’s Ethernet traffic would be captured over a period of time and these two characteristics would be compared against the fingerprint to see if they exceeded the set limits before raising alarm. These limits were an IPID difference more than 30% greater, a RTT greater than any that were observed in the fingerprint, and a CDF difference greater than 1.5%.
These techniques could also be applied in home IoT networks, which would be more useful in the future where more devices such as home door locks, lights and other electronics become Internet connected and open to attacks from the outside world. In automation networks, PLCs are being connected via the Internet, allowing remote programming which has cost benefits for companies, but opens up a security risk that anyone could remotely access the device if they gain the correct credentials. By simply looking at the IPID difference, a remote user accessing a device could be detected and the device can have external access closed off while the threat is dealt with.

== 6 References ==

[1] M. Schukat and P. Cortijo, "Public key infrastructures and digital certificates for the Internet of things," in Signals and Systems Conference (ISSC), 2015 26th Irish, Carlow, 2015.
[2] Microsoft, "Password Authentication Protocol (PAP)," 2005. [Online]. Available: https://technet.microsoft.com/en-au/library/cc737807(v=ws.10).aspx. [Accessed 29 Mar 2016].
[3] A. L. T. F. Dirk Reinelt, "Securing communication in automation networks," 5th IEEE International Conference on Industrial Informatics, pp. 149-154, 2007.
[4] P. Flood and M. Schukat, "Peer to Peer Authentication for Small Embedded," Zilina, 2014.
[5] E. Hjelmvik, "Passive OS Fingerprinting," 2011. [Online]. Available: http://www.netresec.com/?page=Blog&month=2011-11&post=Passive-OS-Fingerprinting. [Accessed 29 Mar 2016].
[6] T. Gibb, "OS Fingerprinting With TTL and TCP Window Sizes," 2012. [Online]. Available: http://www.howtogeek.com/104337/hacker-geek-os-fingerprinting-with-ttl-and-tcp-window-sizes/. [Accessed 29 Mar 2016].
[7] K. Kumar, "Hop Count Based Packet Processing Approach to Counter DDoS Attacks," in Recent Trends in Information, Telecommunication and Computing (ITC), Kochi, 2010.
[8] S. Templeton and K. Levitt, "Detecting Spoofed Packets," 2003.
[9] Q. Li and W. Trappe, "Detecting Spoofing and Anomalous Traffic in Wireless Networks via Forge-Resistant Relationships," IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, vol. 2, no. 4, 2007.
[10] Q. Li and W. Trappe, "Relationship-based Detection of Spoofing-related Anomalous Traffic in Ad Hoc Networks," in 2006 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks, Reston, 2006.
[11] H. Wang, C. Jin and K. Shin, "Defense Against Spoofed IP Traffic Using Hop-Count Filtering," IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 15, no. 1, 2007.
[12] A. Mukaddam and I. Elhajj, "Round trip time to improve hop count filtering," in 2012 Symposium on Broadband Networks and Fast Internet (RELABIRA), Baabda, 2012.
[13] X. Wang, M. Li and M. Li, "A scheme of distributed hop-count," in Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference, Shanghai, 2009.
[14] M. Ohta, Y. Kanda, K. Fukuda and T. Sugawara, "Analysis of Spoofed IP Traffic Using Time-to-Live and Identification Fields in IP," in Biopolis, Workshops of International Conference on Advanced Information Networking and Applications, 2011.
[15] T. Kohno, A. Broido and K. Claffy, "Remote physical device fingerprinting," in 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, 2005.
[16] IETF, " INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," 1981. [Online]. Available: https://tools.ietf.org/html/rfc791. [Accessed 12 Apr 2016].
[17] "Manual Transmission," Computer Science E-1, [Online]. Available: http://cse1.net/recaps/11-tcpip.html. [Accessed 03 Jun 2016].
[18] "TracesPlay," Sourceforge, [Online]. Available: http://tracesplay.sourceforge.net/. [Accessed 02 June 2016].
[19] "IP Tables Command," DD-WRT, 15 April 2015. [Online]. Available: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL. [Accessed 03 Jun 2016].
[20] "Speed, Rates, Times, Delays: Data Link Parameters for CSE 461," [Online]. Available: http://courses.cs.washington.edu/courses/cse461/98sp/issues/definitions.html. [Accessed 12 04 2016].
[21] N. Razavi, "Kullback-Leibler Divergence," Matlab, 15 Jul 2008. [Online]. Available: http://au.mathworks.com/matlabcentral/fileexchange/20688-kullback-leibler-divergence. [Accessed 16 Jul 2016].
[22] C. Jin, H. Wang and K. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed Traffic," in 10th ACM conference on Computer and communications security, Washington, 2003.

== 7 Appendices ==

'''7.1 Project Management'''
'''7.1.1 Work Breakdown'''
The project will be conducted in the following order. The initial background research will show ways in which device characteristics can be used. The different methods will be explored in order of expected complexity with each one building on findings of the previous. Finally, the last stage will be to develop a software tool based on all previous findings.
Introduction and literature review
Understand IP characteristics
Plan how software will be used to aid analysis
Explore different methods that could be used for fingerprint creation
TTL fingerprinting
IP Identification numbers
Transmission times
Developing final software tool
3.1 Combine methods into one fingerprint creation tool
3.2 Analyses traffic to check fingerprints
3.3 Test on larger scale systems
3.4 Conclusion of findings

'''7.1.2 Timeline'''
The Thesis will be developed in three stages. It will start with the first draft which is due on 22/04/2016. This will contain a basic literature review, introduction and subheadings to show the structure of the rest of the document. After this, further literature reviews will be done with some basic network tests to gain an insight into patterns that may help identify devices. From this, basic algorithms will be developed to create the fingerprint and analyse network traffic. These findings will be included in the next submission, the second draft, due on 04/06/2016. The final stage involves bringing the different methods together to create a reliable device monitoring prototype and testing its operation with multiple devices. This will be presented along with all other work in the final thesis, due on 21/10/2016.
Progress update 30/05/16: Patterns in IP packet characteristics identified and basic algorithms to test traffic created. Project is on schedule to start combining techniques to provide the monitoring facility and test its effectiveness.
Table 1 gives a breakdown on how the work will be carried out with critical dates and timeframes for tasks outlined.
Table 1: Project Timeline (dates)
Research existing authentication methods (29/02/2016-11/04/2016)
Complete literature reviews and plan structure of thesis (12/04/2016-22/04/2016)
MILESTONE: Draft 1 of Thesis due on 22/04/2016
Use packet capture software and Matlab to identify patterns in Ethernet traffic (23/04/2016-04/05/2016)
Time to Live characteristics
IP identification number characteristics
Transmission time characteristics
Analyse effectiveness of techniques and if any complement each other (05/05/2016-27/05/2016)
Build and test fingerprint creation tool
Build and test traffic monitoring tool
Develop prototype software tool to provide creation and checking from packet capture files (30/05/2016-08/07/2016)
Present and discuss recommendations and prototypes (28/05/2016-14/10/2016)
Add any extra literature reviews and sources required to further develop system and test on larger scale networks (28/05/2016-14/10/16)
MILESTONE: Draft 2 of Thesis due on 04/06/2016
Update Thesis as required from feedback (20/06/2016-20/10/2016)
MILESTONE: Final Thesis due on 21/10/2016
10. Prepare presentation items for exhibition and final seminar day (01/10/2016-
04/11/2016)
MILESTONE: Exhibition (24/10/2016-28/10/2016)
MILESTONE: Final seminar (31/10/2016-04/11/2016)
'''7.1.3 Budget'''
Most components required such as PCs, software and a network to test are readily available at Adelaide University. A budget of $250 per semester is provided by the university and will be reserved for any extra equipment that tests may require.
'''7.1.4 Risk Analysis'''
The following risks may affect the project:
Loss of work
This could happen if hard drive failure causes the loss of documents and programming completed for the project. It is unlikely to occur and the risk will be mitigated by making regular backups online and offline (i.e. USB backups)
Not completing work in time
This risk may cause deliverables to not be submitted on time, impacting on project results. This risk is reduced by making sure all work is done consistently through the semester and not left to the last minute.
Research must be conducted in an ethical, responsible and legal way.

'''7.2 Code Snippets'''
'''7.2.1 IP address conversions'''
Conversion from dotted decimal to integer:
splitted=strread(ans,'%s','delimiter','.')
decimal=str2num(char(splitted(1)))*256^3+str2num(char(splitted(2)))*256^2+str2num(char(splitted(3)))*256^1+str2num(char(splitted(4)))
Conversion from integer to dotted decimal:
strcat(num2str(bitand(bitshift(IPVector,-24), 255)) ,'.',num2str(bitand(bitshift(IPVector,-16), 255)) ,'.',num2str(bitand(bitshift(IPVector,-8), 255)) ,'.',num2str(bitand(bitshift(IPVector,0), 255)))
MATLAB ping

'''7.2.3 IP ID analyser'''
[[File:30.png]]
'''7.2.4 Round Trip Time analyser'''
[[File:31.png]]
'''7.2.5 CDF difference calculator'''
[[File:32.png]]
'''7.3 Output'''
7.3.1 Section 3.4.2 Test 1 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:33a.png]]

7.3.2 Section 3.4.2 Test 2 output
First row is source IP, second is destination IP, third is received time, fourth is TTL, fifth is IPID
[[File:34.png]]

'''7.4 Estonia Tour Report'''
During the winter break, our honours project group went on a study tour to Estonia to learn about cyber security. We visited government officials to learn about their electronic government system and attended a 1-week summer school on cyber security.
'''7.4.1 Introduction'''
The Estonia study tour was a great experience where we learnt a lot about cyber security and worked on our individual honours projects. The environment we were in allowed us to rapidly learn new concepts and work collaboratively with peers and lecturers. Being immersed in the Estonian culture was an interesting experience as we saw sights around the city and learnt about their digital e-Government system. The summer school taught us digital forensic analysis techniques and how to work with lawyers to present a case in a moot court.
'''7.4.2 Positives'''
The cyber security summer school gave us practical experience and lectures with people who are experts in fields relating to cyber security and law. We were able to work in groups and interact with peers who had different backgrounds and skills, assisting us to complete the task. Interacting with the law students was challenging at first as we have never been exposed to this. Throughout the week we learnt how to communicate our technical findings to the lawyers who could use the findings to support their case. Although the summer school was aimed at post-graduates, I think we were able to participate and contribute in a positive way and working with people who had more experience accelerated our learning. The workload for the week was suitable and still gave us time to recover at the end of the day. For those who wanted to explore deeper into the forensic evidence, we could after hours.
We were shown the e-Government system in their showroom and a meeting with Siim Sikkut, a government policy advisor. This was interesting and taught us how their system works and why cyber security is important. It was amazing to see the timeline of how they have developed solutions and how technologies they have been using for 10 or more years are only starting to be implemented in Australia. The importance in the economy of digital signatures was explained as it is more reliable and speeds up transactions.
Estonia has a great startup culture which was explained to us in a meeting with Heidi, the Estonia Business Angels Network managing director. Startup founders have many places to gain support with mentoring and funding through government and private networks within the country. This was further expanded by exploring Mektory, the Innovation and Business center at Tallinn University of Technology. The center had many rooms set up for tasks including 3D printing, welding, wood machining, air flow dynamics, phone app testing and more. This center could be used by university students who had business ideas and allowed them to rapidly develop prototypes.
A week was also spent working on our individual honours projects. During this time, we worked together discussing different ideas in preparation for and prepare for the ICR conference. Having lecturers working with us was valuable as we could get quick answers to questions and feedback could be given. Presenting at the ICR conference helped me gain stronger direction as to where my project is going and gave me feedback from experts who attended.
'''7.4.3 Personal Highlights'''
My personal highlights include the Mektory visit, the KGB museum, the summer school and exploring the Old Town. The Skype tour was also interesting and gave a different perspective of a working environment. Workers were given flexible working hours and dedicated rooms to relax and play games with each other. We also experienced riding in Tesla self-driving cars on some of our taxi rides. Not only was it fun to ride in the car, but we also discussed the security implications of Internet connected and automated cars.
We were also given the opportunity to have some amazing meals and experience the local cuisine. Some of the more unique foods we ate included elk soup and ox rib which tasted excellent. Eating at Umami, an outdoor restaurant was a pleasant experience complemented with great food. Walking to the markets allowed us to purchase fresh fruit and pastries and enjoy the countryside scenery.
A few of us decided to go to the Seaplane Harbour maritime museum. It had many interesting exhibits and allowed us to explore a submarine and handle historic weapons that were used on ships. I would recommend visiting the museum, to anyone interested in maritime and weapons history.
On the final weekend, we took a day trip to Helsinki to do some sightseeing. It was a busy day that involved a lot of walking, but we squeezed in most of the major sights in Helsinki. The ferry ride was extremely comfortable and got us there early, giving us plenty of time to explore. I would definitely recommend future students to visit there as it is so close and even stay the night, if they have time.
We visited the TV tower which gave a fantastic view of the city and showed us some of Tallinn’s history. We were also allowed to walk around the outside of the tower in harnesses and sit on the edge which was a great experience, although a bit frightening at first.
'''7.4.4 Recommendations'''
I have a few recommendations to improve the study tour in future years. The summer school was conducted relatively well, with a good balance of group work and lectures. I think there could have been more lectures about what to look for in digital forensics with examples and less focus on how to use the software which was shown on the first day. Also learning more about what was expected in a technical/legal argument would help as we were unsure at first how we should present our findings to the lawyers and whether it was important to the case. Having more people with a law background would also help the groups work better. We only had one person with legal background and it was hard for them to manage what they needed from the team and they had no one to bounce ideas off of and share the load. Bringing law students from Adelaide is an idea that would have been beneficial as it would be easier for the technical people from Adelaide to work with them and also increase the law presence at the summer school.
The study tour group size worked well, although a few less would give more time for supervisors to focus on individual projects. If half of the students were law students, the load could be balanced with the law supervisor for example.
The bus passes and phone SIM worked perfectly and allowed us to communicate and travel easily. The food and taxi payments were done by individuals and was sometimes hard to manage and keep track of expenses. I would recommend some sort of prepaid credit card with a few that could be distributed to the group. The card could be linked to taxi apps for group travel and personal cards could also be linked for personal travel expenses.
Overall, the study tour was very well organized and was an enjoyable and insightful experience. It was the perfect combination of sight-seeing, group socializing, learning and teamwork which helped achieve its outcome. The tour went for the right length of time, as we were able to explore much of Tallinn and also complete the required work.

File:Eq1a.png

2016-10-26T05:50:50Z

A1645994:

File:35.png

2016-10-26T05:50:39Z

A1645994:

File:34.png

2016-10-26T05:50:18Z

A1645994:

File:33a.png

2016-10-26T05:50:10Z

A1645994:

File:30.png

2016-10-26T05:49:52Z

A1645994:

File:32.png

2016-10-26T05:49:32Z

A1645994:

File:31.png

2016-10-26T05:49:18Z

A1645994:

File:28.png

2016-10-26T05:48:55Z

A1645994:

File:27.png

2016-10-26T05:48:42Z

A1645994:

File:26.png

2016-10-26T05:48:33Z

A1645994:

File:25.png

2016-10-26T05:48:12Z

A1645994:

File:24.png

2016-10-26T05:48:05Z

A1645994:

File:23.png

2016-10-26T05:47:52Z

A1645994:

File:22.png

2016-10-26T05:47:43Z

A1645994:

File:21.png

2016-10-26T05:47:29Z

A1645994:

File:20.png

2016-10-26T05:47:22Z

A1645994:

File:19.png

2016-10-26T05:47:14Z

A1645994:

File:18.png

2016-10-26T05:46:52Z

A1645994:

File:17.png

2016-10-26T05:46:33Z

A1645994:

File:16a copy.jpg

2016-10-26T05:45:46Z

A1645994:

File:15.png

2016-10-26T05:45:21Z

A1645994:

File:14.png

2016-10-26T05:45:01Z

A1645994:

File:13.png

2016-10-26T05:44:43Z

A1645994:

File:12.png

2016-10-26T05:44:24Z

A1645994:

File:11a.png

2016-10-26T05:44:05Z

A1645994:

File:10a.png

2016-10-26T05:43:42Z

A1645994:

File:9a.png

2016-10-26T05:43:06Z

A1645994:

File:8a.png

2016-10-26T05:42:38Z

A1645994: A1645994 uploaded a new version of "File:8a.png"

File:8a.png

2016-10-26T05:42:21Z

A1645994: A1645994 uploaded a new version of "File:8a.png"

File:8a.png

2016-10-26T05:41:41Z

A1645994:

File:7a.png

2016-10-26T05:40:58Z

A1645994:

File:6a.png

2016-10-26T05:40:39Z

A1645994:

File:5a.png

2016-10-26T05:40:19Z

A1645994:

File:4a.png

2016-10-26T05:39:58Z

A1645994:

File:3a.png

2016-10-26T05:39:37Z

A1645994:

File:2a.png

2016-10-26T05:39:09Z

A1645994:

File:1a.png

2016-10-26T05:38:48Z

A1645994:

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T05:37:16Z

A1645994: /* Abstract */

Projects:2016s1-160a Cyber Security - IoT and CAN Bus Security

2016-10-26T05:35:41Z

A1645994: /* Adrian Daniele - Ethernet Device Anomaly Detection Using a Digital Fingerprint */