IoT security is as multilayered as IoT implementations themselves. See the matter from an attacker’s viewpoint and the reason is obvious: if devices are secure but the network is weak, they’ll gain control of the devices via the network. If both are solid but the applications that manage or control them are poorly-protected, that’s their in. It’s a case of one building, several doors. And for attackers, IoT is a huge opportunity: all that computing power, great for productivity, if only we could access it.
In this post, we’ll look at what happens when they get in, how they do it, and how to keep them out.
Understanding IoT security: the risks and challenges
IoT massively increases the attack surface available to bad actors, because it increases the number of connected devices vastly, and many of those devices are not hardened even to the same degree as standard desktop PCs and mobile devices. Consumer IoT devices are notoriously insecure, but we’re more concerned here with business and Industrial IoT devices, networks and applications.
What happens when IoT implementations get hacked?
In 2016, Twitter suffered an outage that left users in the US, primarily in coastal regions, without access for most of a day. Box, Boston Globe, New York Times, Github, Airbnb, Reddit, Freshbooks, Heroku and Vox Media properties, Spotify, Shopify, and other sites were affected too, because the attack targeted the DNS provider Dyn.
Dyn told TechCrunch at the time that ‘the DDoS traffic has been coming from tens of millions of discrete IP addresses around the globe.’ Security researcher Bruce Schneier blogged in September the same year that: ‘These attacks are significantly larger than the ones they’re used to seeing. They last longer. They’re more sophisticated. And they look like probing. One week, the attack would start at a particular level of attack and slowly ramp up before stopping. The next week, it would start at that higher point and continue. And so on, along those lines, as if the attacker were looking for the exact point of failure… Someone is extensively testing the core defensive capabilities of the companies that provide critical Internet services.’
The unprecedented sophistication of these attacks was directly traceable to the relative ease with which attackers could penetrate and take over IoT networks. There are now more than twice as many IoT devices as in 2016, but the security picture has changed too little.
In 2021, the most active botnet is Mozi, a variant of the Mirai botnet. Mozi mostly targets Japan and the United States, relying on IoT devices.
IoT device vulnerabilities
Many IoT devices are shipped with security backdoors designed to let support personnel gain easy access. Others use standard logins across the device range; every device in a company’s building portfolio may share the login username and password ‘admin/admin’ or ‘admin’password.’ These insecurities are being built out of consumer goods; your first home router probably had admin/admin as the login, but your current one almost certainly doesn’t. However, IoT devices are often not built with security in mind. The problem is widespread: in 2020, ZDNET published details of a 515,000-device botnet for sale on the web, created from devices shipped with weak password protection and using weak, easily-guessable custom passwords.
In some cases, these devices are secure when shipped. The problem arises when they’re not updated. Every system has vulnerabilities; over time these are discovered and patched. When they’re not patched, the device loses the arms race with bad actors. This was how the Satori worm spread, by targeting specific, known vulnerabilities.
Device vulnerabilities should be combated by including devices with flexible, secure default settings — including password complexity, expiration and one-time passwords that force users to modify default credentials on setup. Two-factor, multi-factor and biometric authentication, and digital certificates using public key infrastructures can protect devices and networks. Where appropriate, this data should form part of a device visibility plan that is audited regularly and stored securely in encrypted form.
Network vulnerabilities
The problem goes beyond devices. Many IoT networks are also insecure, consisting of large, flat networks built for lateral communication between endpoints. This is actually a good thing in some ways, but it’s also a security nightmare: if one device’s systems are compromised, the attacker can quickly gain control of all devices across the network, moving laterally across endpoints and never encountering a secure device at all.
Many IoT implementations have low resources, and therefore use unencrypted traffic to save bandwidth. This makes them vulnerable to spyware that can simply intercept this traffic and harvest login data from it or alter it in transit.
Networks for IoT implementations are often built to a budget and a timetable by architects for whom security is not top of mind or who may lack the skills to build secure networks; they may also have trouble convincing the C suite that security should be a priority.
Networks are frequently compromised by poor device management. A 2020 study focusing on the medical sector found a wide range of vulnerabilities. Up to 15% of devices on surveyed networks were unknown or unauthorized, including one hospital with ‘Facebook and YouTube applications running on MRI and CT machines,’ and another where a nearby Tesla car was connected to the network. Between 5% and 19% were using unsupported legacy operating systems, and 51% of teams did not know what types of smart devices were connected to their networks. Of the 49% that did have some idea, some were guessing; others were tinkering with their existing IT systems to get visibility. About 75% of deployments had VLAN (Virtual Local Area Network) violations.
Device visibility
The first priority should be to create and maintain a database of each connected device, ideally with a dedicated IoT security solution to ensure that they are identified by basic hardware information such as manufacturer and model ID, and serial numbers, hardware, software and firmware versions, and OS and configuration data. This information becomes hugely valuable if there is a problem with data exposure or hostile action, because it allows you to identify vulnerable devices in advance by comparison with those already compromised. Before that happens, you can use this data for segmentation and firewall development.
Network segmentation
Network segmentation divides a network into subsections, giving granular control over traffic between endpoints and reducing attack surface. Think of it like fire doors. In a large building with no fire doors, a burning drape in one room can destroy the whole building. The fire spreads unimpeded, room to room and floor to floor. With fire doors, damage is still done, but it’s confined and slowed. In a network with network-wide endpoint connectivity, a successful attack on one endpoint — one single device — can contaminate the whole network. In a segmented network the damage can be confined to the affected section. Enterprises should use VLAN and next-generation firewall policies to implement network segmentation.
VLANs are subnetworks that let network admins partition their networks without requiring new hardware or major changes in current network infrastructure. They can be used to accelerate network performance by grouping the devices that communicate with each other the most, but they’re also a crucial component of modern network management.
Application vulnerabilities
Finally, applications and control devices can be insecure too. If a mobile device is used to manage an IoT implementation, and that device is hacked, the attacker is now behind the majority of network- and device-level protections.
Similarly, if an application can be breached — say, by a front-end injection at the level of a web application that harvests legitimate login data — the attacker can gain access to the network via its controlling application. All web applications are potentially susceptible to injection attacks, in which code is injected into the front-end of the website adding requests that compromise the user’s data security or the application. SQL and XML are common forms of injection attack.
Applications can also be breached via some third-party software libraries which contain known vulnerabilities or have been hacked before. If these libraries are used to build IoT software or if they are later added during updates, they can compromise the system.
IoT applications should be built using the latest security standards and protocols, ideally following the suggestions from the National Institute of Standards and Technology as well as the December 2020 US IoT Cybersecurity Improvement Act. However, these are baselines; security in the application layer should be designed to meet the needs of the business.
Application security needs to be both prioritized equally with device and network security, and integrated with them. Security is global.
Cloud vulnerabilities
All the vulnerabilities discussed thus far apply to cloud implementations, but there are cloud-specific issues too. Secure network protocols, including message-passing, point-to-point encryption, and security certificates, are critical for overall cloud security. And whether it’s AWS, Azure, or GCP, each device needs to have access to the cloud environment to be secure. Cloud providers grant certificates and private keys to their users, generating them for each device individually.
Microsoft offers the Azure Secure Score, letting you assess the security state of your IoT implementation — even if it’s hosted by other cloud providers. The Azure Defender tool helps protect hybrid clouds. There’s even an IoT-specific offering in Azure IoT.
Amazon gives its users a Security Hub, showing a comprehensive view of security alerts and posture across AWS accounts and regular automated security checks. Integrated dashboards bring together your security status across accounts and give at-a-glance visibility. AWS also has IoT-specific offerings.
Google’s equivalent of these offerings is Cloud Security Command Center. Like AWS and Microsoft’s offerings, it’s a central hub for cloud security, giving users centralized visibility and control. Command Center also flags security and compliance issues and automatically offers solutions, as well as providing a suite of threat protection and detection tools.
Where a business doesn’t use these ‘out-of-the-box’ solutions, they need to replace them with a custom security system that offers equivalent protections, and it’s here that many IoT implementations fall down.
In particular, how can organizations recreate the same security measures and features in private cloud or across multi-cloud environments? Even if they use a public cloud provider, that provider typically won’t take responsibility for organizational structure, such as Identity and Access Management (IAM) processes, infrastructure configuration choices like network setup, firewalls, load balancers, and application security.
In cloud environments, there are often multiple stakeholders with differing responsibilities, and these should be identified. They’re likely to include the provider, who typically ensures the security and reliability of infrastructure housed within its platform; the CIO or CISO, who manages the information and data security of the entire organization; the Security Operations Center (SOC), a central organizational unit responsible for IT infrastructure organization-wide; DevOps, who are responsible for secure implementation, deployment and operations; and cloud foundations, dedicated teams in some organizations that exist to move the whole organization’s IT environments toward cloud-native technologies.
Organizations should ascertain where responsibilities lie so that they can take ownership of what’s under their control — and establish what to look for in partners. When searching for software providers, for instance, companies should look for partners that are SOC 2-compliant.
Social engineering
Social engineering is perhaps the most effective, common, and pervasive attack vectors in digital security. Persuading people to click on unknown links in emails is trivially easy, even when they have been warned regularly. Data harvested from social networks, device and location data can all be used to build the tools needed to imitate an individual, guess their credentials, and gain access to networks via their accounts.
Botnets and DDoS attacks
IoT networks are large, connected groups of Turing-complete computers — meaning they’re able to do anything any other computer can do, given enough time. Even though each device is hardly a formidable computational resource by itself, in very large numbers they’re ideal for doing big, repetitive tasks. That’s usually what they’re built for, but attackers can take them over and use them to do things like mine cryptocurrencies, carry out hacking and other malicious activities directed at other networks and devices, and do DDoS (Distributed Denial of Service attacks).
Takeaways:
- IoT security threats are global, using attacks at one layer to affect, take over or damage the whole system; solutions similarly must be global.
- Many of the most common problems faced by IoT implementations can be prevented by adopting best practices from the outset. This means addressing security issues at the device, platform, network and application levels.
- IoT security for organizations takes two forms: controlling the aspects your organization controls directly, and selecting appropriate partners.
Image Credits: Featured Image Source, Dark Clouds, Hacker
