Lesson 

1  of  7
Data collection and communication

How IoT devices communicate with each other, or whether they do, depends on what you want
to derive from the data. The majority of raw data that IoT devices create is unstructured. Without
some context defining what the data is and why the data is being collected, the raw data is of
little use on its own. You have business questions that only the data can answer.

Data collected from the device and analyzed against the contextual information is used to
improve processes, predict failure, and monitor health and well-being. Deploying smart sensors,
smart cameras, and smart devices provides convenience and operational efficiency. If the data
from these devices isn't being gathered, processed, analyzed, and acted upon, then this lack of
data analysis takes the "smart" out of smart devices. 

This ability to gather data from hundreds or thousands of individual devices and use that data to
make intelligent decisions driven by quantifiable, measurable data, is a unique benefit of running
an IoT infrastructure. Companies no longer have to gather data manually, make best guess
estimations about their production lines and equipment efficiency, or have production equipment
fail without warning. The IoT data allows for real-time metrics and predicative analysis so that
equipment can be replaced or repaired without impacting production workflows or product.
The first step is to determine the questions you want your data to answer and how best to gather
and analyze that data. The type of data gathered depends on the type of device, the purpose of the
device, and the questions that the company is looking to answer. Whether the data is forwarding
directly to AWS IoT Core or processed at the edge using AWS IoT Greengrass, or if your IoT
devices need to communicate directly, these questions need to be answered. The answers
determine the best data collection and analysis solution for your company. 
The speed at which the data is uploaded is also important. Millisecond latency on an
industrial device can mean the difference between equipment failing and impacting the
whole production line, and predicting and responding to the failure before it becomes an
issue. If the communication speed and fast analysis of the data is essential to operations,
the IoT data must be processed where the devices live. To achieve cost-savings or the
quickest response time, you can process and filter edge device data before storing it in the
AWS Cloud.

How data moves from IoT device to the AWS Cloud  

With vast amounts of data being generated, moved, and stored, how do ensure the
security of that data as it moves across the network? Securing the communications
channels ensures that data in transit is not intercepted, modified, or deleted. This is a
critical part of creating an end-to-end IoT security solution. Next, you'll review the
requirements of a secure communications channel.
Lesson 2  of  7
Securing communication
IoT data can be intercepted if an unauthorized user establishes themselves on the network in a
position to intercept the data. This is called a man-in-the-middle attack, and it occurs when an
unauthorized user has gained access to the network using malware, insecure protocols, or social
engineering. After they've gained access, this unauthorized user now has access to steal or
manipulate messages and data. It is critical to use an beginning-to-end security model for
protecting data in transit.
Security model with AWS IoT

Device:

AWS creates a complete security model for IoT, starting with the operating system for
microcontrollers called Amazon FreeRTOS. The Amazon version of FreeRTOS has been
extended to include libraries that secure device data and connections, including support for data
encryption and key management. Amazon FreeRTOS includes support for Transport Layer
Security (TLS v1.2) to help devices connect securely to the AWS Cloud. 

TLS is a cryptographic protocol that uses security algorithms to provide secure communications
over a network.

Device to AWS iOT core

Data moving between AWS IoT Core and other AWS services is protected as it moves into the
AWS Cloud. During TLS client authentication, AWS IoT requests a client X.509 certificate and
validates the certificate’s status and AWS account against a registry of certificates. It then
challenges the client for proof of ownership of the private key that corresponds to the public key
contained in the certificate.
To use AWS IoT certificates, clients must support all of the following in their TLS
implementation:
 TLS 1.2
 SHA-256 RSA certificate signature validation
 One of the cipher suites listed under the TLS Cipher Suite Support in the AWS IoT
Developer Guide.

AWS IoT Core to the cloud

The AWS IoT rules engine can then forward device data to other devices and AWS services according to
customer-defined rules. AWS access management systems are used to securely transfer data to its final
destination. 

