The Bots Are Coming!
How to not become part of the planet’s largest botnet
The surge of networked devices in the Internet of Things (IoT) increased the stakes for information security once more. But IoT sensors and actors also pose a threat towards existing information infrastructure. They can be used as remote-controlled drones in so-called Distributed-Denial-of-Service (DDoS) attacks. How do we ensure the trustworthiness of information systems on the Internet of Things? How do we protect against attacks of a global bot army?
Boon and bane IP-based networking
The trend towards “augmenting” everyday objects into “smart things” and the business models based on them (interaction, monitoring, predictive maintenance, extra services) require the global networking of devices. To enrich IoT devices with value-added services, they have stepped out of the shadows of industrial production facilities and their proprietary protocols. Today, they communicate primarily via IP-based networks. — With distressingly high bandwidths. This is manifested in rising attacks on IoT devices, for example, routers, webcams, and smart TVs, but also refrigerators and (yes!) washing machines. Depending on the source (Mozilla, IDC, ABI Research, Gartner, Frost & Sullivan), the number of IoT devices in 2020 is estimated at between 26 and 40.9 billion.
The majority of new application programming interfaces (APIs) are now developed using the REST architecture paradigm. With HTTP(S) as the standard protocol, the majority of devices can thus be accessed via the public Internet. This standardization — although desirable for developers — has exposed a huge attack surface for IT infrastructures.
API calls now account for 83% of global Internet traffic and 40% of the vulnerability of web applications is not the user interface but the API, according to Akamai. Gartner expects APIs to account for 90% of the attack surface by 2021 and thus become the most common target by 2022.
At the American parcel service USPS, 60 million user data records were available via an API for one year. An error allowed all logged-in users to perform a wildcard search of all user accounts and (analog) packages without further authorization checks. The bug thus occurred at the lowest implementation level, access protection.
In 2016, the malware “Mirai” (still active in modified versions) was responsible for the largest botnet and the largest DDoS attack. Due to the size of the botnet, the attack could be executed with a load of 620 Gbps, which could have eliminated many critical information infrastructures.
In the B2C market, convenience is often exchanged for security, as a result of which devices such as webcams and other “smart home” products are repeatedly delivered with standard passwords or without any encryption at all. Only half of the users change passwords, which leads to these devices being compromised in large numbers and then used for DDoS attacks.
With the growth of home offices, these consumer IoT devices are increasingly found in the same networks as work notebooks. This is accompanied by the loss of personally identifiable information (PII) and the compromise of enterprise information systems.
The risks are inherent to the device characteristics. Limited computing capacity and diversity of hardware and software can prevent or complicate adequate security measures. Systematic maintenance of the devices with security updates and hardened components is still one of the biggest obstacles to maturity. Physical access control is an extra challenge that we already know from the mobile computing era.
Finally, the protection of IoT devices is often neglected due to their low manufacturing costs. Write-offs for defective or lost devices can be part of a business plan. But the consequential costs of safety deficiencies rarely seem to be part of that assessment. An ecological problem is the forced replacement of products at the end of their life-cycle. Whether with or without the consent of the customer, some IoT devices are bricked (a.k.a. “death by software”).
Vulnerabilities in the Internet of Things
A saying in the IT security community says that the defender must defend all points, but the attacker can choose the weakest one. “Defense-in-Depth” thus describes the protection of all essential stations between the sender and receiver of data packets. This is to prevent a single weak point from compromising the entire system. Each new device category (most recently mobile devices, now IoT) can represent precisely this vulnerability due to its novelty.
The Open Web Application Security Project (OWASP) has established itself as a source of practice-oriented guidelines, in which the most frequent vulnerabilities in web applications, APIs, server applications, etc. are collected. For IoT applications, this list has been aligned with the Baseline Security Recommendations for IoT of the European Union, Common Criteria and other standards. The most common IoT vulnerabilities according to the OWASP IoT Top 10 are (also see image above):
- I1 Weak Guessable, or Hardcoded Passwords
- I2 Insecure Network Services
- I3 Insecure Ecosystem Interfaces
- I4 Lack of Secure Update Mechanism
- I5 Use of Insecure or Outdated Components
- I6 Insufficient Privacy Protection
- I7 Insecure Data Transfer and Storage
- I8 Lack of Device Management
- I9 Insecure Default Settings
- I10 Lack of Physical Hardening
The top 10 problems show the lack of maturity of the IoT ecosystem. Weak or standard passwords should not be among the most common vulnerabilities, nor the use of insecure network services (on the devices) or insecure interfaces to the rest of the ecosystem. Thus, the problems are by no means caused exclusively by the IoT devices themselves, but rather by the overall context of the application architecture. Thus, holistic solutions must be found, starting with the architecture and system design.
Security from the very beginning: Security-by-Design
If possible, measures to increase security should be used in the system design and throughout the development process. The basis for this can be threat modeling. This provides an overview of the system boundaries and communicating individual systems. The components can then be analyzed individually and in combination as required, resulting in an assessment that reflects the actual risks.
The categories of risks that are not completely free of overlaps can be examined, for example, using the following well-known mnemonic devices (see Writing Secure Code 2):
- STRIDE: Spoofing, Tampering, Information Disclosure, Elevation of privilege
- DREAD: Damage potential, Reproducibility, Exploitability, Affected users, Discoverability
The identified risks can then be countered with appropriate measures. At the beginning of the development process, these include constructive measures such as applying security-by-design principles, suitable architecture models and design patterns. But analytical measures such as code reviews and load and security tests also make a significant contribution to the security of the overall system.
IoT Architectures: Don’t reinvent the wheel!
Reference architecture models can help to design reliable and secure information systems. They provide definitions and a framework of how different aspects are connected. Usually, they also include patterns of how to solve the most common problems in the given application area. Some (mostly European) IoT reference architectures include:
- AIOTI High-Level Architecture (HLA): Comprehensive reference architecture model on IoT and Big Data
- oneM2M: IoT-specific middleware with platform-independent APIs (“IoT operating system” for gateways and servers)
- Reference Architecture Model Industry 4.0 (RAMI): Comprehensive reference architecture model for industry 4.0
- ISO/IEC 30141: ISO standard for an IoT-specific reference architecture
Remarkable is the mutual reference of the standards, which makes it necessary to consider and weigh up the individual cases together. For example, the AIOTI architecture classifies itself as the manifestation of the layers in the RAMI model. oneM2M equally addresses an implementation-specific subset of RAMI.
Due to the focus of the individual models on certain aspects and the omission of others, no clear mapping between the models is possible, of course. It must be decided in each case which model offers the appropriate framework for the corresponding architecture. However, the use of standards and reference models will most likely increase the security of IoT architectures and connected systems.
Securing an exemplary IoT infrastructure
The figure below shows the components and their interaction in a typical IoT scenario with IoT sensors/actuators, a cloud backend and connected business applications with mobile devices. Each component and each interface in this architecture offers attack possibilities on the overall system. Attackers can use all layers of the OSI model. Accordingly, security must also be considered at all levels.
After the hardware, this begins with the diverse operating systems, which should be hardened and up-to-date. At the operating system and container level, there are also isolation mechanisms (control groups, access control lists, sandboxes, etc.) that should be used.
Furthermore, no unused services should be in operation that unnecessarily increases the attack surface. The use of proxies (IoT gateway, API gateway, cloud gateway, DMZ proxy) also offers the possibility of allowing only very specific data traffic to pass through to further systems.
Basic protection at transport level can be achieved for IoT sensors and actuators with unique, registered IDs and symmetrical encryption to the IoT gateway. The individual components communicate with each other via protocols. IoT-specific protocols such as CoAP, MQTT and AMQP, but also Kafka and REST/Http each have security features that must be implemented correctly. Established standard libraries and frameworks should be used as far as possible. It is generally not advisable to develop even simple security-relevant functions in-house if such libraries exist.
The use of Web Application Firewalls (WAF) and Identity and Access Management (IAM) can help fend off attacks at the infrastructure level. DDoS attacks can sometimes even be detected and mitigated by features of the cloud infrastructure.
Once the data has reached the back end, the authorization to access certain resources (data, services) should be recorded in policies. The set of rules contains the information, which roles are allowed to perform which operations (read, write) in which context (location, time, IP address, authorization objects…). This allows a fine-grained role-based access control (RBAC) to be implemented, which only grants access to authorized entities (roles, clients, services) as a white list.
Administrative controls for IoT are not much different from those of conventional information technology as listed in ISO/IEC 27010. Detective controls should be part of the monitoring and alerting concept so that suspicious behavior can be spotted and dealt with. The operation of the infrastructure also includes the replacement of defective IoT devices, the replacement of batteries and a concept for installing firmware and security updates. Data backup and data recovery are as much a part of the operation as the scalability of the platform when additional devices are connected.
Alternative approaches
Large cloud computing providers offer platform-specific IoT solutions that are strongly integrated with the respective cloud ecosystem and thus partly contain SDK, IoT Gateway, Message Broker and IAM from a single source. Depending on the standards and protocols used, the risk of a vendor lock-in increases. But then again, you shouldn’t implement it yourself.
Another approach to security is to bake trust modules into the IoT hardware. A trust anchor at the hardware level makes it possible to validate the integrity of the hardware and software stack on the devices and thus provide greater security for communication.
The International Data Spaces Association (IDSA) is also trying to solve the problem using trust anchors, but with a decentralized and platform-independent approach. The current IDS reference architecture describes a decentralized infrastructure of trusted and certified “connectors” whose integrity can be attested via a special communication protocol (IDSCP). This requires a central public key infrastructure and brokers for the semantically driven networking of the connectors. Once implemented, however, the concept could offer a trustworthy and secure infrastructure, especially for IoT scenarios.
Conclusion
Given the immaturity and explosive proliferation of IoT devices, there is now a considerable risk of attacks on information systems. This risk can be significantly reduced by well-known basic information security and additional IoT-specific security measures.
In addition to a security focus in the development process, the use of uniform platforms, standards, and reference architectures can drastically reduce the cost of security implementations. Given the expected added value and the considerable risk for directly and indirectly connected IT systems, greater investment in the information security of IoT infrastructures justifies itself.
