Post Production / on the field controls? about iot-security-verification-standard-isvs HOT 6 CLOSED

Hi @kanetil,

We wanted to make sure requirements are actionable, measurable, and testable. Process and operational oriented requirements were left out of scope.

Vulnerability tracking related requirements in 1.1.6 1.1.7 1.2.1 3.2.4. Perhaps we could clarify one of them further?

Logging related requirements in 2.2.5 3.1.6 3.2.6 They're focused around information disclosure and verbosity.

from iot-security-verification-standard-isvs.

Understood, so to clarify, my issue is about having the proper capabilities to monitor the device remotely, and not stored on the device alone without capabilities to research an incident in progress on a remote device.

Example:
"Verify any collected logs are retrievable over an online connection either periodically or on-demand."

an IoT SIEM is of importance, especially for non-consumer IoT devices, and it needs a way to get its logs

from iot-security-verification-standard-isvs.

Good point from the incident perspective. Devices need to retain logs locally and remotely for longer periods of time. The implementation might be tricky because the required architecture is more involved with authentication, authorization, and/or a PKI to encrypt logs over the wire using the RoT certificate (potentially). Each of these could introduce additional entry points if not properly designed although thats complicating things a bit. :)

How about something like the following

Verify that collected logs are securely retrievable over an online connection either periodically or on-demand.

from iot-security-verification-standard-isvs.

Looks good.

Now we need to define the logs as tamper-proof to some degree, but that's a different requirement probably

How about:
verify that tamper prevention controls are embedded in the security logging mechanism

from iot-security-verification-standard-isvs.

We are working to understand if there are other IoT specific monitoring capabilities we should consider outside of retrieving over an online connection.
Tamper protections on devices may not be prevalent for the time being but there is an argument to be made from the ecosystem perspective although that is more server side.

from iot-security-verification-standard-isvs.

There are multi-device logic you can embed on the backend system (sink-hole detection, detection of version downgrade etc) - do we want to go into that rabbit-hole? a whole world of threat hunting awaits

from iot-security-verification-standard-isvs.