EE5022: Cyber Security for

Internet of Things

Securing IoT and Industrial Control Systems

1
 Outline
2

 Security incidents in IoT and CPS Cyber-Physical Systems

 Cybersecurity goals
 IoT security considerations
 ICS security considerations Industrial Control Systems
 Best practices

Biplab Sikdar
 Mirai Botnet Attack
3

 DDoS attack on Dyn

 Dyn is a managed DNS services provider
 Dyn provides DNS services for Twitter, SoundCloud, Spotify,
Reddit, Amazon, PayPal and a host of other sites
DNS server

Singtel network

Biplab Sikdar
 Mirai Botnet Attack
4

 Attacked on Friday October 21, 2016 during 11:10 UTC to

13:20 UTC and from 15:50 UTC to 17:00 UTC
 DDoS attack against Dyn’s Managed DNS infrastructure
 Complex and sophisticated attack, using maliciously targeted,
masked TCP and UDP traffic over port 53
 Dyn confirmed Mirai botnet as primary source of malicious
attack traffic.
 Attack generated compounding recursive DNS retry traffic,
further exacerbating its impact.

Biplab Sikdar
 Mirai Botnet Attack
5

Biplab Sikdar
 Mirai Botnet Attack
6

Biplab Sikdar
 Mirai Botnet Attack
7

 Took over a number of IoT Devices

such as CCTV cameras, DVRs, routers
 White-labeled DVR and IP

cameras
 username: root and password:
xc3511
 password hardcoded into device
firmware

Biplab Sikdar
 Mirai Botnet Attack
8

Biplab Sikdar
 Mirai Botnet Attack
9

 Advances in attacker capabilities:

 620 Gbps attack against KrebsOnSecurity.com (09/2016)

 990 Gbps attack against French hosting provider OVH

(09/2016)
 1200 Gbps attack against DNS provider Dyn (10/2016)

Biplab Sikdar
 Mirai Botnet Attack
10

 Botnets for hire:

 Two hackers renting access to a Mirai botnet: claim has

more than 400,000 infected bots, ready to carry out DDoS

attacks
 Israeli DDoS-for-Hire service called vDos

 Mirai code is now open-source

 Cost of hiring a botnet:

 Software-as-a-service model

 From 20-50 UD$ for an hour per month

Biplab Sikdar
 Possible Attacks on IoT
11

Latif, Rabia, et al.

"Distributed Denial of Service
Attack Source Detection
Using Efficient Traceback
Technique (ETT) in Cloud-
Assisted Healthcare
Environment." Journal of
medical systems 40.7 (2016):
1-13.

Biplab Sikdar
 Examples of (Insecure) IoT Devices
12

 IP Camera
 Router
 Baby monitor
 Smart home
 Network Attached Storage
 Smart cars

Biplab Sikdar
 Example 1: ChargePoint EV Charger
13

 Supports Wi-Fi and Bluetooth

protocols
 J1772 EV socket type
 Two output power levels – 16 Amp
and 32 Amp
 Offers remote start, scheduling,
reminder, energy tracking and other
remote features through the
ChargePoint mobile app

Biplab Sikdar
 Example 1: ChargePoint EV Charger
14

 Two PCBs connected by a

proprietary cable
 Power board: This board is
mainly used for controlling
current commutation between an
electrical network and a
vehicle’s outlet
 Panda board: Wi-Fi, Bluetooth
and NFC protocols

Biplab Sikdar
 Example 1: ChargePoint EV Charger
15

 Panda board:
 Stores the firmware on a
Flash NAND chip by
Micron
 Includes a JTAG debug
socket
 Use OpenOCD scripts and
the JTAG socket to read
and write NAND content

Biplab Sikdar
 Example 1: ChargePoint EV Charger
16

 NAND image can be reverse engineered and analyzed

using open source tools (e.g., binwalk)
 Root access:
 The Linux kernel had an open telnet
port with password authentication
 Inject code through JTAG socket into
password verification procedure
 Authentication procedure uses a BEQ
 If BEQ is changed to BNE, authentication
is bypassed with an incorrect password
 A permanent user account with root
access can now be created in the device
Biplab Sikdar
 Example 2: Smart Meters
17

 Itron Centron CL200 smart meter:

 Primary functionality: measure customer’s
energy usage and report the collected
information through an RF channel
 This information is used to charge the
customer for their energy usage and to
get statistics on community energy usage
 Physical attack: Node tampering
 Attacker captures the device hardware

and tampers with its electronic circuit

 Objective: change the DeviceID of the
smart meter
Biplab Sikdar
 Example 2: Smart Meters
18

 Hardware analysis:
 Main board: measures line and reference voltages, checks
the energy flow direction, energy pulse data, and line
frequency.
 Daughter board: contains a ATMega microcontroller, a
tamper sensor, and a 1 KB EEPROM and collects energy
usage information, tamper data, and board ID.
 The microcontroller can be used to re-enable JTAG, and re-
enable write access for on-chip memories.

Biplab Sikdar
 Example 2: Smart Meters
19

 Duaghter board:

Biplab Sikdar
 Example 2: Smart Meters
20

 Changing the ID:

 ID of the meter: found on the front of the device underneath
the plastic cover
 Analysis of on-chip memory: the ID was being stored in the
external EEPROM
 The EEPROM dump shows where the ID is stored and it can
then be changed to any arbitrary value

Biplab Sikdar
 Example 3: Smart Home
21

 Haier SmartCare:
 A smart device to control and read
information from sensors and
actuators in a user’s home
 Connections through ZigBee
 To connect to the device, users need
to download a mobile app
 Users create an account through the
manufacturer’s cloud service to view
their and interact with their devices
from outside of their local network

Biplab Sikdar
 Example 3: Smart Home
22

 Hardware:
 Processor: TI AM3352BZCZ60
(contains ARM Cortex A8 and
supports Linux and Android)
 Device has a UART connection
that can be used to read serial
data from the device
 This connection can be used to
