The Promise of IoT

We are just beginning to reap the benefits of the Internet of Things (IoT). More devices are connecting to our networks every day. Take a moment to evaluate how many
connected devices you currently use. Do you have a smart phone and a laptop? Do you also have a tablet? Do you wear a device to track your fitness? Do you own one or
more gaming consoles? Does your home have a connected system for remotely controlling your thermostat? Is your refrigerator c onnected?

Before we explore the security challenges to the IoT, take a moment to investigate the promise of the IoT.

Click Play in the figure to see examples of what we can accomplish with the IoT.

Click here to read a transcript of this video.

Anatomy of an IoT Attack

The IoT has expanded the opportunities for threat actors to act against our networks. IoT devices are increasingly
being compromised. They are used in a wide variety of attacks because they often lack critical device protections
such as strong passwords, up-to-date operating systems, and segmented networks.

Click Play in the figure to watch a dramatization of some of the weaknesses inherent in many of today’s IoT
devices.

Click here to read a transcript of this video.

Go to the next page to interact with this video and learn more details about the attack.

Video Demonstration - Mirai Botnet

Mirai is malware that targets IoT devices configured with default login information. Closed-circuit television (CCTV) cameras make up the majority of Mirai’s targets. Using
a brute force dictionary attack, Mirai runs through a list of default username/passwords:

 root/default

 root/1111

 root/54321

 admin/admin1234

 admin1/password

 guest/12345

 tech/tech
  support/support

After successful access, Mirai targets the Linux-based BusyBox utilities designed for these devices. These utilities were used to turn the devices into bots that can be
remotely controlled as part of a botnet. The botnet can then be used as part of a distributed denial of service (DDoS) attack. A Mirai botnet of over 152,000 CCTVs, and
digital video recorders (DVRs) was responsible for the largest DDoS attack in September 2016. With peak traffic of over 1 Tb/s, it took down the hosting services of a
France-based web hosting company.

In October 2016 the services of Dyn, a domain name service (DNS) provider, were attacked, causing internet outages for millio ns of users in the United States and
Europe.

Click Play in the figure to view a demonstration of how a DDoS attack makes services unavailable.

Click here to read the transcript of this video.

Note: In December 2017, three American threat actors pleaded guilty to conspiring to “conduct DDoS attacks against websites and web hosting companies located in the
United States and abroad.” The three felons face up to 10 years in prison and $250,000 in fines.

Lab - Shodan Search

In this lab, you will use the Shodan search engine to gain an understanding of why security should be a focus of any IoT impl ementation.

Shodan has servers located around the world that continually crawl the internet looking for connected devices. It c an find specific devices and device types. Some of the
more popular searches include webcams, default passwords, routers, video games, and more.

Shodan is a favorite tool used by researchers, security professionals, large enterprises, and computer emergenc y response teams (CERTs).

 Researchers can use Shodan to data mine information about what devices are connected, where they are connected, and what services are exposed.

 Security professionals can use Shodan as part of a penetration testing plan to discover devices that need to be hardened to prevent potential attacks.

 Large enterprises employ security professionals who use tools like Shodan for determining the current risk profile of the enterprise’s connected devices.

 CERTs can use Shodan to quickly generate reports about an emerging attack on connected devices.

Shodan is also a tool used by nefarious individuals and groups commonly referred to as threat actors. Shodan can accelerate a threat actor’s reconnaissance of internet-
connected devices. Like all the tools in this course, you must use it responsibly according to your organization’s ethical hacking policies.

Lab - Shodan Search 1.1.1.6

Lab - Evaluate Recent IoT Attacks

In this lab, you will research recent IoT attacks and describe mitigation techniques.

As the number of connected IoT devices continues to grow at an exponential rate, so are the number of attacks on these devices. There are a wide variety of attacks on
IoT devices that have been documented and reported in the news.

As an IT professional working with IoT devices, it is important to be aware of the wide range of attacks and vulnerabilities that have occurred on these devices. It is also
important to know how to defend against and mitigate the damage from these types of attacks.

Lab - Evaluate Recent IoT Attacks 1.1.1.7

IT and OT in the Manufacturing Sector

Organizations often have two distinct networking domains that can be summarized as information technology (IT) and operationa l technology (OT).

 IT – This includes devices in the data center, in the cloud, bring your own device (BYOD), and thousands of sensors and actuators connected in the field.

 OT – This includes industrial control systems (ICSs), supervisory control and data acquisition (SCADA) systems, and all the devices that connect to these
systems.
Historically, the IT and OT departments within a manufacturing company could mostly function independently. OT kept the plant running smoothly and IT managed
business applications from the front office. The two teams occasionally collaborated on successful projects, such as implementing printers on the factory floor or s ervicing
industrial computers. Unfortunately, those opportunities were rare and often contentious.

The world of manufacturing is changing. By converging IT and OT, operations managers use IT tools to sift through the reams of operational data and make real -time
decisions. IT teams can also use this data to do innovative things such as improving the supply chain and reducing downtime.

This convergence presents important security challenges. There has long been the need in IT to protect critical business data from theft, alteration, or damage. Robust
Software, systems, and processes have evolved to address threats to information assets. However, since OT has historically operated in networks that are isolated from
the internet or even IT networks, many unsupported legacy systems, operating systems, and applications are not secure. Furthe r, OT network architectures have not been
designed to isolate control and data applications from threat actors. With the coming convergence of IT and OT and the potential exposu re of OT networks to the internet,
OT security has become a significant concern.

Click Play in the figure to see how IT and OT are converging.

Click here to read a transcript of this video. 1.1.2.2

Consumer Technology

In addition to IT and OT, we have consumer technology (CT) which includes connected devices in the home, wearable technology, smart cars, and more. But it is not just
new device types that are connecting to the internet. Many of us are increasing the number of devices we use to communicate.

New device types and the increasing number of devices per person all add up to a significant portion of connected devices in the age of IoT. In 2016, internet traffic from
CT devices was 61% of all IP traffic. Of all the CT traffic, 81% of it was video traffic.

Search for Cisco’s Visual Networking Index tool to explore more statistics.

IoT Security Model

Whether the IoT device belongs to IT, OT, CT, or some combination of the three, strong security is required. Service providers are those organizations that connect our
devices to the internet. As such, they are in a unique position to offer services to address the IoT security needs of their clients.

In the figure, drag the elements into position to create the conceptual model for IoT security.

NICE Cybersecurity Workforce Framework

The National Institute for Standards and Technology (NIST) published the National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framew ork in
November 2017. The publication is an excellent reference for learning how to identify, recruit, develop, and retain cybersec urity talent. The publication clearly defines work
roles that include the necessary knowledge, skills, and abilities (KSAs) required as well as the tasks performed by someone i n the work role.

The work roles are divided into seven categories, as shown in the figure. Skills and knowledge gained in this course apply to both the Securely Provision and the Protect
and Defend categories

Securely Provision

Work roles in the Securely Provision category are responsible for conceptualizing, designing, procuring, and implementing secure information technology (IT) systems. In
the Securely Provision work category, the Risk Management specialty area is the focus for this course. This includes all the processes necessary to assure that existing
and new IT systems meet the organization's cybersecurity and risk requirements. Additionally, it includes the appropriate treatment of risk, compliance, and assurance
from internal and external perspectives.

The work role is Security Control Assessor. People in this role conduct comprehensive assessments of management, operational, and technical security controls to
determine their overall effectiveness. This is particularly important in the area of IoT systems, because these systems are relatively new in the IT landscape.
Protect and Defend

Work roles in the Protect and Defend category are identifying, analyzing, and mitigating threats to IT systems. In the Protect and Defend work category, the etsi

and Management specialty area is the focus for this course. This includes the following:

 conducting assessments of threats and vulnerabilities;

 determining deviations from acceptable configurations or policies;

 assessing the level of risk;

 and developing or recommending appropriate mitigation countermeasures.

The work role is Vulnerability Assessment Analyst. People in this role perform assessments of IT systems and identify where those systems deviate from acceptable
configurations or policy. They are also responsible for measuring the effectiveness of the security architecture against known vulnerabilities.

Throughout the rest of the course, our focus will be on assessing the risk in IoT systems and performing vulnerability assessments. There are many other work roles
specified in the NICE framework. Click here for a navigable database of the Categories, Specialty Areas, and Work Roles in the NICE Cybersecurity Workforce
Framework.

Click here to download the full NIST.SP.800-181 publication that specifies the NICE Cybersecurity Workforce Framework.

Packet Tracer - Explore the Smart Home

The smart home is another example of how the IoT is transforming the way we live, work, and play. Smart home devices include lights, thermostats, security systems,
smoke and fire detection, appliances, TVs, doors, windows, and anything that can be remotely monitored and controlled.

In another course, you explored a smart home scenario in Packet Tracer. Revisit that scenario to discover unique security req uirements for the IoT devices in the home.
While completing the instructions, record a list of security issues that you discover along the way. Compare your list with other students in your class or search the internet
for smart home security issues.

Later in this course, you will have the opportunity to evaluate the security of the Smart Home system by creating a detailed threat model of it.

Packet Tracer - Explore the Smart Home Instructions

Packet Tracer - Explore the Smart Home PKA 1.2.1.1

Lab - Evaluate Home Automation Products

In this lab, you will investigate the wide variety of home automation products that are available. Some products may require monitoring or maintena nce services, so your
geographical location might have an impact on your choices.

Assume you have a budget of $1000 USD (or equivalent local currency) and the choice of one primary objective for home automation from the following:

 Increase convenience

 Enhance security

 Save energy

You will choose an objective and conduct online research to find home automation products to satisfy your objective. You will then select the desired products keeping the
total cost under $1,000 and prepare a presentation about what you bought, how it achieves your goal, and how the system will be used by the customer.

Lab - Evaluate Home Automation Products 1.2.1.3

Introduction to IoT in Healthcare

In this topic, you will explore the role of the IoT in the healthcare industry. This use case will provide you with an example of how you might evaluate a different industry.
This discussion will provide an explanation of IoT healthcare use cases, vulnerabilities, risks, and mitigation.

Click Play in the figure to see how Cisco provides comprehensive solutions for implementing the IoT in healthcare.

Click here to read a transcript of this video. 1.2.2.1

Personal Fitness Devices

Any discussion of healthcare and the IoT must start with wearable personal fitness devices. These fitness devices are among t he most popular commercial IoT products.
Some of these devices communicate with a cloud application. They use a Bluetooth connection to a phone and a cellular data or Wi -Fi connection to the internet and
cloud, as shown in the figure.

They come in many forms, such as a wrist watch, headband, helmet, or head phones. They usually consist of a sensor that can detect your heart rate and an
accelerometer that detects motion in the form of steps. Some include more advanced features, such as location services using a GPS sensor, sleep monitoring, and
enhanced application features. A cloud application enables storage of personal fitness data, an analysis dashboard, and a wide range of c onfiguration settings.

IoT Healthcare Monitoring

One function of IoT devices is healthcare monitoring, which involves the collection and evaluation of patient data over a period of time. The IoT has enabled real-time
remote patient monitoring (RPM). Patients who do not require direct observation by healthcare professionals in a clinical setting can be monitored at home. Monitoring
devices can be worn by the patient and connected to the internet. The gateway combines signals from the sensors and submits t he monitoring data securely over the
internet to cloud applications. If the data reveals concerns about a patient's health, applications can promptly notify healthcare personnel , enable communication with the
patient, and even call for emergency medical assistance.

An RPM system is shown in the figure. A patient is wearing a number of different sensors that form a body sensor network (BSN) that collects information such as heart
rate, body temperature, and blood-oxygen levels. A gateway device, which can also be worn, connects the BSN to the monitoring platform across the internet.

IoT in the Hospital

In a clinical setting, as many as 20 medical devices can be found in a single hospital room. The IoT provides various functio nalities to connected medical devices. Aside
from monitoring and submitting patient data, IoT sensors can be used to track the location of these devices. It is estimated that health care personnel can spend up to 25%
of their time searching for medical devices that are required for patient care. Asset tracking through the use of the netwo rk can greatly enhance operational efficiency. IoT
sensors also monitor device operation in order to detect problems and help prevent device failure.

For example, therapeutic devices use actuators that are controlled by software to regulate the administration of drugs, fluids, and oxygen. Such devices can be monitored
and controlled from a central location rather than by personnel who must go to the device. The use of the IoT in health care adds great efficiency to operations, but also
adds challenges for IT departments and data security professionals.
Hacking a Pacemaker

Security researcher Scott Erven, working at Essentia Health, conducted a two-year survey of medical device security. His team uncovered security vulnerabilities in
connected medical devices such as drug infusion and insulin pumps, Bluetooth-enabled defibrillators, refrigeration units that are used to store drugs and blood, and many
other devices.

In August of 2017, the United States government Food and Drug Administration (FDA) approved a software update that will patch a security flaw in radio frequency-
enabled implantable cardiac pacemakers. The pacemakers are surgically implanted in a patient's chest in order to help control the beating of the patient's heart. The
devices include an embedded microprocessor and firmware that is vulnerable to remote attacks over radio frequency (RF). An attack on the pacemaker could result in the
death of the patient. Fortunately, the firmware update could be made over RF without requiring removal or repl acement of the device. It is estimated that 465,000 devices
were affected.

Vulnerabilities

Adding thousands of poorly secured nodes to healthcare networks is like adding thousands of flimsy or unlocked doorways that threat actors can exploit. Potential
vulnerabilities range from weak or nonexistent authentication, unsecured embedded server processes, and unnecessarily vulnerabl e applications that could be
compromised due to user error. In fact, it has been found that healthcare personnel may use web clients running on medical devices and systems to surf the web and read
email, making these critically important devices vulnerable to the same attacks as any computer. Because many medical devices have a long period of use, the computers
used to operate them are often running old and unpatched operating systems. Medical devices are poorly regulated and frequently not designed according to hardware
and software security standards.

Risks

Vulnerabilities in connected healthcare devices result in many risks. Vital therapies can be manipulated, interrupted, or disabled, resulting in patient injury or death.

Less critical, but very important, are the risks that poor device security can pose to patient data. Poor device security can allow a threat actor to access data that is stored
on a connected healthcare device, or the device can provide access to data stored on the network. Personally-identifiable information (PII) about patients can be stolen or
manipulated. Government regulations regarding the handling of PII can result in severe penalties to healthcare organizations if a data breach occurs.

Mitigation

The best way to mitigate risk in healthcare IoT is to not put vulnerable devices on the network at all. Device manufacturers must design and build their devices with security
in mind throughout the development lifecycle. Healthcare administrators must ensure the devices they purchase are secure and that device security has been adequately
configured.

IT personnel must provide a reliable means for updating and patching network-attached devices. Network architectures should isolate data and control networks from
maintenance, vendor, and asset location functionalities. Finally, all healthcare personnel must undergo training to build sec urity awareness and create institutional values
that embrace security in all aspects of healthcare network operation.

Lab - Evaluate the IoT Security Risk in an Industry Sector

Any implementation of the IoT is going to have risk associated with it. Risks could range from fairly insignificant to very destructive depending on the market, equipment,
number of people affected, and numerous other factors.

In this lab, you will research an industry sector and evaluate the risks associated with implementing an IoT solution.

Lab - Evaluate the IoT Security Risk in an Industry Sector 1.2.2.9

Lab - Set Up PL-App on a Raspberry Pi

Some of the labs for this course use a Raspberry Pi that is connected to a computer. The computer is used to work with Python and Jupyter notebooks that are running on
the Raspberry Pi. In addition, for some labs, the computer will run a virtual machine (VM) that interacts with the Pi.

In this lab, you will set up the PL-App on your computer and then connect to the Raspberry Pi over the network.

PL-App Image for IoT Security

PL-App Launcher for Windows

PL-App Launcher for Mac

Latest version of Student Jupyter Notebooks

Lab - Set Up PL-App on a Raspberry Pi 1.2.3.1

Lab - Set Up the IoT Security Lab Topology

Computing power and resources have increased tremendously over the last 10 years. A benefit of having multicore processors and large am ounts of RAM is the ability to
use virtualization. With virtualization, one or more virtual computers operate inside one physical computer. Virtual computers that run within physical computers are called
virtual machines (VMs). VMs are often called guests, and physical computers are often called hosts. Anyone with a modern comp uter and operating system can run VMs.

In this lab, you will install the IoT Security Kali and Metasploitable VMs in the lab topology.

Lab - Set Up the IoT Security Lab Topology 1.2.3.2

Lab - Harden a Raspberry Pi

The Raspberry Pi is a doorway to the Internet of Things (IoT). In this lab you will take a Raspberry Pi that is acting as an IoT gateway device and interconnecting critical
systems and sensors and perform device hardening. You will harden a Raspberry Pi by following recommended security practices for the Raspbian OS. You will also limit
the network protocols and services allowed to connect to the IoT gateway by activating and configuring the Uncomplicated Firewall (UFW). Finally, you will utilize an
separate Kali VM with the Kali Linux OS, acting as a threat actor, to test the security of the IoT gateway.

Lab - Harden a Raspberry Pi 1.2.3.3

Lab - Investigate Vulnerability Assessment Tools

Kali Linux is a Debian-based Linux distribution aimed at advanced Penetration Testing and Security Auditing. Kali contains several hundred tools which are geared
towards various information security tasks. Kali tools are organized into different categories. In this lab, you will explore some of the tools available in Kali Linux.

Lab - Investigate Vulnerability Assessment Tools 1.2.3.4

Chapter 1: The IoT Under Attack

This chapter began by discussing unsecured IoT devices. More devices are connecting to our networks every day. IoT devices are increasingly being compromised and
used in a wide variety of attacks because they often lack critical device protections such as strong passwords, up-to-date operating systems, and segmented networks.

Next, the chapter detailed the unique IoT risk. By converging IT and OT, operations managers use IT tools to sift through the reams of operational data and make real-time
decisions. IT teams can also use this data to do innovative things such as improving the supply chain and reducing downtime. New device types and the increasing
number of devices per person all add up to a significant portion of connected devices in the age of IoT.

The next section discussed NICE and IoT systems. NIST’s NICE publication is an excellent reference for learning how to identify, recruit, develop, and retain cybersecurity
talent. From the NICE Securely Provision work category, the risk management specialty area is a focus for this course. This specialty area includes all the processes
necessary to assure that existing and new IT systems meet the organization's cybersecurity and risk requirements. In the NICE Protect and Defend work category,
vulnerability assessment and management is a focus for this course. This specialty area includes conducting assessments of threats and vulnerabilities; determining
deviations from acceptable configurations or policies; assessing the level of risk; and developing or recommending appropriat e mitigation countermeasures.

The next section of this chapter covered the smart home IoT use case. The smart home is another example of how the IoT is tra nsforming the way we live, work, and play.

The next section discussed the healthcare IoT use case. Some fitness devices communicate with a cloud application. A cloud application enables storage of personal
fitness data, an analysis dashboard, and a wide range of configuration settings. Patients who do not require direct observati on by healthcare professionals in a clinical
setting can be monitored at home. Monitoring devices can be worn by a patient and connected to the internet. The use of the IoT in health care adds great efficiency to
operations, but also adds challenges for IT departments and data security professionals. Healthcare personnel may use web clients running on medical devices and
systems to surf the web and read email, making these critically important devices vulnerable to the same attacks as any compu ter. Vital therapies can be manipulated,
interrupted, or disabled, resulting in patient injury or death. Healthcare administrators must ensure the devices they purchase are secure and that device security has been
adequately configured.

The final section of this chapter covered the IoT Security lab environment. This section consisted of four labs to set up a computer for the labs found throughout this
course. In addition, for some labs, the computer will run a virtual machine (VM) that can interact with a Rapberry Pi over a network.

OSI and TCP/IP Models

Layered models are often used to illustrate how data communication occurs from end to end. There are many benefits to using a layered model to explain protocols and
operations:

 They assist in protocol design because protocols operating at a specific layer have defined information that they act upon and a defined interface to the layers
above and below.

 They foster competition because products from different vendors can work together.

 They prevent technology or capability changes in one layer from affecting other layers above and below.

 They provide a common language to describe networking functions and capabilities.

You are familiar with two models used in networking: the OSI model and the TCP/IP model. Spend some time reviewing these models before you look at IoT models. In
the following pages, the activities will remind you of the structure of these models and the functions of their layers.

Note: OSI is an abbreviation for Open Systems Interconnection. TCP/IP is an abbreviation for Transport Control Protocol/Internet Protocol, two important protocols in the
TCP/IP suite.

IoT Reference Model

Like the OSI model, the IoT Reference Model has seven parts. However, the parts are called levels instead of layers. The IoT Reference Model was developed as a
common framework to guide and to help accelerate IoT deployments. The intent of the IoT reference model is to provide common terminolo gy and help clarify how
information flows and is processed for a unified IoT industry.

As shown in the figure, the model breaks down the IoT concept into seven functional levels, from physical devices and controllers at Level 1 to collaboration and process es
at Level 7.

Security in the IoT Reference Model

The figure shows that security must permeate throughout all levels in the IoT Reference Model. Security measures include:

 Securing the hardware and software of each device or system connected to the IoT network.

 Providing security for all the processes that occur at each level in the network.

 Securing the movement of data and communications between each level.

ETSI M2M Standardized Architecture

In 2008, the European Telecommunications Standards Institute (ETSI) created an architecture for machine-to-machine (M2M) communications, which also includes IoT
devices. The purpose of the model was to provide a common framework for understanding the placement of various standards and protocols in an IoT syst em. The ETSI
model includes three domains, as shown in the figure:

 Application Domain - This is where management functions can occur such as data analytics, connectivity management, smart energy management, fleet
management, or any application that consumes the data from IoT devices.

 Network Domain - This is where data exits on the local network and is transported to the Application Domain using wired and wireless protocols, such as
Multiprotocol Label Switching (MPLS), Long-Term Evolution (LTE), and Worldwide Interoperability for Microwave Access (WiMax).

 M2M Device Domain - This is where end devices, such as sensors, actuators, and controllers, connect to the network through M2M gateways using various
protocols, such as IEEE 802.15.4 and Bluetooth.

Note: For more information, use an internet search to learn more about the protocols and standards listed above.

Other IoT Models

There are a variety of other special use IoT models that have been developed, including the following:

 Purdue Model for Control Hierarchy - This is a common and well-understood model in the manufacturing
industry that segments devices and equipment into hierarchical functions. It has been incorporated into
 many other models and standards in the industry. Click here for an explanation of how Cisco incorporates
this model into its Converged Plantwide Ethernet (CPwE) solution. A simplified version of the model is
shown in the figure.

 Industrial Internet Reference Architecture (IIRA) - Created by the Industrial Internet Consortium (IIC), the
IIRA is a standards-based framework used by system architects to design industrial systems. Click here for
the IIC’s 2017 version of the IIRA.

 Internet of Things - Architecture (IoT-A) - Commonly referred to as IoT-A, this model is more formally
known as the Architectural Reference Model (ARM) for the Internet of Things. The IoT-A model is
maintained by the IoT Forum. Click here for a detailed description of the IoT-A model.

A Simple IoT Model

IoT systems can be very large and complex. Thousands of sensors, actuators, and gateways may be present in an IoT system. IoT devices may connect to gateways
using a number of protocols, and gateways may connect to the internet and cloud applications using a similarly large number of protocols. In order to secure an IoT
system, it is important to understand where vulnerabilities exist within the system.

Simplifying the system by dividing it into functional areas is a very useful way to gain an understanding of complex systems. The figure shows a simple IoT model similar to
the ETSI M2M standardized architecture. The ETSI model has three domains, each with a data management focus. Here, we convert those domains to Application,
Communication, and Device layers, as shown in the figure.

Functionally, we are interested in how things are connected to the network. For example, the Device layer of an irrigation system might include individual sprinkler heads,
moisture sensors, temperature sensors, and actuators. At the Communication layer, these devices might all be connected to a local irrigation control panel that monitors
the state of the system. At the Application layer, the control panel may be connected to a remote data center where all the control panels for multiple irrigation systems
are aggregated.