MQTT security
AWS IoT Core supports HTTP, WebSocket, and MQTT. MQTT is a lightweight
communication protocol specifically designed to tolerate intermittent connections. If you
are connecting to the AWS IoT message broker using MQTT, each connection must be
associated with an identifier known as a client ID. MQTT client IDs uniquely identify
MQTT connections. If a new connection is established using a client ID that is already
claimed for another connection, the AWS IoT message broker drops the old connection to
allow the new connection. You can use authorization features in AWS IoT Core to ensure
that a device in your fleet is not unintentionally authorized to disconnect other devices by
opening MQTT connections with client IDs that are already in use. Client IDs must be
unique within each AWS account and each AWS Region, so you do not need to enforce
global uniqueness of client IDs outside of your AWS account or across Regions within
your AWS account.

The AWS IoT message broker enables clients to communicate with AWS IoT and for AWS IoT
to communicate with clients. Clients send data by publishing a message on a topic. Clients
receive messages by subscribing to a topic. When the message broker receives a message, it
forwards the message to all clients subscribed to the topic.

The message broker supports the use of the MQTT protocol to publish and subscribe and the
HTTPS protocol to publish. Both protocols are supported through IP version 4 and IP version 6.
The message broker also supports MQTT over the WebSocket protocol. How you connect to the
message broker depends on the protocol you are using. Different protocols require different
authentication mechanisms. 
The following table shows each protocol supported by AWS IoT, the authentication method, and port used for each protocol.
Protocol Authentication Port ALPN Protocol Name
MQTT X.509 client certificate 8883, 443 x-amzn-mqtt-ca
HTTPS X.509 client certificate 8883, 443 x-amzn-http-ca
HTTPS SigV4 443 N/A
 Protocol Authentication Port ALPN Protocol Name
MQTT over WebSocket SigV4 443 N/A

For a deep dive on MQTT and TLS, choose MQTT and TLS authentication.
AWS MQTT and TLS
MQTT with TLS client authentication on port 443: Why it is useful and how it works
MQTT AND TLS AUTH...

Creating secure topics

The message broker uses topics to route messages from publishing clients to subscribing clients.
Topics consist of one or more topic levels separated by a forward slash (/). Common practice is
to create a topic from general to most specific, for example, city/building/basement/device.

 It is a best practice to keep topics concise, use lower cases lettering, document your naming
conventions, and not to use personally identifiable information. 

What if you want to make your topics specific and identifiable?  You can do this if you choose;
however, if you want security in all layers of your IoT environment, then you want to make it
difficult for someone to identify your devices if they compromise your network. Designing topic
names with no personal identifiers makes an unauthorized user's job harder. And that's your goal
in securing your systems—making it hard for someone who seeks to do harm. 
Designing MQTT Topics for AWS IoT Core 
This whitepaper focuses on best practices for designing MQTT topics in AWS.
MQTT WHITEPAPER
Now that we've discussed MQTT protocol security and securing topics, let's explore how you
secure the data on disk.

Appendixes

The Internet of Things on AWS – Official Blog

MQTT with TLS client authentication on port
443: Why it is useful and how it works
by Jared Sharfin | on 07 FEB 2018 | Permalink |  Share

The AWS IoT Core service now allows you to connect devices using MQTT with TLS client
authentication on port 443.  Previously this combination of protocol and authentication
mechanism was only supported on port 8883.  So what’s the big deal? Read on to learn more
about how this feature makes it easier to connect your devices or skip to the final section to learn
how you can start taking advantage of it today.

443, 8883 – What’s the difference?

TCP connections are typically associated with a combination of IP address and port number.
This immediately raises the question of which port number to use to ensure that your application
can communicate with other 3rd party applications. To solve this problem, the Internet Assigned
Numbers Authority (IANA) maintains a mapping of TCP and UDP port numbers to various
messaging protocols that have registered with the organization. While this is not a canonical list,
these standards are widely adopted, especially for more popular protocols. A quick search of
their database shows that port 443 is the registered port for HTTP over TLS (i.e. internet traffic)
and 8883 is the registered port for MQTT over TLS. AWS IoT Core complies with these
standards as much as possible (see here), but as we have learned from our customers, there are
scenarios where it makes sense to deviate from them.

