概要
- 各国・標準化団体のIoTデバイスのセキュリティ関連仕様・法整備
日本
総務省
１．ＩｏＴ機器を含む端末設備のセキュリティ対策に関する技術基準の整備
インターネットプロトコルを使用し、電気通信回線設備を介して接続することにより、電気通信の送受信に係る機能を操作することが可能な端末設備について、最低限のセキュリティ対策として、以下の機能を具備することを技術基準に追加することが適当。
①アクセス制御機能※1、
②アクセス制御の際に使用するID/パスワードの適切な設定を促す等の機能、
③ファームウェアの更新機能※1、又は①～③と同等以上の機能※2
※1 端末への電力供給が停止した場合でも、これらの機能の維持が必要。
※2 同等以上の機能を持つものとしては、国際標準ISO/IEC15408に基づくセキュリティ認証(CC認証)を受けた複合機等が含まれる。
経済産業省
特にCPS.DS-8では下記のように耐タンパーデバイスの利用を強調。
グルーバル
ISO/IEC 62443
下記のEDRで耐タンパー要件(Physical tamper resistance and detection)
GSMA
US NIST
Europe ETSI
ETSI TS 103 645の基本要件 (ETSI TS 103 645は2020年ETSI EN 303 645として改定)
Chap 4 Cyber security provisions for consumer IoTで下記の項目を言及。13の大項目、37項目
4.1 No universal default passwords
- Provision 4.1-1 All IoT device passwords shall be unique and shall not be resettable to any universal factory default
value.
4.2 Implement a means to manage reports of vulnerabilities
- Provision 4.2-1 Companies that provide internet-connected devices and services shall provide a public point of contact
as part of a vulnerability disclosure policy in order that security researchers and others are able to report issues.
- Provision 4.2-2 Disclosed vulnerabilities should be acted on in a timely manner.
- Provision 4.2-3 Companies should continually monitor for, identify and rectify security vulnerabilities within products
and services they sell, produce, have produced and services they operate as part of the product security lifecycle.
4.3 Keep software updated
- Provision 4.3-1 All software components in consumer IoT devices should be securely updateable.
- Provision 4.3-2 The consumer should be informed by the appropriate entity, such as the manufacturer or service
provider, that an update is required.
- Provision 4.3-3 When software components are updateable, updates shall be timely.
- Provision 4.3-4 When software components are updateable, an end-of-life policy shall be published for devices that
explicitly states the minimum length of time for which a device will receive software updates and the reasons for the
length of the support period. This policy shall be published in an accessible way that is clear and transparent to the
consumer.
- Provision 4.3-5 When software components are updateable, the need for each update should be made clear to
consumers and an update should be easy to implement.
- Provision 4.3-6 When software components are updateable, updates should, where possible, maintain the basic
functioning of the device, which can be critical to remain available during an update.
- Provision 4.3-7 When software components are updateable, the provenance of software updates should be assured and
security patches should be delivered over a secure channel.
- Provision 4.3-8 For constrained devices that cannot have their software updated, the product should be isolable and the
hardware replaceable.
- Provision 4.3-9 For constrained devices that cannot have their software updated, the rationale for the absence of
software updates, the period of hardware replacement support and an end-of-life policy should be published in an
accessible way that is clear and transparent to the consumer.
4.4 Securely store credentials and security-sensitive data
- Provision 4.4-1 Credentials and security-sensitive data shall be stored securely within services and on devices. Hard-coded credentials in device software shall not be used.
Reverse engineering of devices and applications can easily discover credentials such as hard-coded usernames and passwords in software. Simple obfuscation methods also used to obscure or encrypt this hard-coded information can be trivially broken. Secure, trusted storage mechanisms can be used to secure security-sensitive data, such as those provided by a Trusted Execution Environment (TEE) and associated trusted, secure storage, or the secure storage and processing capabilities of software running on a Universal Integrated Circuit Card UICC/embedded Universal Integrated Circuit Card (eUICC).
4.5 Communicate securely
- Provision 4.5-1 Security-sensitive data, including any remote management and control, should be encrypted in transit, with such encryption appropriate to the properties of the technology and usage.
- Provision 4.5-2 All keys should be managed securely.
The use of open, peer-reviewed standards is strongly encouraged.
4.6 Minimize exposed attack surfaces
- Provision 4.6-1 Unused software and network ports should be closed.
- Provision 4.6-2 Hardware should not unnecessarily expose access to attack (e.g. open serial access, ports or test points).
- Provision 4.6-3 Software services should not be available if they are not used.
- Provision 4.6-4 Code should be minimized to the functionality necessary for the service/device to operate.
- Provision 4.6-5 Software should run with least necessary privileges, taking account of both security and functionality.
4.7 Ensure software integrity
- Provision 4.7-1 Software on IoT devices should be verified using secure boot mechanisms, which require a hardware root of trust.
- Provision 4.7-2 If an unauthorized change is detected to the software, the device should alert the consumer and/or
administrator to an issue and should not connect to wider networks than those necessary to perform the alerting
function.
4.8 Ensure that personal data is protected
- Provision 4.8-1 Device manufacturers and service providers shall provide consumers with clear and transparent information about how their personal data is being used, by whom, and for what purposes, for each device and service.
This also applies to third parties that can be involved, including advertisers.
- Provision 4.8-2 Where personal data is processed on the basis of consumers' consent, this consent shall be obtained in a valid way.
- Provision 4.8-3 Consumers who gave consent for the processing of their personal data shall be given the opportunity to withdraw it at any time.
4.9 Make systems resilient to outages
- Provision 4.9-1 Resilience should be built in to IoT devices and services where required by their usage or by other relying systems, taking into account the possibility of outages of data networks and power.
- Provision 4.9-2 As far as reasonably possible, IoT services should remain operating and locally functional in the case of a loss of network and should recover cleanly in the case of restoration of a loss of power.
- Provision 4.9-3 Devices should be able to return to a network in an expected, operational and stable state and in an orderly fashion, rather than in a massive-scale reconnect.
4.10 Examine system telemetry data
- Provision 4.10-1 If telemetry data is collected from IoT devices and services, such as usage and measurement data, it should be examined for security anomalies.
- Provision 4.10-2 If telemetry data is collected from IoT devices and services, the processing of personal data should be kept to a minimum and such data should be anonymized.
- Provision 4.10-3 If telemetry data is collected from IoT devices and services, consumers shall be provided with information on what telemetry data is collected and the reasons for this.
4.11 Make it easy for consumers to delete personal data
- Provision 4.11-1 Devices and services should be configured such that personal data can easily be removed from them when there is a transfer of ownership, when the consumer wishes to delete it, when the consumer wishes to remove a service from the device and/or when the consumer wishes to dispose of the device.
- Provision 4.11-2 Consumers should be given clear instructions on how to delete their personal data.
- Provision 4.11-3 Consumers should be provided with clear confirmation that personal data has been deleted from services, devices and applications.
4.12 Make installation and maintenance of devices easy
- Provision 4.12-1 Installation and maintenance of IoT devices should employ minimal steps and should follow security best practice on usability. Consumers should also be provided with guidance on how to securely set up their device.
- Provision 4.13-1 Data input via user interfaces and transferred via application programming interfaces (APIs) or between networks in services and devices shall be validated.
その他リンク
