scriptingxss
commented
2 years ago DnR operations should be out of scope IMO. Widening the scope to include processes and operational procedures that vary based on the organization typically have reliance on compliance program requirements but also internal mandates based on incidents. Perhaps im missing the intention. Feel to clarify :)
root keys cannot be remotely updated.
A best practice is to design with cryptographic agility including a plan that incorporates root key compromise and rotation of those. IoT platforms can provide this capability to remotely update key sets when incidents occur or as part of a rotation policy through OTA. Lorawan docs mention how this might be performed with a key management system and a "secure" Arm MCU reference architecture though im not sure if this has been deployed in practice. See the following: https://lora-alliance.org/wp-content/uploads/2020/11/cypress-escrypt-member-security-whitepaper_web-opt.pdf
Side note: We should add the following Lorawan security FAQ reference: https://resources.lora-alliance.org/faq/lorawan-security-faq
Re: 4.5.8 MAC addresses are generally trustworthy. How reliable are MAC address comparisons as a means to validate legitimacy if they can be changed through software means?
The ISVS currently does not cover security requirements related to detecting and responding to security incidents.
Example requirement that's missing: Verify that an appropriate response strategy is in place in case an end device's root keys are compromised, given that root keys cannot be remotely updated.
Other example of a requirement that exists but could be generalized: | 4.5.8 | Verify that users can obtain an overview of paired devices to validate that they are legitimate (for example, by comparing the MAC addresses of connected devices to the expected ones). | | | ✓ |