Cloud, IoT and Enterprise Security

Chapter 10
IoT, Edge and Cyber-Physical Security

Post Graduate Program in Cyber Security
Cloud, IoT and Enterprise Security   •   Post Graduate

10. IoT, Edge and Cyber-Physical Security

Introduction and Context

The Internet of Things (IoT) connects physical objects—sensors, actuators, machines, vehicles, appliances, medical devices and industrial equipment—to digital networks and services. These objects collect observations from the physical world, exchange data, and increasingly make or support decisions. Edge computing places processing closer to those objects, while cyber-physical systems (CPS) integrate computation, communication and physical processes in a tightly coupled manner.

Security in this environment cannot be treated as a smaller version of conventional enterprise information security. A compromised laptop may expose data or provide an entry point into a network; a compromised industrial controller, infusion pump or vehicle system may alter a physical process and threaten safety, production or human life. Devices may operate for decades, have limited memory and processing capacity, use proprietary protocols, and remain physically accessible to attackers. Consequently, IoT and CPS security must combine cybersecurity, systems engineering, operational technology (OT), safety engineering, privacy, supply-chain assurance and lifecycle governance.

This chapter examines the architecture and security of IoT, edge and cyber-physical environments. It follows the device from design and provisioning through operation, maintenance and decommissioning. Particular attention is given to identity, firmware, embedded operating systems, protocols, gateways, industrial environments and the tension between security controls and physical or operational constraints.

Learning Objectives

After studying this chapter, the learner should be able to:

  • distinguish IoT, edge computing, OT, industrial IoT (IIoT) and CPS;
  • explain the security role of sensors, actuators, gateways, edge nodes, cloud platforms and control systems;
  • assess threats to firmware, embedded operating systems, device identities and communication protocols;
  • design lifecycle controls for secure provisioning, authentication, updates, monitoring and decommissioning;
  • apply segmentation, zero-trust principles and defense-in-depth to IoT and OT environments;
  • evaluate the relationship between cybersecurity, safety, availability, privacy and physical constraints; and
  • recommend security improvements for realistic enterprise and industrial scenarios.

The Architecture of Connected Physical Systems

An IoT system is best understood as a chain of observation, communication, computation and action. Sensors measure temperature, pressure, location, vibration, electrical current or other variables. A microcontroller processes measurements and may trigger a local response. Gateways aggregate data from multiple devices, translate protocols or enforce policy. Edge nodes perform analytics near the source, reducing latency and dependence on a central cloud. Cloud or enterprise platforms provide large-scale storage, analytics, orchestration and integration with business processes. Actuators convert digital commands into physical actions such as opening a valve, adjusting a motor or changing a building’s temperature.

This architecture is not always linear. Devices may communicate laterally, gateways may operate autonomously during loss of connectivity, and control loops may be distributed across several layers. A safety-critical function may therefore depend on a sensor, a field bus, a programmable logic controller (PLC), an engineering workstation and a supervisory control and data acquisition (SCADA) server. Security analysis must follow data and control flows rather than merely counting devices.

The distinction between IoT and OT is significant. IoT commonly emphasizes connectivity, data collection and service integration. OT refers to systems that monitor or control physical equipment and industrial processes. OT environments prioritize availability, deterministic behavior, process integrity and safety. IT security practices such as aggressive patching or endpoint isolation may be unsuitable if they interrupt a continuous production process. IIoT combines industrial equipment and operational processes with modern connectivity, analytics and cloud services. CPS is the broader engineering concept in which cyber components and physical processes interact through feedback loops.

Edge computing is both a performance architecture and a security boundary. Processing locally can reduce latency, limit the volume of sensitive data sent to the cloud and permit continued operation during network disruption. However, edge nodes may be deployed in factories, vehicles, retail premises or remote locations where physical protection is weak. They can therefore become high-value aggregation points and require strong local identity, secure boot, tamper awareness, logging and recovery mechanisms.

