IoT Device Security Checklist V2

• [   ]   Do not expose an embedded device on the public Internet by default, unless it is essential to the operation of the device. If is must be on the Internet, consider operating in client-mode — having the device call out to your cloud service and not listening for incoming connections as a server.

• [   ]   A device should be secure by default without requiring the user to to take any actions such as turning off optional services.

Authentication

• [   ]   Ensure all passwords are hashed using appropriate crypto such as bcrypt. Never write your own crypto and correctly initialize crypto with good random data.

• [   ]   Use best practices for user logon and password reset — don’t wing this.

• [   ]   Implement simple but adequate password rules that encourage users to have long, random passwords.

• [   ]   Never use default or blank passwords in factory settings. Always require the user to enter their own unique password.

• [   ]   Never have any undocumented and unpublicized means of access to the device including back-door accounts (like ‘field-service’).

• [   ]   Never use basic or digest HTTP authentication for web apps as these both have critical weaknesses in browser implementations and cannot reliably implement log out functionality.

Encryption

• [   ]   Secure all sensitive data on the device and in flight using strong encryption.

• [   ]   Use TLS to encrypt communications and to authenticate and authorize communications endpoints.

• [   ]   Use TLS for the entire management application, not just for login forms and responses.

Network

• [   ]   Don’t listen on hidden or undocumented ports, or have open listening services that are not essential for the device and not fully disclosed to the user.

• [   ]   Make sure that DOS attacks won’t cripple your device. Limit the number of inbound connections and use rate limiters on slower API paths and authentication related APIs like login and token generation routines.

• [   ]   Prevent the device being subverted in botnets. Have limits on unexpected compute tasks and outbound connections and traffic the device can initiate.

• [   ]   Don’t use universal plug and play unless critical to your device’s success. UPnP is poorly secured and opens new attack vectors.

Web Management Apps

• [   ]   Secure your development systems that build device firmware. Build the software only from secured, isolated development systems.

• [   ]   Ensure that all components of your software are scanned for vulnerabilities for every firmware release. This means O/S, libraries and packages. This should be automated into the CI-CD process.

• [   ]   Do browser-side input validation for quick user feedback, but never trust it. Always validate on the server and encode user input before displaying. Never directly inject user content into responses.

• [   ]   Validate every last bit of user input using white lists. Consider generating validation code from API specifications using a tool like Swagger. It is more reliable than hand-generated code.

• [   ]   Enforce sanity limits on the size and structure of user submitted data and requests.

• [   ]   Don’t emit revealing error details or stack traces to users and don’t deploy your apps to production with DEBUG enabled.

• [   ]   Cookies must be httpOnly and secure and be scoped by path and domain.

• [   ]   Use CSP without allowing unsafe-* backdoors. It is a pain to configure, but worthwhile. Use CSP Subresource Integrity for CDN content.

• [   ]   Use X-Frame-Option and X-XSS-Protection headers in client responses. Use https://observatory.mozilla.org to score your device.

• [   ]   Use HSTS responses to force TLS only access. Redirect all HTTP request to HTTPS in the server as well.

• [   ]   Use CSRF tokens in all forms and use the new SameSite Cookie response header which fixes CSRF once and for all newer browsers.

• [   ]   Remove headers that identify your stack and software versions. No need to make the hackers job easier.

• [   ]   Don’t use GET requests to 3rd party services with sensitive data or tokens in the URL as these may be logged in servers and proxies.

Updating

• [   ]   Have a secure boot process where the firmware is cryptographically signed to ensure the firmware has not been altered.

• [   ]   Ensure a device can be automatically and securely updated and patched for the lifetime of the product. This should not require any user intervention. If the device cannot be automatically updated, have a prominent indicator that an update is necessary and a quick and painless procedure to apply that update.

• [   ]   Maintain staff and infrastructure to prepare and deliver security updates for the lifetime of the device.

• [   ]   A device should make efforts to detect if it has been hacked. A few well chosen embedded canary tests can detect hacks and alert the user or device builder that the device is performing unauthorized activities or is compromised.

Staff

• [   ]   Hire staff and embedded developers that are specifically trained and experienced in all facets of device security.

• [   ]   Train staff (especially senior staff) as to the dangers and techniques used in security social engineering.

• [   ]   Prioritize security and security features into the device from the get-go.

Hack Yourself First

• [   ]   Perform a security audit of the entire design and implementation.

• [   ]   Perform detailed penetration testing and fuzzing on the device.

• [   ]   Perform chaos testing to determine how your service behaves under stress.

Incident Response

• [   ]   Have a threat model that describes what and who you are defending against. It should list and prioritize the possible threats and actors.

• [   ]   Setup a standard email account and web page on your company site that is dedicated for users to report security issues (security@example.com and /security).

• [   ]   Have a practiced security incident plan. One day, you will need it.