Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assessment of principle 25 #40

Closed
tamberg opened this issue Jun 19, 2018 · 1 comment
Closed

Assessment of principle 25 #40

tamberg opened this issue Jun 19, 2018 · 1 comment

Comments

@tamberg
Copy link
Contributor

tamberg commented Jun 19, 2018

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#25-the-device-firmware-must-be-compliant-with-industry-security-standards

"Suggestion to change the principle to ""The organisation offers security support for the entire lifetime of the product"" - NICE TO HAVE

Assessment criteria:

  • Implement a vulnerability disclosure programme (this could be a bug bounty)
  • Inform users of vulnerabilities in the product, its dependencies
  • Provide security updates in due time (i.e. not 6 months later)
  • Ensure the backend remains secure throughout the lifetime of the product
  • Have a security@ email address"

Are there specific industry standards to mention?


"A product will be tested to see if its firmware is compliant with
Usage of latest available SDK’s
Monitor and patch with updates for core backend libraries (e.g. wifi libraries, web servers, XML parsers, etc. etc.), not just SDK updates.
A known-good failsafe firmware should be available
Fair use of Hardware Security Module
Use of on-chip cryptographic accelerators where available
Use of secure storage options where available
Usage of CRP where available
Secure Setup
Only necessary ports open/available
All services that handle sensitive data have adequate authentication
No debug ports are available (ssh/telnet/etc.)
No unnecessary services (e.g. FTP, TFTP, SMB, etc.)
Documented moves to detect and block basic brute force attacks (e.g. password bruteforcing, WPS Pixie Dust, service bruteforcing, etc.)
Remove Debug/Development headers from PCB (JTAG/UART/etc.)
The organisation’s product must be compliant with the IoTSF Security Compliance Framework
Assessment criteria: Relevant compliance class number is published on packaging and online presence of the organisation.
The organisation must take every precaution to protect usersits customers from the product being exposed to local / adjacent subnet attacks or any other attack.
"

@tamberg
Copy link
Contributor Author

tamberg commented Jun 21, 2018

Replaced all security principles with a higher level version, see #3:
https://github.com/openiotmark/iotmark-principles/tree/develop#security

@tamberg tamberg closed this as completed Jun 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant