CompTIA CASP+ CAS-004 Certification: Securing the Internet of Things

The Internet of Things (IoT) is a broad phrase that refers to any device that collects data from the world around us and then sends it over the Internet to be intelligently analyzed and used to give information and services (Figure 9.1). This concept was expanded to include an industrial closed-loop control system in which data is collected, combined with related data, sent to an intelligent station, processed, and acted upon to change the environment.

The Internet of Things is an ideal domain for not only securing devices, but also for innovations in secure system design, secure building block technologies, and secure hardware and software development practices, all of which combine to make the Internet of Things into secure internet of things.

The figure below illustrates the Internet of Things:



Figure: Internet of Things (IoT)

Structure
- Internet of Things lifecycle
- Internet of things
- Insecure IoT deployments
- IoT security challenges and requirements
- Managing IoT security services
- Future IoT security
- Wearable devices

Objective
Disruptive new-age devices and their related technologies have changed the way work is done and has created new options to use technologies in offices, homes, healthcare, manufacturing, agriculture, and other domains. While such technologies are revolutionary, they are not always secure. In the rush to have disruptive technology in the markets, security is not always the primary focus. Organizations and users adopting such cutting-edge ‘things on the internet’ often walk on the bleeding edge of technology.

IoT device lifecycle
The security of IoT devices is challenging since security is present at every stage of the device’s lifespan, as illustrated in Figure 9.2. The security SDK/API is crucial for simplifying the device development during the build process. Provisioning and configuring the IoT device would need technologies that could scale across multiple CPU families and include giving a persona to the device. For easy deployment and potential anonymity, the deployment phase should be flexible. The security requirements and specifications for the connectivity should be followed. These devices must be managed in a secure and seamless manner. Due to the integration of diverse assets/secrets from many suppliers in the system, the retirement or decommissioning phase is equally important for an IoT device.

Confidentiality (encryption/decryption) and integrity (sign/verify) properties are used to illustrate a typical flow (for a sensing application), as follows:
- Device
- Establishes a secure connection with the Gateway/Cloud (could be one-time or periodic, depending upon the policy enforcement).
- Interacts with smart and dumb sensors and actuators, collects data, and regulates and drives the sensors and actuators.
- Performs local analytics and, if desired, encrypts the data.
- Encrypts or signs (or both) the data and transmits it to Gateway, depending on the policy.
- Gateway
- Decrypts and authenticates the data before doing some local analytics.
- Encrypts/signs the data before sending it to the fog/cloud.
- Cloud
- Data is decrypted/authenticated by the fog/cloud instance, and cloud applications do analytics.
- Data is encrypted/signed and stored in databases by cloud applications.

Device identity, protected boot, protected storage, trusted execution environment, and containers are the five buckets of capabilities that security essentials focus on.

The figure below illustrates the IoT device lifecycle:



Figure: IoT device lifecycle

Device identity
A platform’s hardware identity is an immutable, unique identifier. The platform and the persona must be inextricably linked. A hardware root of trust, also known as a hardware embedded cryptographic key, can be a useful device identifier. As part of the Trusted Platform Module (TPM) specification, the Trusted Computing Group (TCG) specifies hardware-roots-of-trust. For storage, all TPM manufacturers must implement a hardware root of trust. Intel® Platform Trust Technology (PTT) integrates a security engine into several of its SoC devices to achieve TPM capabilities. A distributed group of IoT nodes may be trusted by using an IoT system that imposes a common and confirmed safe boot policy.

The establishment of a secure IoT network necessitates distributed trust.

Protected boot
This functionality protects against sophisticated bootkits and rootkits that have been shown to sit in very early boot code and are capable of launching a range of assaults on the system. These attacks take place without the awareness of the operating system, making them immune to detection by anti-malware software. TCG establishes a root-of-trust-for-measurement (RTM) requirement for secure platform boot, requiring the platform to offer a secure platform reset and first boot executive that is implemented in hardware. TCG didn’t go into detail about a specific implementation. The hardware-based root of trust for the system boot process is Intel Boot Guard. It enforces OEM boot regulations architecturally and protects the initial measurement and verification of the first OEM component. OEM boot policy is stored in the OEM-programmed FPF file.

Protected storage
Protected storage is a basic security capability that is necessary to support a variety of additional security features. The Trusted Platform Module (TPM) supports safe storage primitives for cryptographic keys, configuration registers, and whitelist values, among other security objects.