Corporate firewalls and even some home routers often restrict inbound and outbound traffic to be
transmitted over a small range of TCP ports. This is done as a security measure to limit the attack
surface for possible cyber attacks. Standard ports for things like HTTPS traffic (port 443) are left
open but others that are used for less common protocols, such as MQTT (port 8883) may be
intentionally blocked. If you are manufacturing IoT devices that will ultimately be used in IT
environments that you do not control, this can cause serious headaches. For example, if you
manufacture medical devices that are sold to hospitals around the country, you do not want to
have to negotiate separately with each hospital’s IT department to open port 8883 in their
firewall so that your devices can connect to your IoT application running on AWS IoT Core. It
just so happens that there is a standard extension to the TLS protocol that can help with precisely
this issue.

ALPN – One port to rule them all

Application Layer Protocol Negotiation (ALPN) is an extension to TLS defined by RFC

7301 that is supported by many of the most common TLS implementations. ALPN enables
clients connecting to a TLS server to pass an extra parameter, known as a ProtocolNameList, as
part of the ClientHello message during the TLS handshake. The ProtocolNameList is a
preference ordered list of the application protocols that the client would like to use to
communicate. As part of the ServerHello message, the TLS server selects one protocol from this
list that will be used to transmit application data over the connection.

The full TLS handshake including the ALPN extension works as follows:

Client Server

ClientHello -------->
(ALPN extension &
list of protocols)
ServerHello
(ALPN extension &
selected protocol)
Certificate*
ServerKeyExchange*
CertificateRequest*
 <-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data

* Indicates optional or situation-dependent messages that are not

always sent.

AWS IoT Core supports a special ProtocolName, “x-amzn-mqtt-ca”, that enables clients to
specify that they will be using MQTT with TLS client authentication. It is necessary to use this
special value instead of just “MQTT” because in addition to signalling which application
protocol the client will be using, AWS IoT Core also uses the ProtocolName to signal that it
should send a CertificateRequest as part of the TLS handshake. If the client were to send a
certificate without AWS IoT Core requesting it, the TLS specification dictates that AWS IoT
Core should terminate the handshake.

How can I connect my devices on port 443 using MQTT?

1. Ensure your device’s TLS client implementation supports the ALPN extension.
o Consult the manual to be certain, but this Wikipedia page provides a handy list.
o Amazon FreeRTOS source code supports the ALPN extension.
2. Register your device with AWS IoT Core by creating, activating, and downloading a
certificate or bring your own certificate.
3. Configure the ALPN extension on your device with the “x-amzn-mqtt-ca” protocol*.
4. Connect to AWS IoT Core on port 443.

*NOTE: Currently “x-amzn-mqtt-ca” is the only supported ALPN ProtocolName and it is only
supported on port 443. The most up to date mappings can always be found on the Protocols
page in the AWS IoT Core Developers Guide

TAGS: AWS IoT
Lesson 3  of  7
Securing data
To create a complete security model, data in transit and the data sitting in storage needs to be
encrypted. This means that any unauthorized access doesn't result in the data being modified,
stolen, or deleted. Vast amounts of data is collected in an IoT environment. You've learned how
to use secure protocols between devices and the AWS IoT Core to ensure that the
communication channels are not easily compromised. Now explore the actual physical data and
how you can ensure that it can't be read while in transit or at rest. 

Encryption basics
In an IoT environment, the data is constantly being gathered in transit from devices to the AWS
IoT Core, moving from the AWS IoT Core to the AWS Cloud, or securely saved in a storage
solution, database, or other AWS resource. The most fundamental part of keeping data secure is
the use of encryption. 

Unencrypted data is called plaintext. Because it is in its original form, the data is easily read and
understood. Encryption occurs when an algorithm (a mathematical equation) is run against the
plaintext data. The algorithm scrambles (encrypts) the information into a series of random letters
and numbers. The algorithm used to scramble the data is called a cipher, and the scrambled data
is called ciphertext. To read the data, the receiving computer/person must unscramble (decrypt)
the data. The encryption/decryption process uses a pair of corresponding keys that are generated
to use one particular type of algorithm to modify the data.   

TLS and cipher suite