For data management, we are interested in when and where data is processed. Is it processed at the Mist layer, close to the ground where things are connected to the
network? For example, can the sprinkler for an irrigation system detect temperature and soil moisture and activate autonomously? Or is the data processed at
the Fog layer on a local device that has more power, such as irrigation system’s control panel? Can a supervisor remotely override the autonomous actions of the control
panel using a mobile or desktop application in the Cloud?

Regardless of functional connectivity and data management aspects of the IoT system, security must permeate throughout, as shown by the arrow in the graphic.

Note: The figure is adapted from a model created by Jerome Henry and Rob Barton for the Internet of Things (IoT) Fundamentals video course published by Cisco Press.

IoT Security Model

To better understand the placement of the more common protocols and standards used in IoT systems, this course uses a combination of the functional layers of the IoT
simplified model overlaid with the TCP/IP model, as shown in the figure.

Many of these IoT standards and protocols will be discussed in more depth in later chapters. Briefly, they are as follows:

Application

 Zigbee – This includes a suite of protocols and uses low-power digital radios based on the IEEE 802.15.4 wireless standard. It includes protocols at the
Application and Communication layers. The majority of components in the Zigbee specification exist at the application layer.

 Hypertext Transfer Protocol (HTTP/HTTPS) – These are robust application protocols for getting and posting data.

 Message Queuing Telemetry Transport (MQTT) – This is a lightweight publish and subscribe messaging protocol designed for resource-constrained devices
that use TCP.

 Constrained Application Protocol (CoAP) – A specialized application protocol designed for transmission of data by constrained devices on M2M networks.

Communication

 Thread – This is a standard for home automation that uses Internet Protocol version 6 (IPv6) for routing on top of an IEEE 802.15.4 wireless network.

 Transport Control Protocol (TCP) – This is a reliable transport protocol that guarantees data delivery through a system of synchronization and acknowledgment
messages.
  UDP – This is a lightweight, unreliable transport protocol that has no mechanism for guaranteed data delivery.

 RPL – This is a Routing Protocol for Low-Power and Lossy Networks that uses IPv6. Lossy networks are classified as those with devices that typically have high
loss rates, low data rates, and instability.

 IPv6 – This is a 128-bit addressing space that provides 340 undecillion unique addresses, which is more than enough for any conceivable number of IoT devices.

 6LoWPAN – This is an Internet Engineering Task Force (IETF) standard for IPv6 Low-power Wireless devices in a Personal Area Network that provides a way for
IPv6 to conform to the IEEE 802.15.4 standard. That is why 6LoWPAN is shown as crossing between the Communications Network and Devices layers in the
figure.

Device

 IEEE 802.15.4 – This is the Institute of Electrical and Electronic Engineers standard for low-rate wireless personal area networks (LR-WPANs) that is meant to be
used by low-cost, low-speed devices.

 Bluetooth Low Energy (BLE) – This is a wireless personal area network (WPAN) protocol that uses the 2.4 GHz radio frequency. The LE version provides
much-reduced power consumption without sacrificing range.

 Wi-Fi – This is a collection of IEEE 802.11 standards for wireless local area networks (WLANs) that operate in the 2.4 GHz and 5 GHz frequencies.

 Near Field Communication (NFC) – This is a collection of protocols for device-to-device communications when the devices are very close to one another (within
4 cm or 1.6 inches).

 Cellular – This includes all the cellular technologies covered by the 3rd Generation Partnership Project (3GPP) such as 4th generation (4G), LTE, and 5th
generation (5G).

 LoRaWAN, Sigfox, NB-IoT - Low-power wide-area network (LPWAN) protocols designed to carry small data payloads over long distances at low transfer rates.
Lab - Create an IoT Sensor-Actuator System

IoT systems often consist not only of sensor and actuator electronics, but also of software applications that control the sys tems through a cloud platform. In home
automation systems, sensors and actuators in the home connect to the local network over Wi-Fi and a cloud management platform through the internet. The cloud
management platform collects data from the IoT system and enables control of it from either a browser or specialized app that runs on a mobile device.

In this lab, you will build a simple circuit that is controlled by the Raspberry Pi. Then, through the integration of two web services, you will create a simple app that can
control the circuit from a mobile device, either over a cellular or Wi-Fi connection. To complete this lab, you will use your circuit building and Python skills from the IoT
Connecting Things course.

This lab uses a Jupyter notebook. To launch the lab, complete the following steps:

 Use PL-App Launcher to connect to your Raspberry Pi.

 Click the link for the Course Materials and then the link for the notebooks for this course.

 Open lab 2.2.1.4 - Create an IoT Sensor-Actuator System

Lab - Create an IoT Sensor-Actuator System 1.2.3.2

The CIA Triad

The CIA triad guides the fundamental requirements of any cybersecurity operation. The letters for the CIA triad stand for the confidentiality, integri ty, and availability of data
and information.

 Confidentiality - This requirement maintains control on information access and disclosure. Transmitted and stored data is encrypted for privacy.

 Integrity - This requirement prevents improper addition, modification, or destruction of data and information. A hash of the data should be created prior to
transmission and the hash should be tamper-proof. Access controls should also be in place to protect stored data.

 Availability - This requirement ensures information can be accessed when it is required. This means that the IoT devices can communicate on the network so
that they can submit data to and can be controlled by IoT applications. This also means that devices can not be damaged or tampered with.

Click each requirement for more information about the CIA triad.

Ten Critical Requirements for IoT Security

A set of 10 security requirements that are focused on the IoT specifically are shown in Figure 1. These requirements are a useful way to think about the securi ty needs of
IoT systems.

These 10 IoT security requirements can be organized by functional layer, as shown in Figure 2. This helps focus attention on the appropriate components of the system.
System-Wide IoT Security Requirements

The first four requirements apply to the entire IoT system, as shown in the figure.

1. Ensure data privacy. Keeping all data private should be a general requirement for confidentiality as described by the CIA triad. This includes all business and personal
data whether in transit or in storage. Data privacy includes, at a minimum, protecting personally identifiable information (P II), such as PII used in healthcare settings.

2. Minimize the attack surface. The attack surface includes all of the entry points to the system that could be exploited by a hacker. Large IoT systems provide many
potential entry points into the system. Conceivably, a hacker could use an IoT device to gain access to an entire corporate network. Minimizing the attack surface means
that all potential entry points into the network are secured. All unnecessary entry points are closed.

3. Log critical events. IoT devices require the ability to log critical system events. Logging is the process of recording events in the system. Logging should include
measurement of normal network operation and alerts for unusual network activity.

4. Minimal security operations support. A security staff requires training and management. At a minimum, they must be able to monitor systems for security incidents,
address newly discovered vulnerabilities, and investigate security breaches.
Device IoT Security Requirements

Requirements 5, 6, and 7 apply to the device layer of the IoT system, as shown in the figure. IoT devices are sensors, actuators, controllers, and gateways. All of these
devices require operating system and application programs and data in order for the devices to operate.

5. Secure boot and system integrity. IoT devices should have measures to ensure that operating systems and software are not tampered with by hackers or malware.
Hardware components, such as Trusted Platform Modules (TPM), can be used to ensure that devices are operating as intended, that device identity is valid, and that
security-related data, such as encryption keys, are protected from tampering or loss.

6. Hardened and secure system. It is important that operating systems on IoT devices do not run unnecessary network services. Network services could allow threat
actors a pathway into the system and perhaps the IoT network.

7. Secure firmware and operating system updates. It is a critical requirement that device firmware and operating systems can be updated when vulnerabilities are
discovered. Many IoT devices are deployed in the field. It is impracticable to transport them to a central location for an up date. Therefore, some sort of secure mechanism
for updating these devices over the network must be deployed.
Communication IoT Security Requirements

Requirement 8 applies to the communication layer of the IoT system, as shown in the figure. IoT communication is two-way. Sensors transmit data to applications through
gateways, and applications control actuators over the network. Transmitted data can be stolen, altered, or destroyed. Control communications can be altered or entirely
falsified. In either case, the results can be disastrous.

8. Secure communications. IoT systems must employ measures that prevent interception and falsification of data. These systems must use techniques to verify that data
that is received comes from authentic sources.
Application IoT Security Requirements

Requirements 9 and 10 apply to the application layer of the IoT system, as shown in the figure. An administrator configures IoT devices either through a command line
interface (CLI) or a graphical user interface (GUI).

9. No default or weak credentials. All IoT devices must use a strong authentication process. Many IoT products ship with default credentials that make it easier for the
device owner to configure the device. Default credentials must be changed prior to putting the device into service. Passwords should conform to security policies for length
and composition.

10. Secure web interfaces. Internet-facing web interfaces have login facilities that could be vulnerable to various types of cyberattacks. These interfaces shoul d be secure
from attacks. In addition, IoT devices use application program interfaces (API) to interact directly with web applications. Credentials in use between IoT devices and web
applications should be protected from attack.
Lab - Investigate IoT Security Requirements
In this lab, you will review a list of the top 10 IoT security vulnerabilities as documented by the Open Web Application Security Project (OWASP). These vulnerabilities are
generic weaknesses in IoT devices, communications, or applications that can be exploited by threat actors. The vulnerabilitie s are directly related to the IoT security
requirements.

Lab - Investigate IoT Security Requirements 2.2.2.8

Threat Model Analysis for an IoT System

Threat modeling is primarily a tool used to conduct tasks for risk management and vulnerability assessments. Threat modeling is a structured approach for analyzing the
security and vulnerability of a system, whether that system be a device’s hardware, software, or the networks used to communicate with other devices.

There are different ways to describe the process of threat modeling. However, this course uses an adaption of Microsoft’s Threat Model Analysis and applies it to an IoT
system, as shown in the figure. Notice that the model includes aspects of risk management and vulnerability assessment.

Click here for latest iteration of Microsoft’s Threat Model Analysis.

Step 1: Identify Security Objectives

Use the following categories to determine the security objectives for the IoT system:

 Identity - Document the controls that are in place to ensure that evidence is collected on the identity of users accessing and using the IoT system. A user can be
another device, such as a controller accessing an actuator.

 Financial - Document the financial risks of the various aspects of the IoT system so that management can determine which level of risk is acceptable. For
example, the financial risk of losing a controller in the network would probably not be as tolerable as losing one of the sen sors that report to the controller.

 Reputation - Document any possible impact on the organization’s reputation if the IoT system is attacked. For example, the reputation of a company that sells
web cameras would be severely impacted if their product became part of a worldwide distributed denial of service (DDoS) attac k.
  Privacy and Regulation - Document the impact of privacy concerns and regulation requirements. For example, the data from a temperature sensor in an
irrigation system may not have any privacy or regulatory concerns. However, the data sent from a fitness device will have pri vacy and regulatory considerations.

 Availability Guarantees - Document the expected availability and guaranteed uptime of the IoT system. For example, the tolerance for downtime to an industrial
control system (ICS) may be very low and require the implementation of significant security measures and system redundancies.

 Safety - Document the potential impacts to physical welfare of people and physical damage to equipment and facilities. This is particu larly important in ICS
environments.

Step 2: Document the IoT System Architecture

Create documents that describe the IoT system architecture including:

 Components of the IoT system at the application, communication, and device layers

 The flow of data between components and between layers

 The technologies, protocols, and standards used to implement the IoT system

Step 3: Decompose the IoT System

Use the documentation from Step 2 to dive deeper into individual components and features that impact the security objectives of the IoT system. The aim is to create a
security profile that will help you identify threats and vulnerabilities in the design, implementation, and deployment of the IoT system.

During this step, gather information about the IoT system using the following tasks:

 Identify trust boundaries between trusted components and untrusted components.

 Identify data flow between devices, the communications network, and the applications.

 Identify entry points where data is input into the system.

 Identify sensitive data within the IoT system where secure resources are stored and manipulated.

 Document the security profile to include approaches to input validation, authentication, authorization, configuration, and an y other areas of the IoT system that are
vulnerable.

Step 4: Identify and Rate Threats

The purpose of this step is to identify and rate threats. A threat is a potential danger to any asset such as data or components of the IoT system. Threat actors are people
or entities who exploit vulnerabilities. A vulnerability is a weakness in the IoT system or its design that could be exploited by a threat. Vulnerabilities combine to make up an
attack surface. Attack surfaces describe different points where a threat actor could get into a system, and where they could get data out of the system.

In this course, we will use two tools to identify and rate the threats and vulnerabilities.

STRIDE

STRIDE is a vulnerability assessment tool used to identify threats. STRIDE is an acronym that stands for the following catego ries of threats:

 Spoofing Identity

 Tampering with Data

 Repudiation

 Information Disclosure

 Denial of Service

 Elevation of Privilege
DREAD

DREAD is a risk assessment tool and is used to rate the threats discovered in the STRIDE process. DREAD is an acronym that stands for the variables used to quantify,
compare, and prioritize the amount of risk in each threat:

DREAD Risk Rating = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability)/5

STRIDE and DREAD will be explored in more detail later in the course.

Step 5: Recommend Mitigation Techniques and Technologies

After identifying and rating the threats, you must then determine the mitigation techniques for each threat and select the most appropriate technology that would reduce or
eliminate the threat. During this evaluation, you must keep in mind what makes sense from a business perspective, including e xisting policies within your organization.

Although you will perform some mitigation techniques and technologies in the labs, comprehensive mitigation implementation is beyond the scope of this course.

Chapter 2: IoT Systems and Architectures

This chapter began by discussing the OSI and TCP/IP models. There are many benefits to using a layered model to explain protocols and operations. They assist in
protocol design, they foster competition, they prevent technology or capability changes in one layer from affecting other layers above and below, and they provide a
common language to describe networking functions and capabilities.

Next, the chapter detailed IoT models. The intent of the IoT reference model is to provide common terminology and help clarif y how information flows and is processed for
a unified IoT industry. Security must permeate throughout all the levels in the IoT Reference Model. The ETSI model includes three domains, M2M device, network, and
application. There are a variety of other special use IoT models that have been developed including the Purdue Model for Control Hierarch, IIRA, and IoT-A.

The next section of this chapter covered the IoT security layers in a simplified IoT model consisting of device, communicatio n, and application layers. To better understand
the placement of the more common protocols and standards used in IoT systems, this course uses a combination of the functional layers of the IoT simplified model
overlaid with the TCP/IP.

The next section covers IoT security requirements. A list of the ten critical IoT security requirements is introduced and explained in reference to the IoT security model
layers. This is followed by a lab in which you investigated the OWASP Top 10 IoT security vulnerabilities.

The next section of this chapter covered the process of threat model analysis. Step 1 is to identify security objectives, step 2 is to document the IoT system architecture,
step 3 is to decompose the IoT system, step 4 is to identify and rate threats, and step 5 is to recommend mitigation. In step 4, STRIDE is used to identify threats and
DREAD is used to rate threats.

OWASP Hardware Vulnerability Overview

While there are many similar components, connections, authentication procedures and other similarities between
IT and IoT systems, there are several areas that need to be addressed specifically in an IoT system. OWASP
(Open Web Application Security Project) has compiled a list of vulnerabilities that should be addressed for each
attack surface within the IoT system. The vulnerabilities described by the OWASP Attack Surfaces that apply to
the devices layer of the IoT Protocol Suite are further defined in Figures 1 through 5.

The hardware sensors (Figure 1) are often placed in locations that give them easy exposure to tampering.
Additional physical perimeter security, as well as security cameras, may possibly be needed to thwart tampering.
The sensing environment could be manipulated either intentionally or unintentionally. An example of this could be
a fan located near a temperature sensor blowing cool air on the sensor. Because the sensor is not detecting a
rise in temperature, the room will be at a higher temperature than it should be. Depending on how critical the
temperature is to equipment operations this could be a damaging situation. Sensors may also be placed in
locations where they are susceptible to physical damage.
Device memory, as discussed in Figure 2, has the potential to be accessed. This provides an attacker with
sensitive data. Many devices are manufactured and shipped with default usernames and passwords. Threat
actors can use these default credentials to access the device’s memory, potentially exposing sensitive data such
as plaintext login credentials and encryption keys.

Figure 3 outlines the various device physical interfaces that could be attacked. Many IoT devices use removable
media such as SD cards to store information and the operating system. If a threat actor gained physical access to
the device, the card could be removed and duplicated or stolen. The device could be reset by powering it off or
going through the physical reset routine, such as holding down the reset button for 10 seconds. Physical access
to the device might also expose device identifiers, such as a serial number.

IoT devices often use protocols other than Ethernet to communicate with sensors and actuators. These protocols
use serial interfaces such as Universal Asynchronous Receiver-Transmitter (UART), Joint Test Action Group
(JTAG), Inter-Integrated Circuit (I2C), and Serial Peripheral Interface (SPI) for communications. A threat actor
could connect to one of these interfaces, gaining terminal access, and potentially steal or alter data. Then it is
possible for a threat actor to install a backdoor to provide continuous access.

Figures 4 and 5 specify the vulnerabilities of the firmware on the IoT device and the firmware update mechanism.
If not protected properly, the firmware of the device can be extracted and potentially modified for the attacker’s
benefit. Making certain encryption keys are kept secure is extremely important. Keeping applications and
operating systems updated is critical. After attackers are able to determine the version of an operating system or
application, they can search for vulnerabilities in order to exploit the device.
Constrained Devices

The IoT is largely made up of constrained devices. A constrained device usually has very limited power, memory, and processing cycles. In RFC 7228, the Internet
Engineering Task Force (IETF) defined the classes for constrained devices as shown in Figure 1.

Communication capabilities are also limited. Where communication is available it is unlikely that encryption is implemented due to the limited processing power of these
devices, particularly the Class 0 devices. Lack of encryption is one of the vulnerabilities listed by OWASP.

Click here to read the full RFC 7228.

Constrained devices discussed in this course include:

 Smart Sensors - At the center of IoT devices are smart sensors. Sensors have been around long before IoT. Initially they may have only provid ed a user with
some type of visual indication of what was being measured. Some sensors were able to communicate with other devices using spe cialized protocols and
interfaces. Even today many sensors require the use of a gateway to gather the information in order for it to be used in an IoT environment. Smart sensors have
the capability to communicate with a monitoring system by using an embedded microprocessor. Smart sensors also have the abili ty to self-diagnose if a problem
is encountered, such as requiring replacement of a failed switch or cleaning a dirty photo eye.

 Embedded Devices - An embedded device is essentially a product that contains a computing system designed for a special purpose. An embedded devi ce’s
operating system is typically designed to run a single application. ATM machines, point-of sale terminals, smart appliances, such as dishwashers and
refrigerators, may contain an embedded device. Products with embedded devices may provide internet connectivity, in which cas e they are considered smart or
intelligent. An embedded device that is unable to connect to the internet is said to be a “dumb device”.

 Prototyping - The Raspberry Pi and Arduino are prototyping devices for embedded systems. The Raspberry Pi needs a complete operating system to operate
and is more closely related to a desktop computer because it provides input via a keyboard and multiple types of display outp ut. The Arduino is a single-board
microcontroller that can be configured by writing program code to instruct it do various functions. The program is then compiled and sent to the Arduino’s non-
volatile flash memory. The Arduino will only perform the tasks that were written with that program code. It can be reprogramm ed by modifying the program code
and going through the same process to write the new code to NVRAM.

Click here for a series of videos from the Embedded World 2018 Exhibition and Conference.

IoT CPU Types

The major CPU types used in the IoT are ARM, MIPS and x86. The processors fall into two main categories: Reduced Instruction Set Computing (RISC) and Complex
Instruction Set Computing (CISC).

RISC

RISC processors typically have fewer transistors than CISC processors. Fewer transistors translate to lower cost, less power consumed, and less heat produced. These
attributes make RISC processors good candidates for both mobile and IoT devices. The Instruction Set Architecture (ISA) essen tially uses one computer cycle for each
instruction and contains a small set of simple instructions. The two main providers of RISC processors include:

 ARM (Advanced RISC Machine) – This is an architecture generally licensed to other companies to design their own processor. ARM processors are available in
both 32-bit and 64-bit architectures. The main CPU for the Raspberry Pi is an ARM processor.

 MIPS (Microprocessor without Interlocked Pipeline Stages) - The MIPS architecture is used for many processors in embedded systems as well as networking,
mobile, and IoT devices. MIPS processors are available in 32-bit and 64-bit implementations.

The mobile computing market is currently dominated with RISC processors primarily developed around the ARM processor.

CISC

CISC processors have the ability to perform several operations with a single instruction. More transistors are necessary to store the more complex instructions. The
additional transistors create more heat, require more power, and add to the cost of the processor. However, the use of comple x instructions reduces the size of the
program code. This provides a benefit in loading and storing applications, compared to the RISC architecture. The primary pro viders of CISC-based processors are Intel
and Advanced Micro Devices (AMD). Both Intel and AMD have been actively pursuing the IoT market by attempting to reduce power consumption and heat in their
processors.

Heterogeneous Computing
The most recent trend in reducing power requirements and increasing performance is making use of heterogeneous computing. Ess entially, heterogeneous computing
involves using more than one kind of processor with different capabilities. A common approach used by several manufactures em ploys the Graphics Processing Unit
(GPU) to perform complex mathematical calculations or to handle encryption and decryption tasks.

big.LITTLE Computing

ARM has a technology termed big.LITTLE which uses processors (cores) with differing processing capabilities and power requirements. The LITTLE processor uses less
power when the task at hand does not require as much processing capability. The big processor provides the most compute performance, with the trade off being higher
power requirements. Using this type of heterogeneous architecture can extend battery life in devices that are in remote locat ions.

Memory

IoT devices have various types of memory used for storing data, firmware, and processing. Common memory types and uses are:

 SD Card – SD cards and MicroSD cards (µSD) are often used to store data necessary for IoT operation or to store collected data. They could even include the
entire operating system and configuration files necessary for operation. The SD Card must be protected from removal in order to keep an attacker from modifying
the contents in any way, as well as protecting potentially sensitive data.

 Non-Volatile Memory – EPROM (erasable programmable read-only memory) and EEPROM (electrically erasable programmable read-only memory) are
considered non-volatile memory because they retain the information stored even when power is off. This type of memory is often used to store firmware, the
bootloader, and other critical information required for the IoT device to operate. An attacker may be able to read the commun ication between the memory and the
microcontroller. There is more discussion of this type of attack in the next section.

 Embedded MultiMediaCard (eMMC) - A type of non-volatile memory that is often soldered directly to a system board (embedded), although removable versions
are available. It is fast, low-power, and relatively inexpensive. Embedded types resist tampering and theft better than removable SD Card memory.

 Volatile Memory – SRAM (Static Random Access Memory) and DRAM (Dynamic Random Access Memory) are used to hold the operating code and provide
temporary storage while the device is running. After the device is powered down, all data in memory is lost.

Physical Ports

IoT devices may have some of the same physical ports as desktop or mobile devices, such as USB and Ethernet. In addition, the re could be several other interfaces not
found on common computer devices. These may be accessible on some IoT devices in the form of a header with pins protruding from the circuit board, as shown in the left
front side of the circuit board in the figure.

Several of these interfaces provide some sort of serial communication in which bits are transferred one after another in a series. Standard procedures for the protection of
USB and Ethernet ports should be employed. Those ports could potentially be used to extract information from the device by co nnecting another computer system to the
IoT device.

The following is a list of some of the other communication ports that may be available:

 Universal Asynchronous Receiver-Transmitter (UART) – This interface could be used to communicate with other hardware peripheral devices. This attack
surface may provide read/write access to the device using serial communication. There may be a login shell available if the a ttacker gains access to these pins.
Even if a login shell is not available, there is the possibility that data may be transmitted on these pins providing an attacker with the ability to capture the data.
When these pins are not needed they should be disabled within the configuration if possible. There are typically three pins n ecessary for serial communication
with UART: Tx (Transmit), Rx (Receive), and Ground.

 Inter-Integrated Circuit (I2C) – This is a serial data protocol used for short distance communication, often between chips on the same board. I2C may be used to