Protected storage has the following characteristics:
- Data confidentiality: Unauthorized entities cannot read the data.
- Data integrity: Unauthorized entities cannot modify the data or unauthorized data modification can be detected.
- Anti-replay protection: Unauthorized entities cannot replay/reuse stale data for storage.
PTT is an implementation of the TCG TPM specification in an SoC that depends on hardware separation of flash and other memory to restrict access outside of the TCG specified interfaces. Intel® QuickAssist Technology (QAT) is a hardware data encryption accelerator with key storage security built-in. Bulk data encryptions, which enable cypher texts to be stored on regular storage media but encryption keys to be kept in hardware, are a frequent way for constructing safe storage for data that surpasses the capacity of hardened secure storage resources.

Hardware security
Platform attacks have historically progressed from application-level software (SW) through user-mode SW, kernel-mode SW, firmware (FW), and now hardware (HW). From 2003 to 2021, the incidence of HW and FW level vulnerabilities rose significantly, reinforcing the necessity for HW-based security to harden the platform. The technologies involved in securing an IoT device anchored to a Hardware Root of Trust (HW RoT) and eventually booting into a Trusted Execution Environment (TEE) are described in this guide. In an IoT setting, there are four main areas of concern for security – the device, user identification, data, and security at runtime.

Trusted execution environment
Trusted Execution Environment (TEE) is a separate execution environment from the general-purpose execution environment (Figure below). A security coprocessor, for example, is an isolated environment, whereas the core CPU is a general-purpose execution environment. HW/SW/FW that creates an isolated environment may be included in trusted execution environments. The TEE can have strong guarantees for safe and reliable execution of TEE workloads by carefully regulating the infrastructure that creates the HW/FW/SW that implements it.

A TEE is often used for workloads that need the usage of cryptographic keys to secure the confidentiality and integrity of data as it is translated to and from the ciphertext.


Figure: Trusted execution environment

Built-in security
Built-in security features are critical for a platform’s security to be protected, detected, and corrected. These characteristics allow for the protection of the platforms’ identity and data assets against assaults, as well as the detection of attacks and the deployment of remedial steps to make the platforms more robust.

Threats to firmware and RoT update
An Internet Engineering Task Force working group named Software Upgrades for Internet of Things (SUITS), is addressing firmware updates for IoT systems. SUITS is a working group that established a thorough list of dangers and requirements that systems adopting updates should comply with.
- Malicious/modified firmware updates: When upgrading firmware, the first hazard to consider is corrupted or deliberately changed software. If an attacker can edit the firmware as it is being sent to the platform, or even while it is being updated, the attacker can insert features into the device. Accidental corruption is equally as harmful, as it might compromise a machine if the firmware is corrupted during the update process (causing the system to be permanently broken).
- Rollback to old (vulnerable) firmware: The second most prevalent hazard to the firmware is rolling back to a previous version. An attacker who can compel a system to reload an older version of firmware may be able to reintroduce a previous vulnerability, allowing them to seize control of the platform. This is particularly risky since the platform owner may mistakenly assume they are immune to that vulnerability and may not be looking for signs of compromise for that specific assault.
- Unauthorized update request: The person or entity allowed to update firmware on the platform is an often neglected danger to firmware and RoT upgrades. Allowing a network attacker to force a firmware upgrade is dangerous. An attacker might cause an issue by successfully pushing corrupt or invalid firmware onto a platform, but even a genuine firmware update could cause platform instability or a denial of service. Firmware update procedures should ensure that the entity requesting the update is permitted to do so, either by functioning under an administrator account or by cryptographically proving that their request came from an authorized administrator.
- Unknown firmware source: Even if an authorized entity requests a firmware update, the firmware source (the firmware code itself) should originate from a known and approved source. Broadcom should not write firmware that is meant to update an Infineon TPM device; there are exceptions, most notably when an OEM repackages an update for their device (i.e., HP repackaging a TPM update for the devices they manufacture).
- Incorrect firmware application: Finally, firmware must be compatible with the system model and version of the hardware on which it runs. Hardware components can come in a variety of revisions, and software for one component may not work properly on a different stepping or version.

Software security
The operating system should be the primary concern when evaluating software security on any platform. The operating system (OS) is the most fundamental level of software on any computer. It regulates which hardware is turned on and what other applications may perform. The OS provides a foundation for all other software on the platform. If the operating system lacks a basic capability, or if other software is unable to manage or access any aspect of the system (hardware or software), no other component of the platform can compensate. If the operating system lacks any security features, the remainder of the software on the platform is likely to be more vulnerable. Some essential elements of operating systems are discussed, as well as how the operating system should contribute to the platform’s security.

