Software risks: Securing open source in IoT
There are now 7 billion IoT devices in use across the world. This number is expected to triple by 2025, reaching an unprecedented 21.5 billion devices, says Lev Lesokhin of CAST. The market for Internet of Things (IoT) devices has exploded — now, IoT device makers wanting to cash in on the race to implement IoT are desperate to get their products to market. In the continual breakneck race to sell products, not all software for IoT devices is being made to the highest standard.
To bring new products and features to market quickly, there’s little time to write custom code, especially when pre-designed packages and frameworks can be downloaded for free from open source communities like GitHub and Apache. However, with IoT code as with everything in life, you get back what you put into it. The 2018 Software Intelligence Report from CAST found many open source projects fare poorly on compliance with security rules.
Free open source code does not come with watertight security built in. In the race to market, many companies sacrifice security for speed, foregoing rigorous security checks that consider the structure and inner-workings of such code. Each IoT device, all seven billion of them, must also be run with secure software that’s robust enough to ward off hacker activity.
Open source can be written by anybody. Much of the code in software written for IoT devices is also written by engineers from the embedded software world of standalone devices. This contrasts starkly with the software built to handle the data of large enterprise-wide transactions IoT devices are a part of. Protecting data in this latter context requires a different kind of expertise and skill that far from all developers have.
With the reality that anyone, regardless of development background, can contribute to Open Source Software, it’s much harder to ensure that security and quality standards are upheld. Inefficient, sloppy, or even malicious code can potentially slip in unnoticed.
So many flaws, yet buyers are unlikely to notice. Many see IoT devices through the lens of business – a means to a strategic end such as improved production efficiency. The irony is that while IoT devices are sophisticated enough to be turned against their owners, they are often not considered sophisticated enough to be protected from attack.
The eyes of the world are on your code
Flaws in proprietary, in-house code do occur, but only the developers contracted to write the code may ever know about them. The source code would be private and inaccessible from any prying eyes. However, just as open source is easy for businesses to access, it is just the same for everyone else. Code may have been looked at by many developers and possibly hackers before it is incorporated into the codebase an IoT device depends on.
American retail chain Target found itself the victim to the tune of US$220 million (€194 million) via credit card detail theft all the way back in 2013 when attackers found a weakness in the climate control system the chain used.
Credentials were stolen from the supplier of the climate control system and were unchanged on deployment at Target, leaving every installed system completely vulnerable.
Check yourself before you wreck yourself
While vulnerabilities can never be negated fully, the likelihood can be reduced through three key steps:
The essential first step is a manufacturer understanding what is in the IoT software they ship. Open source, when carefully used, can be very beneficial. However, to protect everyone involved, from the makers to end users, the provenance of the code being put into use should be traced all the way back to its roots and cross-referenced with known vulnerabilities.
Real care and as much time as possible should be taken. Once manufactured, it is unlikely that any problems discovered after the fact will be rectified, as occurred in the case of Target where systems were comparatively easy to access. While producers of IoT devices might be eager to sprint ahead of competitors, they should be aware that any problems can be around for a very long time.
The software needs to be analysed end-to-end, because the code on the device is no longer standalone. Once scanned, companies should immediately go to work. Address any and all highlighted vulnerabilities and reinforce the transactions with low resilience. Working off as much of the code’s technical debt as possible should be the goal, creating a robust system that will stand the test of time and protect its future owners.
Ultimately, remember that the offices of Target’s climate control system vendor ended up being visited by the US Secret Service and the company is still part of an ongoing investigation costing them $18.5 million (€16.3 million). That shouldn’t have to happen to anyone else and it can be avoided.
The author of this blog is Lev Lesokhin, EVP of Strategy & Analytics at CAST.