Difference between revisions of "OWASP Internet of Things Project"

Latest revision as of 07:02, 1 November 2019

Main
IoT Top 10
OWASP IoT Top 10 2018 Mapping Project
IoTGoat
ByteSweep
Firmware Security Testing Methodology
IoT Attack Surface Areas
IoT Vulnerabilities
Medical Devices
Firmware Analysis
IoT Event Logging Project
Project About

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 separated into the following categories - Seek & Understand, Validate & Test, and Governance.

Updated!

The OWASP IoT Project for 2018 has been released!

Philosophy

The OWASP Internet of Things Project was started in 2014 as a way help Developers, Manufacturers, Enterprises, and Consumers to make better decisions regarding the creation and use of IoT systems.

This continues today with the 2018 release of the OWASP IoT Top 10, which represents the top ten things to avoid when building, deploying, or managing IoT systems. The primary theme for the 2018 OWASP Internet of Things Top 10 is simplicity. Rather than having separate lists for risks vs. threats vs. vulnerabilities—or for developers vs. enterprises vs. consumers—the project team elected to have a single, unified list that captures the top things to avoid when dealing with IoT Security.

The team recognized that there are now dozens of organizations releasing elaborate guidance on IoT Security—all of which are designed for slightly different audiences and industry verticals. We thought the most useful resource we could create is a single list that addresses the highest priority issues for manufacturers, enterprises, and consumers at the same time.

The result is the 2018 OWASP IoT Top 10.

Methodology

The project team is a collection of volunteer professionals from within the security industry, with experience spanning multiple areas of expertise, including: manufacturers, consulting, security testers, developers, and many more.

The project was conducted in the following phases:

Team Formation: finding people who would be willing to contribute to the 2018 update, both as SMEs and as project leaders to perform various tasks within the duration of the project.
Project Review: analysis of the 2014 project to determine what’s changed in the industry since that release, and how the list should be updated given those changes.
Data Collection: collection and review of multiple vulnerability sources (both public and private), with special emphasis on which issues caused the most actual impact and damage.
Sister Project Review: a review of dozens of other IoT Security projects to ensure that we’d not missed something major and that we were comfortable with both the content and prioritization of our release. Examples included: CSA IoT Controls Matrix, CTIA, Stanford’s Secure Internet of Things Project, NISTIR 8200, ENISA IoT Baseline Report, Code of Practice for Consumer IoT Security, and others.
Community Draft Feedback: release of the draft to the community for review, including multiple Twitter calls for comments, the use of a public feedback form, and a number of public talks where feedback was gathered. The feedback was then reviewed by the team along with initial Data Collection, as well as Sister Project Review, to create the list contents and prioritization.
Release: release of the project to the public in December 2018.

The Future of the OWASP IoT Top 10

The team has a number of activities planned to continue improving on the project going forward.

Some of the items being discussed include:

Continuing to improve the list on a two-year cadence, incorporating feedback from the community and from additional project contributors to ensure we are staying current with issues facing the industry.
Mapping the list items to other OWASP projects, such as the ASVS, and perhaps to other projects outside OWASP as well.
Expanding the project into other aspects of IoT—including embedded security, ICS/ SCADA,etc.
Adding use and abuse cases, with multiple examples, to solidify each concept discussed.
Considering the addition of reference architectures, so we can not only tell people what to avoid, but how to do what they need to do securely.

Participation in the OWASP IoT Project is open to the community. We take input from all participants — whether you’re a developer, a manufacturer, a penetration tester, or someone just trying to implement IoT securely. You can find the team meeting every other Friday in the the #iot-security room of the OWASP Slack Channel.

The OWASP IoT Security Team, 2018

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.

Share this:

What is the OWASP Internet of Things Project?

The OWASP Internet of Things Project provides information on:

IoT Attack Surface Areas
IoT Vulnerabilities
Firmware Analysis
ICS/SCADA Software Weaknesses
Community Information
IoT Testing Guides
IoT Security Guidance
Principles of IoT Security
IoT Framework Assessment
Developer, Consumer and Manufacturer Guidance
Design Principles
IoTGoat

Project Leaders

Daniel Miessler
Craig Smith
Vishruta Rudresh
Aaron Guzman

Contributors

Justin Klein Keane
Saša Zdjelar

IoT Top 2018 Contributors

Vijayamurugan Pushpanathan
Alexander Lafrenz
Masahiro Murashima
Charlie Worrell
José A. Rivas (jarv)
Pablo Endres
Ade Yoseman
Cédric Levy-Bencheotn
Jason Andress
Amélie Didion - Designer

Related Projects

Collaboration

The OWASP Slack Channel

Hint: If you're new to Slack, join OWASP's slack channel first, then join #iot-security within OWASP's channel.

Quick Download

OWASP IoT Top Ten 2018

IoT Attack Surface Mapping DEFCON 23

IoT Testing Guidance Handout

OWASP IoT Top Ten 2014 PDF

OWASP IoT Project Overview

News and Events

OWASP IoTGoat Project underway
New firmware security analysis tool, ByteSweep
IoT ASVS and Testing Guide set to kick off in 2019
Added a Slack channel
Added a sub-project; IoT Security Policy Project

Classifications

Internet of Things (IoT) Top 10 2018

The OWASP IoT Top 10 - 2018 is now available.

I1 Weak Guessable, or Hardcoded Passwords

I2 Insecure Network Services

I3 Insecure Ecosystem Interfaces

I4 Lack of Secure Update Mechanism

I5 Use of Insecure or Outdated Components

I6 Insufficient Privacy Protection

I7 Insecure Data Transfer and Storage

I8 Lack of Device Management

I9 Insecure Default Settings

I10 Lack of Physical Hardening

Internet of Things (IoT) Top 10 2014

IoT Top 10 2018 Mapping Project

The OWASP IoT Mapping Project is intended to provide a mapping of the OWASP IoT Top 10 2018 to industry publications and sister projects. The goal is to provide resources that enable practical uses for the OWASP IoT Top 10 . As with all Top 10 lists, they should be used as a first step and expanded upon according to the applicable IoT ecosystem.

Mappings are structured with control categories, tests, or recommendations in the left column, descriptions in the middle column, and their mapping to the OWASP IoT Top 10 2018 list in the right column. Each mapping may not have a 1 to 1 relation; however, similar recommendations and/or controls are listed. For mappings that are not applicable to the IoT Top 10 2018 list, an "N/A" is provided as the mapping.

An example mapping of the IoT Top 10 2014 is provided below.

For additional mappings, please visit the following link: https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/

Share this:

What is the IoT Top 10 Mapping Project?

The OWASP IoT Mapping Project is intended to provide a mapping of the OWASP IoT Top 10 2018 to industry publications and sister projects. The goal is to provide resources that enable practical uses for the OWASP IoT Top 10 . As with all Top 10 lists, they should be used as a first step and expanded upon according to the applicable IoT ecosystem.

Mappings include the following:

and more...

GitBook

Mappings are hosted on GitBook using the following link https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/

Project Leaders

Aaron Guzman

Collaboration

The Slack Channel

IoTGoat Project

IoT Goat is a deliberately insecure firmware based on OpenWrt. The project’s goal is to teach users about the most common vulnerabilities typically found in IoT devices. The vulnerabilities will be based on the top 10 vulnerabilities as documented by OWASP: https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project. IoTGoat is expected to be released by December 2019.

To get more information on getting started or how to contribute, visit the project's Github: https://github.com/scriptingxss/IoTGoat

Share this:

What is the IoTGoat Project?

The IoTGoat Project is a deliberately insecure firmware based on OpenWrt. The project’s goal is to teach users about the most common vulnerabilities typically found in IoT devices. The vulnerabilities will be based on the IoT Top 10.

GitHub

https://github.com/scriptingxss/IoTGoat

Project Leaders

Aaron Guzman
Fotios Chantzis
Paulino Calderon

Related Projects

WebGoat
Serverless Goat
NodeGoat
RailsGoat

Collaboration

The Slack Channel

IoTGoat Google Group

Quick Download

News and Events

Coming Soon

OWASP Project Header.jpg

ByteSweep Project

ByteSweep is a Free Software IoT security analysis platform. This platform will allow IoT device makers, large and small, to conduct fully automated security checks before they ship firmware. A Free Software IoT Firmware Security Analysis Platform

ByteSweep Features:

Firmware extraction
File data enrichment
Key and password hash identification
Unsafe function use detection
3rd party component identification
CVE correlation

Share this:

What is the ByteSweep Project?

A Free Software IoT Firmware Security Analysis Platform.

GitLab

https://gitlab.com/bytesweep/bytesweep

Project Leaders

Matt Brown

Collaboration

The Slack Channel

Quick Download

https://gitlab.com/bytesweep/bytesweep/blob/master/INSTALL.md

OWASP Project Header.jpg

Firmware Security Testing Methodology

The Firmware Security Testing Methodology (FSTM) is composed of nine stages tailored to enable security researchers, software developers, consultants, hobbyists, and Information Security professionals with conducting firmware security assessments.

Stage	Description
1. Information gathering and reconnaissance	Acquire all relative technical and documentation details pertaining to the target device’s firmware
2. Obtaining firmware	Attain firmware using one or more of the proposed methods listed
3. Analyzing firmware	Examine the target firmware’s characteristics
4. Extracting the filesystem	Carve filesystem contents from the target firmware
5. Analyzing filesystem contents	Statically analyze extracted filesystem configuration files and binaries for vulnerabilities
6. Emulating firmware	Emulate firmware files and components
7. Dynamic analysis	Perform dynamic security testing against firmware and application interfaces
8. Runtime analysis	Analyze compiled binaries during device runtime
9. Binary Exploitation	Exploit identified vulnerabilities discovered in previous stages to attain root and/or code execution

The full methodology release can be downloaded via the following https://github.com/scriptingxss/owasp-fstm/releases/download/v1.0/Firmware_Security_Testing_Methodology_Version1.pdf.

Share this:

What is the Firmware Security Testing Methodology

The Firmware Security Testing Methodology Project provides:

Attack walkthroughs
Tool usage examples
Screenshots
Companion virtual machine preloaded with tools (EmbedOS) - https://github.com/scriptingxss/EmbedOS

Project Leaders

Aaron Guzman

Quick Download

https://github.com/scriptingxss/owasp-fstm/releases

IoT Attack Surface Areas Project

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

Attack Surface	Vulnerability
Ecosystem (general)	Interoperability standards Data governance System wide failure Individual stakeholder risks Implicit trust between components Enrollment security Decommissioning system Lost access procedures
Device Memory	Sensitive data 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 Tamper resistance Debug port UART (Serial) JTAG / SWD Device ID/Serial number exposure
Device Web Interface	Standard set of web application vulnerabilities, see: OWASP Web Top 10 OWASP ASVS OWASP Testing guide Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism
Device Firmware	Sensitive data exposure (See OWASP Top 10 - A6 Sensitive data exposure): Backdoor accounts Hardcoded credentials Encryption keys Encryption (Symmetric, Asymmetric) Sensitive information Sensitive URL disclosure Firmware version display and/or last update date Vulnerable services (web, ssh, tftp, etc.) Verify for old sw versions and possible attacks (Heartbleed, Shellshock, old PHP versions etc) Security related function API exposure Firmware downgrade possibility
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 Device Firmware OTA update block Firmware loaded over insecure channel (no TLS) Replay attack Lack of payload verification Lack of message integrity check Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism
Administrative Interface	Standard set of web application vulnerabilities, see: OWASP Web Top 10 OWASP ASVS OWASP Testing guide Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism Security/encryption options Logging options Two-factor authentication Check for insecure direct object references Inability to wipe device
Local Data Storage	Unencrypted data Data encrypted with discovered keys Lack of data integrity checks Use of static same enc/dec key
Cloud Web Interface	Standard set of web application vulnerabilities, see: OWASP Web Top 10 OWASP ASVS OWASP Testing guide Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism Transport encryption 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 Update authentication 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 Hidden services
Ecosystem Communication	Health checks Heartbeats Ecosystem commands Deprovisioning Pushing updates
Network Traffic	LAN LAN to Internet Short range Non-standard Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA) Protocol fuzzing
Authentication/Authorization	Authentication/Authorization related values (session key, token, cookie, etc.) disclosure Reusing of session key, token, etc. Device to device authentication Device to mobile Application authentication Device to cloud system authentication Mobile application to cloud system authentication Web application to cloud system authentication Lack of dynamic authentication
Privacy	User data disclosure User/device location disclosure Differential privacy
Hardware (Sensors)	Sensing Environment Manipulation Tampering (Physically) Damage (Physicall)

Share this:

What is the IoT Attack Surface Areas Project?

The IoT Attack Surface Areas Project provides a list of attack surfaces that should be understood by manufacturers, developers, security researchers, and those looking to deploy or implement IoT technologies within their organizations.

Project Leaders

Daniel Miessler
Craig Smith

Related Projects

Collaboration

The Slack Channel

Quick Download

Coming Soon

News and Events

Coming Soon

IoT Vulnerabilities Project

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. Usage of pre-programmed default passwords
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 or tampering 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
Firmware and storage extraction	JTAG / SWD interface In-Situ dumping Intercepting a OTA update Downloading from the manufacturers web page eMMC tapping Unsoldering the SPI Flash / eMMC chip and reading it in a adapter	Firmware contains a lot of useful information, like source code and binaries of running services, pre-set passwords, ssh keys etc.
Manipulating the code execution flow of the device	JTAG / SWD interface Side channel attacks like glitching	With the help of a JTAG adapter and gdb we can modify the execution of firmware in the device and bypass almost all software based security controls. Side channel attacks can also modify the execution flow or can be used to leak interesting information from the device
Obtaining console access	Serial interfaces (SPI / UART)	By connecting to a serial interface, we will obtain full console access to a device Usually security measures include custom bootloaders that prevent the attacker from entering single user mode, but that can also be bypassed.
Insecure 3rd party components	Software	Out of date versions of busybox, openssl, ssh, web servers, etc.

Share this:

What is the IoT Vulnerabilities Project?

The IoT Vulnerabilities Project provides:

Information on the top IoT vulnerabilities
The attack surface associated with the vulnerability
A summary of the vulnerability

Project Leaders

Daniel Miessler
Craig Smith

Related Projects

Collaboration

The Slack Channel

Resources

Top 10 IoT Vulnerabilities from 2014

News and Events

Coming Soon

Medical Device Testing

The Medical Device Testing project is intended to provide some basic attack surface considerations that should be evaluated before shipping Medical Device equipment.

Attack Surface	Vulnerability
Ecosystem (general)	Interoperability standards Data governance System wide failure Individual stakeholder risks Implicit trust between components Enrollment security Decommissioning system Lost access procedures
HL7	XML Parsing XSS Information Disclosure
Device Memory	Sensitive data 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 Tamper resistance Debug port Device ID/Serial number exposure
Device Web Interface	Standard set of web vulnerabilities: SQL injection Cross-site scripting Cross-site Request Forgery Username enumeration Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism
Device Firmware	Sensitive data exposure: Backdoor accounts Hardcoded credentials Encryption keys Encryption (Symmetric, Asymmetric) Sensitive information Sensitive URL disclosure Firmware version display and/or last update date Vulnerable services (web, ssh, tftp, etc.) Security related function API exposure Firmware downgrade
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 Device Firmware OTA update block Replay attack Lack of payload verification Lack of message integrity check Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism
Administrative Interface	Standard web vulnerabilities: SQL injection Cross-site scripting Cross-site Request Forgery Username enumeration Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism 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 Use of static same enc/dec key
Cloud Web Interface	Standard set of web vulnerabilities: SQL injection Cross-site scripting Cross-site Request Forgery Credential management vulnerabilities: Username enumeration Weak passwords Account lockout Known default credentials Insecure password recovery mechanism Transport encryption 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 Update authentication 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 Hidden services
Ecosystem Communication	Health checks Heartbeats Ecosystem commands Deprovisioning Pushing updates
Network Traffic	LAN LAN to Internet Short range Non-standard Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA) Protocol fuzzing
Authentication/Authorization	Authentication/Authorization related values (session key, token, cookie, etc.) disclosure Reusing of session key, token, etc. Device to device authentication Device to mobile Application authentication Device to cloud system authentication Mobile application to cloud system authentication Web application to cloud system authentication Lack of dynamic authentication
Data Flow	What data is being captured? How does it move within the ecosystem? How is it protected in transit? How is it protected at rest? Who is that data shared with?
Hardware (Sensors)	Sensing Environment Manipulation Tampering (Physically) Damaging (Physically) Failure state analysis

Share this:

What is the Medical Attack Surfaces project?

The Medical Attack Surfaces project provides:

A simple way for testers, manufacturers, developers, and users to get an understanding of the complexity of a modern medical environment
Allows people to visualize the numerous attack surfaces that need to be defended within medical equipment ecosystems

Project Leaders

Daniel Miessler

Related Projects

Collaboration

The Slack Channel

Resources

News and Events

Daniel Miessler presented on using Adaptive Testing Methodologies to evaluate the security of medical devices at RSA 2017.

Firmware Analysis Project

The Firmware Analysis Project is intended to provide security testing guidance for the IoT Attack Surface "Device Firmware":

Section
Device Firmware Vulnerabilities	Out-of-date core components Unsupported core components Expired and/or self-signed certificates Same certificate used on multiple devices Admin web interface concerns Hardcoded or easy to guess credentials Sensitive information disclosure Sensitive URL disclosure Encryption key exposure Backdoor accounts Vulnerable services (web, ssh, tftp, etc.)
Manufacturer Recommendations	Ensure that supported and up-to-date software is used by developers Ensure that robust update mechanisms are in place for devices Ensure that certificates are not duplicated across devices and product lines. Ensure supported and up-to-date software is used by developers Develop a mechanism to ensure a new certificate is installed when old ones expire Disable deprecated SSL versions Ensure developers do not code in easy to guess or common admin passwords Ensure services such as SSH have a secure password created Develop a mechanism that requires the user to create a secure admin password during initial device setup Ensure developers do not hard code passwords or hashes Have source code reviewed by a third party before releasing device to production Ensure industry standard encryption or strong hashing is used
Device Firmware Guidance and Instruction	Firmware file analysis Firmware extraction Dynamic binary analysis Static binary analysis Static code analysis Firmware emulation File system analysis
Device Firmware Tools	Firmwalker Firmware Modification Kit Angr binary analysis framework Binwalk firmware analysis tool Binary Analysis Tool Firmadyne Firmware Analysis Comparison Toolkit ByteSweep
Vulnerable Firmware	Damn Vulnerable Router Firmware OWASP IoTGoat

Share this:

What is the Firmware Analysis Project?

The Firmware Analysis Project provides:

Security testing guidance for vulnerabilities in the "Device Firmware" attack surface
Steps for extracting file systems from various firmware files
Guidance on searching a file systems for sensitive of interesting data
Information on static analysis of firmware contents
Information on dynamic analysis of emulated services (e.g. web admin interface)
Testing tool links
A site for pulling together existing information on firmware analysis

Project Leaders

Craig Smith

Related Projects

Collaboration

The Slack Channel

Resources

News and Events

Coming Soon

IoT Logging Events

This is a working draft of the recommended minimum IoT Device logging events. This includes many different types of devices, including consumer IoT, enterprise IoT, and ICS/SCADA type devices.