A basic set of security services that an operating system should provide is as follows:
- Execution separation: Provides structures and procedures for separating distinct execution units of programs so that they don’t interfere with the execution of other programs; this separation includes processes, threads, interrupt service routines (ISRs), and critical sections.
- Memory separation: Provides mechanisms for separating the various types of memory used by running applications, such as process memory, thread-only stacks, shared memory, and memory-mapped I/O.
- Privilege levels: Provides structures to separate executing programs into different privilege levels; this separation includes task identifiers for executing programs, user and group identities to own executing programs, and administrator vs. user privilege levels.
- System authorization: Provides structures and mechanisms to assign rights to objects and verify the privilege level of execution units against those rights; this includes setting the default privilege level assigned to programs and then enforcing those privileges when programs access system resources, by permitting or restricting certain operations. The least privilege principle may be implemented using this system authorization technique. This includes user authentication and the granting of rights to programs under the user’s control in systems with human users.
- Error protection in programming: Provides structures and techniques that prevent attackers from manipulating mistakes in running programs and taking control of the platform; they generally include stack overflow protection, heap corruption detection and prevention, and control flow redirection limitation. Software attacks come from these errors, allowing a hacker to inject arbitrary code and seize control of a device. Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP) are two types of control flow safeguards.
- Access-controlled secure storage is a means for storing program secrets and preventing unauthorized users or programs, including the administrator, from accessing those secrets; the system typically provides this using hardware-backed secure storage.
Operating systems have the greatest degree of power on a platform, allowing them access to practically everything. An attacker that successfully attacks an operating system can gain the entire control of the platform, as well as privileged access to other platforms on the same network. The following five components describe popular exploitation attack patterns:
- Fault injection: A fault injection causes an execution fault in a process or thread; while part of the blame for this threat lies with the applications, fault injection is the first step toward defeating the operating system, so the OS must take some responsibility to protect against the vulnerabilities that cause this threat. The operating system employs containment to keep these risks from becoming bigger problems for the platform, although it normally lets the error stop the attacked process or thread from running. The operating system employs programming error safeguards, such as control flow prevention, as part of a basic set of security services. The operating system includes programming error safeguards, such as control flow protections and stack smashing protections, to counter this danger, according to our basic list of security services.
- Arbitrary Code Execution (ACE) is the injection of an attacker’s code into a platform process or thread, forcing the injected code to run in place of the current process or thread, essentially assuming the identity and authorizations of that process or thread. Arbitrary code execution not only violates execution separation by enabling unauthorized code to corrupt an execution unit, but it also violates an operating system’s memory separation promise by allowing data to corrupt the platform’s code. If fault injection succeeds, either because the application mitigations were ineffective or because the operating system did not offer any fault injection safeguards, arbitrary code execution is the usual escalation of fault injection. An attacker inserts code into the data used to cause the problem and uses fault injection to have the injected code execute or redirect as part of the fault. Attackers frequently utilize buffer overflows and heap corruption to construct arbitrary code execution attacks.
- Code in one execution unit viewing or interacting with code or data in another execution unit is referred to as a breach of containment. After gaining arbitrary code execution, an attacker can use that power to extract data or corrupt other execution flows on the platform. Attackers frequently utilize side-channel assaults to obtain data and watch program execution. Because side channels allow a lower-privileged execution unit to monitor a higher-privileged execution unit, they can possibly retrieve secrets such as passwords and cryptographic keys from the other execution units. These attacks violate memory separation by allowing one program to observe or infer data from another; frequently, attacks on the execution separation are used to breach memory separation. Speculative branch prediction is a frequent example of this execution separation breach, but there are others as well.
- Escalation of privilege: Escalation of privilege refers to circumventing the operating system’s permission systems or code in order to gain access to a level of privilege that should not have been granted. An attacker can use the secrets extracted from other execution units to assume a higher privilege level after breaching confinement and obtaining secrets from other execution units. In rare situations, the attacker can inject a flaw into the operating system itself, forcing it to provide a privilege to the attacker’s code unit that should not have been granted. In both circumstances, the attacker has increased the privileges granted to the attacker’s process by the operating system. This escalation deviates from the system authorization procedures’ intended behavior.
- Rootkit: A rootkit is a type of malware that infiltrates the operating system and takes over part of its functions. Following arbitrary code injection, an attacker can use a chain of arbitrary code injections, containment flaws, and/or escalation of privilege attacks to finally inject the attacker’s code into the operating system. The attack may be a simple one-two chain in some circumstances or a sequence of more sophisticated acts in others. If the attacker can edit the operating system code on disc or in flash, he or she can stay on the device indefinitely. Once an attacker has gained this degree of access to a system, removing the attacker from the system frequently necessitates a complete rebuild of both the software and firmware on the device.

