OWASP Internet of Things Project

• Main
• IoT Attack Surface Areas
• Top IoT Vulnerabilities
• Top 10 IoT Vulnerabilities (2014)
• IoT Testing Guides
• IoT Security Guidance
• Talks
• Curated IoT Reading
• Community
• Podcasts
• IoT Conferences
• IoT Framework Assessment
• Principles

OWASP Internet of Things (IoT) Project Oxford defines the Internet of Things as: “A proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.” The OWASP Internet of Things Project is designed to help manufacturers, developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying, or assessing IoT technologies. The project looks to define a structure for various IoT sub-projects such as Attack Surface Areas, Testing Guides and Top Vulnerabilities. Licensing The OWASP Internet of Things Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

What is the OWASP Internet of Things Project? The OWASP Internet of Things Project provides: IoT Attack Surface Areas IoT Testing Guides Top IoT Vulnerabilities IoT Security Guidance Community Groups Curated IoT Reading List Developer Guidance Design Principles Project Leaders Daniel Miessler Craig Smith Major Contributors Justin Klein Keane [1] Related Projects The OWASP Mobile Top 10 Project The OWASP Web Top 10 Project

Email List Subscribe to the Top Ten list Quick Download IoT Attack Surface Mapping DEFCON 23 IoT Testing Guidance Handout OWASP IoT Top Ten PDF OWASP IoT Top Ten Infographic OWASP IoT Top Ten PPT OWASP IoT Top Ten-RSA 2015 News and Events Daniel Miessler gave his IoT talk at DEFCON 23 Migrating the IoT Top Ten to be under the IoT Project HP Study Reveals 70 Percent of Internet of Things Devices Vulnerable to Attack. IoT devices averaged 25 vulnerabilities per product, indicating expanding attack surface for adversaries Classifications

The OWASP IoT Attack Surface Areas (DRAFT) are as follows:

Attack Surface	Vulnerability
Ecosystem Access Control	Implicit trust between components Enrollment security Decommissioning system Lost access procedures
Device Memory	Cleartext usernames Cleartext passwords Third-party credentials Encryption keys
Device Physical Interfaces	Firmware extraction User CLI Admin CLI Privilege escalation Reset to insecure state Removal of storage media
Device Web Interface	SQL injection Cross-site scripting Cross-site Request Forgery Username enumeration Weak passwords Account lockout Known default credentials
Device Firmware	Hardcoded credentials Sensitive information disclosure Sensitive URL disclosure Encryption keys Firmware version display and/or last update date
Device Network Services	Information disclosure User CLI Administrative CLI Injection Denial of Service Unencrypted Services Poorly implemented encryption Test/Development Services Buffer Overflow UPnP Vulnerable UDP Services DoS
Administrative Interface	SQL injection Cross-site scripting Cross-site Request Forgery Username enumeration Weak passwords Account lockout Known default credentials Security/encryption options Logging options Two-factor authentication Inability to wipe device
Local Data Storage	Unencrypted data Data encrypted with discovered keys Lack of data integrity checks
Cloud Web Interface	SQL injection Cross-site scripting Cross-site Request Forgery Username enumeration Weak passwords Account lockout Known default credentials Transport encryption Insecure password recovery mechanism Two-factor authentication
Third-party Backend APIs	Unencrypted PII sent Encrypted PII sent Device information leaked Location leaked
Update Mechanism	Update sent without encryption Updates not signed Update location writable Update verification Malicious update Missing update mechanism No manual update mechanism
Mobile Application	Implicitly trusted by device or cloud Username enumeration Account lockout Known default credentials Weak passwords Insecure data storage Transport encryption Insecure password recovery mechanism Two-factor authentication
Vendor Backend APIs	Inherent trust of cloud or mobile application Weak authentication Weak access controls Injection attacks
Ecosystem Communication	Health checks Heartbeats Ecosystem commands Deprovisioning Pushing updates
Network Traffic	LAN LAN to Internet Short range Non-standard

The top IoT vulnerabilities (DRAFT) are as follow:

