Managing Risks On IoT Projects

190 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)
Managing Risks on IoT

5 Projects
Lesson Time: 2 hours, 30 minutes
Lesson Introduction
The challenges in designing, developing, implementing, and managing an Internet of Things
(IoT) system are not only technical. You must also manage risks related to cybersecurity,
privacy, and safety.
Lesson Objectives
In this lesson, you will:
• Identify security and privacy risks in IoT systems.
• Identify strategies to keep IoT systems secure and to protect the privacy of users.
• Manage IoT-related safety risks.
TOPIC A
Identify IoT Security and Privacy Risks
The general concept underlying the Internet of Things (IoT) is to connect every object to make
tasks easier and more efficient, automate tedious tasks, use resources more efficiently, and generally
improve the quality of our lives—in short, to make things better. However, if not managed well, IoT
has the potential to make things much worse from the perspective of cybersecurity and privacy.
The Rationale for IoT Security

Connecting everyday things such as cars, appliances, homes, and so forth exposes a lot of sensitive
data. A burglar might be able to more efficiently determine who is at home and what the home
contains. An attacker can use a compromised system to do harm, like changing the braking behavior
of a car, and causing other sorts of machines to fail. The exposure of sensitive data can damage the
reputation of a company or individual. As the number of devices and networks increases, the
opportunities for attacks upon them increase as well. So security is a critical concern in the design of
any IoT system.
Security concerns apply not only to consumer-oriented IoT. Consumer IoT devices, of course, may
be installed on company networks, affording a wide range of security issues. And even industrial-
grade systems have vulnerabilities. Many systems used for industrial control in manufacturing,
energy, water treatment, waste management, and a variety of other high-stakes industries, were
designed and deployed in a time when cybersecurity was not a concern. Systems may run antiquated
operating systems, may operate for weeks or months without a security update, and may not even
have any malware protection installed. Communication pathways for these systems can be quite
complicated, with undocumented side channels. The networks they operate on may not be well
segmented, offering little or no isolation between unrelated subsystems.
Security researchers have expressed concerns about industrial control systems being vulnerable to
cyberwarfare/cyberterrorism attacks, feeling that some operators:
• Have designed, deployed, and operated industrial control systems without attending to security
and authentication.
• Believe that industrial control systems provide "security through obscurity" because they use
specialized protocols and proprietary interfaces.
• Believe their networks are secure because they are physically secured or disconnected from the
Internet.
Case Study: Mirai Botnet

The abundance of inexpensive, connected devices deployed in the Internet of Things creates a new
platform from which cybercriminals can launch an attack. In 2016, the Mirai botnet attack disrupted
services provided by the Dyn Internet services provider, denying service to numerous popular
websites. Since the original attack, variants of Mirai have been used in various other attacks.
Mirai exploits vulnerable IoT devices, causing them to scan the internet for IP addresses of other
devices. Using a table of more than 60 default usernames and passwords, it attempts to log in to the
device. If it is successful, it infects the device, and the infection cycle continues.
Other than some sluggishness and increased use of bandwidth, infected devices continue to function
normally. The infection is not permanent; rebooting the device will clear the infection. However,
unless the device's administrative password is changed immediately, it will be reinfected by other
infected devices, which monitor a command-and-control server.
Once a botnet of infected devices is assembled, the command-and-control server can use the
devices to stage a denial of service (DoS) attack against a target. By employing so many devices,
Lesson 5: Managing Risks on IoT Projects | Topic A
Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 191
Mirai is able to bypass software intended to protect against denial of service (DoS) attacks by
monitoring the IP address of incoming requests. Normally such software would block traffic when
too many requests come from a single IP address. However, distributing the attack across many
different devices (with different IP addresses) bypasses this protection. Also, because the devices are
on different networks, much more collective bandwidth is available for an attack than if attacks
originated from one network, and attacks can't be traced back to a single origin.
Fronts of Attack
IoT systems are (by definition) typically connected to the Internet, which means they are potentially
vulnerable on many possible fronts:
• IoT devices themselves, typically on the edge of the network, may be attacked directly. For
example, an attacker may have physical access to the device, and can therefore physically attack
it, removing a memory card, pulling data from device memory, breaking the device or altering its
function, and so forth. If devices are exposed to the Internet, they can be attacked if the devices
themselves are not configured for security or if their software includes vulnerabilities.
• Edge systems such as a messaging broker or IoT gateway, attached to both the Internet and the
local network, could be a point of vulnerability.
• Networks used to communicate between IoT devices, cloud storage, applications, and other
hardware and software involved in the system can be attacked if not properly configured for
security. For example, usernames, passwords, and content transmitted over the network without
encryption could be viewed by someone monitoring network communication.
• Storage used to hold IoT data could be attacked if not secured properly. Onboard device
storage, local network storage (e.g., IoT gateway), cloud storage, or application storage all
provide possible fronts of attack.
• Databases that hold IoT data are a source of possible exposure.
• Applications that process and control IoT data and devices can be attacked.
Attack Phases and Techniques

Cyberattacks generally don't happen spontaneously, in an instant. They are often methodical,
planned out, and staged over time through various phases as the attacker systematically looks for
vulnerabilities and takes advantage of them.
Survey and Assess Phase

Attackers might perform intelligence, surveillance, and reconnaissance (ISR) activities to learn
what technologies and protocols the target uses, how it is configured, and versions of software and
hardware involved. They might perform various tests, such as seeing if any controls in a web page
echo text they enter, seeing if any logging or configuration information is exposed, and so forth.
In this early phase, attackers avoid using invasive approaches that would alert anyone to the attack.
They might perform footprinting to look for configuration information that would be helpful for
an attack, such as open ports, software components and their versions, network topology, and
similar information. Fingerprinting compares output from the target system to known "fingerprints"
that uniquely identify details about the system.
Attackers might use social engineering methods to trick users into providing helpful information
or performing helpful tasks. Techniques include:
• Phishing: The attacker sends an electronic communication (such as an email or text message),
disguising as a trustworthy entity (such as a bank official, accountant, sweepstakes administrator,
and so forth) in order to obtain sensitive information. Messages typically provide a link to a fake
website, which prompts the user to enter user names, passwords, credit card details, and so forth.
• Spearphishing: In a more individualized attack (like a fisherman trying to spear a particular
fish), an attacker might take the time to learn information about a specific victim. This supports a
more convincing attack. For example, the attacker might find out what bank the victim uses, the
company the victim works for, or the names of the victim's family members. By including this
information in communication with the victim, it gives the impression the attacker knows the
victim, and is, therefore, more trustworthy.
• Shoulder surfing/dumpster diving: The attacker spies on a user entering credentials as they
log in, or inspects items on the user's desk or garbage to look for clues that may be useful.
• Impersonation: An attacker pretends to be someone trusted enough to gain sensitive
information. For example, the attacker could call a user, pretending to be from customer service
or an IT helpdesk, asking for information that may be useful.
• Keylogging: If attackers can gain access to a user's computer, they can install a keylogger on
end user systems to track text they enter, such as usernames and passwords.
Exploit and Penetrate Phase

This phase is typically more invasive than the first phase. The attacker takes advantage of
vulnerabilities to exploit and penetrate the system. The attacker may continue to work deeper into
the system, or may opt to take advantage of the information and access gained at that point.
There are various types of network attacks an attacker might use to gain a foothold in the system,
such as:
• Wireless attack: Various forms of attack may be carried out against wireless networks to
penetrate the network or to prevent others from using it effectively.
• Spoofing attack: A software-based attack where the goal is to assume the identity of a user,
process, address, or other unique identifier with the purpose of tricking people or computers into
providing access or information that you would otherwise be unauthorized to have.
• Man-in-the-middle (MITM): An attacker secretly relays and possibly alters network
communication between two parties.
• Pharming attack: An attacker redirects one website's traffic to a fake site made to look like the
legitimate site. The redirection may be accomplished by changing the hosts file on a victim's
computer or by exploiting a vulnerability in DNS.
Malware can also be used to exploit and penetrate targets, or provide a platform for other attacks.
Types of malware include:
• Spyware: Surreptitiously installed malicious software that is intended to track and report the
usage of the target computer or device, or collect data from it.
• Virus: A piece of code that spreads itself from one computer to another by attaching itself to
other files through a process of replication, requiring human intervention to spread. Code in a
virus executes when the file it is attached to is opened.
• Worm: Like a virus, a worm replicates across the infected system. Unlike a virus, however, it
does not require human intervention and can replicate itself and does not attach itself to other
programs or files.
• Trojan horse: A trojan horse is software that appears harmless, but carries a malicious payload,
such as a virus or a backdoor.
• Ransomware: Code that restricts the victim's access to a computer or the data on it. The
attacker demands a ransom (usually through an online payment system such as PayPal or Bitcoin)
under the threat of continuing the restriction or destroying information on the locked device.
Various forms of password attacks may be performed to obtain unauthorized access to computers,
devices, and services.
• Password cracking: Recovering a secret password from data stored or transmitted by a
computer. There are various methods to accomplish this, such as brute force, dictionary attacks,
and rainbow tables.
• Password sniffing: The attacker monitors network transmissions to extract password data for
later use. This is particularly a problem when credentials are passed across the network in
unencrypted form.
Vulnerabilities in software may provide attackers with the ability to do things they should not be
allowed to do. An attacker might look for a backdoor, which provides a way to gain access to a