Core Security Concepts and Terminology

The traditional confidentiality, integrity and availability triad remains relevant, but CPS adds safety, authenticity, resilience and process integrity. Confidentiality protects operational data, credentials, location information and personal data. Integrity ensures that measurements, firmware, configurations and commands have not been altered. Availability ensures that services and control functions remain dependable. Authenticity establishes that a device, user, update or command is genuine. Safety concerns preventing unacceptable physical consequences, even when a security failure occurs. Resilience concerns the ability to resist disruption, operate in a degraded mode and recover safely.

A device identity is a unique, verifiable representation of a device or its hardware-backed security module. Authentication proves possession or control of that identity. Authorization determines what an authenticated device may do. Attestation provides evidence about a device’s state, such as whether it booted approved firmware. Secure boot verifies the authenticity and integrity of software before execution. A hardware root of trust is a protected foundation—such as a trusted platform module, secure element or protected key store—from which cryptographic assurances are established.

The attack surface includes interfaces through which a device can be reached or influenced: wireless radios, Ethernet ports, debug interfaces, web consoles, mobile applications, cloud APIs, update mechanisms, physical ports and supply-chain components. Firmware is software stored in device memory that controls hardware operation. Unlike ordinary application software, firmware is often difficult to update and may have direct access to memory, sensors and actuators. A bootloader is the initial program that loads or verifies the operating system and application firmware.

A gateway mediates between devices and other networks. It may perform protocol translation, aggregation, authentication, filtering and local decision-making. A digital twin is a digital representation of a physical asset or process, updated from operational data and sometimes used for simulation or control. Inaccurate or manipulated twin data can produce unsafe decisions. A safety instrumented system is designed to place a process into a safe state when specified hazardous conditions arise; it should not be assumed that a general-purpose cybersecurity control can substitute for independent safety engineering.

Threats Across the Device Lifecycle

Security begins before a device is installed. During design and manufacture, attackers may exploit insecure default credentials, undocumented services, counterfeit components, malicious code, vulnerable third-party libraries or weak random-number generation. Supply-chain compromise can affect hardware, firmware, development tools, cloud services and update infrastructure. A device that is secure in operation may still be untrustworthy if its provenance is unknown.

Provisioning is the process by which a device receives its identity, credentials, configuration and authorization. Manual entry of shared passwords is risky because credentials may be duplicated, exposed or never rotated. More robust approaches use unique device credentials, certificate-based authentication, secure enrollment and a controlled association between a device, its owner and its intended location. Provisioning systems should record provenance and support revocation when equipment is stolen, replaced or retired.

During operation, common threats include eavesdropping, replay, spoofing, man-in-the-middle attacks, denial of service, malicious commands, sensor manipulation and exploitation of exposed services. A sensor may report plausible but false values rather than simply becoming unavailable. This makes anomaly detection and cross-checking important. For example, a sudden pressure reading that conflicts with valve position and nearby sensors may indicate manipulation or failure.

Maintenance introduces additional risks. Remote administration, temporary vendor access and firmware updates are necessary in many environments but create privileged pathways. Updates must be authenticated, integrity-protected, authorized and recoverable. A device should reject unsigned or incorrectly targeted firmware, preserve a known-good version where possible, and prevent rollback to a vulnerable version unless a controlled recovery procedure explicitly permits it. Update signing keys require strong protection, separation of duties and emergency revocation procedures.

Decommissioning is often neglected. Retired devices may retain certificates, customer information, network configurations, cryptographic keys or cloud relationships. Secure decommissioning includes asset-record updates, access revocation, data erasure or cryptographic destruction, removal from management platforms and safe disposal of storage media. Ownership transfer requires a reset that removes the former owner’s trust relationships without creating an unauthenticated default state.

Embedded Platforms, Firmware and Protocols