Event Category	Events
Request Exceptions	Attempt to Invoke Unsupported HTTP Method Unexpected Quantity of Characters in Parameter Unexpected Type of Characters in Parameter
Authentication Exceptions	Multiple Failed Passwords High Rate of Login Attempts Additional POST Variable Deviation from Normal GEO Location
Session Exceptions	Modifying the Existing Cookie Substituting Another User's Valid SessionID or Cookie Source Location Changes During Session
Access Control Exceptions	Modifying URL Argument Within a GET for Direct Object Access Attempt Modifying Parameter Within a POST for Direct Object Access Attempt Forced Browsing Attempt
Ecosystem Membership Exceptions	Traffic Seen from Disenrolled System Traffic Seen from Unenrolled System Failed Attempt to Enroll in Ecosystem Multiple Attempts to Enroll in Ecosystem
Device Access Events	Device Case Tampering Detected Device Logic Board Tampering Detected
Administrative Mode Events	Device Entered Administrative Mode Device Accessed Using Default Administrative Credentials
Input Exceptions	Double Encoded Character Unexpected Encoding Used
Command Injection Exceptions	Blacklist Inspection for Common SQL Injection Values Abnormal Quantity of Returned Records
Honey Trap Exceptions	Honey Trap Resource Requested Honey Trap Data Used
Reputation Exceptions	Suspicious or Disallowed User Source Location

Share this:

What is the IoT Security Logging Project?

The IoT Secure Logging Project provides a list of core events that should be logged in any IoT-related system. The project exists because IoT systems in general are not logging nearly enough events to constitute input for a solid detection and response program around IoT devices, and for companies that want to do this there are not many good resources for what should be logged.

Project Leaders

Daniel Miessler

Related Projects

The OWASP AppSensor Project

Collaboration

The Slack Channel

Quick Download

Coming Soon

News and Events

Coming Soon

PROJECT INFO
What does this OWASP project offer you?

RELEASE(S) INFO
What releases are available for this project?

what	is this project?
Name: OWASP Internet of Things Project
Purpose: N/A
License: CC-BY 3.0 for documentation and GPLv3 for code.
who	is working on this project?
Project Leader(s): Daniel Miessler Craig Smith
Project Contributor(s): Justin Klein Keane] Yunsoul
how	can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: N/A
Project Roadmap: Not Yet Created
Key Contacts
Contact Daniel Miessler to contribute to this project Contact Daniel Miessler to review or sponsor this project

current release
Not Yet Published
last reviewed release
Not Yet Reviewed

other releases

@@ Line 1: / Line 1: @@
-=Main=
+= Main =
 <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== 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''.
