Difficulties to check 1.1.1. about iot-security-verification-standard-isvs HOT 5 CLOSED

The proposed changes by @scriptingxss make sense to me. They are also in-line with issue #54 - where we discuss using the term "IoT System" referring to the connected products/devices. Personally my preference goes to the following one, as there is an emphasis on the deployed environment. It's important to think about where a product will eventually be used - as this will create the product's risk profile.

Verify that the IoT system is developed with the level of security (L1, L2, or L3) applicable to the product's capabilities and risks posed in its deployed environment.

from iot-security-verification-standard-isvs.

I agree. There is a risk analysis phase that should help determine which ISVS level they aspire to achieve and I believe this requirement was supposed to be used as such. Your suggestion is similar to the threat modeling requirement but I do like the explicit call out of risk.

Any recommended enhancements we should consider to better articulate the overall risk according to ISVS levels?

from iot-security-verification-standard-isvs.

I may have misunderstood 1.1.1. too.

If the goal of 1.1.1. is to verify that the ISVS security level (L1, L2, L3) covers the risks faced by users appropriately, I would suggest:
Verify that the security level is appropriate to the risks faced by users of the system
This would be similar to NIST IR 8259 recommendations (iirc) which demands manufacturers to cover the "most common risks" faced by their customers.

If the goal of 1.1.1. is to validate the applicability / choices made for each clause (after deciding if we are in L1, L2 or L3), we can have the following requirement:
For each ISVS clause, verify that the security level is appropriate to the risks covered by the clause. If the clause is not implemented, verify that an appropriate justification exists (or something like that).
This is more aligned with 62443-4-1 and EN 303 645 (justification based on the applicable threats and the resulting risks)

The latter is more granular but goes beyond a simple "boxticking" exercise.

from iot-security-verification-standard-isvs.

Had to think about this one a bit. I appreciate the suggestions proposed. The justification bit could be subjective depending on internal risk practices and mitigation acceptance criteria's.

Thoughts on the following?

Verify that the IoT system is developed with the level of security (L1, L2, or L3) applicable to the product's capabilities and risks posed in its deployed environment.

or

Verify that the IoT system is developed following the product's risk profile in alignment with the security level (L1, L2, or L3) applicable to its capabilities.

I think both of these could be more measurable than the way its currently written. I can see a pentester evaluating a product to help determine which level it should be based on capabilities and focus test cases from there. For example, bare metal (no OS) or sensor = level 1 smart cameras or medical devices = level 2

from iot-security-verification-standard-isvs.

@cbassem - Interested in your opinion if you have a moment

from iot-security-verification-standard-isvs.