communicate between the microcontroller and EEPROM chips to store data or program code. An attacker could potentially corrupt data or extract data that is
being transferred.

 Serial Peripheral Interface (SPI) – This is a short distance serial protocol that uses a four-wire serial bus. SPI allows for multiple devices to be connected to the
same wires and is capable of full duplex communication using separate Slave Select lines. SPI has a clock signal so it operates in a synchronous fashion and at
much faster data rates than UART or I2C. SPI is also used for communicating with devices on the same board. It may be used for communicating with EEPROM,
flash, or other devices located as much as a few feet away. When considering the attack surface, keep in mind that the same problems exist for SPI as the other
serial communication. Extracting sensitive information is a very real possibility.

 Joint Test Action Group (JTAG) – JTAG is not a communication protocol, but rather a protocol to be used for testing and debugging. Providing access to the
JTAG port could allow an attacker to reverse engineer the logic for the microcontroller. An attacker could also extract the firmware and possibly even load
malicious firmware on the device. There are specialized boards available to assist with the process after access to the JTAG pins has been gained.
Embedded Systems

An embedded system is designed for a specific function within a larger system. The home security devices shown in the figure form a good example of an embedded
system. All operations of the security system are controlled by a microcontroller designed specifically for that purpose. In this case, the microcontroller can be programmed
for the sensors unique to the installation. Sensors may include smoke sensors, motion sensors, gas sensors, temperature sensors, and more. The sensors provide d ata to
the microcontroller which will trigger an alarm if something exceeds the thresholds set for the particular sensor. The microcontroller may have the ability to display
information on a screen or communicate with other computer equipment for monitoring.

The home security system in the figure uses a microcontroller. Some embedded systems use microprocessors. A microprocessor an d microcontroller may have the same
CPU embedded. However, the microprocessor requires external components such as memory. The microcontroller-based system is self-contained and could include flash
memory, RAM, serial communications, and other peripherals within the integrated circuit.

Embedded systems may use an embedded operating system or be programmed directly using the machine code for the CPU. Embedded systems are tailored to handle
real-time operations. In some cases, stripped down versions of Linux are used. Embedded Linux can be found in smart TVs, gaming consoles, Network Attached Storage
(NAS), and numerous other devices. Other embedded systems include Java Embedded and Windows IoT, formerly known as Windows Em bedded.

Debugging the programming for embedded systems is handled differently than typical PC software debugging. On a PC, the software is developed on the same proc essor
that the program will run on. This provides the use of built-in tools within the development environment to debug for potential program errors. On an embedded system, the
software is built outside the environment in which it will be operating. In order to debug embedded system software, the syst ems make use of the JTAG port to track down
software issues.

Compiled or Interpreted Code

When developing application software for any system, developers may have a choice as to the programming language and developm ent environment. There are emulation
environments for developing applications targeted to other platforms which run on a PC. For instance, when developing for mobile devices, an emulator is available so that
screen layout would mirror how the application will look and perform on the mobile device, as shown in the figure. The same is true for some of the applications that would
run on an IoT device.

Developers also have a choice as to the type of programming language. Programming languages fall into two broad categories: c ompiled or interpreted.

Compiled Code

Source code is written in a format that is readable with a text editor and then converted (compiled) into machine code that is read and executed by the processor. The
developer must complete the compilation process before the program is useable. If changes are necessary, the text code is cha nged and then recompiled prior to being
used. Examples of compiled code languages include C, C++, Rust and Visual Basic.

Interpreted Code

With interpreted code, each instruction is executed one after another. The interpreter translates the instruction into a form of machine code that can be performed by the
processor. If an error occurs, the program will stop at that point and corrections can be made. Python may currently be the m ost popular interpreted code language for IoT
devices. Other interpreted languages that may be used include JavaScript, Perl, and PHP.

Depending on the operating system used, it is also possible to use scripts to perform various tasks. In a Linux environment it is fairly common to use shell scripts to
perform certain repetitive tasks. In a Windows environment PowerShell has become very popular and powerful. Microsoft has also made PowerShell available on several
Linux distributions. Both of these scripting environments operate in an interpretive fashion.

When considering the OWASP Attack Surface, program code can be a great risk. Interpreted code is easy to modify because it is generally stored in a text format. Even
compiled code could be altered by an attacker using a debugger and replacing machine code instructions with malicious code. W ith compiled code, it is possible to verify
the digital signature of the binary executable to check that it has not been altered.

Debug/Boot Mode

It is common for systems to offer a special debug/boot mode in case the system encounters a problem when starting up. Sometimes the debug/boot mode can be
accessed using a keystroke combination. This is also possible in the case where attackers have access to the device board. Th ey may be able to use the JTAG port.
When operating in debug/boot mode, there is a possibility authentication could be bypassed. If attackers can gain access to t he debug/boot mode, it would be possible for
them to make other changes to the system or even install a backdoor. This would provide access to the system at will, if the system is available on a network.

Common IoT Operating Systems

IoT devices typically use a trimmed down version of an operating system. Developers can choose from open source and commercia l options.

Busybox

Busybox is an open source compiled executable that contains many of the core utilities that are usually found in Linux distri butions. Most of the utilities are scaled-down
versions that have fewer options than their full equivalents. Busybox was written to run on constrained devices that have limited storage and system resources. Busybox is
modular, so unnecessary utilities can be left out of the compiled binary. This modularity permits device manufacturers to rem ove unnecessary utilities that can create
security vulnerabilities from the version that is deployed with an IoT device. For instance, telnet and the telnet daemon may be present. An attacker could use telnet as a
brute force attack vector in DDoS attacks. Click here to see a Busybox system in action.

Android Embedded

Android Embedded is a lightweight Linux version primarily used in mobile devices, but it can also be used for IoT devices. It is designed to reduce power consumption and
works with all of the common processors used in IoT devices. Android Embedded also includes all of the necessary connectivity software including video display drivers
and network drivers.

Commercial Options

In the commercial options, products such as VxWorks, Windows 10 IoT, and ARM Mbed are available:
  VxWorks is a real time operating system (RTOS) developed by Wind River Systems. VxWorks is a popular embedded OS in several sectors, including medical,
energy, transportation, consumer electronics and others. VxWorks also supports all of the major processors.

 Windows 10 IoT Core is a version of Windows 10 designed to run on smaller devices. It runs on either ARM or x86/x64 devices and can support devic es that
have a display.

 ARM Mbed is the only one of these offerings that restricts itself to one processor, that being ARM. ARM Mbed is an open source OS, so it is still a popular option.

Physical Vulnerabilities of Constrained Devices

The previous discussion of constrained devices focused on the vulnerabilities related to data transmission and lack of encryption mechanisms. Constrained devices are
often placed in remote locations where physical security may be difficult to implement. Potential vulnerabilities could include:

 Theft of the device

 Physical damage to the device

 Disabling the device, removing power source

 Disabling communication, disconnecting cables or other means of disruption

It is a good idea to provide some type of video surveillance where possible. Providing a tamper proof or tamper resistant type of housing should also be considered. Using
an anti-tamper seal on the case could provide a visual method of determining if a device has been compromised. Tamper proof housing c ould even render the device
unusable if the case were opened.

Physical Device Security

Any time physical access is available to most types of computing devices, there are potential security risks. The same issues that pertain to constrained devices apply to
other IoT devices. A device such as a sensor could be moved, causing it to lose calibration. Many smart sensors have the ability to trigger an alarm when they are not in
proper adjustment. When it is practical, selecting devices with self-monitoring capability is a good idea.

Devices that have storage, such as an SD card, could potentially have data stolen or destroyed by an attacker. This is another situation that calls for a tamper proof
enclosure.

Physical device security is easier to implement in a controlled environment. Standard surveillance and security protocols should be implemented as a first layer of defense.
Physical device security also includes insuring that you always have access to the device. Consider implementing battery back up to power IoT devices that rely on fixed
power sources in case of power outages.

Hardware Vulnerabilities

Hardware vulnerabilities are very common with many IoT devices. Wired magazine published an article in August
2017 outlining how to gain access to firmware on numerous IoT devices using eMMC flash and a $10 SD card
reader. By soldering five wires to the eMMC flash chip and using a standard SD card reader the attacker was able
to retrieve the firmware, operating system, and software on the chip and then save them to a PC. After the
software is copied it can be examined for code vulnerabilities. This particular hack affected hundreds of millions of
devices. Many manufacturers issued patches for the devices but there are likely still a large number of devices
that are vulnerable. Hacks like this one illustrate the need for implementing physical device security.

An example of another hardware vulnerability is gaining shell access via the UART connection to an IoT doorbell.
While most systems require some type of authentication when gaining access to the UART pins, there are some
devices that provide a command prompt with availability to numerous commands when connected. In another
UART hack, a smart refrigerator provided access to a root shell when the system was rebooted.

Other devices that have been found to have hardware-based vulnerabilities that have been exploited include:

 Blu-Ray players
  Cameras

 Home automation devices

 Media players

 Music players

 NAS devices

 Printers

 Televisions

 VoIP hardware

 Medical devices

 Networking devices

 Android TV devices

Lab - Investigate the FCC Database

IoT devices often use wireless technologies to communicate with various equipment, including other IoT devices. The FCC requi res companies that develop devices that
use any form of radio frequency for transmission to register those devices and provide supporting information about the particular device. Tests must be performed to
make certain that the devices conform to the rules established by the FCC. The FCC requires that device manufacturers visibly display the FCC ID on the device.

In this lab, you will use the Federal Communications Commission (FCC) database to view information about various IoT devices that utilize radio frequencies for data
transmission.

Lab - Investigate the FCC Database 3.2.1.4

Lab - Compromise IoT Device Hardware

In this lab, you will demonstrate how an IoT device may be compromised by physically connecting to the device using communication protocols other than Ethernet. A
Raspberry Pi could be used for controlling and monitoring many types of equipment. It is important that security is in place at the forefront when configuring and positioning
these types of devices. The last part of the lab demonstrates how to secure against these compromises.

Lab - Compromise IoT Device Hardware 3.2.1.5

Esca lisa

Firmware Vulnerabilities

IoT devices require firmware to run. Firmware is basically embedded software that contains a minimal operating system and related programs to control the IoT device.
Just like any other software or operating system, IoT device firmware can contain security vulnerabilities that are discovered aft er their release. An internet search for “IoT
vulnerabilities” will result in countless examples of a variety of IoT security issues and hacking. IoT devices are susceptible to a wide range of attacks; however, firmware-
related vulnerabilities are quite prevalent. Firmware-related vulnerabilities for IoT devices are similar to those of other computers or networking devices. These
vulnerabilities include the following:

Default Login Credentials

Most IoT attacks occur because the default login credentials were not changed. It is not uncommon for IoT device manufacturers to ship their products with default
passwords, as shown in the figure. Default or weak login credentials will allow a hacker to access a device very easily. Default credentials only require the use of an
internet search engine, but a weak password will require a few extra steps including the use of password challenging software. It is important that usernames and
passwords are changed to meet strong criteria before connecting any IoT device to the internet. In the event that a hacker is able to crack a password, it is important that
every device has a unique password.

Distributed Denial of Service (DDoS) attacks

DDOS attacks require botnets of infected systems from around the world. IoT devices are often compromised through the use of default or weak login credentials. For this
reason, IoT devices are commonly targeted. After the weak login information is known, a hacker can write an automated script to log into remote IoT devices and copy the
infected software to their systems.

Out-of-Date Firmware

If a hacker is trying to target a specific IoT device or group of devices, they will usually look to see if the firmware is out of date or look for any exploits that have yet to be
addressed with a patch.

Buffer Overflow Attacks

Buffer overflow attacks can occur with vulnerable software when the programmer does not account for the size of the input that a user might enter. A buffer overflow attack
could cause corrupt data, a denial of service, or could allow malicious code to run on the target system.

Backdoor Installation

The installation of a backdoor usually occurs after the attacker gains remote access to the IoT device. On a Linux-based operating system, the attacker could run the
netcat command in the background and execute malicious commands on this system remotely from anywhere in the world. In additi on, network diagnostic and testing tools
are sometimes left behind in the firmware by the IoT device manufacturer. These tools can make the devices more exploitable i f unauthorized entry occurs.

Firmware Update Issues

Updating IoT firmware and installing patches to fix security vulnerabilities are critical components of network security. There are several questions to keep in mind when
dealing with IoT device firmware updates, as shown in the figure.

IoT security has not kept up with the growth rate of IoT devices. In some cases, patches do not exist for security vulnerabilities for devices. In other cases, the device may
not even be updatable or patchable. IoT devices in an organization might number in the thousands or tens of thousands. Installing updates and patches on this number of
devices presents its own challenges. In addition, it is important to verify that all upgrades and patches come from a verified source. These factors need to be considered
when managing IoT devices and firmware.
Firmware Update Solutions

As a network security administrator or IT professional working with IoT devices, it is necessary to keep a database of all of your IoT devices and their firmware information.
Firmware should be updated as soon as new releases come out because it is likely these updates are addressing security vulnerabilities. A plan should exist for checking
the manufacturer’s website for updates on a regular basis.

In addition, it is important to monitor or subscribe to various security vulnerability services such as BugTraq and US-CERT (United States Computer Emergency Readiness
Team). A screen shot of the US-CERT Alerts page is shown in the figure. Click here to learn more about BugTraq.

Sometimes vulnerabilities in a certain firmware will be discovered and announced before the vendor has a patch or update to install. If a serious vulnerab ility exists without
a known fix from the manufacturer, decisions must be made by the appropriate level of management as to whether or not to leave these devices online. Most of the time,
updates and fixes are kept up-to-date on the manufacturer’s website.

The best solution is to have an automatic system for updating firmware and installing security patches on IoT devices within an organization. It is important that any
firmware updates or patches are digitally signed and verified before installing.

Rooting an OS

Rooting an IoT device occurs when an attacker follows a process that successfully obtains root-level user access to the device OS. An attacker with root access has
complete control over that device. She can read, modify, or delete any file on that system. In the wrong hands, this can be a very dangerous level of access.

The JTAG and UART interfaces are common attack vectors for gaining root access to the device. If the attacker can obtain physical access to a device, she can connect
her laptop or tablet to the IoT device using either the JTAG or UART serial interfaces. She now has access and can hack into the device. With a UART interface, this could
be as simple as connecting pins to the transmit, receive, and ground connectors. After obtaining access, she can read the device’s memory and modify the firmware. After
she has access to the firmware, she can look for vulnerabilities and introduce new security holes. This can be achieved by downloading the firmware, modifying it, and re-
uploading it to the device with a backdoor or other newly introduced vulnerability.

Lab - Compromise IoT Device Firmware

IoT devices are susceptible to attacks like many other internet-connected devices that are running an operating system. In the past, threat actors have taken over smart
home devices including security cameras, refrigerators, ovens, air conditioners, and even vehicles whil e they were being driven. IoT devices with cameras can potentially
be used as spying devices within one’s home. Many popular IoT devices run Linux as their OS.
Vulnerabilities with device firmware include, but are not limited to: key handling vulnerabilities, hard coded passwords, default username/passwords, plaintext password
transmission, buffer overflow attacks, distributed denial of service attacks, and firmware modification attacks.

This lab requires students to download a device firmware binary file and decompress/decode it to its file system and kernel components. Students will be required to
analyze the firmware and investigate how vulnerabilities can be exploited.

In this particular lab, we will be exploring an IoT device’s firmware file by using a wide variety of tools/commands on a Kali Linux virtual image.

Lab - Compromise IoT Device Firmware 3.2.2.7

Access Control Models

An organization must implement proper access controls to protect its network resources, information system resources, and inf ormation.

A security analyst should be familiar with different basic access control models to have a better understanding of how threat actors can break the access controls.

 Mandatory access control (MAC) - Applies the strictest access control and is typically used in military or mission critical applications. It assigns security level
labels to information and provides users with access based on their security level clearance.

 Discretionary access control (DAC) - It allows users to control access to their data as owners of that data. DAC may use ACLs or other methods to specify
which users or groups of users have access to the information.

 Non-Discretionary access control - Access decisions are based on an individual's roles and responsibilities within the organization, also known as role-based
access control (RBAC).

 Attribute-based access control (ABAC) - Allows access based on attributes of the object (resource) be to accessed, the subject (user) accessing the resource,
and environmental factors regarding how the object is to be accessed, such as time of day.

Another access control model is the principle of least privilege, which specifies a limited, as-needed approach to granting user and process access rights to specific
information and tools. The principle of least privilege states that users should be granted the minimum amount of access requ ired to perform their work function.

A common exploit is known as privilege escalation. In this exploit, vulnerabilities in servers or access control systems are exploited to grant an unauthorized user, or
software process, higher levels of privilege than they should have. After the privilege is granted, the threat actor can access sensitive information or take control of a
system.

Various types of IoT devices require different levels of access to the network and network resources, just as users do.

OAuth 2.0 Authorization Framework

Access control for IoT is an increasingly important security concern, as the number of IoT devices grows.
Traditionally, IoT vendors have not implemented this security consideration into their products. This is starting to
change. Identity and access management (IAM) is becoming a critical component to IoT solutions for
organizations. IAM is the security principle that defines who can access what resources and the privileges they
have when they obtain access.

The OAuth 2.0 Authorization Framework is a standardized protocol for internet-based authentication and
authorization specified in IETF RFC 6749. This protocol can be used for access control of IoT devices to make
them more secure by having an authorization server handle the authorization of resources. This is very beneficial
in an environment where there are third-party applications that need restricted access to resources. Without this,
resources would have to share credentials with third parties. It is able to achieve this through the delegation of
authorization to resources using the following process:

1. The client makes an authorization request to the resource owner. The resource owner is the entity that controls
the resource.

2. The resource owner sends back an authorization grant to the client. The client is the device making the
request.

3. The client sends the authorization grant to the authorization server, requests an access token, and tries to
authenticate. The authorization server is the entity that issues and controls tokens to clients after authentication.

4. If the authentication was successful, the authorization server validates the authorization grant and sends an
access token back to the client.
5. The client sends the access token to the resource server to make a resource request. The resource server is
the server that hosts the resources that are being requested.

6. After validating the access token, the resource server allows access to the requested resource.

Click here for RFC 6749, The OAuth 2.0 Authorization Framework.

IoT Device Identity Management

A fundamental component of securing any IoT infrastructure is to identify and authenticate an IoT device. Identity management normally refers to the process of identifying,
authenticating, and authorizing users' access to devices or resources. However, in the world of IoT, identity management also refers to the identification of a wide range of
IoT devices and managing their access to data. The IoT world not only includes Machine-to-Human (M2H) communication, but also Machine-to-Machine (M2M). There are
a wide range of IoT devices that communicate with other devices, such as medical devices or specialized sensors in a manufact uring facility. It is not uncommon for
sensitive information to be transmitted between devices, so access to this data should be controlled. IoT device identity man agement should handle the access of IoT
devices to information from other resources as well as handling access to that device's own resources.

As the number of IoT devices continues to grow exponentially, the relationships between devices also grow exponentially. Trad itional Identity and Access Management
(IAM) platforms are not able to keep up with the growth of IoT devices and the large number of relationships between these devices. With large organizations, the number
of identities could number in the millions. A newer approach is called Identity Resource Management (IRM). IRM can help organizations manage a larger number of
identities and relationships between those identities, while keeping resources secure. It is much more scalable than the trad itional IAM platforms.

Data and Password Security

Encryption is the mechanism that is used to ensure data confidentiality. Encrypting is applying an algorithm to data that wil l make it unreadable to those who are not
authorized to see the information. The algorithm could be applied to a file containing a secret email, or to all network traffic which could contain an email or passwords. In
order to decrypt the message and make it readable again, a secret key is required.

Passwords are usually stored as hash values. Passwords are usually encrypted during transmission. The hashed value of the tra nsmitted password is then compared to
the hashed value of the stored password to authenticate the user. Hashes are designed to be irreversible. Encryption must be reversible in order for the encrypted
transmitted data to be made readable by the receiving device or process.

Encryption for IoT data is critical because some of the information being transmitted could contain sensitive patient information. It might even contain information being
sent to an IoT device that is used to control the amount of a medication in an IV pump for a patient. If any of this information is intercepted or tampered with, the
consequences could be very serious.

IoT devices are especially vulnerable to threat actors because many older IoT devices currently in production do not support encryption. To make things worse, IoT
devices usually require some form of wireless communication which makes it easier for threat actors to intercept data transmissions if there is no encryption.
There are several IoT wireless standards that IoT manufacturers can use that support some level of security:

 Zigbee - 10-100 meters; low-power; low-data rate; offers basic encryption

 LoRa - Up to 10 kilometers; low-power; offers better encryption than Zigbee 64-128 bit

 LTE-M (Long Term Evolution for Machines) – Long range; uses cellular; most secure; offers NSA AES 256-bit security

 White-Fi (IEEE 802.11af) - Up to 100 meters; low power; WPA security

Encryption in Constrained Systems

Due to the nature and size of IoT devices, they usually have a limited amount of resources. A consequence of this is that mos t IoT devices do not have the processing
power or resources necessary for the more robust encryption algorithms. Because encryption is still a necessary component for their functionality, lightweight encrypti on
algorithms could be used. These algorithms could be implemented in software or through an integrated circuit (IC) via hardware. Each of these methods comes with an
increase in cost for the IoT manufacturer because both methods require additional resources. Currently, there is no standard, and many IoT devices do not support
encryption at all.

The National Institute of Standards and Technology (NIST) has recently started the “lightweight cryptography initiative”. The goal is to develop a standard cryptographic
algorithm that can be used in small IoT devices with minimal resources. The purpose is to secure these devices and their data . As of May of 2018, this initiative is still in
development.

Public Key Cryptography

Traditional cryptography is based on the sender and receiver of a message knowing and using the same secret key. Using this m ethod, the sender uses the secret key to
encrypt the message, and the receiver uses the same secret key to decrypt the message. This method is known as “symmetric crypto graphy”. The problem is getting the
sender and receiver to agree on the same secret key without anyone else finding out. Because all keys in a secret-key cryptosystem must remain secret, the challenge has
been providing secure key management.

The concept of public-key cryptography was introduced in 1976 by Whitfield Diffie and Martin Hellman in order to solve the secure key management problem. In their
concept, each person gets a pair of keys: one called the public key and the other called the private key. These two keys are mathematically related to each other. Each
person's public key is published while the private key is kept secret. The need for the sender and receiver to share secret information is eliminated and all communications
involve only public keys, and no private key is ever transmitted or shared. With this system, anyone can send a confidential message by using public information (public
key of the intended recipient), but the message can only be decrypted using the private key of the intended recipient. In add ition, public-key cryptography can be used not
only for privacy (encryption), but to prove the authenticity and origin of data or software (digital signatures), as well.

Implementing public key cryptography into IoT devices is the recommended method to ensure IoT device security. This can be ac hieved by programming the cryptographic
method into the integrated circuit (IC) or in the firmware. Using a strong enough key and algorithm could require trillions of dollars of computing power to break.
Implementing this into the device usually comes at an increased cost. All of these factors must be considered by the IoT manu facturer.

Authorities and the PKI Trust System

The Public Key Infrastructure (PKI) with its Certificate Authority (CA) is needed to support large-scale distribution and identification of public encryption keys. The PKI
framework facilitates a highly scalable trust relationship. PKI is used to prove the identity of the IoT device.

It consists of the hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revo ke digital certificates.

Click the plus signs (+) in Figure 1 to see the main elements of the PKI.

Click the plus signs in Figure 2 to see how these elements interoperate:

In the example, Bob has received his digital certificate from the CA. This certificate is used whenever Bob communicates with other parties.

Bob communicates with Alice.

When Alice receives Bob’s digital certificate, she communicates with the trusted CA to validate Bob’s identity.

Note: Not all PKI certificates are directly received from a CA. A registration authority (RA) is a subordinate CA and is certified by a root CA to issue certificates for specific
uses.

There are numerous challenges with using PKI with IoT devices. Some of the challenges include the resource limitations of IoT devices. That means that the hardware
cannot support the demand. Another challenge is that of using a PKI Authority. Certificate management with the large number of IoT devices will require time-consuming
intervention and may ultimately be impossible to manage as more devices are added. The industry is currentl y trying to solve this issue. One solution is for an organization
to issue its own certificates for these devices. There are also 3rd party vendors with software that will allow for automatic provisioning of the PKI certificates for IoT devices
without human intervention.
Packet Tracer - Threat Modeling at the IoT Device Layer

A home owner has been reading about the IoT and is very enthusiastic about the capabilities of home automation IoT systems. The home owner wants to install such a
system in his house but does not know how to do so. He has contacted a company that can design and install the system. The company focuses on security throughout
the system design, provisioning, and development process. They are currently developing a threat model for the system. You have been hired by the company and your
first task is to complete the threat model.

The house is 3500 sq. ft. and includes two stories and an attic. The customers are away from home regularly and have requeste d the safest house possible. The customer
wants to be able to remotely monitor the house and wants the following IoT-supported systems:

 Climate control

 Smoke / fire

 Temperature issues out of the normal range

 Door and window locks

 Lawn watering

 Local alarm and emergency department messaging

The system should be controllable locally and through the cloud. The user should be able to access the controller from a web browser from inside the network as well as
remotely through a smartphone app. This will allow the customers to monitor or control the system when they are away.

The system should collect and store data from the remote sensors and various actions should take place based on the input from those sensors. For example, if the
temperature goes above the maximum range, it probably means the AC is not working and someone needs to be notified ASAP. If the system detects smoke, the local
alarm should sound, and the customer and the fire department should be alerted. Data from the system should be retained and a nalyzed. In addition, the customer should
be able to change the threshold values that trigger different actuators and events as necessary, either locally or through th e mobile app. The triggers and behaviors, data
analytics, and remote-control access are all available through a home automation cloud application service that the system will interface with.

The home owners should have password protected accounts for access to the system. In addition, the company should have access to system diagnostics in case
problems occur with the system. Only the homeowner should have access to the cloud applications.

The team has designed the system and it is your job to perform threat modeling on the design.

You will start by creating a threat model for system. The home automation system has been prototyped in Packet Tracer. The system is very similar to the home IoT
system that you explored earlier in the course. Because the threat modeling process is very detailed, we will be breaking it up into four linked labs. The first three labs are
for each layer of the IoT attack surface. In the final lab, you will rate the risks and determine how the risks will be managed.

In this Packet Tracer, you will begin the threat modeling process for the device layer of the IoT attack surface.

Packet Tracer - Threat Modeling at the IoT Device Layer Instructions 3.3.2.5

Packet Tracer - Threat Modeling at the IoT Device Layer PKA 3.3.2.5

Chapter 3: The IoT Device Layer Attack Surface

This chapter began by discussing IoT device hardware components. OWASP has compiled a list of vulnerabilities that should be addressed for each attack surface within
the IoT system. Where communication is available it is unlikely that encryption is implemented due to the limited processing power of constrained devices, particularly th e
Class 0 devices. In IoT devices, the CPU, memory, and physical ports have the potential to be compromised by threat actors.

Next, the chapter detailed IoT device software components. Embedded systems may use an embedded operating system or be programmed directly using the machine
code for the CPU. Interpreted code is easy to modify because it is generally stored in a text format. Even compiled code could be altered by an attacker using a debugger
and replacing machine code instructions with malicious code. If an attacker can gain access to the debug/boot mode it would be possible for them to make other changes
to the system or even install a backdoor. This would provide access to the system at will if the system is available on a network.

The next section of this chapter covered hardware security. Constrained devices are often placed in remote locations where ph ysical security may be difficult to implement.
Standard surveillance and security protocols should be implemented as a first layer of defense. While most systems require some type of authentication when gaining
access to the UART pins there are some devices that provide a command prompt with availability to numerous commands when connected.

The next section discussed firmware vulnerabilities. Just like any other software or operating system, IoT device firmware ca n contain security vulnerabilities that are
discovered after their release. In some cases, patches do not exist for security vulnerabilities for devices. In other cases, the device may not eve n be updatable or
patchable. Firmware should be updated as soon as new releases come out because it is likely these updates are addressing security vulnerabilities. If the attacker can
obtain physical access to a device, she can connect her laptop or tablet to the IoT device using either the JTAG or UART seri al interfaces to gain unauthorized access and
hack into the device.

The next section discussed network access control concepts. A security analyst should understand the different basic access control models to have a better
understanding of how attackers can break the access controls. The OAuth 2.0 Authorization Framework can be us ed for access control of IoT devices to make them more
secure by having an authorization server handle the authorization of resources. IoT device identity management should handle IoT device access to other information from
other resources in addition to handling access to that device's resources.

The final section of this chapter covered encryption. Encryption for IoT data is critical because some of the information bei ng transmitted could be sensitive PII. Most IoT
devices do not have the processing power or resources necessary for the more robust encryption algorithms. Implementing public key cryptography into IoT devices is the
recommended method to ensure IoT device security. The PKI framework facilitates a highly scalable trust relationship. PKI is used to prove the identity of the IoT device.

OWASP Communication Layer Vulnerabilities

As we know, the IoT consists of sensors, actuators, and smart things that are connected to applications through
communication channels. The communication channels carry IoT data to the applications for storage and
processing. Some IoT applications process and analyze the data to create interactive dashboards and reports.
Other applications use conditions and rules to control the actuators that make changes in the environment.
Communication channels enable such feedback loops to function.

The communication layer of the IoT is responsible for the transportation of data between devices, facilities, and
applications. This data transportation often occurs in the cloud. Network security needs to be considered for all
elements of the IoT system’s attack surface. Data in motion can be intercepted, damaged, or altered. In addition,
because the purpose of much of the IoT is data collection, attacks on the systems that carry data can bring down
an entire IoT system.

Some of the Open Web Application Security Project (OWASP) communication layer vulnerabilities are shown in
the figure.

Communication Channels

Depending on the application and environment, IoT communication channels can take a number of forms. In some implementations, sensor nodes can communicate
directly with IoT applications using IPv6. This can happen through a router using LAN and WAN protocols, or even directly ove r cellular data services to the internet.

Figure 1 shows some of the various types of wireless networks that exist in the IoT. Each network may use different protocols to communicate between IoT devices,
between IoT devices and gateways, and between IoT devices and the internet or the cloud.

Figure 2 shows the ETSI model, which is a representative end-to-end IoT system. Note that it is characterized as a machine-to-machine (M2M) system.

Many IoT sensor nodes are constrained in terms of resources, power, and processing. This means that communication channels will exist between low power devices and
a gateway device. The gateway translates wireless sensor network (WSN) traffic to IP protocol traffic that can travel on traditional data networks.

Some WSNs can consist of hundreds, or even thousands, of sensor nodes. These nodes may only have battery power and very limited processing ability. Due to power
constraints, these nodes may only use very short-range radios. In this case, protocols are used that allow sensor data to travel from node to node until the data reaches
the gateway.

These communication channels, and the protocols that enable them, make up the IoT data communication attack surface.
IoT Communication Scenarios

IoT wireless protocols operate in several different topologies. Figure 1 shows a mesh topology in which smart objects forward data to other smart objects in order to reach
a gateway (which may be out of range). This enables sensor nodes and smart objects to be deployed over a much larger area than would otherwise be possible if each
node were required to communicate directly with a gateway. The Cisco 829 Industrial Integrated Services Router (IISR) connects to a private or public network.

Figure 2 shows a hub-and-spoke, or star, topology. In this case all things must be deployed within range of the IoT gateway. This limits the potential coverage area of the
network and requires the purchase, installation, and configuration of additional gateway devices and the links to the WAN or internet. In both topologies, the gateway
device converts the traffic to Wi-Fi or Ethernet. It also encapsulates the data in IP packets for transmission on the enterprise network and the internet.

Figure 3 illustrates a scenario in which things can communicate directly with the cloud or data center. In this situation, the things have their own IPv6 protocol stacks and
messaging protocols. This allows the sensor data to be sent through the IP network without requiring translation into IP by an IoT gateway. Because most things are not
likely to be using Wi-Fi due to power and processing constraints, the gateway will convert the traffic to the appropriate Layer 2 encapsulation; however, the Layer 3
encapsulation will most likely be unaltered. In this topology, each thing will have its own unique IPv6 address.
Wireless Protocol Overview

Recall that the IoT Protocol Suite includes the following wireless protocols:

 IEEE 802.15.4 - The Institute of Electrical and Electronic Engineers’ standard for low-rate wireless personal area networks (LR-WPANs) that is meant to be used
by low-cost, low-speed devices. ZigBee, Thread, and 6LoWPAN are based on IEEE 802.15.4.

 Bluetooth Low Energy (BLE) – This is a wireless personal area network (WPAN) that uses the 2.4 GHz radio frequency. The LE version provides much-reduced
power consumption without sacrificing range.

 Wi-Fi - This is a collection of IEEE 802.11 standards for wireless local area networks (WLANs) that operate in the 2.4 GHz and 5 GHz frequencies.

 Near Field Communication (NFC) – This is a collection of protocols for device-to-device communications when the devices are very close to one another (within
4 cm or 1.6 inches).

 Cellular – This includes all the cellular technologies covered by the 3rd Generation Partnership Project (3GPP) such as 4th generation (4G), LTE, and 5th
generation (5G).

 Low-power WAN Protocols (LPWAN) A general term for a number of wireless protocols such as LoRaWAN, Sigfox, and NB-IoT that generally operate over
unlicensed RF bands. These protocols enable constrained devices to transmit small amounts of data over distances of up to 10 km depending on the
environment.

In this topic, we will focus on Bluetooth, Wi-Fi, and IEEE 802.15.4.

Bluetooth and Wi-Fi

Bluetooth and Wi-Fi are often used in IoT systems that require simplicity of setup, such as a home IoT network. Because Bluetooth and Wi -Fi are arguably the most
common wireless protocols and are found in most connected homes, home automation and security applications will frequently use them.

Because the home IoT market is predicted to be very large, many vendors create devices that are easy to set up to help increa se sales. However, simplicity of setup and
administration frequently sacrifices security. For example, when a new IoT device, such as a smart plug, is first installed, how does the consumer connect to it? If the smart
plug is designed to be controlled over the internet, it must connect somehow to the home Wi-Fi network, even though it does not know the SSID. Some of these devices
will actually set up hot spots within the house that can be identified by the vendor's cell phone app or PC software. This enables the buyer to connect to the device without
first having to configure it for the local network. These minimally secured Wi-Fi hotspots are seldom known to be in operation within the home. This, combined with widely-
known login credentials, make these smart devices very vulnerable to control by unauthorized users. In addition, poorly secured devices may actually provide a path into
the rest of the network for threat actors and malware.

Lab - Sniffing Bluetooth with the Raspberry Pi

In this lab, students will become familiar with varying levels of security on different common devices that use Bluetooth/BLE (Bluetooth Low Energy). Students will
configure a Raspberry Pi to detect and display information about the Bluetooth devices that are in its range. This is an awareness building lab that will help students
understand the nature of wireless hacking processes and requirements and take on a “hacker mindset” to think like a “white ha t” to help secure IoT Security devices.

Lab - Sniffing Bluetooth with the Raspberry Pi 4.1.2.3

IEEE 802.15.4 Overview

The computational and operating power constraints of many IoT things, examples of which are shown in Figure 1, required new wireless protocols to be developed to
enable things to communicate on networks. Because the fundamental communication model of the IoT is M2M, most traffic is uplo aded to the network at configurable
regular intervals. In addition, the data that is transmitted on the network by individual things can be very small, depending on the type of thing. The IEEE 802.15.4 protocol
was originally developed for use in personal area networks (PANs). However, it has become popular in a wide range of applications, including IoT WSNs in which devices
may be operating on limited battery power.

As shown in Figure 2, 802.15.4 consists of media access layer (MAC) and physical layer (PHY) and specifications. Because it a dheres to this layered architecture,
developers have been able to create diverse upper-layer protocols on the same 802.15.4 foundation. For example, ZigBee, Thread, and 6LoWPAN all run on top of
802.15.4.
IEEE 802.15.4 Device Roles

As shown in the figure, 802.15.4 devices can operate in several roles:

 Full Function Device (FFD) – This can operate as a PAN coordinator and communicate with any other device.

 Personal Area Network (PAN) Coordinator - One FFD is designated as the PAN coordinator for the WSN.

 Reduced Function Device (RFD) – These are extremely simple devices that can only communicate with FFDs or the PAN coordinator. RFDs can never act as
the coordinator.
IEEE 802.15.4 Topologies

IEEE 802.15.4 devices can form the following wireless topologies, as shown in the figure:

Star Topology

In the star topology, communication is established between devices and a single central controller, called the PAN coordinato r. The PAN coordinator may have a fixed
power supply, while the other devices will most likely be battery powered. Applications that benefit from this topology include home automation, PC peripherals, toys, and
games. After an FFD is activated for the first time, it may establish its own network and become the PAN coordinator. Each star network chooses a PAN identifier which is
not currently used by any other network within the radio sphere of influence. This allows each star network to operate indepe ndently. Alternatives to the star topology are
considered peer-to-peer topologies because connections can be formed between FFD and RFD nodes until the PAN node is eventually reached.

Mesh Topology

In a mesh topology, there is also one PAN coordinator. In contrast to the star topology, any device can communicate with any other device as long as they are in range of
one another. A mesh network can be ad hoc, self-organizing, and self-healing. Applications such as industrial control and monitoring, wireless sensor networks, asset and
inventory tracking would benefit from such a topology. RFDs do not have the capability of relaying messages; therefore, they must be able to connect to an FFD or PAN.

Cluster Tree Topology

Cluster-tree topology is a special case of a mesh network in which most devices are FFDs. An RFD may connect to a cluster-tree network as a leaf node at the end of a
branch. Any of the FFDs can act as a coordinator and provide synchronization services to other devices and coordinators. Only one of these coordinators is the PAN
coordinator.

The role of the PAN coordinator as a point of concentration for a potentially large number of 802.15.4 nodes makes it an essential competent of the WSN. It should be
protected from physical threats such as disconnection and tampering. In addition, it should be monitored for indications of c ompromise.
IEEE 802.15.4 Security

Because 802.15.4 operates at the OSI physical and data link layers, it is largely concerned with the security of the wireless frames. There are four basic security services
performed at the data link layer:

 Access control – This service prevents unauthorized devices from joining the network.

 Message integrity – This service protects against alteration of data while it is in transit by using an encrypted cryptographic key. This key is sometimes referred
to as a message authentication code.

 Message confidentiality – This service prevents threat actors from reading the transmitted data. Message data payloads are encrypted to protect the
confidentiality of the message.

 Replay protection - Legitimate messages can be captured and sent out on the network at a later time. Because the messages are authenticated, they may be
accepted by the relevant hosts. If these messages are replayed with great frequency, network performance can be degraded to t he extent that legitimate data
cannot reach the gateway. Because intermediate devices may also be constrained systems, device battery power can also be depleted.

The 802.15.4 protocol provides security functionality in the form of security suites that can be specified by the overlaying application layers. The suites are shown in Figure
1. Each security suite offers different encryption and authentication schemes with different key lengths.

Note that 802.15.4 uses symmetric key cyphers for encryption. Symmetric key cyphers are inherently less secure then asymmetric, or public key, cryptography. In
symmetric encryption, all devices on the network must know the key and the key is used for both encryption and decryption, as shown in Figure 2. In order for the key to be
pre-shared, it is frequently encrypted with another key, which may need to be programmed into the device. This hard-coded initial key is necessary, otherwise the data
transmission encryption key would need to be shared in plaintext. Because all devices in the network require the same key, if that key is compromised, the security of all
data transmitted on the network is at risk.

To provide flexibility to the 802.15.4 network, multiple security suites and variations may be used in the same network. To t rack this, each node must maintain an access
control list (ACL) which is a table of security information for every node that it communicates with. This ACL is used to authenticate devi ces and keep track of security keys
and other security values.
Mesh Protocols that Use 802.15.4

The following protocols are built on top of IEEE 802.15.4:

 6LoWPAN – This protocol provides IPv6 services to low power devices in PANs, as the name implies. It can be added to other protocol stacks such as Zigbee
and Thread. It provides header compression and IPv6 addressing services.

 Zigbee – This is a simple and inexpensive group of upper-level wireless communication protocols that implement small lower-power PANs. It is widely
implemented in home automation, medical device data collection, and various other applications. It adds an optional security layer, a network layer including
routing, and an application layer to the IEEE 802.15.4 PHY and MAC layers.

 Thread – This is a wireless mesh protocol built specifically for IoT home networks that uses IPv6 for addressing and 6LoWPAN as the foundation.

 WirelessHART – This is an international wireless specification (IEC 62591) for the Industrial Internet of Things (IIoT). It is built on an 802.15.4 mesh network.
WirelessHART adds enhanced security and other features to the upper layers, including the HART application layer, to enhance its value in industrial
applications.

 ISA 100.11a – This is a U.S. standard for communication on the IoT. Unlike WirelessHART, it does not stipulate an application layer and uses 6LoWPAN and
User Datagram Protocol (UDP) for its network and transport layers.

Other Wireless Options

Other wireless protocols have been developed that support low power wide area networks (LPWAN). LoRa is one of a number of LPWAN technologies and has become
popular due to its low cost and wide implementation.

LoRaWAN

The Things Network is an international organization which enables development of IoT proof -of-concept systems using the LoRa radio physical layer and LoRaWAN data
link, and network layer elements of the protocol stack. The Things Network encourages individuals to create and maintain their own LoRaWAN gateways which are shown
in the figure.

Click here for more information on The Things Network.

Cellular

Cellular data standards, collectively known as 3GPP, are also implemented to extend IoT networks, but often with devices that have a fixed power supply. Current cellular
data services are not well suited to IoT applications due to power constraints. The fifth generation (5G) cellular specifications include LTE Advanced for Machine-Type
Communication (LTE MTC). This technology includes features that greatly improve power consumption while providing simplified device capability for small periodic data
transmission. Narrowband IoT (NB-IoT) is a low-power low-bandwidth protocol especially for indoor applications. It uses a portion of a wireless LTE carrier's frequency
spectrum.

IoT Communication Layer Vulnerabilities

Many constrained devices will not support a full Transport Control Protocol/Internet Protocol (TCP/IP) stack; therefore, gateways often provide IP services to enable sensor
data to be sent for processing by data analysis and control applications.

The main purpose of the IoT is to transmit, store and analyze data over IP networks; therefore, IP security is a serious concern. Elements of the IoT attack surface that will
have IP vulnerabilities, as shown in the figure, include:

 The sensor network

 The IoT gateway

 The enterprise IT network (Cisco 829 router in the figure)

 The uplink to the internet

IoT devices that have direct internet connections are also a serious concern, as illustrated by the Mirai botnet attacks.

The IoT gateway is vulnerable to attack, as are the devices that are responsible for passing data on to the network. Each IP interface between elements of the
communication channel is also vulnerable to attack. This includes the interface to the cloud applications across the internet , as shown in the figure.
Common IP Vulnerabilities

There are different types of attacks targeting IP. These are some of the more common IP-related attacks:

 DoS attacks - Threat actors attempt to prevent legitimate users from accessing information or services. This could prevent users from accessing IoT controller applications.

 DDoS attacks – This attack is similar to a DoS attack, but features a simultaneous, coordinated attack from multiple source machines. As in the Mirai Botnet, thousands of
vulnerable IoT devices can be enlisted to launch potentially devastating DDoS attacks.

 ICMP attacks - Threat actors use Internet Control Message Protocol (ICMP) echo packets (pings) to discover subnets and hosts on a protected network, to generate DoS flood
attacks, and to alter host routing tables.

 Address spoofing attacks - The threat actor puts the source IP address in a packet to masquerade as a different source, tricking the destination into believing the packet came
from a legitimate source. Especially concerning is the spoofing of IoT IP gateway devices. Such attacks to can expose large amounts of data to loss, alteration, or falsification.

 Man-in-the-middle attack (MITM) - Threat actors position themselves between a source and destination to transparently monitor, capture, and control the communication. They
could simply eavesdrop by inspecting captured packets or alter packets and forward them to their original destination. In the IoT addition of a rogue device that masquerades as
a legitimate member of an IoT network can result in significant data theft or falsification.

 Session hijacking - Threat actors gain access to the physical network, and then use an MITM attack to sniff a valid token for access to a web server.
DoS Attacks

DoS is one of the most common types of attacks. The goal of a DoS attack is to prevent legitimate users from gaining access to websites, email, online accounts, and other services.

There are two major sources of DoS attacks:

 Maliciously Formatted Packets – Threat actors craft a maliciously formatted packet and forward it to a susceptible host, causing it to crash or become extremely slow.

 Overwhelming Quantity of Traffic – Threat actors overwhelm a target network, host, or application, causing it to crash or become extremely slow.

A DDoS attack is similar in intent to a DoS attack, except that a DDoS attack is larger because it originates from multiple, coordinated sources. DDoS attacks introduced new terms such
as botnet, handler systems, and zombie computers. Click Play in Figure 1 to view a simple animation of a DDoS attack.

Another type of DDoS attack is shown in Figure 2. This scenario is similar to that used by the Mirai Botnet attack. This attack could proceed as follows:

1. The threat actor (botmaster) builds or purchases the use of a botnet of zombie hosts. The command-and-control (CnC) server communicates with zombies over a covert channel using
Internet Relay Chat (IRC), Peer-to-Peer (P2P), Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), or secure HTTP (HTTPS).

2. Zombie computers continue to scan and infect more targets to create more zombies.

3. When ready, the botmaster uses the handler systems to make the botnet of zombies carry out the DDoS attack on the chosen target.

In Figure 2, the threat actor communicates with the zombies using the CnC server to launch a DDoS attack against the victim's infrastructure.

Bots have a worm-like ability to self-propagate but they can be used for other purposes:

 Log keystrokes

 Gather passwords

 Capture and analyze packets

 Gather financial information

  Launch DoS attacks

 Relay spam

 Open back doors on the infected host

There are many potential sources of DoS and DDoS attacks. While DDoS attacks are very easy to detect, they are hard to combat. Insecure IoT devices have been exploited to increase
the size of botnets exponentially.

Insecure IoT devices have been enrolled as bots in massive DDoS attacks. Threat actors have been able to exploit password vulnerabilities to copy malicious software onto thousands of
internet-connected devices. These devices were then used to attack websites. The sheer number of IoT devices, and the very serious sec urity vulnerabilities in many of them, make IoT
devices a very attractive target for botnet DDoS attacks.

Amplification and Reflection Attacks

Threat actors often use amplification and reflection techniques to create DoS attacks. The example in the figure illustrates how an amplification and reflection technique called a Smurf
attack is used to overwhelm a target host:

1. Amplification - The threat actor forwards ICMP echo request messages that contain the source IP address of the victim to a large number of hosts.

2. Reflection - The hosts all reply to the spoofed IP address of the victim to overwhelm it.

Note: Newer forms of amplification and reflection attacks such as DNS-based reflection and amplification attacks and Network Time Protocol (NTP) amplification attacks are now being
used.

Threat actors also use resource exhaustion attacks to consume the resources of a target host to crash it, or to consume the resources of a network to adversely affect its operation. These
types of attacks may also deplete the batteries of IP-capable smart things.

ICMP Attacks
The Internet Control Message Protocol (ICMP) was developed to carry diagnostic messages and to report error conditions when routes, hosts, and ports are unavailable. ICMP messages
are generated by devices when a network error or outage occurs. The ping command is a user-generated ICMP message that is called an echo request. An echo request is used to verify
connectivity to a destination.

Threat actors use ICMP for reconnaissance and scanning attacks. This enables them to launch information-gathering attacks to map out a network topology, discover which hosts are
active (reachable), identify the host operating system (OS fingerprinting), and determine the state of a firewall.