-==OWASP Internet of Things (IoT) Project==
+The project looks to define a structure for various IoT sub-projects separated into the following categories - Seek & Understand, Validate & Test, and Governance.
-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.”
+==Updated!==
+The OWASP IoT Project for 2018 has been released![[File:OWASP 2018 IoT Top10 Final.jpg|center|thumb|1301x1301px]]
+== Philosophy ==
+The OWASP Internet of Things Project was started in 2014 as a way help Developers, Manufacturers, Enterprises, and Consumers to make better decisions regarding the creation and use of IoT systems.
+This continues today with the 2018 release of the OWASP IoT Top 10, which represents the top ten things to avoid when building, deploying, or managing IoT systems. The primary theme for the 2018 OWASP Internet of Things Top 10 is simplicity. Rather than having separate lists for risks vs. threats vs. vulnerabilities—or for developers vs. enterprises vs. consumers—the project team elected to have a single, unified list that captures the top things to avoid when dealing with IoT Security.
+The team recognized that there are now dozens of organizations releasing elaborate guidance on IoT Security—all of which are designed for slightly different audiences and industry verticals. We thought the most useful resource we could create is a single list that addresses the highest priority issues for manufacturers, enterprises, and consumers at the same time.
+The result is the [https://www.owasp.org/images/1/1c/OWASP-IoT-Top-10-2018-final.pdf 2018 OWASP IoT Top 10].
+== Methodology ==
+The project team is a collection of volunteer professionals from within the security industry, with experience spanning multiple areas of expertise, including: manufacturers, consulting, security testers, developers, and many more.
+The project was conducted in the following phases:
+# '''Team Formation''': finding people who would be willing to contribute to the 2018 update, both as SMEs and as project leaders to perform various tasks within the duration of the project.
+# '''Project Review:''' analysis of the 2014 project to determine what’s changed in the industry since that release, and how the list should be updated given those changes.
+# '''Data Collection''': collection and review of multiple vulnerability sources (both public and private), with special emphasis on which issues caused the most actual impact and damage.
+# '''Sister Project Review''': a review of dozens of other IoT Security projects to ensure that we’d not missed something major and that we were comfortable with both the content and prioritization of our release. Examples included: [https://cloudsecurityalliance.org/artifacts/csa-iot-controls-matrix/ CSA IoT Controls Matrix], [https://api.ctia.org/wp-content/uploads/2018/08/CTIA-IoT-Cybersecurity-Certification-Test-Plan-V1_0.pdf CTIA], [http://iot.stanford.edu/ Stanford’s Secure Internet of Things Project], [https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8200.pdf NISTIR 8200], [https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot/at_download/fullReport ENISA IoT Baseline Report], [https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/747413/Code_of_Practice_for_Consumer_IoT_Security_October_2018.pdf Code of Practice for Consumer IoT Security,] and others.
+# '''Community Draft Feedback''': release of the draft to the community for review, including multiple Twitter calls for comments, the use of a public feedback form, and a number of public talks where feedback was gathered. The feedback was then reviewed by the team along with initial Data Collection, as well as Sister Project Review, to create the list contents and prioritization.
+# '''Release:''' release of the project to the public in December 2018.
+== The Future of the OWASP IoT Top 10 ==
+The team has a number of activities planned to continue improving on the project going forward.
-''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''.
+Some of the items being discussed include:
+* Continuing to improve the list on a two-year cadence, incorporating feedback from the community and from additional project contributors to ensure we are staying current with issues facing the industry.
+* Mapping the list items to other OWASP projects, such as the ASVS, and perhaps to other projects outside OWASP as well.
+* Expanding the project into other aspects of IoT—including embedded security, ICS/ SCADA,etc.
+* Adding use and abuse cases, with multiple examples, to solidify each concept discussed.
+* Considering the addition of reference architectures, so we can not only tell people what to avoid, but how to do what they need to do securely.
-The project looks to define a structure for various IoT sub-projects such as Attack Surface Areas, Testing Guides and Top Vulnerabilities.
+Participation in the OWASP IoT Project is open to the community. We take input from all participants — whether you’re a developer, a manufacturer, a penetration tester, or someone just trying to implement IoT securely. You can find the team meeting every other Friday in the the #iot-security room of the OWASP Slack Channel.
-[[File:iot-project.png|400px|thumb|center]]
+'''''The OWASP IoT Security Team, 2018'''''
 ==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.
-== ==
 {{Social Media Links}}
-| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+| style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
 == What is the OWASP Internet of Things Project? ==
-The OWASP Internet of Things Project provides:
+The OWASP Internet of Things Project provides information on:
-* IoT Attack Surface Areas
+* [https://www.owasp.org/index.php/IoT_Attack_Surface_Areas IoT Attack Surface Areas]
-* IoT Testing Guides
+* IoT Vulnerabilities
-* Top IoT Vulnerabilities
+* Firmware Analysis
-* IoT Security Guidance
+* ICS/SCADA Software Weaknesses
-* Community Groups
+* Community Information
-* Curated IoT Reading List
+* [https://www.owasp.org/index.php/IoT_Testing_Guides IoT Testing Guides]
-* Developer Guidance
+* [https://www.owasp.org/index.php/IoT_Security_Guidance IoT Security Guidance]
+* [https://www.owasp.org/index.php/Principles_of_IoT_Security Principles of IoT Security]
+* [https://www.owasp.org/index.php/IoT_Framework_Assessment IoT Framework Assessment]
+* Developer, Consumer and Manufacturer Guidance
 * Design Principles
+* IoTGoat
 == Project Leaders ==
@@ Line 41: / Line 78: @@
 * Daniel Miessler
 * Craig Smith
+* Vishruta Rudresh
+* Aaron Guzman
-== Major Contributors ==
+== Contributors ==
 * [https://www.owasp.org/index.php/User:Justin_C._Klein_Keane Justin Klein Keane]
+* Saša Zdjelar
+== IoT Top 2018 Contributors ==
+* Vijayamurugan Pushpanathan
+* Alexander Lafrenz
+* Masahiro Murashima
+* Charlie Worrell
+* José A. Rivas (jarv)
+* Pablo Endres
+* Ade Yoseman
+* Cédric Levy-Bencheotn
+* Jason Andress
+* Amélie Didion - Designer
 == Related Projects ==
-* [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project The OWASP Mobile Top 10 Project]
+* [[OWASP_Project|OWASP Project Repository]]
-* [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project The OWASP Web Top 10 Project]
+* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
+* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
+* [https://www.owasp.org/index.php/OWASP_Embedded_Application_Security OWASP Embedded Application Security]
+* [https://www.owasp.org/index.php/C-Based_Toolchain_Hardening OWASP C-based Toolchain Hardening]
+| style="padding-left:25px;width:200px;" valign="top" |
-| valign="top"  style="padding-left:25px;width:200px;" |
+== Collaboration ==
+[https://owasp.slack.com The OWASP Slack Channel]
-== Email List ==
+Hint: If you're new to Slack, [https://lists.owasp.org/pipermail/owasp-community/2015-July/000703.html join OWASP's slack channel first], then join #iot-security within OWASP's channel.
-[https://lists.owasp.org/mailman/listinfo/owasp_internet_of_things_top_ten_project Subscribe to the Top Ten list]
 == Quick Download ==
+[https://www.owasp.org/images/1/1c/OWASP-IoT-Top-10-2018-final.pdf OWASP IoT Top Ten 2018]
 [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping DEFCON 23]
 [https://www.owasp.org/images/2/2d/Iot_testing_methodology.JPG IoT Testing Guidance Handout]
-[https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf OWASP IoT Top Ten PDF]
+[https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf OWASP IoT Top Ten 2014 PDF]
-[https://www.owasp.org/images/8/8e/Infographic-v1.jpg OWASP IoT Top Ten Infographic]
+[https://www.owasp.org/images/b/bd/OWASP-IoT.pptx OWASP IoT Project Overview]
-[https://www.owasp.org/images/0/01/Internet_of_Things_Top_Ten_2014-OWASP-ppt.pptx OWASP IoT Top Ten PPT]
-[https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf OWASP IoT Top Ten-RSA 2015]
 == News and Events ==
-* Daniel Miessler gave his IoT talk at DEFCON 23
+* OWASP [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoTGoat IoTGoat Project] underway
-* Migrating the IoT Top Ten to be under the IoT Project
+* New firmware security analysis tool, ByteSweep
+* IoT ASVS and Testing Guide set to kick off in 2019
+* Added a [https://owasp-iot-security.slack.com/ Slack channel]
+* Added a sub-project; [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Security_Policy_Project IoT Security Policy Project]
 ==Classifications==
@@ Line 76: / Line 134: @@
     {| width="200" cellpadding="2"
     |-
-    | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
+    | rowspan="2" width="50%" valign="top" align="center" | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
-    | align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
+    | width="50%" valign="top" align="center" | [[File:Owasp-builders-small.png|link=]]
     |-
-    | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
+    | width="50%" valign="top" align="center" | [[File:Owasp-defenders-small.png|link=]]
     |-
-    | colspan="2" align="center"  | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
+    | colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
     |-
-    | colspan="2" align="center"  | [[File:Project_Type_Files_DOC.jpg|link=]]
+    | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
     |}
+|}
+= IoT Top 10 =
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
+== Internet of Things (IoT) Top 10 2018 ==
+The [https://www.owasp.org/images/1/1c/OWASP-IoT-Top-10-2018-final.pdf OWASP IoT Top 10 - 2018] is now available.
+* I1 Weak Guessable, or Hardcoded Passwords
+* I2 Insecure Network Services
+* I3 Insecure Ecosystem Interfaces
+* I4 Lack of Secure Update Mechanism
+* I5 Use of Insecure or Outdated Components
+* I6 Insufficient Privacy Protection
+* I7 Insecure Data Transfer and Storage
+* I8 Lack of Device Management
+* I9 Insecure Default Settings
+* I10 Lack of Physical Hardening
+== Internet of Things (IoT) Top 10 2014 ==
+* [[Top 10 2014-I1 Insecure Web Interface|I1 Insecure Web Interface]]
+* [[Top 10 2014-I2 Insufficient Authentication/Authorization|I2 Insufficient Authentication/Authorization]]
+* [[Top 10 2014-I3 Insecure Network Services|I3 Insecure Network Services]]
+* [[Top 10 2014-I4 Lack of Transport Encryption|I4 Lack of Transport Encryption]]
+* [[Top 10 2014-I5 Privacy Concerns|I5 Privacy Concerns]]
+* [[Top 10 2014-I6 Insecure Cloud Interface|I6 Insecure Cloud Interface]]
+* [[Top 10 2014-I7 Insecure Mobile Interface|I7 Insecure Mobile Interface]]
+* [[Top 10 2014-I8 Insufficient Security Configurability|I8 Insufficient Security Configurability]]
+* [[Top 10 2014-I9 Insecure Software/Firmware|I9 Insecure Software/Firmware]]
+* [[Top 10 2014-I10 Poor Physical Security|I10 Poor Physical Security]]
+= OWASP IoT Top 10 2018 Mapping Project =
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== IoT Top 10 2018 Mapping Project ==
+The OWASP IoT Mapping Project is intended to provide a mapping of the OWASP IoT Top 10 2018 to industry publications and sister projects. The goal is to provide resources that enable practical uses for the OWASP IoT Top 10 . As with all Top 10 lists, they should be used as a first step and expanded upon according to the applicable IoT ecosystem.
+Mappings are structured with control categories, tests, or recommendations in the left column, descriptions in the middle column, and their mapping to the OWASP IoT Top 10 2018 list in the right column. Each mapping may not have a 1 to 1 relation; however, similar recommendations and/or controls are listed. For mappings that are not applicable to the IoT Top 10 2018 list, an "N/A" is provided as the mapping.
+An example mapping of the IoT Top 10 2014 is provided below.
+[[File:2014 2018Mapping.png|center|frameless|746x746px]]
+For additional mappings, please visit the following link: https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/<nowiki/>{{Social Media Links}}
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== What is the IoT Top 10 Mapping Project? ==
+The OWASP IoT Mapping Project is intended to provide a mapping of the OWASP IoT Top 10 2018 to industry publications and sister projects. The goal is to provide resources that enable practical uses for the OWASP IoT Top 10 . As with all Top 10 lists, they should be used as a first step and expanded upon according to the applicable IoT ecosystem.
+Mappings include the following:
+* [https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/mappings/owasp-iot-top-10-2014 OWASP IoT Top 10 2014]
+* [https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/mappings/gsma-iot-security-assessment-checklist GSMA IoT Security Assessment Checklist]
+* [https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/mappings/code-of-practice Code of Practice (UK Government)]
+* [https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/mappings/enisa-baseline-security-recommendations-for-iot ENISA Baseline Security Recommendations for IoT]
+and more...
+== GitBook ==
+Mappings are hosted on GitBook using the following link https://scriptingxss.gitbook.io/owasp-iot-top-10-mapping-project/
+== Project Leaders ==
+* Aaron Guzman
+== Collaboration ==
+[https://owasp.slack.com The Slack Channel]
+|}
+= IoTGoat =
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== IoTGoat Project ==
+IoT Goat is a deliberately insecure firmware based on OpenWrt. The project’s goal is to teach users about the most common vulnerabilities typically found in IoT devices. The vulnerabilities will be based on the top 10 vulnerabilities as documented by OWASP: [[OWASP_Internet_of_Things_Project|https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project]]. IoTGoat is expected to be released by December 2019.
+To get more information on getting started or how to contribute, visit the project's Github: https://github.com/scriptingxss/IoTGoat
+{{Social Media Links}}
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== What is the IoTGoat Project? ==
+The IoTGoat Project is a deliberately insecure firmware based on OpenWrt. The project’s goal is to teach users about the most common vulnerabilities typically found in IoT devices. The vulnerabilities will be based on the IoT Top 10.
+== GitHub ==
+https://github.com/scriptingxss/IoTGoat
+== Project Leaders ==
+* Aaron Guzman
+* Fotios Chantzis
+* [[User:Calderpwn|Paulino Calderon]]
+== Related Projects ==
+* WebGoat
+* Serverless Goat
+* NodeGoat
+* RailsGoat
+== Collaboration ==
+[https://owasp.slack.com The Slack Channel]
+[https://groups.google.com/forum/#!forum/iotgoat IoTGoat Google Group]
+== Quick Download ==
+* [https://docs.google.com/presentation/d/1SJfabCBxvC3GWnmBCqisO5pyLzkB1-EVcR7s8baT0dE/edit?usp=sharing Project Kick-off Slides]
+* [https://strozfriedberg.webex.com/recordingservice/sites/strozfriedberg/recording/playback/5529b228ac514bed8cc050a9dee0f0df Project Kick-off Meeting]
+* [https://docs.google.com/spreadsheets/d/1KXX2K7ikkve6wmdfAVu-sZONgKEBuAkRij_paJUgX2w/edit?usp=sharing Project Task List]
+== News and Events ==
+* Coming Soon
+|}
+= ByteSweep =
+[[File:OWASP_Project_Header.jpg|link=]]
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== ByteSweep Project ==
+ByteSweep is a Free Software IoT security analysis platform. This platform will allow IoT device makers, large and small, to conduct fully automated security checks before they ship firmware. A Free Software IoT Firmware Security Analysis Platform
+ByteSweep Features:
+* Firmware extraction
+* File data enrichment
+* Key and password hash identification
+* Unsafe function use detection
+* 3rd party component identification
+* CVE correlation
+{{Social Media Links}}
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== What is the ByteSweep Project? ==
+A Free Software IoT Firmware Security Analysis Platform.
+== GitLab ==
+https://gitlab.com/bytesweep/bytesweep
+== Project Leaders ==
+* Matt Brown
+== Collaboration ==
+[https://owasp.slack.com The Slack Channel]
+== Quick Download ==
+* https://gitlab.com/bytesweep/bytesweep/blob/master/INSTALL.md
+|}
+= Firmware Security Testing Methodology =
+[[File:OWASP_Project_Header.jpg|link=]]
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== Firmware Security Testing Methodology ==
+The Firmware Security Testing Methodology (FSTM) is composed of nine stages tailored to enable security researchers, software developers, consultants, hobbyists, and Information Security professionals with conducting firmware security assessments.
+{| class="wikitable"
+|'''Stage'''
+|'''Description'''
+|-
+|1. Information gathering and reconnaissance
+|Acquire all relative technical and documentation details  pertaining to the target device’s firmware
+|-
+|2. Obtaining  firmware
+|Attain firmware using one or more of the proposed methods listed
+|-
+|3. Analyzing firmware
+|Examine the target firmware’s characteristics
+|-
+|4. Extracting  the filesystem
+|Carve filesystem contents from the target firmware
+|-
+|5. Analyzing filesystem contents
+|Statically analyze extracted filesystem configuration  files and binaries for vulnerabilities
+|-
+|6. Emulating  firmware
+|Emulate firmware files and components
+|-
+|7. Dynamic analysis
+|Perform dynamic security testing against firmware and  application interfaces
+|-
+|8. Runtime  analysis
+|Analyze compiled binaries during device runtime
+|-
+|9. Binary Exploitation
+|Exploit identified vulnerabilities discovered in previous  stages to attain root and/or code execution
+|}The full methodology release can be downloaded via the following https://github.com/scriptingxss/owasp-fstm/releases/download/v1.0/Firmware_Security_Testing_Methodology_Version1.pdf.
+{{Social Media Links}}
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== What is the Firmware Security Testing Methodology ==
+The Firmware Security Testing Methodology Project provides:
+*Attack walkthroughs
+*Tool usage examples
+*Screenshots
+*Companion virtual machine preloaded with tools (EmbedOS) - <nowiki>https://github.com/scriptingxss/EmbedOS</nowiki>
+== Project Leaders ==
+* Aaron Guzman
+== Quick Download ==
+* https://github.com/scriptingxss/owasp-fstm/releases
 |}
 = IoT Attack Surface Areas =
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== IoT Attack Surface Areas Project ==
 The OWASP IoT Attack Surface Areas (DRAFT) are as follows:
-{| border="1" class="wikitable" style="text-align: left"
+{| class="wikitable" style="text-align: left" border="1"
 ! Attack Surface
 ! Vulnerability
 |-
-| '''Ecosystem Access Control'''
+| '''Ecosystem (general)'''
 |
+* Interoperability standards
+* Data governance
+* System wide failure
+* Individual stakeholder risks
 * Implicit trust between components
 * Enrollment security
@@ Line 105: / Line 406: @@
 | '''Device Memory'''
 |
-* Cleartext usernames
+* Sensitive data
-* Cleartext passwords
+** Cleartext usernames
-* Third-party credentials
+** Cleartext passwords
-* Encryption keys
+** Third-party credentials
+** Encryption keys
 |-
 | '''Device Physical Interfaces'''
@@ Line 118: / Line 420: @@
 * Reset to insecure state
 * Removal of storage media
+* Tamper resistance
+* Debug port
+** UART (Serial)
+** JTAG / SWD
+* Device ID/Serial number exposure
 |-
 | '''Device Web Interface'''
 |
-* SQL injection
+* Standard set of web application vulnerabilities, see:
-* Cross-site scripting
+** [[:Category:OWASP Top Ten Project|OWASP Web Top 10]]
-* Cross-site Request Forgery
+** [[:Category:OWASP Application Security Verification Standard Project|OWASP ASVS]]
-* Username enumeration
+** [[:Category:OWASP Testing Project|OWASP Testing guide]]
-* Weak passwords
+* Credential management vulnerabilities:
-* Account lockout
+** Username enumeration
-* Known default credentials
+** Weak passwords
+** Account lockout
+** Known default credentials
+** Insecure password recovery mechanism
 |-
 | '''Device Firmware'''
 |
-* Hardcoded credentials
+* Sensitive data exposure ([[Top 10 2013-A6-Sensitive Data Exposure|See OWASP Top 10 - A6 Sensitive data exposure]]):
-* Sensitive information disclosure
+** Backdoor accounts
-* Sensitive URL disclosure
+** Hardcoded credentials
-* Encryption keys
+** Encryption keys
+** Encryption (Symmetric, Asymmetric)
+** Sensitive information
+** Sensitive URL disclosure
 * Firmware version display and/or last update date
+* Vulnerable services (web, ssh, tftp, etc.)
+** Verify for old sw versions and possible attacks (Heartbleed, Shellshock, old PHP versions etc)
+* Security related function API exposure
+* Firmware downgrade possibility
 |-
 | '''Device Network Services'''
@@ Line 151: / Line 468: @@
 * Vulnerable UDP Services
 * DoS
+* Device Firmware OTA update block
+* Firmware loaded over insecure channel (no TLS)
+* Replay attack
+* Lack of payload verification
+* Lack of message integrity check
+* Credential management vulnerabilities:
+** Username enumeration
+** Weak passwords
+** Account lockout
+** Known default credentials
+** Insecure password recovery mechanism
 |-
 | '''Administrative Interface'''
 |
-* SQL injection
+* Standard set of web application vulnerabilities, see:
-* Cross-site scripting
+** [[:Category:OWASP Top Ten Project|OWASP Web Top 10]]
-* Cross-site Request Forgery
+** [[:Category:OWASP Application Security Verification Standard Project|OWASP ASVS]]
-* Username enumeration
+** [[:Category:OWASP Testing Project|OWASP Testing guide]]
-* Weak passwords
+* Credential management vulnerabilities:
-* Account lockout
+** Username enumeration
-* Known default credentials
+** Weak passwords
+** Account lockout
+** Known default credentials
+** Insecure password recovery mechanism
 * Security/encryption options
 * Logging options
 * Two-factor authentication
+* Check for insecure direct object references
 * Inability to wipe device
 |-
@@ Line 171: / Line 503: @@
 * Data encrypted with discovered keys
 * Lack of data integrity checks
+* Use of static same enc/dec key
 |-
 | '''Cloud Web Interface'''
 |
-* SQL injection
-* Cross-site scripting
+* Standard set of web application vulnerabilities, see:
-* Cross-site Request Forgery
+** [[:Category:OWASP Top Ten Project|OWASP Web Top 10]]
-* Username enumeration
+** [[:Category:OWASP Application Security Verification Standard Project|OWASP ASVS]]
-* Weak passwords
+** [[:Category:OWASP Testing Project|OWASP Testing guide]]
-* Account lockout
+* Credential management vulnerabilities:
-* Known default credentials
+** Username enumeration
+** Weak passwords
+** Account lockout
+** Known default credentials
+** Insecure password recovery mechanism
 * Transport encryption
-* Insecure password recovery mechanism
 * Two-factor authentication
 |-
@@ Line 198: / Line 534: @@
 * Update location writable
 * Update verification
+* Update authentication
 * Malicious update
 * Missing update mechanism
@@ Line 220: / Line 557: @@
 * Weak access controls
 * Injection attacks
+* Hidden services
 |-
 | '''Ecosystem Communication'''
@@ Line 235: / Line 573: @@
 * Short range
 * Non-standard
+* Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA)
+* Protocol fuzzing
 |-
+| '''Authentication/Authorization'''
+|
+* Authentication/Authorization related values (session key, token, cookie, etc.) disclosure
+* Reusing of session key, token, etc.
+* Device to device authentication
+* Device to mobile Application authentication
+* Device to cloud system authentication
+* Mobile application to cloud system authentication
+* Web application to cloud system authentication
+* Lack of dynamic authentication
+|-
+| '''Privacy'''
+|
+* User data disclosure
+* User/device location disclosure
+* Differential privacy
+|-
+| '''Hardware (Sensors)'''
+|
+* Sensing Environment Manipulation
+* Tampering (Physically)
+* Damage (Physicall)
+|-
 |}
-= Top IoT Vulnerabilities=
+{{Social Media Links}}
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
-The top IoT vulnerabilities (DRAFT) are as follow:
+== What is the IoT Attack Surface Areas Project? ==
-{| border="1" class="wikitable" style="text-align: left"
+The IoT Attack Surface Areas Project provides a list of attack surfaces that should be understood by manufacturers, developers, security researchers, and those looking to deploy or implement IoT technologies within their organizations.
+== Project Leaders ==
+* Daniel Miessler
+* Craig Smith
+== Related Projects ==
+* [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project The OWASP Mobile Top 10 Project]
+* [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project The OWASP Web Top 10 Project]
+== Collaboration ==
+[https://owasp.slack.com The Slack Channel]
+== Quick Download ==
+* Coming Soon
+== News and Events ==
+* Coming Soon
+|}
+= IoT Vulnerabilities =
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== IoT Vulnerabilities Project ==
+{| class="wikitable" style="text-align: left" border="1"
 ! Vulnerability
 ! Attack Surface
@@ Line 264: / Line 662: @@
 |
 * Ability to set account passwords to '1234' or '123456' for example.
+* Usage of pre-programmed default passwords
 |-
 | '''Account Lockout'''
@@ Line 278: / Line 677: @@
 * Device Network Services
 |
-* Network services are not properly encrypted to prevent eavesdropping by attackers
+* Network services are not properly encrypted to prevent eavesdropping or tampering  by attackers
 |-
 | '''Two-factor Authentication'''
@@ Line 336: / Line 735: @@
 * Current firmware version is not displayed and/or the last update date is not displayed
 |-
+| '''Firmware and storage extraction'''
+|
+* JTAG / SWD interface
+* [https://www.flashrom.org/Flashrom In-Situ dumping]
+* Intercepting a OTA update
+* Downloading from the manufacturers web page
+* [https://www.exploitee.rs/index.php/Exploitee.rs_Low_Voltage_e-MMC_Adapter eMMC tapping]
+* Unsoldering the SPI Flash / eMMC chip and reading it in a adapter
+|
+* Firmware contains a lot of useful information, like source code and binaries of running services, pre-set passwords, ssh keys etc.
+|-
+| '''Manipulating the code execution flow of the device'''
+|
+* JTAG / SWD interface
+* [https://wiki.newae.com/Main_Page Side channel attacks like glitching]
+|
+* With the help of a JTAG adapter and gdb we can modify the execution of firmware in the device and bypass almost all software based security controls.
+* Side channel attacks can also modify the execution flow or can be used to leak interesting information from the device
+|-
+| '''Obtaining console access'''
+|
+* Serial interfaces (SPI / UART)
+|
+* By connecting to a serial interface, we will obtain full console access to a device
+* Usually security measures include custom bootloaders that prevent the attacker from entering single user mode, but that can also be bypassed.
+|-
+| '''Insecure 3rd party components'''
+|
+* Software
+|
+* Out of date versions of busybox, openssl, ssh, web servers, etc.
+|-
 |}
-= Top 10 IoT Vulnerabilities (2014)=
+{{Social Media Links}}
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
-For each attack surface areas, the following sections are included:
+== What is the IoT Vulnerabilities Project? ==
-* A description of the attack surface
+The IoT Vulnerabilities Project provides:
-* Threat agents
-* Attack vectors
+* Information on the top IoT vulnerabilities
-* Security weaknesses
+* The attack surface associated with the vulnerability
-* Technical impacts
+* A summary of the vulnerability
-* Business impacts
-* Example vulnerabilities
+== Project Leaders ==
-* Example attacks
-* Guidance on how to avoid the issue
+* Daniel Miessler
-* References to OWASP and other related resources
+* Craig Smith
-== ==
-* [[Top_10_2014-I1 Insecure Web Interface | I1 Insecure Web Interface]]
+== Related Projects ==
-* [[Top_10_2014-I2 Insufficient Authentication/Authorization | I2 Insufficient Authentication/Authorization]]
-* [[Top_10_2014-I3 Insecure Network Services | I3 Insecure Network Services]]
+* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
-* [[Top_10_2014-I4 Lack of Transport Encryption | I4 Lack of Transport Encryption]]
+* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
-* [[Top_10_2014-I5 Privacy Concerns | I5 Privacy Concerns]]
-* [[Top_10_2014-I6 Insecure Cloud Interface | I6 Insecure Cloud Interface]]
+== Collaboration ==
-* [[Top_10_2014-I7 Insecure Mobile Interface | I7 Insecure Mobile Interface]]
+[https://owasp-iot-security.slack.com The Slack Channel]
-* [[Top_10_2014-I8 Insufficient Security Configurability | I8 Insufficient Security Configurability]]
-* [[Top_10_2014-I9 Insecure Software/Firmware | I9 Insecure Software/Firmware]]
+== Resources ==
-* [[Top_10_2014-I10 Poor Physical Security | I10 Poor Physical Security]]
+* [https://www.owasp.org/index.php/Top_IoT_Vulnerabilities Top 10 IoT Vulnerabilities from 2014]
+== News and Events ==
+* Coming Soon
+|}
+= Medical Devices =
-= IoT Testing Guides =
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
-== Tester IoT Security Guidance ==
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
-(DRAFT)
+== Medical Device Testing ==
-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.
+The Medical Device Testing project is intended to provide some basic attack surface considerations that should be evaluated before shipping Medical Device equipment.
-{| border="1" class="wikitable" style="text-align: left"
+{| class="wikitable" style="text-align: left" border="1"
-! Category
+! Attack Surface
-! IoT Security Consideration
+! Vulnerability
 |-
-| '''I1: Insecure Web Interface'''
+| '''Ecosystem (general)'''
 |
-* Assess any web interface to determine if weak passwords are allowed
+* Interoperability standards
-* Assess the account lockout mechanism
+* Data governance
-* Assess the web interface for XSS, SQLi and CSRF vulnerabilities and other web application vulnerabilities
+* System wide failure
-* Assess the use of HTTPS to protect transmitted information
+* Individual stakeholder risks
-* Assess the ability to change the username and password
+* Implicit trust between components
-* Determine if web application firewalls are used to protect web interfaces
+* Enrollment security
+* Decommissioning system
+* Lost access procedures
 |-
-| '''I2: Insufficient Authentication/Authorization'''
+| '''HL7'''
 |
-* Assess the solution for the use of strong passwords where authentication is needed
+* XML Parsing
-* Assess the solution for multi-user environments and ensure it includes functionality for role separation
+** XSS
-* Assess the solution for Implementation two-factor authentication where possible
+* Information Disclosure
-* 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'''
+| '''Device Memory'''
 |
-* Assess the solution to ensure network services don't respond poorly to buffer overflow, fuzzing or denial of service attacks
+* Sensitive data
-* Assess the solution to ensure test ports are are not present
+** Cleartext usernames
+** Cleartext passwords
+** Third-party credentials
+** Encryption keys
 |-
-| '''I4: Lack of Transport Encryption'''
+| '''Device Physical Interfaces'''
 |
-* Assess the solution to determine the use of encrypted communication between devices and between devices and the internet
+* Firmware extraction
-* Assess the solution to determine if accepted encryption practices are used and if proprietary protocols are avoided
+* User CLI
-* Assess the solution to determine if a firewall option available is available
+* Admin CLI
-|-
+* Privilege escalation
-| '''I5: Privacy Concerns'''
+* Reset to insecure state
+* Removal of storage media
+* Tamper resistance
+* Debug port
+* Device ID/Serial number exposure
+|-
+| '''Device Web Interface'''
 |
-* Assess the solution to determine the amount of personal information collected
+* Standard set of web vulnerabilities:
-* Assess the solution to determine if collected personal data is properly protected using encryption at rest and in transit
+** SQL injection
-* Assess the solution to determine if Ensuring data is de-identified or anonymized
+** Cross-site scripting
-* Assess the solution to ensure end-users are given a choice for data collected beyond what is needed for proper operation of the device
+** Cross-site Request Forgery
+** Username enumeration
+* Credential management vulnerabilities:
+** Username enumeration
+** Weak passwords
+** Account lockout
+** Known default credentials
+** Insecure password recovery mechanism
 |-
-| '''I6: Insecure Cloud Interface'''
+| '''Device Firmware'''
 |
-* Assess the cloud interfaces for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces)
+* Sensitive data exposure:
-* Assess the cloud-based web interface to ensure it disallows weak passwords
+** Backdoor accounts
-* Assess the cloud-based web interface to ensure it includes an account lockout mechanism
+** Hardcoded credentials
-* Assess the cloud-based web interface to determine if two-factor authentication is used
+** Encryption keys
-* Assess any cloud interfaces for XSS, SQLi and CSRF vulnerabilities and other vulnerabilities
+** Encryption (Symmetric, Asymmetric)
-* Assess all cloud interfaces to ensure transport encryption is used
+** Sensitive information
-* Assess the cloud interfaces to determine if the option to require strong passwords is available
+** Sensitive URL disclosure
-* Assess the cloud interfaces to determine if the option to force password expiration after a specific period is available
+* Firmware version display and/or last update date
-* Assess the cloud interfaces to determine if the option to change the default username and password is available
+* Vulnerable services (web, ssh, tftp, etc.)
+* Security related function API exposure
+* Firmware downgrade
 |-
-| '''I7: Insecure Mobile Interface'''
+| '''Device Network Services'''
 |
-* Assess the mobile interface to ensure it disallows weak passwords
+* Information disclosure
-* Assess the mobile interface to ensure it includes an account lockout mechanism
+* User CLI
-* Assess the mobile interface to determine if it Implements two-factor authentication (e.g Apple's Touch ID)
+* Administrative CLI
-* Assess the mobile interface to determine if it uses transport encryption
+* Injection
-* Assess the mobile interface to determine if the option to require strong passwords is available
+* Denial of Service
-* Assess the mobile interface to determine if the option to force password expiration after a specific period is available
+* Unencrypted Services
-* Assess the mobile interface to determine if the option to change the default username and password is available
+* Poorly implemented encryption
-* Assess the mobile interface to determine the amount of personal information collected
+* Test/Development Services
+* Buffer Overflow
+* UPnP
+* Vulnerable UDP Services
+* DoS
+* Device Firmware OTA update block
+* Replay attack
+* Lack of payload verification
+* Lack of message integrity check
+* Credential management vulnerabilities:
+** Username enumeration
+** Weak passwords
+** Account lockout
+** Known default credentials
+** Insecure password recovery mechanism
 |-
-| '''I8: Insufficient Security Configurability'''
+| '''Administrative Interface'''
 |
-* Assess the solution to determine if password security options (e.g. Enabling 20 character passwords or enabling two-factor authentication) are available
+* Standard web vulnerabilities:
-* Assess the solution to determine if encryption options (e.g. Enabling AES-256 where AES-128 is the default setting) are available
+** SQL injection
-* Assess the solution to determine if logging for security events is available
+** Cross-site scripting
-* Assess the solution to determine if alerts and notifications to the user for security events are available
+** Cross-site Request Forgery
+** Username enumeration
+* Credential management vulnerabilities:
+** Username enumeration
+** Weak passwords
+** Account lockout
+** Known default credentials
+** Insecure password recovery mechanism
+* Security/encryption options
+* Logging options
+* Two-factor authentication
+* Inability to wipe device
 |-
-| '''I9: Insecure Software/Firmware'''
+| '''Local Data Storage'''
 |
-* Assess the device to ensure it includes update capability and can be updated quickly when vulnerabilities are discovered
+* Unencrypted data
-* Assess the device to ensure it uses encrypted update files and that the files are transmitted using encryption
+* Data encrypted with discovered keys
-* Assess the device to ensure is uses signed files and then validates that file before installation
+* Lack of data integrity checks
+* Use of static same enc/dec key
 |-
-| '''I10: Poor Physical Security'''
+| '''Cloud Web Interface'''
 |
-* Assess the device to ensure it utilizes a minimal number of physical external ports (e.g. USB ports) on the device
+* Standard set of web vulnerabilities:
-* Assess the device to determine if it can be accessed via unintended methods such as through an unnecessary USB port
+** SQL injection
-* Assess the device to determine if it allows for disabling of unused physical ports such as USB
+** Cross-site scripting
-* Assess the device to determine if it includes the ability to limit administrative capabilities to a local interface only
+** Cross-site Request Forgery
-|}
+* Credential management vulnerabilities:
+** Username enumeration
-===General Recommendations===
+** Weak passwords
+** Account lockout
-Consider the following recommendations for all user interfaces (local device, cloud-based and mobile):
+** Known default credentials
-* Avoid potential Account Harvesting issues by:
+** Insecure password recovery mechanism
-** Ensuring valid user accounts can't be identified by interface error messages
+* Transport encryption
-** Ensuring strong passwords are required by users
+* Two-factor authentication
-** Implementing account lockout after 3 - 5 failed login attempts
-= IoT Security Guidance =
-== '''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.
-{| border="1" class="wikitable" style="text-align: left"
-! Category
-! IoT Security Consideration
 |-
-| '''I1: Insecure Web Interface'''
+| '''Third-party Backend APIs'''
 |
-* Ensure that any web interface in the product disallows weak passwords
+* Unencrypted PII sent
-* Ensure that any web interface in the product has an account lockout mechanism
+* Encrypted PII sent
-* Ensure that any web interface in the product has been tested for XSS, SQLi and CSRF vulnerabilities
+* Device information leaked
-* Ensure that any web interface has the ability to use HTTPS to protect transmitted information
+* Location leaked
-* 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'''
+| '''Update Mechanism'''
 |
-* Ensure that any access requiring authentication requires strong passwords
+* Update sent without encryption
-* Ensure that user roles can be properly segregated in multi-user environments
+* Updates not signed
-* Implement two-factor authentication where possible
+* Update location writable
-* Ensure password recovery mechanisms are secure
+* Update verification
-* Ensure that users have the option to require strong passwords
+* Update authentication
-* Ensure that users have the option to force password expiration after a specific period
+* Malicious update
-* Ensure that users have the option to change the default username and password
+* Missing update mechanism
+* No manual update mechanism
 |-
-| '''I3: Insecure Network Services'''
+| '''Mobile Application'''
 |
-* Ensure all devices operate with a minimal number of network ports active
+* Implicitly trusted by device or cloud
-* Ensure all devices do not make network ports and/or services available to the internet via UPnP for example
+* Username enumeration
-* Review all required network services for vulnerabilities such as buffer overflows or denial of service
+* Account lockout
+* Known default credentials
+* Weak passwords
+* Insecure data storage
+* Transport encryption
+* Insecure password recovery mechanism
+* Two-factor authentication
 |-
-| '''I4: Lack of Transport Encryption'''
+| '''Vendor Backend APIs'''
 |
-* Ensure all communication between system components is encrypted as well as encrypting traffic between the system or device and the internet
+* Inherent trust of cloud or mobile application
-* Use recommended and accepted encryption practices and avoid proprietary protocols
+* Weak authentication
-* Ensure SSL/TLS implementations are up to date and properly configured
+* Weak access controls
-* Consider making a firewall option available for the product
+* Injection attacks
+* Hidden services
 |-
-| '''I5: Privacy Concerns'''
+| '''Ecosystem Communication'''
 |
-* Ensure only the minimal amount of personal information is collected from consumers
+* Health checks
-* Ensure all collected personal data is properly protected using encryption at rest and in transit
+* Heartbeats
-* Ensure only authorized individuals have access to collected personal information
+* Ecosystem commands
-* Ensure only less sensitive data is collected
+* Deprovisioning
-* Ensuring data is de-identified or anonymized
+* Pushing updates
-* 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'''
+| '''Network Traffic'''
 |
-* Ensure all cloud interfaces are reviewed for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces)
+* LAN
-* Ensure that any cloud-based web interface disallows weak passwords
+* LAN to Internet
-* Ensure that any cloud-based web interface has an account lockout mechanism
+* Short range
-* Implement two-factor authentication for cloud-based web interfaces
+* Non-standard
-* Ensure that all cloud interfaces use transport encryption
+* Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA)
-* Ensure that any cloud-based web interface has been tested for XSS, SQLi and CSRF vulnerabilities
+* Protocol fuzzing
-* 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'''
+| '''Authentication/Authorization'''
 |
-* Ensure that any mobile application disallows weak passwords
+* Authentication/Authorization related values (session key, token, cookie, etc.) disclosure
-* Ensure that any mobile application has an account lockout mechanism
+* Reusing of session key, token, etc.
-* Implement two-factor authentication for mobile applications (e.g Apple's Touch ID)
+* Device to device authentication
-* Ensure that any mobile application uses transport encryption
+* Device to mobile Application authentication
-* Ensure that users have the option to require strong passwords
+* Device to cloud system authentication
-* Ensure that users have the option to force password expiration after a specific period
+* Mobile application to cloud system authentication
-* Ensure that users have the option to change the default username and password
+* Web application to cloud system authentication
-|-
+* Lack of dynamic authentication
-| '''I8: Insufficient Security Configurability'''
+|-
+| '''Data Flow'''
 |
-* Ensure password security options are made available (e.g. Enabling 20 character passwords or enabling two-factor authentication)
+* What data is being captured?
-* Ensure encryption options are made available (e.g. Enabling AES-256 where AES-128 is the default setting)
+* How does it move within the ecosystem?
-* Ensure secure logging is available for security events
+* How is it protected in transit?
-* Ensure alerts and notifications are available to the user for security events
+* How is it protected at rest?
-|-
+* Who is that data shared with?
-| '''I9: Insecure Software/Firmware'''
+|-
+| '''Hardware (Sensors)'''
 |
-* Ensure all system devices have update capability and can be updated quickly when vulnerabilities are discovered
+* Sensing Environment Manipulation
-* Ensure update files are encrypted and that the files are also transmitted using encryption
+* Tampering (Physically)
-* Ensure that update files are signed and then validated by the device before installing
+* Damaging (Physically)
-* Ensure update servers are secure
+* Failure state analysis
-* 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===
+{{Social Media Links}}
-Consider the following recommendation for all Internet of Things products:
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
-* 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. ]
+== What is the Medical Attack Surfaces project? ==
+The Medical Attack Surfaces project provides:
-== '''Developer IoT Security Guidance''' ==
+* A simple way for testers, manufacturers, developers, and users to get an understanding of the complexity of a modern medical environment
+* Allows people to visualize the numerous attack surfaces that need to be defended within medical equipment ecosystems
-(DRAFT)
+== Project Leaders ==
-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 [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Framework_Assessment Secure IoT Framework] in order to proactively address many of the concerns listed below.
+* Daniel Miessler
-{| border="1" class="wikitable" style="text-align:left;"
+== Related Projects ==
-! Category
-! IoT Security Consideration
-! Recommendations
-|- style="vertical-align:top;"
-| '''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 [https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities#Generic_Application_Frameworks 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.
-|- style="vertical-align:top;"
-| '''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 [https://www.owasp.org/index.php/Authentication_Cheat_Sheet OWASP Authentication Cheat Sheet]
-|- style="vertical-align:top;"
-| '''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.
-|- style="vertical-align:top;"
-| '''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.
-|- style="vertical-align:top;"
-| '''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.
-|- style="vertical-align:top;"
-| '''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 [https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project Cloud Top 10 Security Risks] documents.
-|- style="vertical-align:top;"
-| '''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 [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project OWASP Mobile Project] for further guidance.
-|- style="vertical-align:top;"
-| '''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.
+* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
-|- style="vertical-align:top;"
+* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
-| '''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).
+== Collaboration ==
+[https://owasp-iot-security.slack.com The Slack Channel]
-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.
+== Resources ==
+* [https://www.owasp.org/index.php/IoT_Firmware_Analysis IoT Firmware Analysis Primer]
+* [https://otalliance.org/initiatives/internet-things Online Trust Alliance - Internet of Things]
+* [https://people.debian.org/~aurel32/qemu/ Pre-compiled QEMU images]
+* [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]
+* [https://craigsmith.net/episode-11-1-firmware-extraction/ Short Firmware Extraction Video]
+* [https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/ Firmware Emulation with QEMU]
+* [https://craigsmith.net/episode-18-1-file-extraction-from-network-capture/ File Extraction from Network Capture]
-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.
+== News and Events ==
-|- style="vertical-align:top;"
+* Daniel Miessler presented on using Adaptive Testing Methodologies to evaluate the security of medical devices at RSA 2017.
-| '''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===
+= Firmware Analysis =
-Consider the following recommendations for all user interfaces (local device, cloud-based and mobile):
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
-* 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. ]
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
-== '''Consumer IoT Security Guidance''' ==
-(DRAFT)
+== Firmware Analysis Project ==
-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.
+The Firmware Analysis Project is intended to provide security testing guidance for the IoT Attack Surface "Device Firmware":
-{| border="1" class="wikitable" style="text-align: left"
+{| class="wikitable" style="text-align: left" border="1"
-! Category
+! Section
-! IoT Security Consideration
+!
 |-
-| '''I1: Insecure Web Interface'''
 |
-* If your system has the option to use HTTPS, ensure it is enabled
+Device Firmware Vulnerabilities
-* 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
+* Out-of-date core components
-* 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
+* Unsupported core components
-* If the system has account lockout functionality, ensure that it is enabled
+* Expired and/or self-signed certificates
-* Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
+* Same certificate used on multiple devices
-|-
+* Admin web interface concerns
-| '''I2: Insufficient Authentication/Authorization'''
+* Hardcoded or easy to guess credentials
+* Sensitive information disclosure
+* Sensitive URL disclosure
+* Encryption key exposure
+* Backdoor accounts
+* Vulnerable services (web, ssh, tftp, etc.)
+|-
 |
-* 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
+Manufacturer Recommendations
-* 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
+* Ensure that supported and up-to-date software is used by developers
-* Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
+* Ensure that robust update mechanisms are in place for devices
-|-
+* Ensure that certificates are not duplicated across devices and product lines.
-| '''I4: Lack of Transport Encryption'''
+* Ensure supported and up-to-date software is used by developers
+* Develop a mechanism to ensure a new certificate is installed when old ones expire
+* Disable deprecated SSL versions
+* Ensure developers do not code in easy to guess or common admin passwords
+* Ensure services such as SSH have a secure password created
+* Develop a mechanism that requires the user to create a secure admin password during initial device setup
+* Ensure developers do not hard code passwords or hashes
+* Have source code reviewed by a third party before releasing device to production
+* Ensure industry standard encryption or strong hashing is used
+|-
 |
-* If your system has the option to use HTTPS, ensure it is enabled
+Device Firmware Guidance and Instruction
-|-
-| '''I5: Privacy Concerns'''
 |
-* Do not enter sensitive information into the system that is not absolutely required, e.g. address, DOB, CC, etc.
+* Firmware file analysis
-* Deny data collection if it appears to be beyond what is needed for proper operation of the device (If provided the choice)
+* Firmware extraction
-|-
+* Dynamic binary analysis
-| '''I6: Insecure Cloud Interface'''
+* Static binary analysis
+* Static code analysis
+* Firmware emulation
+* File system analysis
+|-
 |
-* If your system has the option to use HTTPS, ensure it is enabled
+Device Firmware Tools
-* 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)
+* [https://github.com/craigz28/firmwalker Firmwalker]
-* If the mobile application has the option to use two factory authentication such as Apple's Touch ID, ensure it is enabled
+* [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]
-* If the system has account lockout functionality, ensure that it is enabled
+* [https://github.com/angr/angr Angr binary analysis framework]
-* If the system has the option to require strong passwords, ensure that is enabled
+* [http://binwalk.org/ Binwalk firmware analysis tool]
-* If the system has the option to require new passwords after 90 days for example, ensure that is enabled
+* [http://www.binaryanalysis.org/en/home Binary Analysis Tool]
-* Do not enter sensitive information into the mobile application that is not absolutely required, e.g. address, DOB, CC, etc.
+* [https://github.com/firmadyne/firmadyne Firmadyne]
-|-
+* Firmware Analysis Comparison Toolkit
-| '''I8: Insufficient Security Configurability'''
+* [https://gitlab.com/bytesweep/bytesweep ByteSweep]
+|-
 |
-* If your system has the option, enable any logging functionality for security-related events
+Vulnerable Firmware
-* 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
+* [https://github.com/praetorian-inc/DVRF Damn Vulnerable Router Firmware]
-* If your system has the option to download updates securely, ensure it is enabled
+* [https://github.com/scriptingxss/IoTGoat OWASP IoTGoat]
-* 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
+|}{{Social Media Links}}
-* Disable any unused physical ports through the administrative interface
-|}
-===General Recommendations===
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
-If you are looking to purchase a device or system, consider the following recommendations:
+== What is the Firmware Analysis Project? ==
-* 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. ]
+The Firmware Analysis Project provides:
+* Security testing guidance for vulnerabilities in the "Device Firmware" attack surface
+* Steps for extracting file systems from various firmware files
+* Guidance on searching a file systems for sensitive of interesting data
+* Information on static analysis of firmware contents
+* Information on dynamic analysis of emulated services (e.g. web admin interface)
+* Testing tool links
+* A site for pulling together existing information on firmware analysis
+== Project Leaders ==
-= Talks =
+* Craig Smith
-RSA Conference San Francisco <br>
+== Related Projects ==
-[https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf Securing the Internet of Things: Mapping IoT Attack Surface Areas with the OWASP IoT Top 10 Project] <br>
-Daniel Miessler, Practice Principal <br>
-April 21, 2015 <br>
---- <br>
-Defcon 23 <br>
-[https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping] <br>
-Daniel Miessler <br>
-August 6-9, 2015
-= Curated IoT Reading =
+* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
+* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
-* [http://sharedli.st/craigz28 Craig Smith's IoT Reading List]
+* [https://www.owasp.org/index.php/OWASP_Embedded_Application_Security OWASP Embedded Application Security Project]
+== Collaboration ==
+[https://owasp-iot-security.slack.com The Slack Channel]
-= Community =
+== Resources ==
+* [https://www.owasp.org/index.php/IoT_Firmware_Analysis IoT Firmware Analysis Primer]
+* [https://otalliance.org/initiatives/internet-things Online Trust Alliance - Internet of Things]
+* [https://people.debian.org/~aurel32/qemu/ Pre-compiled QEMU images]
+* [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]
+* [https://craigsmith.net/episode-11-1-firmware-extraction/ Short Firmware Extraction Video]
+* [https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/ Firmware Emulation with QEMU]
+* [https://craigsmith.net/episode-18-1-file-extraction-from-network-capture/ File Extraction from Network Capture]
-[https://www.iamthecavalry.org/ I Am The Cavalry]
+== News and Events ==
+* Coming Soon
-A global grassroots organization that is focused on issues where computer security intersects public safety and human life.
+|}
-Their areas of focus include:
+= IoT Event Logging Project=
-* Medical devices
-* Automobiles
-* Home Electronics
-* Public Infrastructure
-== ==
-[http://builditsecure.ly BuildItSecure.ly]
-A project focused on helping small business connect with security researchers to aid in securing their IoT-based products before going market.
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:                   OWASP_Project_Header.jpg|link=]]</div>
-Their goals include:
+{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-* Focus effort towards small business
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
-* Build partnerships
-* Coordinate efforts
-* Curate informational resources
-* Present research
-== ==
-[https://otalliance.org 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.
+== IoT Logging Events==
-Addressing the mounting concerns, in January 2015 the Online Trust Alliance, established the [https://otalliance.org/initiatives/internet-things 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.
+This is a working draft of the recommended minimum IoT Device logging events. This includes many   different types of devices, including consumer IoT, enterprise IoT, and ICS/SCADA type devices.
-== ==
-[https://allseenalliance.org/framework 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.
+{| class="wikitable" style="text-align: left" border="1"
-== ==
+! Event Category
-[http://www.iiconsortium.org/ The Industrial Internet Consortium (IIC)]
+! Events
+|-
+| '''Request Exceptions'''
+|
+* Attempt to Invoke Unsupported HTTP Method
+* Unexpected Quantity of Characters in Parameter
+* Unexpected Type of Characters in Parameter
+|-
+| '''Authentication Exceptions'''
+|
+* Multiple Failed Passwords
+* High Rate of Login Attempts
+* Additional POST Variable
+* Deviation from Normal GEO Location
+|-
+| '''Session Exceptions'''
+|
+* Modifying the Existing Cookie
+* Substituting Another User's Valid SessionID or Cookie
+* Source Location Changes During Session
+|-
+| '''Access Control Exceptions'''
+|
+* Modifying URL Argument Within a GET for Direct Object Access Attempt
+* Modifying Parameter Within a POST for Direct Object Access Attempt
+* Forced Browsing Attempt
+|-
+| '''Ecosystem Membership Exceptions'''
+|
+* Traffic Seen from Disenrolled System
+* Traffic Seen from Unenrolled System
+* Failed Attempt to Enroll in Ecosystem
+* Multiple Attempts to Enroll in Ecosystem
+|-
+| '''Device Access Events'''
+|
+* Device Case Tampering Detected
+* Device Logic Board Tampering Detected
+|-
+| '''Administrative Mode Events'''
+|
+* Device Entered Administrative Mode
+* Device Accessed Using Default Administrative Credentials
+|-
+| '''Input Exceptions'''
+|
+* Double Encoded Character
+* Unexpected Encoding Used
+|-
+| '''Command Injection Exceptions'''
+|
+* Blacklist Inspection for Common SQL Injection Values
+* Abnormal Quantity of Returned Records
+|-
+| '''Honey Trap Exceptions'''
+|
+* Honey Trap Resource Requested
+* Honey Trap Data Used
+|-
+| '''Reputation Exceptions'''
+|
+* Suspicious or Disallowed User Source Location
-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.
+|-
-== ==
+|}
-[http://securingsmartcities.org/ 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.
+{{Social Media Links}}
-= Podcasts =
+| style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:  25px;" valign="top" |
-* [http://iotpodcast.com/ The Internet of Things Podcast]
+== What is the IoT Security Logging Project? ==
-* [http://www.iot-inc.com/tag/podcasts/ IoT Inc]
-* [https://soundcloud.com/craig-smith-381 IoT This Week]
-* [http://farstuff.com/ Farstuff: The Internet of Things Podcast]
+The IoT Secure Logging Project provides a list of core events that should be logged in any IoT-related system. The project exists because IoT systems in general are not logging nearly enough events to constitute input for a solid detection and response program around IoT devices, and for companies that want to do this there are not many good resources for what should be logged.
-= IoT Conferences =
+== Project Leaders ==
-* [http://www.iotevents.org Internet of Things Events]
+* Daniel Miessler
-Conference Call for Papers
+== Related Projects ==
-* [http://www.wikicfp.com/cfp/servlet/tool.search?q=internet+of+things&year=t WikiCFP - Internet of Things]
-* [http://www.wikicfp.com/cfp/servlet/tool.search?q=iot&year=t WikiCFP - IoT]
-= IoT Framework Assessment =
+* [https://www.owasp.org/index.php/OWASP_AppSensor_Project The OWASP AppSensor Project]
-== IoT Framework Security Considerations ==
+== Collaboration ==
+[https://owasp-iot-security.slack.com The Slack Channel]
-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).
+== Quick Download ==
+* Coming Soon
-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.
+== News and Events ==
+* Coming Soon
-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.
-; 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
+=Project About=
-: 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 =
+{{Template:Project About
+| project_name =OWASP Internet of Things Project
+| project_description =
+| project_license =CC-BY 3.0 for documentation and GPLv3 for code.
+| leader_name1 = Daniel Miessler
+| leader_email1 =
+| leader_username1 =
+| leader_name2 =Craig Smith
+| leader_email2 =
+| leader_username2 =
+| contributor_name1 = Justin Klein Keane]
+| contributor_email1 =
+| contributor_username1 = Justin_C._Klein_Keane
+| contributor_name2 = Yunsoul
+| contributor_email2 =
+| contributor_username2 = Yunsoul
+| mailing_list_name =
+| links_url1 =
+| links_name1 =
+}}
-== Principles of IoT Security ==
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-# '''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.
-__NOTOC__ <headertabs />
+__NOTOC__ <headertabs></headertabs>
-[[Category:OWASP_Project]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document]]
+[[Category:OWASP_Project]]
+[[Category:OWASP_Document]]
+[[Category:OWASP_Download]]
+[[Category:OWASP_Release_Quality_Document]]

Difference between revisions of "OWASP Internet of Things Project"

Latest revision as of 07:02, 1 November 2019

OWASP Internet of Things (IoT) Project

Updated!

Philosophy

Methodology

The Future of the OWASP IoT Top 10

Licensing

What is the OWASP Internet of Things Project?

Project Leaders

Contributors

IoT Top 2018 Contributors

Related Projects

Collaboration

Quick Download

News and Events

Classifications

Internet of Things (IoT) Top 10 2018

Internet of Things (IoT) Top 10 2014

IoT Top 10 2018 Mapping Project

What is the IoT Top 10 Mapping Project?

GitBook

Project Leaders

Collaboration

IoTGoat Project

What is the IoTGoat Project?

GitHub

Project Leaders

Related Projects

Collaboration

Quick Download

News and Events

ByteSweep Project

What is the ByteSweep Project?

GitLab

Project Leaders

Collaboration

Quick Download

Firmware Security Testing Methodology

What is the Firmware Security Testing Methodology

Project Leaders

Quick Download

IoT Attack Surface Areas Project

What is the IoT Attack Surface Areas Project?

Project Leaders

Related Projects

Collaboration

Quick Download

News and Events

IoT Vulnerabilities Project

What is the IoT Vulnerabilities Project?

Project Leaders

Related Projects

Collaboration

Resources

News and Events

Medical Device Testing

What is the Medical Attack Surfaces project?

Project Leaders

Related Projects

Collaboration

Resources

News and Events

Firmware Analysis Project

What is the Firmware Analysis Project?

Project Leaders

Related Projects

Collaboration

Resources

News and Events

IoT Logging Events

What is the IoT Security Logging Project?

Project Leaders

Related Projects

Collaboration

Quick Download

News and Events

Navigation menu

Search