6 ways to reduce your IoT attack surface
The Internet of Things is a massive attack surface that grows bigger every day. These devices are often riddled with basic security problems and high-risk vulnerabilities, and they are becoming a more frequent target of sophisticated hackers, including cyber criminals and nation-states.
Many people have long associated IoT attacks with lower-level threats like distributed denial of service and crypto-mining botnets. But in reality, there are a growing number of ransomware, espionage and data theft attacks that use IoT as the initial access point into the larger IT network, including the cloud. Advanced threat actors are also using IoT devices to achieve persistence inside these networks while evading detection, as was recently seen with the QuietExit backdoor.
In our own analysis of millions of IoT devices deployed in corporate environments, we have found that both high-risk and critical vulnerabilities (based on the Common Vulnerability Scoring System, or CVSS) are widespread. Half of all IoT devices have vulnerabilities with a CVSS score of at least 8, and 20% have critical vulnerabilities with a CVSS score of 9–10. At the same time, these devices also suffer from a number of basic security failures, in terms of password protection and firmware management.
While IoT risks can’t be completely eliminated, they can be reduced. Here are several steps companies should take.
Create a holistic and up-to-date asset inventory
In our research, we have found that 80% of corporate security teams can’t even identify the majority of IoT devices on their network. That is an astounding number, and it shows how serious the problem is. If a company doesn’t even know which devices are on its network, how can it possibly defend them from attack or protect its IT network from lateral movement after a successful IoT breach?
IoT inventorying isn’t easy, though. Traditional IT discovery tools were never designed for IoT. Network behavior anomaly detection systems listen for traffic on span ports, but most of the IoT traffic is encrypted, and even if it isn’t, the information transmitted doesn’t have enough identification details.
It’s not enough to simply know something is an HP printer without any specifics, especially if it has vulnerabilities that need to be fixed. Legacy vulnerability scanners can help, but they operate by sending malformed packets, which aren’t great for IoT identification and can even knock an IoT device offline.
A better approach is to discover IoT devices by interrogating the devices in their native language. This will allow an organization to create an inventory with exhaustive details about the IoT devices, such as device version, model number, firmware version, serial number, running services, certificates and credentials. This allows the organization to actually remediate these risks and not just discover them. It also enables them to remove any devices considered high-risk by the U.S. government, such as Huawei, ZTE, Hikvision, Dahua and Hytera.
Password security is essential
Attacks on IoT devices are easy to carry out because many of these devices still have default passwords. We have found this to be the case in approximately 50% of IoT devices overall, and it is even higher in specific categories of devices.
For example, 95% of audio and video equipment IoT devices have default passwords. Even when devices don’t use default passwords, we’ve found that most of them have only undergone one password change in as much as 10 years.
SEE: Password breach: Why pop culture and passwords don’t mix (free PDF) (TechRepublic)
Ideally, IoT devices should have unique, complex passwords which are rotated every 30, 60 or 90 days. However, not all devices support complex passwords. Some older IoT devices can only handle four-digit PINs, whereas others only allow 10 characters, and some don’t accept special characters.
It’s important to learn all of the details and capabilities of an IoT device, so effective passwords can be used and changes can be made safely. For legacy devices with weak password parameters, or no ability to provide any level of authentication, consider replacing those devices with more modern products that will allow better security practices.
Manage device firmware
Most IoT devices run on outdated firmware, which poses significant security risks since vulnerabilities are so widespread. Firmware vulnerabilities leave devices exposed to attacks including commodity malware, sophisticated implants and backdoors, remote access attacks, data theft, ransomware, espionage, and even physical sabotage. Our research has determined that the average device firmware is six years old and roughly one-quarter of devices (25–30%) are end-of-life and no longer supported by the vendor.
IoT devices should be kept updated with the latest firmware version and security patches provided by the vendors. Admittedly, this can be a challenge, particularly in large organizations where there are literally hundreds of thousands to millions of these devices. But one way or another, it has to be done to keep the network secure. Enterprise IoT security platforms are available that can automate this and other security processes at scale.
However, sometimes device firmware should be downgraded, rather than updated. When a vulnerability is being widely exploited, and there is no available patch—since IoT vendors often take longer to issue patches than traditional IT device manufacturers—then it may be advisable to temporarily downgrade the device to an earlier firmware version that does not contain the vulnerability.
Turn off extraneous connections, and limit network access
IoT devices are often easy to discover and have too many connectivity features enabled by default, such as wired and wireless connections, Bluetooth, other protocols, Secure Shell, and telnet. This promiscuous access makes them an easy target for an external attacker.
It’s important for companies to do system hardening for IoT just as they have with their IT networks. IoT device hardening involves turning off these extraneous ports and unnecessary capabilities. Some examples are running SSH but not telnet, operating with wired ethernet, but not Wi-Fi, and turning off Bluetooth.
Companies should also limit their ability to communicate outside of the network. This can be done at Layer 2 and Layer 3 through network firewalls, unidirectional diodes, access control lists, and virtual local area networks. Limiting internet access for IoT devices will mitigate attacks that depend on the installation of command-and-control malware, such as ransomware and data theft.
Ensure certificates are effective
In our research, we’ve found that IoT digital certificates, which ensure secure authorization, encryption and data integrity, are frequently out of date and poorly managed. This problem even occurs with critical network devices, like wireless access points, which means even the initial access point to the network isn’t properly secured.
It’s very important to validate the state of these certificates and integrate them with a certificate management solution in order to remediate any risks which might occur, such as TLS versions, expiration dates and self-signing.
Watch out for environmental drift
Once IoT devices have been secured and hardened, it’s important to make sure they stay that way. Environmental drift is a common occurrence, as device settings and configurations can change over time due to firmware updates, errors and human interference.
Key device changes to watch out for are passwords that are reset to default or other credential modifications that didn’t come from the PAM, firmware downgrades, and insecure services which have suddenly been turned back on.
Brian Contos, chief security officer of Phosphorus, is a 25-year veteran of the information security industry. He most recently served as vice president of security strategy at Mandiant, following its acquisition of Verodin, where he was the CISO. Brian has held senior leadership roles at other security companies, including chief security strategist at Imperva and CISO at ArcSight. He began his InfoSec career with the Defense Information Systems Agency (DISA) and later Bell Labs.
