IoT Framework Security Considerations

18 March 2016

Designing a secure IoT solution depends on a number of security considerations. One of the most important consideration is the use of a secure IoT framework for building your ecosystem. Using a secure framework ensures that developers don't overlook security considerations and allows for rapid application development. Ideally a framework contains security components baked into the framework in such a way as to provide security by default that developers don't have to think about. This frees developers and architects to focus on features and capabilities without burdening their development efforts with security considerations (or mistakes).

The purpose of this document is to outline a vendor agnostic set of evaluation criteria that developers and architects can use to measure relative security strengths of IoT development frameworks. This should serve as a useful benchmark as well as impetus for vendors to produce more robust IoT development frameworks to address the many security issues that beleaguer IoT.

Evaluation criteria are broken down into four distinct sections. These sections are representative of typical IoT system archetypes. Each section has specific security related concerns that are outlined in the framework evaluation criteria for that section. These sections are:

  • Edge
  • Gateway
  • Cloud Platform
  • Mobile


The edge code that runs on actual IoT devices. Often times edge components are resource constrained or operate in isolated environments. A gateway device is often used to aggregate and bridge communications from edge devices. The edge, or gateway, will often communicate with some sort of cloud component, often a web service. This component could be deployed in a company data center or a public cloud computing environment. The cloud component often supports complex user interfaces, analytics capabilities, and provide access to data aggregation back ends. Finally, many IoT ecosystems consist of mobile application components that allow users to interact with the ecosystem via smart phones or tablets.


The edge is the actual physical device that makes up the IoT ecosystem. Note that in many deployments the edge is heterogeneous, meaning it is made up of any number of types of devices with different hardware, operating systems, networking or communications capability and resources. An ideal framework will provide cross platform components so that edge code can be deployed anywhere from bare metal, to an embedded operating system, to a mobile OS, to a full blown desktop computer, and so on.

Framework Considerations for Edge Component

