Vendor Best Practices

Work in progress

As a producer of IoD devices, your company is responsible for the safety of your products. This should include the safety of your customers data and other information generated through usage of your products.

Failure to fully address the risks to security and privacy can lead to a large number of problems for your customers and through market forces, your companies reputation, sales, and perhaps even it's existence.

Based on experiences with other related "Internet of Things" (IoT) devices and their common security issues, as well as taking into consideration the unique nature of "Internet of Dongs" connected devices, the following is a far from exhaustive list of best practices and recommendations for the design and operation of these devices, their accompanying software and backend systems. It also attemtps to provide a framework for resolving vulnerabilities and problems discovered by outside researchers and internal processes for ensuring problems do not occur in the first place.

Follow IoT minimum standards

IoD overlaps in many ways with IoT, and you can leverage all the learnings and suggestions for that field such as the following:

Secure Software Design

Keeping security and privacy in mind at all stages in the developement process is nessecary to ensure problems are stopped before they start. There are some specific things we recommend that are common problems among IoD vendors.

Always assume the customers internet will go offline, and at some point your servers will have an outage. Your device should have a local manual override, always. Your device should fail when it can't contact your servers or the internet into the safest mode possible (unlock, turn off).
Seek and destroy the OWASP top 10 vulnerabilities for your platforms at a minimum. Be it Mobile, or Web App based
Do not include any API keys, or other such secrets in your software applications, they can be easily discovered
Utilize session tokens for all queries and exchanges. This can help prevent replay attacks and other abuses
Utilize rate limiting or other technical means to limit the users ability to execute queries (login attempts, user search, etc) to a reasonable amount to prevent automated abuse (such as data-scraping).

Encrypt and utilize secure transmission and storage

Encrypt Everything. All traffic between clients and any vendors server should be encrypted with industry accepted methods. This includes all parts of your website, not just the online store
SSL/TLS implementations should not use self signed certificates, only public certificate authority signed certificates (they are not expensive if done right)
SSL/TLS implementations should use strict checking or 'pinning' of the certificates used. Avoid the easy path of just skipping certificate checking
Minimize the requirements in your design for communication with any central servers in favor of direct, encrypted client-to-client. WebRTC, where encryption is mandatory is a good example technology
All of your websites should be accessible, if not default to using SSL/TLS (https). Best efforts should be made to keep these sites at an 'A' rating or better via such tools as SSLlabs.com

Minimimize Data Collection, and be sure to secure what you collect

Do not collect data you do not need, you do not need to protect that which you do not have.
Customer generated metadata and telemetry: This is data generated by the user pheripherally to their use of the device, such as time stamps for usage, pattern selection, etc. Avoid collecting this data in the first place or sending it outside the client.
Customer generated metadata and telemetry #2: If such data is needed between clients, do not send such data through central servers, send it peer to peer. If you must use a central server, do not store this data. If you must store it, do not store it any longer than necessary and be transparent about your collection
Avoid the temptation to collect any behavioral data at all. Given the nature of the data users generate (text, audio, video, usage, etc), it is a far greater risk to collect and store it, rather than not collecting it at all
Avoid usage of personally identifiable information in any account signups required to use the device (Emails, phone numbers, etc). If an identifier is needed, allow the user to pick a pseudo-anonymous username themselves or generate an internal account identifier not based on user data
If emails of other personally identifying information is collected (i.e. emails for contacting the customer), it should be kept separate from operation of the device and not included in any record used for communication between devices or client to server

Vulnerability Disclosure

Bugs and vulnerabilities will happen. Hopefully they will be found before going to production and corrected. However, sometimes external parties (researchers, curious consumers) will find them before you do. When this happens, it is important to have a clear and direct path established for these people to report these issues and to work with them to see the issues resolved. It's a free resource for you and provides more credibility to any claims of caring about security if you are welcome to reports that improve your products security.

Below is an approximate set ot requirements and work flow for a vulnerability disclosure program:

Consider having a Security.txt on your website to make the information easy to find in an expected location.
Have a "security@" email address established that reaches multiple people in positions to act on information recieved (distribution address is fine).
The "security@" email address should be easily located on the website but not be large or prominent (FAQ section is common) but should conatin a link to a larger description of the process and expectations of both sides.
This FAQ entry and larger description can also include descriptions of what systems, vulnerabilities and other restrictions are in scope. You may also specify what is considered out of scope and not "fair game". Keep in mind to err on the side of openness and not be over restrictive. The Pornhub bug bounty at Hackerone is a good example.
This "security@" email should have an automated reply acknowledging reciept of thier email and that a human response will follow within 2-3 working days and may include an outline of the process you follow internally and what you expect of the person submitting the report (i.e. confidentiality until the issue is fixed)
Have a process internally for what happens when a report arrives at the "security@" address. This should involve a high priority, analysis of the report and an attempt to replicate it within the 2-3 working day window
Even if you have not replicated the report yet, a human should respond to the researcher to confirm the report, ask for more time, more information, etc. Keeping the researcher in the loop is vital to the process and appreciating the fact they have chosen to report the issue to you privately
Depending on the severity of the issue, work with the researcher to establish a timeline to get the issue fixed and keep them apprised. You may find other issues while fixing the reported one which may require more time to deploy than just the original report
Once the vulnerability is fixed and distributed to the customers, the researcher is allowed to publicize or otherwise disclose that the vulnerability existed and other technical details as they see fit. The vendor can do the same if they wish
Credit should be given where credit is due, on both sides of the process
If the researcher is working with the IoD project, they will have submitted the report with a candidate DVE (Dong Vulnerability Exposure) number (DCN-<YEAR>-<NUMBER>) for tracking each vulnerability. This is especially useful for keeping communication clear and issues not being forgotten about
If the researcher is working with the IoD project, and the vulnerability is confirmed, A DVE (Dong Vulnerability Exposure) report will be created for them to reference and for others to learn from the types of vulnerabilities the project is finding within IoD devices
If the researcher is working with the IoD, they will hopefully adhere to the IoD researcher code of conduct. If they are are not associated with the IoD project, we cannot provide any assurance about their behavior

Bug Bounty

You can consider adding a bug bounty program to reward those who disclose vulnerabilities. A bug bounty program can be as simple as giving away free swag, recognition, or product to people who report vulnerabilities. The reward does not need to be monetary.