Git Product home page Git Product logo

betteriot-principles's People

Contributors

tamberg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

betteriot-principles's Issues

Assessment of principle v20180309#31

[LDN meeting] Assessment for #31: link to shop selling spare parts and/or link to customer support where requests can be made. Published document telling consumers what parts are available OR if no parts are available, that is declared. SUPPLEMENTARY EVIDENCE ifixit repairability score

Assessment of principle v20180309#5

[LDN meeting] Proposal for assessment of #5 "API exists with at least information on: endpoints, documentation Information on limits / throttling on API access"

Privacy principle on profiling should include opt-out

(from a post by emalstm in Slack)

The company SHALL NOT utilise their products to sell customer data to third parties without the knowledge of their customers. Their customer’s data SHALL NOT be used for profiling, marketing or advertising without transparent disclosure.

I would like to change it since this is not GDPR compliant. A better sentence:

Their customer’s data SHALL NOT be used for profiling, marketing or advertising without transparent disclosure and easy opt-out.

(or: Their customer’s data SHALL ONLY be used for profiling, marketing or advertising after transparent disclosure and opt-in)

Assessment for principle 17

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#17-the-organisation-must-be-explicit-as-to-the-expected-duration-of-terms-of-service

This principle could be combined with the one underneath

A "best before" statement?

need to update data governance to define this wording needs to be clear about explaining consequences of any change of use

Check that online and/or packaging presence of the device includes statements or labelling system that makes clear what duration of the terms of service is.

Clarify API docs vs. API access

Clarify the difference between open as in API docs vs. API access with a key or token. (Sometimes people conflate openness with insecurity.)

Assessment of principle 26

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#26-the-organisation-must-have-clear-admin-user-management-policies

"The principle should be about ""the product integrates security by default"" - NICE TO HAVE

Assessment criteria:

  • Security options are active by default.
  • Strong encryption of data at rest and in transit
  • User should change the default password at first run
  • The user is alerted in case of a security alert (nice to have)
  • No hidden account"

Link to document with commentary


"An attempt to stop shared credentials across devices, compromising one device does not compromise all the devices.
best-practices: either device-id specific keys, non-extractable keys, group key management"


"The product will be tested to make sure it is compliant with
Ability and requirement to change Administrator/root access passwords
Device-unique passwords should be loaded into each device at production
Where this is not possible, the admin/root password is to be changed on device first setup or admin first login, whichever happens first
Specific account that hidden backdoor accounts are not to be included on production releases
Limited number of large-scope administration accounts (such as Domain/Enterprise admin accounts)
"

Rethink principle v20180309#32 & 33

[LDN meeting] Principle #32 & #33 needs rework / rethinking, clarity over whether this is for software or hardware or both, and a sense of what good looks like and why this is here - eg manufacturing responsibility, waste and recycling, labour conditions, IOT travel miles, ??? Could do software too eg software BOM proposal from IATC worth consdieration

Assessment should talk about ewaste and BoM; needs work. need to consider issues of regional availability of manufacturing etc.... are there good third party responsible manufacturing standards?

CONSIDER REWORK/REMOVAL

Assessment of principle 7

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#7-the-organisation-should-allow-third-parties-to-communicate-directly-with-its-devices-without-going-through-the-backend

wording unclear (e.g. third parties), must be scure locally as well; third parties/consumers?. If it's beyond consumers it becomes more difficult to implement/apply

Assessment as availability of radio interface information and API

Documentation of radio interfaces and API

Assessment of principle 21

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#21-the-organisations-backend-may-implement-additional-secure-setup-options

"The principle should be more about: "" the organisation implements security in its processes""
Assessment criteria:

  • Awareness and training on security (for the organisation and the staff)
  • Secure development lifecycle (for the product and the staff)
  • Secure business environment (for the organisation)
  • Keep informed on the threats (for the product and the staff)
  • Perform regular security assessment (for the product and the organisation)
  • Ensure third-parties follows security requirements (for the product and the organisation)
  • Issues security communication and remediation (for the product and customers)"

Link to document with commentary


"Inform users of security issues
Secure OTA updates"

The security principles and assessment criteria are too technical

The principles are too technical and too specific. The current criteria might evolve in time (i.e. encryption might be broken) and should not constraint a solution to implement one specific technology.

