はじめに

ETSI EN 303 645 は欧州の規格制定団体ETSIが作成した、民生用IoT機器のサイバーセキュリティについての欧州規格です。現在のところは国際規格でなくEUローカルの規格なのですが、次のような理由でご紹介します。

IoT機器のサイバーセキュリティの設計指針として要点を得た規格になっている
IoT機器のためのセキュリティ規格であるが、IoT機器に限らずいろいろな機器でも参考にできる要素が多い
セキュリティ要件が比較的具体的に書かれてるのでわかりやすい。コモンクライテリアなんか訳わかんねーよって方も安心
世間の、特にEUではどのレベルのサイバーセキュリティ対策が求められているかの相場観がつかめる。(結構レベルが高いです。とはいえ、超大手のICT企業だったらこれくらいはクリアできてるよ、っていうくらいのレベル)
EU のサイバーセキュリティ法(Regulation EU 2019/881)や UK の製品セキュリティ及び通信インフラ法(PSTI)により、近い将来EUとUKで販売されるIoT機器とサービスにはこの規格が法律上の強制になると見込まれている。
規格書って値段が高く1部数万円するものがザラにありますが、これはなんとタダ。（ETSIが作るEN規格はどれも無料です）

規格原文の入手方法

最新版はetsi.orgのサイトから無料で入手できます。"ETSI EN 303 645 pdf" で検索してみてください
2023年3月時点の最新版は V2.1.1 です。

★ 2023/3/11追記
IPAが規格の和訳を公開しました！ ありがとうIPA！

あとで取り上げる、EN 303 645のための技術仕様書 (虎の巻) ETSI TS 103 701の最新版はV1.1.1です。

この記事の用語について

お急ぎの方はここをすっ飛ばして、先にお進みください

EU法： EU指令、EU規則のようにEU加盟国で強制力を持つルール。
暗号化プリミティブ Cryptographic primitive：暗号システムで使用する、基礎的なレベルのアルゴリズムのこと。具体的にはハッシュ関数や対称暗号関数(AES, DES)、非対称暗号、デジタル署名技術などの要素技術を指します。
関連するサービス associated services: 民生用IoT機器とともに提供される各種サービスのこと。例えば心拍数を測定してクラウドに送信する機能を有するIoT機器と心拍データを使った健康管理サービスがあったとして、健康管理サービスを提供している者が機器の製造者か製造者が指定するサードパーティである場合、この健康管理サービスは機器とともに提供される"関連するサービス"となります。機器製造者と関係ない者が作成した健康管理サービスは関連するサービスと見なされません。この用語が問題になる場合は、本規格書3.1の2番目の用語定義を参照してください。
クリティカルなセキュリティパラメーター Critical Security Parameter (CSP)：開示されることや変更されることが暗号モジュールに危機を与えうるパラメーターのことです。一般的な例でいうと、暗号鍵やパスワードやPINなどの相手確認データ、認証データ。
攻撃対象領域 attack surfaces：相手確認されていない者がシステムに攻撃可能なあらゆる部分の集合。ハッカーが攻撃する点っていうと、パスワードの入力画面やソフトウェアのセキュリティホールなんかが初めに思いつくと思いますが、設定のミスや内部関係者へのソーシャルハックなどあらゆる攻撃点が考慮すべき対象となります。
個人データ Personal data： "個人情報"のことです。EU法での "personal data" と日本の個人情報保護法における"個人情報"には少しズレがあるので、本記事では"個人情報"という語ではなく"個人データ"という語を使います
個人データ保護法 GDPR：個人データの保護を目的としたEU法の GDPR; General Data Protection Regulation 規則 2016/679は、そのまま日本語に訳すと"一般データ保護規則"なのですが、本文書では通称である"個人データ保護法"を使います。
コモンクライテリア Common Criteria, CC: 「情報システムのセキュリティ要件の作成と運用が決められた手順で実施できているかどうかを評価するための規格」です。EN 303 645のような「特定の情報システムに対してセキュリティが十分であるかどうかの評価項目を列挙する」という規格とは性格が異なります。EUサイバーセキュリティ法のための認証スキームでは、認証の評価はCCに基づくことになっていますが、EUサイバーセキュリティ庁(ENISA)によれば「CCと評価方法(IEC 62443-2, EN 303 645など)は互いに競合するのではなく補完的なものである」とのことです。
製造者： Manufacturer の訳です。OEMの場合は製品を実際に製造する者ではなく製品にブランドを与えて販売する者が製造者です。IoT機器がEU外で製造されている場合は、EUの輸入業者も製造業者になりえます。
制約された機器 Constrained device：「データを処理する能力、データを通信する能力、データを保存する能力、またはユーザーと対話する能力のいずれかに物理的な制限がある機器」のことです。もう少し具体的にいうと、プロセッサーの能力が低い機器や少容量メモリ機器のことですが、低機能なり少容量なりの基準が数値で定義されてるわけではありません。
セキュリティ研究者 security researcher：文字通り、セキュリティを研究している人のことです。セキュリティ研究者の仕事の一つに脆弱性の発見としかるべき組織への報告があります。いわゆるホワイトハッカーですね。一方で発見した脆弱性を悪用したりブラックマーケットに流すセキュリティ研究者＝ブラックハッカーもいます。脆弱性情報がブラックマーケットに流されないために、脆弱性報告にはほどほど高額な報酬を払わなければならないと考える企業が海外では増えています。
認可： Authorization の訳です。権限を与えるという意味
(相手)確認： Authentication の訳です。二者の間で互いに相手が誰かを確認するという意味。"認証"と訳されることが多いですが、本文書では Certification と区別するために"確認"と訳します。
認証： Certification, Certificate の訳です。互いが正当な相手であるかどうかを第三者を通じて確認するという意味

EN 303 645の構成

EN 303 645 の概要を知るには、目次を見るのが手っ取り早いと思います。
目次のタイトルと、どんなことが書かれているかを下記に示します。

序文
　規格の成立背景などが書かれています
1章適用範囲
　この規格の対象は何なのかが記されています。対象はもちろん民生用のIoTデバイスです。具体例として、ネットに繋がっているホームオートメーション機器、家電機器、玩具などが挙げられてますが、この例に限定されないこと、またIoT機器と関連するサービスの相互作用は規格の対象だが関連するサービスそのものは規格の対象外であること、 といったことが書かれています。
　なお、機器の製造者と無関係のサードパーティがIoT機器のために作ったサービスは、この規格の対象にならないとはいえEUに上市するときはサイバーセキュリティ法や個人データ保護法(GPDR)などの対象になるので、セキュリティを確保することや個人データ漏えいなどのセキュリティアクシデント発生時に当局への報告義務があることにはご留意ください。(EUではサービスを無料で提供する場合でも、サービス提供の条件として個人データの商用利用を要求するなら上市するとみなされる事にも注意してください指令 (EU) 2019/770)
2章参考文献
3章用語定義
4章レポートの書き方
　ある製品がこの規格に適合するかどうかを判定するレポートの書き方が示されています
5章民生用IoT機器のサイバーセキュリティ規定
　本規格のキモとなるパートで、セキュアなIoT機器に求められる 13 の要求が列挙されています。
　本文書は Qiita の中では長文ですが、ここの13項目の概要さえ読んでおけば「EN 303 645っていうのはだねえ」と人にウンチクを傾けることができるようになります。たぶん。
- 5.1 共通のデフォルトパスワードは設けないこと
  　もしIoT機器に初期パスワードを設定するなら機器ごとに完全にランダムなものを割り当てましょう
- 5.2 脆弱性の管理報告手段を実装すること
  　セキュリティ専門家などが脆弱性を報告してきた時にどうするかのルールを作るとともに、外部からの脆弱性報告を受け付ける窓口を公開しましょう
- 5.3 ソフトウェアのアップデートを続けること
  　機器のサポート期間を告知して、その間はセキュリティアップデートを提供しましょう
- 5.4 機密性の高いセキュリティパラメーターは安全に保存すること
  　大事なパラメーターやセキュリティ上のパラメーターは、保護されたストレージやメモリに置きましょう
- 5.5 安全に通信すること
  　通信には適切な暗号を使いましょう
- 5.6 外部にさらされる攻撃対象領域を最小限とすること
  　攻撃対象領域は最小化しましょう
- 5.7 ソフトウェアの整合性を確保すること
  　不正なソフトウェアが入る隙がないように、セキュアなブートとセキュアなアップデートをするとともに改ざん検出もしましょう
- 5.8 個人データは確実に安全にすること
  　個人データの守りを確実にするとともに、IoT機器に備わっているセンサーの機能をユーザーに明示しましょう
- 5.9 停止から回復力のあるシステムを作ること
  　停電やネットワーク障害から自動で復帰できるシステムを設計しましょう
- 5.10 通信データの検査をすること
  　攻撃されていないかどうかのチェックをしましょう
- 5.11 ユーザーが簡単にユーザーのデータ消去を行えること
  　ユーザーが個人データの消去を要求をしてきたら速やかに対応しましょう(EU個人データ保護法の要求)
- 5.12 機器へのインストールとメンテナンスが容易であること
  　ユーザーのミスを防ぐため、判りやすいUIとマニュアルを提供しましょう
- 5.13 入力データは検証すること
  　攻撃からの防御のため、データはバリデートしましょう
6章民生用IoT機器の個人データ保護規定
　IoT機器が個人データを扱う際の規定が書かれている。内容は後述の表を参照してください
附属書A(情報) 基本の考え方とモデル
　スマートスピーカーなどを実例にしたこの規格の解説
附属書B(情報) 基本の考え方とモデル
　機器の設計者がこの規格に適合していることを確認するための表。本規格の各要求が命令か、強い推奨かの一覧も書かれている。なお、この規格への適合性を本気で確認するなら ETSI TS 103 701 という技術仕様書の参照が必須です。

５章「民生用IoT機器へのサイバーセキュリティ要求」の要約

この章はコンメンタールのような形式で記述しようと思ったのですが、EN 303 645は無料公開されているとはいえ著作物で、全文訳の公開はよろしく無い感じなので、キモとなる部分の要訳を私のコメントと合わせて表にまとめることとしました。
この章では規格の要約を紹介しますが、私の誤訳や誤解も多々あるはずなので、眉に唾を付けて読んでください。要約の文章で、命令形(〜すること。〜ねばならない。〜してはならない。)と強い推奨(〜べきだ。〜するべきではない。)が混在していますが、これは私が適当に翻訳してるからではなく、原文のshall, shall notを命令形、原文のshould, should notを強い推奨に訳しているからです。
規格の全文和訳はIPAにより公開されています。

		規格の要訳	コメント
5	民生用IoT機器のサイバーセキュリティ規定
5.1	共通のデフォルトパスワードは設けないこと (5.1-1 〜 5.1-5)
		機器のパスワードとして、共通のデフォルトパスワードを設定してはならない。機器ごとに異なるデフォルトパスワードを設定する場合でも、MACアドレスを使うような第三者に推定可能なものであってはならず、個体ごとに完全にランダムでなくてはならない。機器にデフォルトパスワードを割り当てなくとも、機器がユーザーの確認をする手段は存在し、例えば機器の初期化の際に関連するモバイルのサービスを利用して証明書を作成するような方法もある。機器の相手確認の方法としては、"NIST Special Publication 800-63B ”が推奨される。なお、機器がユーザーを相手確認する機構においては、最善の暗号化をすることが必要で、かつ相手確認のトークン(パスワードや指紋情報)が容易に変更できるようになっていなければならない。機器が"制約のある機器”では無いなら、相手確認はネットワーク越しのブルートフォース攻撃を無効化する機構を備えること。DDoS攻撃への耐性も重要である。	この条項の規定は特に難しいところはないと思います。昔、外部からアクセスする時のデフォルトパスワードが一律だったためハッキングされ放題だった監視カメラがありましたが、さすがに今ではそんなものはないでしょう。 NIST SP 800-63Bという文書が引用されていますが、NIST SP 800 シリーズというのは米国の国立標準技術研究所が発行しているセキュリティガイドライン群のことで、63B は電子認証に関するガイドラインです。NIST SP 800シリーズは、ググればこの 63B を含めて主要な文書を日本語の翻訳や解説文書をネットで読むことが可能です。相手確認のブルートフォース攻撃を無効化する機構とは、誤ったパスワード入力の数が増えたら応答時間を長くしていくとかいう手法のことです。
5.2	脆弱性の管理報告手段を実装すること (5.2-1 〜 5.2-3)
		製造者は少なくとも以下を含んだ脆弱性開示のポリシーを公開すること。・問題を報告するための連絡先情報・以下のタイムラインに関する情報　　1) 最初の受領確認　　2) 報告された問題が解決されるまで、状況の更新製造者は公開された脆弱性にタイムリーに対処するべきで、また製品のサポート期間中は脆弱性の監視や対応に当たるべきである。対応すべき脆弱性の対象は、オープンソースやサードパーティ製のソフトウェアコンポーネントを含む製品全てである。タイムリーな対処とは一般的には90日以内であるが、ハードの修正が必要な場合はより日数がかかるかもしれない。	どこの会社もISO 9001等の規格に基づいたマネジメントシステムを導入していると思いますが、脆弱性に対するポリシーをマネジメントシステムに組み込んでいない企業は今後は市場から退場していただくしか無い...っていうのが現在のEU規制当局の姿勢です。これはサイバーセキュリティ指令だけの要求ではなく、今後発行されるNIS2指令などでも同じです。 IoT機器をEUに上市するなら、セキュリティ研究者からの脆弱性報告を受け付ける体制を構築して、脆弱性窓口を公開するくらいは当然、というレベルのセキュリティ体制づくりが要求されるわけです。脆弱性の報告と情報公開に関してISO 29147、脆弱性の調査と対策には ISO 30111 という国際規格もあります。
5.3	ソフトウェアのアップデートを続けること (5.3-1 〜 5.3-16)
		IoT機器の全てのソフトウェアコンポーネントが変更可能であるわけではないが(ブートローダーの第一ステージなど)、それ以外は安全な方法でソフトウェアアップデートが可能であるべきだ(5.3-1)。また、制約された機器でないなら、アップデートを安全にインストールするための機構も備えなくてはならない(5.3-2)。本規格は次のようなアップデートを要求する。・ユーザーにとってシンプルであること(5.3-３) ・自動で行われるべき(5.3-4) ・機器を初期化する際にはセキュリティアップデートがあることを確認するべき(5.3-5) ・アップデートの有効、無効、延期をユーザーが選択できるべき(5.3-6) ・アップデートの機構に最も最適な暗号を採用すること(5.3-7) ・タイムリーなセキュリティアップデートを実施すること(5.3-8) ・機器はアップデートをするにあたり、相手が誰かの信頼性と整合性を確認するべき(5.3-9) ・ネットワーク越しのアップデートでは、機器は更新の信頼性と整合性を確認すること(5.3-10) ・製造者はセキュリティアップデートが必要なことをユーザーに通知すべき(5.3-11) ・アップデートの最中に機器の基本機能が停止するならそのことを通知すべき(5.3-12) ・製造者は機器のサポート期間をユーザーに公開すること(5.3-13) ・制約のある機器で、ソフトウェアのアップデートができない場合は、製造者はハードウェアのサポート期間と方法を公開すべき(5.3-14) ・制約のある機器で、ソフトウェアのアップデートができない場合は、機器は分割して交換ができるようになっているべき(5.3-15) ・民生用IoT 機器は、モデル名をラベルなどに表記するか物理的なインターフェイスでモデル名を認識できるようになっていること(5.3-16)。	5.3はEN 303 645の中で一番ボリュームの多いパートで、上市するIoT機器はセキュリティアップデートをしなさいという趣旨の規定です。ソフトでのセキュリティアップデートができないような、制約された機器であってもセキュリティサポートは強く推奨されています(5.3-14, 5.3-15)。制約された機器でないならソフトウェアの安全なアップデートは義務です(5.3-2)。アップデートは自動で行われることが求められていますが(5.3-4)、アップデートの無効や延期をユーザーに選択させることも要求(5.3-6)であることに注意してください。ユーザーがアップデートを拒絶することには十分な理由があるとされています。製造者はアップデートをお願いすることはできますが強制はできません。(ダウングレードの防止は製造者に認められています) セキュリティアップデートと別目的のアップデートを一緒に行うことは禁止されてませんが、別々にすることが推奨されてます(5.3-4)。アップデートは自動で行われることが要求されてますが、アップデートが失敗して機器が文鎮化することを避けるため、ウォッチドッグや二重フラッシュメモリーまたはリカバリパーテーションを用いた復旧機構の実装が期待されています(5.3-4)。アップデートそのものがセキュアであることも要求事項です。具体的にどのように実装するかは条文のコメントとして挙げられています。セキュリティサポート期間を設定することが強く推奨されています(5.3-13)が、本規格でいう”サポート期間”は製品保証などの意味でのサポート期間とは異なります(3.1の11番目)。ちなみにEUでは Directive (EU) 2019/770と 2019/771 により、エンドユーザーが機器を買った日から2年間のソフトウェアサポートは最低限の義務です。機器のカテゴリによってはそれ以上のサポート期間を要求する法律もあります機器のモデル名が識別できるようになっていることが義務ですが(5.3-16)、これはそのモデルがセキュリティサポートの対象であるかどうかをユーザーやセキュリティアップデートサービスに識別させることが目的です。ソフトウェアアップデートに関する要求は他の条項にも記載があります。(5.4, 5.9, 5.10, 5.12 など)