Threat actors often use ICMP to create DoS attacks. For example, threat actors use ICMP messages to significantly saturate and slow down the target device in a type of DoS attack
called an ICMP flood attack, as shown in the figure.

Elements of the IoT communication network that have IP addresses are susceptible to ICMP attacks.

Address Spoofing Attacks

IP address spoofing attacks occur when a threat actor creates packets with false source IP address information. These packets help the threat actor to either hide the identity of the
sender or to pose as another legitimate user. The attacker can then gain access to otherwise inaccessible data, or circumvent security configurations. Spoofing is usually incorporated into
another attack such as a Smurf attack.

Spoofing attacks can be conducted as follows:

 Non-blind spoofing - The threat actor can see the traffic that is being sent between the host and the target. Non-blind spoofing is used by the threat actor to inspect the reply
packet from the target victim. Reasons for non-blind spoofing include determining the state of a firewall, TCP sequence-number prediction, or hijacking an authorized session.

 Blind spoofing - The threat actor cannot see the traffic that is being sent between the host and the target. Blind spoofing is used in DoS attacks.

Media Access Control (MAC) address spoofing attacks are used when threat actors have access to the internal network. Threat actors alter the MAC address of their host to match
another known MAC address of a target host, as shown in Figure 1. The attacking host then sends a frame throughout the networ k with the newly-configured MAC address. When the
switch receives the frame, it examines the source MAC address. The switch overwrites the current content-addressable memory (CAM) switching table entry and assigns the MAC
address to the new port, as shown in Figure 2. It then forwards frames destined for the target host to the attacking host.

Application or service spoofing is another spoofing example. A threat actor can connect a rogue DHCP server to create an MITM condition. When this occurs, a rogue DHCP server is
used to respond to legitimate requests with inaccurate information and potentially redirecting users to an incorrect default gateway or DNS server that can be used for malicious purposes.

Mitigation techniques such as DHCP snooping and Dynamic ARP Inspection (DAI) can be used to mitigate IP and MAC address spoofing. Both of these are beyond the scope of this
course.
TCP Vulnerabilities

Like IP, TCP is also vulnerable. TCP provides the following services:

 Reliable delivery - Reliable communication is the most important benefit of TCP. TCP incorporates acknowledgments to guarantee delivery, instead of relying on upper-layer
protocols to detect and resolve errors. If a timely acknowledgment is not received, the sender retransmits the data. Requiring acknowledgments of received data can cause
substantial delays.

 Flow control - TCP implements flow control to address delays. Rather than acknowledge one segment at a time, multiple segments can be acknowledged with a single
acknowledgment segment.

 Stateful communication - TCP stateful communication between two parties happens by way of TCP three-way handshake. Before data can be transferred using TCP, a three-
way handshake opens the TCP connection. If both sides agree to the TCP connection, data can be sent and received by both parties using TCP.

Examples of application layer protocols that make use of TCP reliability include HTTP, Secure Socket Layer/Transport Layer Security (SSL/TLS), File Transfer Protocol (FTP), DNS zone
transfers, and others.

As shown in the figure, the protocols at the Transport Layer of the OSI model use port addressing to enable multiple conversations to be tracked and connected with the correct
applications. Well-known port numbers identify commonly used applications. However, an application such as Telnet can be assigned any port number within the range of open ports.
Because Telnet is not secure, it should not be left running on IoT devices. In addition, other undesirable applications and s ervices, including malware, can use obscure port numbers. It is
important that any smart object be evaluated regarding which communication protocols are enabled on it by default and which listening ports are open.

The TCP protocol is vulnerable to port scanning. Network applications use TCP or UDP ports. Threat actors conduct port scans of target devices to discover which services they offer.
Port scanners can supply very detailed information about the services that are running on a networked device. These services can be vulnerable to exploitation by threat actors.
TCP SYN Flood Attack

The TCP SYN Flood attack exploits the TCP three-way handshake. As illustrated in Figure 1, the threat actor continually sends TCP SYN session request packets with a randomly
spoofed source IP address to an intended target. The target device replies with a TCP SYN-ACK packet to the spoofed IP address and waits for a TCP ACK packet. Those responses
never arrive. Eventually the target host is overwhelmed with half-open TCP connections and denies legitimate TCP traffic.

A TCP reset attack can be used to terminate TCP communications between two hosts. Figure 2 displays how TCP uses a four-way exchange to close the TCP connection using a pair of
FIN and ACK segments from each TCP endpoint. A TCP connection can also be torn down when it receives an RST bit. This is an abrupt way to tear down the TCP connection and
inform the receiving host to immediately stop using the TCP connection. A threat actor could launch a TCP reset attack and send a spoofed packet containing a TCP RST to one or both
endpoints.

TCP session hijacking is another TCP vulnerability. Although difficult to conduct, it enables a threat actor to overtake an a lready-authenticated host as it communicates with the target.
The threat actor would have to spoof the IP address of one host, predict the next sequence number, and send an ACK to the other host. If successful, the threat actor could send data to
the target device, but not receive data from it.
UDP Vulnerabilities

UDP is a simple protocol that provides the basic transport layer functions. UDP is commonly used by DNS, Trivial File Transfer Protocol (TFTP), Network File System (NFS), and Simple
Network Management Protocol (SNMP). It is also used with real-time applications such as media streaming or VoIP. UDP is a connectionless transport layer protocol. It has much lower
overhead than TCP because it is not connection-oriented and does not offer the sophisticated retransmission, sequencing, and flow control mechanisms that provide reliabilit y. The UDP
segment structure is much smaller than TCP’s segment structure. The figure shows the UDP segment structure.

This does not mean that applications that use UDP are always unreliable, nor does it mean that UDP is an inferior protocol. It means that these functions are not provided by the transport
layer protocol and must be implemented elsewhere if required.

The low overhead of UDP makes it very desirable for protocols that make simple request and reply transactions. For example, using TCP for DHCP would introduce unnecessary network
traffic. If there is a problem with a request or a reply, the device simply sends the request again.

UDP is not protected by any encryption. It is possible to add encryption to UDP, but it is not available by default. The lack of encryption allows anyone to look at the traffic, change it, and
send it on to its destination. Changing the data in the traffic will alter the 16-bit UDP checksum, which is mandatory when carried over IPv6. The threat actor can create a new checksum
based on the new data payload and record it in the header as a new checksum. The destination device will find that the checksum matches the data without knowing the data has been
altered.

This type of attack is not the most widely used. It is more common to see a UDP attack where all of the resources on a network are consumed. This is called a UDP flood attack. To do
this, the threat actor must use a tool like UDP Unicorn or Low Orbit Ion Cannon that sends a flood of UDP packets, often from a spoofed host, to a server on the subnet. The program will
sweep through all of the known ports trying to find closed ports. This will cause the server to reply with an ICMP port unreachable message. Because there are so many closed ports on
the server, this causes so much traffic on the segment that almost all of the bandwidth gets used. The result is very similar to a DoS attack.

Lab - Port Scanning an IoT Device

Nmap or “Network mapper” is free and open source network port scanner. It can be used to test devices such as IoT, Firewalls, etc. for open, closed or filtered ports and additionally can
provide an inventory of devices and services available on a network. Nmap uses the TCP header flag fields URG, ACK, PSH, RST, SYN, FIN shown in the diagram to accomplish its
scans as well as other protocols such as UDP, ICMP and a built-in database of known application signatures. https://nmap.org/

Lab - Port Scanning an IoT Device 4.2.2.5

Lab - Packet Crafting to Exploit Unsecured Ports

Hping 3 is a network tool used to send custom built TCP/IP packets at a target to illicit a response. Like Nmap a network mapper tool hping3 can uses the TCP header flag fields URG,
ACK, PSH, RST, SYN, FIN to accomplish its scans as well as other protocols, such as UDP and ICMP. Unlike Nmap, however, hping3 can use its ability to craft packets to attack a target
as well.

Lab - Packet Crafting to Exploit Unsecured Ports 4.2.26

Security for IoT Communication Protocols

The figure shows the Cisco security artichoke concept. The artichoke’s layers are armor-like petals. It is a good image to consider when thinking of IoT security. As we know, IoT devices
must be secured physically and protected from damage, destruction, and tampering. The physical device firmware and physical i nterfaces must not be vulnerable. The first stage in
creating a threat model of IoT system security is to decompose the network communication channels by identifying the component technologies and their features, much like removing
petals from the security artichoke.

Similarly, IoT communication must also be secure. Devices that join IoT sensor and actuator networks must use robust wireless protocols. These protocols must include measures to only
allow authenticated, approved devices to join the network. In addition, the data that is transported at this layer of the network must be validated and protected from eavesdropping and
alteration.

Cryptographic approaches that protect credentials, encrypt data payloads, and create secure channels for protocol conversations are also an important part of IoT security.

Constrained devices may be limited due to the computational requirements of encryption. Low power communication technologies may not be able to support the same frequent
encryption-related negotiations between devices and gateways or application servers that more powerful devices and higher bandwidth communications permit.

The IEEE 802.15.4 protocol has several inherent weaknesses that an IoT system designer should be aware of. The AES-CTR security suite has significant weaknesses and it should be
avoided. For example, it is vulnerable to DoS attacks. Note also that IEEE 802.15.4 has an option in which no encryption is used at all.

The ACL functionality that is used to authenticate devices has several weaknesses. Devices should retain their ACL tables in low power mode. Finally, the acknowledgment mechanism is
not encrypted. It should not be used by developers, and acknowledgments, if required, should occur at the higher protocol layers.

With the enormous economic potential of the IoT, standards bodies and vendors are constantly creating new technologies to overcome these limitations. It is important that IoT system
developers be aware of not only the limitations of the technologies they choose but also the opportunities provided by emerging IoT technologies.
Isolation of IT and OT Traffic

With the convergence of IT and OT in many IoT solutions, especially in the industrial context, the enterprise attack surface expands dramatically. There are many benefits of this
convergence. However, it can mean adding large numbers of constrained devices, legacy computer hardware and operating systems , and immature protocols to IT networks. The
potential risks are enormous.

It is important to reduce the size of the overall attack surface by establishing smaller zones of trust through the use of firewalls and other security technologies. This will enable control of
access at Layer 3 and Layer 4 of the OSI model. This helps to ensure that a successful attack on one part of the network does not permit access to all parts of the network. Data from
multiple areas of the network may need to pass through these zones of trust. Therefore, traffic isolation techniques, such as using VLANs, is important. The figure shows traffic zoning and
isolation in an Industrial IoT architecture. Note the firewalls that isolate the enterprise IT network from the manufacturing OT network. The DMZ between them includes services that
require administration from the enterprise network but which serve the manufacturing network.

Case Study: No Isolation of IT and OT Traffic

Consider the benefits of isolating IT and OT traffic in light of the following case study.

A major retailer discovered a security breach in which personal information, including credit card numbers, was stolen from over 50 million customers. Investigation revealed that the
breach occurred due to weak security at a contracting heating, ventilation, and cooling (HVAC) company. The contractor required network access to systems at hundreds of retailer’s
locations. Security vulnerabilities in the contractor network enabled threat actors to infect the retailer point-of-sale networks with malware. The malware was used to steal customer credit
and debit card numbers.

This case illustrates two important points. First, device, network, and application security are only as strong as the weakest link, which in this case was the security of the contractor who
had access to the network. Second, the contractor should not have had access to the same network that carried confidential data. In this case, the contractor network became a part of
the retailer's attack surface, which drastically increased the vulnerability to the network. Note that the vulnerability that enabled this malware infection may have presented little risk to the
contractor but presented great risk to the retailer. The retailer eventually spent at least $200 million to resolve issues related to this breach.

At the TCP/IP protocol level of communication, only secure application layer protocols should be used. If this is not possible, then protocols with weak security should be enhanced
through other technologies. Transport security, in the form of TLS or Datagram Transport Layer Security (DTLS) should be implemented to authenticate and protect IoT data as it moves
on IP networks to IoT applications within the network or on the cloud.

Threat Model for IoT Communication Technologies

OWASP recommends guidelines to mitigate vulnerabilities for the communication channels in IoT systems, as shown in Figure 1. A threat model of these systems requires a thorough
understanding of data flows on the network and the locations of trust boundaries relative to the flows. Trust boundaries are areas in the communication system where data could come
from an untrusted source. Figure 2 shows a simple data flow diagram for an online store that includes trust boundaries enforc ed by firewalls. Crossing a trust boundary means that the
level of trust and reliability of data has changed.

Recall that creating a threat model includes using the STRIDE model to identify the threats and the DREAD model to score the risk of each threat. The results of this rating will provide a
prioritized risk model to guide efforts to mitigate threats.
IoT Communications Checklist

When evaluating devices, systems, and technologies for an IoT application, be sure to investigate and verify the following in regards to the IoT communications layer:

Verify 802.15.4 security:

 AES-CTR mode is not used.

 Both encryption and authentication are used.

 Acknowledgments are not relied upon in this channel.

 Integrity of key management.

 ACLs are maintained in low-power mode.

 The latest version of the protocol is in use.

Verify TCP/IP Communication security:

 All data flows are thoroughly and accurately documented.

 Data flow is adequately protected at trust boundaries according to specific vulnerabilities.

 Firewalls or other systems segregate traffic in different trust zones.

 VPNs (or other means) segregate potentially insecure traffic from mission critical traffic.
  Transport encryption is utilized to ensure confidentiality, integrity, and authenticity.

Packet Tracer - Threat Modeling at the IoT Communication Layer

In this Packet Tracer, we will continue with the process of creating a threat model for the home automation IoT system that was started in the Chapter 3 Lab - Threat Modeling at the
Physical Device Layer. You may want to review the description of the system and Packet Tracer file from that lab.

In this lab, you will be working with the communication layer of the IoT attack surface. Remember that our home automation network differs somewhat from the PT network. The home
automation network that we are working with does not use Wi-Fi as the wireless protocol for the sensors and actuators. Instead, you will choose another protocol for the IoT sensor-
actuator-controller network such as Zigbee or Z-Wave. The controller handles local communication with the various wireless networks in the house and the internet. It serves as the IP
gateway for the IoT sensor-actuator network. It also functions as a router that enables communication between the local wireless LAN and the internet.

Packet Tracer - Threat Modeling at the IoT Communication Layer Instructions

Packet Tracer - Threat Modeling at the IoT Communication Layer PKA 4.3.1.6

Chapter 4: IoT Communication Layer Vulnerabilities

This chapter began by discussing the functions of the IoT communication layer. The communication layer of the IoT is responsible for the transportation of data between devices, facilities
and applications, often in the cloud. Many IoT sensor nodes are constrained in terms of resources, power, and processing. This means that communication channels will exist between
low power devices and a gateway device.

Next, the chapter detailed wireless protocols. The IoT Protocol Suite includes many wireless protocols including IEEE 802.15.4, BLE, Wi-Fi, NFC, and cellular. Bluetooth and Wi-Fi are
easy to set up, but this often sacrifices security. ZigBee, Thread, WirelessHART, ISA 100.11a, and 6LoWPAN all run on top of 802.15.4 devices which can operate as an FFD, PAN
coordinator, or RFD. The 802.15.4 protocol provides security functionality in the form of security suites that can be specified by the overlaying application layers. LoRa is one of a number
of LPWAN technologies and has become popular due to its low cost and wide implementation. Current cellular data services are not well suited to IoT applications due to power
constraints.

The next section of this chapter covered IP vulnerabilities. Elements of the IoT attack surface that will have IP vulnerabilities include the sensor network, the IoT gateway, the enterprise IT
network, and the uplink to the internet. There are different types of attacks targeting IP including DoS, DDoS, ICMP, address spoofing, MITM, and session hijacking. Threat actors often
use amplification and reflection techniques to create DoS attacks. Threat actors use ICMP for reconnaissance and scanning attacks. Spoofing attacks can be conducted as either blind or
non-blind.

The next section discussed TCP and UDP vulnerabilities. The TCP protocol is vulnerable to port scanning. TCP attacks include the TCP SYN flood, TCP reset, and TCP session
hijacking. It is possible to add encryption to UDP, but it is not available by default.

The final section of this chapter covered IoT communication security. Cryptographic approaches that protect credentials, encrypt data payloads, and create secure channels for protocol
conversations are also an important part of IoT security. It is important to reduce the size of the overall attack surface by establishing smaller zones of trust through the use of firewalls
and other security technologies. At the TCP/IP protocol level of communication, only secure application layer protocols should be used. Creating a threat model includes using the
STRIDE model to identify the threats and the DREAD model to score the risk of each threat.

OWASP Application Vulnerabilities

An application vulnerability is any weakness that a threat actor could use to compromise the security of that application. He can then use specific tools and methods to discover
application vulnerabilities such as application penetration testers, port scanners, and code checkers.

IoT devices have many different types of software such as firmware, operating systems, and applications. Any connected device is a vulnerable device. The applications that are installed
can have many different types of vulnerabilities. Threat actors look for vulnerabilities in order to gain access. These are s ome of the most widely exposed vulnerabilities, as listed by the
Open Web Applications Security Project (OWASP):

 Username enumeration – The threat actor is able to find valid usernames by interacting with the authentication mechanism of the application.

 Weak passwords – The threat actor uses default passwords which have not been changed, or sets account passwords that they choose.

 Account lockout – The threat actor attempts to authenticate which causes the account to be locked after multiple failed attempts.

 Lack of multi-factor authentication – It is easier for a threat actor to gain access when only one form of authentication is required.

 Insecure 3rd party components – As vulnerabilities are discovered, they will require patches to be installed. When components such as Secure Shell (ssh), BusyBox, or web
servers are not kept up to date, the threat actor might expose these vulnerabilities and gain access.
Local Applications

Before devices began connecting to the internet, they were relatively sheltered from attack. Threat actors had to have physical access to these devices. Now threat actors can detect
devices on the network and exploit their vulnerabilities. These are some of the most popular local exploits:

 Firmware Replacement – Updates and patches to devices are usually done remotely. If the process is not secure, the threat actor could intercept the update and install their
own malicious update. This could allow them to have full control over the device and begin attacking other devices within the system.

 Cloning – By creating a duplicate physical device, running similar software and firmware, the threat actor could replace a legitimate device. When the device is up and running,
the threat actor could then steal information, or compromise additional devices.

 Denial of Service (DoS) – The threat actor could launch a DoS attack to fill the communications channel, causing devices to respond to requests late, or not at all. Depending
on the devices, this could cause a lot of damage. Click Play in the animation to view a simple animation of a DoS attack.

 Extraction of Security Parameters – When a device is not protected properly, the threat actor may be able to extract security parameters from it such as authentication
information or security keys.

Now that these devices are accessible over the internet through communications protocols, the threat actor can attack them remotely. These are some of the most popular remote
exploits:

 Man-In-the-Middle Attack (MITM) – The threat actor gets between devices in the system and intercepts all of the data being transmitted. This information could simply be
collected or modified for a specific purpose and delivered to its original destination.

 Eavesdropping Attack – When devices are being installed, the threat actor can intercept data such as security keys that are used by constrained devices to establish
communications after they are up and running.

 SQL Injection (SQLi) – The threat actor uses a flaw in the Structured Query Language (SQL) application. This allows data theft or tampering, unauthorized access to a file
system, and other security breaches.

 Routing Attack – A threat actor could place a rogue routing device on the network, or modify routing packets to manipulate routers to send all packets to the threat actor’s
chosen destination. He could then drop specific packets, known as selective forwarding, or drop all packets, known as a sinkhole attack.

Mobile Applications

We use mobile devices to access banking information, send email and texts, store contacts and pictures of friends and family. Even though iOS and Android are relatively secure, they
can still be compromised, especially through the applications that we install on them and use on the web. Just like local applications, compromised mobile applications provide threat
actors with a way to gain access and control of mobile devices. These are some of the most widely exposed vulnerabilities:

 Insecure communication – The communication technology and channel must be secured. When there is weak negotiation, poor handshake practices, or the use of incorrect
versions of SSL, the communication is not secure.

 Insecure data storage – Many applications have access to data storage areas of mobile devices, even though they may not need it. Data storage must be secured and
applications must be tested to ensure there is no data leakage.

 Insecure authentication –Sessions must be managed properly to ensure secure authentication. Users must be identified when necessary, and their identit y must be
maintained securely.

 Improper platform usage – Mobile apps use features built into the platforms such as TouchID, Keychain, and Android intents. Should these security controls be misused,
access to the device and other apps can be compromised.

 Insufficient cryptography – The cryptography used to encrypt sensitive data must be sufficient and must be applied when necessary.
OWASP Web and Cloud Application Vulnerabilities

Web and cloud vulnerabilities are among the main sources of data breaches. More people are storing their data in the cloud, and more businesses are using cloud applications to collect,
store, and analyze data, including data from IoT devices. In order to secure these exposed applications, other security applications must be used. These include static analysis to identify
and fix vulnerabilities in applications, web application scanners to find and monitor web applications, and runtime protection to defend against attacks at the application layer in real time.
These are some of the most common web and cloud application vulnerabilities:

 Injection – An injection is where the threat actor sends a command, along with other data, to the interpreter. This is often performed on SQL, NoSQL (sometimes referred to as
“not only SQL”), Lightweight Directory Access Protocol (LDAP), and the OS. The extra data sent by the threat actor can trick the interpreter into executing commands and
access data without authorization. An injection attack will only work on an application that is vulnerable to the attack.

 XML external entities (XXE) – Incorrectly configured or old XML processors will evaluate the external references to entities that are in eXtensible Markup Language (XML)
documents. Using these external entities can disclose files and file shares, perform port scanning and code execution, or even launch a DoS attack.

 Sensitive data exposure – Often, Application Programming Interfaces (APIs) and web applications do not protect data correctly. They may not encrypt data, or correctly
exchange it with browsers. A threat actor may use this data to perform identity theft and commit fraud.

 Broken access control – If access is not configured properly, the threat actor might be able to access unauthorized data. With high enough permissions, they may be able to
modify access rights for themselves or others.

 Broken authentication – Session management and authentication can be incorrectly implemented. This allows the threat actor to discover keys and passwords, or to
masquerade as other users.

Device Management and Data Applications

There are many different types of applications in the Cloud that are used for IoT systems. IoT systems are highly distributed and can span a building, a city, or even the globe. IoT data
can be stored at the edge of the network, or in a central location. Some processing of this data takes place at the mist or fog layers by gateways and in some of the more capable sensors
and actuators. Other data processing takes place in the cloud. Sensors and actuators may be managed by these cloud-based applications.

Cloud computing applications can use incredibly large amounts of resources. Through complex computations on enormous amounts of sensor data, specific actions can be carried out by
actuators, humans can be alerted, or a database may simply be updated. These computations can be used to gain insight through cognitive and predictive analytics. They can also be
used in real time to adjust factory conditions, traffic control, or prevent an emergency. Dashboard-like cloud applications provide a presentation to humans for them to better understand
the details, as is shown in the figure. All of these transactions and data presentations must be done in a secure environment .

Guidelines for Secure Web and Cloud Applications

To ensure that cloud applications and cloud-based web interfaces are secured, follow these guidelines, as shown in the figure:

 Review all web and cloud applications for security vulnerabilities, including web interfaces and API interfaces.

 Explicitly prevent the use of weak passwords.

 Implement account lockout mechanisms to prevent brute-force attacks.

 Use two-factor authentication whenever possible.

 Always use transport encryption, such as SSH and Secure Socket Layer 3.0 (SSL). SSL 3.0 is also known as Transport Layer Security (TLS).

 Thoroughly test for SQLi, cross-site Scripting (XSS), and cross-site Request Forgery (CSRF) vulnerabilities.

 Set passwords to expire after a certain period of time.

 Force users to change the default username and password whenever possible.
Password Vulnerabilities

Threat actors know that password policy is not always followed by everyone. They will try to crack passwords to gain access into the target system. The biggest problem with the
conventional username and password combination is the user. Some users must remember many different passwords on a daily basis. Passwords should be easy to remember and
difficult to crack, but most people only care about having passwords that are easy to remember.