Suggestion to use 5 security principles and integrate the current ones as assessment criteria:

  1. The organisation should implement security in its processes (must have)
  2. The product follows the principle of security by design (must have)
  3. The product integrates security by default (nice to have)
  4. A risk assessment was performed on the product to ensure it is secure against IoT threats, including: [list of IoT threats] (must have)
  5. The organisation offers security support for the entire lifetime of the product (must have)

Assessment of principle v20180309#28

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#28-the-organisation-must-be-clear-about-the-expected-lifetime-of-the-service-provided-by-the-device-and-backend

"Rewrite to : ""The organisation is clear about the minimum supported lifetime of the service provided by the device and backend""
Currently ""support"" is not defined."

end of life notice/declaration; published plan for end of product life, following a template we could provide. includes what happens when company discontinues supprot or is acquired or goes bust etc. This could include protections such as asset locks, escrow code, isurance policies, etc to protect against organisation going bust or being bought. also should cove rbusiness priorities changing.

public statement of how long the intent to support the service is. ALSO public plan for end of life, based on a template,

Assessment of principle v20180309#12

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#12-the-organisation-should-not-degrade-or-change-the-current-core-functionality-of-the-device-over-the-product-lifetime

"The principle fits better in Lifecycle.
Challenge is to define the granularity of core functionality.
Current assesement criteria are not written taking self assessemnt into account."

"Core functionality is as declared when submitting for IOTMark AND what is included in marketing materials at that time. The test needs to be run over time. the assessment is: compare current functionality with original marketed functionality
"

Reword principle v20180309#12

From

12. The vendor SHOULD NOT degrade or change the core functionality of the connected product over its lifetime.

to

12. The vendor SHOULD preserve the core functionality of the connected product over its lifetime.

(to get a positive statement)

Merging interop principles into a single principle

[LDN meeting] Could the 3 "connect to backend" principles be aggregated into one since the principle here is about being able to connect. Assessment then indicates level of intereop - from complete public private API equivalence to subset of functions being made available to none. Assessment also factors any limits / throttles on API access, and use of API standards (hypercat, IIC...)

"API exists with at least information on: endpoints, documentation
Information on limits / throttling on API access"

Assessment of principle 25