5.4	機密性の高いセキュリティパラメーターは安全に保存すること (5.4-1 〜 5.4-4)
		機密性の高いセキュリティパラメーターは安全なストレージに保存すること。具体例でいうと、信頼された実行環境(TEE; Trusted Execution Environment)もしくはハードウェアの暗号ストレージもしくはセキュアエレメンツ(SE; Secure Elements)もしくは専用のセキュリティコンポーネント(DSC; Dedicated Security Components)、UICC(Universal Integrated Circuit Card)などである。ストレージだけではなくメモリ上のセキュリティパラメータも同様の保管が可能である。機器に物理的に書き込まれる一意のIDをセキュリティ用途で使用する場合も、物理的、電気的、ソフト的な改ざん防止が必要である。機器のソフトにクリティカルなセキュリティパラメーターをハードコードしてはならず、資格情報はリモートや物理的保護を用いたAPIなどで管理すること。単純な難読化は簡単に突破される。ソフトウェアアップデートの整合性チェックに使用するクリティカルなセキュリティパラメーターをグローバルにすると、それが開示されてしまった場合に大規模な攻撃の原因となってしまうので、機器毎にユニークなものとすること。	攻撃者が容易にアクセスできる領域に重要なセキュリティパラメーターを置くなという要求です。特にパスワードや暗号鍵(公開鍵は重要なセキュリティパラメーターではない)は絶対に攻撃者がアクセスできるところにハードコードしてはならないということです。単純な難読化は安全な保管だとはみなされていません(5.4-3)。文中の、"信頼された実行環境”, "セキュアエレメンツ”, "DSC", "UICC” はセキュリティ用語です。 5.6では、ハードウェアによるメモリのアクセス制御機構、5.7ではセキュアブートが要求されています。機器に使用するマイコンや周辺チップは一定水準のセキュリティ機能を有するものを選択する必要があります。
5.5	安全に通信すること (5.5-1 〜 5.5-8)
		民生用IoT機器は最善の暗号を使って安全に通信をすること。場合によっては実装に対してレビューを実施すべきである。暗号のアルゴリズムや暗号化プリミティブは更新可能であるべきだが、更新ができない機器では意図された寿命が暗号アルゴリズムの寿命(鍵のサイズとか)を超えないようにすることが重要である。初期化後のネットワークのアクセスは相手確認をした後にすべきである。またセキュリティに関する変更の前には相手確認をしなければならない。(ARP,DHCP, DNS, ICMP, NTPプロトコルは相手確認不要) クリティカルなセキュリティパラメーターを通信する時は技術、リスク、使われ方を考慮した暗号化をすべきである。また製造者はクリティカルなセキュリティパラメーターをセキュリティマネジメントの手続きに従って管理すること。(公開・レビューされた規格を使うことが強く勧められる)	適切な強度の暗号を選択せよという規定です。暗号化プリミティブは更新可能であることが要求(強い推奨)されていますが、暗号化プリミティブの更新なんか想定していないシステムって多いのではないでしょうか。その場合、製品寿命の間には破られることが無いと予想される暗号アルゴリズムを使用することが示唆されています。 RSA暗号やECC暗号は10年位したら量子コンピューターで破られるという予想は考慮しないといけないかもしれません。
5.6	外部にさらされる攻撃対象領域を最小限とすること (5.6-1 〜 5.6-9)
		未使用のネットワークと論理インターフェイスは全て無効にすること。機器の初期化状態では、ネットワーク越しに開示するセキュリティに関する情報は最小限に抑えること。機器は物理的なインターフェイスを攻撃にさらさないようにすべきであり、物理的にアクセスできるデバッグインターフェイスはソフト的に無効にしなければならない。機器上で動かすソフトウェアサービスは、必要最小限に抑え、機器に含まれるコードは機器とサービスが動作する最小に抑えるべきである。ソフトウェアは最小限の特権で実行させるべきである。機器はハードウェアによるメモリのアクセス制御機構を有するべきである。製造者は機器のソフトウェアを開発するに当たって安全な開発プロセスを採用すべきである。	"攻撃対象領域”はセキュリティ用語。内容は特にややこしくないと思います。とはいえ、実装には気をつけなくてはなりません。有効になっているデバッグインターフェイスにアクセス可能な機器って世間にたくさんあるような...
