Joseph Daoud

Mason Rice

Stephen Dunlap

John Pecarina

Multi-controller exercise environments for training industrial control system first responders

Keywords: Industrial control systems, cyber first responders, training platform

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Diseases can manifest themselves in a number of ways depending on the individual. For health care professionals, this can sometimes make a diagnosis difficult and an accurate prognosis challenging. To prepare themselves to perform these tasks, medical students go through a rigorous curriculum that goes well beyond traditional classroom lectures. The curriculum involves many practical exercises, clinical rotations, internships and residency [5]. The knowledge, skills and experience gained from such a curriculum enhances a physician's ability to analyze a patient's symptoms in the context of the patient's unique medical history in order to arrive at a diagnosis and an accurate prognosis [START_REF] Bauer | Talking with your doctor about prognosis[END_REF].

As in the case of human diseases, cyber threats manifest themselves in many different ways and cyber first responders must be able to diagnose and respond to the threats just like physicians. Given the similarities between the two endeavors, it is reasonable to expect that hands-on training similar to what medical students receive would be very effective for cyber first responders.

This chapter describes a training platform that is specifically designed to provide realistic training for cyber first responders. The mobile training platform incorporates several programmable logic controllers (PLCs) as well as other realistic hardware and software components that maximize the knowledge, skills and experience gained by cyber first responders during their training.

Background

Academic institutions, government organizations and businesses offer a variety of certifications, training courses and degree programs in the area of cyber security [START_REF]ISC) 2 ), (ISC) 2 Information Security Certification Programs[END_REF]12]. These programs provide cyber first responders with valuable skills. However, the vast majority of these programs focus on traditional information technology (IT) systems, often neglecting operational technology (OT) systems. While there is some overlap between the two types of systems with regard to security, the differences are significant enough that cyber first responders need specialized knowledge, skills and experience to handle operational technology incidents involving industrial control systems. Two distinguishing characteristics of industrial control systems are the heavy use of proprietary software and communications protocols and the focus on safety. Almost every vendor has its own proprietary applications for interacting with its control devices (e.g., programmable logic controllers). Additionally, industrial control systems manage physical processes in which anomalies can present significant safety risks. Cyber first responders must be cognizant of these factors when conducting their activities.

Several industrial control system testbeds have been developed, but the vast majority of testbeds are geared toward research and development as opposed to education and training: Sandia National Laboratories: Sandia National Laboratories operates several facilities, including the Distributed Energy Technology Laboratory, Network Laboratory, Cryptographic Research Facility, Red Team Facility and Advanced Information Systems Laboratory [START_REF]SCADA Testbeds[END_REF]. All these testbeds contain real and simulated supervisory control and data acquisition (SCADA) assets for research and development in various domains. For example, the Distributed Energy Technology Laboratory houses industrial control systems used in electricity generation and distribution; however, control system security is not necessarily the primary focus of research at the laboratory [10].

Idaho National Laboratory: Idaho National Laboratory has several facilities [START_REF]Defending the Network Against Hackers, Fact Sheets: 21st Century Science and Technology[END_REF]. One of its cyber security facilities is intended to connect to several existing critical infrastructure testbeds, including a SCADA testbed, power grid testbed, mock chemical mixing facility, wireless testbed and physical security testbed. The testbeds comprise a full-scale critical infrastructure test range that covers 890 square miles. Unfortunately, due to the nature of the facility, most learning opportunities are restricted to authorized individuals from government and industry [8].

National Institute of Standards and Technology:

The National Institute of Standards and Technology is tasked with publishing guidelines and recommended practices in many disciplines, including cyber security. The NIST industrial control system testbed was developed to enable the evaluation of security guidelines and best practices [START_REF] Candell | An Industrial Control System Cybersecurity Performance Testbed[END_REF]. The testbed comprises real and emulated industrial control system components that can be evaluated with the appropriate security mechanisms in place.

SANS Institute:

The SANS CyberCity is one of a few physical industrial control system platforms that is specifically designed for security training. The CyberCity platform is used in the SANS SEC562 course, which focuses on penetration testing and kinetic cyber effects [START_REF]SEC562: CyberCity Hands-On Kinetic Cyber Range Exercise[END_REF]. It is a 1:87 scale city with hands-on exercises involving railway switching junctions, a water reservoir and power grid. While some of the systems in CyberCity are simulated, real hardware is incorporated in the power grid system, including Allen-Bradley, Siemens and Phoenix Contact programmable logic controllers [START_REF] Skoudis | How to build a completely hackable city in five steps: And why you should build your skills in this arena[END_REF]. CyberCity is an effective training platform, but it is very expensive. Furthermore, it is not a mobile platform. While it can be accessed remotely for training purposes, remote training does not support intense, hands-on interactions with physical components, which is an important aspect of cyber first response training.

Effective training curricula must be in place to enable professionals to assess and react to cyber incidents involving industrial control systems. Butts and Glover [START_REF] Butts | How industrial control system security training is falling short[END_REF] propose three core areas that should be covered in an industrial control system training course: (i) industrial control system principles; (ii) cyber manipulation; and (iii) response coordination. Each core area has recommended instructional blocks that cover important areas of proficiency.

The industrial control system principles core provides an introduction to common control system components, cyber-physical interactions involving these components, communications protocols and real-world configurations. The cyber manipulation core covers attack techniques that target industrial control system components and networks. The response coordination core primarily focuses on industrial control system incident response. Butts and Glover [START_REF] Butts | How industrial control system security training is falling short[END_REF] recommend that all these concepts be taught via realistic scenarios involving genuine industrial control systems.

Even the best training platforms have very limited value unless they are used appropriately. Developing realistic training scenarios is an important, but difficult, task. Traditional "capture the flag" events, which are focused on gaining access, are fundamentally inadequate for industrial control systems.

The actions taken after gaining access to an industrial control system are far more important.

An effective evaluation of an industrial control system scenario must incorporate the physical process being controlled. Yoon et al. [START_REF] Yoon | Evaluating the readiness of cyber first responders responsible for critical infrastructure protection[END_REF] leverage the NFPA 1410 format, which is used by firefighters, to develop an effective framework for evaluating the readiness of cyber first responders. This framework contains specific objectives, descriptions, evaluation criteria and accompanying references for each training scenario. Furthermore, each scenario contains a designator that describes the type of scenario and the skills addressed by the scenario. The framework proposed by Yoon and colleagues is used in this research to develop training scenarios with measurable evaluation criteria.

Multi-PLC Training Platform

This section describes the design considerations and implementation details of the multi programmable logic controller training platform.

Design Considerations

The training platform is designed to incorporate multiple programmable logic controller models, thereby emphasizing the differences between the individual programmable logic controllers.

Requirements.

The training platform is intended to be reasonably inexpensive and mobile so that training can be conducted at multiple locations. A replica of a jail was created within a 55.32 cm × 42.39 cm × 26.97 cm Pelican 1610 case using genuine components and realistic programs. To enhance realism, the components were selected based on the design of an actual jail in the United States. Ladder logic programs for the programmable logic controllers were created to implement the same operations as the real jail. Any one of the three programmable logic controllers can be selected by the training administrator to be active at a given time. Figure 1 shows the completed training platform.

