ISO 27400 Lead Manager flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

IoT system definition

A system of interacting physical and digital components providing services through sensing, actuation, and communication. Security scope covers the entire system, including network, cloud services, and users, not only the devices.

Physical consequence of compromise

An exploited IoT actuator can cause injury, environmental damage, or safety incidents. Impact assessment must therefore include safety and physical harm alongside data confidentiality and availability losses.

Trust boundary in IoT

A point where data or control crosses between components with different trust levels, such as device to gateway or gateway to cloud. Each crossing requires authentication and authorization decisions.

Device constraint-driven security

Limited processing, memory, energy, and physical accessibility restrict which controls are feasible. Control selection must account for these limits and for device lifetimes often spanning ten to twenty years.

IoT lifecycle phases

Concept, development, production, deployment and operation, maintenance, and decommissioning. Security requirements apply at every phase, including destruction of keys and data at disposal.

Data minimization in IoT

Continuous sensor collection should be limited to data needed for the stated purpose. Linkability of sensor readings can re-identify individuals even after direct identifiers are removed.

Ecosystem security dependency

IoT security depends on network, cloud, mobile apps, supply chain, and users together. One weak component can undermine the whole system, so assessment must cover the ecosystem.

ISO/IEC 27400 control structure

The standard organizes security controls by area across device, communication, and system concerns. Controls are guidance to be selected and tailored through risk assessment, not a certification checklist.

Risk treatment options

Mitigate by applying controls, transfer through insurance or contracts, avoid by removing the function, or accept with documented accountability. Residual risk must be recorded and owned.

Secure boot control

A device verifies the cryptographic signature of its firmware at startup using a hardware root of trust, preventing execution of modified or unauthorized code even after physical or network tampering.

Mutual authentication

Both endpoints prove their identity before exchanging data, for example device to gateway and gateway to cloud. It prevents unauthorized devices joining and blocks impersonated backend services.

Network segmentation for IoT

IoT devices are placed in restricted network zones with allowlisted flows, so a compromised device cannot reach unrelated systems or move laterally into corporate infrastructure.

Least functionality principle

Each device exposes only the services, ports, and interfaces required for its role. Unused interfaces and debug functions are disabled to reduce the attack surface.

Defense in depth

Layered controls across physical, network, host, application, and data levels. No single control is assumed sufficient, especially for long-lived devices exposed to untrusted environments.

Supply-chain assurance

Requirements placed on component and device suppliers covering provenance, secure manufacturing, vulnerability disclosure, and duration of security update support, verified through contracts and evidence.

Planning context definition

Before control selection, define business purpose, system boundary, stakeholders, legal and regulatory obligations, and organizational risk appetite. These determine which risks and controls matter.

Policy versus standard

The security policy states objectives and mandatory intent. Supporting standards specify concrete technical baselines, such as required cryptographic algorithms or firmware signing rules, that implement the policy.

RACI for IoT security

A matrix assigning responsible, accountable, consulted, and informed roles across asset owners, engineering, security operations, suppliers, and executives. Accountability must name a person, not a team.

Asset inventory prerequisite

A catalogue of devices, firmware versions, network addresses, owners, and data classifications. Protection and monitoring cannot be planned for assets that have not been identified and classified.

Risk register contents

Each entry records the threat scenario, existing controls, likelihood, impact, treatment plan, named owner, and target date. It is reviewed at intervals and on significant change.

Security program metrics

Measurable objectives such as patch latency, percentage of devices on current firmware, and count of unmanaged devices. Metrics enable monitoring, comparison over time, and corrective action.

Supplier security requirements

Contract terms covering security requirements, vulnerability disclosure, incident notification timelines, and the duration of update support, agreed before procurement rather than after deployment.

Secure provisioning

Unique per-device credentials and keys generated in a trusted environment and injected before deployment. Shared or default credentials are prohibited, and keys rotate on compromise or at set intervals.

Signed firmware update

Updates are cryptographically signed and verified before installation, deployed in stages with rollback capability, and recorded so the firmware version of each device is auditable.

Administrative access control

Strong authentication and role-based authorization on administrative interfaces, with vendor maintenance accounts removed or disabled after commissioning to prevent persistent backdoor access.

IoT detection use cases

Monitoring rules for anomalous behavior such as unexpected outbound connections, repeated authentication failures, or configuration changes outside maintenance windows, each with defined alert thresholds.

Software bill of materials

An inventory of components and versions inside device firmware. It enables rapid identification of affected devices when a third-party vulnerability is disclosed and supports patch prioritization.

IoT containment actions

Incident response steps specific to devices: network isolation, remote disable, credential revocation, and firmware rollback, coordinated with safety and operations teams when physical processes are affected.

Monitoring scope

Technical telemetry such as logs, alerts, and health metrics, plus compliance indicators like control coverage and risk indicators such as open vulnerabilities and overdue patches.

Review cadence

Continuous operational monitoring, management review at planned intervals, and full risk reassessment on significant change such as new firmware architecture, new supplier, or new integration.

Continual improvement cycle

Plan-Do-Check-Act: measure performance against objectives, identify gaps, implement corrective actions, then verify effectiveness in the next cycle. Metrics are trended, not viewed as snapshots.

Secure decommissioning review

Confirm destruction of data and keys, removal from inventory and monitoring, and migration of dependent services, so unsupported devices do not remain deployed and unmanaged.