5.7	ソフトウェアの整合性を確保すること (5.7-1 〜 5.7-2)
		民生用IoT機器はセキュアブートの機構を利用してソフトウェアの検証をすべきである。ソフトウェアに不正な変更を検出した場合、機器はユーザーや管理者に問題を警告するべきであるが、警告機能のために必要なネットワークよりも広いネットワークへの接続は避けるべきである。	一般的に、ソフトウェアの整合性(Integrity)は、セキュアブートとセキュアなアップデートによって確保されると考えられています。機器のブートは“信頼性の起源(Root of trust)”であるので、ソフトウェアの改ざんがなされていないことを検証するセキュアブートの機構を含めましょう、というのが5.7-1の要求です。検出したソフトウェアの改ざんを通知することも要求です。
5.8	個人データは確実に安全にすること (5.8-1 〜 5.8-3)
		機器とサービスの間で転送される個人データの機密性は最善の暗号で保護すべきで、特にセンシティブな個人データの機密性を保護する暗号は技術の特性や用途を考慮しなければならない。機器の全ての外部センサーの機能はユーザーにとって明確で判りやすく入手しやすい方法で文書化すること。	日本のように個人情報保護の規制が緩い国だったら手を抜いて良いと主張する気は毛頭ないのですが、もし製品をEUに上市するなら、個人データの保護には最大限の配慮が必要です。規定5.11と6も参照してください。どんなセンサーでも内蔵していることと機能をマニュアルやカタログとかでユーザーに伝える必要があります。機器がマイクやGPSのようなセンシティブな情報を収集しうるセンサーを内蔵している事をユーザーに隠すというのは論外です。
5.9	停止から回復力のあるシステムを作ること (5.9-1 〜 5.9-3)
		民生用IoT機器とサービスは、ネットワーク回線と電力が停止することに対しての回復性を実装すべきである。ネットワーク接続が失われてもローカルの機能は維持され、電力が喪失した後の復元はきれいに復帰するべきである。復帰の際のネットワーク接続はインフラの能力を考慮して安定した運用がなされるようにネットワークに接続するべきである。	文中"きれいに復帰”というのは、電力喪失前と同等以上のネットワーク接続と機能が維持できるように再起動せよ、という意味です。停電の後の再起動でユーザーに入力指示を求める状態のまま、サービス停止状態で待機し続けるシステム、なんていうのはよろしく無いでしょう。 "インフラの能力を考慮して安定な運用”というのは、例えば大規模な停電やネットワーク障害の後でたくさんの機器が一斉にネットワークやサーバーに大量アクセスすることがあっても耐える設計をせよという意味です。これは単に回線やサーバーを増強するのではなく、機器がサーバーにアクセスする際にランダムな待機時間を設定することでも実現できます。
5.10	通信データの検査をすること (5.10-1)
		民生用IoT機器とサービスによって収集されたデータは、セキュリティ異常の検査をするべきである。具体的にはログイン試行の異常な増加や、無効であるソフトウェアアップデートの相手確認によってセキュリテイ異常を検知することができる。	特にややこしい点はないと思います。ネットワークに繋がっている製品は、外部からの攻撃を検出する機構を備えるとともに、できれば不揮発性のストレージにログを取りましょう。
5.11	ユーザーが簡単にユーザーのデータ消去を行えること (5.11-1 〜 5.11-4)
		簡単な操作で機器からユーザーのデータを消去できる機能を提供しなければならない。および簡単な操作でサービスから個人データを消去できる機能と、個人データの消去方法の明確な説明書がユーザーに提供されているべきである。個人データを機器・サービス・アプリから消去されたことの明確な証明がユーザーに提供されるべきであり、この個人データの消去とは、単に機器からのデータ消去にとどまらず関連するサービスからの消去も含む。個人データの削除にはバックアップデータの遡及的削除も期待されている。	この条項はEU個人データ保護法:GDPR と整合しており、この条項への違反はGDPRにも違反する可能性があります。
5.12	機器へのインストールとメンテナンスが容易であること (5.12-1 〜 5.12-3)
		民生用IoTのインストールとメンテナンスは、最小のユーザーの関与でできるようにするとともに使いやすさはセキュリティを考慮して最も実践的であるべきだ。具体的には、デフォルトのオプションが適切に設定済みのセットアップウィザードを用意する例が挙げられる。製造者はセキュリティ設定のガイドと、機器がセキュアに設定されていることの確認方法のガイドを提供するべきである。	特にややこしい点はないと思います。セキュリティ設定のUIを判りやすく作り、判りやすいマニュアルを提供することは、ユーザーの設定ミスを防ぐことに繋がります。