The training platform is designed to meet five criteria:

Incorporate physical components.

Incorporate cyber manipulation principles.

Incorporate response coordination techniques.

Provide hands-on experience.

Implement effective training scenarios with measurable training evaluation metrics.

Components. on the control panel at a guard station in a jail. Indicator lights are controlled based on inputs from a sensor that detects if the cell door is secure. Because the exercise platform does not have actual doors, this sensor is simulated in the Wiring. To take full advantage of the Y-Box technology, the physical components are not wired directly to the programmable logic controller. Instead, different wiring schemes are adopted. For some applications, the Y-Box can be thought of as a "man-in-the-middle" device that receives electrical signals from the programmable logic controllers and other components, and forwards the signals to their destinations. The wiring schemes used for the lights and pushbuttons are shown in Figures 2 and3, respectively.

The cabinet locks are wired differently because the Y-Box cannot provide sufficient electrical current to disengage the lock. In this case, the Y-Box is used to monitor the signal on the line between the programmable logic controller and the relay, which ultimately powers the lock. This is accomplished by daisy chaining the programmable logic controller outputs from the relay to the Y-Box. Figure 4 shows the wiring diagram.

The other wiring challenge involves connecting all three programmable logic controllers as a single set of components. This requires the inputs and outputs of the three programmable logic controllers to be synchronized and wired together. Programmable Logic Controller Selection. The value of having three programmable logic controllers in a single platform is lost if they cannot all assume full control over the components. Once again, the Y-Box can be leveraged to control the flow of electricity to an individual programmable logic controller while denying power to the other programmable logic controllers. This is accomplished using solid state relays controlled by a Y-Box digital output. When the solid state relay receives the control signal from the Y-Box, power is allowed to flow through the relay to its corresponding programmable logic controller, activating the device. This is the case for the ControlLogix and Siemens S7-300 programmable logic controllers. The CompactLogix programmable logic controller is slightly different from the other two controllers because it operates on 24 V DC. In this case, the relay controls power to a 24 V power supply that, in turn, powers the CompactLogix programmable logic controller. Figure 6 shows the wiring of the relays. Note that the figure is simplified and does not show the 24 V power supply.

Exercise Layout

Figure 7 shows a possible exercise layout. The following paragraphs describe the functions of each segment of the three tables in the exercise layout.

White Cell Table.

An effective white cell should be aware of all the activities performed by the training participants. The simulation terminal is a 8 shows the Y-Box software view of the system with the physical reality of the system as well as the system from the perspective of the programmable logic controller. The figure also shows the programmable logic controller selection buttons that dictate which controller is active at any given time. It should be noted that the buttons in the software are capable of overriding the physical components in the Pelican case, enabling the white cell to manage all the aspects of the exercise at all times.

Platform Table . An engineering workstation and a human-machine interface operate beside the platform. The training platform is contained in a Pelican 1610 case. Inside the case is a fully-functioning replica of a guard station panel that closely mimics what would be found in an actual jail. Additionally, the case contains five cabinet locks, three of which represent jail cells and two that serve as mantraps. Each jail cell has a corresponding light that indicates whether or not the cell is secure. The mantrap has only one light that indicates it is secure only when both its doors are closed and locked. The programmable logic controllers are connected to a network switch housed in the Pelican case.

Exercise Participant Table.

Training participants are seated at the exercise participant table within sight of the training platform as shown in Figure 7. Laptops are provided with standard security tools (e.g., Kali Linux and Security Onion) as well as virtual machines containing proprietary software applications that interact with the programmable logic controllers. A participant may also bring any tools that he/she feels are appropriate to the exercise. From his/her table, the participant is connected to a network switch in the Pelican case and is free to interact with the platform to complete the assigned tasks. Note that the layout can be adjusted to accommodate different rooms and table sizes, and additional network switches can be added to accommodate more participants.

Training Scenario

One of the most important steps in securing an industrial control system is to properly segment the control network [START_REF] Stouffer | Guide to Industrial Control Systems (ICS) Security[END_REF]. This simple task demonstrates the different implementations of similar features by the three programmable logic controllers. For this reason, a beginner-level scenario was first designed for the multi programmable logic controller training platform.

Because this scenario is intended to demonstrate the differences in programmable logic controller implementations, the scenario is simplified in several ways. First, the initial IP addresses of all three programmable logic controllers are the same (192.168.108.205). The new IP addresses that the participants load on the programmable logic controllers are also the same (10.1.4.205). Additionally, the participants need not concern themselves about whether or not changing the IP address would impact the functionality of other industrial control system components. In this scenario, it is assumed that all the other issues regarding components that are dependent on the programmable logic controller IP address have already been reconciled. More complicated scenarios can be developed to demonstrate the potential second-and third-order effects that can occur from this process.

The final scenario simplification is that no password protections exist for any of the files. In a real-world environment, it is reasonable to expect that a cyber first responder would be provided the necessary access by an asset owner to perform the tasks. While credentials are required by the ControlLogix administrative web server, they were reset to the factory-default credentials for demonstration purposes. Finally, the training scenario is implemented using the framework proposed by Yoon et al. [START_REF] Yoon | Evaluating the readiness of cyber first responders responsible for critical infrastructure protection[END_REF].

The following are the details of the training scenario:

Objective: Isolate a programmable logic controller that is located in an improperly segregated network.

Description:

The participant uses the relevant software and appropriate technique to change the programmable logic controller IP address from 192.168.108.205 to the new IP address 10.1.4.205.

Type: Network reconfiguration.

Evaluation Criteria:

-Identify the relevant software within five minutes.

-Identify the appropriate technique for updating the IP address within ten minutes.

-Update and confirm the new IP address within fifteen minutes.

-Perform all the activities with minimal programmable logic controller downtime.

References: NIST SP 800-82, Rockwell Automation EWEB module documentation, Siemens S7-300 documentation and Rockwell Automation CompactLogix documentation.

Segmentation Using a CompactLogix PLC

The first task for the participant is to interact with the CompactLogix programmable logic controller. Updating the IP address of this programmable logic controller involves the following steps:

Step 1: Open the appropriate RSLogix5000 project file and access the Ethernet module properties.

Step 2: Under the Port Configuration tab, enter the new IP address in the appropriate field and click Set. Confirm the update in the dialogue windows that appear.

Step 3: Ensure connectivity to the new IP address (this may require routing or changing the IP address of the engineering workstation).

Step 1 requires the identification of the RSLogix5000 software. Step 2 involves the identification and update of the IP address. Step 3 ensures that the programmable logic controller is available. Since the CompactLogix programmable logic controller can have its IP address updated without downtime, the participant should receive a lower evaluation if the programmable logic controller resets or faults. Figure 9 shows the relevant dialogue window for updating the IP address.

Segmentation Using a Siemens PLC

After the participant has completed the assigned task on the CompactLogix programmable logic controller, the instructor switches control to the Siemens programmable logic controller. After the programmable logic controller has booted, the participant must change the IP address of the Siemens controller to an isolated subnet. This is the first time that the participant is exposed to the differences between the programmable logic controllers. In particular, the programming environment for the Siemens programmable logic controller is different from that of the CompactLogix controller.