Embedded operating systems vary from bare-metal firmware and real-time operating systems (RTOSs) to embedded Linux and specialized industrial platforms. An RTOS may provide deterministic scheduling, which is essential for timing-sensitive control, but it may offer fewer security services than a general-purpose operating system. Embedded Linux provides a richer software ecosystem but also a larger attack surface and more complex patch dependencies. Bare-metal systems can be small and predictable, yet security functions must often be engineered directly into the application.

Secure design should include memory protection, least privilege, secure inter-process communication, disabled debug access in production, protected secrets, input validation and a mechanism for security logging. Resource constraints do not eliminate the need for cryptography; they require appropriate algorithms, efficient implementation and careful key management. Cryptographic algorithms should be selected according to current standards and lifecycle expectations rather than invented or weakened for convenience.

IoT protocols operate at several layers. Constrained devices may use lightweight messaging protocols such as Message Queuing Telemetry Transport (MQTT) or Constrained Application Protocol (CoAP), while industrial environments may use protocols such as Modbus, DNP3, OPC UA, PROFINET or vendor-specific field buses. Protocol security varies considerably. Some legacy protocols provide little or no authentication or confidentiality and must be protected through segmentation, gateways, monitoring and compensating controls. Secure variants and transport protection are preferable, but encryption alone does not authorize an unsafe command.

Protocol assessment should ask: Who can communicate? How are endpoints authenticated? Are messages fresh and protected against replay? Can commands be constrained by role, process state or physical limits? Are errors handled safely? Are logs generated? Does the protocol tolerate loss or delay without causing dangerous behavior? In a control system, an apparently valid command may still be unsafe if it is issued at the wrong time or to the wrong equipment.

Identity, Trust and Secure Communications

Device identity should be unique, non-transferable where appropriate and bound to a defined ownership and purpose. Certificates based on a public key infrastructure can support scalable authentication, but only when certificate issuance, renewal, revocation and clock management are reliable. Symmetric keys may be suitable for constrained environments, although large-scale rotation and compromise recovery become difficult if keys are shared.

A practical trust architecture often separates device identity, application identity and human identity. A device may authenticate to a gateway, while a service authorizes a particular telemetry topic or command. A human operator may use multifactor authentication and receive time-limited permissions. These layers reduce the consequences of a stolen device credential or compromised application.

Confidentiality and integrity should be provided in transit through appropriately configured secure channels. Mutual authentication is valuable where both endpoints must establish trust. Gateways should not automatically trust every device on a local network; they should validate identity, policy and device state. Network segmentation can separate sensors, control networks, safety systems, enterprise systems and internet-facing services. Segmentation is not merely a collection of virtual networks: firewall rules, one-way transfer mechanisms, monitored conduits and carefully controlled remote access may be necessary.

Zero-trust thinking is particularly useful in IoT environments. It assumes that network location does not establish trust and requires explicit verification, least privilege and continuous evaluation. However, controls must be adapted to operational constraints. A device unable to support frequent reauthentication may be protected through a trusted gateway, local policy enforcement and physical controls rather than simply excluded from service.

Safety, Availability and Physical Constraints

Security decisions in CPS must account for the possibility that a defensive action can itself create danger. Disconnecting a controller may stop an unsafe process; alternatively, it may disable a safety function or cause loss of environmental control. Patching a production PLC during operation may be unacceptable, while postponing the patch increases exposure. Such decisions require coordinated risk assessment by cybersecurity, engineering, operations, safety and management personnel.

The principle of fail-safe design means that failure should move a system toward a condition with acceptable risk. The appropriate safe state depends on the process. Closing a valve may be safe in one plant and hazardous in another. Security controls should therefore be tested against process models, not applied solely from generic checklists. Defense in depth can include physical barriers, independent safety systems, manual overrides, redundant sensors, network controls, application validation and incident response procedures.

Availability also has a special meaning in OT. A short interruption may corrupt a batch, damage equipment or create unsafe pressure. Maintenance windows may be infrequent, and equipment may be unsupported by its manufacturer. Compensating controls—application allowlisting, strict segmentation, passive monitoring, jump servers, backups and restricted vendor access—may be required when patching is impossible.