system without going through normal authentication methods. The backdoor may have been put in
place on purpose to support development and testing of the product, or it may result from an
oversight or programming error. In some cases, attackers may figure out a way to install their own
backdoor—for example, by issuing commands to provide elevated privileges.
Attackers use various methods to uncover software vulnerabilities, such as:
• Fuzzing: An attacker sends an application a set of random or unusual input data designed to
cause software to fail, and observes how it is handled by the application, and whether it produces
results that can be exploited.
• Cross-site scripting: An attacker takes advantage of vulnerabilities in a website's configuration
that enable malicious code from outside the site to be injected into the site's legitimate content.
• Buffer overflow: By finding ways to submit too much data to poorly written software, an
attacker may be able to cause the software to crash, so the system can't be accessed by legitimate
users, or create a condition in which the attacker can change data values in memory to perform
any number of other attacks.
Escalate Privileges Phase

Since many tasks an attacker might perform will require access privileges typically only provided to
system operators, at some point the attacker may try to gain higher access privileges of an
administrator, system, or root account.
Maintain Access Phase

At some point, attackers might want to make themselves at home and set themselves up for long-
term access. Attackers will bolster their own defenses in the system by covering their tracks (hiding
software tools they have planted, removing log entries, and so forth).
Deny Service Phase

In some cases, attackers may decide they no longer want to (or can't) maintain long-term access to
the system, and don't mind revealing their presence to stage a major attack that will embarrass or
cause damage to the victims, or will serve as a feather in their own cap. At this point, the attacker
might stage a denial of service (DoS) attack upon the system, overwhelming it with processing or
communication tasks, or otherwise destroying its ability to provide service to legitimate users. As
illustrated by the Mirai botnet attack, an attacker may enlist many different devices to perform a
distributed denial of service attack.
The OWASP Top Ten

OWASP (Open Web Application Security Project), based on input from numerous organizations
focusing on web security, has published various top 10 lists of the most common security threats
affecting web applications, mobile apps, and Internet of Things devices. Each of these areas affects
IoT systems, so OWASP is a good resource for anyone planning or implementing security related to
the Internet of Things.
Of particular interest is the OWASP top ten list for IoT.
• Injection: Injection flaws, such as Structured Query Language (SQL), Not-only Structured
Query Language (NoSQL), operating system (OS), and Lightweight Directory Access Protocol
(LDAP) injection, occur when untrusted data is sent to an interpreter as part of a command or
query. The attacker's hostile data can trick the interpreter into executing unintended commands
or accessing data without proper authorization.
• Broken Authentication: Application functions related to authentication and session
management are often implemented incorrectly, allowing attackers to compromise passwords,
keys, or session tokens, or to exploit other implementation flaws to assume other users' identities
temporarily or permanently.
• Sensitive Data Exposure: Many web applications and Application Programming Interfaces
(APIs) do not properly protect sensitive data, such as financial, healthcare, and personally
identifiable information (PII). Attackers may steal or modify such weakly protected data to
conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised
without extra protection, such as encryption at rest or in transit, and requires special precautions
when exchanged with the browser.
• External Entities (XXE): Many older or poorly configured XML processors evaluate external
entity references within XML documents. External entities can be used to disclose internal files
using the file Uniform Resource Identifier (URI) handler, internal file shares, internal port
scanning, remote code execution, and denial of service attacks.
• Broken Access Control: Restrictions on what authenticated users are allowed to do are often
not properly enforced. Attackers can exploit these flaws to access unauthorized functionality
and/or data, such as access other users' accounts, view sensitive files, modify other users' data,
change access rights, etc.
• Security Misconfiguration: Security misconfiguration is the most commonly seen issue. This is
commonly a result of insecure default configurations, incomplete or ad hoc configurations, open
cloud storage, misconfigured Hypertext Transfer Protocol (HTTP) headers, and verbose error
messages containing sensitive information. Not only must all operating systems, frameworks,
libraries, and applications be securely configured, but they must also be patched and upgraded in
a timely fashion.
• Cross-Site Scripting (XSS): XSS flaws occur whenever an application includes untrusted data
in a new web page without proper validation or escaping, or updates an existing web page with
user-supplied data using a browser API that can create Hypertext Markup Language (HTML) or
JavaScript. XSS allows attackers to execute scripts in the victim's browser that can hijack user
sessions, deface web sites, or redirect the user to malicious sites.
• Insecure Deserialization: Insecure deserialization often leads to remote code execution. Even
if deserialization flaws do not result in remote code execution, they can be used to perform
attacks, including replay attacks, injection attacks, and privilege escalation attacks.
• Using Components with Known Vulnerabilities: Components, such as libraries, frameworks,
and other software modules, run with the same privileges as the application. If a vulnerable
component is exploited, such an attack can facilitate serious data loss or server takeover.
Applications and APIs using components with known vulnerabilities may undermine application
defenses and enable various attacks and impacts.
• Insufficient Logging & Monitoring: Insufficient logging and monitoring, coupled with
missing or ineffective integration with incident response, allows attackers to further attack
systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most
breach studies show time to detect a breach is over 200 days, typically detected by external
parties rather than internal processes or monitoring.
OWASP provides a guide to these threats. Search for pdf OWASP_Top_10_2017, or open https://
www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

ACTIVITY 5-1
Identifying the Rationale for IoT Security
Scenario
An important step in determining how you will manage risks is to assess the potential consequences
should they become reality. This will help you determine where you should place your priorities, and
the effort you should expend to mitigate or avoid the risks. In this activity, you will discuss security
risks in IoT projects, and identify the rationale for focusing on security in your IoT projects.
1. What risk factors contribute to security problems with consumer IoT devices?
2. What damage might an organization incur from an attack on their IoT

systems?
Builders and Breakers

People who design and develop IoT systems operate like builders. A builder starts with a concept or a
blueprint (perhaps working from full-fledged requirements documentation—or perhaps not),
gathers raw materials (operating systems, a compiler, software libraries, reusable components,
hardware, and so forth), plans a strategy to produce the various parts and integrate them into a
whole, and develops a functioning system.
If IoT developers are builders, then attackers are breakers. A breaker starts with an attack target,
gathers information (through research, probing, and experimentation), plans a strategy to exploit
and penetrate the target, and launches one or more attacks. Whereas the builder constructs a working
system, the breaker essentially deconstructs the system.
To successfully build a system, IoT developers rely on knowledge (of various components, protocols,
APIs, development tools, and so forth), skills (such as networking, user interface design,
programming, and debugging), and experience (using various tools, strategies, and tactics, and
knowing which ones work best in various situations).
To successfully break a system, attackers rely on knowledge (vulnerabilities of various components,

protocols, languages, APIs, and so forth), skills (such as using reconnaissance tools, recognizing
vulnerabilities, and launching an effective attack), and experience (using various tools, strategies, and
tactics, and knowing which ones work best in various situations).
You can improve your ability to build secure systems by learning how to switch as needed from a
builder mindset to a breaker mindset.
For example, you have seen that code can determine whether you are reading values from a
component or writing values to the component. You might choose one option for a sensor (reading
input values from a certain pin) and another for an actuator (write output values to a certain pin).
You know how you intend to work with the component, and you act accordingly when you
configure and code the system. However, sensors and actuators simply convert energy from one
form to another and can be used as both a sensor and actuator. For example, a microphone
converts sound waves into electrical signals that can be read as an input, while a speaker converts
electrical signals into sound output. Mechanically, a speaker and microphone have essentially the
same components.
A breaker knows this and might take advantage of it, hacking the system to read input instead of
writing output, essentially using a speaker as a microphone. It was not the builder's intention to
provide an audio monitoring system, but the breaker found a vulnerability that enabled that misuse
case.
Note: This example may seem a bit far-fetched, but researchers have demonstrated various ways
such a hack can be performed on actual systems, such as "jack retasking."
As you design an IoT system, you will rightfully focus on how to make it all work. But don't forget
to also periodically examine how an attacker might make your design fail, possibly compromising
your users and data.
Case Study: Threats to MQTT Messaging

As you design and implement each part of the system, you should consider ways an attacker might
compromise it (misuse cases), and identify protections you might put into place to prevent them.
For example, with a messaging protocol such as Message Queuing Telemetry Transport (MQTT)
used to communicate between devices, there are various ways an attacker might compromise the
security of MQTT communication, such as:
• Sending the attacker's own data values
• Sending the attacker's own commands
• Intercepting and viewing messages the attacker isn't authorized to see
• Modifying messages while they are in transit between legitimate devices
• Preventing legitimate devices in the IoT system from communicating
Building Security In
As with any aspect of software quality, to ensure successful implementation, security should be dealt
with throughout the entire project lifecycle. From the very start, as you plan and identify
requirements, security requirements should be identified. Those requirements should be designed
and developed into the product, and testing should verify the requirements have been met. As you
deploy and maintain the system over time, security should be monitored and necessary updates
applied as needed to maintain security.
For example, during the design process, you should use threat modeling to systematically evaluate
your exposure to individual security threats. Although it is common for development teams to create
diagrams and documents to model how the system will work, it is less common for a development
team to model how the system might be attacked and where it will be necessary to provide
protections and countermeasures. This is the essence of threat modeling—thinking about the design
with a breaker mindset to identify where the system might be attacked, and then revisiting the design
with a builder mindset to design protections for cybersecurity and privacy.
In later phases, as you test whether the system meets functional requirements, you might also test its
ability to withstand cyberattacks—performing vulnerability assessments and penetration tests,
for example.

ACTIVITY 5-2
Identifying Security Problems in an IoT
Application
Before You Begin

The course data files are installed on your computer in C:\095024Data. These files include a
customized version of the Arduino IDE (located in C:\095024Data\Tools\arduino), which
contains example programs that you will use in this course. The example programs are contained in
the File > Sketchbook sub-menus inside the Arduino IDE.
The ESP8266 microcontroller is connected to a USB port on the development computer. You have
successfully connected the device to the Wi-Fi network, and the SSID and password are now cached
on the device. You have installed the light sensor, a 10K resistor, and a DHT11 sensor on the
breadboard.
The Arduino IDE is not running and no command-line consoles are open.
Scenario
With no encryption in the network or application, data sent between machines in the sensor
network may be at risk. In this activity, you will use a network analyzer to demonstrate how a "man
in the middle" attack could easily intercept and view data being communicated over the local sensor
network.
Figure 5-1: Unencrypted communication puts data at risk.
1. Launch the MQTT broker and a subscriber.

a) Show the Windows Start menu, type cmd, and press Enter to open a Command Prompt console.
b) Enter the title Broker command to give the Command Prompt window a title.
c) Enter the cd c:\095024Data\Tools\mqtt_broker command to change the working directory.
d) In the Broker window, enter the start "Subscriber One" cmd command to start another
Command Prompt console.

