This blog by Robert Dobson was originally posted on Device Authority website.
With this growth comes many challenges, not least “how do we ensure these devices are secure?” Yet at the same time enabling these IoT devices to connect with services in a robust and automated way which doesn’t stifle or impact the growth of the market. Traditional PKI orientated architectures are too heavy weight and cumbersome for a lot of IoT type applications for today and future products. For IoT applications we need to have ways to secure products which meet the needs of each application in a way which suits the IoT markets.
A recently observed trend is that customers are starting to become aware that they need to take control of their own security posture, moving away from an approach which lets the manufacturer control it, to one which focusses on the customer’s device and platform requirements. Customers want to choose how the protect their businesses, IP and supply chain by creating their own individual security posture and avoiding using existing methods of using default passwords, which is not an acceptable or a secure option.
This blog series aims to cover a range of topics trying to identify the key issues, building out some ideas on how we might address some of the issues which seem pertinent to addressing security in IoT.
The main topics covered will include:
- DDOS recent attacks and prevention solutions
- Automated Device Owner Certificate Provisioning
- Enrolling devices at scale securely
- Policy based security, Managing large groups of devices for different users
- Secure firmware and software updates
The first instalment for this blog seeks to cover the current hot topic of DDOS and the use of Cameras to wreak havoc on online services and how we then might be able to protect against these attacks.
DDOS, Cameras and recent attacks:
Distributed Denial of Service (DDOS) has been used for many cyber-attacks over the past decade or so, and the recent attacks are no different in the way they have been used to create havoc on some very well know services. What is alarming with these latest round of attacks is how they have been used at a large scale to bring down these services. A significant number of security professionals are warning that the lack of security in the IoT will make it attractive for attackers to target. This is particularly worrisome, as the predictions for growth of the IoT market is very large, which opens the ground for potentially huge attacks which could impact critical services.
DDOS attacks are orchestrated by a hacker gaining access to “unsecure” devices and then introducing malware into these devices without the knowledge of the device owner. These devices are then used as a “zombie” army / Botnet (collection of compromised computers often referred to as “zombies”) to attack (under the control of the attacker) specific services and websites. Each malicious attack is aimed at denying services to users and overloading the service.
The most recent DDOS attacks use internet connected Cameras to form an army of zombie devices, these devices were then used to target specific services such as OVH. Over 145,000 devices were used in the OVH attack and generated up to 1.1 Tera Bits Per second of data traffic! Similar attacks were recently inflicted on Dyn DNS service, with a reported attack from 100,000 end devices that took out Twitter, Amazon and others for many users.
This DDOS attack along with several other recent attacks were started by attackers connecting to each Camera device (usually via SSH or a Telnet session) and then infecting them with a simple program that guessed at their factory-set passwords, often “admin” or “password.” Once infected, these devices were turned into an army of simple robots.
One way to make these DDOS type attacks harder is to ensure each device (in this case Cameras) uses a more robust username and password. If each device or a group of devices had different usernames and passwords, then gaining entry to vast swathe of devices would be more difficult.
The key thing here as a customer is to enforce your own security posture and not leave this to the manufacturer.
So, how do we improve our security posture to reduce the risks against DDOS? One way is to move away from using default passwords for all products for the lifetime of the product. An additional idea is to have an Integrity Validation mechanism in your product which allows you to detect malware infecting the device and then preventing the effected device(s) from gaining access to a network.
The latter can be achieved by using Device Authority’s KeyScaler platform which the designer would install onto the IoT device. Each device basically gets given a “unique” digital DNA. This could include the makeup of the firmware on the device, hardware configuration and many other parameters. This DNA is then used when connecting devices securely KeyScaler and forms the basis of a trust anchor for the device. KeyScaler would identify a change to the software on the device when the device tries to register. KeyScaler would then quarantine the device and raise an alert/event which could then be used to disable the devices network connectivity in some way i.e. Blacklist a device from gaining access to a Cellular network and preventing the device from carrying out a DDOS style attack.
In a future product release of our KeyScaler platform we will be introducing an Automated Admin Password Management function to securely rotate / renew username and passwords remotely for specific users and user groups. This will address the problem of updating passwords and usernames on the fly to mitigate potential hacks.
The next blog in this series will discuss “Automated Device Owner Certificate Provisioning”. Which can speed up delivery of standard signed certificates (in a PKI Model) to devices such as Cameras. This can bring down your production costs and improve speed up your deployment.
Check out our Automated Camera Security Management solutions.
Make sure you sign up for our next webinar: IoT Security Automation for Connected Surveillance Cameras.
Disclaimer:
The views and opinions expressed in this article are those of the authors and do not necessarily reflect the official policy or position of the IoT Security Foundation.