Privacy is relevant even when devices are industrial. Smart-building sensors can reveal occupancy patterns; connected vehicles can expose movement; health devices can reveal intimate medical information. Data minimization, purpose limitation, access controls, retention rules and transparency should be applied to telemetry as well as traditional databases.

A Security Engineering and Governance Approach

A mature IoT security program integrates technical measures with governance. The first step is an accurate asset and dependency inventory. The inventory should record device type, owner, location, firmware version, communication paths, business or safety function, support status and recovery requirements. Passive discovery is often safer than active scanning in fragile OT networks.

Next, organizations should classify assets according to consequences of compromise. A temperature sensor in a noncritical office, a hospital infusion pump and a turbine controller should not receive identical controls. Threat modeling can examine spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege, while hazard analysis examines physical consequences. Security and safety analyses should inform one another but remain conceptually distinct.

Controls should then be selected across the lifecycle:

  • secure development practices, code review, dependency management and vulnerability disclosure;
  • unique identity, secure provisioning and hardware-backed key protection;
  • secure boot, signed firmware and controlled update processes;
  • network segmentation, least privilege and authenticated management access;
  • centralized or federated logging, time synchronization and anomaly detection;
  • tested backups, recovery images and manual safe-operation procedures; and
  • retirement, revocation, data destruction and supplier accountability.

Governance must define who may approve updates, who can authorize emergency access, how vendors are supervised and how incidents are escalated. Contracts should address vulnerability notification, support duration, software bills of materials (SBOMs), secure update capability, breach cooperation and end-of-life responsibilities. Standards and guidance from bodies such as NIST, IEC 62443, ISO/IEC 27001, ISO/SAE 21434 and sector regulators can support a risk-based program, but compliance does not replace engineering judgment.

Monitoring, Detection and Response at the Edge

Monitoring IoT and OT requires an understanding of normal process behavior. Traditional signature-based tools may miss attacks that use valid credentials or legitimate commands. Network monitoring can identify unusual communications, new devices, protocol violations and unexpected write operations without placing agents on fragile controllers. Edge analytics can detect anomalies locally and continue operating when cloud connectivity is interrupted.

Useful indicators include changes in firmware or configuration, unusual command frequency, impossible sensor combinations, unexpected maintenance connections, certificate failures and deviations from production schedules. Detection systems should be calibrated to avoid overwhelming operators with false alarms. A high-severity alert should correspond to an actionable decision.

Incident response plans must distinguish between cyber containment and process safety. Responders may need to preserve control, move equipment to a safe state, isolate a gateway rather than a controller, or switch to manual operation. Plans should identify engineering authorities, vendor contacts, safety officers and communication channels. Exercises should include loss of connectivity, ransomware affecting enterprise systems, manipulated sensor data and compromise of update infrastructure.

Illustrative Case: Compromise of a Connected Water-Utility Pumping Station

Background

A regional water utility operates several remote pumping stations. Each station contains flow and pressure sensors, PLCs, a local HMI, a cellular gateway and a cloud monitoring service. The stations were modernized to support predictive maintenance, but some PLCs still use a legacy control protocol without native authentication.

Situation and Problem

Operators observe intermittent pressure fluctuations and alarms indicating inconsistent flow. Investigation shows that an exposed gateway account has been used to send commands to one station. The attacker has not stopped the pumps; instead, commands are issued briefly and at irregular intervals, creating conditions that resemble mechanical faults. The utility must restore trustworthy operation without damaging pumps or interrupting water delivery.

Analysis

The initial weakness is not only the legacy protocol. The gateway was reachable through a vendor remote-access service, used a shared account and permitted broad communication between the remote-access segment and the control network. The utility also lacks a complete inventory of gateway firmware and has no independent validation of commands against process conditions. Cloud telemetry remains available, but its integrity cannot be assumed because it receives data through the compromised gateway.

