ISO 27400 Foundation flashcards

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

IoT system layers

Reference structure of device, gateway/edge, network, cloud/service, and application/user layers. Security and privacy controls are required at each layer and at the interfaces connecting them.

Constrained device

An IoT endpoint with limited processing power, memory, energy, or bandwidth. Controls must be lightweight and proportionate, such as secure boot, hardware key storage, and efficient cryptography.

Privacy by design

Approach embedding privacy into system architecture from the outset, with defaults that protect data, end-to-end security, transparency, and respect for user privacy throughout the lifecycle.

Data minimisation

Principle that only personal data adequate, relevant, and necessary for a stated purpose is collected and processed. In IoT it limits sensor collection to what the function actually requires.

Purpose limitation

Personal data collected for one stated purpose is not reused for incompatible purposes without a lawful basis. IoT operators must define and document purposes before deployment.

Defence in depth

Layering independent controls so failure of one does not compromise the whole system. Assumes any single device or layer may be breached and limits the resulting impact.

Least privilege

Granting each user, service, and device only the access rights needed for its function, reducing the impact of compromise or misuse across an IoT deployment.

Security properties

Confidentiality, integrity, availability, authenticity, accountability, and non-repudiation. IoT designs must state which properties apply to each data flow and interface.

IoT lifecycle security

Security obligations across concept, development, production, deployment, operation, maintenance, and decommissioning. Includes patching during operation and secure erasure of credentials at disposal.

Risk-based control selection

Choosing safeguards according to identified threats, vulnerabilities, likelihood, and impact, considering device role, environment, and data sensitivity rather than applying a fixed checklist.

Fail-safe defaults

Design rule that access is denied and systems enter a safe state when a failure occurs. Unused ports, services, and accounts are disabled by default.

Transparency to users

Requirement that operators inform users and bystanders about what data IoT devices collect, why, how long it is kept, and with whom it is shared.

Storage limitation

Personal data is kept only as long as needed for the stated purpose. IoT logs, sensor histories, and metadata require defined retention periods and deletion procedures.

Accountability principle

The operator must be able to demonstrate compliance with security and privacy requirements through policies, records, audits, and assigned responsibilities across the IoT system lifecycle.

Bystander data capture

Collection of data about people who did not choose to interact with a device, such as cameras or presence sensors. Requires notice, minimisation, and strong justification.

Default credentials

Factory-set usernames and passwords shared across devices. They are a leading IoT weakness and must be replaced by unique per-device credentials or forced change at provisioning.

Hard-coded credentials

Credentials embedded in firmware that cannot be changed. They enable mass compromise once extracted and should be replaced by hardware-protected keys or secure provisioning.

Secure boot

Boot process that verifies the integrity and authenticity of firmware using cryptographic signatures anchored in hardware, preventing execution of unauthorised or tampered code.

Signed firmware update

Update mechanism where the vendor signs firmware and the device verifies the signature before installation, blocking malicious or corrupted images and supporting rollback protection.

Mutual authentication

Both device and server prove their identities, typically with certificates, before exchanging data. Prevents unauthorised devices joining and impersonation of backend services.

Man-in-the-middle attack

Attacker intercepts and possibly alters communication between device and server. Mitigated by TLS/DTLS, certificate validation, and protected key storage on the device.

Replay attack

An attacker retransmits previously captured valid messages to trigger actions. Countered by nonces, timestamps, sequence numbers, and session freshness checks.

Denial of service

Attack or failure that makes device or service unavailable, for example by flooding or exhausting battery. Controls include rate limiting, filtering, and graceful degradation.

Network segmentation

Placing IoT devices on separate network zones with restricted traffic to other systems. Limits lateral movement when a device is compromised and reduces exposure of critical assets.

Attack surface reduction

Disabling unused ports, services, debug interfaces, and accounts so fewer entry points remain exploitable. Applied at manufacture and maintained through configuration control.

Re-identification risk

Risk that pseudonymised or aggregated IoT data is linked back to individuals using metadata, location patterns, or auxiliary datasets. Addressed by anonymisation and access limits.

Pseudonymisation

Replacing direct identifiers with tokens so data cannot be attributed to a person without additional separately protected information. Reduces exposure but is not full anonymisation.

Edge processing

Analysing or filtering data close to the sensor before transmission. Reduces data volume in transit, supports minimisation, and lowers privacy exposure from central storage.

Tamper detection

Physical controls that reveal or respond to unauthorised access to a device, such as seals or sensors that erase keys when the enclosure is opened.

Secure provisioning

Process of injecting unique identities, keys, and configuration into devices in a controlled environment, ensuring no shared secrets and verifiable device authenticity at first connection.

Vulnerability disclosure

Documented channel and process for researchers to report flaws and for the vendor to remediate and inform users. Supports coordinated patching during the device support period.

Audit logging

Recording security-relevant events such as access, configuration changes, and failures. Logs support detection and accountability but must be protected and retention-limited.

Supply chain risk

Threat that third-party components, firmware, or manufacturers introduce vulnerabilities or malicious code. Addressed by provenance checks, component inventory, and supplier assurance.