Battlestar solution
Guest
on 28 March 2017
Tags: Security , Ubuntu Core , white paper
This is a guest post by Peter Kirwan, technology journalist. If you would like to contribute a post, please contact ubuntu-devices@canonical.com
Forecasts suggest that by 2020, 20bn to 30bn IoT devices will be connected to networks worldwide. Almost certainly, the tactics employed by Colonel Saul Tigh in this clip from episode 201 of Battlestar Galactica will not successfully secure these devices against exploitation in DDoS attacks.
And yet, the notion of mass disconnection seems attractive to some.
In the wake of two huge Mirai-mediated DDoS attacks last year, Mark Warner, a US Senator for Virginia, wrote to the chairman of the Federal Communications Commission, which is responsible for regulating America’s communications networks, with the following query.
“Would it be a reasonable network management practice for ISPs to designate insecure network devices as ‘insecure’ and thereby deny them connections to their networks, including by refraining from assigning devices IP addresses?”
In reply, Wheeler didn’t offer an opinion on whether it would be “reasonable” to disconnect “insecure” devices. He didn’t point out that state-directed disconnection wouldn’t be effective beyond US borders. Neither did he comment on the huge potential invasion of privacy involved, nor on the legal nightmare that would confront telcos cutting off their customers’ access to the network.
What Wheeler did say was that the FCC would be investigating “market failure” within the “device manufacturer community”. He also raised the possibility that the FCC could adjust the way it approves devices for consumer use “to protect networks from IoT device security risks”.
This is how regulation starts: with agencies like the FCC searching for remedies that lie within their grasp.
IoT-mediated DDoS is a big deal. In the long run, as we point out in this recent white paper, device vendors will need to manage vulnerability if they are to escape liability.
At the moment, there’s a lot wrong with the kind of low-end IoT devices that played such a prominent role in Mirai-based DDoS attacks in Europe and North America. The list includes hard-coded passwords, limited or non-existent UIs, inability to update and a lack of encryption and secure key storage.
If you construct an OS for IoT devices with security in mind, the results look very different. Canonical’s Ubuntu Core, for example, offers the following:
- Reduced footprint, with minimum points of vulnerability
- A centralised mechanism for software updates
- Automatic rollback to last known working configuration
- Read-only, digitally-signed files
- Sandboxed applications
In the face of complex threats, the notion of pulling the plug, Galactica-style, amounts to little more than rhetoric designed to appease those whose main contribution to debate involves the phrase “something must be done”.
To contain the threats posed by the explosion of IoT connectivity, we need to take action on multiple fronts. As the FCC indicates, the device itself is one of the most important vectors of all. When IoT devices contain software designed with security in mind, the attack surface will shrink significantly. That’s a goal worth shooting for.
Internet of Things
From home control to drones, robots and industrial systems, Ubuntu Core and Snaps provide robust security, app stores and reliable updates for all your IoT devices.
Newsletter signup
Related posts
EdgeIQ and Ubuntu Core; bringing security and scalability to device management
Today, EdgeIQ and Canonical announced the release of the EdgeIQ Coda snap and official support of Ubuntu Core on the EdgeIQ Symphony platform. EdgeIQ Symphony...
Getting started with Azure IoT Operations on Ubuntu
Introduction With the recent announcement of the release of Azure IoT Operations, Microsoft has provided its customers with a unified data plane offering...
Needrestart local privilege escalation vulnerability fixes available
Qualys discovered vulnerabilities which allow a local attacker to gain root privileges in the needrestart package (CVE-2024-48990, CVE-2024-48991,...