Communications encryption
Encrypted communications should occur end-to-end wherever possible. Keep in mind that some communications may pass through a barrier, such as a gateway or load balancer, which may impact end-to-end encryption. Encryption allows endpoints to validate identity (such as through x509 certificates and roots of trust) to ensure that communications cannot be intercepted or redirected.
Storage encryption
Sensitive data on the edge is liable to theft or exposure unless it is stored with proper security considerations. Frameworks should offer some form of secured local storage for data that protects it from local malicious applications, compromised operating systems, or malicious owner/operator. Sensitive data can include sensor reading, configuration settings, authentication credentials, or cryptographic keys.
Strong logging
The framework should offer robust logging, including security event logging. The log events should be customizable and should report sensitive events in a usable format for end users, managers, and operators. Logs often provide forensic evidence of abuse so integration with common log formats (such as Windows event logs or Unix syslog), allows for integration into more robust monitoring systems.
Automatic updates and/or version reporting
Keeping software up to date and allowing for patches and updates is critical for a secure framework. The framework should clearly identify the running version and allow for software patches and updates. An automatic updating process frees users from having to manually update systems, raising the likelihood that systems will be kept up to date.
Update verification
Updates should be delivered over a secured channel and verified after download to ensure that updates are legitimate. Binary signing (and checking) and update hashes delivered over a verified, encrypted, channel ensure that malicious updates aren't installed on a device. Be aware that physical access may allow an attacker to "side load" a binary to place it directly on a device so updates should be verified prior to installation rather than simply checking a download.
Cryptographic identification capabilities
IoT ecosystems are primarily comprised of autonomous systems which are extremely capable of performing complex cryptographic operations. Frameworks should support cryptographic capabilities to verify trusted components (such as gateway, cloud, or mobile) and include cryptographic lifecycle management. This means supporting the issuing, and re-issuing, of cryptographic material, expiration of cryptographic certificates, a revocation and revocation checking mechanism, and a system from signing key material. This capability enables strong cryptographic authentication, which is particularly important with machine to machine (M2M) authentication and communications encryption.
No default passwords
The framework should support custom credentials that can be created, set, and reset by the operator. The framework should eschew default or shared credentials across the ecosystem. Credentials includes local authentication components as well as authentication components to cloud, gateway, mobile, or other ecosystem devices.
Strong local authentication
The framework should provide strong authentication of operators to the edge. Where possible this should include complex passwords and multi-factor authentication. The authentication mechanism should report or log failed authentication attempts and provide a exponential delay or lock out mechanism to prevent brute force attacks.
Offline security features
The framework should assume that the edge component may lose connectivity and fall back to local security features in the absence of network resources. These offline security features should be just as robust as online features in order to prevent attackers from disrupting communications so as to degrade security countermeasures.
Configurable root trust store
Cryptographic roots of trust are critical for using certificates for identity validation. These stores should be configurable in order to add new certificates and expire or remove revoked certificates to maintain forward compatible security. The framework should enforce checks on the ability to manipulate the trust root.
Device and owner authentication
The framework should recognize that in an IoT ecosystem the device may need to authenticate as itself or broker identity of an owner or operator. The identity model of the framework should recognize the unique access and authentication needs for both the autonomous component and the human user(s).
Transitive ownership considerations
IoT devices are often sold or ownership is transfered. The framework should allow the device to be wiped, reset, or otherwise have data compartmentalized or destroyed to protect owner information. Whether the device is a set piece in a physical location whose owner might change, or physically transferable to a potentially hostile or competitive owner, the framework should take into consideration the transitive nature of the device and allow for information protection accordingly.
Defensive capabilities
The framework should provide mechanisms to detect malicious and anomalous activity or integrate easily into device side malware protection or anomaly detection products. To the extent possible the framework should support a self defending edge component.
Plugin or extension verification, reporting and updating
Additions and extensions to the edge components should be validated prior to installation by the framework. The framework should support reporting and updating capabilities for extensions in the same manner as for the core.
Secure M2M capabilities
The framework should support machine to machine trust, authorization, verification, and authentication. To the extent possible this support should extend to offline capabilities to avoid a single point of failure in a platform or gateway. The framework might support transitive trust, so that an owner might certify a number of devices which could then authenticate and trust based on the owner, independent of the device or platform in the ecosystem. The platform or gateway may also be able to confer transitive trust for M2M communications.
Secure web interface
Frameworks that provide an interface for edge components should utilize an interface that addresses the OWASP Top 10 at a minimum. To the extent possible, web interfaces should be constructed with web application development frameworks that ensure security countermeasures against common vulnerabilities such as authentication bypass, cross site scripting and cross site request forgery. Web interfaces should be presented over TLS (HTTPS) and should not use self signed or invalid certificates. To the extent possible the framework should limit access to the web interface to prevent unauthorized use or abuse.
Utilize established, tested networking stacks and protocols
Frameworks should utilize well supported network stacks and protocols to avoid common security vulnerabilities in newer, untested, or exotic stacks and protocols. Frameworks should limit the number of protocols to the minimum possible and should provide protocols or stacks in a disabled-by-default state to limit attack surface.
Use latest, up to date third party components
Frameworks should use up to date 3rd party components as well as the capability to report on versions and update these components as they age or security updates become available. The framework should insure that any updates should be distributed over a secured channel and verified before installation.
Capability to utilize hardware devices
The framework should support the use of any available hardware security features such as Hardware Security Modules (HSM's), Trusted Platform Modules (TPM's), and cryptographic coprocessors. The framework may not require these components, but should utilize them if available.
Support multi-factor authentication
The framework should support multi factor authentication for the device and/or any operators if possible.
Support temporal and spacial authentication and functionality
IoT devices might be moved and the framework should have the capability to fine tune permissions based on space and time. The framework should support location aware permissions utilizing any number of the sensors on an edge device and should also support a permissions model that can change based on rules of time.
Tracks and contains data from potentially tainted (insecure) sources
IoT devices might be required to process data from channels that cannot be secured. The framework should allow for some form of data tagging or sanitization to track and contain data from untrusted sources.
Features (interfaces) are disabled by default
The framework should strive to disable as many services and features as possible by default, allowing developers and deployment configuration to enable features as necessary in order to minimize attack surface. The framework should allow for configuration reporting and potentially for remote configuration changes to respond to ecosystem changes.
Written in a type safe programming language or subject to scrutiny
Framework components for edge devices should be written in programming languages that posses security countermeasures and demonstrate a history of strong security. Framework edge components written in languages prone to security issues, such as C, should be rigorously scrutinized to ensure that code level vulnerabilities, such as buffer overflows, are not present.
Does not employ secrets in code
The framework edge components should be architected in such a way as to recognize the likelihood of reverse engineering and physical compromise and employ defensive countermeasures to protect any secrets in the component.
Device monitoring and management capabilities
The framework should enable device platform monitoring, and possibly management, capabilities to allow for detection of security weaknesses or vulnerabilities in other components on the edge.