e) In the Broker window, enter the mosquitto -v command to launch the Mosquitto broker in
verbose mode.
The IoT device is still running the previous program, so messages are shown by the Broker.
f) In the Subscriber One window, enter the mosquitto_sub -t building/alldata -v command
to launch the Mosquitto broker in verbose mode.
g) Arrange the windows on your desktop so you can see both at the same time.
2. Load a sketch that publishes data values using MQTT.

a) From the Windows Start menu, select Arduino to start the Arduino IDE.
b) Select File→Sketchbook→Managing Risks on IoT Projects→MQTT_NoEncryption.
c) Close the sketch that is still open in the background so MQTT_NoEncryption is the only sketch that
is open.
Note: Leave the command windows open. You'll be using them again shortly.
3. Set the MQTT server address.

a) Revise line 9 to replace YourName with your name.
b) In line 10, change the IP address to match the IP address of your computer.
4. Start the process to compile and upload the sketch.

a) Select Tools→Serial Monitor to display the serial monitor window, and ensure the baud rate is set to
9600 baud.
b) Select Sketch→Upload.
5. Use a network analyzer to intercept and view messages in transit.

a) Once the program is running on the IoT device, view the command console windows and verify the
device is communicating with the MQTT broker and subscriber.
b) Show the Windows Start menu, type message. Right-click the tile for Microsoft Message Analyzer,
and select Run as administrator.
c) If a User Account Control prompt is shown, select Yes to confirm launching the application.
d) If you are prompted to update news items and get other updates, select Do not update items and
No, I do not want to participate, and select OK.
e) Select Start Local Trace.
f) When the filter text box is displayed, type tcp.port==1883 as shown.
g) Select Apply.

Messages should start appearing in the top list. If they do not, then press F5 to restart the session.
6. Analyze the messages.

a) After several messages appear in the top list, select Session→Stop to stop capturing messages.
b) In the top list, select one of the message rows, and in the Details 1 pane, select Payload.
The Field Data pane shows the MQTT message data in clear text.
c) In the top list, select various other rows.
In each case, you can see the data contained in the message.
7. What problems do you see in the current setup, and how might you address
them?
8. Clean up the workspace.

a) Minimize the Microsoft Message Analyzer window.

TOPIC B
Manage IoT Security and Privacy Risks
You've seen that the potential threats to cybersecurity and privacy in IoT systems are numerous.
Fortunately there are strategies you can apply to protect against these threats.
Cybersecurity Strategies
When planning protections against security and privacy risks, there are specific countermeasures you
can take to protect against specific threats. For example, OWASP provides guidelines on specific
strategies you can implement to protect against the threats identified in its top ten lists. Platform
vendors such as Microsoft, Google, and Amazon Web Services provide guidelines in their developer
community sites on using their technologies securely.
Unfortunately, the cybersecurity landscape changes continually, and there aren't cookbook
countermeasures for every threat. However, designing your system in light of general security
principles such as the CIA Triad, AAA, and Defense in Depth can help you design defenses that
hold up over time.
CIA Triad
Throughout the entire lifecycle of an IoT project, you should focus on ensuring the system provides
three aspects of security: confidentiality, integrity, and availability. Collectively, these aspects are
called the CIA triad, referring to the first letter of each one. If one of these services is
compromised, the security of users and the organization they work within are threatened.
• Confidentiality—What does the system do to keep information and communications private
and protect them from unauthorized access?
• Integrity—How does the system ensure the organization's information is ensured to be
accurate, without error, and without unauthorized modification?
• Availability—What protections ensure systems operate continuously and that authorized users
can always access the data they need?
As you design and evaluate your system, consider what you have done to promote these qualities. If
you're thinking about the design of your system from the breaker mindset, you might view these
same concerns as outlined by the DAD Triad.
• Disclosure—How might an attacker reveal information and communications intended to be
private and protected?
• Alteration—Is it possible for an attacker to perform unauthorized modification of information,
and introduce errors or defects?
• Denial—Does the system enable an attacker to cause systems to fail or perform poorly, and
prevent authorized users from accessing the data they need?
Note: To learn more about the CIA triad, check out the Spotlight on Components of the CIA
Triad presentation from the Spotlight tile on the CHOICE Course screen.
Lesson 5: Managing Risks on IoT Projects | Topic B