[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.
"

Assessment of principle v20180309#11

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#11-the-organisation-should-make-it-possible-for-customers-to-turn-off-the-connection-to-the-backend-this-might-mean-that-functionality-of-the-device-is-reduced

The organisation makes it possible for customers to understand dependencies on backend services (open/closed) and what functionality of the device/service would change if any connection is removed

"proposed principle text: The organisation makes it possible for customers to understand dependency on backend services and functionality of the device when connection to any service is removed.
Assessment: describe each level of dependency - own services, third party, no backend
category: should this be in life cycle - doesn't feel like data governance "

A link should be provided/published which shows the user documentation (public docs) where these dependencies are explained. FURTHER ADDITIONAL EVIDENCE may be in the form of a youtube video of someone testing a device with adn without backend services connected.

Assessment of principle v20180309#4

[LDN meeting] wording unclear (e.g. third parties), who is th third party? is the distinction between clients (point 5) and devices (point 4) useful here? Should we not have only point 4 saying: The organisation SHOULD allow third parties to connect devices and clients to its backend.

Proposal "API exists with at least information on: endpoints, documentation
Information on limits / throttling on API access"

Outmoded advice on password complexity (18)

Snip: "The company’s sign in process encourages its customers to choose passwords which include alphanumeric characters, special symbols, and are of significant permitted length."

This is an oft repeated, sadly incorrect security concept. Please do not bake this into the IOT Mark Standard. The most important thing for passwords is that they should have the most entropy possible.

References:

Assessment of principle 6

[LDN meeting] Comments & proposal for assessment of #6: "wording unclear (e.g. third parties)
more a ""Best case"" than only ""nice to have"", GIVING AWAY IP!, assesment criteria not clear."

Change "give the ability" to "allow"

For simplicity and uniformity, principles stating something like "The vendor MUST give users the ability to ..." should be shortened to "The vendor MUST allow users to ...".

Assessment of principle 23

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#23-the-organisation-must-enforce-a-strong-user-identity-policy

"Passwords do not represent an ""identity"".
The principle could be removed and replace by ""the product follows the principles of security by design"" - MUST HAVE
Assessment criteria:

  • Remove all unused services, obsolete security functions
  • Ensure the product can perform default functions when not connected to the Internet.
  • Have secure over-the-air updates
  • All passwords must be cryptographically secure (i.e. not based on the MAC address or on a counter).
  • Implement a secure way for users to delete data at the end of life/when selling a product
    "

Link to document with commentary


strong user identity but also usage of pseudonyms enabled


"The organisation’s sign in process encourages its customers to choose passwords which include alphanumeric characters, special symbols, and are of significant permitted length. These passports should be validated server side. Two factor authentication should be included & support for tokenized 2FA e.g. google authenticator.
"

Assessment of principle 20

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#20-the-organisation-must-provide-at-least-minimum-cryptographic-security-on-its-backend--secure-configuration

"The product will be tested to check the following:
Minimal compliance with OWASP Top 10 (2017) and SANS Top 25 which includes:
No SQLi - adequate protections/query parameterisation/filtering present
Good protection against XSS - adequate filtering present
Strong session management
Good authentication management
Random CSRF tokens that are strongly enforced based on last-issued token
Web Server users should not be running as root/admin
Principle of Least Privilege: API service users should have limited access
Managed access to data: Do DB users need to write to a DB they only search in? Do DB users have access to DB’s they shouldn’t do?
"


"This is way too technical.
Suggestion: ""A risk assessment was performed on the product to ensure it is secure against IoT threats, including:

  • Insecure network communications
  • Insecure remote interfaces
  • Web application attacks
  • Unauthorised access to personal data
  • Credentials can be compromised (via CSRF, SQLi)
  • Authentication and access control""

MUST HAVE

Assessment criteria:

  • Ensure a risk assessment is performed regularly
  • Mitigate all issues discovered according to business' risk tolerance and user interest.
  • Ensure products can be updated remotely to fix further issues"

" option 1: something like ""the system should use best practice / state of the art security for the use case and application environment"" supported by a set of exemplars (eg ""for BLE lightbulb, X; for smart home control platform, Y""). ............ or option 2: ""the security architecture/spec will be submitted to the IOTmark expert committee who will rule whether or not it is good enough. the spec and the ruling will be logged so that others can learn from it""
dynamic updated list vs. reference to external ""standard"" specific for security"


"The product will be tested to check the following:
FDE
TLSv1.2 on all web-based endpoints
Secure hashing
E.g. Salted bcrypt/scrypt
Secure PII storage
Only necessary ports are exposed to the internet (e.g. no access to debug ports like SSH/Telnet/etc., hadoop ports not open, SMB ports not open, NoSQL/SQL server ports not open, etc. etc.)
Relevant Cookie flags and security headers (web) present where applicable (see OWASP guidelines)
"

Assessment of principle 13

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#13-the-organisation-must-give-users-the-ability-to-transfer-ownership-of-the-device

There must also be a “master switch” ability to take over ownership if you have the device in your pocession

"Proposal: multi-user support
Proposal: permissions for cloud-data accessibility by third parties
Proposal: ability to disable/enable 3d-party integrations"

for software does this this need to go up a level?

When a factory reset is performed per the vendor’s instructions, the device shall be restored into the brand new state with a phyisical feedback indicator.

Assessment of principle 24

[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#24-the-device-should-use-strong-cryptographic-schemes

[tamberg] Being specific might be OK if there's a clear process to update assessment criteria. E.g. the whole iotmark could be versioned. Link to document with commentary, https://docs.google.com/document/d/1fqfr3wVZHlJf8s4GXMfmTTR0myalSApgsa8vVYVKqwE/edit# [domguinard] should we not carefully select other assessements that should be used for that, e.g., https://www.gsma.com/iot/iot-security-assessment/ or OWASP IoT, etc.


[aallan] If the device is NOT capable of strong cryptographic schemes then the device does not have to implement them. This is explicit as part of the mark. If any part/rules of the mark do not apply, they they don't need to be satisifed. I fthe device is avapable of using them, then it should use them


" The product will be tested to make sure it complies with
Per Device Private Keys
Use known-good cryptographic schemes such as:
AES256-CBC with random IV's
RSA based with key strength of 2048 (ideally 4096) bits
E.g. NaCl for public/private keys
Use demonstrably cryptographically secure TRNG’s/PRNG’s
"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.