The incident involves confidentiality risks from exposed operational information, integrity risks from manipulated commands and availability risks if the attacker escalates. The most serious consequence is physical: repeated inappropriate pump operation could damage equipment or cause service disruption. A simple network shutdown could also interrupt control and monitoring.

Approach and Solution

The incident team first consults operations and safety personnel and places the affected station under local supervised control. The gateway’s remote-access path is isolated while the PLC is not abruptly powered down. Operators compare local readings with independent gauges and neighboring stations. Commands are restricted through a temporary allowlist, and the station is operated within conservative pressure limits.

The utility then revokes the shared vendor credentials, issues individual certificates, and requires multifactor authentication through a controlled jump host. Firewall rules are rewritten so that the gateway can communicate only with approved services and specific PLC functions. Passive network monitoring is deployed to identify unauthorized writes. Gateway firmware is verified and replaced from a trusted source; the PLC configuration is compared with a known-good backup. Cloud dashboards are treated as informational until telemetry integrity is re-established.

For long-term improvement, the utility creates an asset inventory, separates monitoring from control paths, introduces signed updates, documents safe manual operation and contracts with the vendor for vulnerability notification and support. It also adds plausibility checks that compare pressure, flow, valve state and pump status before accepting a command.

Outcome

Water service continues with reduced automation during the investigation. The utility identifies the unauthorized activity, restores trusted configurations and improves remote-access governance. The incident demonstrates that containment must be adapted to physical processes: preserving safe control is more important than applying a generic “disconnect everything” response.

Learning Points

The case illustrates the value of unique identity, segmentation, least privilege, independent process validation, passive monitoring and tested recovery. It also shows why cloud visibility cannot automatically be treated as ground truth and why cybersecurity, operations and safety teams must make decisions together.

Challenges, Limitations and Common Mistakes

A major challenge is legacy technology. Some devices cannot support modern cryptography, secure boot or agents. Replacing them may be financially or operationally unrealistic. Risk reduction therefore requires compensating controls and a documented modernization plan.

Another challenge is incomplete ownership. A device may be purchased by an engineering department, managed by IT, maintained by a vendor and used by operations. Without clear accountability, vulnerabilities remain unresolved and credentials persist. Shadow IoT—devices installed without formal approval—creates especially serious inventory and privacy problems.

Common mistakes include placing devices directly on the internet, retaining default passwords, treating a gateway as automatically trustworthy, using one credential for an entire fleet, allowing unrestricted vendor access, relying only on perimeter firewalls and assuming encryption proves authorization. Organizations also overuse active vulnerability scanning in sensitive control networks, deploy monitoring without operational tuning, and fail to test restoration from backups.

Security controls may introduce their own weaknesses. An overloaded gateway can become a single point of failure; an incorrectly configured certificate authority can disable an entire fleet; an update can create unsafe timing behavior; and excessive data collection can create privacy and compliance exposure. Every control should therefore be evaluated for security benefit, operational effect, recovery behavior and residual risk.

Emerging Directions

The IoT security field is moving toward secure-by-design regulation, stronger product-security obligations, SBOMs, coordinated vulnerability disclosure and measurable support lifetimes. Hardware-backed identity and remote attestation are becoming more practical for edge devices. Confidential computing may protect sensitive processing at edge nodes, although it does not solve compromised sensors or unsafe actuator commands.

Artificial intelligence and machine learning are increasingly used for anomaly detection, predictive maintenance and digital-twin analysis. Their value depends on trustworthy data, explainable alerts and protection against adversarial or poisoned inputs. AI should assist engineering judgment rather than autonomously issue high-consequence commands without constraints.

Post-quantum cryptography may eventually affect long-lived IoT deployments because equipment installed today can remain operational for many years. Organizations should inventory cryptographic dependencies and favor upgradeable architectures. Autonomous vehicles, robotics, smart grids and connected medical systems will further blur the boundaries among cybersecurity, safety, privacy and product assurance.

