IoT will only ever be as secure as its application code
The Internet of Things offers a beautiful, interconnected vision of the future. However, secure code has to underpin all things IoT because just one chink in the armor leaves us all vulnerable.
The pace at which the Internet of Things (IoT) is entering our homes and workplaces is phenomenal. This proliferation brings lots of potential benefits to users but it also presents numerous security risks. There is currently no common IoT platform; instead there are various tech giants competing to own the IoT platform of choice with securing that platform seeming to be a lesser consideration. The Open Web Application Security Project (OWASP)’s top ten IoT list of vulnerabilities gives recommendations on how to develop IoT applications that will help fight off hacking attempts. In the IoT space, releases are generally quick and often so OWASPs top ten is certainly helpful but they can only have a positive affect if the underlying application code itself is secure.
The pros and cons
There is no doubting the benefits of IoT. For consumers, British Gas’ Hive already allows you to control your home heating from wherever you happen to be while London City Airport is using IoT to keep things moving and thus make the customer’s journey easier. Unfortunately, the benefits come at a price. The hacking of IoT devices has become mainstream news. Cars can be hacked causing accidents or even hacked in order to access sensitive information on mobile devices connected to your car’s WiFi network. IoT devices give hackers another avenue to hack into which also happens to be one that is perhaps not as secure as it could be. Regardless of how secure some of your devices might be, it only takes one chink in the armor and the hacker is in.
The case of the Smart TV
The Smart TV is probably the most prevalent of connected devices in people’s homes today. They are effectively mini-computers with WiFi access and applications that require the user to input information such as email IDs, phone numbers, full names etc. Unfortunately, unlike the smart phone app-stores like Google Play and the App Store, there are no regulations when it comes to Smart TV apps which means that security protocols are often absent. In fact, manufactures often give developers the software development kits (SDKs) with no real security policy, thus allowing hackers easy access to innards including the file I/O and the screen/app control API.
In other words, Smart TV apps are running with complete “root” access. Taking the case of the Smart TV specifically, a flaw in the application layer can provide a hacker entry to a Smart TV which can lead to identity theft and harvesting of sensitive account information. Hackers can record private footage through the built-in camera and microphone or work out passwords through key-logging and / or capturing sensitive screenshots. And a hacked TV can also be used for commercial espionage through monitoring usage behavior and patterns.
But of course, it doesn’t stop there, defense forces are increasingly going online and we’ve all seen the various TV shows and movies where the hackers get control of a weaponized drone. The security risks associated with IoT are very real and it seems that tech giants are ploughing ahead with their IoT platforms like Google’s Brillo, Apple’s HomeKit, Intel’s IoTivity, Qualcomm’s AllJoyn and most recently, Samsung’s Artik Cloud Platform. We know that manufacturers within Apple’s HomeKit ecosystem have to use certified chipsets and specialized firmware developed with security in mind but the reality is that with no actual regulation or industry standards to speak of, many smart devices end up not password protected with data being transferred from the devices without adequate encryption.
Recommendations from OWASP for end users and developers
There are a number of things end users can do to help the fight against hackers such as changing default passwords (1111, 1234 etc), use strong or complex passwords and change them regularly, and try to avoid open public hotspots in favor of secure local WiFi networks. But of course, it shouldn’t be left only to end users to protect themselves, center security protocols should be built in to these applications; here are four security measures OWASP says all IoT application developers must use:
- Prevent brute forcing – Malicious attackers use a wide variety of automated methods to guess passwords in order to hack into systems. Blocking access after a certain number of login attempts will help to prevent this.
- Disable use of default password – To avoid the easily hackable default passwords, IoT hardware should be programmed to enforce a “default password change” during the initial setup process. The new password should have to be “strong” and replaced regularly.
- Store credentials securely – All private data should be encrypted, stored in a secure manner and not be exposed over the network. Cloud systems require strong transports encryption.
- Secure updating mechanisms – IoT devices need to be updated constantly (new features, security patches, etc). The software should be able to process update files in an encrypted manner, after they are validated before implementation using signed files.
Real IoT security begins with secure code
While the above are good rules to live by, if the application has bad code integrity, there is a limit to how helpful these measures can actually be. And with Gartner claiming that we will see over 25 billion connected things by 2020, the issues around securing these things cannot be ignored any longer. To avoid vulnerabilities such as SQL injections, Cross-Site Scripting (XSS) and more, those in the business of IoT should consider secure application code underpins any and all IoT platforms or devices.
The most effective way to avoid these vulnerabilities is to develop applications in a secure Software Development Life Cycle (sSDLC). In many instances, code is written, passed to another team and then checked for security vulnerabilities very close to release times. Checking this late in the process means that it takes longer for the coders to re-code in order to fix any bugs or vulnerabilities as they are not as familiar with the code then as they would have been when they were first writing it. It also puts pressure on the business to release a new version that isn’t fully patched due to time constraints.
The cost of delay is sometimes too high and vendors prefer to “Take the risk” Security implemented in the form of Static Code Analysis (SCA), a SAST methodology allows the automating of the security process and enables early elimination of application-layer vulnerabilities. This saves developer’s time, which incidentally is what they are normally measured on, and helps protect the business from hackers.
At the moment, the hacker story lines portrayed in many TV shows and movies are not as fictional as you might think. Whether by hackers themselves to portray their own security concerns around IoT or through malicious hacks, we’ve already seen cars, fitbits, baby monitors, Samsung’s smart fridge for its access to Google Calendar and even WiFi enabled Hello Barbie. And of course, hacking students at the University of Alabama managed to hack the pacemaker in a robot used for medical training students enabling them to theoretically kill that “patient”. With former Vice President Dick Cheney having a pacemaker, that episode of Homeland suddenly seems a lot less far-fetched. This is now our reality but if applications are developed securely with high code integrity, smart devices will become safer. The IoT revolution is nothing to be feared if vulnerabilities are eliminated at the root – the application code.