5.13	入力データは検証すること (5.13-1)
		民生用IoT機器のソフトウェアはユーザーインターフェースからの入力データ、APIもしくは機器もしくはネットワーク経由で送られたデータを検証(Validate)すること。	温度センサーから返ってくる筈のない値が返ってきてもシステムは正常でありつづけますか？機器からデータセンターに送信される計測データのフォーマットが崩れていてもバッファーオーバーフローが起きませんか？システムの破壊や侵入のために異常なデータを送りつけるのは一般的な攻撃手段です。
6	民生用IoT機器のデータ保護規定 (6.1 〜 6.5)
		製造者は機器がどんな個人データを処理するか、それがどのように使用されるか、誰によってどのような目的で処理されるかについて、明確で透過的な情報を消費者に提供すること。個人データが消費者の同意によって処理される場合、この同意は有効な方法で入手されていること。有効な方法での同意とは、通常は自由で明白かつ明示的なオプトインの選択を与えることを含む。個人データの処理に同意を与えた消費者はその同意をいつでも取り消せること。民生用IoT機器とサービスによって遠隔的なデータが収集される場合、個人データの処理は最小限必要なものに留めるべきであり、消費者にはなにの遠隔的データがどのように使用されるか、誰によってどのような目的で採取されるかという情報を提供しなければはらない。	この条項はEU個人データ保護法:GDPR と整合しており、この条項への違反はGDPRにも違反する可能性があります。 GDPR及び個人データに関わるEU法では、5.11や本規定を満たすことは必須で、さらに個人データの収集や保管・加工およびデータ流出の防止や流出してしまった時の対応の規定が設けられています。もし、EU在住者の個人データを扱う際は、最低限GDPRの要求を満たすシステムを構築することが必須です。EUのユーザーが自分の個人データの削除を要請してきた時に対応できますか？個人情報を流出させてしまった時に72時間以内にEU当局に届け出をする体制は構築されていますか？

技術仕様書を使ったEN 303 645への適合評価

あるIoT機器がEN 303 645に適合しているかどうかを評価するには、5章「民生用IoT機器へのサイバーセキュリティ要求」と附属書 Bとにらめっこしながら機器が要求を満たすかを判定していくわけですが、要求が数字で与えられている規格ではないので判定する人によって解釈に幅が出てしまい、評価結果が異なることも多いでしょう。でも大丈夫ご安心めされよ。2021年8月にETSIは ETSI TS 103 701 という文書を発行しました。
ETSI TS 103 701 のタイトルは、「民生用IoT機器のサイバーセキュリティ; 基本要件の適合性評価」です。TS というのは、 Technical Specification; 技術仕様書の略です。TS は規格書ではないのですが、ETSIが発行する技術的要求をとりまとめた規格書に準ずる文書です。ETSI TS 103 701 には、IoT機器が EN 303 645 に適合しているかどうかを判定するときの判断基準が書かれています。要は虎の巻で、これを使えば判定者による評価ブレを小さくすることができます。
多くの認証会社がEN 303 645を使ったIoT機器のセキュリティ認証の商売をやっていますが、このTSを使えば第三者に頼らずともだれでも規格への適合性をだいたい判定できるでしょう。(認証機関のセキュリティ証明書はそれはそれで値打ちがあるのですが。)

EN 303 645 の成立

EN 303 645の起源は英国の文科省が作成した13のパートからなるIoT機器のセキュリティについてのガイドラインです。英文科省は2020年1月にこのガイドラインを英国の法律案として公開しましたが、その際に全13のサブパートを義務とするのではなく、最初の3つのパートだけを絶対に守るべき義務としました。すなわち、

パスワードはユニークなものであり、かつ工場出荷時の共通設定にリセットできないものであること

IoT製造者は脆弱性ポリシーの一部として、脆弱性報告の窓口を公開すること

IoT製造者はセキュリティアップデートを提供する最低期間を明示すること

です。この3点は特に重要だということです。
EUの規格制定機関であるETSIは、サイバーセキュリティ法の整合規格としてこの法案が有用だと考え、法案の13のパートを大きく変えること無く作り変えたのが、EN 303 645です。

サイバーセキュリティに関するEU法について

