Containerization does not imply security (3.2.11) about iot-security-verification-standard-isvs HOT 3 CLOSED

I agree that containers need to be properly configured and don't provide protections outside of the box. Containers for embedded are not the same as whats being used for microservices within cloud-native architectures. Scalability is less of a concern compared to the agile userspace application updatability and refined controls once configured.

We'll add a link to the OWASP Docker top 10 and LXC{D} security pages.

How about the following?

Verify that third-party applications are configured to execute within a containerized runtime environment (e.g. Linux containers, Docker, etc.) isolated from the host operating system.

I think we could expand the control objectives to be more explicit in regards to containers leveraging Linux kernel security primitives to achieve host isolation. Potentially the following:

The Linux operating system is one of the most popular in IoT. It has many features from first-line security to defense-in-depth, including the isolation mechanisms supported by namespaces and cgroups, and additional kernel security modules for access controls. Leverage these isolation mechanisms when configuring and deploying third-party applications to run within a container.

Thoughts?

from iot-security-verification-standard-isvs.

I think the second statement is really good.
However, I would prefer to make it clear in the control itself that some configuration/action is needed to ensure containers are fully isolated.

If I may, my proposal would be:
Verify that third-party applications are configured to execute within a containerized runtime environment (e.g. Linux containers, Docker, etc.) that is hardened to ensure proper isolation from the host operating system.

Alternatively, "hardened" could be replaced by "configured"?

from iot-security-verification-standard-isvs.

Added

from iot-security-verification-standard-isvs.