Vulnerability	Attack Surface	Summary
Username Enumeration	Administrative Interface Device Web Interface Cloud Interface Mobile Application	Ability to collect a set of valid usernames by interacting with the authentication mechanism
Weak Passwords	Administrative Interface Device Web Interface Cloud Interface Mobile Application	Ability to set account passwords to '1234' or '123456' for example.
Account Lockout	Administrative Interface Device Web Interface Cloud Interface Mobile Application	Ability to continue sending authentication attempts after 3 - 5 failed login attempts
Unencrypted Services	Device Network Services	Network services are not properly encrypted to prevent eavesdropping by attackers
Two-factor Authentication	Administrative Interface Cloud Web Interface Mobile Application	Lack of two-factor authentication mechanisms such as a security token or fingerprint scanner
Poorly Implemented Encryption	Device Network Services	Encryption is implemented however it is improperly configured or is not being properly updated, e.g. using SSL v2
Update Sent Without Encryption	Update Mechanism	Updates are transmitted over the network without using TLS or encrypting the update file itself
Update Location Writable	Update Mechanism	Storage location for update files is world writable potentially allowing firmware to be modified and distributed to all users
Denial of Service	Device Network Services	Service can be attacked in a way that denies service to that service or the entire device
Removal of Storage Media	Device Physical Interfaces	Ability to physically remove the storage media from the device
No Manual Update Mechanism	Update Mechanism	No ability to manually force an update check for the device
Missing Update Mechanism	Update Mechanism	No ability to update device
Firmware Version Display and/or Last Update Date	Device Firmware	Current firmware version is not displayed and/or the last update date is not displayed

For each attack surface areas, the following sections are included:

• A description of the attack surface
• Threat agents
• Attack vectors
• Security weaknesses
• Technical impacts
• Business impacts
• Example vulnerabilities
• Example attacks
• Guidance on how to avoid the issue
• References to OWASP and other related resources

• I1 Insecure Web Interface
• I2 Insufficient Authentication/Authorization
• I3 Insecure Network Services
• I4 Lack of Transport Encryption
• I5 Privacy Concerns
• I6 Insecure Cloud Interface
• I7 Insecure Mobile Interface
• I8 Insufficient Security Configurability
• I9 Insecure Software/Firmware
• I10 Poor Physical Security

Tester IoT Security Guidance

(DRAFT)

The goal of this page is to help testers assess IoT devices and applications in the Internet of Things space. The guidance below is at a basic level, giving testers of devices and applications a basic set of guidelines to consider from their perspective. This is not a comprehensive list of considerations, and should not be treated as such, but ensuring that these fundamentals are covered will greatly improve the security of any IoT product.

