In my previous article, “How to address the IoT security ticking time bomb,” we examined the expected growth of the IoT devices and components market, which according to Boston Consulting Group is expected to reach $267 billion in sales by 2020. I also highlighted the firmware security vulnerabilities that, if left unaddressed, will significantly impair IoT adoption and growth.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
To recap, most of the firmware built into embedded parts and IoT devices use open source software components. Newer versions of these components are available without the security vulnerabilities. Nevertheless, it ranges from challenging to impossible for OEM development teams and their third-party software suppliers to accurately and effectively track all open source software components in their code, especially when their main focus is to concentrate on developing higher-order systems.
Because the majority of firmware is sourced externally or contains code from third-party vendors that is built using open source code components. Also, third-party code is usually distributed in binary format without the source code. This makes it nearly impossible to initially identify any potential known security vulnerabilities. As more known security vulnerabilities make their way into shipping firmware, the likelihood of litigation initiated by consumers, distributors or OEMs is very likely to flourish.
Given that the vulnerabilities are in the firmware and the code is often procured in binary format, the most efficient and cost-effective manner is to use a binary code scanner. According to Gartner, analysis of the compiled binary code is important if you don’t have the source code of the original application to analyze. Think of it as purchasing known security vulnerability insurance.
There are really four technologies from which developers can choose: static code analyzers and checksum, hash and fingerprint-based binary code scanners. Each provides value depending on the job required.
Why static code analyzers are not optimum for binary code scanning
There are three primary ways to perform static analysis: an examination of the byte code of an interpreted language like Java, an analysis of the source code or an examination of the raw binaries.
There are no pure-play static binary code analyzers. Static code analyzers that purport to examine binary code disassemble it first and then analyze the reconfigured source code for common programming errors. Interestingly, in many countries, including the U.S., disassembly of licensed third-party code is construed as reverse engineering, and therefore a violation of intellectual property laws.
As a best practice, pure-play binary code scanners should be used as the first line of defense because they look for known security vulnerabilities.
Checksum, hash and code fingerprint-based binary code scanners
For some time, checksum and hash-based binary code scanners have been used to find known security vulnerabilities. Despite their reasonable efficacy, they have been constrained by limited databases of precompiled binaries of the most commonly used open source components.
Today, there are binary code scanners that use code fingerprint-based algorithms. They examine “fingerprints” extracted from a binary, which are then compared to fingerprints collected from open source components hosted in numerous open source repositories. Once a component and its version are identified through this fingerprint-based matching, it is straightforward to locate known security vulnerabilities associated with the component from vulnerability databases, such as the National Vulnerability Database (NVD).
Another advantage of fingerprint-based scanners is their robust ability to identify a modified version of an open source software component when compared to checksum scanners. Additionally, unlike checksum or hash-based binary scanners, fingerprint-based scanners don’t need to keep separate databases of checksums or hash values for different CPU architectures. This capability significantly increases their flexibility and accuracy in comparison to legacy binary code scanners.
Fingerprint binary code scanners
OEMs should consider two fingerprint-based binary code scanners as the first and best line of defense against security vulnerabilities. The first is the Binary Analysis Tool (BAT). It has been successfully used for more than six years.
The other is a commercially available software and cloud-based service that uses the technology behind the BAT. With it, developers and users can quickly and easily scan open source software in their embedded applications and IoT devices to identify more than 180,000 known security vulnerabilities, cataloged in numerous databases. These vulnerability databases, which include the NVD and VulnDB, among others, are updated daily. The commercial product also adds enterprise support, “fuzzy matching” of binary code and support for automated build systems like Jenkins.
As a best practice, OEMs should start checking for firmware vulnerabilities with fingerprint-based scanning and then patch the security vulnerabilities before using optional tools. If an organization is faced with financial or time constraints, it should consider fingerprint-based binary code scanning as the bare minimum.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.