Most people are not educated about using strong passwords. Most passwords are easy to guess, seldom changed, reused multiple times, and written down where they can be easily
discovered. Many times, users do not even change the default password. Default credentials for thousands of devices are freely available on the internet. Threat actors use this
information to compromise and take over systems.

Web Frontend Vulnerabilities

Web frontend vulnerabilities apply to the apps, APIs, and services. The most significant vulnerabilities include XSS, SQLi, a nd broken authentication. There are many more vulnerabilities
listed in the OWASP top 10. Every developer should understand the basics of web security when adding features, fixing bugs and updating application code. The better that everyone
understands security, the less impact data breaches and attacks can cause. The three most common web frontend vulnerabilities are discussed below.

Cross-site Scripting

In a XSS attack, the threat actor injects code, most often JavaScript, into the output of a web application. This forces client-side scripts to run the way that the threat actor wants them to
run in the browser. For example, the threat actor could execute scripts in the user’s browser to redirect traffic to malicious web pages, or hijack a user session by stealing cookies, as
shown in Figure 1. This type of manipulation can be performed every time a certain event is performed, such as a mouse over, or every time that the page is loaded. Vulnerable web
applications are the target of XSS attacks, not the user.

As an example, a banking website may have an XSS vulnerability. The threat actor exploits this vulnerability and injects JavaScript through the front-end interface in a feedback field.
Instead of feedback about the web page or the bank, they provide the malicious code necessary to replace the login box where a user would type their username, password, pin code,
and answers to secret questions. When the user visits the legitimate banking web site, he enters his credentials into a text field created by the threat actor, who then collects the login
information. They are now free to log in as the user and take their money and change their contact and login information. Bec ause the code runs in the user’s session, the threat actor can
bypass the normal security restrictions required to perform actions as that user.

SQL Injection

SQLi targets the SQL database itself, rather than the web browser, as shown in Figure 2. When the vulnerability is exploited, a threat actor can control an application’s database. The
threat actor can collect, change, or delete data, or even change how the database uses the data. If the root credentials can be found, then the threat actor can take complete control of the
database and program how it behaves.

Similar to XSS, SQLi is where the threat actor injects code into text entry fields that will be used to query the SQL database. Instead of using JavaScript, malicious SQL commands are
used to trick the database into returning unauthorized records and other data. The reason that SQLi works so often is that the application does not sanitize the untrusted data that is
entered in the web page fields. Many organizations are vulnerable because their code does not sanitize the queries properly.

Broken Authentication

Broken authentication includes both session management and protecting the identity of a user. A threat actor can hijack a ses sion to assume the identity of a user especially when
session tokens are left unexpired. The threat actor can access usernames and passwords using brute force attacks, dictionary attacks, and default credential lists when credentials are
not protected.
Threat Modeling at the Application Layer

Security should be built in to applications from the start. Threat modeling can help to make sure applications are as secure as they can be.

For the Application Layer of the IoT Protocol Suite, Threat Modeling focuses on Steps 3, 4 and 5, as shown in the figure.

Step 3: Decompose the Application

This step is designed to gain a basic understanding of the application and its interaction with external entities. Use cases are created to see how it is used and identify entry points where
the threat actor might interact with the application. This step is also used to create data flow diagrams (DFDs). A DFD shows the many paths through the system and shows the privilege
boundaries. This step provides a good understanding of what assets the threat actor might want and in determining what access rights are granted to external entities by the application.

Step 4: Identify and Rate Threats

This step is used to categorize threats. Specific categorizations such as STRIDE and DREAD used in this course help vulnerabi lity assessors identify and rate threats from the threat
actor’s perspective.

Step 5: Recommend Mitigation

In some cases, a threat may be mitigated with a countermeasure. Using the risk ranking of the threats, the threats are ranked from highest to lowest risk to prioritize which threats should
be handled first. This risk ranking is usually aligned to the business impact of the threat. In some cases, the risk may be acceptable because the business impact is lower than the cost of
the countermeasure. It might also be possible to completely remove the risk, such as no longer using a vulnerable application.
Lab - Use OpenVAS for Vulnerability Assessment

Open Vulnerability Assessment System (OpenVAS) is a framework that provides services and tools for vulnerability scanning and management. Network Vulnerability Tests (NVT) are
used by OpenVAS to checking existing security issues. NVTs are developed based on Common Vulnerabilities and Exposures (CVE).

CVE is a category of known security threats. The threats are divided into two categories: vulnerabilities and exposures. The entries provide an identification number, a description, and
public references regarding the cybersecurity vulnerabilities. The goal of the CVE is to allow the sharing of data easier acr oss different vulnerability tools, repositories, and services. A
CVE is associated with a Common Vulnerability Scoring System (CVSS).

The CVSS provides an open and standardized way for scoring. The scoring system allows an organization to prioritize which vulnerabilities to fix and access the impact of the
vulnerabilities on their systems.

In this lab, you will use OpenVAS to perform a vulnerability scan on the Metasploitable VM and review the vulnerability assessment report from the scan.

Lab - Use OpenVAS for Vulnerability Assessment 5.1.2.7

Lab - Challenge Passwords with Kali Tools

There are numerous Kali tools used to challenge passwords. It is very likely you have already seen and/or used John the Ripper (john). John is a very powerful tool, but there are other
tools that might be more appropriate to use depending on the situation. It is important to be aware of as many tools as possible so you can select the most appropriate tool for the task at
hand.

Hashcat is a powerful offline password challenging tool. It offers various attack modes including dictionary, brute force, and combination attack. Hashcat offers different features and has
other advantages in comparison to John the Ripper that you may want to know how to use. For the purposes of this lab, we will use the combination attack based on the available
information. We will be using a combination attack to recover the password of a serious golf fan.

In this lab, you will explore tools that are available in the Kali VM to challenge passwords.

Lab - Challenge Passwords with Kali Tools 5.1.2.8

Lab - Web Application Vulnerability

Web application vulnerabilities involve system flaws or weakness in a web application. These vulnerabilities can occur due to form inputs that have not been validated or sanitized,
misconfigured web servers, and application design flaws. The attackers can exploit these weaknesses to compromise the application's sec urity. The attacks can use tools, such as Nmap
and Skipfish, to scan for weaknesses in an application. Nmap is a network exploration tool that can provide information on open ports and operating system. Skipfish is a web application
security scanner. The result provides an interactive sitemap by doing recursive crawl and dictionary-based probes.

In this lab, you will exploit a misconfiguration in a simple Python application by performing a SQL injection tool, sqlmap that is available in the IoTSec Kali VM. The tool, sqlmap, is an
automatic SQL injection tool. You will discover web application weakness and apply the correction in the Python script that will sanitize application input.

Lab - Web Application Vulnerability 5.1.2.9

Role of Messaging Protocols

IoT devices use messaging protocols to agree on how they will communicate. A message protocol defines the functions and rules for transmitting messages between devices.

Hypertext Transfer Protocol (HTTP) along with Representational State Transfer (REST) APIs are often used for web application communications. However, HTTP messages have high
overhead. This makes HTTP inefficient for IoT devices for the following reasons:

 IoT devices are resource-constrained and may not have the ability to install HTTP services.

 HTTP is an inefficient messaging protocol that uses more resources.

 HTTP does not include a reliable publish and subscribe model.

 HTTP has no mechanism for preserving or retaining messages.

 HTTP has no method for informing users that the device is no longer available.

Click Play in the figure to see an animation of the HTTP protocol process.

IoT Messaging Protocols

There are many different messaging protocols in use in the IoT. Some were developed before the IoT and some were developed specifically for use in the IoT. Because there are many
different requirements of connected devices, it is unlikely that one single protocol will dominate. These are some of the more common IoT application layer protocols in use today:
  MQTT – Message Queueing Telemetry Transport uses the Transport Control Protocol (TCP) and requires a message broker.

 CoAP – Constrained Application Protocol is a document transfer protocol that uses the User Datagram Protocol (UDP).

 XMPP – Extensible Messaging and Presence Protocol uses TCP and was originally designed for instant messaging.

Other IoT application layer protocols not shown in the figure include:

 DDS – Data Distribution Service uses TCP and is designed to connect devices to other devices.

 AMQP – Advanced Message Queuing Protocol uses TCP and is designed to connect servers together.

These are some important characteristics for IoT protocols to consider:

 Power consumption – Many IoT devices are not connected to a permanent power supply. The more power that is used, the higher the likelihood that the device will go offline.

 Speed – This is the amount of data that can be transferred over a period of time. Increased bandwidth reduces contention, and allows the network to add more devices.

 Latency – This is the amount of time it takes for messages to be sent and received. For real-time applications, this is more of a factor.

 Security – When there are sensitive connections or sensitive data transfers, the data, connection, or both must be secured.

In this chapter, we focus on MQTT and CoAP.

MQTT

MQTT was developed by IBM specifically for the IoT, where lightweight machine to machine (M2M) communications are used. MQTT has a short message header and a short
specification containing only CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, and DISCONNECT message types.

MQTT uses a type client-server model called publish-subscribe. Clients connect to the server called a broker. Typically, a client either publishes a topic or subscribes to a topic. A topic is
any specific type of message, like humidity, temperature, or light. The broker manages all communications between publishers and subscribers.

In the figure, the sensor is publishing data for a temperature topic to the broker. Whenever the broker receives the data from the publisher, it forwards the message to the two clients that
are subscribers. The broker keeps track of all of the topics to which clients are subscribed.

MQTT is designed to collect data from many devices and deliver it to the IT infrastructure. It is used when there is a need to monitor many small devices and have their data available in
the cloud to trigger M2M decisions. For example, moisture sensors on a very large farm would be set to a threshold to determi ne when to irrigate specific sections of the farm.

The publish-subscribe model works well in the IoT for two important reasons. First, clients that are not connected will not prevent the e ntire system from working. This is because clients
are independent of one another. Also, because this model keeps traffic to a minimum, it helps to reduce the amount of power used by IoT devices during communication.

MQTT uses a hierarchical system for organizing topics. This allows clients to receive many messages when they are subscribed to a topic with sub-topics. A topic consists of one or more
topic levels with each level separated by a forward slash, for example:

plant2/building3/floor3/room2/temperature

MQTT has a few features that make it especially friendly for use on IoT networks. An option called last will and testament allows a device to provide a custom message to the broker that
is sent to all subscribers when the device unexpectedly disconnects. Also, retained messages is an option that can be used to provide immediate status updates to any newly subscribed
client. This ensures that each client has the most current data as soon as it subscribes to a topic.
CoAP

Like MQTT, CoAP is a lightweight protocol designed to be used for M2M communication. CoAP uses UDP instead of TCP which makes for much smaller pac kets than MQTT. CoAP
needs no centralized device in a broker role as does MQTT; sensors and other nodes may connect with and publish to each other. It also supports multicast transmissions which makes
resource discovery and updates more efficient.

CoAP uses a client-server model where clients request from servers and servers respond to clients. CoAP was designed to work with HTTP, as shown in the figure. CoAP supports the
four HTTP methods: GET, POST, PUT, and DELETE. In addition, CoAP has the ability to observe a resource. When a CoAP GET request has the observe flag set, the server can reply to
the client even after the transfer is over. This allows the client to inform servers of state changes as they happen, which is crucial for many IoT devices.

When choosing to implement either MQTT or CoAP, it will depend on the application. MQTT is used mostly for multiple clients where live data is the only data. Although MQTT does
support persistence, it is most often better to use CoAP for this purpose. CoAP is commonly used when the state of an IoT device changes and that changed state needs to be reported.

Other Application Messaging Protocols

A few other IoT protocols in use include the following:

XMPP

XMPP was originally created as an instant messaging protocol for the Jabber application. It uses XML and runs over TCP. XMPP uses an addressing scheme (name@domain.com)
which helps to simplify connections. XMPP is used to poll devices on demand for updates. In the IoT, XMPP is an easy way to address devices and helps when data is sent between
distant points. XMPP operation is shown in Figure 1.

XMPP can be easily scaled, offers security, and supports many different communication types. These include socket connections, Bidirectional streams over Synchronous HTTP (BOSH)
and Efficient XML Interchange (EXI). This makes it ideally suited for IoT applications. XMPP is a good choice in protocols to connect home IoT devices to a web server so that they can be
monitored from a smartphone or other device.

DDS

The main purpose of DDS is M2M connections, specifically for devices that directly use device data. Devices that measure real-time data in microseconds are good candidates for using
DDS. DDS can filter and select what data goes where and can deliver millions of messages per second to multiple receivers eff iciently and simultaneously, as shown in Figure 2. There
are also lightweight implementations of DDS that can be used on constrained devices.

DDS is the only protocol that can deliver the reliability and speed needed to build complicated real-time applications. DDS is rooted in the military and is used in their systems. In addition,
DDS is used in medical imaging, automotive testing, financial trading, air traffic control, and complicated high data use IoT networks.

AMQP

AMQP is not always the first choice when implementing an IoT network. But when reliability is the most important factor, it is a good choice. AMQP uses queues to send messages
between servers, as shown in Figure 3. AMQP uses TCP for reliable point-to-point connectivity and endpoints must acknowledge that they received each and every message.
Lab - Hacking MQTT

Message queuing telemetry transport (MQTT) is publish/subscribe, extremely simple and lightweight messaging protocol. It is designed for IoT devices and uses minimal bandwidth and
device resources. MQTT is an ideal protocol for machine-to-machine (M2M) communications. MQTT uses the reserved TCP/IP port 1883 by default. When using MQTT over SSL, it uses
the registered TCP/IP port 8883.

The MQTT protocol uses topics as a communication avenue. MQTT topics uses a hierarchal structure, similar to a file path. The structure is used for message filtering and routing. As an
MQTT client, you can subscribe to one topic or multiple topics using wildcards, # and +. MQTT protocol does not allow publishing to topics using wildcards. You can only publish to an
individual topic. For example, the published topic can be the output data from sensor.

The MQTT broker is the server that handles the communications between the publisher and subscriber. The broker is responsible for receiving and filtering all the messages and deciding
who are interesting in the messages and sending the messages to the subscribed clients.

In this lab, you will setup an MQTT infrastructure that includes a broker, publisher, and subscriber. You will also publish MQTT messages and subscribe MQTT topics. You will also secure
the MQTT communications using username and password credentials and transport layer security (TLS). Furthermore, you will attack the MQTT infrastructure by trying to intercept the
MQTT communications between the clients and server.

Lab - Hacking MQTT 5.1.3.7

A Note About UPnP

Universal Plug and Play (UPnP) was developed in an effort to help users more easily set up and connect network-enabled devices such as printers, video game consoles, and smart TVs.
UPnP is a set of protocols that allows devices to detect the presence of other UPnP-enabled devices on the network with no intervention from the user. UPnP automatically configures the
correct way to communicate with the device and sets up the communication pathway. UPnP was designed to be used on residential networks where the user may not know how to
correctly configure the network or a device to find other resources. The multicast nature of UPnP consumes far too many resources on networks that contain many UPnP-enabled
devices, such as enterprise networks.

The problem with UPnP is that it has major security flaws. Should one of the devices on your network be exploited, t hese security flaws might give the threat actor remote control of
devices such as cameras, lights, thermostats, or even security systems. A threat actor would be able to then compromise more devices, steal passwords and other personal data. She
might even use the devices on your network to begin a DDoS attack on a remote server, among other nefarious acts.

Home routers supporting UPnP can be fooled by malware to redirect DNS traffic to a rogue server using a single UPnP request. After being redirected, the threat actor could create
malicious DNS entries that misdirect legitimate traffic to malevolent websites. Entering the URL to your bank’s website could result in a redirection to a spoofed website set up by the
threat actor.
Lab - UPnP Vulnerabilities

In this lab, you will turn a Raspberry Pi into a working router. Unlike most routers, the Pi will connect to the network wirelessly using PL-App, and route to a local Ethernet network. A client
will be added and connectivity will be tested. The client will then use Universal Plug and Play (UPnP) to open a communication port through the router without authentication.

Lab - UPnP Vulnerabilities 5.1.3.9

Securing MQTT

Although MQTT is a great protocol for the IoT, it is not secure. Connecting all these devices together and brokering messages exposes sensitive data. This data is not always meant to be
available to the public and should be protected. This exposure of data goes well beyond privacy in the IoT. Real machines can become compromised, causing data exposure, physical
harm, or even death to people.

It is not always practical to employ cryptographic algorithms to secure data on constrained IoT devices. The devices may need much more power, CPU processing, and memory than they
have in order to encrypt and decrypt data. However, some form of security should be included in IoT application development. For MQTT, the security implementation must be based on
the capabilities of the broker and the clients. Recall that clients typically have the role of MQTT publisher or subscriber. The server has the role of MQTT broker.

Generally, for a broker, there are three ways a client can authenticate:

 Client ID – Every client must be assigned a client ID. The client ID links topics to clients when it subscribes to a topic. Client IDs must be unique for each client. When persistent
connections are used, the broker remembers all of the subscribed topics for that client ID.

 Usernames and passwords – As with other software, a broker may require that a client send a valid username and password in order for the connection to be established. This
username and password combination is sent in plaintext so it is not secure. Transport encryption must be used to secure the credentials.

 Client certificates – x509 certificates can be deployed when a high level of security is necessary. This may not be a good security solution when t here are many clients
because the certificates must be configured and managed on each device.

Client authentication is a good start, and certificates are good for a small MQTT deployment. But when high security is needed for a large deployment, the communication itself must be
secured. With MQTT, there are two ways to protect the messages:

 TLS encryption – This is the same technology used to secure HTTP. TLS creates an encrypted connection between nodes over which the messages ar e sent. TLS can be
problematic to implement if constrained devices lack the processor power and memory to use it.

 Payload encryption – Performed at the application layer, payload encryption provides end to end encryption, protecting the message even from the broker. Payload encryption
does not protect any passwords that might be used on the connection.
Securing CoAP

Like MQTT, CoAP is a great protocol for use in the IoT, but it is not secure. CoAP was designed for low overhead, simplicity, and multicast support in environments with constrained
devices. Because CoAP uses UDP, it cannot use TLS. TLS requires reliable transport to function correctly. Instead, CoAP uses Datagram Transport Layer Security (DTLS). This is
sometimes referred to as secured CoAP (CoAPs).

When DTLS was developed, it was made to resemble TLS as closely as possible. This prevents the need to create an all-new security protocol, while allowing for code and infrastructure
reuse. At first, DTLS was designed to be used on powerful devices that have high-bandwidth connections. Through the use of header compression compliant with 6LoWPAN, packet size,
fragmentation, and energy consumption are all significantly reduced. A very simple implementation is available for embedded devices called tinydtls.

DTLS may be the best security protocol for IoT devices because it can protect data with keys and algorithms, provide key exchange, and perform authentication. The t wo-way handshake
DTLS uses is shown in the figure.

Click here for the IETF draft standard for DTLS two-way authentication.

Disable UPnP

Although UPnP was designed to help users connect things, it also leaves large security holes that threat actors can use to infiltrate your network and compromise your devices and data.
Therefore, it is a best practice to turn off UPnP on all devices when possible. Make sure to test for any changes in functionality after turning off the service. Some manual configuration
may be necessary to ensure devices and communications continue to work properly.

UPnP assumes that all local devices are friendly and trustworthy. If a device on your network becomes infected with malware, it could use UPnP, just like your new printer or game
console can. This could allow the malware to install control software on a computer, open a port on the router using UPnP, and contact a threat actor. This gets them in to start probing
other devices on your network.

Most home routers have the ability to turn UPnP on and off. In the figure, the administrator has unchecked Turn UPnP On and is ready to apply the change.
Password Issues

One of the most widely used ways of compromising systems is by stealing credentials. The Mirai botnet exploit took advantage of publically-known default credentials to compromise
thousands of IoT devices. With any new device, always change the default username and password. Even if you cannot change the username, be sure to change the password during
configuration. This should be your first priority. Some password examples are shown in the figure.

Strengthen and protect passwords using the following guidelines:

 Pass phrases - Use a pass phrase instead of a password. Use random words along with numbers and characters. If done properly, these can be quite easy to remember, but
very difficult to guess.

 Hardened passwords - Make passwords difficult to crack by using a minimum of 8 characters and allowing at least 64 characters to support passphras es.

 Password managers - Use a password manager to avoid writing down passwords. These programs require a single password for you to access all your other passwords. T his
allows you to create very complicated passwords that you do not have to memorize.

 Multi-factor authentication - Some systems will use more than one form of authentication such as sending a text message to your phone with a code that must be entered or
requiring your fingerprint for authentication, as shown in the figure.

Recently, United States National Institute for Standards and Technology (NIST) published improved password requirements. NIST standards are intended for government application but
can also serve as a standard for others as well.

Click here to learn more about the improved NIST password requirement.
Harden Administrative Interfaces

Interfaces exposed to the internet are constantly under attack by threat actors. They use scanning tools to discover them, and the internet to research flaws and how to exploit them.
Deploy web interfaces and protect them in the same way as web applications. Use encrypted transport protocols and validate certificates. Limit access as much as possible. Make sure
strong credentials are in place before deployment because many users will not change the configuration. There are easy ways to prevent the most common vulnerabilities in applications
and to limit the amount of damage that they would be able to cause.

SQLi

To prevent SQL injection, the data must be kept separate from the commands and queries that are used. The best way to do this is to use a safe API. A safe API provides a
parameterized interface or does not use the interpreter at all. Parameterizing queries specify placeholders that indicate to the database that they are data and not part of a command.
Object Relational Mapping Tools (ORMs) can also be used to create a virtual object database by using an object-oriented language to convert the data between systems that are not
compatible.

A whitelist can also be implemented on the server side for input validation. This is not always effective when an application requires special characters, or special APIs. On legacy
systems, the special characters can be escaped by using the escape syntax for the specific interpreter that is being used. Also, use LIMIT and any other controls within queries. This will
prevent mass disclosure of records.

Routinely test applications using both static and dynamic testing. Also, enforce a policy of least privilege on the database. Every application should have its own credentials when
accessing the database. Only supply an application with the minimum amount of rights that it must have.

XXE

eXternal Entity injection (XXE) has become a very popular form of attack. It is very important to train developers to be able to identify and mitigate XXE injection. According to OWASP,
the safest way to prevent it is to disable XML external entity and DTD processing in the application. The method should be si milar to the following command:

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

These are some additional methods to prevent XXE:

 Use less complicated data formats like JSON.

 Upgrade or patch XML libraries and processors that the application or operating system uses.

 Use whitelisting on the server side when validating input, filtering, or sanitizing. This will prevent hostile data in XML documents.

 Use XML Schema Definition (XSD) or similar validation on incoming XML when uploading. Verify that it is being validated.

 Detect XXE in source code by using SAST tools. When the application is large and complicated, use manual code review.

XSS

XSS vulnerabilities are very common. They have affected some of the largest and most popular applications. XSS has been liste d on the OWASP top 10 list since it began. XSS attacks
are very dangerous because they can give the threat actor the ability to do whatever the user can, and to see what the user is seeing. This could include financial information and
passwords, often without the user or the application knowing that they are under attack. There are three best practices to prevent XSS in applications:

 Escaping – This censors the data that the web page receives. It ensures the data that the application receives is secure before it is rendered for the end user.

 Validating Input – Whitelisting can be used to allow only known good characters into the application. This is especially effective at preventing XSS in forms because the user
cannot add special characters in the fields.

 Sanitizing – Remove potentially harmful markup from any input. This is especially useful when a site allows HTML markup.

There is no perfect single method for preventing XSS attacks entirely. By using a combination, or all, of the methods here, t he vast majority of XSS attacks will be prevented. Use a mix of
code review, static testing, and dynamic testing. Also, always follow secure coding practices when creating, updating, and patching applications to prevent XSS and other attacks.
Packet Tracer - Threat Modeling at the IoT Application Layer