AAA
Figure 5-2: Authentication, authorization, and accounting.
Authentication, authorization, and accounting (AAA) work together to ensure the system has
complete control over which users or processes can access the system (authentication), what they
are allowed to access once they're in the system (authorization), and how much they consume or use
(accounting).
Authentication is the process of identifying whether someone or something (a user) should be
allowed to access the system. The user might be a human being. Or the user might be a software
process—typically a software agent performing a task on behalf of a user. Think of authentication as
essentially providing a key to the "front door" of the application.
Authorization builds on authentication by verifying the authenticated user or process has
permission to perform specific tasks within the application. Think of authorization as essentially
providing a key to various "rooms" within the application. Different users are authorized to access
different functions and data within the system. So security checks typically involve both
authentication and authorization, working together. For example, authorization checks are
essentially useless if you don't first authenticate the user. Remember to perform both checks on all
users, including backend processes.
Accounting measures the resources the user or process consumes while accessing the system, such
as the time within the system or data sent or received during a session. Accounting may be used for
billing, trend analysis, resource utilization, capacity planning, and so forth.
Defense in Depth
Various layers within the IoT architecture help provide a strong, cooperative defense. For example,
you might employ defense strategies such as the following.
• Isolated communication channels: When possible, use a secure communication channel that
is physically or logically isolated from unauthorized clients. Virtual Private Network (VPN)
technology can be used to establish an isolated communication channel when a public network
must be used.
• Authentication: Require that communicating devices provide credentials (such as username and
password, or an encrypted key certificate). Communication from unauthenticated devices will be
rejected. For example, the MQTT protocol enables you to require a client identifier, username,
and password. An application that communicates using MQTT can use this information to
determine whether to accept communications from a particular device.
• Identification and authorization: Once it has established a user's or client's identity, an
application can associate certain privileges with that identity. Some users may be allowed to do
certain advanced tasks (like changing a device's security configuration, for example, or viewing a
summary of data collected about all users), while other users may have more limited access (like
viewing a summary of data the device has collected about themselves, but not about other users).
• Network layer encryption: Where you must use public networks to communicate between
devices, use encryption to keep data within the message confidential. Also make sure that
passwords and usernames are encrypted while in transit. For example, the Transport Layer
Security/Secure Sockets Layer (TLS/SSL) protocol is typically used to encrypt traffic over the
cloud. TLS/SSL supports authentication as well as encryption.
• Application layer encryption: Some communication protocols or technologies may not directly
support authentication and encryption, so applications have to implement these features at both
ends of the communication. For example, an IoT device may encrypt data before it sends that
data over an MQTT message. The message broker just hands the encrypted message over to
subscribers without attempting to decrypt the message. The analytics program subscribing to the
data then decrypts the message, so only the device and the analytics program need to have the
information required to encrypt and decrypt the messages.
In addition to addressing different types of vulnerabilities, multiple layers of defense provide an
effective barrier to attackers by requiring them to solve multiple problems to get to their target. The
more tasks they have to perform, the more likely their presence will be detected before they can
perform significant harm.
Layered Defenses for Constrained Devices

Resource-constrained devices may be limited in the types of protection they can provide for
themselves. While robust computing devices such as servers and desktop computers are powerful
enough to provide very strong security capabilities, IoT devices may have very few resources left for
security measures after implementing their core capabilities.
In some cases, you may need to adjust where and how you implement security measures, applying
stronger measures where you have strong capabilities, and weaker measures where you have weak
capabilities. For example, you may find that resource limitations force you to implement slightly
weaker encryption or authentication capabilities on a constrained device. In such a case, you might
implement stronger protections on the device's local network to provide a suitable layered defense.
Following a defense in depth strategy, consider taking the following steps to protect constrained
devices.
• Isolate devices: Do not place weaker devices directly on the Internet. Isolate them on local
networks to reduce the attack surface and limit the spread of malware. Make sure local networks
are as secure as possible.
• Move to the edge: IoT devices could connect to a cloud server, but this requires that they are
connected to the Internet, exposing them to potential outside threats. Also, it increases the
number of local devices communicating between the local network and the cloud. By aggregating
communications locally, and then using one device, such as an IoT gateway, to communicate
with the cloud, you reduce the attack surface and streamline communications. The IoT gateway
can employ powerful hardware, enabling it to use robust encryption, authentication, and other
strong security measures.
• Manage configuration: An important strategy is putting processes and tools into place to
ensure devices are running the latest software updates, and are configured properly (for example,
not left set up with the default administrative password). Consider using the IoT gateway to
perform such security monitoring and protection tasks on behalf of IoT devices.

• Cloud security: Although local network security is an important line of defense for IoT devices,
it is also essential to ensure they cannot be indirectly reconfigured or controlled from outside
through vulnerabilities such as cross-site scripting, injection, and so forth.
• Physical security: While securing the world outside IoT devices is critical, don't neglect the
security of the device itself. Make sure it is physically secure. For example, removable memory
cards make it easy for someone with physical access to the device to extract information from it.
• Device security: Whenever possible, on your IoT devices use a system that supports secure
booting to prevent unauthorized software from being loaded onto the device during the boot
process. This should also include secure firmware update capabilities.
Note: Do your best to provide the best security possible on the device itself. For example, any
network-facing interfaces on the devices should be hardened against vulnerabilities.
Encryption on Constrained Devices

The local network used by IoT devices might be encrypted (for example, if the device is on a Wi-Fi
network using WPA2 security). Eventually, however, data from an IoT device may leave the local
Wi-Fi network and end up on an unencrypted network, such as a local Ethernet network, for
example. So you should add another layer of encryption to protect the data in transit.
Generally, encryption algorithms that are more secure require more computing resources to process.
In some cases, the high quality encryption algorithms used to provide security for data traversing the
Internet may require more processing capability than an IoT device can muster. Providing no
encryption is generally not a wise option. But at times, it may be necessary to use a less demanding
encryption algorithm and provide other protections to bolster security.
Two popular protocols currently used for encryption of Internet traffic include SSL/TLS and
Advanced Encryption Standard (AES). SSL/TLS is a robust encryption method commonly
employed for Transmission Control Protocol/Internet Protocol (TCP/IP) communications.
AES is much less demanding for a computer to process than SSL/TLS, but it is nonetheless
considered secure enough that the National Security Agency (NSA) approves its use in protecting
Top Secret information when used with 192- or 256-bit keys.
AES uses the same key to encrypt and decrypt data, which is a potential vulnerability. Because of
this, it should only be used when you control both the server and end devices.
Note: Use AES with an initialization vector (IV) to scramble the unencrypted data before
encrypting it to ensure that two identical messages won't produce identical encrypted data,
enabling an attacker to identify patterns in an encrypted data stream.
Encoding
Another form of processing that must be performed by IoT devices and other systems in the IoT
architecture is encoding. Encoding prepares data for transmission or storage. Encoding might
include some form of compression or minification to decrease the size of the message that will be
sent. It also includes putting data into a structured format easily processed by a machine, such as
XML or JSON.
In some cases, data on IoT devices may be presented in a binary form, such as an object, which is
useful for programming in a particular language (such as C++ or Java), but not for transmission
over a network. As part of the encoding process, objects may need to be serialized, or converted
into a data format that can be easily represented through text characters, such as XML or JSON.
Data Integrity
Data integrity means you are sure no third party modified contents of your communications while
they were in transit. Data that was sent matches data that was received. Using a network protocol
such as TLS/SSL or Datagram Transport Layer Security (DTLS) helps to ensure data integrity by
encrypting the message so it can't be modified in transit.
Another way data integrity can be assured is to use a checksum or digital signature, which can be
recalculated based on the received message and compared with the original to verify data integrity.
Communication and messaging protocols such as MQTT typically provide a checksum or digital
feature that software developers can use for this purpose.
Blockchain
Blockchain is a technology created to authenticate and track transactions of Bitcoin, a form of digital
money based in the cloud. With no centralized authority or bank, Bitcoin uses an online accounting
system based on a distributed open network of dedicated computers spread around the world.
Because Bitcoin was designed so no single entity would control the accounting of Bitcoin
transactions, a decentralized system needed to be developed so the integrity of the accounting data
could be verified anywhere in the network. Blockchain is that technology.
Blockchain uses a tree-like data structure distributed throughout the world. A major characteristic of
this tree structure is that, with just a small portion of the overall tree (a branch), there is enough
information to verify a transaction contained in the tree is valid and contains intact data. The
validation algorithm is computationally easy and fast to perform. Developers of IoT systems have
recognized that these characteristics provide blockchain with widespread applications for ensuring
the integrity of data in IoT.
Advocates of using blockchain technologies in IoT list the following benefits:
• Transparent: Blockchain provides a permanent, immutable record of transactions as items pass
between points in the supply chain. Activities can be tracked and analyzed by anyone authorized
to connect to the network. If a problem occurs, the blockchain record makes it straightforward
to identify where the breakdown occurred.
• Trusted: Since data is encrypted and distributed, it can be trusted by parties involved in the
transaction. Humans cannot falsify the record with inaccurate data.
• Smart: Some blockchain networks enable the creation of agreements triggered by certain
conditions, enabling payments to occur immediately when certain conditions have been met.
• Secure: Attackers would have to bypass blockchain's security layers, which use some of the most
robust encryption standards available.
Privacy
The EU General Data Protection Regulation (GDPR) took effect in 2018, providing privacy
protections for all citizens of the European Union. The law focuses on information organizations
may obtain from customers and how that information must be protected. The law specifies that
organizations must obtain users' permission to process data through a clear affirmation by the user,
follow "privacy by design" rules, and report any data breaches. Special care must be taken when
handling the personal data of children. Consumer IoT devices (such as smart speakers, personal
fitness trackers, smart home devices, and connected cars) are especially affected by this law.
While this law protects citizens of the European Union, it applies to organizations throughout the
world who handle their data.
Privacy by Design
Privacy by Design is an approach to software development that takes privacy into account
throughout every phase of development. The underlying premise of Privacy by Design is not simply
protecting data, but as much as possible designing software so data doesn't need protection—for
example, minimizing data collected in the first place.