With rootkit access, an adversary may generally bypass the platform’s access-controlled secrets safeguards, allowing the attacker to alter all secrets and execution units on the device. By altering access control decisions, concealing execution units, and decreasing or eliminating memory protections across various execution units through modifications to page table allocations, a rootkit can actually affect the behavior of the operating system.

Containers
Containers are a sort of software separation technique that enables one or more programs, as well as their associated libraries, packages, and services, to operate in a namespace provided by the operating system (Figure below). Certain resources in an operating system are arranged into namespaces. For example, all users are contained under a namespace, which implies there can only be one root user and one dave user (users are actually based on numeric identifiers, but the concept still holds). If two users have the same name, they are the same person. Devices, file paths, and some logical resources, such as network ports and process IDs, all use the same namespace notion. The operating system within a container assigns the container its own namespace for some sorts of resources. So one container can open port 443 for a web server to wait for incoming traffic, while another container may do the same, and there will be no conflict.

To distinguish the two network traffic flows outside the container, some sort of mapping must be performed. In our user identity example, two containers may both have the user dave, but they wouldn’t be associated with the same user; consequently, there would be no conflict between the containers and no privilege leakages or access overlaps between the containers’ apps.

The figure below illustrates the containers:


Figure: Containers

Containers also take advantage of a kernel feature known as cgroups. Cgroups define a kernel structure that restricts the amount of memory and CPU processing accessible to group programs. This may be used to make sure that a cgroup’s processes don’t starve out other groups. This guarantees that all containers receive an equal amount of processing time and that no one container may monopolize the CPU and prevent other containers’ programs from running. Different containerization engines package these capabilities in different ways to enable the creation and management of an environment that allows for the separation of software for applications. Although all of them are referred to as containers, the attributes and controls of different containerization engines may differ somewhat. The following is a quick rundown of the most common types of IoT attacks:

- A DoS attack causes a VM to stall or produce such a significant VM abort that the hypervisor refuses to let the VM continue to run. A more serious DoS might harm a platform device, prohibiting all VMs from accessing it until the platform is restarted, thereby breaking device mediation. Attacks on a virtualized hardware device that cause a denial of service (DoS) are a breach of execution separation. Another sort of DoS attack depletes resources, such as network socket handles, preventing other VMs from acquiring the resource required to perform a function.

- Stack Overflow and arbitrary code execution: Vulnerabilities like stack smashing, heap smashing, and use-after-free allow an attacker to run their own code on the platform. This form of attack can allow the rights of code to be escalated, making it a privileged user. This might lead the VM to misbehave and breach the hypervisor’s trust in the VM, resulting in an execution or memory separation violation in para-virtualized systems (prevent abuses from direct execution of commands from guest VMs).

- Obtain information: An out-of-bounds read vulnerability allows a virtual machine (VM) to acquire memory that is not in its logical memory region. These flaws are frequent in virtualized drivers and VM software. A memory separation violation is represented as a gain information vulnerability.

- Gain privileges: Add-ons, such as tools and plugins, are commonly used to carry out gain privilege assaults. The CVE-2017-4943 vulnerability, for example, enables a show log plugin to obtain root access to the platform management VM, which handles network settings, system updates, health monitoring, and device management. Because root on a para-virtualized VM allows the attacker to easily break the implicit para-virtualized cooperation agreement, gaining root on a para-virtualized system is comparable to compromising the hypervisor itself (Management of hypervisor platform).

Security management
During the installation, configuration, operation, and decommissioning of systems, security management is the combination of active processes and executed procedures that ensure the confidentiality, integrity, and availability of those system and network resources for the organization’s approved mission(s).

Secure device onboarding
Device provisioning, or how to provide devices so they can connect to the relevant back-end cloud system or device management system, is the first issue that requires a solution in an IoT system. Pre-provisioning devices to connect to a certain cloud agent during manufacture is a typical technique. This is how Microsoft Azure Sphere works. While it works, the solution binds the device to a single cloud, and the technique has the potential to disrupt high-speed production.
 

The figure below illustrates secure device onboarding:


Figure: Secure device onboarding

SDO utilizes a few hardware security features to construct this high-level service, including the following:
- Platform’s root of trust, which contains an identification key; an EPID group signature key is preferable for device installation privacy, although an RSA or ECDSA key may also be utilized.
- Intel SDO client firmware running on a TEE; SDO presently utilizes the CSME, but SGX or Trusty are other options.
- The manufacturer’s public key, a GUID, and an ownership credential are stored securely on the device.