In this Packet Tracer, you will continue with the process of creating a threat model for the home automation IoT system that was started in the previous chapters. You will refer to the
home automation Packet Tracer file that you used previously.

You will work with the IoT application layer of the IoT attack surface and think about the various applications that may be used in a home automation IoT system.

As you have learned in the course, you can think about IoT applications as concerned with either data or control. Data applications allow users to understand what is happening in an IoT
system by providing dashboards and other data representations to communicate information about the system. Usually these applications are part of a cloud service and can be accessed
over the internet through a web portal. Control applications enable interaction with the system, either through direct control of actuators from the application interface, or through software
which automates the operation of the system through code that reads sensor values and triggers actuators.

Embedded applications are also present in some IoT devices. These usually exist as HTTP interfaces that run on the IoT devices and are accessed over the network. In this case, these
devices will have their own IP addresses on the local LAN.

Packet Tracer - Threat Modeling at the IoT Application Layer Instructions 5.2.1.6

Packet Tracer - Threat Modeling at the IoT Application Layer PKA

Chapter 5: IoT Application Layer Attack Surface

This chapter began by discussing IoT local application vulnerabilities. An application vulnerability is any weakness that a threat actor could use to compromise the security of that
application. Threat actors can detect devices on the network and exploit their vulnerabilities. Even though iOS and Android are relatively secure, they can still be compromised, especially
through the applications that we install on them and use on the web.

Next, the chapter detailed IoT web and cloud application vulnerabilities. In order to secure exposed cloud applications, security applications such as static analysis, web application
scanners, and runtime protection must be used. All of the transactions and data presentations in cloud computing applications must be do ne in a secure environment. Web and cloud
applications and cloud-based web interfaces must follow strict guidelines to keep them secure. Every developer should understand the basics of web security when adding features, fixing
bugs and updating application code. Threat modeling can help to make sure applications are as secure as they can be.

The next section of this chapter covered IoT application layer protocols. A message protocol defines the functions and rules for transmitting messages between devices. Because there
are many different requirements of connected devices, it is unlikely that one single protocol will dominate. MQTT is used when there is a need to monitor many small devices and have
their data available in the cloud to trigger M2M decisions. CoAP uses a client-server model where clients request from servers and servers respond to clients. Other message protocols
exist in the IoT including XMPP, DDS, AMQP, and UPnP, among others.

The final section of this chapter covered mitigating security issues in messaging protocols. For MQTT, the security implementation must be based on the capabilities of the broker and the
clients. Instead of TLS, CoAP uses DTLS. If a device on your network becomes infected with malware, it could use UPnP, just like your new printer or game console can. Strengthen and
protect passwords using strict guidelines. To harden administrative interfaces, use a mix of code review, static testing, and dynamic testing.

Be a Bounty Hunter

One of the more exciting careers in network security is the bug bounty hunter. Talented ethical hackers are hired by crowdsourced security services to test their clients' networks. This
enables the security service company to access a wide range of creative hacking talent that they would not normally have acce ss to if they only used hackers that are on staff.

HackerOne is one of the first companies to provide vulnerability assessment services from a crowdsourced model. HackerOne enlists ethical hackers to use their talents at the request of
HackerOne’s business clients. HackerOne also tests core internet technologies such as Open SSL, various servers such as Nginx and Apache, and languages such as PHP, Python, and
Perl.

HackerOne enlists nearly 100,000 hackers to discover vulnerabilities and have paid millions of dollars in internet bug bounties.

Click here for the HackerOne website.

Vulnerability Assessment

Vulnerability assessment identifies vulnerabilities that are likely to be exploited by threat actors. Vulnerability
assessments can be routinely and regularly conducted, often in an automated way, or may be targeted at specific
components of an IoT system. Adopting a hacker mindset is helpful in vulnerability assessment as shown by the
success of HackerOne.

Vulnerability assessments are frequently performed using off-the-shelf-tools, either free or purchased. Many free
tools are found in Kali Linux. Click here for a categorized list of Kali Linux tools.

The Process of Vulnerability Assessment

Vulnerability assessments should be carefully planned. The planning process includes defining the objectives and scope of the test, identifying the tools to be used, and determining who
will perform the tests and a testing process. The systems that will be targeted must also be defined. Will the vulnerability test address aspects of the network, applications, or both? Is it
necessary to test password security? Perhaps only specific aspects of the system are to be targeted in a given test. Vulnerability tests can be conducted from inside the network, or from a
remote location outside the network.
In addition, a thorough understanding of the network system is required. It is important to know the entry points into the network, the exposure of the entry points to various potential threat
vectors, and the locations of mission-critical assets and the data pathways to them. An example of the vulnerability assessment process is shown in the figure.

Finally, it is important to report the vulnerabilities that were discovered and the potential levels of exposure to threats. Later, in risk assessment, the vulnerabilities are translated into risks
so that they may be prioritized and addressed accordingly.

Types of Vulnerability Assessment

Vulnerability assessment can be classified into three different types depending on who conducts the assessment and the degree of knowledge that the assessors have of the network:

 White box - These assessors have knowledge of the network systems that they are assessing. They frequently focus on specific aspects of the system to execute their
assessments. These testers frequently operate from within the organization.

 Black box - This assessment is the closest to an actual attack. The assessors, who are usually working for a third party, have no knowledge of the network architecture prior to
conducting their assessment.

 Gray box - White box testers identify the vulnerabilities, and then black box testers are hired to target the discovered vulnerabilities . A gray box tester has partial knowledge of
the network systems they are testing including access to the documentation of internal network architecture. The goal is to verify the vulnerabilities, determine the ease of
exploiting them, and to determine the potential impacts of exploits.
Penetration Testing

Penetration testing (pen testing) pushes vulnerability assessment to the next level. It consists of actual focused attacks that uncover the potential impacts associated with known
vulnerabilities. Skilled ethical hackers take on the role of threat actors and launch actual attacks that are meant to replicate what malicious hackers might do. Pen testing is an assessment
tool used in black box testing because the hackers operate with no knowledge of the internal workings of the target system. Pen tests can uncover the potential damage from a known
vulnerability exploit.

Pen testing can also be used to confirm that vulnerabilities identified in other vulnerability assessments do in fact exist and that they can result in significant harm if exploited. When used
in this way, it is considered to be gray box testing. Finally, pen tests can be used to confirm that measures taken to eliminate a vulnerability have been effective and the v ulnerability no
longer exists.

You will learn about some popular vulnerability assessment tools, some of which you have used in previous labs. Many others are available in Kali. Click here for more information on
individual tools or search for information on the internet.

Port Mapping Tools

Port mapping tools, such as Nmap, Netcat, or SolarWinds Port Scanner are invaluable for discovering open ports on end systems and network devices. Open listening ports can provide
access to the system by hackers.

Nmap is one of the oldest vulnerability scanners available. The figure shows Nmap’s GUI form, called Zenmap. Zenmap can produce very detailed information about a single system or a
range of systems on a network segment. It discovers hosts on the network and can report not only on the open ports, but also identify the operating systems that are running on hosts. In
addition, Nmap can reveal details about the services that are running on the open ports including the software versions in a process known as fingerprinting.
Password Vulnerability Tools

Weak or default passwords are a significant vulnerability in network systems, as we have seen from the Mirai botnet example in previous chapters.

Weak passwords on IoT application portals are also a concern. Because these services are frequently exposed to the internet, threat actors with a range of skills and motivations can find
these portals attractive targets. In this case, significant data loss can occur due to theft or damage and threat actors can take over important actuator control systems causing damage,
injury, or death.

There are several common types of password attack methods that can be used to assess password security:

 Brute force - This attack is a very time consuming, inefficient, automated means of trying every possible combination of letters, numbers, and symbols to challenge logins.

 Dictionary attack - This attack uses lists of words that could be used as passwords. Some lists contain real examples of passwords that have been stolen from user accounts.

 Password sniffing and cracking - Many passwords are stored or transmitted as hashes. Protocol analyzers can be used to intercept authentication traffic that contains hashed
passwords. Hashed passwords may also be discovered in the file systems of IoT devices. When they are intercepted, tools such as John the Ripper and Aircrack-NG can be
used to attempt to break the hash encryption in order to display plaintext passwords.

 Rainbow tables - Rainbow tables contain hashed values and their plaintext equivalents. These pre-cracked passwords greatly speed up the process of gaining entry to a
system. Very large rainbow tables can be obtained online. Intercepted hashes are looked up in the rainbow table and, if found, the plaintext equivalent can be known without
actually unencrypting the hashed password. It is much faster to search for a hash in a table than it is to actually crack the hash.

It is essential that organizational policies enforce standards for creating and using passwords. Measures should be taken to defeat brute force attacks by allowing a limited number of
authentication failures before an account is locked out. However, username security is also essential because account lock out can be a malicious denial of service in which attackers
intentionally try to lockout legitimate users.

Additionally, enhanced approaches to authentication in IoT systems must be considered when there is high risk of damage or physical harm to people, such as in Industrial Internet
Control Systems (IICSs).

Click here for the United States National Institute of Standards and Technology (NIST) guidelines for digital identities.

Also, the FIDO (Fast IDentity Online) Alliance shown in the figure has developed new authentication technologies and standards for the IoT. Click here for information on the FIDO
Alliance.

Web Application Vulnerability Tools

In this course, you have used tools in the Kali suite such as Nikto, Skipfish, and sqlmap. Other prominent tools are described below.

 OWASP ZAP - The Open Web Application Security Project (OWASP) is a primary reference for web application vulnerabilities. Click here for the OWASP web site and type
"Top 10" in the search bar to locate the webpage with the OWASP Top 10 most critical vulnerabilities. The webpage should also include preventive measures and example
attack scenarios. It is an invaluable list for all IoT application developers and vulnerability testers. The OWASP ZED Attack Proxy (OWASP ZAP) is a very popular free open-
source vulnerability assessment tool that is frequently used for black box pen testing. It is known as an attack proxy because it sits between the tester’s browser and the web
application, intercepting and inspecting messages sent between the two. Click here for more information on OWASP ZAP.

 OpenVAS - Frameworks are suites of tools that are combined to perform vulnerability assessment functions. The OpenVas framework used early in this course combines a
number of vulnerability scanning tools into a unified application that includes vulnerability data storage, scan scheduling, and reporting. Click here for more information on
OpenVAS.

 Burp Suite - Burp Suite is a comprehensive group of web application vulnerability testing tools that can identify the presence of the OWASP top 10 vulnerabilities. It includes a
scanner, a configurable automated attack tool, and a web crawler that can map the file system of a web application. Burp Suite is a product developed by Dafydd Stuttard and
his company, PortSwigger. Click here for more information.

Vulnerability Assessment Services

Security as a service (SECaaS) companies provide a wide range of managed security services including vulnerability scanning. Companies such as Alienvault and Qualys offer such
services. Mandiant, the maker of the Fire Eye security management platform, offers penetration testing services, as do a number of other companies.

Cisco offers network penetration assessment as part of its portfolio of security products and services. Click here for more information.

Vulnerability Information Sources

What happens if new vulnerabilities appear that are not currently part of the test regimen? How do you find out if a newly discovered vulnerability may be present in your systems?

A proactive approach to security is essential. While periodic manual and automated vulnerability assessments are important, i t is very possible that threats can emerge that are not
immediately detectable by these tools. New vulnerabilities and threats develop daily. New exploits are constantly appearing t hat can evade network security systems.

Fortunately, a number of threat intelligence sources work diligently to discover, investigate, and disseminate threat information as it is discovered. For example, Cisco Talos Intelligence
Group (Figure 1) is one of the largest commercial threat intelligence teams in the world. These teams are supported by telemetry and sophisticated systems to create accurate, rapid, and
actionable threat intelligence for Cisco customers, products, and services. Talos defends Cisco customers against known and e merging threats, discovers new vulnerabilities in common
software, and interdicts threats in the wild before they can further harm the internet at large. Click here for more information on Cisco Talos.
The NIST National Vulnerability Database (NVD) enhances Common Vulnerabilities and Exposures (CVEs) with additional analysis, a database, and a fine-grained search engine. The
NVD and CVE are synchronized so that any new information in the CVE appears immediately on the NVD. Common Vulnerability Scor ing System (CVSS) scores are also included in the
NVD. You will learn more about CVSS in the next section. Click here for the NVD. Click here for the CVE standard.

Finally, hardware and software vendors should inform customers and the public about vulnerabilities in their products. Patches and updates are usua lly made available in a timely manner.
IoT security personnel should be aware of how prospective vendors react to newly discovered vulnerabilities and threats. Be sure you evaluate vendors based on their history of threat
response. Vendors should notify customers quickly and make patches and updates available. Of course, all devices should be capable of firmware updates and the manufacturers should
provide practical means of distributing and installing secure updates for the devices and software.

It is also a good idea to subscribe to security-related email lists and to read blogs and other information sources to stay up-to-date on cybersecurity threats.

IoT Risk Assessment

Most approaches to IT security emphasize user actions and data security. IT systems have routinely embraced distributed client-server systems that use public networks. IT system
vulnerabilities are often concerned with human behavior, TCP/IP protocols, and network architectures that have evolved to enhance the operation of Ethernet. Most approaches to OT
security are concerned with the safety of people and equipment. OT communication is frequently M2M with humans monitoring and controlling industrial, energy, environmental, or smart
city systems, among others. The data flows and protocols used in these systems can be fundamentally different from IT systems .

The IoT enables a very new set of risks. Widespread cyber attacks, such as DDoS, are not new. What is new is the scale of the attacks that are enabled by the enormous IoT attack
surface, such as compromising critical industrial infrastructure components that are now connected to the internet. It is clear that new risks enabled by dynamic large-scale IoT systems
present great challenges to risk assessment approaches.

The figure is of a meter that registers from low risk to high risk with a needle pointing to high risk.

Thinking about Risk

Risk is determined as the relationship between threats, vulnerabilities, and the assets of an organization. It first involves answering the following questions as part of a risk assessment:

 Who are the threat actors who want to attack us?

 What vulnerabilities can threat actors exploit?

 How would the organization be affected by successful attacks?

 What is the likelihood that different attacks will occur?

 What can the organization do to address the risk?

The figure provides a way to think about these questions in reference to a simple representation of a system.

NIST Special Publication 800-30 describes risk assessment as:

…the process of identifying, estimating, and prioritizing information security risks. Assessing risk requires the careful ana lysis of threat and vulnerability information to determine the extent
to which circumstances or events could adversely impact an organization and the likelihood that such circumstances or events will occur.

Click here to download the full NIST Special Publication 800-30.

The figure demonstrates threat actor attacks. Threat actors create multiple attacks on vulnerabilities in a network. Some of those attacks find a vulnerability that has no security measure
in place. This exploit could help threat actors to gain access to data, apps, identity, devices and other areas of the network. This could lead to a loss of reputation, advantage, equipment,
safety, and others.
Common Vulnerability Scoring System

The CVSS is a risk assessment designed to convey the common attributes and severity of vulnerabilities in computer hardware and software systems. The third revision, CVSS 3.0, is a
vendor-neutral, industry standard, open framework for weighting the risks of a vulnerability using a variety of metrics. These weights combine to provide a score of the risk inherent in a
vulnerability. The numeric score can be used to determine the urgency of the vulnerability, and the priority of addressing it.

The Forum of Incident Response and Security Teams (FIRST) has been designated as the custodian of the CVSS to promote its adoption globally. Cisco and other industry partners
contributed to the standard. Click here for the CVSS Special Interest Group at the FIRST website.

While the CVSS was not designed for IoT systems, it is useful for understanding how a vulnerability can be evaluated in the c ontext of risk. Unfortunately, the current CVSS does not
include metrics around the issue of safety because it was primarily designed for IT security. We anticipate that future scoring systems will include additional metrics that are specific to IoT
implementations.
The CVSS Metrics Groups

The CVSS tool, requires the assessor to select values in a series of three metric groups for each vulnerability that has been identified in a vulnerability assessment.

Before performing a CVSS assessment, it is important to know key terms that are used in the assessment instrument.

Many of the metrics address the role of what the CVSS calls an authority. An authority is a computer entity, such as a databas e, operating system, or virtual sandbox, which grants and
manages access and privileges to users.

The figure shows the three metric groups and the individual metrics that make up each group.

Base Metric Group

This represents the characteristics of a vulnerability that are constant over time and across contexts. It has two classes of metrics:

 Exploitability - These are features of the exploit such as the vector, complexity, and user interaction required by the exploit.

 Impact metrics - The impacts of the exploit are rooted in the CIA triad of confidentiality, integrity, and availability. Note that safety is missing from the metrics.

Temporal Metric Group

This measures the characteristics of a vulnerability that may change over time, but not across user environments. Over time, the severity of a vulnerability will change as it is detected and
measures to counter it are developed. The severity of a new vulnerability may be high, but will decrease as patches, signatures, and other countermeasures are developed.

Environmental Metric Group

This measures the aspects of a vulnerability that are rooted in a specific organization’s environment. These metrics help to guide consequences within an organization and also allow
adjustment of metrics that are less relevant to what an organization does.

The figure is of the CVSS Metric Groups. In the base metric group there are 2 columns: exploitability metrics and impact metrics. Exploitability metrics: attack vector, attack complexity,
privileges required, and user interaction. Impact metrics: confidentiality impact, integrity impact, and availability impact. Scope is also under the base metric group but is not under either of
the columns. Temporal Metric Group: Exploit code maturity, remediation level, and report confidence. Environmental metric group: modified base metrics, confidentiality requirement,
integrity requirement, and availability requirement.
CVSS Base Metric Group

The Base Metric Group Exploitability metrics include the following criteria:

 Attack vector – This is a metric that reflects the proximity of the threat actor to the vulnerable component. The more remote the threat actor is to the component, the higher the
severity. Threat actors close to your network or inside your network are easier to detect and mitigate.

 Attack complexity – This is a metric that expresses the number of components, software, hardware, or networks, that are beyond the attacker’s control and that must be
present in order for a vulnerability to be successfully exploited.

 Privileges required – This is a metric that captures the level of access that is required for a successful exploit of the vulnerability.

 User interaction - This metric expresses the presence or absence of the requirement for user interaction in order for an exploit to be successful.

 Scope – This metric expresses whether multiple authorities must be involved in an exploit. This is expressed as whether the initial authority changes to a second authority
during the exploit.

The Base Metric Group Impact metrics increase with the degree or consequence of loss due to the impacted component. Impact metric components include:

 Confidentiality Impact – This is a metric that measures the impact to confidentiality due to a successfully exploited vulnerability. Confidentiality refers to the limiting of access to
only authorized users.

 Integrity Impact – This is a metric that measures the impact to integrity due to a successfully exploited vulnerability. Integrity refers to the trustworthiness and authenticity of
information.

 Availability Impact – This is a metric that measures the impact to availability due to a successfully exploited vulnerability. Availability refers to the acc essibility of information
and network resources. Attacks that consume network bandwidth, processor cycles, or disk space all impact the availability.

The CVSS Process

The CVSS Base Metrics Group is designed as a way to assess security vulnerabilities found in software and hardware systems. It describes the severity of a vulnerability based on the
characteristics of a successful exploit of the vulnerability. The other metric groups modify the base severity score by accounting for how the base severity rating is affected by time and
environmental factors.

The CVSS process uses a tool called the CVSS v3.0 Calculator, shown in Figure 1. The calculator is similar to a questionnaire in which choices are made that describe the vulnerability
for each metric group. After all choices are made, a score is generated. Pop-up text that offers an explanation for each metric and metric value are displayed by hovering a mouse over
each. Choices are made by choosing one of the values for the metric. Only one choice can be made per metric.

Click here to explore the CVSS calculator.

A detailed user guide that defines metric criteria, examples of assessments of common vulnerabilities, and the relationship of metric values to the final score is available to support the
process.

After the Base Metric group is completed, the numeric severity rating is displayed, as shown in Figure 2. A vector string is also created that summarizes the choices made. If other metric
groups are completed, those values are appended to the vector string. The string consists of the initial(s) for the metric, a nd an abbreviated value for the selected metric value separated
by a colon. The metric-value pairs are separated by slashes. An example vector string created for the Base Metric group is shown in Figure 3. The vector strings allow the results of the
assessment to be easily shared and compared.

In order for a score to be calculated for the Temporal or Environmental metric groups, the Base Metric group must first be completed. The Temporal and Environmental metric values then
modify the Base Metric results to provide an overall score. The interaction of the scores for the metric groups is shown in Figure 4.

Lab - Using the CVSS

CVSS refers to the Common Vulnerability Scoring System. It is a vendor-neutral, industry standard that offers an open framework for conveying the severity of vulnerabilities. It helps to
determine the urgency and priority of responses to vulnerabilities. The CVSS model is designed to provide users with an overall composite score representing the severity and risk of a
vulnerability.

The results of a CVSS calculation are based on metrics and formulas. The metrics are in three distinct categories that can be quantitatively or qualitatively measured.

This lab will provide you with a security vulnerability scenario, and it will be your job to use the CVSS calculator and specification document to determine what the Base Score is.

Lab - Using the CVSS 6.2.1.9

Threat Modeling in Depth

Threat modeling is a proactive approach to assessing security of systems and software. It provides a system that encompasses vulnerability and risk assessment in to a coherent whole,
as shown in Figure 1. Ideally, it is applied iteratively as the system passes different stages of design and production. Doing so helps create a security focus.

As new vulnerabilities and the threats that accompany them are discovered, threat modeling can be applied to deployed systems . However, because the cost of addressing vulnerabilities
increases dramatically as the system moves from design to development to deployment, threat modeling is best applied throughout the development process.

There are three approaches to threat modeling:

 Attack-centric – This is conducted from the point of view of the attacker.

 Defense-centric – This analyzes the architecture system to identify threats to different elements.

 Asset-centric – This focuses on classifying assets and assigning value to them.

In this course we are mostly concerned with a defense-centric approach.

In a broad sense, the threat modeling process begins with understanding the system by answering the following questions:

 What are we modeling?

 What are the potential threats?

 What are the risks?

 What can be done to address the risks?

In Figure 2, steps one through three are concerned with understanding the system. Step four concerns vulnerability and risk assessment, and step 5 addresses recommendations to
mitigate the risks.

Note: The threat modeling approach employed in this course is adapted from the Microsoft approach to threat modeling.
System Security Objectives

The first step (Figure 1) is to determine what the security objectives are for the system, based on its purpose and operation. It is important to understand what type of data is handled by
the system and the consequences of data theft or destruction. Will data loss result in financial losses? If so to what degree? If a security breach occurs, will the reputation of the company
be damaged? If so, what are the business impacts? For example, if hackers steal customer information for a computer security sof tware company, the resulting loss of reputation could
have greater impact than if the hackers had stolen other types of data.

In addition, governments and other organizations are enacting regulations that govern how data is gathered, transmitted, and stored. Violations of these regulations can result in serious
financial and legal penalties. Failure to comply with privacy and other regulations can have great impact and should be a major security consideration in systems that handle private data.

Finally, some systems must have high availability. Critical infrastructure systems provide services that support a nation's defense security, economic functioning, and the health and safety
of the people who live there. The services provided by these systems must always be available. Because of the critical nature of the services, disruptions can have serious impacts at the
national level.

Categories for determining security objectives in an IoT system were covered in a previous chapter and are summarized in Figure 2.
Map Data Flows

After the security objectives are identified, the functions of the system architecture should be diagrammed. Not all components of the system are depicted. Instead, the data flows from
functional sections of the IoT system are shown.

Data flow diagrams (DFDs) are extremely useful for visualizing an IoT system. DFDs depict the pathways that data will take between different functional components of the system,
including entry points into the system and the devices and people using those entry points. DFDs also label the kind of data flows and the protocols in use.

Data Flow Diagrams Components