Privacy by Design was initially proposed by Ann Cavoukian, the Information & Privacy
Commissioner of Ontario, Canada, as a set of seven principles, described here.
Item Description
1. Proactive not Data privacy should be considered early and often (throughout the entire
Reactive; Preventative development lifecycle) not just after there is a problem.
not Remedial
2. Privacy as the Default As initially installed, the application should be as private as possible. The
Setting user must opt in to decrease privacy to less private settings. By default,
restrictions are placed on sharing, data collection, and data retention.
3. Privacy Embedded Privacy should be built into the design of the software. It should be
into Design explicitly included in processes like requirements identification, threat
modeling, user interface design, testing, and so forth.
4. Full Functionality— Customers value privacy. It is part of the value that customers pay for.
Positive-Sum, Not
Zero-Sum
5. End-to-End Security Privacy protections should follow the data wherever it goes—when it is
—Full Lifecycle first created, shared with others, archived, and deleted.
Protection
6. Visibility and Privacy practices should be clear and overt, so users can have confidence
Transparency—Keep it in their privacy expectations. Policies and mechanisms should be in place
Open to ensure users can address problems and have them resolved efficiently.
7. Respect for User Users own their data. Data held in the software should be accurate, and
Privacy—Keep it User- the user must have the power to correct errors. The user can grant and
Centric revoke consent on the use of the data.
Data Anonymization
To maintain privacy, personally identifiable information (PII) may need to be anonymized before it
is transmitted, processed, or analyzed. This means the identity associated with personal data has
been masked somehow to conceal the person associated with the data.
Firmware and Software Countermeasures

Make sure all layers of software on IoT devices are secure. This includes the device's firmware,
operating system, and application software running on the device.
Manufacturers may release firmware and other security updates for microcontrollers. If possible, use
only microcontrollers that employ a cryptographic bootloader to support a secure update process.
Only updates that can be validated through an encryption key will be installed. Make sure each
device is using the most secure version of the firmware (typically assumed to be the latest version).
The operating system (if any) used on a device should be hardened for security. This includes
various processes intended to reduce the attack surface and provide layers of defense, such as
removing unneeded services, protocols, and system features, closing unused communication ports,
and so forth.
Programs developed for devices should be designed, developed, tested, deployed, and maintained
following secure coding practices. This includes security by design (including threat modeling), code
reviews, various forms of testing, and continuous monitoring for security events.

Case Study: Protecting MQTT Messaging

Many MQTT brokers and software libraries include support for authentication, authorization, and
encryption. If these are supported by your MQTT broker and devices, this may be the most direct
way to provide layers of security for MQTT messaging. In some cases, not all of these features may
be provided or practical to use. However, you may be able to implement features in other layers of
software. For example, you may opt to provide encryption in the network and application layers
when you can't do so through MQTT. Whatever approach you use, you should consider how data
will be protected at every stage in the end-to-end communication, to ensure multiple layers of
protection are provided.
Guidelines to Prevent IoT Vulnerability Defects

Follow these guidelines to prevent critical Internet of Things security risks identified by OWASP.
Note: All of the Guidelines for this lesson are available as checklists from the Checklist tile on
the CHOICE Course screen.
Provide a Secure Web Interface