Best Practices for Practitioners

A defensible program should maintain a current asset and dependency inventory, assign accountable owners and classify devices by physical consequence. It should use unique identities, secure provisioning, hardware-protected keys where feasible, secure boot, signed updates and documented recovery procedures. Network access should be explicitly authorized, segmented and monitored, with remote administration limited to approved, time-bound paths.

Organizations should integrate threat modeling with hazard analysis, test controls in representative environments and coordinate cybersecurity decisions with operations and safety engineering. Vendors should be assessed for secure development, support duration, vulnerability handling, SBOM availability and end-of-life processes. Finally, incident exercises should rehearse degraded operation, manual control, safe isolation and restoration—not merely data recovery.

Chapter Summary

IoT, edge and cyber-physical systems connect digital computation to physical processes, making security failures capable of causing operational, financial, privacy and safety consequences. Their architecture includes sensors, actuators, embedded platforms, gateways, edge nodes, control systems and cloud services. Security must address the complete lifecycle: design, manufacture, provisioning, operation, maintenance, updates and decommissioning.

Effective protection combines unique identity, secure boot, signed firmware, strong communications, least privilege, segmentation, monitoring and tested recovery. Legacy protocols and constrained devices require compensating controls rather than neglect. OT and CPS environments demand careful balancing of confidentiality, integrity, availability, safety and resilience. Risk assessment should unite cybersecurity, engineering, operations and governance. Emerging capabilities such as edge analytics, AI, attestation and digital twins offer value only when their data, models and control boundaries are trustworthy.

Key Terms

IoT: A network of physical objects capable of sensing, processing, communicating or acting.

Edge computing: Processing and analysis performed near the source of data or control.

Cyber-physical system: An integrated system in which computation and communication interact with physical processes.

Operational technology: Hardware and software used to monitor or control physical operations.

Industrial IoT: Application of IoT technologies to industrial assets and processes.

Sensor: A component that detects and measures a physical condition.

Actuator: A component that produces a physical action in response to a control signal.

Gateway: An intermediary that connects devices or networks and may translate protocols or enforce policy.

Firmware: Software stored on a device that controls its hardware functions.

Secure boot: A process that permits execution only of authenticated and authorized startup software.

Hardware root of trust: A protected hardware foundation for cryptographic identity and verification.

Device identity: A unique, verifiable representation of a device.

Attestation: Evidence about the identity or software state of a device.

Provisioning: The controlled enrollment of a device, including identity, credentials and configuration.

Operational technology: Systems that directly monitor or control physical equipment and processes.

SCADA: A system for supervisory monitoring and control of geographically distributed processes.

PLC: A programmable industrial controller used to execute control logic.

Digital twin: A digital representation of a physical asset or process.

Software bill of materials: An inventory of software components and dependencies in a product.

Secure decommissioning: The controlled retirement of a device, including access revocation and data removal.

Review Questions

Short Answer Questions

1. How does edge computing alter the security boundary of an IoT system?

2. Why is device identity preferable to shared passwords in a large IoT deployment?

3. What is the purpose of secure boot?

4. Why can encryption alone not guarantee that a control command is safe?

5. Identify two security tasks that must occur during device decommissioning.

Long Answer Questions

1. Explain the architecture of an IoT-enabled cyber-physical system and discuss the security responsibilities of sensors, gateways, edge nodes and cloud platforms.

2. Discuss the complete lifecycle of IoT security from manufacture and provisioning to updates and retirement.

3. Compare the security and operational challenges of IT systems, IoT environments and OT networks.

4. Explain how segmentation, zero-trust principles and least privilege can be adapted to constrained or legacy devices.

5. Discuss why cybersecurity and safety engineering must be coordinated but not treated as identical disciplines.

Analytical / Application Questions

1. A factory uses legacy PLCs with unauthenticated protocols and a vendor gateway connected to the internet. Propose a prioritized risk-reduction plan that avoids unsafe interruption of production.