The following steps are required to complete the task on the Siemens programmable logic controller:

Step 1: Open the SIMATIC project file.

Step 2: Access the HW Config tab in the SIMATIC software and navigate to the Object Properties of the PN-IO module.

Step 3: Under the General tab, select Properties and enter the new IP address as shown in Figure 10.

Step 4: Download the new configuration to the programmable logic controller using the old IP address as the target station.

Step 5: Ensure connectivity to the new IP address (this may require routing or changing the IP address of the engineering workstation).

Step 1 involves the identification of the SIMATIC software. Steps 2 through 4 involve the identification of the appropriate technique to update the IP address.

Step 5 ensures that the programmable logic controller completes the download successfully with minimal downtime.

Segmentation Using a ControlLogix PLC

The participant now performs the required tasks using an implementation that is unique to the ControlLogix programmable logic controller. The Control-Logix programmable logic controller is equipped with a 1756-EWEB Enhanced Web Server Module that provides an administrative web interface to manage the programmable logic controller.

The following steps are involved:

Step 1: Open a web browser and navigate to the IP address of the programmable logic controller.

Step 2: Open the Network Configuration tab, enter the new IP address in the appropriate field and apply the changes.

Step 3: Confirm that the new address is correct. Upon completion, a message is displayed that notifies the participant of the new IP address.

Step 4: Ensure connectivity to the new IP address (this may require routing or changing the IP address of the engineering workstation).

Step 1 requires the participant to identify the web interface provided by the EWEB module. Step 2 involves the identification and application of the appropriate technique to perform the update. Steps 3 and 4 confirm that the change is successful. There should be no downtime when performing this task on the ControlLogix programmable logic controller.

Scenario Selection and Alternate Scenarios

The network segmentation scenario was chosen because it effectively demonstrates how different programmable logic controllers often require different techniques to perform the same task. These differences emphasize the value of a cyber first responder having experience on a variety of programmable logic controllers. The scenario incorporates several of the training items proposed by Butts and Glover [START_REF] Butts | How industrial control system security training is falling short[END_REF] and implemented in the framework of Yoon et al. [START_REF] Yoon | Evaluating the readiness of cyber first responders responsible for critical infrastructure protection[END_REF].

Note that segmenting a network is only one of many tasks that a cyber first responder may need to complete in his/her line of work and it is certainly not a difficult task. Other examples such as modifying ladder logic programs, updating firmware and applying patches are also unique to different programmable logic controllers and have varying levels of difficulty. Because the training platform incorporates real programmable logic controllers, a number of scenarios, including scenarios involving advanced topics, could be implemented with minimal reconfiguration.

Two scenarios that showcase the flexibility of the multi programmable logic controller platform are described below.

Analysis of a Malicious Implant in PLC Firmware

Objective: Reverse engineer the firmware to identify and analyze a malicious implant.

Description:

The participant uses the relevant software and appropriate techniques to extract programmable logic controller firmware from the device and identifies malicious code given the correct version of the firmware. The participant then determines the exact functionality and purpose of the malicious code.

Type: Reverse engineering.

Evaluation Criteria:

-Identify the malicious code within 45 minutes.

-Restore the programmable logic controller firmware within 20 minutes.

-Analyze the malicious code within 90 minutes.

References: Rockwell Automation ControlLogix documentation, Siemens S7-300 documentation, Rockwell Automation CompactLogix documentation.

The reverse engineering scenario further emphasizes the differences between programmable logic controllers by requiring a participant to extract and analyze firmware from the devices (see [START_REF] Basnight | Firmware Counterfeiting and Modification Attacks on Programmable Logic Controllers[END_REF] for details about reverse engineering industrial control devices). The scenario also brings up the important point that there are often similarities between programmable logic controllers. Specifically, the CompactLogix and ControlLogix programmable logic controllers have very similar firmware despite being different models. The reverse engineering scenario can be implemented with malware samples of varying complexity to accommodate and/or enhance participant abilities.

Digital Forensics of a Malfunctioning PLC

Objective: Determine the cause of a malfunctioning programmable logic controller.

Description:

The participant uses the relevant software and appropriate techniques to identify the root cause of the programmable logic controller behavior.

Type: Digital forensics.

Evaluation Criteria:

-Collect sufficient data to perform digital forensics within 30 minutes.

-Identify the cause of the malfunction within 45 minutes.

-Identify the corrective action within 60 minutes.

References: Rockwell Automation ControlLogix documentation, Siemens S7-300 documentation, Rockwell Automation CompactLogix documentation.

The digital forensic scenario involves similar tasks as the reverse engineering scenario. It also shows that the process for conducting digital forensics on industrial control systems is identical for different programmable logic controllers (see [START_REF] Folkerth | Forensic Analysis of Industrial Control Systems[END_REF] for details about this process). Despite using the same process, the data being analyzed (e.g., ladder logic program, network traffic and log files) would be different because of the operational differences between the programmable logic controllers. These operational differences mean that a cyber first responder in a real-world situation will have to focus on specific, contextualized pieces of information to effectively analyze the root cause of a malfunctioning programmable logic controller. The difficulty of this scenario can be modulated by inducing different types of programmable logic controller malfunctions ranging from simple faults to advanced malware infections. The scenario can be repeated multiple times with different symptoms to increase the participant's exposure to a variety of malfunctions.

Results

This section describes the principal results pertaining to training platform development.

Hardware Verification

The initial debugging of the wiring, Y-Box code and programmable logic controller code involved interacting with the physical components mounted in the Pelican case and confirming that the Y-Box and programmable logic controller behaved as intended. This process revealed that some of the variables had been coded incorrectly in the ladder logic. These variables needed their memory addresses reassigned to correct their mapping to the programmable logic controller inputs and outputs. The Y-Box software was also verified, confirming the behavior of the physical components and that the software could override the physical components to control the case autonomously.

Reliability Test

After confirming that the components were behaving correctly, an automated Python script tested the reliability of the training platform. The test involved the following steps:

Step 1: Select the programmable logic controller.

Step 2: Power up the selected programmable logic controller.

Step 3: Wait 25 seconds for the programmable logic controller to activate.

Step 4: Test all the buttons, locks and lights for functionality.

Step 5: Shut down the programmable logic controller.

Step 6: Reset the Y-Box parameters. Initial runs of the reliability test encountered failures because the Python test code sent commands too quickly, which did not provide the Y-Box with adequate time to update its inputs and outputs. This issue was resolved by including "wait" commands of 25 seconds for the programmable logic controller to boot and varying amounts of time between 0.4 and 2.0 seconds for other functions (e.g., button presses, lock status updates and indicator light updates).