Web-based administrative consoles provided for managing IoT devices may include common
vulnerabilities that might apply to any web application. To avoid this defect, make sure web-based
administrative consoles:
• Are configured to install with the safest default settings, assuming many users will not change the
configuration.
• Enable default user names and passwords to be changed, and prompt the user to do so upon
first use.
• Require strong passwords.
• Provide an account lockout feature after a certain number of failed access attempts.
• Use HTTPS to protect transmitted information.
• Use web application firewalls.
• Provide a means to receive upgrades and security fixes.
• Adhere to all general patterns for preventing web vulnerabilities.
• Do not include common web vulnerabilities. Refer to the OWASP Top 10 Web Vulnerabilities
(https://www.owasp.org/index.php/Top_10-2017_Top_10) for a list of common
vulnerabilities you should prevent.
Provide Secure Network Services

Network infrastructure supporting IoT devices might be misconfigured and vulnerable. To avoid
this defect:
• Use threat modeling and other brainstorming techniques to identify ways the network might be
compromised, and take all measures necessary to remove or disable unneeded services, protect
required services, detect malicious activity, and react to an attack with measures such as lock-outs
or temporary firewall rules.
• Do not use Universal Plug and Play (UPnP) to make network ports and/or services available to
the Internet.
• Make sure devices and network services are configured to minimize open network ports.
• Make sure devices and network services are protected against DoS attacks.
• Use tested, proven, networking stacks and interfaces that handle exceptions gracefully.
• Disable or protect all test or maintenance interfaces.
• Do not expose unauthenticated protocols or channels, such as Trivial File Transfer Protocol
(TFTP) and Telnet.
• Where possible, relegate IoT devices to a separate, firewalled, monitored network.
Protect Data in Transit

To ensure that data is protected while in transit:
• Ensure all communication between system components is encrypted as well as encrypting traffic
between the system or device and the Internet.
• Use encrypted protocols to protect data in transit, or encrypt data before transmitting it.
• Use properly configured and up-to-date SSL/TLS.
• Use standard, robust encryption protocols.
Protect Privacy
To ensure that personal information and privacy are protected:
• Minimize data collection.
• Consult with data scientists and legal and compliance teams to determine risk of data collection
and storage.
• Provide end users the option to specify what data will be collected.
• Use encryption to protect all collected personal data at rest and in transit.
• Ensure that collected personal information is accessible only by authorized users.
• Ensure that a data retention policy is in place.
• Anonymize collected data, using one of the following techniques to mask the identifying data:
• Replacement: Substitute any values that could be used to identify the user with different
values.
• Suppression: Omit (all or in part) any values that could be used to identify the user.
• Generalization: Substitute specific values that could be used to identify the user with
something less specific. For example, generalize the date of birth to the year or decade in
which the user was born.
• Perturbation: Make random changes to the data to corrupt values that could be used to
identify the user.
Provide Secure Cloud and Mobile Interfaces

Cloud APIs and web interfaces are vulnerable to attack. Mobile applications that manage or
communicate with IoT devices are also vulnerable. To avoid these defects:
• Review all cloud and mobile interfaces for security vulnerabilities.
• Implement multi-factor authentication.
• Require strong, complex passwords.
• Provide an account lockout feature after a certain number of failed access attempts.
• Ensure that all cloud and mobile interfaces use transport encryption.
Provide Flexible Security Configuration

Consumers may have different security requirements, and those requirements may change over time.
Design IoT projects with secure defaults and allow consumers to select options to be enabled or
disabled. Design systems to allow for the detection of malicious activity, as well as self-defending
capabilities and a reaction plan should a compromise be detected. Make sure your devices provide
options to:
• Disable functions that are not used or required to reduce the attack surface.
• Control security logging capabilities.
• Configure alerts and notifications for security events.
• Select and configure strong encryption.
• Configure security alerts for administrators and end users.
• Control password security (such as enabling longer passwords or multi-factor authentication).
• Design products so improvements can be added to a system or device through future releases,
updates, and patches.
Provide Secure Software/Firmware on IoT Devices

To maintain the security of IoT devices over time, it is critical to plan for patches and updates. It is
important to protect confidentiality, integrity, and availability when providing updates. Make sure
that IoT devices you release:
• Can be updated quickly when vulnerabilities are discovered.
• Are updated through secure update servers.
• Require updates to be signed (code signing) and verify those updates before installing them.
• Discard updates that are not properly delivered or signed.
• Provide a mechanism for issuing, updating, and revoking cryptographic keys as well.
Physically Secure IoT Devices

IoT devices should be protected from direct physical access by an attacker. Make sure your devices:
• Provide external ports (e.g., USB) only when absolutely essential.
• Limits access to external ports (through an authentication process, for example).
• Have operating systems that are properly protected.
• Can be configured to limit administrative capabilities, preferably defaulting to least privilege.
• Are tamper resistant.
• Do not expose any testing or debugging interfaces that can be used to gain unauthorized access.
• Account for the transfer of ownership of devices to ensure that data is not transferred along with
the ownership.
Prevent Configuration Vulnerabilities

To prevent configuration vulnerabilities in your hosting platforms:
• Review all switches and configuration settings to ensure the safest possible configuration.
• Remove or disable all unnecessary features (services, accounts, privileges, ports, etc.).
• Change default passwords for pre-configured accounts.
• Define a repeatable (preferably automated) process to quickly and easily provision and harden
the configuration of a new deployment environment.
• Configure development, testing, and production environments the same way (but with different
passwords).
• Define and adhere to a process for monitoring and patching vulnerabilities of all services and
components in each deployed environment, and performing timely updates.
• Design a strong application architecture that securely separates components to minimize security
problems across component boundaries in the event a misconfiguration should appear at any
time.
• Run scans and perform audits periodically (automatically, if possible) to help detect future
misconfigurations or missing patches.
• Use the most secure configuration for database connection strings. Use trusted connections, and
do not use cleartext passwords. If possible, use a password hash instead of cleartext credentials.
• Configure network transmissions to use secure encryption. Use SSL, Secure Shell (SSH), and
other forms of encryption (such as encrypted database connections) to prevent data from being
intercepted or interfered with over the wire.
• Configure data storage to use secure encryption. Encrypt file, object, and database storage.
• Some information security policies and standards require the database on-disk data to be
encrypted. However, this is essentially useless if the database connection allows clear text access
to the data.
• Configure passwords to be stored only in a non-reversible format.
• If possible, configure services to not store sensitive data such as PII and credit cards at all.
Prevent Vulnerabilities in Virtual Machine Infrastructure

There are a number of security concerns involved with using virtual machine environments, such as
cloud platforms. Work with cloud services providers and the features they provide to implement the
following security controls:
• Make sure that a patch management system is in place to ensure all relevant patches are
installed. This is especially important for any patches released that apply to the virtualization
software itself. Also, carefully determine when and if general operating system patches should
also be installed on the host and guests.
• Provide the minimum access needed in virtual machines and virtual networks to meet
requirements. This will limit potential damage if security is breached. Monitor access to all
environments on a regular basis to prevent unauthorized access.
• Log and review user and system activities in the virtual environment to check for irregular
activity and any possible security breaches.
• Pay special attention to how you configure virtual networking devices, enabling network
connectivity between systems only when necessary. Note that the security capabilities of virtual
networking appliances may not be exactly the same as a physical device. For example, virtual
switches in certain modes may fail to isolate traffic between host and guest or guest and guest in
a virtual infrastructure.
• Consistently capture snapshots, or the state of the virtual environment at a certain point in
time, to provide a quick and easy way to recover the entire environment should it be
compromised.
• Carefully monitor the number of virtual machines to avoid VM sprawl, which occurs when
the number of virtual machines exceeds the organization's ability to control or manage all of
those virtual machines. A compromised VM could easily slip by your notice if you're dealing with
VM sprawl. One of the best ways to avoid VM sprawl is to use a VM lifecycle management
(VMLM) solution. VMLM solutions provide you with a centralized dashboard for maintaining
and monitoring all of the virtual environments in your organization.
• Protect against VM escape, which occurs when an attacker executes code in a VM that allows
an application running on the VM to "escape" the virtual environment and interact directly with
the hypervisor. The attacker may be able to access the underlying host operating systems and
thereby access all other VMs running on that host machine. The best way to protect against VM
escape is to ensure that your virtualization software is kept up-to-date. You can also attempt to
limit the resource sharing functionality between host and guest.

ACTIVITY 5-3
Protecting Data in Transit
Before You Begin

breadboard.
The Arduino IDE is running. In separate command-line consoles, the Broker and Subscriber One
windows are open. The Mosquitto broker is running, and Subscriber One is subscribed to building/
alldata. Microsoft Message Analyzer is running in a minimized window.
Scenario
Encryption protects data in transit. In this activity, you will provide application layer encryption
using AES. You will analyze network traffic to affirm it is no longer readable.
1. Load a sketch that performs application level encryption of MQTT messages.

a) Select File→Sketchbook→Managing Risks on IoT Projects→MQTT_Encrypted.
b) Close the Arduino IDE window that is still open in the background so MQTT_Encrypted is the only
sketch still open.

3. While you compile and upload the sketch, examine the code that encrypts
and decrypts message data.
a) Select Sketch→Upload.

b) Examine lines 32 through 43.
• This code defines variables that will be used for AES encryption.
• AES uses symmetric encryption. The same key is used on both ends of communication, so the
key must be protected on both ends.
• In this example, the encryption key (line 34) is hard-coded for demonstration purposes only.
• One strategy for ensuring the security of keys involves generating a new key at the start of each
session. Programmers should use tools provided by the platform for this purpose.

c) Examine how outgoing messages are encrypted in lines 56 through 87.
Data is first encrypted. Then the encrypted bytes are encoded as hexadecimal strings so they can
be transferred as plain text without communication problems that might occur because of control
characters in the message.

d) Examine how incoming messages are decrypted in lines 115 through 148.
Decoding and decryption of incoming messages reverse the processes performed on the outgoing
messages. The hexadecimal values are decoded into bytes that make up the cipher. Then the
cipher is decrypted back to the original values.
4. When the program is uploaded to the device, examine the output.

a) Examine the Subscriber One command console.
• The data is encrypted. Client applications would have to decode and decrypt the data to
consume it.
• Over time, you might notice the patterns of some encrypted values are repeated. With the same
algorithm and inputs, the same output is produced. Even though the content is encrypted, an
attacker may be able to recognize patterns, which can be a problem.
• This example uses symmetric encryption—which uses the same key for encryption and
decryption.
• In some circumstances, you might use asymmetric encryption, which uses one key to encrypt
and another to decrypt. By using asymmetric encryption, it is possible to have one of the keys be
public (doesn't matter if everyone knows it) and the other private (must be kept secret on one
end of the communication).
• Asymmetric encryption can make it easier to manage keys because only one end of the
communication (a server, for example) needs to keep the key secret.
5. Examine stages in encryption and decryption.

a) In the serial monitor, examine the sequence in which outgoing messages are encrypted and
incoming messages are decrypted.
Note: You can uncheck Autoscroll so you can focus better on a single entry. If
you do, you may need to check this option again later to restore the scrolling
feature.
• This trace listing shows the sequence of data being sent out by the sensor application to the
MQTT broker, and later received back (because the sensor application subscribed to the same
message it published to).
• The payload is sent across the network as text representing the hexadecimal values of each byte
in the cipher text.
• When the message is returned, the hexadecimal values are decoded back to cipher bytes. Then
the cipher is decrypted.
6. Minimize the Arduino IDE.

a) Minimize the Arduino IDE and serial monitor windows.
b) Leave the command consoles running as they are.
The IoT device is still sending messages to the broker, and Subscriber One is still receiving them.
7. Capture messages in a new Message Analyzer session.

a) Restore the Microsoft Message Analyzer window.
b) Select Session→Restart to capture messages in a new session.
c) After several messages have been captured, select Session→Stop.
8. Analyze the messages.

