AWS wellarchitected high security documentation change
Summary
Updated IoT security documentation with expanded guidance on device identity management, secure credential storage, TLS 1.3 adoption, certificate lifecycle management, and enhanced authentication/authorization practices. Added structured best practice sections (IOTSEC01-BP01 through IOTSEC05-BP01) with risk levels and prescriptive implementation details.
Security assessment
Changes directly address security controls for IoT devices including: mandatory unique identities to prevent credential cloning, hardware-based credential storage (TPM/secure elements) to mitigate physical tampering risks, TLS 1.3 adoption for modern encryption, certificate rotation to limit exposure from expired/compromised credentials, and least privilege enforcement. Explicit warnings about high-risk scenarios (e.g., 'Level of risk exposed: High' in IOTSEC01-BP01) demonstrate concrete security impact.
Diff
diff --git a/wellarchitected/latest/iot-lens/identity-and-access-management.md b/wellarchitected/latest/iot-lens/identity-and-access-management.md index 947d717a5..fcf3c30ce 100644 --- a//wellarchitected/latest/iot-lens/identity-and-access-management.md +++ b//wellarchitected/latest/iot-lens/identity-and-access-management.md @@ -3 +3,3 @@ -[Documentation](/index.html)[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/)[AWS Well-Architected Framework](abstract-and-introduction.html) +[Documentation](/index.html)[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/)[AWS Well-Architected Framework](iot-lens.html) + +IOTSEC01-BP01 Assign unique identities to each IoT deviceIOTSEC02-BP01 Use a separate hardware or a secure area on your devices to store credentialsIOTSEC02-BP02 Use a trusted platform module (TPM) to implement cryptographic controlsIOTSEC02-BP03 Use protected boot and persistent storage encryptionIOTSEC03-BP01 Implement authentication and authorization for users accessing IoT resourcesIOTSEC03-BP02 Decouple access to your IoT infrastructure from the IoT applicationsIOTSEC04-BP01 Assign least privilege access to devicesIOTSEC05-BP01 Perform certificate lifecycle management @@ -7 +9 @@ -IoT devices are often a target because they are provisioned with a trusted identity, might store or have access to strategic customer or business data (such as the firmware itself), might be remotely accessible over the internet, and might be vulnerable to direct physical tampering. To provide protection against unauthorized access, you need to always begin with implementing security at the device level. From a hardware perspective, there are several mechanisms that you can implement to reduce the attack surface of tampering with sensitive information on the device such as: +IoT devices frequently face elevated security risks. There are several reasons for this. Devices are often provisioned with a trusted identity. Devices may store or have access to strategic customer or business data (such as the firmware itself). Devices may be remotely accessible over the internet. Devices may be subject to to direct physical tampering. To provide protection against unauthorized access, you need to always begin with implementing security at the device level. From a hardware perspective, there are several solutions that you can implement to reduce the risk of tampering with sensitive information on the device such as: @@ -9 +11 @@ IoT devices are often a target because they are provisioned with a trusted ident - * Hardware cryptographic modules + * Hardware crypto modules @@ -15 +17 @@ IoT devices are often a target because they are provisioned with a trusted ident - * Up-to-date cryptographic libraries and standards including PKCS #11 and TLS 1.2 + * Up-to-date cryptographic libraries and standards including PKCS #11 and TLS 1.2/1.3 @@ -20 +22 @@ IoT devices are often a target because they are provisioned with a trusted ident -To secure device hardware, you implement solutions such that private keys and sensitive identity are unique to, and only stored on the device in a secure hardware location. Implement hardware or software-based modules that securely store and manage access to the device's private key corresponding to its public key and X.509 certificate. FreeRTOS, AWS IoT Greengrass, and the AWS IoT Device SDKs support this through the use of PKCS#11. In addition to hardware security, IoT devices must be given a valid identity, which will be used for authentication and authorization in your IoT application. +To secure device hardware, you should implement solutions so that private keys and sensitive device identity information are unique to a device and stored only in a secure hardware location on the device. You should implement unique device identities using public-private key pairs. An X.509 certificate containing a public key represents the identity of the device. The corresponding private key is used by the device to prove that it corresponds to that identity. Implement hardware or software-based modules that securely store and manage access to the device's private key corresponding to its public key and X.509 certificate. FreeRTOS, AWS IoT Greengrass, and the AWS IoT Device SDKs support this through the use of PKCS#11. In addition to hardware security, IoT devices must be given a valid identity, which will be used for authentication and authorization in your IoT application. @@ -22 +24 @@ To secure device hardware, you implement solutions such that private keys and se -During the lifetime of a device, you will need to be able to manage certificate renewal and revocation, update device firmware and software. To handle any of these changes, you must first have the ability to update a device in the field. The ability to perform firmware updates, software updates and configuration updates on hardware is a vital underpinning to a well-architected IoT application. Through OTA updates, you can securely rotate device certificates before expiry including certificate authorities and update firmware and software. +During the lifetime of a device, you will need to be able to manage certificate request, renewal and revocation, as well as update device firmware and software. To handle these changes, you must first have the ability to update a device in the field. The ability to perform firmware updates, software updates and configuration updates on hardware is a vital underpinning to a well-architected IoT application. Through over the air (OTA) updates, you can securely rotate device certificates before expiry. OTA can also be used to update trusted certificate authorities and update firmware and software. @@ -24 +26 @@ During the lifetime of a device, you will need to be able to manage certificate -For example, with AWS IoT, you first provision X.509 certificate and then separately create the IoT permissions for connecting to IoT, publishing and subscribing to messages, and receiving updates. This separation of identity and permissions provides flexibility in managing your device security. During the configuration of permissions, you can ensure that any device has the right level of identity as well as the right level of access control by creating an IoT policy that restricts access to MQTT actions for each device. +For example, with AWS IoT, you first provision a X.509 certificate identifying the device and then separately create the IoT permissions for connecting to AWS IoT Core, publishing and subscribing to messages, and receiving updates. This separation of identity and permissions provides flexibility in managing your device security. During the configuration of permissions, you can make sure that the device has the correct identity (authentication) as well as the right level of access control (authorization) by creating an IoT policy that restricts access to MQTT actions for each device. @@ -26 +28 @@ For example, with AWS IoT, you first provision X.509 certificate and then separa -Ensure that each device has its own unique X.509 certificate in AWS IoT and that devices never share certificates (one certificate for one device rule). In addition to using a single certificate per device, when using AWS IoT, each device must have its own unique thing in the IoT registry, and the thing name is used as the basis for the MQTT ClientID for MQTT connect. +Make sure that each device has its own unique X.509 certificate. Each device should have a unique public-private key pair. The private key should, if possible, be generated on the device and never leave the secure storage area where it was generated on the device. Devices should never share keys or certificates used for identification (one certificate for one device rule). In addition to using a single key or certificate per device, each device must have its own unique thing identifier in the IoT registry. In AWS IoT Core, by default, the thing name is used as the basis for the MQTT ClientID for MQTT connect. It is possible to separate Thing name and ClientID if necessary. @@ -28 +30 @@ Ensure that each device has its own unique X.509 certificate in AWS IoT and that -Devices must support rotation and replacement of certificates to ensure continued operation as certificates expire. +Every X.509 certificate has an expiration. This includes certificates representing certificate authorities, including root certificate authorities. Devices must support the replacement of trusted root and intermediate certificate authorities. Devices must also support refresh and replacement of the certificate, which represents the identity of the device. This helps to support continued operation of the device including the ability to authenticate to AWS IoT Core. @@ -30 +32 @@ Devices must support rotation and replacement of certificates to ensure continue -By creating this association where a single certificate is paired with its own thing in AWS IoT Core, you can ensure that one compromised certificate cannot inadvertently assume an identity of another device. It also alleviates troubleshooting and remediation when the MQTT ClientID and the thing name match since you can correlate any ClientID log message to the thing that is associated with that particular piece of communication. +By creating this association where a unique key or certificate is paired with each thing in AWS IoT Core, you can make sure that one compromised certificate cannot inadvertently assume an identity of another device. It also assists in logging (auditing), troubleshooting and remediation of incidents. If the MQTT ClientID and the thing name are different, you must plan to have a way to correlate between thing name and ClientID. This is necessary to work with log messages associated with device communication. @@ -32 +34 @@ By creating this association where a single certificate is paired with its own t -To support device identity updates, use AWS IoT Jobs, which is a managed service for distributing OTA communication and binaries to your devices. AWS IoT Jobs is used to define a set of remote operations that are sent to and run on one or more devices connected to AWS IoT. AWS IoT Jobs by default integrates several best practices, including mutual authentication and authorization, device tracking of update progress, and fleet-wide wide metrics for a given update. +To support device identity updates, use AWS IoT Jobs. AWS IoT Jobs is a managed service for distributing OTA updates and binaries to your devices. AWS IoT Jobs is used to define a set of remote operations that are sent to and executed on one or more devices connected to AWS IoT Core. AWS IoT Jobs by default integrate several best practices, including mutual authentication and authorization, device tracking of update progress, logging or auditing, and fleet-wide wide metrics for jobs that are scheduled to be run across fleets of devices. @@ -34 +36 @@ To support device identity updates, use AWS IoT Jobs, which is a managed service -Use native provisioning mechanisms to onboard devices when they already have a device certificate (and associated private key) on them. For example, you can use just-in-time provisioning (JITP) or just-in-time registration (JITR) that provisions devices in bulk when they first connect to AWS IoT. +Use native provisioning mechanisms to onboard devices when they already have a device key or certificate provisioned onto them. For example, you can use just-in-time provisioning (JITP) or just-in-time registration (JITR) that provisions devices when they first connect to AWS IoT Core. @@ -36 +38 @@ Use native provisioning mechanisms to onboard devices when they already have a d -If the devices cannot use X.509 certificates, or you have an existing fleet of devices with a proprietary access control mechanism, that requires use of bearer tokens such as OAuth over JWT or SAML tokens, use custom auth mechanisms. For example, when a device attempts to connect to AWS IoT, it sends a JWT generated by their identity provider in the HTTP header or query string. The signature is validated by AWS IoT custom authorizer and the connection is established. +If the devices cannot use X.509 certificates, or you have an existing fleet of devices with a proprietary authentication or access control mechanism, use custom authentication or authorization mechanisms. One example of this is the use of bearer tokens such as OAuth over JWT or SAML 2.0 tokens for authenticating communications. For example, a device which sends a JSON web token (JWT) generated by their identity provider in the HTTP header or query string when it attempts to connect to AWS IoT Core. The signature, validity, issuer, and audience of the JWT (in addition to other custom claims) must be validated by an AWS IoT custom authorizer before the connection is established. @@ -38 +40 @@ If the devices cannot use X.509 certificates, or you have an existing fleet of d -It is important to use a standard set of naming conventions when designing device name and MQTT topics. For example, use the same client identifier for the device as the IoT Thing Name. This will also allow to include any relevant routing information for the device in the topic namespace. +It is important to use a standard set of naming conventions when designing device names and MQTT topics. For example, we recommend using the same client identifier for the device as the IoT Thing Name. This will also allow to include relevant routing information for the device in the topic namespace. @@ -40 +42 @@ It is important to use a standard set of naming conventions when designing devic -Enable AWS IoT Device Defender audits to track device configuration, device policies, and checking for expiring certificates in an automated fashion. For example, Device Defender can run audits on a scheduled basis and trigger a notification for expiring certificates. With the combination of receiving notifications of any revoked certificates or pending expiry certificates, you can automatically schedule an OTA that can proactively rotate the certificate. +Enable AWS IoT Device Defender audits to track device configuration, device policies, and checking for expiring certificates in an automated fashion. For example, AWS IoT Device Defender can run audits on a scheduled basis and initiate a notification for expiring certificates. With the combination of receiving notifications of revoked certificates or certificates nearing expiration, you can automatically schedule an OTA update using AWS IoT Jobs that can proactively rotate or refresh the certificate. @@ -42 +44 @@ Enable AWS IoT Device Defender audits to track device configuration, device poli -IOTSEC 1. How do you associate IoT identities and permissions with your devices? +IOTSEC01: How do you associate IoT identities and permissions with your devices? @@ -45 +47,3 @@ IOTSEC 1. How do you associate IoT identities and permissions with your devices? -Your application is responsible for managing how your devices authenticate and authorize their interactions. By creating a process that ensures devices have identity-based permissions for accessing the IoT platform, you establish the greatest control for managing device interactions. +Your application is responsible for managing how your devices authenticate and authorize their interactions. By creating a process that makes sure devices have a unique identity and identity-based permissions for accessing the IoT system, you establish the greatest control for managing device interactions. + +## IOTSEC01-BP01 Assign unique identities to each IoT device @@ -47 +51 @@ Your application is responsible for managing how your devices authenticate and a -**Best practice IOTSEC_1.1** – **Assign unique identities to each IoT device** +When a device connects to other devices or cloud services, it must establish trust by authenticating using credentials such as X.509 certificates (with proof of having the private key) or security tokens. You can find available options from the IoT solution of your choice, and implement device registry and identity stores to associate devices, metadata and user permissions. The solution should enable each device (or Thing) to have a unique name (or ThingName) in the device registry, and the solution should make sure that each device has an associated unique identity principal, such as an X.509 certificate or security token. Identity principals, such as certificates, should not be shared between devices. Detection of multiple devices using the same identity credentials indicates an issue that requires investigation. This could be due to improper device setup or potential unauthorized cloning of device credentials. @@ -49 +53 @@ Your application is responsible for managing how your devices authenticate and a -When a device connects to other devices or cloud services, it must establish trust by authenticating using principals such as X.509 certificates, security tokens, or other credentials. You can find available options from the IoT solution of your choice, and implement device registry and identity stores to associate devices, metadata and user permissions. The solution should enable each device (or Thing) to have a unique name (or ThingName) in the device registry, and it should ensure that each device has an associated unique identity principal, such as an X.509 certificate or security token. Identity principals, such as certificates, should not be shared between devices. When multiple devices use the same certificate, this might indicate that a device has been compromised. Its identity might have been cloned to further compromise the system. +**Level of risk exposed if this best practice is not established:** High @@ -51 +55 @@ When a device connects to other devices or cloud services, it must establish tru -**Recommendation IOTSEC_1.1.1** – _Use X.509 client certificates to authenticate over TLS 1.2_ +**Prescriptive guidance IOTSEC01-BP01-01** _Use X.509 client certificates to authenticate over TLS 1.2/1.3._ @@ -53 +57 @@ When a device connects to other devices or cloud services, it must establish tru -We recommend that each device be given a unique certificate to enable fine-grained management, including certificate revocation. Devices must support rotation and replacement of certificates to ensure continued operation as certificates expire. For example, AWS IoT Core supports AWS IoT-generated X.509 certificates or your own X.509 certificates for device authentication. +We recommend that each device be given a unique key or certificate to enable fine-grained device management, including certificate revocation. Devices must support rotation, refresh, and replacement of certificates to support continued operation. For example, AWS IoT Core supports AWS IoT-generated X.509 certificates or your own X.509 certificates for device authentication. @@ -55 +59 @@ We recommend that each device be given a unique certificate to enable fine-grain -**Recommendation IOTSEC_1.1.2** – _Choose the appropriate certificate vending mechanisms for your use case_ +**Prescriptive guidance IOTSEC01-BP01-02** _Choose the appropriate certificate vending mechanisms for your use case._ @@ -57 +61 @@ We recommend that each device be given a unique certificate to enable fine-grain -We recommend using native provisioning mechanisms to onboard devices when they already have a device certificate (and associated private key) on them. For example, you can use just-in-time provisioning (JITP) or just-in-time registration (JITR) that provisions devices in bulk when they first connect to AWS IoT. +We recommend using native provisioning mechanisms to onboard devices when they already have a device certificate (and associated private key) on them. For example, you can use just-in-time provisioning (JITP) or just-in-time registration (JITR) that provisions devices when they first connect to AWS IoT. @@ -59 +63 @@ We recommend using native provisioning mechanisms to onboard devices when they a -**Recommendation IOTSEC_1.1.3** – _Use security bearer tokens for authorizing to the IoT broker_ +**Prescriptive guidance IOTSEC01-BP01-03** _Use security bearer tokens only if necessary._ @@ -61 +65 @@ We recommend using native provisioning mechanisms to onboard devices when they a -If the devices cannot use X.509 certificates, or you have an existing fleet of devices with a proprietary access control mechanism, that requires use of bearer tokens such as OAuth over JWT or SAML tokens, use custom auth mechanisms. For example, when a device attempts to connect to AWS IoT, it sends a JWT generated by their identity provider in the HTTP header or query string. The signature is validated by AWS IoT custom authorizer and the connection is established. +If the devices cannot use X.509 certificates, or you have an existing fleet of devices with a proprietary access control mechanism that requires use of bearer tokens such as OAuth with JWT or SAML 2.0 tokens, use custom authentication mechanisms. For example, when a device attempts to connect to AWS IoT, it sends a JWT which was generated by their identity provider in the HTTP header or query string of requests. The token is validated by AWS IoT custom authorizer and the connection is established. All communications must be performed over TLS-protected (encrypted) connections using strong cipher-suites. @@ -63 +67 @@ If the devices cannot use X.509 certificates, or you have an existing fleet of d -**Recommendation IOTSEC_1.1.4** – _Use a consistent naming convention that maps your device identity to the MQTT topics_ +**Prescriptive guidance IOTSEC01-BP01-04** _Use a consistent naming convention that aligns MQTT topics with your device identity._ @@ -65 +69 @@ If the devices cannot use X.509 certificates, or you have an existing fleet of d -It is important to use a standard set of naming conventions when designing device name and MQTT topics. For example, use the same client identifier for the device as the IoT Thing Name. This will also allow to include any relevant routing information for the device in the topic namespace. +It is important to use a standard set of naming conventions when designing device names and MQTT topics. For example, we recommend using the same client identifier (`ClientId`) for the device as the IoT Thing Name (`ThingName`). This will also simplify the design for including relevant routing information for the device in the topic namespace. @@ -67 +71 @@ It is important to use a standard set of naming conventions when designing devic -IOTSEC 2. How do you secure your devices and protect device credentials? +IOTSEC02: How do you secure your devices and protect device credentials? @@ -70 +74,3 @@ IOTSEC 2. How do you secure your devices and protect device credentials? -Your IoT devices and identity principals (certificates, private keys, tokens, etc.) must be secured throughout their lifecycle. To ensure device authenticity, your IoT hardware must securely store, manage, and restrict access to the identities that the device uses to authenticate itself with the cloud. By securing your devices and storing your device credentials safely, you can reduce the risk of unauthorized users misusing device credentials. +Your IoT devices and identity credentials (certificates, private keys, or tokens) must be secured throughout their lifecycle. To support device authenticity, your IoT hardware must securely store, manage, and restrict access to the identities that the device uses to authenticate itself with the cloud. By securing your devices and storing your device credentials safely, you can reduce the risk of unauthorized users misusing device credentials. + +## IOTSEC02-BP01 Use a separate hardware or a secure area on your devices to store credentials @@ -72 +78 @@ Your IoT devices and identity principals (certificates, private keys, tokens, et -**Best practice IOTSEC_2.1** – **Use a separate hardware or a secure area on your devices to store credentials.** +A secure element (SE) is any hardware feature you can use to protect information on the device. A common use of an SE is to securely store the device's identity. Secure storage at rest helps reduce the risk of unauthorized use of the device identity. Never store or cache device credentials outside of the SE. If supported, generate public or private key pairs using the SE, and generate the Certificate Signing Requests (CSRs) on the device. With this method, the private key never leaves the SE. If this is not possible, generate and transmit the credentials to the SE in a secure manufacturing facility with Common Criteria EAL certification. Import or install the private key material into the SE in the secure facility. Securely handling a device's identity helps make sure that your hardware and application are resilient to potential security issues that occur in unprotected systems. A SE provides encrypted storage of private information (such as cryptographic keys) at rest and can be implemented as separate specialized hardware or as part of a system on a chip (SoC). @@ -74 +80 @@ Your IoT devices and identity principals (certificates, private keys, tokens, et -A secure element is any hardware feature you can use to protect the device identity at rest. Secure storage at rest helps reduce the risk of unauthorized use of the device identify. Never store or cache device credentials outside of the secure element. Generate private keys on the HSM, and generate the Certificate Signing Requests from the device. If this is not possible, generate and transmit the credentials to the HSM in a secure manufacturing facility with Common Criteria EAL certification. Securely handling a device’s identity helps ensure that your hardware and application are resilient to potential security issues that occur in unprotected systems. A secure element provides encryption of private information (such as cryptographic keys) at rest and can be implemented as separate specialized hardware or as part of a system on a chip (SoC). +**Level of risk exposed if this best practice is not established:** High @@ -76 +82 @@ A secure element is any hardware feature you can use to protect the device ident -**Recommendation IOTSEC_2.1.1** – _Use tamper-resistant hardware that offloads the security encryption and communication from the IoT application._ +**Prescriptive guidance IOTSEC02-BP01-01** _Use tamper-resistant hardware that offloads the cryptographic operations for encryption and communication from the IoT application._ @@ -78 +84 @@ A secure element is any hardware feature you can use to protect the device ident -Device credentials always reside in a secure element, which facilitates any usage of the credentials. Using the secure element to facilitate the use of device credentials further limits the risk of unauthorize use. As an example, AWS IoT Greengrass supports using a secure element to store AWS IoT certificates and private keys. +Device credentials must always reside in a SE, which facilitates usage of the credentials. Using the SE to facilitate the use of device credentials further limits the risk of unauthorized use. As an example, AWS IoT Greengrass supports using a SE to store AWS IoT certificates and private keys. @@ -80 +86 @@ Device credentials always reside in a secure element, which facilitates any usag -**Recommendation IOTSEC_2.1.2** – _Use cryptographic API operations with the secure element hardware for protecting the secrets on the device_ +**Prescriptive guidance IOTSEC02-BP01-02** _Use cryptographic API operations provided by the secure element hardware for protecting the secrets on the device._ @@ -82 +88 @@ Device credentials always reside in a secure element, which facilitates any usag -Ensure that any security modules are accessed using the latest security protocols. For example, in FreeRTOS, use the PKCS#11 APIs provided in the corePKCS11 library for protecting secrets. +Only access security modules using the latest security protocols. For example, in FreeRTOS, use the PKCS#11 APIs provided in the corePKCS11 library for protecting secrets. @@ -84 +90 @@ Ensure that any security modules are accessed using the latest security protocol -**Recommendation IOTSEC_2.1.3** – _Use the AWS Partner Device Catalog to find AWS Partners that offer hardware security modules_. +**Prescriptive guidance IOTSEC02-BP01-03** _Use the AWS Partner Device Catalog to find AWS Partners that offer hardware security modules._ @@ -86 +92 @@ Ensure that any security modules are accessed using the latest security protocol -If you are getting devices that have not been deployed in the field, AWS recommends reviewing the AWS Partner Device Catalog to find AWS IoT hardware partners that either implement a TPM or a secure element. Use AWS IoT Partners that offer qualified secure elements for storing IoT device identities. +If you are getting devices that have not been deployed in the field, AWS recommends reviewing the AWS Partner Device Catalog to find AWS IoT hardware partners that either implement a SE or trusted platform module (TPM). Use AWS IoT Partners that offer qualified SEs for storing IoT device identities. @@ -88 +94 @@ If you are getting devices that have not been deployed in the field, AWS recomme -**Best practice IOTSEC_2.2** – **Use a trusted platform module (TPM) to implement cryptographic controls** +## IOTSEC02-BP02 Use a trusted platform module (TPM) to implement cryptographic controls @@ -92 +98 @@ Generally, a TPM is used to hold, secure, and manage cryptographic keys and cert - 1. TPM is a dedicated crypto-processor to help ensure the device boots into a secure and trusted state. + 1. TPM is a dedicated crypto-processor to help make sure the device boots into a secure and trusted state. @@ -94 +100 @@ Generally, a TPM is used to hold, secure, and manage cryptographic keys and cert - 2. The TPM chip contains the manufacturer’s keys and software for device encryption. + 2. The TPM chip contains the manufacturer's keys and software for device encryption. @@ -96 +102 @@ Generally, a TPM is used to hold, secure, and manage cryptographic keys and cert - 3. The Trusted Computing Group (TCG) defines hardware-roots-of-trust as part of the trusted platform module (TPM) specification. + 3. The Trusted Computing Group (TCG) defines hardware-roots-of-trust as part of the Trusted Platform Module (TPM) specification. @@ -103 +109 @@ A hardware identity refers to an immutable, unique identity for a platform that -**Implementation guidance** +**Level of risk exposed if this best practice is not established:** Medium @@ -105 +111 @@ A hardware identity refers to an immutable, unique identity for a platform that -**Recommendation IOTSEC_2.2.1** – _Perform cryptographic operations inside the TPM to avoid a third party gaining unauthorized access_ +**Prescriptive guidance IOTSEC02-BP02-01** _Perform cryptographic operations inside the TPM to avoid a third party gaining unauthorized access._ @@ -107 +113 @@ A hardware identity refers to an immutable, unique identity for a platform that -All secret keys from the manufacturer required for secure boot, such as attestation keys, storage keys, and application keys, are stored in the secure enclave of the chip. For example, a device running AWS IoT Greengrass can be used with an Infineon OPTIGA TPM. +Store all secret keys from the manufacturer required for secure boot, such as attestation keys, storage keys, and application keys, in the secure enclave of the chip. For example, a device running AWS IoT Greengrass can be used with an Infineon OPTIGA TPM. @@ -109 +115 @@ All secret keys from the manufacturer required for secure boot, such as attestat -**Recommendation IOTSEC_2.2.2** – _Use a trusted execution environment (TEE) along with a TPM to act as a baseline defense against rootkits_ +**Prescriptive guidance IOTSEC02-BP02-02** _Use a trusted execution environment (TEE) along with a TPM to act as a baseline defense against rootkits._ @@ -120 +126 @@ TEE is a separate execution environment that provides security services and isol -**Recommendation IOTSEC_2.2.3** – _Use physical unclonable function (PUF) technology for cryptographic operations_ +**Prescriptive guidance IOTSEC02-BP02-03** _Use physical unclonable function (PUF) technology for cryptographic operations._ @@ -122 +128 @@ TEE is a separate execution environment that provides security services and isol -A PUF technology is a physical object that provides a physically defined digital fingerprint to serve as a unique identifier for an IoT device. As a different class of security primitive, PUFs normally have a relatively simple structure. It makes them ideal candidates for affordable security solutions for IoT networks. Generally, a hardware root of trust based on PUF is virtually impossible to duplicate, clone, or predict. This makes them suitable for applications such as secure key generation and storage, device authentication, flexible key provisioning, and chip asset management. For example, refer to AWS Partner Device Catalog, that has various device solutions with PUFs such as LPC54018 IoT Solution by NXP. +A PUF technology is a physical object that provides a physically defined digital fingerprint to serve as a unique identifier for an IoT device. As a different class of security primitive, PUFs normally have a relatively simple structure. It makes them ideal candidates for affordable security solutions for IoT networks. Generally, a hardware root of trust based on PUF is virtually impossible to duplicate, clone, or predict. This makes them suitable for applications such as secure key generation and storage, device authentication, flexible key provisioning, and chip asset management. Refer to [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices/) which has various device solutions with PUFs such as LPC54018 IoT Solution by NXP. @@ -124 +130 @@ A PUF technology is a physical object that provides a physically defined digital -**Best practice IOTSEC_2.3 – Use protected boot and persistent storage encryption** +## IOTSEC02-BP03 Use protected boot and persistent storage encryption @@ -126 +132 @@ A PUF technology is a physical object that provides a physically defined digital -When a device performs a secure boot, it validates that the device is not running unauthorized code from the filesystem. This helps ensure that the boot process starts from a trusted combination of hardware and software, and continues until the host operating system has fully booted and applications are running. +When a device performs a secure boot, it validates that the device is not running unauthorized code from the filesystem. This helps make sure that the boot process starts from a trusted combination of hardware and software, and continues until the host operating system has fully booted and applications are running. @@ -128 +134 @@ When a device performs a secure boot, it validates that the device is not runnin -Choose devices with TPM (or TEE) for new deployments. Secure boot also ensures that if even a single bit in the software boot-loader or application firmware is modified after deployment, the modified firmware will not be trusted, and the device will refuse to run this untrusted code. +Choose devices with TPM (or TEE) for new deployments. Secure boot also makes sure that if even a single bit in the software boot-loader or application firmware is modified after deployment, the modified firmware will not be trusted, and the device will refuse to run this untrusted code. @@ -130 +136 @@ Choose devices with TPM (or TEE) for new deployments. Secure boot also ensures t -Full disk encryption ensures that the storage and cryptographic elements are secured in absence of a TPM or secure element. The disk controller needs to ensure that all read accesses to the disk are transparently decrypted at-runtime. +Full disk encryption makes sure that the storage and cryptographic elements are secured in absence of a TPM or SE. The disk controller needs to make sure that read accesses to the disk are transparently decrypted and write operations are encrypted at runtime. @@ -132 +138 @@ Full disk encryption ensures that the storage and cryptographic elements are sec -**Recommendation IOTSEC_2.3.1** – _Boot devices using a cryptographically verified operating system image_ +**Level of risk exposed if this best practice is not established:** High @@ -134 +140 @@ Full disk encryption ensures that the storage and cryptographic elements are sec -Use digitally signed binaries that have been verified using an immutable root of trust, such as a master root key (MRK) that’s stored securely in a non-modifiable memory, to boot devices. +**Prescriptive guidance IOTSEC02-BP03-01** _Boot devices using a cryptographically verified operating system image._ @@ -136 +142 @@ Use digitally signed binaries that have been verified using an immutable root of -**Recommendation IOTSEC_2.3.2** – _Create separate filesystem partitions for the boot-loader and the applications_ +Use digitally signed binaries that have been verified using an immutable root of trust, such as a master root key (MRK) that's stored securely in a non-modifiable memory, to boot devices. @@ -138 +144 @@ Use digitally signed binaries that have been verified using an immutable root of -As an example, configure the device boot-loader to use a read-only partition, and applications to use a separate writable partition for separation of concerns and reduce the surface area of the attack. +**Prescriptive guidance IOTSEC02-BP03-02** _Create separate filesystem partitions for the boot-loader and the applications._ @@ -140 +146 @@ As an example, configure the device boot-loader to use a read-only partition, an -**Recommendation IOTSEC_2.3.3** – _Use encryption utilities provided by the host operating system to encrypt the writable filesystem_ +As an example, configure the device boot-loader to use a read-only partition, and applications to use a separate writable partition for separation of concerns and reducing risks. @@ -142 +148 @@ As an example, configure the device boot-loader to use a read-only partition, an -For example, use crypt utilities for Linux such as dm-crypt or GPG, and use BitLocker or Amazon Elastic File System (Amazon EFS) for Microsoft Windows. +**Prescriptive guidance IOTSEC02-BP03-03** _Use encryption utilities provided by the host operating system to encrypt the writable filesystem._ @@ -144 +150 @@ For example, use crypt utilities for Linux such as dm-crypt or GPG, and use BitL -**Recommendation IOTSEC_2.3.4** – _Use services that enable you to push signed application code from a trusted source to the device_ +For example, use crypt utilities for Linux such as dm-crypt or GPG, and use BitLocker or Amazon EFS for Microsoft Windows. @@ -146 +152 @@ For example, use crypt utilities for Linux such as dm-crypt or GPG, and use BitL -You can use AWS IoT Jobs to push signed software binaries from the cloud to the device. For microcontrollers using FreeRTOS, ensure that the firmware images are signed before deployment. +**Prescriptive guidance IOTSEC02-BP03-04** _Use services that can push signed application code from a trusted source to the device._ @@ -148 +154,3 @@ You can use AWS IoT Jobs to push signed software binaries from the cloud to the -IOTSEC 3. How do you authenticate and authorize user access to your IoT application? +You can use AWS IoT Jobs to push signed software binaries from the cloud to the device. For microcontrollers using FreeRTOS, make sure that the firmware images are signed before deployment. Signature verification should also verify that the signer of the package is trusted and the signer's certificate and any intermediate certificate authorities' certificates have not been revoked. + +IOTSEC03: How do you authenticate and authorize user access to your IoT application? @@ -151 +159,5 @@ IOTSEC 3. How do you authenticate and authorize user access to your IoT applicat -Although many applications focus on the thing aspect of IoT, in almost all verticals of IoT, there is also a human component that needs the ability to communicate to and receive notifications from devices. For example, consumer IoT generally requires users to onboard their devices by associating them with an online account. Industrial IoT typically entails the ability to analyze hardware telemetry in near real time. In either case, it's essential to determine how your application will identify, authenticate, and authorize users that require the ability to interact with particular devices. +Although many applications focus on the device aspect of IoT, in almost all industries using IoT, there is also a human component that needs the ability to communicate to and receive notifications from devices. + +For example, consumer IoT generally requires users to onboard their devices by associating them with an online account. Industrial IoT typically entails the ability to analyze hardware telemetry in near real time. In either case, it is essential to determine how your application will identify, authenticate, and authorize users that require the ability to interact with the solution and with particular devices. + +Controlling user access to your IoT assets begins with identity. Your IoT application must have in place a store (typically a user registry or identity provider) that keeps track of a user's identity and also how a user authenticates using that identity. The identity store may include additional user attributes that can be used at authorization time. For example, the user's group memberships. @@ -153 +165 @@ Although many applications focus on the thing aspect of IoT, in almost all verti