view its start up sequence,
interrupt and modify the boot
process, and open a shell

Biplab Sikdar
 Example 3: Smart Home
23

 Through the shell:

 The boot output shows that the device is running Linux and
the shell has root privileges
 Being on the root shell of the device also provides access to
the password hashes on the device

Biplab Sikdar
 Example 3: Smart Home
24

 Cracking the password:

 Documentation on Linux shadow file structures: this device
was using DES encryption on the password while also not
using a salt
 This means that the password is truncated to a maximum of
eight characters then hashed
 Dictionary attack with 32 million passwords failed
 Brute force attack: total keyspace σ8𝑖=0 95𝑖
 Two AMD R9 290 graphics cards ~ five hours to get the

root password

Biplab Sikdar
 Example 4: IP Camera
25

 Edimax camera system:

 Three components: camera, controller, and cloud servers
 Controller and camera in same local network: controller
directly fetches live video from web server on the camera
 Remote scenario: controller communicates with the camera
via cloud servers (registration and command relay servers)

Biplab Sikdar
 Example 4: IP Camera
26

 Registration:
 First configure the camera to use the home wireless network
 Binding: can change password and other configurations (e.g.,
resolution) via a web page of the camera (host = IP address
of camera, http://host/setup.asp?r=20141126)
 Camera and controller register with two remote servers, i.e.,
registration server and command relay server (port 8760)
 The packets transmitted between the controller, camera, and
remote servers are obfuscated (by doing a constant right
shift on all characters) instead of encrypted
 During registration, all the packets use UDP

Biplab Sikdar
 Example 4: IP Camera
27

 Registration Step 1 (registration server):

 The camera to registration server: packet with a value of “1”
in the “opcode value” field, and a UUID (Universally Unique
Identifier) in the “id value” field
 Registration server to camera: packet with command value
“10” and the UUID received from the camera

Biplab Sikdar
 Example 4: IP Camera
28

 Registration Step 2 (command relay server):

 Camera to command relay server: packet with command
value “1” and new UUID to uniquely identify this connection
 Command relay server to camera: packet with command
value “10” and UUID received from the camera

Biplab Sikdar
 Example 4: IP Camera
29

 Registration Step 3:
 On receiving the response from command relay server, the
camera sends a packet with a command value “2” and new
UUID to the registration server
 It is used to inform the registration server the fact that it has
registered with the command relay server.

Biplab Sikdar
 Example 4: IP Camera
30

 Registration Step 4:
 Camera sends two successive packets to registration server
 The first packet (with code value of “3000”) informs the
registration server that the camera is online
 The second packet (with code value of “1010”) carries
camera information (e.g., camera model, firmware version)

Biplab Sikdar
 Example 4: IP Camera
31

 Registration Step 4:
 Registration server responds with a packet with a code value
of “1020”
 The camera repeats STEP 1 to STEP 4 around every 20
minutes to inform the registration server that the camera is
online

Biplab Sikdar
 Example 4: IP Camera
32

 Camera Discovery and Authentication:

 Discovery phase: controller first checks if the camera is online
via the registration server
 It then sends the authentication information to it.

Biplab Sikdar
 Example 4: IP Camera
33

 Camera Discovery and Authentication Step 5:

 User inputs camera ID and password in the controller GUI
 Controller to registration server:
 Packet 1 (code “3000”): to inform the registration server that
the controller wants to check the state of the camera
 Packet 2 (code “2030”): contains camera details and a relay ID
(used in the later communication phase)

Biplab Sikdar
 Example 4: IP Camera
34

 Registration server to controller:

 If the camera is offline: packet with code “5000”
 Otherwise: packet with code “2040” with IP addresses and
ports of both camera and command relay server, and relay ID
 Registration server to camera:
 Packet with code “2020” that includes the IP addresses and
ports of the command relay server and the relay ID

Biplab Sikdar
 Example 4: IP Camera
35

 Camera and Controller Communication Step 6:

 Both camera and controller establish TCP connections with the
command relay server and provide the relay ID
 The command relay server interconnects these two TCP
connections and relays the data between them
 The command relay server does not send any response
packets to either the camera or the controller

Biplab Sikdar
 Example 4: IP Camera
36

 Images from Camera Step 7:

 Controller to camera via command relay server: request
packet contain a value of “/mobile.jpg” in “url value” field,
and authentication information in “auth value” field.
 Authentication information: format username:password and
encoded in the Base64 scheme (default admin:1234)

Biplab Sikdar
 Example 4: IP Camera
37

 Images from Camera Step 8:

 On receiving the request, the camera first checks the
authentication information
 If authentication information is correct, the camera sends
images to the controller via the command relay server
 Otherwise, the camera sends an authorization failure packet
to the controller
 Controller has to send the request packet that contains the
authentication information every time it wants a picture
(repeat steps 7 and 8)

Biplab Sikdar
 Example 4: IP Camera
38

 Device scanning attack:

 Attacker can find out all online cameras by enumerating all
the possible MAC addresses
 Recall connection establishment phase: controller’s “2030”
packet is followed by server’s “2040” packet if the camera
is online and “5000” packet is offline
 Attacker can construct a “2030” packet with the specified
camera MAC address, and check whether the specified
camera is online according to the response packet.
 The MAC address space of a manufacturer can be known
from the Internet.

Biplab Sikdar
 Example 4: IP Camera
39

 Device spoofing attack:

 Phase 1:
 Attacker picks online camera (from device scanning) and
creates a software bot with the specific MAC address
 Phase 2:
 The bot registers with registration server and command relay
server by performing STEP 1 to STEP 4.
 Once the bot receives a packet with code “1020” from the
registration server, the attacker knows that the spoofed camera
is online.

Biplab Sikdar
 Example 4: IP Camera
40

 Device spoofing attack:

 Phase 3:
 When the user opens the control app: the app contacts the
registration server as in STEP 5
 The registration server forwards the packets to the bot and also
informs the control app that the camera is online
 Phase 4:
 The control app builds a TCP connection to the command relay
server which forwards the authentication information to the bot
 Authentication information: Base64 encoded as
username:password which is trivial to decode

Biplab Sikdar
 Example 4: IP Camera
41

 Device spoofing attack:

 Phase 5:
 The bot should get offline as soon as it obtains the
authentication information
 The real camera registers with the registration server and the
command relay server every 20 minutes
 Then the user can see the images and videos taken by real
camera again and may not realize that the camera has been
compromised
 Once the attacker obtains the password, he/she can fully
control the camera

Biplab Sikdar
 Top IoT Vulnerabilities: 1
42

 Serial port exposed:

 IoT devices often have various serial ports on the devices.
 These ports or interfaces when exposed to a malicious user
or attacker could enable them to interact with the device.
 This interaction could lead to the leakage of sensitive
information from the device, dumping the firmware and
performing additional exploitation.
 Most of the devices with exposed serial port also don’t
have secure authentication mechanisms for the ports.
 Examples: routers, baby monitors, IP cameras, smart
thermostats, smart home automation devices

Biplab Sikdar
 Top IoT Vulnerabilities: 1
43

Biplab Sikdar
 Top IoT Vulnerabilities: 1
44

Biplab Sikdar
 Top IoT Vulnerabilities: 2
45

 Default credentials:
 Most home and enterprise IoT devices ship with default
passwords which can be brute forced in minutes or hours.
 Attackers with limited skill can compromise an IoT device.
 Manufacturers often don’t provide the ability to the user to
change the login credential
 Example: Mirai botnet (IoT devices with open ports for
common services that used default credentials)
 Some of the devices which were affected by Mirai had to
even recall their devices since they had no external way to
change the password on their IoT devices.

Biplab Sikdar
 Top IoT Vulnerabilities: 3
46

 Hardcoding issues:
 Sensitive and confidential information are often hardcoded
in IoT device firmware: private certificates, API keys,
passwords to online databases and servers
 Anyone with access to the firmware can see these values.
 Firmware analysis can also expose staging URLs,
development environment details, and encryption keys.
 Some of the common hardcoding issues can be detected by
simply running an automated script which would extract the
file system from the firmware and look through all
individual files and folders for sensitive information.

Biplab Sikdar
 Top IoT Vulnerabilities: 4
47

 Insecure mobile and web applications:

 Many IoT manufacturers do not pay attention to the
security of mobile application and web based dashboards.
 Vulnerabilities: authorization and authentication process
 Mobile/web applications can reveal sensitive information
such as the entire functioning and command pattern of the
IoT devices, which if identified can be used to take over
the smart device.
 Examples: baby monitors, smart anti-theft alarms, smart
thermostats (by SQL and XML injection, authentication
bypass and unauthorized access).

Biplab Sikdar
 Top IoT Vulnerabilities: 5
48

 Insecure network communication:

 Allows an attacker to get access to sensitive information on
the fly, and gain insights on the working of the IoT device.
 Wireless communication mechanisms can be easily sniffed.
 This information may be used to craft packets which can
compromise the entire system.
 To identify insecure network communication: a proxy tool
capable of performing a Man-In-The-Middle attack thus
intercepting the entire communication between the
different devices, and modifying the packets on the fly.

Biplab Sikdar
 Top IoT Vulnerabilities: 6
49

 Missing integrity and signature verification:

 Integrity checks and signature verification for IoT devices is
needed for a strong defense.
 These protection mechanisms should be implemented all the
way from the bootloader, to file system, to OTA updates,
and network communication.
 Without such checks an attacker may modify the original
component with a malicious counterpart and compromise
the device.

Biplab Sikdar
 Other Security Issues
50

 Difficult to update firmware and OS

 Lack of vendor support for repairing vulnerabilities
 Coding errors (buffer overflow)
 Clear text protocols and unnecessary open ports
 DoS / DDoS
 Physical theft and tampering

Biplab Sikdar
 Why are IoT Devices Targeted?
51

 Always on – IoT devices are rarely turned off

 Many manufacturers shy away from security in favor of
usability
 IoT devices aren’t checked on by users – “setup and
forget”
 There are millions of them – this allows for a significant
amount of DDoS traffic from these devices

Biplab Sikdar
 Why is Security an Issue?
52

 Security costs money

 Many IoT device manufacturers are willing to cut corners
on security to meet budget requirements for a project
 Many of these devices are constrained in terms of
memory, storage, and processing – making encryption-
heavy security approaches harder to implement
 These devices often control critical devices such as smoke
detectors and door locks

Biplab Sikdar
 IoT Security Challenges
53

 Devices are not reachable: Device may not be connected

most of the time
 Devices can be lost and stolen: Loss of stored secrets
 Devices are not crypto-engines: Strong security difficult
without processing power
 Devices have finite life: Credentials need to be tied to
lifetime
 Devices are transportable: Will cross borders
 Devices need to be recognized by many readers: What
data is released to what reader?

Biplab Sikdar
 Example: Trane
54

 Connected thermostat vulnerabilities detected by Cisco’s

Talos group allowed foothold into network
 12 months to publish fixes for 2 vulnerabilities
 21 months to publish fix for 1 vulnerability
 Device owners may not be aware of fixes, or have the
skill to install updates

Biplab Sikdar
 Example: Trane
55

 Lessons:
 All software can contain vulnerabilities
 Public not informed for months
 Vendors may delay or ignore issues
 Product lifecycles and end-of-support
 Patching IoT devices may not scale in large environments

Biplab Sikdar
 IoT Devices are Easy to Find
56

Biplab Sikdar
 IoT Attack Surface Areas
57

 Ecosystem access control

 Administrative interface
 Ecosystem communication
 Update mechanism
 Network traffic
 Cloud web interface
 Third-party backend APIs

Biplab Sikdar
 IoT Attack Surface Areas
58

 Device memory
 Device firmware
 Device physical interfaces
 Device network services
 Device web interface
 Local data storage
 Vendor backend APIs
 Mobile application

Biplab Sikdar
 Minimizing the Attack Surface
59

 “Trustworthy Products”
 Implement Trusted Device Policy
 Access control
 Mature behavioral based anomaly detection
 Decrease “Mean Time to Detect” and “Mean Time to
Contain”
 Instrument the network – Fireamp, NGIPS, Netflow
 Segment the network – control zones, security group
tags, data-aware

Biplab Sikdar
 Goal of Computer Security
60

 confidentiality: only sender, intended receiver should

“understand” message contents
 sender encrypts message
 receiver decrypts message
 authentication: sender, receiver want to confirm
identity of each other
 message integrity: ensure message not altered (in
transit, or afterwards) without detection
 access and availability: services must be accessible
and available to users
Biplab Sikdar
 A Secure System
61

 Is a computer that is connected to the Internet an

example of a secure machine?
 Can we protect Confidentiality, Authentication,
Integrity and Availability of data on such a
machine?
 Let’s look at these in turn.

Biplab Sikdar
 A Secure System
62

 Is a computer that is connected to the Internet an

example of a secure machine?
 Protecting Confidentiality: We routinely read of
malicious software and attacks that steal credit
card numbers, steal identity, steal passwords, etc.
 Protecting Integrity: Ransomware encrypts files

and prevents user from accessing them.

 Protecting Availability: DoS attacks prevent
access to websites.

Biplab Sikdar
 A Secure System
63

 Let us disconnect the computer from the Internet.

 Sacrifices some data availability but maybe we’re
willing to live with that.
 Does it protect data confidentiality?
 No! We can still exfiltrate data out of the machine
(USB sticks).
 Does it protect data integrity?
 No! We can still infect the machine with malicious
software (again, USB sticks).

Biplab Sikdar
 A Secure System
64

 Now, let us disconnect the computer from the Internet,

and switch it off.
 Is it “secure”?
 No! Data that is stored on hard disks can still be
recovered by bad guys using forensic tools.
 There are other kinds of sophisticated attacks:
 Example: Cold Boot Attack

Biplab Sikdar
 So What is a Secure System?
65

 Answer: “it depends”.

 If we assume a very powerful adversary, we will
need very powerful defenses to achieve even basic
confidentiality and integrity.
 Threat model: what we assume about the adversary
(i.e., attacker)

Biplab Sikdar
 Threat Models in Practice
66

 Network-based (or remote) attacker:

 Located remotely and connected to the victim’s machine via
a network link.
 Can send and receive packets to the victim’s machine.
 This is the threat model that is most used in practice.
 Local/inside attacker:
 Has an account to log into the victim’s machine.
 Perhaps even has physical access to the machine itself.
 Example: Snowden attacks

Biplab Sikdar
 Developing a Threat Model
67

 IoT environments are complicated

 Potentially significantly more so than what most are used
to
 Threat modeling is more valuable and more necessary
than ever
 Why develop a threat model?
 Avoid introducing vulnerabilities
 Identify vulnerabilities in an existing system
 Understand the system

Biplab Sikdar
 Developing a Threat Model
68

The Good Old Days

Biplab Sikdar
 Developing a Threat Model
69

Mobile: complications

Biplab Sikdar
 Developing a Threat Model
70

IoT: even more

complications

Biplab Sikdar
 High Level Overview
71

1 2 3 4
Decide on Build your Enumerate Decide on
scope dataflow threats mitigations
diagrams

Biplab Sikdar
 Creating a Data Flow Diagram
72

 Decompose the
system into a series of
processes and data
flows
 Explicitly identify trust
boundaries

Biplab Sikdar
 Example
73

Biplab Sikdar
 Identify Threats from Data Flow
74

STRIDE is expansion STRIDE

of the common CIA • Spoofing Identity
threat types • Tampering with
• Confidentiality Data
• Integrity • Repudiation
• Availability • Information
Disclosure
• Denial of Service
• Elevation of
Privilege

Biplab Sikdar
 Mapping Threats to Assets
75

Threat Type External Process Data Data

Interactor Flow Store
S – Spoofing Yes Yes
T – Tampering Yes Yes Yes
R – Repudiation Yes Yes Yes
I – Information Disclosure Yes Yes Yes
D – Denial of Service Yes Yes Yes
E – Elevation of Privilege Yes

Biplab Sikdar
 Countermeasures
76

 Do nothing
 Remove/turn off the feature
 Warn the user
 Counter the threat with Operations
 Accountability
 Separation of Duties
 Counter the threat with Technology
 Change in Design
 Change in Implementation
 There is no “catch all” countermeasure
Biplab Sikdar
 IoT System Security
87

Biplab Sikdar
 Solutions for IoT System Security
88

 Typical IoT devices need to communicate with cloud platforms.

 The content of the communication includes the following
aspects:
 IoT devices send real-time operation information to the
cloud platform
 Cloud platform sends instructions or data to the terminal
device
 Cloud platform sends data to the mobile app

 Mobile app sends instructions or data to the cloud platform

Biplab Sikdar
 Solutions for IoT System Security
89

 IoT ecosystem: many risks in devices, networks, and clouds.

 Device: firmware is tampered with; the firmware is
debugged; and the firmware is simulated.
 Network: data is monitored; data is tampered with.
 Cloud: malicious acquisition of user data.

Biplab Sikdar
 Solutions for IoT System Security
90

Image: Tang and Du Biplab Sikdar

 Device: Hardware
91

 Traditional physical hardware security: considers waterproof,

dustproof, electromagnetic interference, material strength, etc.
 Cyber-security: security of the debugging interface.
 Debugging interface: used to reduce the maintenance cost
of the device.
 Provides simple channel to the core software of the device.

 Current devices generally have a serial port or ADB

interface.
 Apple HomePod: uses independent debugging protocol
interfaces and integrated design.
 Requires strong destructive tools such as a hand saw to open
the box for in-depth analysis.

Biplab Sikdar
 Device: Hardware
92

Data interface for Apple HomePod

Biplab Sikdar
 Device: Hardware
93

 In addition to improving the production process:

 Use password verification when protecting the debugging
interface:
 Local fixed password verification.

 Cloud password verification.

 Cloud password verification:

 More secure.

 Successful attack requires the attacker to modify all the

communication verification procedures in the firmware
(which is costly).

Biplab Sikdar
 Device: Operating System
94

 Operating system and firmware belong to the software of the

terminal device.
 Operating system:
 Mature solutions like embedded Linux and Android systems,
with tailored and customized functions.
 Devices (e.g., Toshiba’s Flash Air) with independent
operating system.

Biplab Sikdar
 Device: Operating System
95

 Security of embedded Linux:

 Serial port verification mechanism is not friendly

 Program signature mechanism and the process sandbox do

not exist in the original system
 User permissions of general equipment are not
systematically divided.
 Therefore, requires complete customized program to
provide basic protection capabilities.
 The Android system’s sandbox, program signature
mechanism,

Biplab Sikdar
 Device: Operating System
96

 Security of Android:
 Greatly reduced attack surface due to Android’s sandbox,
program signature mechanism, user permissions, and
TrustZone.
 Android-based program reinforcement has become more
advanced with the development of mobile operating
systems in recent years.
 More device operating systems have migrated from
embedded Linux to Android.

Biplab Sikdar
 Device: Operating System
97

 Firmware of devices based on lightweight operating systems

 Generally does not distinguish between user mode and
kernel mode during development.
 Applications and operating systems use a unified memory
space: applications that need to run with ordinary
permissions are also used advanced permissions to run.
 This lightweight operating system is more insecure than
embedded Linux.
 Nevertheless, it has been used extensively in the past device
design.
 Establishing isolation between applications and kernel
programs and between applications and applications, can
improve the reliability and security of the lightweight
operating system.

Biplab Sikdar
 Device: Operating System
98

Isolation between applications and kernel programs

Image: Tang and Du Biplab Sikdar

 Device: Firmware
99

 Core security elements of the IoT device need to be deployed

in the firmware.
 Standard security system: each IoT device is preset with unique
identification and authentication credentials in the production
process (e.g., key, certificate, etc.)
 Firmware: verifies that the credentials have not been tampered
with or copied, and then uses the credentials to build security
capabilities for:
 Identity authentication and identification.

 Access control.

 Firmware update schemes.

 File encryption.

 Communication encryption.

Biplab Sikdar
 Internet
100

 IoT devices generally use mobile networks, Wi-Fi, Bluetooth,

ZigBee, etc. to connect to the cloud.
 Network protocols have security attributes: some protection
against tampering with data packets in the network.
 Attacks caused by packet sniffing: must ensure the security of
communication data at the network level.
 TLS or other encryption technologies: provide encryption
technologies and are usually based on certificates and keys.
 Security of encryption also depends on the lower-level IoT
security identification and authentication system.

Biplab Sikdar
 Cloud
101

 Both IoT devices and mobile apps interact with the cloud
platform through the network.
 Cloud platform can be used for data storage, data calculation,
and data display.
 According to the privacy data protection laws of various
countries (e.g., EU’s GDPR1), data needs to be encrypted and
data authorized by the user can be stored, and deleted when
the data retention period expires.
 In addition to the traditional information security construction,
there are two additional considerations for IoT:

Biplab Sikdar
 Cloud
102

 Security of external data interface:

 Self-use applications and third-party applications obtain
real-time device information through the data interface.
 The cloud platform needs to design a data access authority
system and data encryption protocol.
 Access of malicious devices:
 When a compromised device attempts to connect to the
cloud platform, the cloud platform should identify and add
the device to the blacklist.

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
103

 December 23, 2015

 Ukrainian news media TSN:
“At least three power regions
were attacked, leading to
hours of blackouts at around
15:00 local time. Attackers
invaded the monitoring and
management system. More
than half of the region and
part of the Ivan-Frankovsk
region suffered hours of
outages.”

Biplab Sikdar
 What is a CPS/ICS
104

 Cyber-Physical System (CPS)

 NSF: “physical and software components are deeply
intertwined, each operating on different spatial and
temporal scales, exhibiting multiple and distinct behavioral
modalities, and interacting with each other in a myriad of
ways that change with context”
 Industrial Control Systems (ICS)
 Wikipedia: “general term that encompasses several types
of control systems and associated instrumentation used for
industrial process control”

Biplab Sikdar
 Industrial Control System Overview
105

Process Control SCADA Automation

Systems (PCS) Biplab Sikdar
 A Simple Control System
106

Sensor(s) +
Actuator(s) +
Controller(s)

Biplab Sikdar
 Legacy ICS
107

 Proprietary
 Complete vertical solutions
 Customized
 Specialized communications
 Wired, fiber, microwave, dialup, serial, etc.
 100s of different protocols
 Slow; e.g. 1200 baud
 Long service lifetimes: 15–20 years
 Not designed with security in mind

Biplab Sikdar
 Internet
Modern ICS
108
Enterprise
Enterprise Network Enterprise
Network
Workplaces Optimization

Firewall
IP Suite
Third Party
Application Mobile
Server Operator

Services
Network
Connectivity Historian Application Engineering
Server Server Server Workplace

Control
Network

Serial, OPC
Redundant
or Fieldbus

Device Network

Third Party
Controllers,
Servers, etc.

Serial RS485

Biplab Sikdar
 Power Grid: Comm and Control
109

borrowed from NIST Smart Grid Twiki

Internet Control Systems Biplab Sikdar
 Technology Trends
110

 COTS (Commercial-Off-The-Shelf) technologies

 Operating systems—Windows, WinCE, embedded RTOSes
 Applications—Databases, web servers, web browsers, etc.
 IT protocols—HTTP, SMTP, FTP, DCOM, XML, SNMP, etc.
 Networking equipment—switches, routers, firewalls, etc.
 Connectivity of ICS to enterprise LAN
 Improved business visibility, business process efficiency
 Remote access to control center and field devices
 IP Networking
 Common in higher level networks, gaining in lower levels
 Many legacy protocols wrapped in TCP or UDP
 Most new industrial devices have Ethernet ports
 Most new ICS architectures are IP-based Biplab Sikdar
 IP-Based ICS
111

 ODVA (Rockwell)  Honeywell Experion

 Profinet  Emerson DeltaV
 Foundation Fieldbus HSE  Yokogawa VNET/IP
 Telvent  Invensys Infusion
 ABB 800xA  Survalent

 IP to the Control Network or even Device Network

 Not all are fully compatible with “ordinary IP”

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
112

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
113

 Kyivoblenergo power company: “The company was

compromised, resulting in failures of 7 substations of 110KV
and 23 substations of 35KV, and 80,000 users powering
down.”
 Infecting malware: BlackEnergy.
 BlackEnergy was used as a backdoor, and released KillDisk to destruct
data and slow system recovery.
 A SSH program with a backdoor also found in other servers
 Attackers could connect to the infected hosts at any time based on the
built-in password
 BlackEnergy was also used by the hacker team “Sandworm” to attack
European and American SCADA industrial control systems in 2014

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
114

 Prior compromise of corporate networks using spear-phishing

emails with BlackEnergy malware;
 Seizing SCADA under control, remotely switching substations
off
 Disabling/destroying IT infrastructure components
(uninterruptible power supplies, modems, RTUs, commutators);
 Destruction of files stored on servers and workstations with
the KillDisk malware;
 Denial-of-service attack on call-center to deny consumers up-
to-date information on the blackout.

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
115

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
116

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
117

 Stage 1:
 Reconnaissance:

 The three impacted organizations had high levels of

automation in their distribution system
 Remote opening of breakers in a number of substations.

 Targeting and final attack plans were highly

coordinated
 Weaponization and/or Targeting:

 Weaponized Excel and Word documents by embedding

BlackEnergy 3 within the documents.

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
118

Biplab Sikdar
 Attack Step: 1
119

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
120

 Delivery, Exploit, and Install:

 Malicious Office documents sent via email to individuals in

administrative or IT network of the electricity companies

 Command and control (C2):
 After installation, BlackEnergy 3 connected to C2 IP

addresses
 Actions: harvest credentials, escalate privileges, move
laterally, identify VPN connections and avenues from the
business network into the ICS network.
 Act:
 Using stolen credentials, adversary entered network

segments with SCADA dispatch workstations and servers

Biplab Sikdar
 Attack Step: 2
121

Biplab Sikdar
 Attack Step: 3
122

Biplab Sikdar
 Attack Step: 4
123

Biplab Sikdar
 Attack Step: 5
124

Biplab Sikdar
 Attack Step: 6
125

Biplab Sikdar
 Ukraine Power Grid Attack: 2015
126

 Stage 2:
 Primary attack: SCADA hijack with malicious operation to

open breakers
 Supporting attacks:

 Schedule disconnects for UPS systems

 Telephonic floods against at least one operator’s

customer support line

 Amplifying attacks:

 KillDisk wiping of workstations, servers, and an HMI card

inside of an RTU
 Firmware attacks against Serial-to-Ethernet devices at

substations
Biplab Sikdar
 Attack Step: 6
127

Biplab Sikdar
 Known Attacks
128

Night Dragon: Shell, ExxonMobil

Stuxnet: Iran

Lansing BWL
Ransomware Saudi Aramco Cyberattack
Biplab Sikdar
 Possible Attacks
129

H. Nguyen et al. "Impact of Signal Delay Attack on Voltage Control for Electrified Railways". IEEE TENCON,
Macau, China, November 2015.

Biplab Sikdar
 Possible Attacks
130

D. Niyato, et al. "Impact of packet loss on power demand estimation and power supply cost in smart grid." IEEE
Wireless Communications and Networking Conference (WCNC), 2011.

Biplab Sikdar
 ICS Security Risks
131

 COTS + IP + connectivity = many security risks

 Security risks of Enterprise networks and more
Worms and Viruses Legacy OSes and applications
DOS and DDOS Inability to limit access
Unauthorized access Inability to revoke access
Unknown access Unexamined system logs
Unpatched systems Accidental misconfiguration
Little or no use of anti-virus Improperly secured devices
Limited use of host-based firewalls Improperly secured wireless
Improper use of ICS workstations Unencrypted links to remote sites
Unauthorized applications Passwords sent in clear text
Unnecessary applications Default passwords
Open FTP, Telnet, SNMP, HTML ports Password management problems
Fragile control devices Default OS security configurations
Network scans by IT staff Unpatched routers / switches

Biplab Sikdar
 Implications of ICS Security Risks
132

 Loss of production
 Penalties and lawsuits
 Loss of: trust, market value
 Physical damage
 Environmental damage
 Injury, loss of life

Biplab Sikdar
 Securing a CPS/ICS
133

 No single solution
 Defense-in-Depth
 Perimeter protection
 Firewall, IPS, VPN, AV, Host IDS, Host AV, DMZ

 Interior Security
 Firewall, IDS, VPN, AV, Host IDS, Host AV, IEEE P1711

(AGA 12), NAC, Scanning

 Monitoring
 Management

Biplab Sikdar
 Defense in Depth
134

Internet
IT Stuff
Enterprise Network IT Stuff

VPN FW
Proxy AV IPS
Scan Host IPS Host AV Log Mgmt IPS
IDS Event Mgmt FW
Control Network Partner
NAC Reporting 62351 Site
Host IDS Host AV VPN
FW
VPN P1711
IDS FW
AV Field Site
Scan Field Site NAC Field Site
Biplab Sikdar
 Security issues in CPS/ICS
135

 Enterprise networks require C-I-A

 Confidentiality of data/IP most important
 ICS requires A-I-C
 Availability and integrity of control matters most
 control data has low entropy - little need for confidentiality
 Many ICS vendors provide six 9’s of availability
 Ensuring availability is hard
 Cryptography does not help (directly)
 DOS protection, rate limiting, resource management, QoS,
redundancy, robust hardware with high MTBF
 Security must not reduce availability!
Biplab Sikdar
 Attacks on Availability
136

 Denial of Service (DoS) attack overwhelms a system

with too many packets/requests
 Exhausts TCP stack or application resources
 Defense: connection limits in firewall
 Distributed Denial of Service (DDoS) attack
coordinates a botnet to overwhelm a target system
 No single point of attack
 Requires sophisticated, coordinated defenses
 DoS and DDoS attacks are particularly effective
when availability is critical
Biplab Sikdar
 ICS Devices are Fragile
137

 Many IP stack implementations are fragile

 Some devices lockup on ping sweep or NMAP scan
 Numerous incidents of ICS shut down by uninformed IT staff
running a well-intentioned vulnerability scan
 Modern ICS devices are much more complex
 Some IEDs include web server for configuration and status
 More lines of code leads to more bugs
 Modern IEDs require patching just like servers

Biplab Sikdar
 Devices with Unpatched Software
138

 Many ICS systems are not patched current

 Particularly Windows servers
 OS and application patches can break ICS
 OS patches are tested for enterprise apps
 Uncertified patches can invalidate warranty
 Patching often requires system reboot
 Before installation of a patch:
 Vendor certification - typically one week
 Lab testing by operator
 Staged deployment on less critical systems first
 Avoid interrupting any critical process phases Biplab Sikdar
 Legacy Equipment
139

 Legacy equipment are common in CPS/ICS

 Usually impossible to update to add security
features
 Difficult to protect legacy communications
 Options: IEEE P1711 for serial encryption
 Password protection is weak
 Little or no audit and logging

Biplab Sikdar
 Host Anti-virus
140

 AV operations can cause significant system disruption

at inopportune times
 3am is no better than any other time for a full disk scan on
a system that operates 24x7x365
 ICS vendors only beginning to support anti-virus
 Anti-virus is only as good as the signature set
 Signatures may require testing just like patches
 virus writers have learned to test against dominant AV
 Application whitelisting can be a good alternative

Biplab Sikdar
 Authentication
141

 Machine-to-machine communication involve no “user”

 Many ICS have poor authentication mechanisms
 Many protocols use cleartext passwords
 Many ICS devices lack crypto support
 Sometimes passwords left at vendor default
 Device passwords are hard to manage
 Often one password is shared amongst all devices
and all users and seldom if ever changed
 This is happening AGAIN in Smart Meter deployments

Biplab Sikdar
 Auditing and Logging
142

 Many ICS have poor or non-existent support for

logging security-related actions
 Attempted or successful intrusions may go unnoticed
 IDS logs may be kept but not reviewed
 Various regulatory requirements are driving some
change in this area
 NERC: North American Electric Reliability Corporation
 FERC: Federal Energy Regulatory Commission
 Sarbanes Oxley and PCAOB (Public Company Accounting
Oversight Board)
 FISMA: Federal Information Security Management Act
Biplab Sikdar
 Unauthorized Applications
143

 Unauthorized apps installed on ICS systems can

interfere with ICS operation
 Many types of unauthorized apps have been found
during security audits
 Instant messaging
 P2P file sharing
 DVD and MPEG video players
 Games, including Internet-based
 Web browsers

Biplab Sikdar
 Inappropriate Use of ICS Desktops
144

 Web browsing from HMI can infect ICS

 Browser vulnerabilities
 Downloads
 Cross-site scripting
 Spyware
 Email to/from control servers can infect ICS
 Sendmail and Outlook vulnerabilities
 Disk storage exhaustion can crash OS
 Storage of music, videos

Biplab Sikdar
 Inadequate Internal Monitoring
145

 Internal monitoring is essential to detect low profile

compromises
 IDS
 port scanning
 vulnerability scanning
 system audit

Biplab Sikdar
 Unmanned Field Sites
146

 Many unmanned field sites

 Many with dialup access
 Some with high-speed connectivity to control center
 Most with poor authentication and authorization

backdoor to the
control center

Biplab Sikdar
 3rd Party Access
147

 Firmware updates and PLC, IED programming are

sometimes done by vendor
 Many ICS have open maintenance ports
 Infected vendor laptops can bring down ICS
 Partners may require continuous status information
 Partner access is often poorly secured
 Partner channels can serve as backdoors
 3rd parties may include:
 Transmission provider or grid neighbor, equipment vendor,
emissions monitoring service or agency, water level
monitoring agency, vibration monitoring service, etc.
Biplab Sikdar
 Human Factors
148

 ICS network often managed by “Control Systems

Department”, distinct from “IT Department” running
enterprise network
 ICS personnel are not IT or networking experts
 IT personnel are not ICS experts
 Majority of control systems workforce is older and
nearing retirement
 Few young people entering this field
 Few academic programs

Biplab Sikdar
 Other Issues
149

 Unusual physical topologies

 Many special purpose, limited function devices
 Static network configurations
 Multicast
 Long service lifetimes

Biplab Sikdar
 Adversaries
150

 Script kiddies
 Hackers
 Organized crime
 Disgruntled insiders
 Competitors
 Terrorists
 Hactivists
 Eco-terrorists
 Nation states
Biplab Sikdar
 Threat Model
151

 Targeted and untargeted threats

 Targeted: terrorist, specifically crafted worm/virus, botnet
 Untargeted: generic worm/virus, script kiddy
 Assume adversary has:
 Complete knowledge of network
 Beachhead in enterprise network
 Limited access to control network
 But no valid credentials

Biplab Sikdar
 Defending a CPS/ICS
152

 Separate control network from enterprise network

 Harden connection to enterprise network
 Protect all points of entry with strong authentication
 Make reconnaissance difficult from outside
 Harden interior of control network
 Make reconnaissance difficult from inside
 Avoid single points of vulnerability
 Harden field sites and partner connections
 Monitor both perimeter and inside events

Biplab Sikdar
 Defense in Depth
153

Internet
IT Stuff
Enterprise Network IT Stuff

VPN FW
Proxy AV IPS
Scan Host IPS Host AV Log Mgmt IPS
IDS Event Mgmt FW
Control Network Partner
NAC Reporting 62351 Site
Host IDS Host AV VPN
FW
VPN P1711
IDS FW
AV Field Site
Scan Field Site NAC Field Site
Biplab Sikdar
 SP99/Purdue Model of Control
154 Level 5 Enterprise Network
Enterprise
Email, Intranet, etc. Site Business Planning and Logistics Network
Zone
Level 4

Terminal Patch AV
Services Mgmt Server

DMZ
Historian Web Services Application
(Mirror) Operations Server

Production Optimizing Engineering Site Operations

Level 3 Control Control
Historian
Station and Control

Supervisory HMI Supervisory HMI Area

Level 2 Control Control Supervisory
Control Control
Zone

Level 1 Batch
Control
Discrete
Control
Continuous
Control
Hybrid
Control
Basic
Control

Level 0 Process

Biplab Sikdar
 Logical Architecture
155

 Enterprise Zone contains typical business systems

 Email, web, office apps, etc.
 DMZ provides business connectivity
 Contains only non-critical systems that need access to both
Control and Enterprise Zones
 Enforces separation between Enterprise and Control Zones
 Consists of multiple functional sub-zones
 Separated by Firewall, IPS, Anti-Virus, etc.
 Control Zone demarcates critical control systems
 Consists of multiple functional sub-zones
 Internally protected by Firewall, IDS, Anti-Virus, etc.
Biplab Sikdar
 DMZ Design Principles
156

 DMZ contains non-critical systems

 DMZ is only path in/out of Control Zone
 Default deny for all firewall interfaces
 No control traffic to outside
 Limited outbound traffic from Control Zone
 Very limited inbound traffic to Control Zone
 No common ports between outside & inside
 Emergency disconnect at inside or outside
 No network management from outside
 Cryptographic VPN and Firewall to all 3rd party connections

Biplab Sikdar
 DMZ Implementation
157

 Sub-zones implemented by physical LANs or VLANs

 Physical LANs require multi-port Security Appliance
 VLANs require:
 VLAN-capable Security Appliance and Switch

 anti-VLAN hopping protections on switch and FW

 FW implements policy between

 DMZ LANs, Enterprise Zone, Control Zone
 Anti-virus proxy controls outbound connections to
enterprise or Internet resources
 Host IPS and/or Host Anti-virus protects DMZ servers
Biplab Sikdar
 DMZ Implementation Enterprise
LAN
158

NAT Security
Appliance
DMZ LAN 2 With
Multiple
DMZ LAN 3 Ports
Routing
DMZ LAN 4 FW
IPS

Anti-Virus
Proxy

Host IPS / Anti-virus

DMZ/Control
Interconnect
WAN/LAN

Biplab Sikdar
 Control Zone: Logical View
160

DMZ

Production Optimizing Engineering Site Operations

Level 3 Control Control
Historian
Station and Control

Supervisory HMI Area

Level 2 Control Supervisory HMI Supervisory
Control Control
Control
Zone

Level 1 Batch
Control
Discrete
Control
Continuous
Control
Hybrid
Control
Basic
Control

Level 0 Process

Biplab Sikdar
 Control Zone: Design Principles
161

 Multiple functional security sub-zones with firewall and IDS

between sub-zones
 Minimal number of connections to DMZ
 Control Zone independent of DMZ, Enterprise
 Separate Security Appliance from DMZ
 Separate Time Server
 Separate AAA
 Allows emergency disconnect from DMZ
 Cryptographic VPN and Firewall to all offsite IP connections
 IEEE P1711 for all offsite serial ICS connections
 Management only from management zone
Biplab Sikdar
 Control Zone: Hierarchical
162

DMZ/Control Interconnect WAN/LAN

FW FW
Level 3
L3
L3
IDS
SPAN Gigabit
Scan Control
L2 L2 Zone
Level 2 dot1q Trunks
QoS, Shaping, Policing
Port Security

10/100
Level 1

Host IDS Host AV

Biplab Sikdar
 Control Zone: Ring
163

DMZ/Control Interconnect WAN/LAN

FW FW
Level 3
L3
L3
IDS
SPAN Gigabit
Scan Control
L2 dot1q Trunks L2 Zone
Level 2
QoS, Shaping, Policing
Port Security

10/100
Level 1

Host IDS Host AV

Biplab Sikdar
 Power Grid: Perimeter Protection
164

Firewall
Site-to-site VPN
IDS/IPS
Client VPN

DMZ

Proxy
Network AV
Host IDS/IPS
NAC

Biplab Sikdar
 Power Grid: Interior Protection
165

IDS
Port Scan
Vuln Scan

Firewall
NAC

Firewall
SCADA VPN SCADA VPN
Port Scan
IDS

Biplab Sikdar
 Power Grid: Monitoring, Logging
166

Log Managed
Analyze Security
Report
Compliance

Biplab Sikdar
 ICS/CPS Standards Efforts
167

 NERC CIPs
 NIST Smart Grid Interoperability Standards Project
 NIST SP800-82
 NIST SP800-53
 NIST PCSRF Protection Profiles
 AMI-SEC
 ISA SP99
 ODVA
 IEEE P1711 (AGA 12) -- serial SCADA encryption
Biplab Sikdar
 Slide Credits
171

 SCADA Security: Andrew Wright

 IoT Security: Dan Cornell
 And many others

Biplab Sikdar