Platform integrity
Maintaining the integrity of the platform software once a device has been supplied is critical to keeping an IoT system running. Platform integrity refers to verifying that a device has booted the system’s proper platform software and that the platform firmware, boot loader, and operating system have not been corrupted. Device management software may check the integrity condition of the platform to see if anything needs to be updated or fixed. However, some software must exist on the device in order to compute platform integrity and then transmit it in a meaningful fashion to the device management software.

Network defense
Because IoT systems are all about communication, they would be obvious targets for network attackers if they didn’t have some kind of protective measures in place. Firewalls and intrusion detection software are common network defensive features that should be included in each IoT device. Because certain devices are so little and have so few resources, no attempt is made to install any network security. Of course, limiting the apps and services that open ports to listen for connections is the first step in network protection. In fact, if your IoT device is so resource-constrained that you’re considering disabling network protections, then listening services should be disabled as well, leaving just outbound connections. Firewalling, on the other hand, is the most basic defense, a software that intercepts incoming network traffic.

Platform monitoring
In the event that a network attacker is able to defeat the device’s network defenses, security management comprises monitoring the device and its workload for irregularities. The monitoring features are integrated with the platform’s device management agent, allowing issues to be notified to the management servers.

McAfee Embedded Control
In security management, there is one last software capability worth mentioning that gives some unique system authorization capabilities. McAfee Embedded Control (MEC) is a software tool that gives IoT systems more access control and integrity. MEC safeguards both executable and data files on a platform, guaranteeing that they are not altered inadvertently or maliciously, even by a user with administrator privileges. On the platform, MEC establishes a new privileged user that can only access the MEC admin interface and administers a database of integrity checksums for directories and files specified by the MEC admin. MEC establishes a robust security mechanism for IoT devices and performs exceptionally well when the platform’s software and configuration do not change frequently. MEC is simple to incorporate into McAfee’s ePO device management package.

Security objectives and requirements
Assets in a retail IoT device include the following:
- Cardholder data and transactional information at rest and in transit.
- Consumer identity: Personally identifiable information (PII) should be kept under rigorous access control, preferably with data-at-rest encryption.
- POS device identity: Device credentials are required to protect against remote hacker assaults and maintain a stable connection to the device cloud infrastructure.
- Hardware components: During production and deployment, the HW BOM list in the platform must always be safeguarded via a transparent supply chain and guarded in the field as needed.
- Firmware, including pre-OS boot loader: The platform’s firmware is a valuable asset.
- User and kernel modes, The OS kernel, as well as user-mode SW components such as apps, are all valuable assets.

Threat #1: Allows a hacker to easily compromise the boot firmware and OS image’s integrity. The hacker gains access to the system by disrupting the execution flow. Implementing Boot Guard to construct a chain of trust based on an HW Root of Trust is the mitigation. When the firmware is tampered with and an attempt is made to boot with this unsigned firmware, the Boot Guard detects this and resets the device to avoid future breaches of critical assets.
 

Threat #2: Unauthorized actors might configure devices according to their preferences, such as usernames, passwords, and password reminders. The Intel Secure Device Onboarding technology might be used to supply the device persona and require users to change their default passwords to more secure ones, as well as provide strong password reminders and two-factor authentication.
 

Threat #3: Logging transaction data to a POS server. This is a serious danger in which an attack might breach the PCI DSS’s P2PE rules, allowing hackers on the network to get cardholder data. To ensure secrecy, Intel AES technology in the CPU may be utilized to encrypt the cardholder’s information. The encryption procedure can be done inside an SG enclave to defend against ring 0 or rootkit assaults, increasing the robustness of this aspect of the solution.
 

Threat #4: Allows the cryptographic keys needed to secure platform and owner secrets to be readily retrieved or stored. Protecting the keys used to encrypt the cardholders’ data by keeping them in a PTT/TPM so that they are never exposed to hackers is once again a significant duty.

Conclusion
This guide focusses on IoT security for safeguarding things on the Internet as connected devices and network infrastructure of the IoT. IoT provides Internet connectivity to systems, embedded devices, sensors that are interrelated computing devices, mechanical and digital machines, objects, animals and/or people. Each such thing is provided with a unique identifier and the ability to automatically transfer data over a network. Allowing these devices to connect to the internet opens them up to a number of serious vulnerabilities if they are not properly protected.