Best Practices for Developing Secure IoT Devices
Connected (IoT) devices are exposed to the local network and the web, making them susceptible to attacks by malicious actors. Attackers often need to compromise many devices in order to perpetrate their attacks. This is certainly true of crypto mining, as well as DDoS attacks which rely on sending queries from hundreds of thousands of devices simultaneously.
To gain access, the simplest way is usually for the attacker to target the weakest points in many connected devices, such as default passwords, known vulnerabilities, insecure and outdated libraries and applications, exploitable bugs, and other relatively basic security vulnerabilities.
Regardless of whether hackers want to run large coordinated attacks or attempt individual breaches, securing each device is of paramount importance. The latest in our practical guide series presents development and deployment recommendations meant to enhance baseline security for connected products. While following and implementing these best practices requires relatively little effort, they can significantly improve the security profile of your devices.
Below is a quick glimpse at the eight best practices outlined in the guide. Download the ebook for detailed implementation recommendations on each of these best practices.
1. Choose a well-supported base distribution
Connected device security is best served by using versions of Linux from a security-oriented base distribution. Only organizations that have extensive resources should consider building a custom Linux distribution since it will allow them to work with an optimized bill of materials. For smaller organizations, customization is not recommended from a security perspective.
2. Implement a Remote Update Mechanism
Choosing a well-maintained base distribution is a great starting point. Over time, as new bugs and security vulnerabilities are found and fixed and the overall quality of the base product improves, it becomes important to keep your devices up to date. Implementing a remote update mechanism enables the base distribution and your device application to receive security patches without explicit user or operator intervention.
3. Use analysis tools to find security hardening recommendations
Running static analysis on your source code is an essential step toward hardening your software. A variety of excellent solutions are available making it possible to achieve good baseline security. Security hardening can often be done by simply modifying configuration options either automatically or by following published guidelines.
4. Use static analysis to eliminate trivial bugs
Trivial bugs, such as not closing file handles or unintended fall through in switch cases can be used to crash your device or gain unauthorized access. But a complete test coverage of the codebase is extremely time consuming, and in most cases, impossible to achieve. Fortunately, there are multiple static analyzers that can detect and prevent a wide range of these types of bugs.
5. Use dynamic analysis to find memory bugs
Most security breaches used to be tied to memory handling errors - stack and heap overflows, page faults, and so on. Well-known examples are the Slammer and Blaster worms which affected hundreds of thousands of machines. There are several free dynamic memory analysis tools that are good at monitoring and capturing anomalous behavior during runtime in order to eliminate memory handling bugs.
6. Remove frame pointers and enable compiler optimizations
Frame Pointers are used as references to the location of variables in the stack. They are required on some architectures during debug to allow locating functions and their arguments in memory. Compiler Optimization results in leaner code that is much further from the original source than regular, unoptimized binaries.
7. Use compiler security flags
Many security vulnerabilities are caused by errors that are common and relatively easy to find, but finding all potential bugs is a difficult and potentially infinite task. On many platforms, the compiler and target architecture supports security features that can detect and prevent these issues by compiling the software with the hardening features enabled.
8. Strip binaries, compile in release mode
Debug symbols are extremely useful in the development phase when debugging, or after deployment when a problem arises in the field and better insight is needed in order to understand the problem. For the same exact reason, debug symbols are also useful to hackers trying to reverse engineer your device when attempting to attack it.
The Bottom-line: Security is Transient
Most existing connected (IoT) products have low to very-low security standards, with the security profile of the market in general as bad as it was 30 years ago on the desktop. Most high-quality device manufacturers and vendors will eventually catch up to the best practices and the base security state of the market will improve. The threat landscape will continue to evolve and adapt as new classes of vulnerabilities are found and utilized. Then the bar for baseline security will rise accordingly, and the cycle is bound to repeat indefinitely.
Keeping connected devices secure from development through deployment and beyond is a serious commitment which requires continuous effort. Only by following at least the basic best practices will prevent your device from being among the lowest common denominator – an obvious target for most attackers as one of the weakest links.
Read the ebook to find detailed implementation recommendations for each best practice.
Share this post