Step 4 is the key part of the reliability test. This step starts with the first jail cell and simulates a button press. The script then checks that the programmable logic controller responds appropriately before repeating the process for the other two cells. Next, the test code evaluates the mantrap by testing every possible combination of button presses and confirming the responses. Finally, it simulates a button press on the cell once again with the panel disabled. In this situation, the lock should not disengage and the test is considered to have failed if it does. The wiring scheme with the Y-Box enables electrical signals to be sent to the programmable logic controller without having to receive signals from the buttons. Furthermore, the state of the panel turnkey can be overridden by the Y-Box itself. These enable each of the functions to be simulated by the Y-Box alone. In the future, the test can be fully automated in a manner that is transparent to the programmable logic controller because the controller receives the same signals as it would under normal operation. To prevent a failure in one iteration from impacting the results of the next iteration, Step 6 resets all the Y-Box values to default values. A total of 150 iterations were performed, with each programmable logic controller tested 50 times. Table 2 shows the reliability test results.

Timing Test

Incorporating multiple programmable logic controllers in a single platform is useless if the switching between the programmable logic controllers takes a prohibitive amount of time. Ideally, control of the system should be switched from one programmable logic controller to another within the amount of time that it takes for the participant to be prepared for the next task. To evaluate this metric, the time required for each programmable logic controller to fully power up was measured and recorded by an automated Python script, which performed the following steps:

Step 1: Select the programmable logic controller.

Step 2: Send power to the programmable logic controller and start the timer.

Step 3: Send the input command to the programmable logic controller.

Step 4: Wait for the programmable logic controller to react to the input and stop the timer upon completion.

Step 5: Shut down the programmable logic controller.

Step 6: Reset the Y-Box parameters.

In the timing test, it is only necessary to examine the amount of time that it takes for the programmable logic controller to become responsive to an input.

Functional Analysis Criteria

The multi programmable logic controller training platform is designed to meet the following criteria: Incorporate physical components.

Incorporate cyber manipulation principles.

Incorporate response coordination techniques.

Provide hands-on experience.

Implement effective training scenarios with measurable training evaluation metrics.

The replication of the jail system, including the programmable logic controllers running realistic ladder logic programs and the pushbuttons, locks, lights and turnkey, enables a training participant to experience many of the physical components involved in a real-world system. This addresses the need for cyber first responders to understand the physical processes underlying an industrial control system.

By creating scenarios that incorporate concepts such as reverse engineering and digital forensics, cyber manipulation principles can be effectively taught to cyber first responders. Participants can be exposed to topics like access vectors, vulnerability analysis, implanting malware, manipulating physical processes and defensive mechanisms, all of which are considered to be cyber manipulation principles [START_REF] Butts | How industrial control system security training is falling short[END_REF].

Skills involved in response coordination include the ability to prioritize system components, identify attacks and understand the steps required to appropriately defend and restore a system to normal operation. Each of these skills is practiced in some way by the scenarios described in this work and can be enhanced by designing alternate scenarios using the training platform.

The entire training platform is self-contained and all the relevant software is embodied in easily-recoverable virtual machines. This enables training participants to have full access to the system for hands-on exercises without being concerned about potential damage to the system. Cyber first responders can benefit most from hands-on exercises that give them experience with realistic systems that incorporate real hardware.

Limitations

The multi programmable logic controller platform has certain limitations. First, the platform does not incorporate any analog components. Analog signals are more complicated than digital signals from a programming perspective and should be incorporated to enhance learning experiences.

Another limitation of the platform is the scale of the replica system. In a full-sized jail, there are many more components, including additional doors and alarms. The design choice leads to the trade-off between training platform cost and scale. The final limitation is that the training platform is limited to the use of one programmable logic controller at a time.

Conclusions

Effective industrial control system platforms are necessary for cyber first responder training. Unfortunately, most testbeds are designed for research and development activities and are not available for training purposes. Furthermore, testbeds developed for training purposes tend to be very expensive or substitute device simulations in place of genuine components. Ideal testbeds incorporate full-scale, fully-operational industrial control systems with training scenarios that impart the unique skills needed by cyber first responders to operate in real-world environments. The cost of such a testbed is prohibitively high; however, the multi programmable logic controller training platform developed in this research can impart many of the desired skills at a fraction of the cost. Furthermore, the multi programmable logic controller training platform can support scenarios ranging from basic tasks such as changing an IP address to advanced tasks involving reverse engineering and digital forensics.

The multiple programmable logic controllers incorporated in the platform provide opportunities for trainees to experience different devices, protocols and programming environments. Similar to medical students, who go through a rigorous curriculum with hands-on, real-world learning experiences, the multi programmable logic controller training platform enables cyber first responders to gain valuable hands-on experience with real control systems to significantly enhance their cyber defense skills.

Note that the views expressed in this chapter are those of the authors and do not reflect the official policy or position of the U.S. Air Force, U.S. Army, U.S. Department of Defense or U.S. Government.

Figure 2 .

 2 Figure 2. Wiring diagram for lights.

Figure 3 .

 3 Figure 3. Wiring diagram for pushbuttons.

Figure 4 .

 4 Figure 4. Wiring diagram for locks.

Figure 5

 5 shows the wiring diagram for an indicator light. The outputs of all

Figure 5 .

 5 Figure 5. Wiring diagram for programmable logic controller inputs and outputs.

Figure 6 .

 6 Figure 6. Wiring diagram for programmable logic controller selection.

Figure 7 .

 7 Figure 7. Exercise layout.

Figure 8 .

 8 Figure 8. White cell view.

Figure 9 .

 9 Figure 9. IP address update of the CompactLogix PLC using RSLogix5000 software.

Figure 10 .

 10 Figure 10. IP address update of the Siemens S7-300 PLC using SIMATIC software.

Table 1

 1

	lists the main components of the platform. The
	pushbuttons, indicator lights and turnkey replicate components that are found

Table 1 .

 1 Training platform components.

	Component	Quantity Component	Quantity
	Cabinet Locks	5	Pushbuttons	5
	Relays (Electromechanical)	5	Red Lights	4
	Relays (Solid State)	3	Peg Boards	2
	Power Supplies (12 V)	1	Power Supplies (24 V)	1
	Network Switches	1	Routers	1
	Circuit Breakers (10 A)	1	Turnkeys	1
	Power Strips	1	CompactLogix PLCs	1
	Siemens S7-300 PLCs	1	ControlLogix PLCs	1
	Y-Boxes	1

Table 2 .

 2 Reliability test results.

	Controller	Trials Failures
	CompactLogix PLC	50	0
	Siemens S7-300 PLC	50	0
	ControlLogix PLC	50	0
	Total	150	0

Table 3 .

 3 Programmable logic controller startup times (seconds).

	Controller	Minimum Maximum Mean Std. Dev.
	CompactLogix PLC	19.547	19.688	19.629	0.030
	Siemens S7-300 PLC	14.782	15.172	15.060	0.062
	ControlLogix PLC	4.797	4.843	4.816	0.010

Table 3

 3 presents the results of the timing test, which were also determined over the course of 150 trials (50 trials per programmable logic controller). The results show that the programmable logic controllers have significantly different boot times, but are very consistent across all the trials.

Acknowledgement

This research was partially supported by the U.S. Department of Homeland Security Industrial Control Systems Cyber Emergency Response Team (ICS-CERT).


Caleb Mays

Mason Rice

Benjamin Ramsey

John Pecarina