Components that might be included in an IoT system DFD are as follows:

 IoT devices – These are sensors and actuators.

 IoT gateways – These enable sensor data to be sent across the IP network. They may also enable control traffic to actuators.

 Local applications – These control and monitor software that is on the same network as sensors and actuators.

 Edge devices – These enable internal IP traffic to be sent between locations and the internet or cloud.

 Data applications – These provide access to IoT data, analytics, and dashboards.

 Data storage – These are data stores and database types.

 Control applications – These process data in order to make decisions that enact control.

 Mobile applications – These enable user monitoring and control from remote locations.

Figure 1 is a DFD with many of these components, as well as a few IoT protocols and standards. The topology icons help you understand where thi ngs are located in a DFD. Normally, a
DFD does not show topology icons, as shown in Figure 2.

DFDs use a series of four symbols to represent these devices. Figure 3 shows two conventions for representing components in a DFD. In this course, you will use the Yourdon and Coad
symbols.

DFD entities should conform to a few basic rules:

 Any process should have at least one input and one output.

 Data stores should have flows for both write and read access.

 Data stored in a system must go through at least one process.

Processes can only be connected to other processes or data stores.

Zones of the System

It is also useful to group symbols into functional zones of the system. Zones can be defined as areas of the system that require different authorization and authentication. In a system
architecture, zones also help to limit the exposure of different parts of the system to the vulnerabilities that are associated with each zone. Zones can be indicated by rectangles with
dashed borders. Example zones might be the sensor area of the network, web applications, the IP gateway and network edge, etc . In some cases, zones can be nested when
components are located within another organization, such as the web gateway zone in the figure. These components might be owned by another company such as Microsoft Azure IoT
Hub, Amazon Web Services IoT, or Google Cloud IoT.
Determine Trust Boundaries

After the system architecture is depicted and zones are added, trust boundaries can be added, as shown in the figure. Trust boundaries delimit sections of the network where the level of
trust between entities at either end of a flow is different. For example, data flowing from an IoT Gateway to Cloud Gateway crosses a trust boundary. The permissions for the IoT Gateway
are different than those for the Cloud Gateway, which is exposed to the internet and accessed by many users. Data traffic that crosses this boundary must be authorized and
authenticated at the incoming device.

Note: Trust boundaries should only cross data flows.

STRIDE

After the IoT system is modeled, the threat identification process can proceed. In this process, you will use the STRIDE mode l to identify threats.

As you learned previously, the STRIDE approach provides a set of categories that are very helpful for identifying potential t hreats in IoT systems. It is used in the vulnerability identification
phase of the threat modeling process.

STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each of these is the opposite of the security goals for a
system, as shown in Figure 1. Figure 2 provides definitions for each category with examples.

STRIDE provides a classification scheme for identifying threats for each element of the DFD. Not all threats are applicable to all elements of the system, as shown in Figure 3. All stride
threat categories apply to processes. Data flows and data stores can have potential tampering, information disclosure, and denial of service vulnerabilities. Data stores may also be
vulnerable to repudiation if they contain logs. External entities are vulnerable to spoofing and repudiation. Understanding which vulnerabilities are relevant to which system elements will
help save time in the threat modeling process.

Note: STRIDE is not a means of conducting vulnerability assessment. It is used to create an inventory of potential threats that can exist within different elements of an IoT system.
Risk Assessment with DREAD

Each threat that is identified by STRIDE must now be assessed for its degree of risk for the organization. Like CVSS, the DREAD model results in a quantitative risk score. This score can
be used with risk cost assessments to evaluate the desirability and feasibility of mitigating a threat. The DREAD model should be applied to every threat that was uncovered during the
threat identification process. The figure provides information about the DREAD categories.
The DREAD Threat Rating Model

Because the STRIDE and DREAD models were developed initially for threat modeling of software systems, small modifications may be required to apply these models to IoT systems. For
example, the DREAD category A, shown in Figure 1, can include affected devices, such as in the Mirai botnet attack.

Each vulnerability that was identified by STRIDE is now rated according the five DREAD categories. The rating values are:

 3 = high

 2 = medium

 1 = low

Figure 2 provides some insight into possible meanings for the metric values for each category. These values are relative to the organization and system which is affected by the
vulnerability. When using DREAD, it may be useful to arrive at a consensus within the organization for the meanings of the metrics for each category.

Note: Some analysts recommend that Reproducibility and Discoverability values always receive a value of 3. This is because it is not possible to hide from threat actors. An organization
should assume that threat actors will eventually uncover any vulnerability.
A DREAD Model Example

Read the case below and look at the ratings in the figure.

Case Study: Retail Chain

A retail chain with 300 locations recently purchased network-connected digital video recorders (DVRs) for the security camera systems in each store. The DVRs are connected through
the internet to regional offices that administer the DVRs and collect the videos. An embedded HTTP server in the DVR allows the device to be configured and controlled through a web
page.

The manufacturer of the DVR has published a notification regarding a recently discovered vulnerability. Threat actors can craft an HTTP cookie request and send it to the DVR embedded
web server. Configured usernames and passwords for the DVR are returned to the threat actor. The security researcher who discovered the vulnerability wrote a tool that makes it easy to
exploit this vulnerability. In addition, a Shodan search can easily identify the presence of the vulnerable cameras on the internet. Due to the simplicity of the security researcher’s tool,
many low-skill hackers begin using it to gain access to the DVRs all over the internet. For devices with this vulnerability, threat ac tors can gain control of the DVR, view live video,
manipulate files, disable operations, etc.

In order to mitigate the threat, the DVR firmware requires an update. However, firmware updates must be installed locally from the configuration menu on each DVR. There is no
mechanism to push and install updates to the devices from a central location. In addition, after the update, new user credentials will need to be configured on devices manually.

Example DREAD Rating for the Vulnerability

Figure 1 shows that the rating for this vulnerability is High. Compare this to rating guidelines in Figure 2. Do you agree with the ratings?

Although the risk is High, this does not mean that company will update the firmware in all devices. This is because the updating process is labor intensive and would prove costly. The
company will most likely investigate other mitigation techniques such as blocking access to the DVRs by using firewall rules at the routers in each location. These rules could be
distributed and monitored from a central location. Implementing the rules might sufficiently lower the DREAD composite metric enough that the risk could be considered relatively minor.

Lab - Assess Risk with DREAD

DREAD is risk assessment model used to quantify risk related to security threats and to quantify potential risks. It is not a vulnerability assessment tool, but it is part of the risk
assessment. They differ because risks are vulnerabilities that have been evaluated in the context of an organization based on previous attacks. The same vulnerability may present vastly
different levels of risk depending on the nature of the organization. There are 5 categories used to compute the result:

 Damage Potential – If the threat is exploited, what is the damage potential?

 Reproducibility – How reproducible is the vulnerability?

 Exploitability – How difficult is it for the vulnerability to be exploited?

 Affected Users – What is the scale of the attack? How many users are affected by this vulnerability?

 Discoverability – How difficult is it to discover the attack?

There are multiple ways to score the DREAD risk assessment model. Microsoft uses a scoring system of 1, 2, or 3 with 3 indicating the high risk for each category (STRIDE). However, for
this lab, we will be using the scoring system described by OWASP at the following link:

https://www.owasp.org/index.php/Threat_Risk_Modeling#DREAD

OWASP uses a scoring system of 0, 5, or 10 for each category with 10 indicating a more serious risk, and 0 indicating no risk. Discoverability is the only category that offers an additional
option of 9. It is important to refer back to this document when scoring each category for Part 1 of this lab.

Lab - Assess Risk with DREAD 6.2.3.6

Recommending Mitigation

The last step in the threat modeling process is mitigation. Secure development and deployment of IoT systems is the most effective way to mitigate risk. This process should be a
requirement for the deployment of all devices, communication channels, and applications.

Several guidelines for recommending secure design should be followed:

 Consider the attack surface area - IoT deployments will have a large attack surface at the device layer. Carefully consider features to be incorporated in the other layers to
limit the overall attack surface of the system.

 Consider devices that are built with secure default configurations and update mechanisms - In their rush to enable customers to deploy home IoT systems with a
minimum of upfront configuration, many vendors created very insecure products. In addition, to keep costs low, vendors may co mpletely eliminate the ability to update firmware,
or make the process practically impossible. Evaluate all products.

 Consider the security policies of partners and third-party services - An insecure external network that has access to an IoT system may greatly expand its attack surface.

 Consider security in all things - Whenever a design decision is proposed, security should always be part of the evaluation of it.

You cannot hide. Never assume that threat actors are not paying attention. Assume that vulnerabilities will be discovered.

General mitigation strategies are rather straightforward. The figure shows some basic mitigations strategies and how they relate to the STRIDE threat model. In addition, the following
guidelines should be followed.

 Keep device firmware up to date. Do not purchase devices that are not updatable or are difficult to update.

 Keep application software up to date. Replace old and unsupported software and hardware (such as in legacy SCADA systems).

 Keep IT and IoT traffic separate on organization networks. Use network architectures, ACLs, VLANs, firewalls to do so.

 Insure physical security whenever possible. Prevent threat actors from tampering with or destroying devices. Prevent threat actors from adding unauthorized devices to
networks.

 Use secure messaging protocols and make sure that all traffic is sufficiently encrypted.

 Engage with the network security personnel within the organization. They are ultimately responsible for configuring and maintaining network security for the entire organization.

Always evaluate the security posture of any partner or vendor who will be granted access to the IoT network.
Risk Management Strategies

Risk management extends vulnerability and risk assessment into a comprehensive process that is developed and followed by organizations. Documentation for this process is frequently
required for organizations which do business in the government and financial sectors, among others. Various security compliance frameworks require documented risk management plans
that can be audited externally.

The figure illustrates the steps in the NIST Risk Management Framework (RMF). The risk management process is cyclical and ongoing. Organizations should constantly be working
through the cycle. Note that the Risk Identification and Risk Assessments parallel the threat modeling approach. The RMF clos es the circle by including the risk response, response
evaluation, and response assessment activities.

A mandatory activity in risk assessment is the identification and matching of threats with vulnerabilities in what is often c alled threat-vulnerability (T-V) pairing. The T-V pairs can then be
used as a baseline to indicate risk before security controls are implemented. This baseline can then be compared to ongoing risk assessments as a means of evaluating risk management
effectiveness. This part of risk assessment is referred to as determining the inherent risk profile of an organization.

After the risks are identified, they may be scored or weighted as a way of prioritizing risk reduction strategies. For example, vulnerabilities that correspond with multiple threats can receive
higher ratings. In addition, T-V pairs that map to the greatest institutional impact will also receive higher weightings.
Risk Response

There are four potential ways to respond to risks that have been identified. Risk assessment can support the decision of which response to implement. These responses are also
classified under the four "T's" of risk response.

 Risk avoidance (Terminate) - Stop performing the activities that create risk. It is possible that as a result of a risk assessment, it is determined that the risk involved in an
activity outweighs the benefit of the activity to the organization. If this is found to be true, then it may be determined that the activity should be discontinued.

 Risk reduction (Treat) - Decrease the risk by taking measures to reduce vulnerability. This involves implementing management approaches discussed earlier in this chapter.
For example, if an organization uses server operating systems that are frequently targeted by threat actors, risk can be reduced through ensuring that the servers are patched
as soon as vulnerabilities have been addressed.

 Risk sharing (Transfer) - Shift some of the risk to other parties. For example, a risk-sharing technique might be to outsource some aspects of security operations to third-
parties. Hiring a security as a service (SECaaS) computer security incident response team (CSIRT) to perform security monitoring is an example. Another example is to buy
insurance that will help to mitigate some of the financial losses due to a security incident.

 Risk retention (Tolerate) - Accept the risk and its consequences. This strategy is acceptable for risks that have low potential impact and relatively high cost of mitigation or
reduction. Other risks that may be retained are those that are so dramatic that they cannot realistically be avoided, reduced, or shared.

As shown in the figure, a guide to deciding which response to take involves weighing the potential impact of the risk against the probability that it will occur. For less likely risks, it may be
appropriate to tolerate the risk if it is low impact, whereas for a higher impact risk, sharing it with a third party may be appropriate. For risks that have a high probability of occurring, it may
be appropriate to reduce the risk impact. However, for risks that are high-impact and highly probable, eliminating the risk is necessary.

The figure is of a guide with risk likelihood on the horizontal access, risk impact on the vertical access and the 4 Ts (Transfer, terminate, tolerate, and treat) placed between the 2 axis.
Packet Tracer - Threat Modeling to Assess Risk in an IoT System

In this Packet Tracer, you will complete your threat model of the IoT home automation system that you have worked with in previous chapters. Now that you have worked with all three
layers of the IoT attack surface, you can create a basic data flow diagram of the system. This will help you to understand the system at a functional level and create trust boundaries that
will help with understanding security risks. Normally, the data flow diagram would be completed in Step 2 of the threat modeling process. However, because of the structure of this course,
you need to do it later, after all of your asset inventories of the three attack surface layers have been completed.

You will use your STRIDE tables from the physical, communication, and application layers of the IoT attack surface and apply the DREAD model to create risk metrics for some of the
threats. Normally, a threat model would include risk metrics for all of the relevant threats that have been identified, however, for the sake of time, you will work with only some of them.

After creating the risk metrics, you will decide how to respond to the risks using the four Ts risk response model.

Packet Tracer - Threat Modeling to Assess Risk in an IoT System Instruction

Packet Tracer - Threat Modeling to Assess Risk in an IoT System PKA 6.2.4.4

The figure is of students working in a lab environment and a screenshot of the packet tracer interface and the packet tracer is titled Threat Modeling to Assess Risk in an IoT System.

The Promise of Blockchain

In this section, you will learn about one of the more promising innovations in IoT security: blockchain.

Don Tapscott opened his talk on blockchain at the TEDSummit in June 2016 with the following statement:

The technology likely to have the greatest impact on the next few decades has arrived. And it's not social media. It's not big data. It's not robotics. It's not even AI....It's called the
blockchain.

Although blockchain is primarily known as the technology behind Bitcoin, it is gaining a lot of attention from those interested in finding better ways to secure any type of transaction,
including information exchanged by IoT devices. Blockchain has the potential to impact all of the domains shown in the figure.

Blockchain is a technology that solves the problem of trust. A blockchain is a distributed ledger whose continuous growing list of records, called blocks, are linked together and secured
using cryptography. A blockchain is immutable, meaning it is unable to be changed.

A wide variety of industries are looking at blockchain techno logy to securely track transactions and to quickly provide accurate information regarding those transactions. For example,
many large retailers and other members of the food supply chain are moving to blockchain to dramatically improve farm-to-store traceability and transparency.

The figure is of a collage of images labelled mobility, big data, machine learning, robotics, the cloud, Internet of Things, and social media. In the center of the collage is the work
blockchain.

IoT and Blockchain

Many consider both IoT and blockchain as disruptive technologies. A disruptive technology is a product or service that enters the market with a vastly different, even revolutionary
approach. It displaces competitors and even affects people’s lives well beyond the use of the product or service itself.

Applying traditional security methods to an IoT system is challenging due to its decentralized topology and the limited resources of IoT devices.

Cisco Systems and other vendors are examining blockchain as a potential solution to IoT’s security issues. Cisco Systems is one of the leading members of the Trusted IoT Alliance, a
consortium of 17 companies to help establish a standard protocol for a blockchain-based IoT security solution.

Click Play in the figure to learn more about the Trusted IoT Alliance.

Click here to view a transcript of this video.

This is a video titled Blockchain: The Next Frontier of IoT Security.

Current Trust Systems

To best understand how blockchain technology works with cryptocurrencies like Bitcoin, we should first look at how trust works in our current monetary system.

When we purchase goods or services, both parties agree on the method of payment. Typically, this is some sort of traditional currency such as cash, debit card, credit card, or a check
(promissory note). In all these cases we rely on a third party, an intermediary, to guarantee the financial transaction between the buyer and the seller, as shown in Figure 1. This
intermediary may be a government guaranteeing the value of the currency, or a bank guaranteeing that the seller will be paid with funds provided by the buyer. It is common that the
financial institution, the intermediary, will charge a fee for this service.

Financial transactions like these are typically recorded in a single, centralized ledger controlled by the trusted intermediary, shown in Figure 2. Intermediaries, such as banks, maintain a
centralized ledger which contains all of its transactions including deposits, withdrawals, and any fees associated with providing this service. We trust that the ledger is accurately
maintained and that there are no inappropriate additions, deletions, or changes to the ledger. This allows people who may not necessarily know or trust each other to conduct business by
using the trusted intermediary to process the financial transaction.

The trust these intermediaries provide include:

 Authenticating that the person making the transaction is who they say they are.
  Ensuring that all transactions made to the ledger, such as a person’s bank account, are accurate.

 Not allowing any illegal transactions, such as attempting with withdraw more than the balance.

Figure 1 is of a handheld credit card processing device and an image of a bank. Figure 2 is of a credit card statement.

Blockchain Trust System

Blockchain accomplishes trust in a very different manner. Unlike other forms of currencies, cryptocurrencies such
as Bitcoin do not use an intermediary to ensure the trust of the transaction. When bitcoins are used to purchase
goods or services, there is no third party involved. Instead, Bitcoin uses the blockchain itself to provide that trust
between the buyer and the seller.

Blockchain is not just for cryptocurrencies. It can be applied to any type of application that uses some type of
transaction or ledger.

The figure is of a circle of interconnected lines with the letter B in the center.

Blockchain Features

Blockchain is a continuously growing list of transactions in the form of blocks. These blocks are linked and secured using cryptography. A blockchain uses the following technologies and
features:

 Digital signatures

 Decentralized ledger

 An algorithm for reaching consensus

 Each block includes the hash of the previous block, forming a chain of blocks known as a blockchain.

Many of the details have been omitted in the explanations that follow. It is also important to note that there are different types of blockchains. The goal here is to help you visualize an
example of a blockchain and the components that it includes.

The figure is of 3 six-sided shapes connected together by a chain. Each of the 3 shapes includes the text: list of transactions, hash of previous block and hash of this block.
Digital Signature

A digital signature is a mathematical scheme for demonstrating authenticating digital information. A digital signature cannot be copied because it is always different. This is because it
uses the message or transaction to help derive the signature. Changing the message even slightly makes the digital signature completely different. Each block in a blockchain consists of
several transactions, including its digital signature. Digital signatures involve the message (or transaction), a private key, and a public key as shown in the figure.
Decentralized Ledger

Blockchain uses a decentralized ledger with all interested parties maintaining a copy, as shown in the figure. The trust is ensured by everyone receiving and believing any new
transactions. In other words, everyone must be using and working with the exact same ledger. This is done using a process known as Proof of Work.

Reaching Consensus

A block includes transactions along with their digital signatures. In Figure 1, Maria's computer is verifying that the message was created by Jose using Jose's public key. Validating
transactions in a block uses a process that makes it time-consuming for someone to produce, but easy for others to verify. This is known as Proof of Work (PoW).The PoW is an algorithm
(hash) performed by computers that requires a large amount of computational work in relatively short amount of time. These computers are known as miners.

As shown in Figure 2, the miner attempts to find a special number which, when applied to the block using a cryptographic hash algorithm such as SHA256, will generate a consecutive
series of zeros (in this example 30 consecutive zeros). The example shows that the special number computed is 926466100956. Although difficult to compute, Figure 3 shows that
knowing this special number makes it easy to verify.

The Blockchain

A blockchain consists of blocks. Each block is a list of transactions, with a hash of the previous block and hash of this block including its PoW, as shown in Figure 4. The hash is
computed using the hash of the previous block (prior PoW), along with all the transactions in this block with their digital signatures. This makes it computationally infeasible to modify a
block or change the order of the blocks. Doing so would mean having to recalculate the hash for this block and every succeeding block.

Figure 1 is of a diagram of the process of validating transactions. Jose creates a message. Using a secret key that only he knows, he signs the message with a digital signature. Jose can
now sent the message with its digital signature to anyone. Maria receives Jose’s message with the digital signature. Maria has Jose’s public key and uses it to verify that this message
really did come from Jose. Jose wants people to have his public key so they can verify that the messages were created by him. If the message was really created by Jose’s secret key
(that only Jose knows), then the result will be true. If the digital signature is a fraud, the result will be false. Figure 2 is a diagram showing a miner attempting to find the special number.
Figure 3 is a continuation of the miner after computing the special number. Though difficult to compute, knowing the special number makes it easy to verify. Figure 4 is of several blocks.
Each includes transactions, the hash of the previous block and the hash of the current block.
Blockchain Applied to IoT Security

Conventional security methods are not practical for IoT because IoT topologies are largely decentralized and the IoT devices have limited resources. As we have seen, blockchain has
been used to provide security in a similar environment used for cryptocurrencies.

Blockchain can be used to help solve many of these security and trust challenges for IoT including:

 Tracking sensor data measurements and preventing malicious data.

 Providing IoT device identification, authentication, and secure data transfer.

 IoT sensors can exchange data directly with each other securely and without the need for an intermediary.

 A distributed ledger eliminates a single source of failure within the IoT ecosystem.

 IoT deployment is simplified and operation costs of IoT are reduced because there is no intermediary.

 IoT devices are directly addressable with blockchain, providing an immutable history of connected devices for trust and trans parency.

The figure is of laptops, streetlights, trucks and various other things connected by lines.

Lab - Blockchain Demo 2.0

Blockchain is the technology behind the cryptocurrency, Bitcoin. It uses a distributed database to cryptographically secure transaction. Blockchain transactions are immutable.

In this lab, you will complete the Blockchain Demo 2.0 created by freeCodeCamp and answer some questions about this technological innovation.

Lab - Blockchain Demo 2.0 6.3.2.7

Chapter 6: Vulnerability and Risk Assessment in an IoT System

This chapter began by discussing vulnerability assessment. Vulnerability assessments can be routine and regularly conducted, often in an automated way, or may be targeted at specific
components of an IoT system. The planning process includes defining the objectives and scope of the test, identifying the tools to be used, and determining who will perform the tests and
a testing process.

Next, the chapter detailed vulnerability testing types and tools. Vulnerability assessment can be classified into three different types; black box, white box, and gray box. In penetration
testing, skilled ethical hackers take on the role of threat actors and launch actual attacks that are meant to replicate what malicious hackers might do. Open listening ports can provide
access to the system by hackers. Because IoT application portals are frequently exposed to the internet, threat actors with a range of skills and motivations can find these portals
attractive targets.

The next section of this chapter covered risk assessment concepts and approaches. The level of risk is dependent on the value of the asset, the vulnerability of that asset within the
context of the software and systems on which they are used, and the likelihood that threats will be successfully executed against that asset. The numeric CVSS score can be used to
determine the urgency of the vulnerability, and the priority of addressing it. The Base Metric Group Impact metrics increase with the degree or consequence of loss due to the impacted
component.

The next section discussed assessing risk with threat modeling. There are three approaches to threat modeling: attack-centric, defense-centric, and asset-centric. Threat modeling for risk
assessment is a five step process. Zones can be defined as areas of the system that require different authorization and authe ntication. Trust boundaries delimit sections of the network
where the level of trust between entities at either end of a flow is different.

The next section discussed threat identification and risk prioritization. The STRIDE approach provides a set of categories that are very helpful for identifying potential threats in IoT
systems. The DREAD model should be applied to every threat that was uncovered during the threat identification process. Each vulnerability ide ntified by STRIDE is rated according to
the five DREAD categories. Secure development and deployment of IoT systems is the most effective way to mitigate risk.

The next section discussed managing risk in IoT systems. A mandatory activity in risk assessment is the identification of threats and vulnerabilities and the matching of threats with
vulnerabilities in what is often called threat-vulnerability (T-V) pairing. There are four potential ways to respond to risks that have been identified: terminate, treat, transfer, or toler ate.

The final section discussed blockchain. A blockchain is a distributed ledger with a continuous growing list of records, called blocks, which are linked together and secured using
cryptography. Each block consists of several transactions, including its digital signature. Blockchain uses a decentralized ledger with all interested parties maintaining a copy. The Proof of
Work is a hash performed by computers that requires a large amount of computational work in relatively short amount of time.

The figure is of numbers, shapes and human figures.