2. A smart-building platform reports occupancy data inconsistent with badge records and camera analytics. Analyze possible causes and recommend controls for identity, integrity, privacy and incident response.

3. During a ransomware incident, an organization considers disconnecting all remote pumps immediately. Evaluate this decision and design a safer containment and recovery approach.

22. Multiple Choice Questions with Answers

Question 1

Which characteristic most clearly distinguishes a cyber-physical system from a conventional information system?

A. It stores data in a relational database.

B. It links computational activity to physical processes through sensing and actuation.

C. It always uses a public cloud platform.

D. It requires a human operator for every action.

Correct Answer: B. It links computational activity to physical processes through sensing and actuation.

Question 2

A manufacturer wants to prevent unauthorized firmware from executing after a device restart. Which control is most directly relevant?

A. Network address translation

B. Data minimization

C. Secure boot

D. Packet compression

Correct Answer: C. Secure boot

Question 3

Why is a shared password for an entire fleet of IoT devices particularly dangerous?

A. It prevents all encryption from being used.

B. Compromise of one password can expose many devices and prevents precise accountability.

C. It makes firmware physically larger.

D. It automatically disables sensor readings.

Correct Answer: B. Compromise of one password can expose many devices and prevents precise accountability.

Question 4

A legacy PLC cannot authenticate commands. Which combination is the most appropriate compensating control?

A. Expose the PLC directly to the internet and rely on obscurity.

B. Use segmentation, controlled gateways, restricted access and monitoring.

C. Disable all safety systems permanently.

D. Replace every sensor with a cloud application.

Correct Answer: B. Use segmentation, controlled gateways, restricted access and monitoring.

Question 5

Why might abruptly disconnecting a compromised industrial controller be unsafe?

A. Controllers never affect physical processes.

B. Disconnection may interrupt control or safety functions and create a hazardous state.

C. Disconnection always increases confidentiality.

D. Industrial networks cannot be segmented.

Correct Answer: B. Disconnection may interrupt control or safety functions and create a hazardous state.

Question 6

Which activity best represents secure provisioning?

A. Installing every device with the same default credential

B. Enrolling a device with a unique identity, approved configuration and authorized ownership record

C. Allowing a device to select its own administrator

D. Deleting all device logs before installation

Correct Answer: B. Enrolling a device with a unique identity, approved configuration and authorized ownership record

Question 7

What is the principal security value of a software bill of materials?

A. It guarantees that software has no vulnerabilities.

B. It identifies software components and dependencies that may require assessment or updates.

C. It replaces the need for access control.

D. It encrypts all telemetry automatically.

Correct Answer: B. It identifies software components and dependencies that may require assessment or updates.

Question 8

An edge node continues local anomaly detection when cloud connectivity is lost. Which edge-computing benefit does this demonstrate?

A. Reduced dependence on centralized connectivity and lower response latency

B. Elimination of all physical attack risks

C. Automatic authorization of every command

D. Removal of the need for device identities

Correct Answer: A. Reduced dependence on centralized connectivity and lower response latency

Question 9

Which observation most strongly suggests manipulation rather than an ordinary sensor failure?

A. One sensor stops reporting and its power supply is disconnected.

B. A sensor reading conflicts repeatedly with valve position, flow and neighboring measurements.

C. A scheduled maintenance window begins.

D. A device reports a normal value at a normal interval.

Correct Answer: B. A sensor reading conflicts repeatedly with valve position, flow and neighboring measurements.

Question 10

What is a central lesson from the water-utility case?

A. Cloud dashboards should always be treated as ground truth.

B. Cybersecurity containment must be coordinated with operations and safety to preserve safe control.

C. Legacy protocols become secure when moved to a cloud platform.

D. Remote access should be shared among all vendors.

Correct Answer: B. Cybersecurity containment must be coordinated with operations and safety to preserve safe control.

Cloud, IoT and Enterprise Security
Chapter 10 of 15