Barry Mullins

Defending building automation systems using decoy networks

Keywords: Internet of Things, home and building automation, honeypots

Introduction

The family was in the car ready for a great weekend getaway. They had planned a three-day camping trip -fishing, hiking, s'mores -the whole experience. The father was pulling away from the home and pushed the button on his phone to close the garage door. The mother used her smart phone to verify that the external doors were locked and that the thermostat was set. The father maneuvered the family car past parked vehicles on the street. The family started what they all hoped would be a great weekend.

The weekend was great! The weather was perfect; not too hot, not too cold and no rain. When the family returned home and their car approached the driveway, everything looked normal. The garage door was down, the doors were shut, there were no broken windows and no signs of a break-in. The inside, however, was a different story. The home had been burgled. The TV and entertainment systems were gone. Jewelry was missing. Family heirlooms had been stolen. Somebody was able to open the garage door. The family thought that their garage door could only have been opened and closed via the application on the phone. How did this happen?

Little did the family know that, as they drove away, the intruder was in one of the cars parked on the street. The burglar noticed the car-top carrier, inferring the family would be gone all weekend. The intruder used an inexpensive radio and computer to capture the wireless commands used to open and close the garage door. With a few simple keystrokes, he replayed the command to open the garage door and walked into the home.

Could the family have done anything more to secure their home? Home automation devices are, no doubt, convenient, but automation networks lack proper security. Users are unknowingly making themselves more vulnerable to intruders by using home automation products.

INSTEON is a leading protocol for home and building automation and, like other proprietary protocols, little research has been published about its vulnerabilities. This chapter presents a technique for analyzing INSTEON traffic and defending INSTEON networks using virtual decoys.

Background

The Internet of Things (IoT) and home and building automation are growing fields. These technologies are used to connect to smart appliances in homes and buildings from anywhere in the world. Homeowners can control their lights, ensure their front doors are locked and view thermostat settings on their mobile devices. Building managers can control access and industrial HVAC settings with a few mouse clicks. While home and building automation is a relatively new field, a report by Transparency Market Research [START_REF]Transparency Market Research, Global home automation market will be worth US°21.6 billion[END_REF] projects that the global industry will grow to °21.6 billion by 2020. Gartner [START_REF] Gartner | Gartner says 6.4 billion connected "things" will be in use in 2016, up 30 percent from 2015[END_REF] predicts that Internet of Things devices -for home and business use -will rise from 6 billion to 20 billion by 2020.

Automation Technologies

The home and building automation market incorporates many technologies and protocols (e.g., Wi-Fi, Bluetooth, ZigBee, Z-Wave and INSTEON). Multiple studies have compared the technical specifications and capabilities of these automation technologies [START_REF] Baviskar | Comparative study of communication technologies for power-optimized automation systems: A review and implementation[END_REF][START_REF] Gomez | Wireless home automation networks: A survey of architectures and technologies[END_REF][START_REF] Withanage | A comparison of the popular home automation technologies[END_REF], but very few researchers have evaluated the security of proprietary Internet of Things protocols. The lack of security research leaves homes and businesses vulnerable and dangerously accessible to intruders.

Wi-Fi.

Wi-Fi is a popular technology that is broadly incorporated in homes and businesses. Amazon's Echo and the Nest line of products use this technology. Wi-Fi attacks such as de-authentication and rogue access point attacks are well-known and tools are incorporated in the Kali version of Linux specifically for evaluating Wi-Fi security. Wi-Fi can be secured through strong encryption techniques. Advances in Wi-Fi security will certainly benefit Wi-Fi-enabled Internet of Things devices.

Bluetooth. Rose and Ramsey [15] have demonstrated that many vendors do not implement optional Bluetooth security features (e.g., encryption by properly pairing devices). Improper Bluetooth pairing leads to confidentiality problems. Rose and Ramsey have passively sniffed passwords for several locks. They have documented several security flaws and have developed proofof-concept tools that open several Bluetooth-enabled locks. They also note that, when presented with improper commands (e.g., unrecognized characters), many locks fail in a non-recoverable state, resulting in denial-of-service to users.