a) In the top list, select one of the message rows, and in the Details 1 pane, select Payload.
• The Field Data pane shows the MQTT message data in encrypted text.
• You can see the topic, but the data is unreadable.
• This would help to prevent a man-in-the-middle attack, as intercepted data on the network would
not reveal its content.
b) Select File→Exit to exit Message Analyzer.
c) Select Close without saving to exit without saving your changes.

ACTIVITY 5-4
Preventing Unauthorized Use of Messaging
Services
Before You Begin

breadboard.
The Arduino IDE and is running in a minimized window, and the serial monitor is showing. In
separate command-line consoles, the Broker and Subscriber One windows are open. The Mosquitto
broker is running, and Subscriber One is subscribed to building/alldata.
Scenario
The IoT device is still running and sending messages to the MQTT broker. To prevent
unauthorized access to messages through the MQTT broker, you will configure the broker to
require authentication.
1. a) In Windows File Manager, view the files in C:\095024Data\Tools\mqtt_broker.
• Mosquitto.conf is a configuration file. You can specify a configuration file when you run Mosquitto
to override the default configuration.
• Passwords.txt contains user names and passwords.
• Mosquitto_passwd.exe is an executable file that enables you to manage the usernames and
encrypted passwords stored in the passwords file.

b) Open mosquitto.conf in Windows Notepad.
Most of the settings in this configuration file have been commented out with hash symbols, but the
first two settings specify that anonymous logins will not be allowed, and provide the name of the
password file.
c) In Windows Notepad, open passwords.txt.
• Three username and password sets have already been provided in this file, for users named
roger, sub_client, and pub_client.
• The stored passwords are encrypted.
• Mosquitto provides the mosquitto_passwd.exe program, which you can use to add more
usernames and encrypted passwords. You will add another user named iot_device.
d) Exit Notepad.
2. Define an MQTT username and password for the IoT device.

a) In the Broker command console, press Control+C to exit Mosquitto.
b) In the Broker command console, enter the mosquitto_passwd -b passwords.txt
iot_device Password!123 command.
This will create a new user named iot_device with the password Password!123. The password will
be encrypted in the file.
c) In Windows Notepad, open passwords.txt.
The iot_device username has been added. The password you provided is encrypted so someone
reading this file will not be able to determine the password.
d) Exit Notepad.
3. Relaunch the MQTT Broker to require authentication.

a) In the Broker command console, enter the mosquitto -c mosquitto.conf -v command.
b) Observe the messages now appearing in the Subscriber One command console.
Since passwords are now required, the subscriber is no longer able to connect to the broker.
4. Relaunch the MQTT subscriber to provide a username and password.

a) In the Subscriber One command console, press Control+C to exit Mosquitto.
You may have to press Control+C twice for the console to respond.
b) In the Subscriber One command console, enter the mosquitto_sub -t building/alldata -
v -u sub_client -P P@ss!Subscribe5 command.
The subscriber has successfully subscribed, but the broker is still showing errors because the IoT
device has not provided a password.
5. Launch the IoT device with the new MQTT password.

a) Restore the Arduino IDE MQTT_Encrypted window, and select File→Sketchbook→Managing Risks
on IoT Projects→MQTT_EncryptAndAuth.
b) Close the Arduino IDE window that is still open in the background so MQTT_EncryptAndAuth is the
only sketch still open.


c) Examine the username and password provided in lines 13 and 14.
The password is shown in cleartext in the source code. As with other credentials, these would need
to be provided to the application in a secure way that can't be extracted from the device, similar to
how you encrypted the password in the passwords.txt file.
7. Start the process to compile and upload the sketch, and observe how
communication resumes with authentication in place.
a) Select Sketch→Upload.
b) When the program runs on the device, observe that communication has resumed in the message
broker and the subscriber. Publishers and subscribers must now use a password to connect to the
MQTT broker.
8. Clean up the workspace.

a) Exit the Arduino IDE.
b) Close the Broker and Subscriber One command windows.
c) Close any Notepad and File Explorer windows.

TOPIC C
Manage IoT Safety Risks
In addition to cybersecurity and privacy risks, IoT may also present various safety risks.
Physical/Loss of Life Accidents

Proponents of IoT focus on its potential to improve our lives. Not only do they envision ways that
IoT will improve our lives, in some cases IoT may even save lives. In fact, analysts estimate that IoT has
the potential to save thousands of lives every year simply by reducing errors and improving
information flow in healthcare. This is not to mention lives saved by preventing traffic accidents,
reducing lives lost to disasters, and so forth.
But technologists have come to accept there is a law of unintended consequences; whenever you introduce
change to complex systems, you may make improvements, but it is likely that you will also create
unanticipated and undesirable outcomes in the process. It is possible that dependence on poorly
secured or faulty IoT systems may in some cases lead to accidents, loss of life, and disasters. The
potential for this has already been demonstrated numerous times.
Medical devices may be vulnerable. In 2017, the U.S. Food and Drug Administration confirmed that
a vulnerability affecting pacemaker and defibrillator implants made it possible for the devices to be
hacked, enabling an attacker to deplete the battery, change the heart rate pacing, or deliver shocks to
the victim's heart.
Smart vehicles may be vulnerable. In 2015, a hacker named Charlie Miller demonstrated to a
reporter for Wired magazine that through remote access, he could hack a connected vehicle's IoT
systems, operating the radio, climate system, windshield wipers, and—alarmingly—disable its
accelerator. The potential for hacking autonomous (self-driving) vehicles seems even greater,
although it may be harder to accomplish as these vehicles are more complicated and designed with
greater security than the typical connected vehicle.
Energy infrastructure may be vulnerable. In 2014, Reuters reported that hackers had successfully
shut down a floating oil rig by tilting it. Malware rendered a separate rig incapable of operation. It
took operators 19 days to restore it to operation. In 2015, USA Today reported that from October
2010 to October 2014, U.S. Department of Energy systems were successfully attacked more than
150 times. Clearly attackers are targeting these systems. While these systems employ defense in
depth, there is potential that a breach in security might enable attackers to disrupt or shut down
systems, or create even worse problems.
Other areas with a significant potential for physical attack and loss of life include waste treatment
and water supply facilities, hospitals, and other medical facilities.
In designing IoT systems, it is important to understand that the risks associated with these systems
may affect more than data or privacy. Physical damage and loss of life are real possibilities that must
be managed. IoT will put stress on existing infrastructure, generating more network traffic and
requiring time and attention to keep things operating properly, and it will increase the global attack
surface, providing cyberattackers with new opportunities to cause dangerous problems.
Infrastructure Outages
Infrastructure outages provide both challenges and opportunities for IoT. Poorly secured or faulty
IoT systems may contribute to the possibility of outages, and mass power or Internet outages may
have a debilitating effect if we become completely dependent on IoT. On the other hand, IoT also
has the potential to improve the efficiency and performance of the Internet, power grid, and other
infrastructure. For example, data gathered from IoT sensors can be used to improve the resilience of
the grid. IoT can monitor physical systems such as transmission lines, transformers, generators, and
Lesson 5: Managing Risks on IoT Projects | Topic C
so forth, and can implement corrections immediately when outages occur. Utilities can use this data
to actively manage resources and make informed decisions about power usage and generation to
predict and prevent problems.
Supply Chain Risks

Many organizations have begun to use IoT in their supply chain to reduce costs, and improve
productivity and customer service. IoT is helping organizations with schedule optimization, fleet
management, and routing. Shipments can be rerouted automatically to deal with changes in traffic,
weather, and other factors. Inventory can be tracked to its precise location.
However, as with other IoT applications, supply chain automation is a two-edged sword. In addition
to the benefits IoT provides, it also carries certain risks. As data passes across networks and through
devices that may be vulnerable, an attacker might be able to disrupt operation of the supply chain, or
to destroy or steal volumes of proprietary and sensitive data.
With the ability to hack the supply chain, an attacker might replace products in transit with the
intention of stealing legitimate products, executing a terrorist attack by replacing legitimate products
with chemical, biological, radiological, nuclear, or explosive payloads, introducing counterfeit or
substandard parts into the supply chain, and so forth. Or an attacker's intention may be simply to
disrupt logistics, preventing products from reaching their intended destination on time.
Data leakage is a significant problem. The ability to observe the supply chain of a competitor or
potential victim organization can reveal key relationships, products and components, shipping
volumes, and destinations. This information can provide a competitor or attacker with significant
insight into the company's business operations.
Data may be leaked when passing between various systems and networks unless data protection is
enforced at every layer and phase of processing—when data is at rest (in storage), in transit, and
crossing system boundaries. In some cases, even when traffic is encrypted, just the patterns of
movement can be revealing.
These risks are mitigated by managing IoT security and privacy risks in every phase of the IoT
development lifecycle, through threat modeling, security by design, defense in depth, actively
monitoring vulnerability reports published by US-CERT and platform vendors, and other
cybersecurity best practices.
IoT Safety Risk Management

