betteriot / betteriot-principles Goto Github PK
View Code? Open in Web Editor NEWBetter IoT Principles
Better IoT Principles
Add a definition section defining the terms device, backend etc. as in http://www.tamberg.org/iotmark/2018/ConnectedProductReferenceModel.pdf
[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
Move #11 to Permissions & Ownership, delete (then empty) Data Governance.
Assessment: Demonstrate training, regular security assessment, security requirements for their suppliers, threat intelligence.
Proposal: The vendor SHOULD allow users to turn off the connection from the device to the backend.
Mention "self-assessed but verifiable" and "verification through documentation", link to https://www.slideshare.net/peterbihr/towards-a-trustmark-for-iot-30-may-2018
[LDN meeting] Proposal for assessment of #5 "API exists with at least information on: endpoints, documentation Information on limits / throttling on API access"
remove.
Patch log for evidence (on-demand or public)
Patches should be regularly applied to any system that is internet facing as a priority, within a reasonable time frame from patch release. Critical patches, where applicable, should be given priority.
Factory reset
Having a permissions section assumes account based systems
"It should be assumed that the data is wiped upon performing a factory reset.
There must be a clear option to revoke access or transfer to another account/user."
(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)
[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.
Description of customer support mechanisms online or on the packaging.
[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#8-the-organisation-may-publish-the-device-source-code-under-an-open-source-license
Inspection: Assumes the central repository of links (so users can find this easily)
purpose :audit device functionality
Clarify the difference between open as in API docs vs. API access with a key or token. (Sometimes people conflate openness with insecurity.)
Assessment: User need to change the password at first run, no unencrypted communication, no unneeded open service.
[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:
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)
"
Clarify or replace the term organisation. Define vendor, user etc.
[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#27-the-organisation-must-offer-the-ability-for-a-user-to-factory-reset-the-device
Duplicate of transferring ownership / no data being stored after ownership is transferred
"Factory reset must remove all links with other services and linked accounts.
Link to 'transfer of ownership' can be made here.
Re-link previously exported data after a factory reset?"
[LDN meeting] Remove https://github.com/openiotmark/iotmark-principles/blob/v20180309/README.md#15-the-organisation-should-offer-users-the-ability-to-export-their-data as it is redundant with GDPR
[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
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
[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:
Link to document with commentary
"Inform users of security issues
Secure OTA updates"
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:
"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,
"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
"
Publish according to the OSHWA guidelines (http://certificate.oshwa.org/)
from
The vendor MUST allow users to stop automated decisions being made, if there are personal legal or significant consequences.
to
The vendor MUST allow users to stop automated decisions of consequence being made about them.
From
to
(to get a positive statement)
[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"
Principle: The organisation is open about the ability of a customer to repair using accessible tools and skills.
Provide a visual overview document of how repairs can be done.
[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:
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.
"
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.
[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"
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:
[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."
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: Ensure pen-test demonstrates the security of the device and its backend (OWASP Top 10, secure backend).
[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:
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.
"
explaining consequences of change of how you use device
Check that online and/or packaging presence of the device includes statements or labelling system that makes clear what the implications of disconnecting device from the networks are.
more research? us law?
more research
Assessment: Define security requirements, strong crypto, provide security support via OTA update (see 5), integrate the security of dependencies (see 5), secure firmware.
"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:
MUST HAVE
Assessment criteria:
" 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)
"
[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.
[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#19-the-organisation-must-inform-the-user-about-firmware-upgrades
There is a way to subscribe to updates
[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
"
Permissions & Ownership => Ownership, as the principles are almost exclusively about ownership.
[LDN meeting] Entire privacy section should be replaced with these flash cards, https://coopdigitalblog.files.wordpress.com/2017/11/co-op_digital_gdpr_rights_posters_a3_print.pdf, as high level principals. The other principals should be deleted. Assessment criteria should be essentially "complies with GDPR"
[LDN meeting] re https://github.com/openiotmark/iotmark-principles/tree/v20180309#10-the-organisation-may-publish-the-backend-source-code-under-an-open-source-license
additionaly: source code for apps/websites used to provide the service. To consider / new idea: in case of termination of service, some way to handover firmware code signing keys or reset keys
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.