ZigBee and Z-Wave. Hall and Ramsey [9,[START_REF] Ramsey | Improved Wireless Security through Physical Layer Protocol Manipulation and Radio Frequency Fingerprinting[END_REF] have researched the Zig-Bee and Z-Wave protocols and have developed tools for securing automation networks that use these protocols. The Philips Hue brand of lights is one product that uses ZigBee. Hall and Ramsey capitalized on Z-Wave broadcast commands to enumerate Z-Wave networks. Their research demonstrates the over-availability problem and general lack of confidentiality in the Z-Wave protocol. Additionally, they discovered problems similar to those encountered in Bluetooth systems, where manufacturers did not implement encryption and other security measures in a proper manner.

INSTEON. INSTEON has been producing home and building automation

devices for more than ten years and recently announced plans to integrate with Revention's point-of-sale system for building automation control [START_REF]Revention, Revention integrates with Insteon to provide automated light fixtures[END_REF]. A wide range of devices, including LED lights, dimmable light switches, open/close sensors and security cameras, are available. INSTEON devices enjoy general acceptance within the Internet of Things community through interoperability with the Amazon Echo and Sonos home surround sound system. Applications on Apple iOS, Google Android and Microsoft Windows 8/10 provide interfaces for monitoring and modifying the devices. Figure 1 presents a schematic diagram of a basic INSTEON network.

Honeypots for Building Automation Defense

The use of honeypots for network defense is not new. The development of traditional honeypots prior to 2006 was constrained by costly hardware. Virtual technologies have since made traditional honeypots inexpensive, convenient and prevalent. Large research honeypots have been used to capture malicious software in information technology networks [START_REF] Bowden | Worm: The First Digital World War[END_REF][START_REF] Provos | Virtual Honeypots: From Botnet Tracking to Intrusion Detection[END_REF].

Using honeypots to defend industrial control and supervisory control and data acquisition (SCADA) networks is a relatively new concept. The Honeynet Project [START_REF] Rist | Conpot ICS/SCADA Honeypot, Honeynet Project[END_REF] has made significant progress in developing an open source honeypot for industrial control networks. Winn et al. [START_REF] Winn | Constructing costeffective and targetable industrial control system honeypots for production networks[END_REF] have researched industrial control system honeypots and have extended the honeyd program to honeyd+ to make it more authentic. They discuss two levels of interaction displayed by a honeypot: (i) high-level interaction; and (ii) low-level interaction. They also argue that the targetability of a honeypot needs to match the intended network and that the decoys must appear authentic enough for an attacker to target the fake devices instead of the real devices. Girtz et al. [START_REF] Girtz | Practical application layer emulation in industrial control system honeypots[END_REF] have enhanced the performance of honeyd+ by developing an application layer emulator. Schneier [START_REF] Schneier | Real-world security and the Internet of Things[END_REF] uses the terms Internet of Things devices and cyber-physical systems interchangeably. He correctly writes that the Internet of Things has given the Internet "hands and feet" with the ability to change physical systems through cyber means. Meanwhile, research in the area of Internet of Things security and industrial control system honeypots are converging. This chapter describes the design and implementation of a honeypot with authenticity and targetability characteristics that can protect an INSTEON home automation network.

Understanding INSTEON

There are three primary sources of information about the INSTEON protocol. The first two documents are published by INSTEON [START_REF] Darbee | INSTEON Developer's Guide (2nd Edition)[END_REF][START_REF]INSTEON Whitepaper: The Details, Version 2[END_REF]. The third source is a presentation and software produced by security researchers, Shipley and Gooler [START_REF] Shipley | Insteon: False security and deceptive documentation[END_REF].

INSTEON Documentation

INSTEON created its own communications protocol and published many of the specifications. Two documents, INSTEON: The Details [START_REF]INSTEON Whitepaper: The Details, Version 2[END_REF] and IN-STEON: Developer's Guide [START_REF] Darbee | INSTEON Developer's Guide (2nd Edition)[END_REF], are intended to inform developers, security professionals and users about the protocol. [START_REF]INSTEON Whitepaper: The Details, Version 2[END_REF] describes the specifications of INSTEON's wireless and power-line protocol settings, packet structure, hopping mechanism, timing scheme, network diagram and many other details. INSTEON claims to use 915 MHz as the center frequency and frequency shift keying (FSK) with a 64 KHz frequency shift as the radio frequency (RF) modulation method, and encode the signal using the Manchester scheme.

INSTEON: The Details. INSTEON: The Details

INSTEON defines its own packet structure, which is shown in Figure 2. An INSTEON packet contains five mandatory fields and one optional field. The structure starts with the source and destination device addresses. INSTEON device addresses, which are three bytes long, are set during manufacturing and remain static. The packet structure continues with one byte for flags, two bytes for commands, an optional user-data field and ends with a one-byte cyclic redundancy check (CRC).

INSTEON flags describe the type of message contained in a packet (e.g., broadcast or non-acknowledgment, group, acknowledgment, extended or standard length), the number of hops remaining and the maximum number of hops allowed for the packet. Standard-length packets are ten bytes long while extended-length packets include 14 bytes of user-defined data, making these packets 24 bytes long. INSTEON messages are not routed like typical Internet Protocol messages. Instead, packets traverse the network by hopping across devices. A packet may hop a maximum of three times as it traverses the network to its destination device.

INSTEON devices are statically networked during the setup (pairing) process. A user performs a series of button-pushes and uses the INSTEON mobile application to program the devices. One device is the controller (master) while the other device is the responder (slave). INSTEON devices can be networked to communicate in a mesh network to limit service disruptions due to malfunctioning devices. The INSTEON hub connects to the user's home router for Internet access. The specifications describe the ability to include encrypted [START_REF] Darbee | INSTEON Developer's Guide (2nd Edition)[END_REF] and [START_REF] Shipley | Insteon: False security and deceptive documentation[END_REF].

data using the user-data field of extended length messages. This capability is an add-on that may be implemented by device developers. [START_REF] Darbee | INSTEON Developer's Guide (2nd Edition)[END_REF] provides additional information about the INSTEON protocol. While most of the specifications in the document match those provided in the previous document [START_REF]INSTEON Whitepaper: The Details, Version 2[END_REF], a few details about the radio frequency specifications differ. Specifically, the frequency shift keying deviation and symbol rate are listed as 200 KHz and 9.124 KBaud, respectively. Additionally, as shown in Figure 3, the IN-STEON packet structure varies from the structure described in the previous document.

INSTEON: Developer's Guide. INSTEON: Developer's Guide

Previous Research

the pilot studies and experiments used to test and improve the packet capture success rate. Third, Shipley and Gooler have not presented a method for enumerating or investigating INSTEON devices; this limitation provided the motivation to find commands that could be used to query and identify INSTEON devices beyond the device address.

Integrating Wireshark

Wireshark is the de facto network traffic analysis tool. Shipley and Gooler's research did not integrate with Wireshark. Instead, INSTEON network traffic was outputted to a terminal window. This made it difficult to view and analyze the packets or save traffic data.

The integration with Wireshark is a three-step problem: (i) outputting pcap data; (ii) developing a dissector to interpret the protocol; and (iii) configuring Wireshark to use the dissector. Over the course of this research, Shipley and Gooler's receiver was enhanced by integrating Wireshark [START_REF] Mays | INSTEON, inste-off, inste-open? presented[END_REF].

Pilot Studies

The first pilot study described in this section captured packets between the INSTEON hub and an LED light. The results established the baseline for the packet capture success test. The second pilot study discovered and verified a command for querying a device for its characteristics.

Pilot Study 1: Determining Packet Count. This pilot study employed a similar experimental setup but a significantly more robust reception method than the one used by Shipley and Gooler. The study determined that, for every "on" command, the hub and LED exchanged eight packets. The same was true for every "off" command. Turning the light on and off 20 times produced a total of 320 packets. This established a baseline number for the packet capture success rate experiment. Additional details about this experiment are provided in Section 4.1.

Pilot Study 2: Enumerating Devices. Command tables from 2007

(see [START_REF] Darbee | INSTEON Command Tables, Revision 20070927a[END_REF]) describe a command that can be used to request the identity of a device. Three messages are transmitted as illustrated in Figure 4. First, the controller device issues the command to request the identity of the responding device. The responding device transmits an acknowledgment of the command and then responds by transmitting a broadcast message. In the INSTEON protocol, broadcast messages are typically used in the device pairing process and have a unique structure. INSTEON broadcast messages contain the device category, subcategory and firmware version of the source device. Figure 5 shows the packet structure of a broadcast message.

The documentation [START_REF] Darbee | INSTEON Device Categories and Product Keys[END_REF] identifies device category 0x05 as corresponding to an "access control" device. Tests confirmed that the devices and their respective categories match the documentation. Thus, the device category can be used as the basis for device enumeration. Note that the device category also informs an attacker about the device that is being controlled (e.g., lighting control, climate control or access control).

INSTEON Protocol Summary

The

Experiments

Two experiments were conducted. The first experiment investigated the packet capture success rate of Shipley and Gooler's receiver and attempted to improve the packet capture rate. The second experiment evaluated the authenticity and targetability of the honeypot developed during this research.

Packet Capture Experiment

The conflicting documentation summarized in Section 3.5 provided the control variables for this experiment. The experiment had two objectives. The first objective was to validate (or refute) Shipley and Gooler's claims regarding the INSTEON radio frequency protocol specifications, specifically the center frequency, frequency shift keying value and symbol rate. The second objective was to determine the best settings to obtain the maximum packet capture success rate with the YARD Stick One software-defined radio.

Two INSTEON devices were used in the experiment: (i) INSTEON hub with Internet connectivity; and (ii) INSTEON LED bulb. The INSTEON hub application on a Windows Surface 3 computer was connected via the Internet to the INSTEON hub to control the LED light. The YARD Stick One was connected to a separate laptop running Ubuntu Linux and the software-defined radio configurations. Figure 6 presents the experimental network environment.

The experiment used the pilot study results described in Section 3.4 as the baseline for the packet capture success rate. The light was turned on and off 20 times to generate 320 packet transmissions while the receiver listened for packets. Each received or dropped packet was viewed as a separate, binary trial (successful or failed reception).

The experiment produced data with a binary distribution. The 320 individual results were pooled and viewed as a single trial. The number of received packets was divided by the number of total packets transmitted to compute the mean packet capture success rate.

The experiment involved varying the frequency between the three values in Table 1 (914.95 MHz, 914.975 MHz and 915 MHz). The frequency deviation and symbol rate were held constant at the start according to Shipley and Gooler's specifications. The best frequency was used in the test for the next control variable, and so on. If there was no distinguishable difference between a given variable, then Shipley and Gooler's settings were used for the next trial. Note that the symbol rate of 76.8 KBaud was assumed to be incorrect in [START_REF] Darbee | INSTEON Developer's Guide (2nd Edition)[END_REF][START_REF] Shipley | Insteon: False security and deceptive documentation[END_REF]. The decision was made to vary the symbol rate between 9 KBaud, 9.125 KBaud and 9.250 KBaud. This resulted in seven radio configurations for the experiment. Table 2 shows the configuration for each experimental trial.

Functional Testing Experiment

The evaluation of the honeypot involved a functional test for authenticity and targetability. This experiment had two goals. The first goal was to ensure that a single honeypot network enumeration and map matched the genuine INSTEON device enumeration and map, enabling an attacker to believe that The test environment consisted of an INSTEON hub, thermostat, two LED bulbs, a regular light bulb with a lamp dimmer module and a lock controller with door lock. Figure 7 illustrates the experimental environment. The honeypot was hosted on a high-performance computer platform (Dell Precision M4500 laptop running Ubuntu 14.04 LTS). A single honeypot host controlled the distinct honeypot networks.

The honeypot target had to be authentic enough so that an attacker could interact with the virtual devices. A successful implementation would involve the virtual devices responding to commands in a manner identical to genuine devices.

The authenticity portion of the experiment involved the attacker enumerating the devices using the Identity Request command described in Section 3.4. The attacker created a full network map by spoofing this command between all known devices. Figure 8 shows the results of the true INSTEON network scan. An interesting point is that the thermostat (ID: D6 F1 32) responded to every other INSTEON device. This is not typical of INSTEON devices and is due to a flaw in the thermostat logic. Based on this information, a decision was made to allow the honeypot thermostat to have the same "flaw."

A targetable honeypot should have multiple decoys to draw the attention of attackers. The decoys should appear to be positioned in the appropriate environments. A single Internet of Things light bulb would be of little interest to an attacker when it is not connected to a larger home automation network. However, the presence of several connected devices could convince an attacker that the decoys are part of a legitimate home automation system. Indeed, an INSTEON hub, thermostat, multiple lights and lock controller would present a network that is reasonably similar to an INSTEON home network, thus posing as an attractive target to an attacker. The targetability portion of the experiment involved checking for the presence of Android devices connected to the INSTEON application. When a user logs into the mobile application, the hub requests the status of all non-batterypowered devices in the INSTEON network. Figure 9 shows the Wireshark output of the traffic generated when the INSTEON hub requests the status of a device. The honeypot was intended to mimic similar network traffic, thus rendering the honeypot devices targetable by an attacker. The traffic was gen- The honeypot functional testing experiment involved the creation of a honeypot with one virtual network and five distinct virtual networks. If all the honeypot networks mimicked the genuine network, then the honeypot networks would be targetable and would help hide the genuine network from a would-be attacker.

Experimental Results

This section analyzes the results of the packet capture and honeypot functional testing experiments.

Packet Capture Experiment

A 99% confidence interval plot was generated for each pooled trial with comparison plots to present the results. Additionally, a linear model for the binary logistical distribution was produced to verify the results.

Figure 10 shows the impact of varying frequency while keeping the frequency shift keying value and symbol rate constant at 150 KHz and 9.125 KBaud, respectively. The 915 MHz frequency produced a packet capture rate of approximately 65%. The 914. [START_REF]A3 2E responds to[END_REF] MHz frequency, which is in the open-source code published by Shipley and Gooler, produced an inferior packet capture rate (approximately 40%) compared with the other frequencies. The final test varied the symbol rates between 9 KBaud, 9.125 KBaud and 9.25 KBaud while maintaining the center frequency at 915 MHz and the frequency shift keying value at 150 KHz. The confidence intervals revealed that the packet capture rates were not statistically different.

A graph containing the confidence intervals for each experimental trial was constructed and a linear model for the regression was created. Figure 12 shows the confidence interval plots for all the experimental trials. The best reception rate was obtained at approximately 75% when the center frequency was 915 MHz, frequency shift keying value was 64 KHz and symbol rate was 9.125 KBaud. The center frequency of 914.95 MHz encoded in Shipley and Gooler's software clearly yielded an inferior packet capture rate. Modifying the center frequency variable was determined to be statistically significant in improving the packet capture success rate.

Figure 13 shows the linear model. This analysis verifies that the frequency has a statistically significant impact on the packet capture rate and that no other variables are statistically significant.

Functional Testing Experiment

The honeypot functional testing experiment involved two parts. First, the authenticity of the honeypot was determined by mapping and investigating the honeypot network individually and comparing it with the baseline (genuine) INSTEON network. Next, the targetability of the honeypot was measured by determining if the honeypot devices presented themselves in a manner similar to the genuine INSTEON devices.

Figure 14 presents the network enumeration used to determine the authenticity of the honeypot. Table 3 summarizes the genuine INSTEON network enumeration compared with the honeypot enumeration. The honeypot devices match the true INSTEON devices with regard to device category information and when compared against the complete network map in Figure 8. Therefore, the honeypot network accurately mimics the genuine INSTEON network, helping convince an attacker that the virtual devices are authentic.

The targetability of the honeypot was determined by presenting distinct honeypot networks together with the genuine network. Figure 15 Figure 16 shows six networks -one genuine INSTEON network and five honeypot networks -running simultaneously. In each case, the simulated network traffic presented by the honeypot devices is functionally identical to the traffic presented by the genuine INSTEON network devices. This helps "hide" the genuine network among the honeypot networks. Instead of a single genuine network, an attacker is presented with six distinct, targetable networks. This protects the genuine network by reducing its attack probability to 1/6, unless the attacker performs deeper analysis before targeting the networks.

compares the

Limitations and Future Work

The honeypot developed in this research is limited in the types of devices it can replicate. Currently, the honeypot is programmed to mimic dimmable lights, access controllers, hubs and thermostats. A typical user would have these devices, but may have other types of devices as well. Other device types include switched lighting controls (e.g., in-wall light switches and dimmers) and security and safety sensors (e.g., door open/close, motion and leak sensors). These capabilities need to be investigated and incorporated in the honeypot.

Additionally, the performance of the honeypot was not measured in the experiments. An experiment that measures packet response times could be performed to identify the number of honeypot devices that could be instantiated before the honeypot experiences noticeable delays.

In its current state, the honeypot developed in this research is purely a decoy. Additional reporting and logging capabilities must be implemented before the honeypot can serve as a robust defensive tool. A relatively simple reporting capability could be implemented by installing an email server in the honeypot host that sends email messages to the user when events of interest occur.

Conclusions

Security and safety are becoming priorities as home and building automation technologies and Internet of Things devices proliferate. Device developers and manufacturers need to incorporate sound security engineering principles throughout the design and implementation phases of home and building automation systems. INSTEON is a leading Internet of Things protocol for home and building automation. The proposed technique for analyzing INSTEON traffic using a YARD Stick One software-defined radio improves the packet capture rate from approximately 40% to almost 75% compared with previous efforts. Additionally, the virtual INSTEON decoy networks developed in this research have excellent authenticity and targetability characteristics, which renders them attractive candidates for helping secure home and building automation systems as well as Internet of Things devices in general.

Note that the views expressed in this chapter are those of the authors and do not reflect the official policy or position of the U.S. Air Force, U.S. Army, U.S. Department of Defense or U.S. Government.

Figure 1 .

 1 Figure 1. INSTEON network.

Figure 4 .

 4 Figure 4. Device identification request, acknowledgment and response messages.

Figure 5 .

 5 Figure 5. Packet structure for broadcast messages.

Figure 6 .

 6 Figure 6. Experimental network environment for packet capture.

Figure 7 .

 7 Figure 7. Experimental network environment for functional testing.

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Figure 8 .

 8 Figure 8. INSTEON network baseline enumeration.

Figure 9 .

 9 Figure 9. Wireshark output of device status request and response.

Figure 10 .

 10 Figure 10. Packet capture results for various center frequencies.

Figure 11 .

 11 Figure 11. Packet capture results for various frequency shift keying values.

Figure 11

 11 Figure11shows the confidence intervals when the frequency was held constant at 915 MHz and symbol rate was 9.125 KBaud, while the frequency shift keying value was varied between 200 KHz, 150 KHz and 64 KHz. No statistical difference in the packet capture rate was observed when varying the frequency shift keying value, although tuning the value to 64 KHz captured approximately 75% of the packets.The final test varied the symbol rates between 9 KBaud, 9.125 KBaud and 9.25 KBaud while maintaining the center frequency at 915 MHz and the frequency shift keying value at 150 KHz. The confidence intervals revealed that the packet capture rates were not statistically different.A graph containing the confidence intervals for each experimental trial was constructed and a linear model for the regression was created. Figure12shows the confidence interval plots for all the experimental trials. The best reception rate was obtained at approximately 75% when the center frequency was 915 MHz, frequency shift keying value was 64 KHz and symbol rate was 9.125 KBaud. The center frequency of 914.95 MHz encoded in Shipley and Gooler's software clearly yielded an inferior packet capture rate. Modifying the center frequency variable was determined to be statistically significant in improving the packet capture success rate.Figure13shows the linear model. This analysis verifies that the frequency has a statistically significant impact on the packet capture rate and that no other variables are statistically significant.

Figure 12 .

 12 Figure 12. Results of all the experimental trials.

Figure 14 .

 14 Figure 14. Honeypot baseline scan.

Figure 15 .

 15 Figure 15. Genuine INSTEON network and a honeypot network.

Figure 16 .

 16 Figure 16. Genuine INSTEON network and five honeypot networks.

  INSTEON documentation and previous research are inconsistent about the wireless specifications and packet structure of the INSTEON protocol. As mentioned above, one document states that the center frequency is 915 MHz while Shipley and Gooler claim that the true center frequency is 914.975 MHz. Further examination of Shipley and Gooler's code reveal a third potential center frequency value of 914.95 MHz. Neither the INSTEON documentation nor previous research agree on the frequency shift keying value. Additionally, the documentation and previous research disagree on the frequency shift keying symbol rate -one document lists 76.8 KBaud, another lists 9.124 KBaud and Shipley and Gooler list 9.125 KBaud. Table 1 summarizes the discrepancies. These conflicts lead researchers to ask: Which values are correct?

Table 1 .

 1 INSTEON radio frequency specifications from all sources.

	Specification	The Details	Developer's Shipley and Gooler Guide
	Center Frequency	915.000 MHz	915.000 MHz	914.975 MHz 914.950 MHz (in code)
	Encoding Method	Manchester	Manchester	"Tokenized" Manchester
	Modulation Method FSK	FSK	Inverted FSK
	FSK Shift	64 KHz	200 KHz	150 KHz
	FSK Symbol Rate	76.800 KBaud 9.124 KBaud	9.125 KBaud

Table 2 .

 2 Packet capture trial runs.

	Trial Frequency	Shift	Symbol Rate
	1	914.950 MHz 150 KHz 9.125 KBaud
	2	914.975 MHz 150 KHz 9.125 KBaud
	3	915.000 MHz 150 KHz 9.125 KBaud
	4	915.000 MHz	64 KHz 9.125 KBaud
	5	915.000 MHz 200 KHz 9.125 KBaud
	6	915.000 MHz 150 KHz 9.000 KBaud
	7	915.000 MHz 150 KHz 9.250 KBaud

the experiment because it was very different from the values in the INSTEON documentation

Table 3 .

 3 Genuine INSTEON network compared with one honeypot network.

INSTEON ID Honeypot ID Device Category Matched

  The honeypot generates network traffic that mimics a user checking the status of the lights, thermostat and other simulated devices. Therefore, the simulated traffic presents a targetable, distinct honeypot network to an attacker. The networks appear to be identical, thus deceiving the attacker that multiple distinct INSTEON networks are present.

	DE C2 33	B1 B1 B1	Network bridge
	D6 F1 32	C1 C1 C1	Climate control
	E7 5C 2F	D1 D1 D1	Dimmable light control
	33 D3 32	E1 E1 E1	Dimmable light control
	95 A3 2E	A1 A1 A1	Dimmable light control
	56 E2 3E	F1 F1 F1	Access control
	two networks -one genuine INSTEON network and one honeypot network -
	running simultaneously.

Shipley and Gooler[START_REF] Shipley | Insteon: False security and deceptive documentation[END_REF] have reverse engineered the INSTEON protocol and developed a basic transmitter and receiver using the YARD Stick One softwaredefined radio. They also claim that INSTEON's documentation is incorrect. Specifically, they maintain that INSTEON: Does not use the 915 MHz center frequency, but instead 914.975 MHz (914.95 MHz is coded in the software-defined radio receiver). Does not use true Manchester encoding. Does not use "traditional" frequency shift keying, but instead inverted frequency shift keying. Does not use the frequency shift keying value specified in the documentation. Does not use the symbol rate specified in the documentation. Does not use the cyclic redundancy check algorithm as specified in the documentation. Does not use the packet structure specified in the documentation. Figure 3 presents Shipley and Gooler's claimed INSTEON packet structure.While Shipley and Gooler's transmitter and receiver tool work, they are limited and could be improved; this was the impetus for the research described in this chapter. First, the receiver program outputs packets directly to the terminal. Second, the receiver seemingly drops packets; this chapter describes

Acknowledgement

This research was partially supported by the U.S. Department of Homeland Security Industrial Control Systems Cyber Emergency Response Team (ICS-CERT).