Many of the safety risks involved in IoT derive from the fact that IoT uses software to monitor and
control the physical world. So a large part of IoT risk management involves software. Employing
secure development life cycle practices goes a long way toward preventing potential safety risks
related to IoT.
However, there is also a physical (non-software) aspect to IoT that must be managed as well, and
which may not lend itself to software risk management approaches. Various methods have been
applied in business and industry to manage risks and promote quality in general. Many of these
approaches are applied to managing IoT safety risks and are described here.
Item Description
Quality management This term was coined in 1991 by Ken Croucher, a British management
systems (QMS) consultant working on designing and implementing a generic model of a
QMS within the IT industry. It refers to a system of organizational goals
and aspirations, policies, processes, documented information, and
resources that enable an organization to consistently meet customer
requirements and enhance their satisfaction. The ISO 9000 family of
standards is probably the most widely known and used example of QMS.

Item Description
Root cause analysis A method of problem solving that focuses on identifying a problem's
(RCA) catalyst. While specific methods are described, essentially you perform
RCA by starting with the problem and asking, "What was the immediate
thing that enabled this to happen?" With each answer, you ask the
question iteratively to work your way toward the fundamental problem,
or root cause, that set the bad sequence of events into motion.
Corrective and CAPA is part of an overall quality management system. It provides a set
preventive action of actions an organization must take to correct and eliminate recurring
(CAPA) problems. Underlying problems are identified through a root cause
analysis. The corrective and preventive action is designed by quality
assurance personnel and those in a position to recognize the problem
when it occurs. There is a systematic process for evaluating the CAPA's
ability to eliminate further occurrences of the problem. In some
industries, such as medical devices and pharmaceuticals, CAPA is
required by regulations to be a part of the organization's QMS.
Hazard analysis and HACCP is a QMS originally developed to protect food in production
critical control points from biological, chemical, and physical hazards. HACCP focuses on
(HACCP) problem prevention, and is used throughout the chain from food
production through preparation processes including packaging and
distribution. HACCP is mandated by the U.S. Food and Drug
Administration (FDA) and Department of Agriculture (USDA) for juice
and meat production.
Safety certification Various organizations provide certifications in safety standards, such as
Certified Safety Professional (CSP), CRSP (Canadian Registered Safety
Professional), and the International Institute of Risk and Safety
Management (IIRSM) certifications. Requirements for these certifications
include such things as educational credentials, field experience, and
passing one or more examinations. Each of these programs defines
standards and best practices for safety management.

ACTIVITY 5-5
Identifying Safety Risks and Remediations
Scenario
Medical IoT devices provide many benefits and have the potential to transform the way patients are
diagnosed, monitored, and cared for. A device with such potential is a new category of infusion
pumps that automatically administer a prescribed dosage of a drug into a patient. These devices are
intended to reduce human error by ensuring that the dosage is administered at the correct time, and
in the correct amounts. The devices are connected to a drug library containing information
regarding the proper dosage amounts.
A researcher evaluated one of these pumps and unfortunately found a number of vulnerabilities.
The device did not have to authenticate when connecting to the drug library. This provides an
attacker with the ability to alter drug dosage upper limits beyond those specified by the drug library.
Also, the device can be directly controlled from a PC by connecting through a serial cable connected
to the communication module and circuit board. The pumps do not require authentication or
genuine signed certificates for updates, so the firmware can be updated and exploited by an attacker.
This would give the attacker the ability to reprogram and control the device.
Two patients at a hospital in Austria had to be treated for morphine addiction after they hacked
their infusion pumps to increase their dosage. One of the patients suffered respiratory arrest because
of the high dosages. The hack did not require advanced hacking tools or extensive skills. The patient
bypassed the device's weak authentication to log in, and found online documentation that provided
the control codes for the machine.
1. What attack scenarios might be possible if a device such as an infusion pump

is not properly designed or configured?
2. What steps should be taken to assure a device like this doesn't facilitate such
attacks?

Summary
In this lesson, you identified security and privacy risks in IoT systems, strategies to keep IoT systems
secure and to protect the privacy of users, and strategies to avoid or mitigate IoT-related safety risks.
How can you ensure that you've thoroughly implemented all of the protections
that your application requires?
What processes does your organization have in place to identify and manage
privacy, security, and safety risks related to IoT?
Note: Check your CHOICE Course screen for opportunities to interact with your classmates,
peers, and the larger CHOICE online community about the topics covered in this course or
other topics you are interested in. From the Course screen you can also access available
resources for a more continuous learning experience.
Note: To learn more about steps you can take to secure your IoT products, check out the
Spotlight on IoT Security presentation from the Spotlight tile on the CHOICE Course screen.
Lesson 5: Managing Risks on IoT Projects |

Managing Risks On IoT Projects

Uploaded by

Copyright:

Available Formats

Managing Risks On IoT Projects

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Managing Risks On IoT Projects

Uploaded by

Copyright:

Available Formats

190 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Managing Risks on IoT

The Rationale for IoT Security

Case Study: Mirai Botnet

Attack Phases and Techniques

Survey and Assess Phase

Exploit and Penetrate Phase

Lesson 5: Managing Risks on IoT Projects | Topic A

Escalate Privileges Phase

Maintain Access Phase

Deny Service Phase

The OWASP Top Ten

Lesson 5: Managing Risks on IoT Projects | Topic A

2. What damage might an organization incur from an attack on their IoT

Builders and Breakers

To successfully break a system, attackers rely on knowledge (vulnerabilities of various components,

Case Study: Threats to MQTT Messaging

Lesson 5: Managing Risks on IoT Projects | Topic A

Before You Begin

Figure 5-1: Unencrypted communication puts data at risk.

1. Launch the MQTT broker and a subscriber.

Lesson 5: Managing Risks on IoT Projects | Topic A

2. Load a sketch that publishes data values using MQTT.

3. Set the MQTT server address.

4. Start the process to compile and upload the sketch.

5. Use a network analyzer to intercept and view messages in transit.

f) When the filter text box is displayed, type tcp.port==1883 as shown.

Lesson 5: Managing Risks on IoT Projects | Topic A

6. Analyze the messages.

8. Clean up the workspace.

Lesson 5: Managing Risks on IoT Projects | Topic A

Lesson 5: Managing Risks on IoT Projects | Topic B

Figure 5-2: Authentication, authorization, and accounting.

Layered Defenses for Constrained Devices

Lesson 5: Managing Risks on IoT Projects | Topic B

Encryption on Constrained Devices

Lesson 5: Managing Risks on IoT Projects | Topic B

Firmware and Software Countermeasures

Lesson 5: Managing Risks on IoT Projects | Topic B

Case Study: Protecting MQTT Messaging

Guidelines to Prevent IoT Vulnerability Defects

Provide a Secure Web Interface

Provide Secure Network Services

Protect Data in Transit

Provide Secure Cloud and Mobile Interfaces

Provide Flexible Security Configuration

Provide Secure Software/Firmware on IoT Devices

Physically Secure IoT Devices

Prevent Configuration Vulnerabilities

Prevent Vulnerabilities in Virtual Machine Infrastructure

Lesson 5: Managing Risks on IoT Projects | Topic B

Before You Begin

1. Load a sketch that performs application level encryption of MQTT messages.

2. Set the MQTT server address.

Lesson 5: Managing Risks on IoT Projects | Topic B

b) Examine lines 32 through 43.

Lesson 5: Managing Risks on IoT Projects | Topic B

c) Examine how outgoing messages are encrypted in lines 56 through 87.

Lesson 5: Managing Risks on IoT Projects | Topic B