Suggestions to improve consistency - Update "Using ISVS" Figure

[cetome]

There are several areas which I believe could be more consistent:

1. Wi-Fi and Bluetooth These are very specific protocols. What if the device uses LoRaWAN or Zigbee? It could be more beneficial to separate LAN and WAN communications as the threat model is different.

2. Figure used in https://github.com/OWASP/IoT-Security-Verification-Standard-ISVS/blob/master/en/Using_ISVS.md#the-isvs-security-model The blocks used in the figure are confusing: they mix components and features (e.g. Wi-Fi or software updates) with processes (e.g. design, secure development). I would suggest to:

• Regroup all processes in one box.
• Simplify the device "design" with components and features in boxes representing a physical device. For example: "internal hardware", "external hardware", "software".

[scriptingxss]

TL;DR - We would love to include ZigBee and Z-Wave but do not have the practical experience on the project team. We need help 😄

1. We chose WiFi and BT since they are more commonly used generally speaking. We do want to expand out to a couple more common wireless protocols if folks would like to contribute their practical expertise in these areas. In fact, we do have an open ZigBee PR (https://github.com/OWASP/IoT-Security-Verification-Standard-ISVS/pull/77) but need help from experts to vet requirements. Sure we can pull industry best practices for IoT protocols but we'd rather include requirements that contributors have implemented in real devices to ensure they provide value and are attainable given common constraints. Without practical experience, it's challenging to accurately level requirements .
2. The figure is showing the building blocks of IoT starting from hardware design (chapter 5) at the bottom which is usually the first step when kicking off a new product introduction within a lifecycle by way of a requirements document (PRD). After hardware requirements are in the HW PRD, software feature PRDs are produced which is where design processes from Chapter 1 comes into play and Chapters 2 through 4 help drive security requirements. It does sound a bit backwards albeit. I can see how the communication block could be confusing although technically communication libraries or drivers for protocols are part of the software platform which vendors may be supplying together with the processor already (e.g. Qualcomm based SoC with WiFi and BT included in one chip). I think we could explore different means to illustrate alignment of chapters and the way they are designed a bit better. Perhaps looping in a graphics professional would be another option. :)

[cbassem]

Concerning 1. The general section covers a base set of communication requirements. The other sections are concrete recommendations for protocols that we've already come in contact with. I've created a issues to make the request for other protocols more explicit #81 (added some labels to attract attention :) ). Feel free to add issues for other protocols as well.

Concerning 2. I feel there is synergy here with the vocabulary concern raised in #54. We could adapt the figure to reflect the changes we make here as well.

[windBlaze]

Hi all, I'm definitely not a graphics professional but I took a shot at improving the figure :) Kept the previous concept, just :

• added a distinction between processes & features / mechanisms as suggested by @cetome
• updated chapters to be in-line with current structure
• grouped all wireless protocols under a "Communications Protocols" box.

Let me know if this is in-line with what you expect, and I'll submit it in a pull request .