A cipher suite is the type of encryption algorithms used to establish a secure connection. When
data is encrypted in transit using TLS, the TLS handshake requires that the device and gateway
agree on the cipher suite used. By using encryption on the data before it moves across the
connection, anyone who intercepts the data in transit will not be able to read the ciphertext. 

If the IoT device does not support encryption (for example, an industrial piece of equipment that
was put into production 30 years ago), you can limit the device's network activity to short-range
areas or zones within the network. These short-range zones are called a boundary. Security can
be implemented to encrypt and secure the data as it passes between the boundaries. When the
data is encrypted, anyone intercepting the data in transit will not be able to read it, regardless of
whether it was from a new smart device or an older piece of insecure production equipment.

Protecting data using server-side encryption

Amazon S3 server-side encryption is about securing or encrypting data at rest—that is, Amazon
S3 encrypts your data at the object level as it writes it to disks in its data center. When you need
to read it, Amazon S3 will decrypt the data for you when you access it. As long as you
authenticate your request and you have access permissions, there is no difference in the way you
access encrypted or unencrypted objects. For example, if you share your objects using a
presigned URL, that URL works the same way for both encrypted and unencrypted objects.

By default, all S3 buckets are private and can be accessed only by users who are explicitly
granted access. When using AWS, it's a best practice to restrict access to only the people who
absolutely need it.

Three options are available, depending on how you choose to manage the encryption keys. You
cannot apply different types of server-side encryption to the same object simultaneously. Let's
explore the three server-side encryption options:

Amazon S3-Managed Keys (SSE-S3)

–

Each object is encrypted with a unique key. As an additional safeguard, the key itself is
encrypted with a master key that is regularly rotated. Amazon S3 server-side encryption uses one
of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to
encrypt your data. 

Keys stored in AWS Key Management Service (SSE-KMS)

–

