::Everyone, excuse the braindump, but I hoped this message in bottle might find its way to Nathan's office, staff, or here may feel inspired to run with these (beyond just the scope of IoT security).::
Disclaimer: I've developed and consumed firmware of multiple categories of products except for military and aerospace.
The easiest system to model is the automotive industry: recalls & TSBs. But don't consume CVEs directly (optional / weak link) because they don't necessarily mean anything.
::Policywonking braindump ahead::
1. Device updates
1.a. Should be enumerable using simple metadata AND
1.b.i. Have a canonical, simple, and fixed URI address website with static content website following accessibility guidelines AND/OR
1.b.ii. Similarly provide updates as static content via HTTP GET requests from a stable, stateless API.
i.b.iii. Unsecured conventional FTP shall be prohibited as an insecure and obsolete technology.
1.c. Device updates shall not be hindered by stateful, conditional access such as logins or CSRF tokens.
1.d. There shall be machine- and user-accessible checksums of all firmware files.
1.e. Optionally, there can be cryptographic signatures of the firmware files themselves (NOT THE CHECKSUM FILES).
1.f. Past updates shall be made available in perpetuity at a fixed URI address.
2. EOL devices: Shouldn't disable themselves. Should be repurpose-able, retaining significant functionality.
3. EOL API services: There should be open sourcing of source or binary installations of server APIs to facilitate repurposing of devices.
3.a. AND a final firmware update to permit changing the URI or DNS address of the API service to facilitate hardware reuse.
4. Paid security updates: It should be expressly forbidden to extort money from users for security updates like Schneider Electric Global (née APC) is now doing to users.
5. Login with (brand): If using first- or third-party credentials to login with a provider, it should use OAuth and SAML.
6. Manual password logon: salted password hashing using PBKDF2, scrypt, bcrypt, or argon2 should be REQUIRED.
7. Default password:
7.a. the default password should either be common OR randomly assigned to each article
7.b AND changed on first use.
8. Remote logon
8.a. If using remote logon, ssh version 2 should be required.
8.b. Telnet should be forbidden as an obsolete and insecure technology.
8.c. Optionally provide a simple manner to disable remote logon, preferably disabled by default.
9. Unique identifier labeling.
9.a. The WiFi/Ethernet MAC address, bluetooth address, or WWN of the device shall be printed on the exterior
9.b. in a manner that is clearly visible with 20/40 eyesight without aid of magnification.
9.c. It SHALL NOT be printed on a removable label.
10. IOT service APIs.
10.a. Should use ordinary technologies, be stable, and function as per documentation.
10.b. Provide a test API with a simulated virtual device.
10.c. Be of minimal cost to use.
10.d. Documentation
10.d.i. Should be published to a static content website that conforms to accessibility guidelines.
11. Telemetry and analytics
11.a. It shall be prohibited without affirmative, opt-in consent to transmit, to any first- or third-party, the following for purposes not strictly necessary for functionality:
11.a.i. Location, position, or geographic region.
11.b.ii. System, bus, network addresses, or identifiers, including but not limited to: Ethernet MAC, WWN, IPv4, IPv6, Bluetooth, Thread, Z-Wave, ZigBee, USB, PCIe, I2C, JTAG.
11.c.iii. Content or metadata of network packets or data EITHER not intended for the device OR not required for interoperability with connected devices. "Connected devices" have a prior, affirmative relationship opted-in by the user explicitly OR are widely-known to automatically configure themselves to associate trust with each other.
11.b.iii. Audio or visual recordings.
11.c.iv. Personal details such as legal name or nickname, postal or physical address, email address, telephone number.
11.c.v. Personal information such as contacts, notes, photographs, videos, audio recordings, browser history, miscellaneous user-generated files, or files known to contain unprotected secrets such as passwords or tokens.
12. Hard reset.
12.a. There should be a simple manner to clear all "data" (personal, state, configuration, and other data) from a device to restore it similar to factory setting.
12.b. The hard reset process MUST EXPLICITLY overwrite all types of data to make it permanently unretrievable.
Disclaimer: I've developed and consumed firmware of multiple categories of products except for military and aerospace.
The easiest system to model is the automotive industry: recalls & TSBs. But don't consume CVEs directly (optional / weak link) because they don't necessarily mean anything.
::Policywonking braindump ahead::
1. Device updates
1.a. Should be enumerable using simple metadata AND
1.b.i. Have a canonical, simple, and fixed URI address website with static content website following accessibility guidelines AND/OR
1.b.ii. Similarly provide updates as static content via HTTP GET requests from a stable, stateless API.
i.b.iii. Unsecured conventional FTP shall be prohibited as an insecure and obsolete technology.
1.c. Device updates shall not be hindered by stateful, conditional access such as logins or CSRF tokens.
1.d. There shall be machine- and user-accessible checksums of all firmware files.
1.e. Optionally, there can be cryptographic signatures of the firmware files themselves (NOT THE CHECKSUM FILES).
1.f. Past updates shall be made available in perpetuity at a fixed URI address.
2. EOL devices: Shouldn't disable themselves. Should be repurpose-able, retaining significant functionality.
3. EOL API services: There should be open sourcing of source or binary installations of server APIs to facilitate repurposing of devices.
3.a. AND a final firmware update to permit changing the URI or DNS address of the API service to facilitate hardware reuse.
4. Paid security updates: It should be expressly forbidden to extort money from users for security updates like Schneider Electric Global (née APC) is now doing to users.
5. Login with (brand): If using first- or third-party credentials to login with a provider, it should use OAuth and SAML.
6. Manual password logon: salted password hashing using PBKDF2, scrypt, bcrypt, or argon2 should be REQUIRED.
7. Default password:
7.a. the default password should either be common OR randomly assigned to each article
7.b AND changed on first use.
8. Remote logon
8.a. If using remote logon, ssh version 2 should be required.
8.b. Telnet should be forbidden as an obsolete and insecure technology.
8.c. Optionally provide a simple manner to disable remote logon, preferably disabled by default.
9. Unique identifier labeling.
9.a. The WiFi/Ethernet MAC address, bluetooth address, or WWN of the device shall be printed on the exterior
9.b. in a manner that is clearly visible with 20/40 eyesight without aid of magnification.
9.c. It SHALL NOT be printed on a removable label.
10. IOT service APIs.
10.a. Should use ordinary technologies, be stable, and function as per documentation.
10.b. Provide a test API with a simulated virtual device.
10.c. Be of minimal cost to use.
10.d. Documentation
10.d.i. Should be published to a static content website that conforms to accessibility guidelines.
11. Telemetry and analytics
11.a. It shall be prohibited without affirmative, opt-in consent to transmit, to any first- or third-party, the following for purposes not strictly necessary for functionality:
11.a.i. Location, position, or geographic region.
11.b.ii. System, bus, network addresses, or identifiers, including but not limited to: Ethernet MAC, WWN, IPv4, IPv6, Bluetooth, Thread, Z-Wave, ZigBee, USB, PCIe, I2C, JTAG.
11.c.iii. Content or metadata of network packets or data EITHER not intended for the device OR not required for interoperability with connected devices. "Connected devices" have a prior, affirmative relationship opted-in by the user explicitly OR are widely-known to automatically configure themselves to associate trust with each other.
11.b.iii. Audio or visual recordings.
11.c.iv. Personal details such as legal name or nickname, postal or physical address, email address, telephone number.
11.c.v. Personal information such as contacts, notes, photographs, videos, audio recordings, browser history, miscellaneous user-generated files, or files known to contain unprotected secrets such as passwords or tokens.
12. Hard reset.
12.a. There should be a simple manner to clear all "data" (personal, state, configuration, and other data) from a device to restore it similar to factory setting.
12.b. The hard reset process MUST EXPLICITLY overwrite all types of data to make it permanently unretrievable.