世界中でサイバー攻撃による被害が拡大する中、EUも対策のための法整備を進めており2019年にはサイバーセキュリティ法(CSA; Cyber Security Act, 規則 EU 2019/881)が公布されています。サイバーセキュリテイ法の対象として想定されているサービス・製品は、ネットワークプロバイダ、ルーター、スマートホン、金融系サービス、キャッシュカード、社会インフラ、大型トラックのタコグラフなどです。サイバーセキュリティ法では、セキュリティ的な重要度に応じてサービス・製品を "高度(High)", "標準(Substantial)", "基本(Basic)" の3つに分類します。そして"高度"と"標準"に分類される製品にはセキュリティ認証を要求し、"基本"に分類される製品にはセキュリティの自己評価を義務付けよう、というのが法の趣旨です。民生用IoT機器は用途によってカテゴリーが変わるのですが、2022年1月現在、重要度カテゴリーの分類基準はまだ策定中です(民生用IoT機器の全てがCSAの対象となるわけでもありません)。
重要度カテゴリーの基準がまだ策定中あることに加え、民生用IoT機器以外の製品カテゴリにはセキュリティ規格がまだほとんどできていないので2022年1月時点ではCSAはセキュリティ認証や自己評価を義務づけていません。しかし現在欧州委員会はサイバーセキュリティ法の実施を精力的に進めており、EN 303 645 がサイバーセキュリティ法の整合規格になる日がいずれやってくると思われます。

EN 303 645はまだ法的に明確に要求されてるわけではないとはいえ、EUでこの規格に法的な値打ちが全くないかというとそうとも限りません。
例えば、EUの個人データ保護法;GDPRは個人データをサイバー攻撃によるリスクから適切に保護することを要求しています。もしIoTシステムの脆弱性を突かれてEUの自然人の個人データが流出してしまった時に、システムが攻撃から保護されていなかったとEU当局が判断すれば罰則を課される可能性があります。2022年現在、GDPRはセキュリティに対する整合規格を定めていませんが、EN 303 645の適合レポートが存在するシステムと、セキュリティについての技術文書がまったくないシステムの2つでは、罰則に関してEU規制当局の判断は大きく異なるのではないでしょうか。
サイバーセキュリティは個人データ保護法のみならず、無線指令(無線製品が対象)などの既存のEU法でも求められてますし、現在改定中のEU製品法にも要求が加わることが決まっています。例を挙げると、2023年に改定が予定されているEU機械規則 (機械もの製品が対象。今の機械指令の改正法) や、時期は未確定ですが改定作業が進められている低電圧指令(家電製品が対象)、一般製品安全指令(特定カテゴリーに含まれない全ての製品が対象)にもサイバーセキュリティの要求が加えられます。
また、製品に対してではなくEU内の組織に対してセキュリティマネジメントを要求するNIS2指令も現在策定中です。法の対象にはネットワークサービス提供事業者のほか製造業者も予定されています。
民生用IoT機器は EN 303 645に適合させることがサイバーセキュリティを要求するEU法に対して一定の効果があると思います。また法律だけの話ではなく、純粋にセキュアなシステムを構築するという観点からも、虎の巻のETSI TS 103 701 まで付いている EN 303 645 は使いやすくて良くできた規格だと考えますし、IoT機器以外の機器にも参考となる要素がたくさんあると思います。

EUは世界の規格の先進国であり、EUの法律/規格はその他の世界各国の法律/規格に波及していきます。EUに製品を販売する企業はもとより、今後はEU以外の国々でもサイバーセキュリティ対策が法的に求められることになっていくでしょう。セキュリティの基準もこのEN 303 645をベースとするものが出てくるでしょうし、セキュリティレベルもこれと同じ水準が必要になってくるだろうと予測しています。

免責

本記事はAs Isで提供するものであり、記事の内容やあなたが記事を読んで採った行為に関して私は一切の責任をおいません。もしこの規格を業務に使う場合は必ず原文を使ってください。
現在EUではセキュリティに関するEU法のためのEN規格の作成が進められており、今後セキュリティの新しいEN規格が続々出てきます。それらの中にはEU法上適合が必須のものも出てくるのでEUに製品・サービスを提供するに当たっては最新の法令をご確認ください。
強固なセキュリティが要求される金融や自動車などの世界は、別途業界用のセキュリティ基準が存在します。製品・サービスを上市する際は適切なセキュリティ基準に従ってください。