xIoT Why are we treating firmware like it is not software?

In a recent post we identified the problem of “zero-awareness” – businesses often don’t know what XIoT devices are attached to their network and what risks and vulnerabilities those devices have. Why this problem exists is a conundrum, both easy to explain and impossible to explain.

The easy explanation is that XIoT devices typically run firmware and our traditional security tools deal with software, not firmware. The conundrum is that firmware is software, so why do we pretend it’s not? Why can’t our security tools, policies, and procedures treat XIoT device firmware just like it does desktop and server software?

Let’s dig into some of the facets of security policies in the context of firmware-based XIoT devices and whether these policies apply to XIoT devices.

Inventories

Many organizations don’t inventory their XIoT devices, let alone do software and/or configuration audits. The same techniques used to inventory desktops, servers, and application software can be applied to XIoT devices. The caveat is that inventory software may not recognize or be able to categorize many XIoT devices. The process of interrogating firmware does pose different challenges than traditional software and a lot of legacy inventory software isn’t built for this. Paradoxically, this increases the importance of good XIoT device inventories, else rogue devices are free to unleash carnage.

Audits

Similar to inventories, the existing security methodologies for auditing things like age, versions, and configurations do apply. The problem is again that many legacy tools do not know how to interrogate firmware. It should be said not all firmware images are the same. For example, Ubiquiti router firmware is typically embedded Linux, so standard Linux interrogation techniques work. However, many other images are built on Real Time Operating Systems (RTOSes) such as FreeRTOS or ThreadX and new interrogation techniques are needed.

Updates and Upgrades

It is critical to control the update process for XIoT devices. While some people shy away from firmware updates because there may be a risk of “bricking” a device as Airbnb users found out the hard way. That risk only serves to emphasize why you need to have control of your updates and upgrades.

Support Accounts with Device Manufacturers

Many vendors require logins to access firmware revisions, so you’ll need to create and maintain accounts with all your vendors. A recent survey we conducted here at NetRise revealed that 75% of businesses don’t have support accounts with more than half of their device manufacturers! And guess what -- if you don’t have a support account, it’s likely that the devices from that vendor have NEVER been updated.

Migrations and End of Life

While many XIoT devices may seem to be fungible commodities, the attack surfaces of similar devices may be completely different. Controlling the entry of new devices into your environment is a critical part of minimizing your attack surface. It is also important to pay close attention to your device manufacturer’s end of life plans and policies. It’s not uncommon for devices to get orphaned as new hardware revisions are released. So, even if a device is not officially marked as end of life by the maker, the firmware upgrades may be sparse and vulnerabilities may not get patched.

Pen Testing

A common misconception is that because xIoT devices have tiny processors, even if they are hacked there isn’t much an attacker can do with them. Besides the obvious flaw in that argument for something like an implantable cardiac device, the cardinality of xIoT devices makes them a great platform for DDoS attacks, as the Mirai botnet clearly shows. Additionally, threat actors can often easily pivot from an initially compromised XIoT device to more traditional workstations and servers. While many of the same tools that are used for pen testing traditional systems can be used against XIoT devices, the sheer number of devices is the real problem; Pen testing has historically consisted of manual consulting engagements, which simply doesn't scale with the number of devices in the XIoT.

How do we proceed?

The reasons why firmware are largely ignored in security circles are not 100% clear, but it is likely that unfamiliarity is a leading factor. As we've discussed here, though, many of the security methodologies you are already using can be applied to fix the “zero-awareness” problem with XIoT devices. Addressing the associated risks and vulnerabilities, then, consists of some pretty simple steps to follow which can lead to huge improvements in an organization's overall security posture:

1. Adjust attitudes and accept responsibility for XIoT devices as part of the overall security program for your company
2. Determine the subset of existing policies that can be applied to existing XIoT devices and apply them!
3. Adjust other policies and procedures to bring the remaining set of XIoT devices into the security program.

Implementing a comprehensive security program that encompasses these principles is at the heart of NetRise.  Unlike other products that largely ignore XIoT devices, our platform is built from the ground up with the conviction that XIoT devices must not only be included in security programs, but also treated with the same level of diligence as server and desktop equipment. Instead of emphasizing the differences with XIoT devices and exacerbating existing budget problems with requirements for security staff with specialized skills, NetRise bridges the gap and brings XIoT devices into the security program providing both visibility and control of XIoT security. 

If you'd like to learn more about the NetRise XIoT platform or discuss your security considerations with one of our experts, help is just a click or call away!