This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "OWASP Internet of Things Top Ten Project"
m (→Developer IoT Security Guidance: Added link to OWASP Periodic Table in framework discussion) |
(Moving the community tab over to the project pages, where it seems more appropriate.) |
||
Line 141: | Line 141: | ||
{{Template:OWASP OWASP_Top10 Project}} --> | {{Template:OWASP OWASP_Top10 Project}} --> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
= Manufacturers = | = Manufacturers = | ||
Revision as of 17:31, 23 October 2015
- Main
- OWASP Internet of Things Top 10 for 2014
- Manufacturers
- Developers
- Testers
- Consumers
- Project Details
NOTE: This project is part of The OWASP IoT Project, which is located here.
OWASP Internet of Things Top 10Oxford 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 (IoT) Top 10 is a project 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 defines the top ten security surface areas presented by IoT systems, and provides information on threat agents, attack vectors, vulnerabilities, and impacts associated with each. In addition, the project aims to provide practical security recommendations for builders, breakers, and users of IoT systems. LicensingThe OWASP Internet of Things Top 10 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 Top 10?The OWASP Internet of Things Top 10 provides:
For each attack surface areas, the following sections are included:
For each role in Manufacturers, Developers, and Consumer, the following recommendations are included:
Project Leaders
Related Projects |
Email ListQuick DownloadIoT Attack Surface Mapping DEFCON 23 News and Events
Classifications |
The OWASP Internet of Things Top 10 - 2014 is as follows:
- 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
Introduction
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 (IoT) Top 10 is a project designed to help vendors who are interested in making common appliances and gadgets network/Internet accessible. The project walks through the top ten security problems that are seen with IoT devices, and how to prevent them.
Examples of IoT Devices: Cars, lighting systems, refrigerators, telephones, SCADA systems, traffic control systems, home security systems, TVs, DVRs, etc…
Feedback
Please let us know how your organization is using the Internet of Things Top 10. Include your name, organization's name, and brief description of how you use the list. Thanks for supporting OWASP!
We hope you find the information in the OWASP Internet of Things Top Ten useful. Please contribute back to the project by sending your comments, questions, and suggestions to [email protected], [email protected], or [email protected], Thanks!
Project Sponsors
- HP Fortify on Demand
- Contribute and add your name here!
Manufacturer IoT Security Guidance
(DRAFT)
The goal of this page 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 |
|
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 |
|
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 page 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.
Category | IoT Security Consideration | Recommendations |
---|---|---|
I1: Insecure Web Interface |
|
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 |
|
Refer to the OWASP Authentication Cheat Sheet |
I3: Insecure Network Services |
|
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 |
|
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 |
|
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 |
|
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 |
|
Mobile interfaces to IoT ecosystems require targeted security. Consult the OWASP Mobile Project for further guidance. |
I8: Insufficient Security Configurability |
|
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 |
|
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 |
|
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
- Recognize the value in autonomous IoT systems to perform security operations that are onerous or impossible to a user. Consider cryptographic authentication mechanisms, public key cryptography, and transitive trust schemes.
[ 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. ]
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 |
|
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 |
|
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
Consumer IoT Security Guidance
(DRAFT)
The goal of this page 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 |
|
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 |
|
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. ]
PROJECT INFO What does this OWASP project offer you? |
RELEASE(S) INFO What releases are available for this project? | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|