The gateway will often support weak edge devices, or allow edge devices a bridge networks to cloud components. Gateways can serve as a communications aggregation and control bottleneck and can allow for an easy interface between an insecure, but trusted, local network, and a secure connection to the untrusted public internet. Often times gateways will support range limited or proprietary protocols from edge devices and in many ecosystems the gateway and the edge might be synonymous, with sensors communicating to the edge which brokers those communications into the IoT ecosystem. A gateway may, or may, not have any sort of user interface, which can present benefits and limitations to the device. Typically gateways have greater resource availability than edge devices and run full operating system stacks. Because it serves as an aggregation point, the gateway has a very security sensitive role in the ecosystem.

Framework Considerations for Gateway Component

Multi-directional encrypted communications
The gateway should enforce secure communications so as to not degrade the security of messages in any direction wherever possible. Sometimes a gateway will bridge secured and unsecured communications channels, in which case careful consideration should be given to data interception, manipulation, and injection on insecure endpoints. The gateway should provide capabilities to segment and isolate communications where possible as well.
Strong authentication of components (edge, platform, user)
Edge components should provide authentication mechanisms as strong as any other component in the framework. Where possible the gateway should authenticate multidirectionally to ensure trusted communications to the edge and to the cloud. Cryptographic capabilities in gateway authentication should be a strong component of the framework solution.
The gateway may serve as a single point of failure (or attack) in the ecosystem and should store only the minimum amount of information, in an encrypted format if possible.
Denial of service and replay attack mitigation
The gateway should be able to detect and resist attacks from the edge including spoofing, replay, and excessive communications. The framework should support the ability of the gateway to log, alert, and respond to detected malicious or anomalous activity by the edge components.
Logging and alerting
The gateway will have access to a volume of traffic and should be able to log and alert based on event logging. The framework might include integration with standard logging services or intrusion detection systems. The framework might even support alternative methods for alerting in the gateway (such as SMS).
Anomaly detection and reporting capabilities
The framework should allow the gateway to observe, baseline, and monitor communications traffic and behavior of components. The gateway will be uniquely suited to monitor traffic to and from the cloud and should support anomaly detection or integrate easily with anomaly and intrusion detection systems. A strong gateway framework might even support intrusion prevention capabilities to exclude suspicious actors from the ecosystem.
Use latest, up to date third party components
Frameworks should use up to date 3rd party components as well as the capability to report on versions and update these components as they age or security updates become available. The framework should insure that any updates should be distributed over a secured channel and verified before installation.
Automatic updates and/or version reporting
Keeping software up to date and allowing for patches and updates is critical for a secure framework. The framework should clearly identify the running version and allow for software patches and updates. An automatic updating process frees users from having to manually update systems, raising the likelihood that systems will be kept up to date.


