The OWASP Internet of Things Security Verification Standard (ISVS) aims to establish levels of confidence in the security of IoT ecosystems by providing requirements and best practices for the software and hardware components, as well as the communicaiton of connected devices.
IoT ecosystems are often complex collections of many interconnected systems. Some of these interconnected systems are IoT systems, containing connected devices and their components, both software and hardware. Others examples of systems in IoT ecosystems are web or mobile applications and cloud components.
The ISVS focuses on providing security requirements for IoT systems and their components: IoT hardware, software, embedded applications and communication protocols. It also provides some general requirements for the IoT ecosystems in which IoT systems reside, while referring to existing industry-accepted standards as much as possible.
The security requirements provided by the ISVS can be represented as a stack. At the bottom, requirements for the hardware platform (V5) are provided. Throughout the ISVS, the hardware platform is regarded as the different hardware components that make up the foundations for a connected device. On top of the hardware platform are the Software Platform (V3) and the Communication (V4) requirements that make use of the hardware platform to enable rich application development. Requirements for these applications are provided in the user space applications requirements layer (V2). Finally, the IoT Ecosystem chapter provides a series of requirements that form the glue between the connected device and the surrounding ecosystem (V1).
The ISVS describes three security verification levels, with each level increasing in depth. Each level contains a set of requirements mapped to security-sensitive capabilities and features.
The goal of level one requirements is to provide protection against attacks that target software only, i.e. attacks that do not involve physical access to the device. Level one requirements aim to provide a security baseline for connected devices where physical compromise of the device does not result in high security impact. These are devices where the device's IP should not be protected, where no sensitive information is being stored on the device, and where compromise of one device does not allow an attacker to move laterally to other devices or systems on the IoT ecosystem.
An example of a level one device is a smart light bulb created with off the shelf hardware and software components. Compromise of the light bulb would not result in an attacker gaining access to state-of-the art technology. If no personal data is stored on the device, there is no data to be stolen. If authentication and authorization are correctly implemented on the supporting cloud infrastructure, the worst thing the attacker could do is spoof the status of the compromised light bulb.
The goal of level two requirements is to provide protection against attacks that go beyond software and that target the hardware of the device. Devices that adhere to level two requirements are devices where compromise of the device should be avoided. These are devices where the device's IP should be protected to a reasonable extent and where there is some form of sensitive information stored on the device.
Examples of level two devices are smart locks, alarm systems, smart cameras, and medical devices that aggregate measurement data and send it to a physician for analysis.
The goal of level three requirements is to provide requirements for devices where compromise should be avoided at all cost. Devices where there is highly sensitive information stored on the device or where compromise of the device can result in fraud. In addition to the security requirements provided by level one and two, level three requirements focus on defense-in-depth techniques that attempt to hinder reverse engineering and physical tampering efforts.
Examples of level three devices consist of hardware crypto wallets, smart-meters, connected vehicles, medical implants, recycle machines that trade aluminium cans for money.
IoT ecosystems can differ a lot from one another. Some ecosystems make use of sensors and hubs, some don't have sensors. Some connected devices run embedded Linux, some do not. While the ISVS aims to structure and define requirements in a way that is applicable as widely as possible, not all of the requirements in the ISVS may apply to a specific ecosystem or device. We strongly encourage tailoring ISVS to your use case and focusing on high impact requirements that are most important to your ecosystem and device. This may require a risk assessment to understand the desired level of security required.
Even though the standard is called a verification standard, its use goes much wider than providing requirements for verifying the overall security posture of connected devices and their components. The fact that requirements are written from a verification perspective ensures that each requirement is measurable and achievable in practice. As a result, requirements can be used at different stages in a connected device's development process. Some example use cases are presented below.
-
During the design of the supporting hardware platform, the hardware platform requirements in V5 are created so that they can be used to validate that the hardware platform provides all of the functionality that is required to implement the security requirements described in the other ISVS chapters.
-
The requirements listed in the ISVS can be used during the requirement elicitation phase of the project. For example, when defining security requirements at the beginning of a product's Secure Development Life Cycle, the ISVS can be used as a minimum set of requirements that should guide the product's development.
-
The ISVS can be used in procurement of custom IoT solutions. When a third party is contracted to develop an IoT product or solution, a buyer can require that the solution is developed according to a specific ISVS security level, and request proof that the solution satisfies the required ISVS security level.
-
When developing internal or external IoT security training, the ISVS can be used to guide curriculums to ensure they contain best practices for specific use cases, instead of demoing or showing common attacks against IoT systems.
-
The requirements can be used to assess the overall security posture of a device's environment. They can help to define test cases, or they can be used by security professionals to assess the device's implementation.
-
The ISVS can be used as a framework to guide the agile development process in order to have a more secure product. Since most new IoT device hardware will first be developed from prototype systems or development boards, the ISVS levels focus on software and hardware security, making it easy to integrate as a part of agile security practices in organizations. The project can start by defining an end-goal ISVS level according to the project's risk assessment and then use the ISVS requirements as tickets in the development backlog. Specific features can be prioritized, and the security efforts can be easily visualized on the board. This can also be used to prioritize auditing and reviewing tasks in the organization, where a specific requirement can be a driver for implementation, review, refactor, or auditing for a specific team member and visible as "debt" in the backlog.
The subsequent chapters of this standard provide an overview of the different requirement categories described above. Each requirement category has a dedicated chapter in which the requirements are listed together with references to relevant standards. Definitions of the different words used throughout the standard are provided in Appendix A - Glossary