Cybersecurity blog header

IoT and embedded devices security analysis following OWASP


OWASP methodology provides standardized guidance for IoT and embedded analysis

OWASP-FSTM methodology offers a standardized guide, step by step, of how to perform a security analysis on IoT and embedded devices. This guide is elaborated so that all possible topics are covered and to ensure that a detailed analysis is performed.


Everyday smart devices such as smartwatches, speakers, cookers, cleaning robots, etc. are small computers with limited processing capacity. Sometimes, in the electronic design process jargon, one may refer to onboard systems when talking about bigger devices and to “embedded systems” when referring to smaller and more limited devices. In either case, when these devices are connected and integrated into a communication network where they can exchange data, they are usually referred to as IoT devices.

But what is IoT? The Data Protection European committee defines IoT as «every infrastructure where sensors are incorporated to common and daily used devices that register, treat, modify, transfer and interact data with other devices or systems making use of their connectivity capabilities. Often, those objects are associated to unique identifiers and personal data».

OWASP-FSTM methodology focuses on the security analysis of these IoT and embedded devices.

OWASP is an acronym for Open Web Application Security Project, referring to an open organization and community with the objective to help other organizations to form, develop, acquire, manage and maintain the security aspects of their applications and devices. Their foundational idea is to erase all insecure software by providing tools, guides and methodologies that, when appropriately used, guarantee some level of security and a low level of vulnerabilities.

IoT and embedded security analysis following OWASP offers a number of advantages

Illustration 1:


The OWASP Project has been actively working on the standardization and the development of methodologies that a great number of companies and organisms of diverse countries use to guarantee the security of their devices.

The quandary: publishing source code for securization?

In order to keep devices and software secure and vulnerability free, mainly when talking about software, based on the software license, there are two main options to follow:

  • Publishing the source code, allowing the community to review, contribute and help patching some of the security problems in the code (GPL licenses and similar)
  • Internally developing security methodologies and processes or externally hiring specialized companies to carry out an IoT security audit.

From the point of view of open-source projects, the best path to secure applications is to make the software source code available to the public for peer review. Although liberating the code could lead to the appearance of high amounts of public vulnerabilities in the short term, the security of the application will improve exponentially overtime. The availability of the source code allows for an easy test and review of basic security issues that otherwise may remain hidden, but after this initial batch of discoveries, code quality will improve leading to a more robust and hardened codebase.

After the initial stages, the common path is to arrive to a mature state where vulnerabilities become very difficult to identify. This is based on the principle that as time goes by, more people will review the code, spotting different problems and fixing vulnerabilities that the original author may have missed.

From the company perspective, when internally managing the security assessment of an application or device it may not make sense to make the source code of a program available due to patenting, competence or other issues.


In this context, some companies try to achieve security through obscurity by reasoning that complexity or source unavailability makes their products more complex to analyze, sometimes to the extent that these beliefs make the products prone to be more vulnerable due to a lack of investment in security under the false sensation of security that obscurity portrays.

Ordering an IoT security audit, a useful solution

Outsourcing security analysis on IoT and embedded devices to specialized companies is often the best and only option. Specialized companies have the knowledge to audit both software and hardware providing less conventional points of view.

Professionals of the security and development have knowledge about the ins and outs of the security implications of technologies that are used in IoT and embedded devices under testing.

During the development lifecycle of smart devices, the following verification stages should be carried out:

  • Usability
  • Repeatability
  • Security

Often, the reality is that companies focus their effort on the first stage. Usability eclipses the other stages of the project and security is left on a second plane due to lack of resources and specific knowledge by the developers and designers of the devices.

Usually, security tests performed inhouse are limited to the correct ways of using a device while specialized companies may focus on covering both foreseen and unforeseen uses along with actions that may be carried out by malicious actors.

There is a widespread agreement among security researchers: «Security through obscurity is not security». To relay on hiding a vulnerability to a certain actor does not mean that it cannot be exploited by any other malicious actor.

OWASP Firmware Security Testing Methodology

The OWASP Foundation launched on December 1st, 2001, and today its guides cover almost all methodological aspects of computer security. The OWASP-FSTM guide refers to the OWASP Firmware Security Testing Methodology. The FSTM methodology is divided into nine stages that guarantee, when followed, that an investigator will carry out an exhaustive security analysis of an embedded or IoT device.

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.

¿Why is it needed use methodology?

Methodology usage is related with the modern manufacturing processes and production improvement. Security analysis tasks on IoT and embedded are a case where the application of a production management strategy such as JIT, developed in 1938 by Toyota, which claims that the best way to achieve quality and stable production is to carry out all jobs just in time.

In fact, knowing what to do and how to do it at all times allows assigning a number of resources to each task, such as the execution time, the necessary tools and the number of necessary IoT devices. Having each resource at the right time and in an orderly manner increases productivity and improves performance in audit work.

eeprom signal lines

Using a coordinated system when an assessment or investigation of hardware / firmware security helps the client in several points:

  • Ensure critical elements were analyzed and reviewed
  • Know the development state in which the analysis is
  • Adapt assessments to the manufacturing process / product review
  • Expedite alternative paths to manage critical points in planning
  • Reduce the costs of developing a new product or reviewing one yet implemented product.
  • Decrease analysis comprehension time by using a common and consistent schema in each part of the analysis
  • Strategic improvements against the rivals when it is known the points of improvement

When a reiteration process is needed, having one system and one methodology, it allows reviewing the previous points as quick as possible and resume the analysis without additional efforts.


Using a methodology for security assessments in IoT devices and embedded systems allows defining a plan when carrying out this work, guaranteeing a thorough and methodical analysis, measurable and comparable over time. It generally requires having multidisciplinary teams, since techniques that touch fields such as telecommunications, electronics and information technology must generally be used.

More articles in this series about OWASP

This article is part of a series of articles about OWASP

  1. OWASP methodology, the beacon illuminating cyber risks
  2. OWASP: Top 10 Web Application Vulnerabilities
  3. IoT and embedded devices security analysis following OWASP
  4. OWASP FSTM, stage 1: Information gathering and reconnaissance
  5. OWASP FSTM, stage 2: Obtaining IOT device firmware
  6. OWASP FSTM, stage 3: Analyzing firmware
  7. OWASP FSTM, stage 4: Extracting the filesystem
  8. OWASP FSTM, stage 5: Analyzing filesystem contents
  9. OWASP FSTM step 6: firmware emulation
  10. OWASP FSTM, step 7: Dynamic analysis
  11. OWASP FSTM, step 8: Runtime analysis
  12. OWASP FSTM, Stage 9: Exploitation of executables
  13. IoT Security assessment
  14. OWASP API Security Top 10
  15. OWASP SAMM: Assessing and Improving Enterprise Software Security
  16. OWASP: Top 10 Mobile Application Risks