The cloud component of an IoT ecosystem refers to the central data aggregation and management portion of the ecosystem. The cloud component will typically consist of a data storage layer (such as a database), analytics and reporting, ecosystem management, a web interface, and other components such as e-mail, backups, etc. The cloud component may or may not be hosted on public cloud infrastructure. Access to the cloud component is typically restricted, especially to the supporting infrastructure. The cloud component carries significant risk because it is the central point of aggregation for most data in the ecosystem and often includes a command and control (C2) component that allows for the manipulation of other components including the delivery and distribution of updates and extensions. It is critical that the cloud component contains extensive and effective security controls since it is the keystone of most IoT ecosystems.

Framework Considerations for Cloud Component

Encrypted communications
The cloud component should support encrypted communications including security certificates to identify itself to other components in the ecosystem. The framework should support cryptographic certificates to identify other components as well, for bi-directional identity verification.
Secure web interface
The cloud web interface should be build using technology that bakes solutions to common web application vulnerabilities in to the code (such as a secure web application development framework). The application should mitigate the OWASP Top 10 at a minimum.
The cloud component should allow for complex authentication including multi factor authentication. The interface should include brute force and anti-account enumeration mitigation features as well. The interface should not ship with default credentials and should allow users to easily set, and safely reset, account information.
Secure Authentication Credentials
Authentication credentials, in any form (passwords, device id's, etc.), should be appropriately salted and hashed, on encrypted, prior to storage ( Storage mechanisms should be uniformly strong and should extend beyond passwords to address machine authentication credentials in any form.
Encrypted storage
The cloud component of an IoT ecosystem is often the system of record and aggregation for the entire deployment. Wherever possible the framework should support data encryption at rest, including in the persistence layer as well as in any export or backup mechanism.
Capability to utilize encrypted communications to storage layer
Communications between the cloud interface and data aggregation layer and the data persistence layer should utilize encrypted communications channel. The framework should utilize encrypted communications by default to prevent data from being exposed in transit.
Data classification capabilities and segregation
The cloud component will collect a variety of varying data from other components in the ecosystem. Some data might be highly sensitive and other data might be benign. The framework should provide the capabilities to classify data and protect data dependent on classification. Interface controls should limit access and exposure of sensitive data according to classification.
Security event reporting and alerting
The cloud component often has the greatest visibility into ecosystem function and security controls are critical at this layer. The cloud component should have robust security event monitoring, reporting, and alerting capabilities. The framework should enable the cloud component to detect and react to malicious activity. The cloud component should be able to segregate bad actors, limit access to malicious parties, and integrate easily with third party logging and intrusion detection and prevention systems.
Automatic updates and update verification
The framework should recognize the need for updates and support easy updates and update verification of the cloud component. The framework should have an easy interface for reporting versions and any available updates. Ideally the framework should support automatic updates to the cloud component. Automated alerting of updates out of band (for instance via SMS or e-mail) is desirable for non-automatically updating components.
Use latest, up to date third party components
Frameworks should use up to date 3rd party components as well as the capability to report on versions and update these components as they age or security updates become available. The framework should insure that any updates should be distributed over a secured channel and verified before installation.
Plugin or extension verification, reporting and updating
The cloud component will often have enhancements and customization options in the form of extensions and plug-ins. The framework should allow for modular updates and monitoring of these components. The framework should ideally ship with a minimal set of features enabled by default to limit attack surface. An easy accounting interface for extensions and plug-ins should be available to administrators. Automated alerting of updates out of band (for instance via SMS or e-mail) is desirable for non-automatically updating components.
Interface segregation and isolation based on utility (device, management interface, user interface, etc.)
The cloud component of an IoT ecosystem will often communicate with various other components of the ecosystem. The utility necessary to communicate with an embedded device will necessarily be very different from the utility provided to a human user of a web interface. The framework should allow for the segregation and protection of communications channels to reduce the attack surface and enforce the principle of least privilege. Attackers may seek to exploit vulnerabilities available to non-human facing interfaces, such as device facing API's. To the extent possible the framework should limit access based on role and use. Cryptographic certificates utilized for purpose access can be useful in this goal. At the very least the framework should provide purpose built interfaces customized for intended use.
Application level firewall and defensive capabilities (IP blocking, throttling, account management, etc.)
The cloud component should have the capability to block certain actors, throttle malicious activity and respond to threats. This should include the capability for the framework to perform mass credential resets, deprecations, and other disaster and breach response capabilities.
Ensure ecosystem segregation in the case of multi-tenant solutions
In the case that the framework supports diverse customer base in a single ecosystem the framework should provide appropriate segregation and data protection. This might include dedicated data storage layers per customer, or data tagging to ensure segregation and access control.
Stack security considerations (no web UI to execute arbitrary code)
Recognizing the complexity and multitude of component security configurations the framework should support full stack security solutions in the cloud component. This includes security countermeasures and integrations on all layers of the cloud component, including potentially integration with cloud provider specific security countermeasures such as isolation or intrusion detection. The cloud component should include secure configuration management and integration with other system automatic updates.
Audit capability
In many ecosystems it is critical to track communications to ensure their proper delivery and timeframe. Frameworks should provide mechanisms to ensure delivery of targeted messages to specific edge components. This feature will allow confidence in audit and troubleshooting and can be used to support delivery guarantees of security sensitive instructions or data. This audit should be bidirectional to allow for tracking of messages to the edge and receipt of messages from the edge.


Mobile interfaces in IoT deployments vary in capabilities and integration. Some mobile applications merely provide limited data reporting from specific edge devices, others allow for the manipulation of edge components, and still others provide a full view analytics and cloud management capabilities. Particular care and attention should be paid to mobile components in IoT ecosystems since they typically are deployed beyond the boundaries of device management, can grant privileged access to alter, adulterate or expose sensitive information, may have the capability to actuate edge devices, are portable and can easily fall into malicious hands. Mobile components may carry many of the same risks as cloud components but are often given less security consideration and are exempt from the robust physical and access security controls that can be placed on cloud components.

Framework Considerations for Mobile Component

Ensure mobile component enforces authentication requirements equal or greater to other components
The limited interface and storage capabilities of mobile applications often encourages simplistic authentication mechanism. Recognizing that attackers will find and target the weakest component of the ecosystem the framework should ensure that mobile authentication mechanisms don't degrade auth requirements.
Local storage security considerations
The framework should be mindful of the sometimes limited storage security on mobile devices. The threat of theft or loss also means that local storage could fall into malicious hands. The framework should strictly limit the amount of data stored on the device and the data should be encrypted where possible.
Capabilities to disable or revoke mobile components in the case of theft or loss
The framework should support the ability to deprovision mobile components quickly and easily to support response in the case of mobile device theft or loss.
Strong audit trail of mobile interactions
Because the mobile device might fall into malicious hands it is critical to keep a security audit trail of mobile application interactions with the ecosystem. The framework should support robust logging and appropriate credentials to track interactions from mobile components to support forensics and in cases were mobile devices were discovered to be used maliciously after the fact.
Mobile application should perform cryptographic verification and validation of other components
Where possible the mobile framework should support cryptographic verification and validation of the other components during interactions. Proper certificate checking and authentication should always take place.
Encrypted communications channels
Mobile devices are particularly prone to use in hostile networks and encrypted communications should be the framework default. Mobile application should operate under the assumption of a hostile observer who will attempt to inspect, interdict, interrupt, replay and otherwise manipulate traffic.
Multi-factor authentication
Mobile devices have extended capabilities to perform multiple factors of authentication. Sensors and biometrics should be supported by the framework for extended security checking on the mobile platform.
Capability to utilize mobile component to enhance authentication and alerting for other components
Where possible the mobile component should integrate into authentication and alerting for events at other components. Edge, gateway, or cloud components might alert to the mobile framework, or the mobile framework might allow for multi factor authentication or enhance authentication to other components.