Category	IoT Security Consideration
I1: Insecure Web Interface	Assess any web interface to determine if weak passwords are allowed Assess the account lockout mechanism Assess the web interface for XSS, SQLi and CSRF vulnerabilities and other web application vulnerabilities Assess the use of HTTPS to protect transmitted information Assess the ability to change the username and password Determine if web application firewalls are used to protect web interfaces
I2: Insufficient Authentication/Authorization	Assess the solution for the use of strong passwords where authentication is needed Assess the solution for multi-user environments and ensure it includes functionality for role separation Assess the solution for Implementation two-factor authentication where possible Assess password recovery mechanisms Assess the solution for the option to require strong passwords Assess the solution for the option to force password expiration after a specific period Assess the solution for the option to change the default username and password
I3: Insecure Network Services	Assess the solution to ensure network services don't respond poorly to buffer overflow, fuzzing or denial of service attacks Assess the solution to ensure test ports are are not present
I4: Lack of Transport Encryption	Assess the solution to determine the use of encrypted communication between devices and between devices and the internet Assess the solution to determine if accepted encryption practices are used and if proprietary protocols are avoided Assess the solution to determine if a firewall option available is available
I5: Privacy Concerns	Assess the solution to determine the amount of personal information collected Assess the solution to determine if collected personal data is properly protected using encryption at rest and in transit Assess the solution to determine if Ensuring data is de-identified or anonymized Assess the solution to ensure end-users are given a choice for data collected beyond what is needed for proper operation of the device
I6: Insecure Cloud Interface	Assess the cloud interfaces for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces) Assess the cloud-based web interface to ensure it disallows weak passwords Assess the cloud-based web interface to ensure it includes an account lockout mechanism Assess the cloud-based web interface to determine if two-factor authentication is used Assess any cloud interfaces for XSS, SQLi and CSRF vulnerabilities and other vulnerabilities Assess all cloud interfaces to ensure transport encryption is used Assess the cloud interfaces to determine if the option to require strong passwords is available Assess the cloud interfaces to determine if the option to force password expiration after a specific period is available Assess the cloud interfaces to determine if the option to change the default username and password is available
I7: Insecure Mobile Interface	Assess the mobile interface to ensure it disallows weak passwords Assess the mobile interface to ensure it includes an account lockout mechanism Assess the mobile interface to determine if it Implements two-factor authentication (e.g Apple's Touch ID) Assess the mobile interface to determine if it uses transport encryption Assess the mobile interface to determine if the option to require strong passwords is available Assess the mobile interface to determine if the option to force password expiration after a specific period is available Assess the mobile interface to determine if the option to change the default username and password is available Assess the mobile interface to determine the amount of personal information collected
I8: Insufficient Security Configurability	Assess the solution to determine if password security options (e.g. Enabling 20 character passwords or enabling two-factor authentication) are available Assess the solution to determine if encryption options (e.g. Enabling AES-256 where AES-128 is the default setting) are available Assess the solution to determine if logging for security events is available Assess the solution to determine if alerts and notifications to the user for security events are available
I9: Insecure Software/Firmware	Assess the device to ensure it includes update capability and can be updated quickly when vulnerabilities are discovered Assess the device to ensure it uses encrypted update files and that the files are transmitted using encryption Assess the device to ensure is uses signed files and then validates that file before installation
I10: Poor Physical Security	Assess the device to ensure it utilizes a minimal number of physical external ports (e.g. USB ports) on the device Assess the device to determine if it can be accessed via unintended methods such as through an unnecessary USB port Assess the device to determine if it allows for disabling of unused physical ports such as USB Assess the device to determine if it includes the ability to limit administrative capabilities to a local interface only

General Recommendations

Consider the following recommendations for all user interfaces (local device, cloud-based and mobile):

• Avoid potential Account Harvesting issues by:
  • Ensuring valid user accounts can't be identified by interface error messages
  • Ensuring strong passwords are required by users
  • Implementing account lockout after 3 - 5 failed login attempts

Manufacturer IoT Security Guidance

(DRAFT)

The goal of this section is help manufacturers build more secure products in the Internet of Things space. The guidance below is at a basic level, giving builders of products a basic set of guidelines to consider from their perspective. This is not a comprehensive list of considerations, and should not be treated as such, but ensuring that these fundamentals are covered will greatly improve the security of any IoT product.

Category	IoT Security Consideration
I1: Insecure Web Interface	Ensure that any web interface in the product disallows weak passwords Ensure that any web interface in the product has an account lockout mechanism Ensure that any web interface in the product has been tested for XSS, SQLi and CSRF vulnerabilities Ensure that any web interface has the ability to use HTTPS to protect transmitted information Include web application firewalls to protect any web interfaces Ensure that any web interface allows the owner to change the default username and password
I2: Insufficient Authentication/Authorization	Ensure that any access requiring authentication requires strong passwords Ensure that user roles can be properly segregated in multi-user environments Implement two-factor authentication where possible Ensure password recovery mechanisms are secure Ensure that users have the option to require strong passwords Ensure that users have the option to force password expiration after a specific period Ensure that users have the option to change the default username and password
I3: Insecure Network Services	Ensure all devices operate with a minimal number of network ports active Ensure all devices do not make network ports and/or services available to the internet via UPnP for example Review all required network services for vulnerabilities such as buffer overflows or denial of service
I4: Lack of Transport Encryption	Ensure all communication between system components is encrypted as well as encrypting traffic between the system or device and the internet Use recommended and accepted encryption practices and avoid proprietary protocols Ensure SSL/TLS implementations are up to date and properly configured Consider making a firewall option available for the product
I5: Privacy Concerns	Ensure only the minimal amount of personal information is collected from consumers Ensure all collected personal data is properly protected using encryption at rest and in transit Ensure only authorized individuals have access to collected personal information Ensure only less sensitive data is collected Ensuring data is de-identified or anonymized Ensuring a data retention policy is in place Ensuring end-users are given a choice for data collected beyond what is needed for proper operation of the device
I6: Insecure Cloud Interface	Ensure all cloud interfaces are reviewed for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces) Ensure that any cloud-based web interface disallows weak passwords Ensure that any cloud-based web interface has an account lockout mechanism Implement two-factor authentication for cloud-based web interfaces Ensure that all cloud interfaces use transport encryption Ensure that any cloud-based web interface has been tested for XSS, SQLi and CSRF vulnerabilities Ensure that users have the option to require strong passwords Ensure that users have the option to force password expiration after a specific period Ensure that users have the option to change the default username and password
I7: Insecure Mobile Interface	Ensure that any mobile application disallows weak passwords Ensure that any mobile application has an account lockout mechanism Implement two-factor authentication for mobile applications (e.g Apple's Touch ID) Ensure that any mobile application uses transport encryption Ensure that users have the option to require strong passwords Ensure that users have the option to force password expiration after a specific period Ensure that users have the option to change the default username and password
I8: Insufficient Security Configurability	Ensure password security options are made available (e.g. Enabling 20 character passwords or enabling two-factor authentication) Ensure encryption options are made available (e.g. Enabling AES-256 where AES-128 is the default setting) Ensure secure logging is available for security events Ensure alerts and notifications are available to the user for security events
I9: Insecure Software/Firmware	Ensure all system devices have update capability and can be updated quickly when vulnerabilities are discovered Ensure update files are encrypted and that the files are also transmitted using encryption Ensure that update files are signed and then validated by the device before installing Ensure update servers are secure Ensure the product has the ability to implement scheduled updates
I10: Poor Physical Security	Ensure the device is produced with a minimal number of physical external ports (e.g. USB ports) Ensure the firmware of Operating System can not be accessed via unintended methods such as through an unnecessary USB port Ensure the product is tamper resistant Ensure the product has the ability to limit administrative capabilities in some fashion, possibly by only connecting locally for admin functions Ensure the product has the ability to disable external ports such as USB

General Recommendations

Consider the following recommendation for all Internet of Things products:

• Avoid the potential for persistent vulnerabilities in devices that have no update capability by ensuring that all devices and systems are built with the ability to be updated when vulnerabilities are discovered
• Rebranded devices used as part of a system should be properly configured so that unnecessary or unintended services do not remain active after the rebranding

[ NOTE: Given the fact that each deployment and every environment is different, it is important to weigh the pros and cons of implementing the advice above before taking each step. ]

Developer IoT Security Guidance

(DRAFT)

The goal of this section is help developers build more secure applications in the Internet of Things space. The guidance below is at a basic level, giving developers of applications a basic set of guidelines to consider from their perspective. This is not a comprehensive list of considerations, and should not be treated as such, but ensuring that these fundamentals are covered will greatly improve the security of any IoT product. Strongly consider using a Secure IoT Framework in order to proactively address many of the concerns listed below.

Category	IoT Security Consideration	Recommendations
I1: Insecure Web Interface	Ensure that any web interface coding is written to prevent the use of weak passwords Ensure that any web interface coding is written to include an account lockout mechanism Ensure that any web interface coding has been tested for XSS, SQLi and CSRF vulnerabilities Ensure that any web interface has the ability to use HTTPS to protect transmitted information Ensure that any web interface coding is written to allow the owner to change the username and password Consider the use of web application firewalls to protect any web interfaces	When building a web interface consider implementing lessons learned from web application security. Employ a framework that utilizes security controls to ensure that vulnerabilities are mitigated in code. Be sure to plan for eventual upgrades or security fixes to the framework as well. If you use optional plugins to the framework be sure to review them for security. Deploy and protect the web interface in the same way you would any web application. Utilize encrypted transport protocols if possible, being sure to validate certificates. Limit access in whatever ways possible. Assume users will not change configuration so deploy in a secure manner with strong credentials already in place.
I2: Insufficient Authentication/Authorization	Ensure that applications are written to require strong passwords where authentication is needed Ensure the application takes into account multi-user environments and includes functionality for role separation Implement two-factor authentication where possible Ensure password recovery mechanisms are written to function in a secure manner Ensure that applications are written to include the option to require strong passwords Ensure that applications are written to include the option to force password expiration after a specific period Ensure that applications are written to include the option to change the default username and password	Refer to the OWASP Authentication Cheat Sheet
I3: Insecure Network Services	Ensure applications that use network services don't respond poorly to buffer overflow, fuzzing or denial of service attacks Ensure applications test ports are taken out of service before going to production	Try to utilize tested, proven, networking stacks and interfaces that handle exceptions gracefully. Be sure that any test or maintenance interfaces are disabled or properly protected. Avoid exposing unauthenticated protocols (such as TFTP) or unencrypted channels (such as telnet) if possible. Consider the attack surface that device network services present. Turn off unnecessary services and deploy measures to protect required services, detect malicious activity, and react to an attack with measures such as lock-outs or temporary firewall rules.
I4: Lack of Transport Encryption	Ensure all applications are written to make use of encrypted communication between devices and between devices and the internet Use recommended and accepted encryption practices and avoid proprietary protocols Consider making a firewall option available for the application	Utilize encrypted protocols wherever possible to protect all data in transit. Where protocol encryption is not possible consider encrypting data before transfer.
I5: Privacy Concerns	Ensure only the minimal amount of personal information is collected from consumers Ensure all collected personal data is properly protected using encryption at rest and in transit Ensuring data is de-identified or anonymized Ensuring end-users are given a choice for data collected beyond what is needed for proper operation of the device	Data can present unintended privacy concerns when aggregated. As a rule collect the minimal amount of data possible. Consult with data scientists, legal and compliance teams to determine risk of data collection and storage. Consider implications of consent and the fact that IoT devices may not present an interface for collecting consent and may passively collect data about people other than owners and operators. IoT may collect information about individuals who cannot provide consent (such as minors) and data collection should be modified accordingly.
I6: Insecure Cloud Interface	Ensure all cloud interfaces are reviewed for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces) Ensure that any cloud-based web interface coding is written to disallows weak passwords Ensure that any cloud-based web interface coding is written to include an account lockout mechanism Implement two-factor authentication for cloud-based web interfaces Ensure that any cloud interface coding has been tested for XSS, SQLi and CSRF vulnerabilities Ensure that all cloud interfaces use transport encryption Ensure that cloud interfaces are written to include the option to require strong passwords Ensure that cloud interfaces are written to include the option to force password expiration after a specific period Ensure that cloud interfaces are written to include the option to change the default username and password	Cloud security presents unique security considerations, as well as countermeasures. Be sure to consult your cloud provider about options for security mechanisms. Consult the OWASP Cloud Top 10 Security Risks documents.
I7: Insecure Mobile Interface	Ensure that any mobile application coding is written to disallows weak passwords Ensure that any mobile application coding is written to include an account lockout mechanism Implement two-factor authentication for mobile applications (e.g Apple's Touch ID) Ensure that any mobile application uses transport encryption Ensure that mobile interfaces are written to include the option to require strong passwords Ensure that mobile interfaces are written to include the option to force password expiration after a specific period Ensure that mobile interfaces are written to include the option to change the default username and password Ensure that mobile interfaces only collect the minimum amount of personal information needed	Mobile interfaces to IoT ecosystems require targeted security. Consult the OWASP Mobile Project for further guidance.
I8: Insufficient Security Configurability	Ensure applications are written to include password security options (e.g. Enabling 20 character passwords or enabling two-factor authentication) Ensure applications are written to include encryption options (e.g. Enabling AES-256 where AES-128 is the default setting) Ensure all applications are written to produce logs for security events Ensure all applications are written to produce alerts and notifications to the user for security events	Security can be a value proposition. Design should take into consideration a sliding scale of security requirements. Architect projects with secure defaults and allow consumers to select options to be enabled or disabled. IoT design should be forward compatible with respect to security - as cipher suites increase and new security technologies become widely available IoT design should be able to adopt these new technologies. Remember the security lifecycle of protect, detect, and react. Design systems to allow for the detection of malicious activity as well as self defending capabilities and a reaction plan should a compromise be detected. Design all stages of the lifecycle to be evolutionary so improvements can be added to a system or device future releases, updates, or patches.
I9: Insecure Software/Firmware	Ensure all applications are written to include update capability and can be updated quickly when vulnerabilities are discovered Ensure all applications are written to process encrypted update files and that the files are transmitted using encryption Ensure all applications are written to process signed files and then validate that file before installation	Many IoT deployments are either brownfield (i.e. applied over existing infrastructure) and/or have an extremely long deployment cycle. To maintain the security of devices over time it is critical to plan for patches and updates. Confidentiality, Integrity, and Availability (CIA) are primary concerns when providing binaries and updates to edge devices. Encrypt updates before distribution, providing decryption keys along with download instructions to authorized devices. Updates should have cryptographic signatures using public key cryptography that can be verified by devices. A cryptographic signature allows for distribution of updates over untrusted channels, such as Content Delivery Network (CDN), peer-to-peer, or machine to machine (M2M). Devices should always validate cryptographic certificates and discard updates that are not properly delivered or signed. If unencrypted updates are utilized be sure that a cryptographic hash of the update is provided over an encrypted channel so the device can detect tampering. Provide a mechanism for issuing, updating and revoking cryptographic keys as well. Key management and lifecycle should be taken into consideration prior to deployment. This includes the SSL trust store, or root trust, on a device, which may have to be modified over the lifespan of the device.
I10: Poor Physical Security	Ensure applications are written to utilize a minimal number of physical external ports (e.g. USB ports) on the device Ensure all applications can not be accessed via unintended methods such as through an unnecessary USB port Ensure all applications are written to allow for disabling of unused physical ports such as USB Consider writing applications to limit administrative capabilities to a local interface only	Plan on having IoT edge devices fall into malicious hands. Utilize whatever physical security protections are available. Disable any testing or debugging interfaces, utilize Hardware Security Modules (HSM's), cryptographic co-processors, and Trusted Platform Modules (TPM's) wherever possible. Consider the implications of a compromised device. Do not share credentials, application or cryptographic keys across multiple devices to limit the scope of damage due to a physical compromise. Plan for the transfer of ownership of devices and ensure that data is not transferable along with the ownership.

General Recommendations

Consider the following recommendations for all user interfaces (local device, cloud-based and mobile):

• Avoid potential Account Harvesting issues by:
  • Ensuring valid user accounts can't be identified by interface error messages
  • Ensuring strong passwords are required by users
  • Implementing account lockout after 3 - 5 failed login attempts

[ NOTE: Given the fact that each deployment and every environment is different, it is important to weigh the pros and cons of implementing the advice above before taking each step. ]

Consumer IoT Security Guidance

(DRAFT)

The goal of this section is help consumers purchase secure products in the Internet of Things space. The guidance below is at a basic level, giving consumers a basic set of guidelines to consider from their perspective. This is not a comprehensive list of considerations, and should not be treated as such, but ensuring that these fundamentals are covered will greatly aid the consumer in purchasing a secure IoT product.

Category	IoT Security Consideration
I1: Insecure Web Interface	If your system has the option to use HTTPS, ensure it is enabled If your system has a two factor authentication option, ensure that it is enabled If your system has web application firewall option, ensure that it is enabled If your system has a local or cloud-based web application, ensure that you change the default password to a strong one and if possible change the default username as well If the system has account lockout functionality, ensure that it is enabled Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
I2: Insufficient Authentication/Authorization	If your system has a local or cloud-based web application, ensure that you change the default password to a strong one and if possible change the default username as well If the system has account lockout functionality, ensure that it is enabled If the system has the option to require strong passwords, ensure that is enabled If the system has the option to require new passwords after 90 days for example, ensure that is enabled If your system has a two factor authentication option, ensure that it is enabled If your system has the option to set user privileges, consider setting user privileges to the minimal needed for operation Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
I3: Insecure Network Services	If your system has a firewall option available, enable it and ensure that it can only be accessed from your client systems Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
I4: Lack of Transport Encryption	If your system has the option to use HTTPS, ensure it is enabled
I5: Privacy Concerns	Do not enter sensitive information into the system that is not absolutely required, e.g. address, DOB, CC, etc. Deny data collection if it appears to be beyond what is needed for proper operation of the device (If provided the choice)
I6: Insecure Cloud Interface	If your system has the option to use HTTPS, ensure it is enabled If your system has a two factor authentication option, ensure that it is enabled If your system has web application firewall option, ensure that it is enabled If your system has a local or cloud-based web application, ensure that you change the default password to a strong one and if possible change the default username as well If the system has account lockout functionality, ensure that it is enabled If the system has the option to require strong passwords, ensure that is enabled If the system has the option to require new passwords after 90 days for example, ensure that is enabled
I7: Insecure Mobile Interface	If the mobile application has the option to require a PIN or password, consider using it for extra security (on client and server) If the mobile application has the option to use two factory authentication such as Apple's Touch ID, ensure it is enabled If the system has account lockout functionality, ensure that it is enabled If the system has the option to require strong passwords, ensure that is enabled If the system has the option to require new passwords after 90 days for example, ensure that is enabled Do not enter sensitive information into the mobile application that is not absolutely required, e.g. address, DOB, CC, etc.
I8: Insufficient Security Configurability	If your system has the option, enable any logging functionality for security-related events If your system has the option, enable any alert and notification functionality for security-related events If your system has security options for passwords, ensure they are enabled for strong passwords If your system has security options for encryption, ensure they are set for an accepted standard such as AES-256
I9: Insecure Software/Firmware	If your system has the option to verify updates, ensure it is enabled If your system has the option to download updates securely, ensure it is enabled If your system has the ability to schedule updates on a regular cadence, consider enabling it
I10: Poor Physical Security	If your system has the ability to limit administrative capabilities possible by connecting locally, consider enabling that feature Disable any unused physical ports through the administrative interface

General Recommendations

If you are looking to purchase a device or system, consider the following recommendations:

• Include security in feature considerations when evaluating a product
• Place Internet of Things devices on a separate network if possible using a firewall

[ NOTE: Given the fact that each deployment and every environment is different, it is important to weigh the pros and cons of implementing the advice above before taking each step. ]

RSA Conference San Francisco
Securing the Internet of Things: Mapping IoT Attack Surface Areas with the OWASP IoT Top 10 Project
Daniel Miessler, Practice Principal
April 21, 2015
---
Defcon 23
IoT Attack Surface Mapping
Daniel Miessler
August 6-9, 2015

• Craig Smith's IoT Reading List

I Am The Cavalry

A global grassroots organization that is focused on issues where computer security intersects public safety and human life.

Their areas of focus include:

• Medical devices
• Automobiles
• Home Electronics
• Public Infrastructure

BuildItSecure.ly

A project focused on helping small business connect with security researchers to aid in securing their IoT-based products before going market.

Their goals include:

• Focus effort towards small business
• Build partnerships
• Coordinate efforts
• Curate informational resources
• Present research

Online Trust Alliance

Formed as an informal industry working group in 2005, today OTA is an Internal Revenue Service (IRS) approved 501c3 charitable organization with the mission to enhance online trust and empower users, while promoting innovation and the vitality of the internet. OTA is global organization supported by over 100 organizations headquartered in Bellevue, Washington with offices in Washington DC.

Addressing the mounting concerns, in January 2015 the Online Trust Alliance, established the IoT Trustworthy Working Group (ITWG), a multi-stakeholder initiative. The group recognizes “security and privacy by design” must be a priority from the onset of product development and be addressed holistically. The framework focuses on privacy, security sustainability. The sustainability pillar is critical as it looks at the life-cycle issues related to long- term supportability and transfers of ownership of devices and the data collected.

AllSeen Alliance

The AllSeen Alliance is a Linux Foundation collaborative project. They're a cross-industry consortium dedicated to enabling the interoperability of billions of devices, services and apps that comprise the Internet of Things. The Alliance supports the AllJoyn Framework, an open source software framework that makes it easy for devices and apps to discover and communicate with each other. Developers can write applications for interoperability regardless of transport layer, manufacturer, and without the need for Internet access. The software has been and will continue to be openly available for developers to download, and runs on popular platforms such as Linux and Linux-based Android, iOS, and Windows, including many other lightweight real-time operating systems.

The Industrial Internet Consortium (IIC)

The Industrial Internet Consortium is the open membership, international not-for-profit consortium that is setting the architectural framework and direction for the Industrial Internet. Founded by AT&T, Cisco, GE, IBM and Intel in March 2014, the consortium’s mission is to coordinate vast ecosystem initiatives to connect and integrate objects with people, processes and data using common architectures, interoperability and open standards.

Securing Smart Cities

Securing Smart Cities is a not-for-profit global initiative that aims to solve the existing and future cybersecurity problems of smart cities through collaboration between companies, governments, media outlets, other not-for-profit initiatives and individuals across the world.

• The Internet of Things Podcast
• IoT Inc
• IoT This Week
• Farstuff: The Internet of Things Podcast

• Internet of Things Events

Conference Call for Papers

• WikiCFP - Internet of Things
• WikiCFP - IoT

IoT Framework Security Considerations

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

Definitions

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.

Edge

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.

Gateway

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.

Storage

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.

Cloud

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.

Authentication

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 (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet). 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

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.

Principles of IoT Security

1. Assume a Hostile Edge
   • Edge components are likely to fall into adversarial hands. Assume attackers will have physical access to edge components and can manipulate them, move them to hostile networks, and control resources such as DNS, DHCP, and internet routing.
2. Test for Scale
   • The volume of IoT means that every design and security consideration must also take into account scale. Simple bootstrapping into an ecosystem can create a self denial of service condition at IoT scale. Security countermeasures must perform at volume.
3. Internet of Lies
   • Automated systems are extremely capable of presenting misinformation in convincing formats. IoT systems should always verify data from the edge in order to prevent autonomous misinformation from tainting a system.
4. Exploit Autonomy
   • Automated systems are capable of complex, monotonous, and tedious operations that human users would never tolerate. IoT systems should seek to exploit this advantage for security.
5. Expect Isolation
   • The advantage of autonomy should also extend to situations where a component is isolated. Security countermeasures must never degrade in the absence of connectivity.
6. Protect Uniformly
   • Data encryption only protects encrypted pathways. Data that is transmitted over an encrypted link is still exposed at any point it is unencrypted, such as prior to encryption, after decryption, and along any communications pathways that do not enforce encryption. Careful consideration must be given to full data lifecycle to ensure that encryption is applied uniformly and appropriately to guarantee protections. Encryption is not total - be aware that metadata about encrypted data might also provide valuable information to attackers.
7. Encryption is Tricky
   • It is very easy for developers to make mistakes when applying encryption. Using encryption but failing to validate certificates, failing to validate intermediate certificates, failing to encrypt traffic with a strong key, using a uniform seed, or exposing private key material are all common pitfalls when deploying encryption. Ensure a thorough review of any encryption capability to avoid these mistakes.
8. System Hardening
   • Be sure that IoT components are stripped down to the minimum viable feature set to reduce attack surface. Unused ports and protocols should be disabled, and unnecessary supporting software should be uninstalled or turned off. Be sure to track third party components and update them where possible.
9. Limit what you can
   • To the extent possible limit access based on acceptable use criteria. There's no advantage in exposing a sensor interface to the entire internet if there's no good case for a remote user in a hostile country. Limit access to white lists of rules that make sense.
10. Lifecycle Support
    • IoT systems should be able to quickly onboard new components, but should also be capable of re-credentialing existing components, and deprovisioning components for a full device lifecycle. This capability should include all components in the ecosystem from devices to users.
11. Data in Aggregate is Unpredictable
    • IoT systems are capable of collecting vast quantities of data that my seem innocuous at first, but complex data analysis may reveal very sensitive patterns or information hidden in data. IoT systems must prepare for the data stewardship responsibilities of unexpected information sensitivity that may only be revealed after an ecosystem is deployed.
12. Plan for the Worst
    • IoT systems should have capabilities to respond to compromises, hostile participants, malware, or other adverse events. There should be features in place to re-issue credentials, exclude participants, distribute security patches and updates, and so on, before they are ever necessary.
13. The Long Haul
    • IoT system designers must recognize the extended lifespan of devices will require forward compatible security features. IoT ecosystems must be capable of aging in place and still addressing evolving security concerns. New encryption, advances in protocols, new attack methods and techniques, and changing topology all necessitate that IoT systems be capable of addressing emerging security concerns for years after they are deployed.
14. Attackers Target Weakness
    • Ensure that security controls are equivalent across interfaces in an ecosystem. Attackers will identify the weakest component and attempt to exploit it. Mobile interfaces, hidden API's, or resource constrained environments must enforce security in the same way as more robust or feature rich interfaces. Using multi-factor authentication for a web interface is useless if a mobile application allows access to the same API's with a four digit PIN.
15. Transitive Ownership
    • IoT components are often sold or transferred during their lifespan. Plan for this eventuality and be sure IoT systems can protect and isolate data to enable safe transfer of ownership, even if a component is sold or transferred to a competitor or attacker.
16. N:N Authentication
    • Realize that IoT does not follow a traditional 1:1 model of users to applications. Each component may have more than one user and a user may interact with multiple components. Several users might access different data or capabilities on a single device, and one user might have varying rights to multiple devices. Multiple devices may need to broker permissions on behalf of a single user account, and so on. Be sure the IoT system can handle these complex trust and authentication schemes.