Similar to SSE-S3, but with some additional benefits and additional charges for using AWS Key
Management Service (AWS KMS). There are separate permissions for the use of an envelope
key (that is, a key that protects your data's encryption key), which provides added protection
against unauthorized access of your objects in Amazon S3. SSE-KMS also provides you with an
audit trail of when your key was used and by whom. Additionally, you can create and manage
encryption keys yourself, or use a default key that is unique to you, the service you're using, and
the Region you're working in. 

Customer-provided Keys (SSE-C)

–

You manage the encryption keys and Amazon S3 manages the encryption, as it writes to disks,
and decryption, when you access your objects

If your use case requires encryption during transit, Amazon S3 supports the HTTPS protocol,
which encrypts data in transit to and from Amazon S3. All AWS SDKs and AWS tools are
designed to use HTTPS by default. Another way to transmit IoT data securely is through
Amazon Kinesis Data Streams. Let's review how Amazon Kinesis can work with your IoT
environment.

Amazon Kinesis and IoT data

Amazon Kinesis is a platform for streaming data on AWS, offering key capabilities to cost-
effectively process streaming data at any scale. Monitoring IoT devices in real time can provide
valuable insight that helps you maintain the reliability, availability, and performance of your IoT
devices.

Track real time Data

You can track time series data on device connectivity and activity. This insight helps you react quickly to
changing conditions and emerging situations.
Gaining data insight
AWS offers the Real-Time IoT Device Monitoring with the Amazon Kinesis Data Analytics solution.
This is a reference implementation that automatically provisions the services necessary to collect, process,
analyze, and visualize IoT device connectivity and activity data in real time. 
Continuous Data intake
You can use Amazon Kinesis Data Streams for rapid and continuous data intake and aggregation. Kinesis
Applications can run real-time analytics on high-frequency event data, such as sensor data collected by
Kinesis Data Streams. This enables you to gain insights from your data at a frequency of minutes instead
of hours or days. You can have mobile applications push data to Kinesis Data Streams from hundreds of
thousands of devices, making the data available to you as soon as it is produced on the mobile devices. 

Data protection in Amazon Kinesis Data Streams

Server-side encryption is a feature in Amazon Kinesis Data Streams that automatically
encrypts data before it's at rest by using an AWS KMS customer master key (CMK) you
specify. Data is encrypted before it's written to the Kinesis stream storage layer, and
decrypted after it’s retrieved from storage. As a result, your data is encrypted at rest
within the Kinesis Data Streams service. This enables you to meet strict regulatory
requirements and enhance the security of your data.

With server-side encryption, you don't need to manage master keys or cryptographic
operations. Your data is automatically encrypted as it enters and leaves Kinesis Data
Streams, so your data at rest is encrypted. AWS KMS provides all the master keys that
are used by the server-side encryption feature. 
Amazon Kinesis data security
This documentation shows you how to configure Kinesis Data Analytics to meet your security
and compliance objectives.
SECURITY BEST PRA...

Amazon Kinesis and IoT role alias

Getting data into AWS Cloud requires devices to authenticate and authorize against the
respective AWS services. Typically, these authentication requests use the AWS Signature
Version 4 algorithm (SigV4), which requires the requestor to have both an access key ID
and secret access key. This requires you to hardcode the access key ID and the secret
access key onto the device. As an alternative, there is a way to use the built-in X.509
certificate as the unique device identity. 

AWS IoT credentials provider allows a device to authenticate AWS requests by

providing an X.509 certificate and then a temporary, limited-privilege security token is
created for authenticating to AWS. The token can be used to sign and authenticate any
AWS request. 
For applications to connect to Kinesis Data Streams, you can create an IoT role alias to
manage temporary credentials. A role alias is an alternative data model pointing to an
IAM role. The credentials provider request must include a role alias name to indicate
which IAM role to assume for obtaining a security token from AWS Security Token
Service (AWS STS). You can update the role alias on the server to point to a different
IAM role, making your device obtain a security token with different permissions.

Authorizing direct calls to AWS services

For more information on creating and using an IoT role alias.
IOT ROLE ALIAS

Authorizing Direct Calls to AWS

Services
PDF
Kindle

Devices can use X.509 certificates to connect to AWS IoT using TLS mutual
authentication protocols. Other AWS services do not support certificate-based
authentication, but they can be called using AWS credentials in AWS Signature
Version 4 format. The Signature Version 4 algorithm normally requires the caller to
have an access key ID and a secret access key. AWS IoT has a credentials provider
that allows you to use the built-in X.509 certificate as the unique device identity to
authenticate AWS requests. This eliminates the need to store an access key ID and a
secret access key on your device.

The credentials provider authenticates a caller using an X.509 certificate and issues a
temporary, limited-privilege security token. The token can be used to sign and
authenticate any AWS request. This way of authenticating your AWS requests
requires you to create and configure an AWS Identity and Access Management (IAM)
role and attach appropriate IAM policies to the role so that the credentials provider
can assume the role on your behalf. For more information about AWS IoT and IAM,
see Identity and Access Management for AWS IoT.

The following diagram illustrates the credentials provider workflow.

1. The AWS IoT device makes an HTTPS request to the credentials provider for a
security token. The request includes the device X.509 certificate for authentication.
2. The credentials provider forwards the request to the AWS IoT authentication and
authorization module to validate the certificate and verify that the device has permission to
request the security token.
3. If the certificate is valid and has permission to request a security token, the AWS IoT
authentication and authorization module returns success. Otherwise, it sends an exception to
the device.
4. After successfully validating the certificate, the credentials provider invokes the AWS
Security Token Service (AWS STS) to assume the IAM role that you created for it.
5. AWS STS returns a temporary, limited-privilege security token to the credentials
provider.
6. The credentials provider returns the security token to the device.
7. The device uses the security token to sign an AWS request with AWS Signature
Version 4.
8. The requested service invokes IAM to validate the signature and authorize the request
against access policies attached to the IAM role that you created for the credentials provider.
9. If IAM validates the signature successfully and authorizes the request, the request is
successful. Otherwise, IAM sends an exception.

The following section describes how to use a certificate to get a security token. It is
written with the assumption that you have already registered a device and created
and activated your own certificate for it.

How to Use a Certificate to Get a Security Token

1. Configure the IAM role that the credentials provider assumes on behalf of your device.
Attach the following trust policy to the role.
2. {
3. "Version": "2012-10-17",
4. "Statement": {
5. "Effect": "Allow",
6. "Principal": {"Service": "credentials.iot.amazonaws.com"},
7. "Action": "sts:AssumeRole"
8. }
}

For each AWS service that you want to call, attach an access policy to the role. The credentials
provider supports the following policy variables:

 credentials-iot:ThingName
 credentials-iot:ThingTypeName
 credentials-iot:AwsCertificateId

When the device provides the thing name in its request to an AWS service, the credentials
provider adds credentials-iot:ThingName and credentials-iot:ThingTypeName as context
variables to the security token. The credentials provider provides credentials-
iot:AwsCertificateId as a context variable even if the device doesn't provide the thing name
in the request. You pass the thing name as the value of the x-amzn-iot-thingname HTTP
request header.

These three variables work for IAM policies only, not AWS IoT policies.

9. Make sure that the user who performs the next step (creating a role alias) has
permission to pass the newly created role to AWS IoT. The following policy gives
 both iam:GetRole and iam:PassRole permissions to an AWS user.
The iam:GetRole permission allows the user to get information about the role that you've just
created. The iam:PassRole permission allows the user to pass the role to another AWS service.
10. {
11. "Version": "2012-10-17",
12. "Statement": {
13. "Effect": "Allow",
14. "Action": [
15. "iam:GetRole",
16. "iam:PassRole"
17. ],
18. "Resource": "arn:aws:iam::your aws account id:role/your role
name"
19. }
}
20. Create an AWS IoT role alias. The device that is going to make direct calls to AWS
services must know which role ARN to use when connecting to AWS IoT. Hard-coding the
role ARN is not a good solution because it requires you to update the device whenever the role
ARN changes. A better solution is to use the CreateRoleAlias API to create a role alias that
points to the role ARN. If the role ARN changes, you simply update the role alias. No change
is required on the device. This API takes the following parameters:
roleAlias

Mandatory. An arbitrary string that identifies the role alias. It serves as the primary
key in the role alias data model. It contains 1-128 characters and must include only
alphanumeric characters and the =, @, and - symbols. Uppercase and lowercase
alphabetic characters are allowed.
roleArn

Mandatory. The ARN of the role to which the role alias refers.
credentialDurationInSeconds

Optional. How long (in seconds) the credential is valid. The minimum value is 900
seconds (15 minutes). The maximum value is 3,600 seconds (60 minutes). The
default value is 3,600 seconds.

For more information about this API, see CreateRoleAlias.

21. Attach a policy to the device certificate. The policy attached to the device certificate
 must grant the device permission to assume the role. You do this by granting permission for
the iot:AssumeRoleWithCertificate action to the role alias, as in the following example.
22. {
23. "Version": "2012-10-17",
24. "Statement": {
25. "Effect": "Allow",
26. "Action": "iot:AssumeRoleWithCertificate",
27. "Resource": "arn:aws:iot:your
region:your_aws_account_id:rolealias/your role alias"
28. }
}
29. Make an HTTPS request to the credentials provider to get a security token. Supply the
following information:
 Certificate: Because this is an HTTP request over TLS mutual authentication,
you must provide the certificate and the private key to your client while making the request.
Use the same certificate and private key you used when you registered your certificate with
AWS IoT.

To make sure your device is communicating with AWS IoT (and not a service impersonating
it), see Server Authentication, follow the links to download the appropriate CA certificates,
and then copy them to your device.

 RoleAlias: The name of the role alias that you created for the credentials
provider.
 ThingName: The thing name that you created when you registered your AWS
IoT thing. This is passed as the value of the x-amzn-iot-thingname HTTP header. This value
is required only if you are using thing attributes as policy variables in AWS IoT or IAM
policies.

Run the following command in the AWS CLI to obtain the credentials provider endpoint for
your AWS account. For more information about this API, see DescribeEndpoint.

aws iot describe-endpoint ‐‐endpoint-type iot:CredentialProvider

The following JSON object is sample output of the describe-endpoint command. It contains

the endpointAddress that you use to request a security token.

{
"endpointAddress":
 "your_aws_account_specific_prefix.credentials.iot.your
region.amazonaws.com"
}

Use the endpoint to make an HTTPS request to the credentials provider to return a security
token. The following example command uses curl, but you can use any HTTP client.

curl ‐‐cert your certficate --key your device certificate key pair -H "x-amzn-iot-

thingname: your thing name" --cacert AmazonRootCA1.pem https://your endpoint /role-
aliases/your role alias/credentials

This command returns a security token object that contains an accessKeyId,

a secretAccessKey, a sessionToken, and an expiration. The following JSON object is sample
output of the curlcommand.

{"credentials":{"accessKeyId":"access key","secretAccessKey":"secret
access key","sessionToken":"session token","expiration":"2018-01-
18T09:18:06Z"}}

You can then use the accessKeyId, secretAccessKey, and sessionToken values to sign requests

to AWS services. For an end-to-end demonstration, see How to Eliminate the Need for Hard-
Coded AWS Credentials in Devices by Using the AWS IoT Credential Provider blog post on
the AWS Security Blog.

Amazon Kinesis is only one of the tools that you can use to secure and monitor your data while
in transit and at rest. The ability to secure your devices, their communication path, the data on
the internet and on the disk enables you build and a complete security model for your IoT
environment. 

What is the best way to monitor and detect any anomalies or abnormal behavior in your IoT
devices or their communication channels? Next, explore the monitoring options available in
AWS, how they work with IoT, and how they can ease your administrative overhead.
Lesson 4  of  7
Student exercise

AWS IoT design

A well-established manufacturing company is in the planning and testing phase for a new IoT
solution for their factories. The company’s original security was based on isolation, with each
factory being its own closed environment with limited internet and no wireless capabilities. They
have recently finished deploying a wireless infrastructure to support their new smart sensors,
thermostats, and other IoT devices within their main facility. This first location is the POC test
for the rest of the facilities, and they feel that they need a better grasp on the security concepts
before going live on this first factory. They have presented you with four pressing questions that
they cannot answer. They need you to make recommendations or to confirm that they have
designed the IoT solution based on security best practices.

Their objective is to verify security of their communications channels and of their data.  

Communication protocols

The company's design document states that each IoT device should be configured to use HTTP
when data is traversing from the device to the AWS IoT message broker. From an AWS IoT
support and security standpoint, which of the following options is better ?

 Drag the protocols into the appropriate bucket. 

Not supported or not secure

 Zigbee
 LLAM
 MQTT Over SOAP
 WebSockets

Supported and secured

 MQTT over Websockets

 MQTT over TLS
 HTTPS with SigV4
 Data storage with Amazon S3
 The first group of IoT test devices are storing their data in an Amazon S3 bucket.
Currently, all devices and IAM users can access the bucket from the facility or
from home (using public access) using the Everyone group. Public access was
configured as a test but was not changed after confirmation that the data was
properly stored and could be retrieved.  Their manager said, "If it's not broken,
don't fix it."
While discussing their bucket permissions, you notice that along with the Everyone
group, they've assigned multiple individual IAM users and applications with access to the
Amazon S3 bucket. 
IoT data security

The last question they have for you is how best to use encryption in their environment.
Now that the IoT devices are sending data in transit using the encryption you suggested,
they want to know more about securing the data at rest.  
The customer is happy with the information you've provided. Their IoT environment is
secure, and they are confident in their AWS solution. Well done!

Lesson 5  of  7
Best practices
 1
Use standard cryptographic network protocols, such as TLS, to protect your data in transit.
 2
Use AWS IoT role aliases for direct calls from IoT devices to AWS services other than AWS
IoT Core.
 3
For devices that cannot support cryptographic network protocols, limit their network activity to
short-range connections within network-level trust boundaries.
 4
Identify and mitigate issues with entry points in your IoT environment that can facilitate
unauthorized access.
 5
Constantly review access, and create mechanisms to assess the credentials and permissions of
your IoT environment.
Lesson 6 of 7
Knowledge check
Answer the following questions to assess what you've learned.
START QUIZ
encrypts