IoT Device Security Checklist V2
Device builders, please, stop and think for a moment, before you add Internet connectivity to your device.
Are you fully prepared to secure and carry the cost of securing your device on the Internet for its entire lifetime?
If you are not, you are avoiding the true cost of your device and you are unwittingly contributing to what is becoming a massive IoT security problem.
When you expose a device on the public Internet of Things, you have a responsibility, not only to the owners and users of that device, but to all the other users and devices on the Internet. If your device is hacked and subverted, the impact is far greater than the headache it gives you. And, yes, that headache might be a doozy.
For years, I’ve worked with embedded devices and I have enjoyed watching our embedded web servers be deployed in hundreds of millions of devices, large and small. However, I’ve seen many examples of poor security practices. I have lost count of the number of times I’ve seen devices with blank or trivial default passwords, easily breached back-door accounts, login forms without encryption, pervasive XSS flaws and so on. This is not only a problem with minor manufacturers — I’ve seen this with major manufacturers who ship millions of devices.
So How Can You Create Secure Embedded Devices?
This checklist has some of the more important items to consider when you create a device to put on the public Internet.
This is version 2 of the checklist. It has been re-organized from version 1 and has a number of new important items. If you are building IoT cloud applications, please read our Web Developer Security Checklist to secure the cloud side of your IoT service. This checklist focuses on the device side, but both sides must be secured.
I try to keep this list tight and focused, and so this will never be a complete list.
Categories
- General
- Authentication
- Encryption
- Network
- Web Management Apps
- Updating
- Staff
- Hack Yourself First
- Incident Response
General
[ ] 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, 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.
Please feel free to suggest any important items that I’ve omitted so the checklist can be improved.
Learn More about Embedthis
Embedthis creates embedded web servers for securely hosting embedded web applications. Our web server products are the ideal platform for IoT and make it easy to quickly create secure management applications for web-based device management.
{{comment.name}} said ...
{{comment.message}}