平成２８年度 IoT 推進のための新産業モデル創出基盤整備

事業（IoT 機器のセキュリティ評価等調査）

報告書

2017 年 3 月

みずほ情報総研株式会社

2

目 次

調査の目的 .......................................................................................................................... 4 実施概要 .............................................................................................................................. 5 国内外の IoT 機器に関連するセキュリティ要件・評価手法の調査 .................................. 6

国内外の IoT 機器に関連する標準規格 ........................................................................ 6 CC ISO/IEC 15408 ........................................................................................... 6 日本国内における IT セキュリティ評価及び認証制度(JISEC) ........................ 12 UL2900 ................................................................................................................. 14 ISO/IEC 19790（暗号モジュール試験及び認証制度） .................................... 23

国内外の IoT 機器に関連するガイドライン .............................................................. 30 IoT 推進コンソーシアム/総務省/経産省（IoT セキュリティガイドライン） ..... 30 NISC(IoT セキュリティのための一般的枠組) ..................................................... 39 JNSA(コンシューマ向け IoT セキュリティガイド) ............................................ 41 OWASP（Internet of Things Top Ten） ............................................................. 45

文献調査におけるセキュリティ要件及びユースケース等の検討 .............................. 50 セキュリティ要件の抽出 ..................................................................................... 50 ガイドライン等におけるユースケースについて ................................................. 51 評価・試験制度における評価手法について ........................................................ 53

IoT 機器のリスク分析とセキュリティ評価手法の整理 .............................................. 54 IoT 機器のテスト評価による妥当性検証 .......................................................................... 56

通信 ............................................................................................................................. 56 クライアントと IoT 機器の通信 .......................................................................... 56 暗号ライブラリ .................................................................................................... 58 サーバ証明書 ........................................................................................................ 58

IoT 機器と外部の通信 ................................................................................................. 59 IoT 機器の対応プロトコル・暗号方式 ................................................................. 59 サーバ認証 ........................................................................................................... 61 サーバ証明書失効リストの確認有無 ................................................................... 63

認証 ............................................................................................................................. 64 管理者認証 ........................................................................................................... 64 利用者認証 ........................................................................................................... 64

ログ機能 ..................................................................................................................... 65 ログの内容 ........................................................................................................... 65 ログの保存方法 .................................................................................................... 65

利用したツール .......................................................................................................... 65

3

国内における IoT 機器のセキュリティ評価の在り方に関する検討 ................................ 66 IoT 機器のセキュリティ評価の必要性 ....................................................................... 66 IoT のセキュリティ評価の考え方 ............................................................................... 66

評価対象の IoT 機器について .............................................................................. 67 評価対象プロトコルについて .............................................................................. 67 評価対象機能について ......................................................................................... 67

評価の基準と表示について ........................................................................................ 68 評価の基準について ............................................................................................. 68 評価結果の表示について ..................................................................................... 69 評価ツールについて ............................................................................................. 70

評価スキームについて ............................................................................................... 70 検討課題 ..................................................................................................................... 74

法制度関係について ............................................................................................. 74 IoT 機器に関する脆弱性及びバージョンアップ機能について............................. 74 詳細検討が必要な事項 ......................................................................................... 75

関係者が参画するワーキンググループの設置・運営 ...................................................... 78 開催日程 ..................................................................................................................... 78 構成員 ......................................................................................................................... 79

まとめ ............................................................................................................................... 80 参考情報 ............................................................................................................................ 81

別添 別添 1：文献調査概要

4

調査の目的

IoT 環境においては、ネットワークに接続される脅威を考慮していない機器の接続や、生

命や重要インフラの制御に関わる機器の接続、機器同士の自律的な接続、セキュリティにコ

ストをかけられない機器の接続など、機器におけるセキュリティ課題が生じることが懸念

される。このようなセキュリティ課題は、IoT 環境におけるサイバー攻撃によるシステム停

止や破壊、意図せぬ重要情報の漏洩等に繋がる恐れがある。 多くの IoT 機器の製造企業は独自のセキュリティ検証・評価を進めている状況であり、

IoT 機器の利用者（サービスプロバイダやエンドユーザ）、IoT 環境に関わる事業者等が IoT機器のセキュリティを客観的に評価することは難しい。

そこで、ネットワークに接続される IoT 機器等に対して必要なセキュリティを確保する

ために、IoT 機器のセキュリティ要件や評価手法を整理するとともに、第三者評価の在り方

について検討を実施した。

5

実施概要

本事業では、IoT 機器のセキュリティ要件や評価手法を整理し、第三者評価の在り方を検

討するために IoTセキュリティ評価ワークンググループ（以下、IoTセキュリティ評価WG）

を設置し、IoT 機器のセキュリティについて検討を実施した。図 2-1 に本事業概要を示す。 本報告書では、IoT 機器のセキュリティ要件の評価手法に関する文献調査を 3 章に、文献

調査結果を踏まえたセキュリティ評価を整理し検討した結果を 3.4 節に、試行試験（テスト

評価）による妥当性の検討について 4 章に IoT 機器のセキュリティ評価の在り方に関する

検討を 5 章に、検討を行うために設置した IoT セキュリティ評価 WG の概要を 6 章に、本

事業のまとめを 7 章に報告する。なお、実施期間は、平成 28 年 12 月から平成 29 年 3 月で

ある。

図 2-1 本事業概要

6

国内外の IoT 機器に関連するセキュリティ要件・評価手法の調査

IoT 機器のセキュリティに関連する国内外の標準規格（国際規格、民間・業界規格等）、

ガイドライン等の調査を行い、IoT 機器に適用可能なセキュリティ要件を整理した。また、

標準規格に基づき認証制度や評価・検査が実施している場合は、要件に対応した評価手法や

評価ツール、利用状況等について調査を実施した。具体的な調査手法については、公開文献

調査及びヒアリング調査を実施した。

国内外の IoT 機器に関連する標準規格

CC ISO/IEC 15408 3.1.1.1 概要

従来、欧米には独自のセキュリティ評価基準が存在し（欧州：ITSEC、米国：TCSEC（通

称 Orange Book））、それらを統合して作られた評価基準が CC（Common Criteria ）で

ある。その後 CC は ISO 化され国際規格 ISO/IEC15408 となり（1999 年 6 月承認、日本

は 2003 年参加）、日本においては JIS X5070 として JIS 化された（2000 年 7 月制定、パ

ート 1：日本語翻訳、パート 2 及びパート 3：要約 JIS）。 なお、現在ではバージョン 3.1 改訂第 4 版が発行されているが、CC バージョン 2.1 の

内容は ISO/IEC15408 と同一である。 CC は以下の 3 パートより構成されている。

1. パート 1（概説と一般モデル） 基本概念、適用範囲 PP（Protection Profile ）1仕様 ST（Security Target ）2仕様

2. パート 2（セキュリティ機能要件） セキュリティ機能要件集（監査、通信、暗号等）

3. パート 3（セキュリティ保証要件） セキュリティ保証要件集（設計、テスト、構成管理等） EAL3の規定（EAL1～7）

CC に基づいた評価が、異なる制度や評価機関でなされても、その評価結果が均質である

必要があるため、評価に使用される手法（どのような対象を評価し、どのような判断を要す

るかなど）を明確にしたCEM (Common Methodology for Information Technology Security

1 セキュリティ要求仕様 2 セキュリティ設計仕様書 3 評価保証レベル

7

Evaluation:共通評価方法) が CC とともに開発されている。CEM も ISO 標準 (ISO/IEC 18045) として発行された。

3.1.1.2 セキュリティ（機能）要件

CC パート 2 は IT 製品・システムが備える必要がある機能要件集であり、PP/ST の機能

要件選択時に参照される。11 の大分類（機能クラス）と 135 の機能コンポーネントとして

規定されている。 以下に機能クラス一覧及び概要を示す。

(1) セキュリティ監査 セキュリティ監査ログデータの収集と管理に関する要件

セキュリティ監査自動応答 セキュリティ監査データ生成 セキュリティ監査分析 セキュリティ監査レビュー セキュリティ監査事象選択 セキュリティ監査事象格納

(2) 通信/否認防止 否認防止のためのデータ通信の識別に関する要件

発信の否認不可 受信の否認不可

(3) 暗号利用 暗号鍵の管理や暗号操作（暗号化、復号、デジタル署名）に関する要件

暗号鍵管理 暗号操作

(4) 利用者データ保護 アクセス制御、情報フロー制御、転送データ秘匿/保全、保管データ秘匿/保全、残存デ

ータ管理等の利用者保護のための要件 アクセス制御方針

アクセス制御機能

データ認証

TOE4からのエクスポート

情報フロー制御方針

情報フロー制御方針

情報フロー制御機能

4 評価対象となる IT 製品やシステム

8

TOE 外からのインポート

TOE 内転送

残存情報保護

ロールバック

蓄積データ完全性

TSF5間利用者データ機密転送保護

TSF 間利用者データ完全性転送保護

(5) 識別/認証 利用者を特定し、本人確認するための要件

認証失敗 利用者属性定義 秘密についての仕様 利用者認証 利用者識別 利用者―サブジェクト結合

(6) セキュリティ管理 セキュリティ属性や業務権限の管理、セキュリティ機能を正常に動作させるための管

理に関する要件 TSF における機能の管理 セキュリティ属性の管理 TSF データの管理 取り消し セキュリティ属性有効期限 管理機能の特定 セキュリティ管理役割

(7) プライバシー プライバシー確保のための匿名性、ペンネーム利用に関する要件

匿名性 偽名性 リンク不能性 観察不能性

(8) TSF の保護 不正再送（replay）/不正削除/不正挿入等、不正な干渉からセキュリティ機能を保護す

るための要件 フェールセキュア

5 TOE セキュリティ機能

9

エクスポートされた TSF データの可用性 エクスポートされた TSF データの機密性 エクスポートされた TSF データの完全性 TOE 内 TSF データ転送 TSF 物理的保護 高信頼回復 リプレイ検出 状態同期プロトコル タイムスタンプ TSF 間 TSF データ一貫性 外部エンティティのテスト TOE 内 TSF データ複製一貫性 自己テスト

(9) 資源利用 一定の資源サービスを提供するための資源の耐障害性や資源割当に関する要件

耐障害性 サービス優先度 資源割当

(10) TOE アクセス 利用条件の設定、離席対策、利用状況の表示等、不正利用防止のための要件

選択可能属性の範囲制限 複数同時セッションの制限 セッションロックと終了 TOE アクセスバナー TOE アクセス履歴 セッション確立

(11) 高信頼パス/チャネル セキュリティ機構と利用者間のセキュアな通信路を確保するための要件

TSF 間信頼チャネル 高信頼パス

3.1.1.3 セキュリティ（保証）要件

保証要件は、設計から製品化に至る過程でセキュリティ機能が確実に実現されていること

を保証するための要件であり、CC パート 3 に規定されている。 以下に保証クラス一覧と概要を示す。

(1) PP の評価

10

PP の内容の妥当性を評価するための要件 PP 概説 適合主張 セキュリティ課題定義 セキュリティ対策方針 拡張コンポーネント定義 セキュリティ要件

(2) ST の評価 ST の内容の妥当性を評価するための要件

ST 概説 適合主張 セキュリティ課題定義 セキュリティ対策方針 拡張コンポーネント定義 セキュリティ要件 TOE 要約仕様

(3) 開発 製品やシステムの内容がプログラムのモジュールやソースコードに正しく反映されて

いることを保証するための要件 セキュリティアーキテクチャ 機能仕様 実装表現 TSF 内部構造 セキュリティ方針モデル化 TOE 設計

(4) ガイダンス文書 システム管理者及び一般利用者向けのマニュアルやガイドラインの記述内容に関する

要件 利用者操作ガイダンス 準備手続

(5) ライフサイクルサポート 開発から保守に至る各工程で必要なセキュリティ対策に関する要件

CM6能力 CM 範囲 配布

6 構成管理

11

開発セキュリティ 欠陥修正 ライフサイクル定義 ツールと技法

(6) テスト 製品やシステムのテストを漏れなく実施し、テスト結果を十分に確認するための要件

カバレージ 深さ 機能テスト 独立テスト

(7) 脆弱性評定 運用時に発生し得るセキュリティ上の問題（誤用、脆弱性）を漏れなく分析し、それに

対する対策が実施されていることを保証するための要件 脆弱性分析

(8) 統合 統合の根拠 開発証拠 依存コンポーネントの依存 統合 TOE のテスト 統合の脆弱性分析

(9) EAL 評価 EAL7（Evaluation Assurance Level）は評価の深さ/厳格さのレベルを示すものでセキ

ュリティ機能の強度を示すものではない。規格ではセキュリティ機能のサブセットという

形でパッケージ化され、7 つのレベルが規定されている。上位レベル（番号の大きいレベル）

は下位レベルの要件を含んでいる。 以下に評価保証レベル一覧と概要を示す。 ① EAL1 評価者はマニュアルや機能仕様書の分析、独立テストを実施

② EAL2 開発者は機能仕様（外部インターフェース）テスト、明確な脆弱性の分析を実施し、評

価者は上位レベル設計書を用いたプログラム構造の検証、サンプリングテスト、明確な

7 評価保証レベル

12

脆弱性に対する侵入テストを実施 ③ EAL3 開発者は上位レベル（サブシステムレベル）までのテスト、誤使用分析を実施し、評価

者は開発セキュリティや開発生産物の構成管理状況評価、独自の脆弱性分析を実施 ④ EAL4 開発者は構成管理の自動化を実施し、評価者は下位レベルの設計書を使用して処理内

容や重要な部分のソースコードを検証 ⑤ EAL5 開発者は半形式的記述言語を用いた上位レベル設計書を作成し、評価者は全ソースコ

ード、隠れた情報漏えいルートを分析 ⑥ EAL6 開発者は半形式的記述言語を用いた下位レベル設計書を作成

⑦ EAL7 開発者は半形式的言語を用いた検証方法に基づく設計とテストを実施

日本国内における IT セキュリティ評価及び認証制度(JISEC) 「IT セキュリティ評価及び認証制度 (JISEC :Japan Information Technology Security

Evaluation and Certification Scheme)」とは、IT 関連製品のセキュリティ機能の適切性･

確実性を、セキュリティ評価基準の国際標準である ISO/IEC 15408 に基づいて第三者（評

価機関）が評価し、その評価結果を認証機関が認証する、わが国の制度で、本制度は主に政

府調達において活用されている。 現在 IPA が本制度の認証機関として、JISEC を運営している。認証機関は、メーカ、ベ

ンダ、ユーザから依頼された製品、システム、PP のセキュリティ評価を実施。認定機関

（NITE または CCRA 認証国の正式な認定機関）による認定を受けていることが必要とな

る。 評価機関で ISO/IEC15408 に基づいて正しく評価されたことを確認、問題がなければ認証

書をメーカ、ベンダ、ユーザに発行する。また、評価/認証ルール、精度の維持を行う。 認定機関は、JIS Q 17025 または ISO/IEC17025（Guide25）に基づき、評価機関に評価

業務を遂行する能力があることを審査、認定する。

【認証機関】 （独）情報処理推進機構（IPA）セキュリティセンター情報セキュリティ認証室

【評価機関】

株式会社 ECSEC Laboratory 評価センター（製品分野：SW、HW（スマートカー

ド等）

13

みずほ情報総研株式会社情報セキュリティ評価室（製品分野：SW） TUV Informationstetchnik GmbH Body for It-Security（製品分野：SW） Brightsight bv（製品分野：HW（スマートカード等） 一般社団法人 IT セキュリティセンター評価部（製品分野：SW）

【認定機関】

（独）製品評価技術基盤機構（NITE）認定センター

表 3.1-1 認証取得製品 カテゴリー 製品 日本企業の製品

アクセス制御デバイスとシステム 66 5 生体認証システムおよびデバイス 3 境界保護デバイスとシステム 85 データ保護 66 データベース 32 2 検出デバイスとシステム 16 IC やスマートカードおよびスマートカード関連機

器・システム 1,002

キー管理システム 27 多機能デバイス 154 87 ネットワークおよびネットワーク関連機器・シス

テム 246

オペレーティングシステム 100 その他のデバイスとシステム 294 50 デジタル署名のための製品 92 信頼できるコンピューティング 14

合計： 2,197 144

表 3.1-2 ソフトウェア認証申請手数料 認証申請等の種類 認証申請の料金（税込） 注 1、注 2

認証申請 注 1 PP 410,400 円 EAL1 529,200 円 EAL2 691,200 円 EAL3 810,000 円 EAL4 1,026,000 円

14

EAL5 以上 要相談

表 3.1-3 ハードウェア（スマートカード等） 認証申請手数料 認証申請等の種類 認証申請の料金（税込） 注 1、注 2

認証申請 注 1 PP 410,400 円 EAL1 529,200 円 EAL2 691,200 円 EAL3 810,000 円 EAL4 1,026,000 円 EAL5 1,112,400 円 EAL6 要相談 EAL7 要相談

表 3.1-4 ソフトウェア、ハードウェア（スマートカード等） その他の申請

認証申請等の種類 認証申請の料金（税込） 注 1、注

2 保証継続申請 注 1 388,800 円 英文認証書発行申請 3,800 円 認証書の再交付請求 3,800 円 英文認証書の再交付請求 3,800 円 認証報告書の再交付請求 3,400 円 保証継続報告書の再交付請求 3,400 円

注１：上記申請手数料料金は、申請１件あたりの料金で。 一旦支払われた申請手数料は、

申請を取下げた場合であっても返金されない。 注 2：海外の開発現場及び製造拠点等へのサイト訪問に係る交通費及び宿泊費については、

申請者が、申請料とは別に実費を負担する必要がある。

UL2900 3.1.3.1 概要

多種多様なデバイスがネットワークに接続される IoT システムにおいて、各デバイスに

搭載されたソフトウェアに脆弱性を作り込まないことがセキュリティ向上の重要なポイン

トであり、こうしたソフトウェアの安全に対する取り組みの 1 つとして製品安全に関する

「第三者認証」が実施されている。

15

UL（Underwriters Laboratories Inc.）は、1894 年に米国で設立された安全認証機関で、

発足以来、家電などの電気機器から、産業機械、医療機器、空気質に至るまでその認証対象

を広げ、2016 年 6 月現在では 100 カ国以上に拠点を構えている。 2016 年 4 月には米国政府や各種専門機関などと連携して、産業制御システムや医療シス

テムに含まれる「ネットワークデバイス」に対するセキュリティ認証「UL CAP（Cybersecurity Assurance Program）」を立ち上げた。 なお、米国における「サイバーセキュリティ国家行動計画（CNAP：Cybersecurity

National Action Plan）」においても IoT のネットワークデバイスに対するセキュリティ検

査・認証の推進に向け、米国国土安全保障省と UL、産業界のパートナーが連携して UL CAPを立ち上げる旨が示されていた。

UL CAP はネットワークデバイスのセキュリティに関するベストプラクティスなどをま

とめた規格群である「UL 2900」シリーズにより実施される。「UL 2900」は既知の脆弱性、

ソフトウェアの弱点、マルウェア対する対応基準を策定し、最低限満たしていなければなら

ないセキュリティリスク管理要件を定義している。 「UL 2900」シリーズは、ソフトウェアのサイバーセキュリティに関する一般的な要求事

項を記した「UL 2900-1」、ネットワーク接続された医療機器を含むヘルスケアシステムに

関する要求事項を記した「UL 2900-2-1」、産業制御システムに関する要求事項を記した「UL 2900-2-2」、組織／プロセスに関する試験の一般的な要求事項を記した「UL 2900-3」（開発

中、2016 年 4 月時点）、実装／評価に関する一般的な要求事項を記した「UL 2900-4」（開

発中、2016 年 4 月時点）などから構成される。今後の新規開発の候補としては、IoT、コネ

クッドカー、照明等が候補とされている。 このシリーズ規格は製品ならびにシステムのセキュリティを評価し、高めるための技術

的要求事項の根幹を成すものであり、市場のセキュリティに対するニーズの拡大に伴い、新

たな技術基準を取り込んでいくことができるように作られている。 プログラムにはソフトウェア自体に対する「既知／未知の脆弱性の有無のチェック」「フ

ァジングテスト 8」「静的コード解析」といった試験に加え、「開発プロセス」「リリース後の

パッチ管理プロセス」の確認といったソフトウェアの開発・運用体制に対する評価も含まれ

る。これらの検証をクリアした製品には、「UL 認証マーク」が与えられる。（注：ULWEBページにはこのように記載があったが、ヒアリングによると UL マークは与えていないと

のことである。）

3.1.3.2 セキュリティ（機能）要件

UL 2900 シリーズ規格には、以下に示す基準に基づいてテスト及び評価する機能がある。 すべてのインターフェイスでゼロデイ脆弱性を識別するための製品のフ

8 ファズ（英：fuzz）（予測不可能な入力データ）を与えることで意図的に例外を発生させ、その例外の

挙動を確認するという方法。

16

ァジングテスト CVE（Common Vulnerability Enumerations）を使用してパッチが適用

されていない製品の既知の脆弱性の評価スキーム 製品上の既知のマルウェアの特定 CWE （Common Weakness Enumerations）で特定されたソフトウェア

の弱点に対する静的ソースコード分析及びオープンソースソフトウェア及びサー

ドパーティのライブラリによって識別されるソフトウェアの弱点の分析 製品に使用するための特定のセキュリティ対策について下記のリスクが

軽減できるとされている。 製品のアクセス制御と認証 製品に使用される暗号化 製品へのリモート通信・製品のソフトウェア更新・製品の廃止 製品ベースの侵入テストの構造化他のテストで特定された脆弱性 製品に設計された製品セキュリティ対策のリスク評価

3.1.3.3 評価手法（ツール）

UL が CAP 立ち上げの初期段階で、シノプシス 9と協業することにより、安全性の保証

とテストの厳密性を実証するためのフレームワーク作りに着手した。 さらに、シノプシスが提供するセキュリティ・テスト・ソリューションにより “ソフトウ

ェア・サインオフ”と呼ばれる、ソフトウェア開発ライフサイクルならびにソフトウェアサ

プライチェーン全体にセキュリティテストを組み込むためのソフトウェア開発手法を開発

した。 UL は、シノプシスのソフトウェア・テスト・ツール群を用いて、以下に示す CAP 認証

項目を実施している。

既知の脆弱性ならびにリスクへの対応 シノプシスの ProtecodeTM を用いて、ソフトウェアの実行ファイルやライブラリをスキ

ャンし、アメリカ合衆国・国立標準技術研究所（NIST）の NVD ( National Vulnerability Database ) に登録されている既知の脆弱性ならびにリスクの有無を確認。

ソフトウェアの弱点

9 Synopsys, Inc.（Nasdaq 上場コード:SNPS）は、エレクトロニクス機器やソフトウェア製品を開発する

先進企業のパートナーとして、半導体設計からソフトウェア開発に至る領域（Silicon to Software）をカバ

ーするソリューションを提供するしている。電子設計自動化（EDA）ソリューションならびに半導体設計

資産（IP）の世界 16 位のグローバル・リーディング・カンパニー。

17

製品提供企業から UL に提出されるすべてのソースコードに対して、シノプシスの

Coverity® を用いて静的コード解析を実行し、SANS Top25（ソフトウェア脆弱性のトップ

25）と OWASP Top 10（Web アプリケーションの脆弱性のトップ 10） で指定されている

ソフトウェアの弱点の有無を特定。

堅牢性テスト Heartbleed バグを発見した実績を持つシノプシスのDefensics® を用いてファジングテ

ストを実行し、製品に組み込まれているすべての外部インターフェイスならびに接続機構

を検証。 シノプシス社のツールを活用することにより、各種の解析/テスト自動化テクノロジーか

らなる包括的なプラットフォームを構築し、シームレスなソフトウェア開発プロセスを実

施することにより、ソフトウェア開発ライフサイクルの早期段階でコードに潜む品質上の

欠陥、セキュリティ脆弱性、規格準拠性違反などの問題を特定/修正が可能となり、ソフト

ウェアサプライチェーン全体としてのセキュリティの確保と透明性を確立させている。 (1) シノプシスが提供するツール群 ①ProtecodeTM 【製品の概要】 シノプシス（Synopsys, Inc.）は 2015 年 11 月、オープンソース・ソフトウェア（OSS）

の使用状況、関連するライセンス、セキュリティリスクを検出/管理するソリューションを

提供しているカナダの非上場企業 Protecode 社を買収した。この買収により、シノプシス

のソフトウェア・インテグリティ・プラットフォームに新たな開発陣/テクノロジー/製品が

加わり、そのソフトウェア構成解析（SCA）ソリューションを拡充し、ソフトウェア品質な

らびにセキュリティ分野における事業展開が強化された。 ソースコード解析による高度な OSS、 ライセンス検出技術、OSS の適切な管理と使用

を可能にする機能、Global IP Signatures Database といった Protecode 社のテクノロジ

ーは、コードに組み込まれたサードパーティコンポーネントを静的バイナリ解析によって

特定し既知のセキュリティ脆弱性を検出するシノプシスの SCA ソリューションを極めて強

力に補完し、シノプシスは業界で最も包括的な SCA ソリューションを提供することが可能

となった。 Protecode Enterprise を使用すると、企業のソフトウェアやシステム用の包括的なソフ

トウェア部品表（BOM）の自動的な生成及びメンテナンス、サードパーティコンポーネン

トに影響する脆弱性の追跡及び監視、オープンソースライセンスのコンプライアンスの管

理が可能となる。 Protecode Enterprise は、ソースコードとバイナリの両方の解析が可能なソリューショ

18

ンで、R&D の継続的インテグレーション（CI）環境に簡単に統合できる。このソリューシ

ョンは、法務チームとコンプライアンスチームのワークフローを全面的にサポートしてい

る。また、他のステークホルダもこのソリューションを使用することにより、サードパーテ

ィコードの使用に伴うリスクを管理することが可能となる。

【主な機能】 ソフトウェア部品表（BOM）の生成

最新のソフトウェア BOM を自動的に生成及びメンテナンスを行う。R&D、法務及びメ

ンテナンスの各部門にわたるステークホルダがソフトウェアパッケージの構成に関する最

新の情報を得る上で、ソフトウェア BOM を R&D でメンテナンスする方法は最も費用対効

果が大きい方法であり、法務部門や他のステークホルダが、推奨されるワークフローを使用

して独自の解析を行うことも可能となる。

セキュリティの脆弱性の評価 プロジェクト内で使用するサードパーティソフトウェアコンポーネントに影響する既知

の脆弱性を特定してマークする。これらのコンポーネントには、検出された脆弱性の修正に

優先順位を付けるために重大性の格付けが付随しており、CI 環境で使用する際に、すでに

スキャンされたコンポーネントに対して既知の脆弱性が新たに検出された場合、アラート

が自動的に生成される。

包括的なオープンソースライセンスのレポート作成 ソフトウェアポートフォリオ内で見つかったソフトウェアのパッケージまたはファイル

に関連するライセンスと法的責任が含まれる即時使用可能な総合的リストを作成する。 ライセンス責任レポート： フリーソフトウェア及びオープンソースソフトウェ

ア（FOSS）のライセンス各種が含まれるサードパーティコンポーネントを組み

込んだ結果生じる法的責任に関するレポート ライセンス互換性レポート： コードポートフォリオの解析中に特定された互換

性のないライセンス及び関連するパッケージのリスト 連結されたライセンス及び帰属リスト： ポートフォリオ内で特定されたすべて

のライセンス及び関連するパッケージが連結されたリスト、かつライセンスの帰

属責任を果たす上で役立つ即時使用可能なレポート 高水準なレポート及び詳細な部品表： 完全なポートフォリオについて HTML

または一般的なドキュメント形式で作成された、タイムスタンプ付きの検証可能

かつ高水準なエグゼクティブレポートまたは詳細なファイル単位のレポート

深いスキャン及びスニペットの検出

19

パブリックドメインのオープンソースファイルと一致するファイルに埋め込まれたコー

ドのスニペット（Web ページの要約文のこと）またはコピー／ペーストコードを検出して

そのレポートを作成し、使用コードとパブリックドメインコードを並べて類似点の比較を

行う。

構成可能なライセンス及び著作権ポリシー 独自の知的財産（IP）ポリシーのテンプレートを定義し、これらを特定のスキャンに適用

する。既知のライセンス及び著作権のブラックリストとホワイトリストを定義し、カスタム

のライセンス及び著作権への対応を定義する。Protecode Enterprise では、ポリシーに関

する違反が自動的にマークされるため、将来の調査時に役立てることが可能となり、一般的

なコードパターンを無視することも、解析の感度を調整することもできる。

輸出規制及び暗号レポート 公開されている輸出規制分類番号（ECCN）及びプロジェクトまたはコードポートフォリ

オ内の暗号コンテンツに関するレポートを作成する。多くの国では、製品内に埋め込まれた

暗号アルゴリズムの開示を必要とする輸出規制を施行している。

SPDX のサポート ソフトウェアパッケージデータ交換（SPDX）標準をサポートしている。Protecode

Enterprise では、SPDX ファイルを読み込んで生成する。

レポート作成オプション HTML、スプレッドシート、または一般的なドキュメント形式でレポートを作成する。

②Coverity® 【製品の概要】

Coverity は米国 シノプシス社（旧：Coverity 社）製の静的解析ツールで、先進の静的解

析アルゴリズムにより、クラッシュやメモリ破壊、Web アプリ脆弱性といった深刻な不具

合検出が可能となるため、デバッグ作業が大幅に削減可能となり、開発者は仕様の実装作業

に注力することが可能となる。 また、Coverity Software Testing Platform の使用により、開発部門は、品質とセキュリ

ティのテストを開発の最も早い段階に組み込め、より迅速に予定通りのソフトウェア出荷

が可能となる。 深刻な不具合を迅速かつ効率的に検出して修正のための必要な情報を開発者に提供する。

開発サイクルの後期での不具合の検出による手戻りによるコスト増やスケジュール遅延を

削減することにより、品質管理やセキュリクティ管理を開発トッププロセスに組み込むこ

20

とが可能となる。 また、製品出荷後あるいは製造工程において発生する、修正費用がかさみブランドのイメ

ージダウンにつながるソフトウェアの障害及びセキュリティ違反の発生リスクを削減する

ことが可能となる。 【主な機能】

Coverity®が製品の主な機能は以下の通り。 Coverity Static Analysis

ソースコードをスキャンしバグを検出する静的コード解析ツール（対応言語：C/C++、C#、Java）で、検知が難しい不具合とセキュリティの脆弱性を検出する。

Coverity Static Analysis は開発プロセスを監視し、コールグラフ、制御フローグラフ

などの中間モデルを生成した上で、実行可能なパスを網羅的にチェックするというアプ

ローチをとっており、NULL ポインタの間接参照や、リソースリーク、デッドロックな

どの発生条件が複雑で、関数間をまたがるようなランタイムエラーを検出することが可

能である。また、その解析技術には SAT ソルバが実装されており、同業他社のソフトウ

ェアと比較して誤検知率が非常に低いことも特徴である。 Dynamic Analysis（動的解析）

マルチスレッド Java アプリケーションのための動的解析機能、深刻な障害を起こしう

る、潜在的な競合状態や、デッドロックを自動検知する。 Architecture Analysis（アーキテクチャ解析）

アーキテクチャ解析機能、アーキテクチャマップ、コールグラフ、依存性構造マトリッ

クスなど、ソフトウェアシステムを可視化する。 Build Analysis（ビルド解析）

ビルド処理解析機能、ソフトウェアのビルドにおいて、遅延の元となる問題や非効率性

を判別する。 ③Defensics® 【製品の概要】

Defensics はセキュリティをテストする次世代のプラットフォームを利用することによ

り、開発側も利用者側も、迅速に信頼性をもって効率的に、危険なエラーや不具合を発見し

修正をできるようになる。未知の脅威を積極的に総合的に可視化することで、Defensics は

優れた脆弱性管理を行うことが可能となる。 Defensics の中核のテクノロジーはファジングテストとして知られ、テストされるシステ

21

ムに無効または予測されない入力内容をシステマチックに送信して、未知の脆弱性がない

かテストする手法で、市場のどのソリューションよりも効果的にソフトウェアの不具合や

脆弱性を明らかにすることが可能となる。 【主な機能】

信頼性が高く簡単に使用できるセキュリティテスト Defensics は簡単に使用できるテストソリューションで、明快で論理的なユーザインター

フェイスにより、テストやセキュリティ及び開発チームはテストプロセスを段階的に進め

ることが可能となる。

幅広いプロトコルに対応 Defensics の世代間モデルベースのテストモジュールは、270 以上の標準的ネットワーク

プロトコルやファイル形式、その他のインターフェイスに対応しており、これらのテストは

先進的な機能やモジュールでさらに強化することができ、あらゆるネットワークプロトコ

ル、サービスインターフェイス、またアプリケーションファイル形式のテストが可能となる。

正確で実用的なレポート Defensics は、正確で簡単に理解できるレポートを提供する。レポートは特定の問題を識

別するテストケースに直接リンクされており、組織内で詳細なテスト結果が共有できるた

め、結果に基づいて簡単に対応することが可能となる。

修正への明確な道筋 Defensics は、わかりやすい修正方法を概説するワークフローを作成することにより、各

テストケース向けの詳細なオンライン資料により問題の解決が迅速になり、テストされた

システムで見つかった不具合の修正が容易になる。

Heartbleed を発見したソリューション Defensics は、Heartbleed バグが識別された時に使用されていたメインプラットフォー

ムで、セキュリティ調査のために Defensics の機能である SafeGuard のルーチンテストが

実行されており、そこで 2 年以上発見されず、50 万以上の Web サイトに影響を与えた不具

合が識別された。 (2) 認証済の IoT 機器等

制御システムや医療システムに含まれるネットワークデバイスを対象としたセキュリテ

ィ認証制度ではあるが、グローバルで UL CAP 認証を取得している企業は、現時点ではま

だパイロット段階の制度であるため、認証を取得している企業は限定的であり、米国内では

22

約 20 社程度が認証を取得していると言われているが、認証デバイスや企業名は公表してい

いない。また日本国内での認証事例はない。 UL CAP は、製品やシステムのセキュリティリスクを特定し、産業制御システム、医療機

器、自動車、HVAC（暖房換気空調設備）、照明機器、スマートホーム、電化製品、警報シ

ステム、消防システム、スマートメーター、ネットワーク機器、家電など幅広い業界機能に

おけるリスクを緩和する方法を提案するのに役立つとしている。

表 3.1-5 UL2900 目次 参考 UL2900 目次（１、2-1、2-2 でほぼ共通）

導入 1 適用範囲 2 引用規格 3 用語集

製品、製品設計や製品の使用に関する文書 4 製品ドキュメント 5 製品設計ドキュメント 6 製品使用のためのドキュメント

リスク管理 7 一般的な事項 8 アクセス制御、ユーザ認証とユーザ承認 9 リモート通信 10 暗号化 11 プロダクトマネジメント

危機管理 12 ベンダ製品リスクマネジメントプロセス

脆弱性とエクスプロイト 13 既知の脆弱性テスト 14 マルウェアのテスト 15 不正な入力テスト

15.1 一般的な事項 15.2 不正な入力テスト I 15.3 不正な入力テスト II

16 構造化ペネトレーションテスト ソフトウェアの弱点の分析

17 ソフトウェアの弱点の分析 18 静的コード分析

23

19 静的バイナリおよびバイトコード分析 ※UL サイト規格カタログ（https://standardscatalog.ul.com/）または規格販売サイト

（http://www.comm-2000.com/）を参照した内容。

ISO/IEC 19790（暗号モジュール試験及び認証制度） 3.1.4.1 概要

暗号モジュール 10試験及び認証制度（JCMVP®：Japan Cryptographic Module Validation Program）とは、暗号モジュールに実装されたセキュリティ機能が正しく実装さ

れていることを確認すると共に、鍵や ID、パスワード等の重要情報のセキュリティを確保

していることを試験、認証する第三者適合性評価制度である。 IPA で実施している「IT セキュリティ評価及び認証制度」を補完する制度であり、暗号

モジュールのセキュリティに関する試験及び認証に特化した制度である。 「IT セキュリティ評価及び認証制度」では、暗号アルゴリズム実装評価を行う場合はソ

ースコードチェックにより行われ、暗号アルゴリズムに関する深い専門知識が要求される

が、「暗号モジュール試験及び認証制度」では、暗号アルゴリズムが適正に実装されている

ことの確認は試験ツール JCATT（Japan Cryptographic Algorithm implementation Testing Tool ）11

を用いて実施するため、暗号アルゴリズムに関する深い専門知識を要求しないという特徴

がある。 米国・カナダの CMVP（Cryptographic Module Validation Program）12制度と同等の制度であ

り、JCMVP では暗号モジュールセキュリティ要求事項として FIPS 140-2 をベースにして

作成された ISO/IEC 19790 の国際一致規格である JIS X 19790 を採用し、暗号モジュール

セキュリティ試験要件として、JIS X 5091 を採用している。この JIS X 5091 は FIPS 140-2 DTR をベースに提案されている ISO/IEC WD24759 を参考にして作成されている。

JCMVP では承認された暗号アルゴリズムは CRYPTREC 作成の電子政府推奨暗号リス

ト 13に記載されたもの等から JCMVP 技術審議委員会の審議を経て決定される。

10 承認されたセキュリティ機能」をソフトウェア/ファームウェア/ハードウェアで実装したもの。承認さ

れたセキュリティ機能とは、電子政府推奨暗号リスト等に記載され安全性の確認されたセキュリティ機

能。 11暗号アルゴリズム試験要件検討 WG によって検討された暗号アルゴリズム試験仕様書に基づいた暗号ア

ルゴリズム試験を実施することが可能なツール。 12 CMVP では暗号モジュールセキュリティ要求事項として FIPS 140-2（Cryptographic Module Validation Program）を採用。また暗号モジュールセキュリティ試験要件として FIPS 140-2 DTR（Derived Test Requirements）を採用している。 13「政府機関の情報セキュリティ対策のための統一基準（平成 19 年 6 月 14 日、情報セキュリティ政策会

議決定）では、「統括情報セキュリティ責任者は、アルゴリズムを選択するに当たっては、必要とされる

安全性及び信頼性について検討を行い、電子政府推奨暗号リストに記載されたアルゴリズムが選択可能で

あれば、これを選択すること」と記載されている。

24

3.1.4.1 セキュリティ（機能）要件

表 3.1-6 暗号モジュールのセキュリティ要求事項の要約 14 セキュリティレベル 1 セキュリティレベル 2 セキュリティレベル 3 セキュリティレベル 4

暗号モジュール

の仕様

暗号モジュール，暗号境界，承認されたセキュリティ機能，並びに通常動作モード及び縮退動作モードの仕様。全てのハー

ドウェア，ソフトウェア及びファームウェアの構成要素を含む暗号モジュールの記述。全てのサービスは，そのサービスが

承認された暗号アルゴリズム，セキュリティ機能又はプロセスを承認された方法で利用していることを示す状態情報を提供

する。

暗号モジュール

インタフェース

必須のインタフェース及び選択可能なインタフェース。全

ての インタフェースの仕様及び全ての入出力データパスの

仕様。

トラステッドチャネル

役割、サービス・

認証

必須の役割と選択可能な役

割 との論理的な分離，及び

必須 のサービスと選択可能

なサービ スとの論理的な分

離。

役割ベース又は ID ベース

のオペレータ認証

ID ベースのオペレータ認

証

多要素認証

ソフトウェア/ ファーム

ウェア セキュリティ

承認された完全性技術，又

は EDC に基づく完全性テ

スト。定 義された SFMI,

HFMI 及び HSMI。 実行

可能コード

承認されたデジタル署名

又はメッセージ認証コード

に基づく完全性テスト

承認されたデジタル署名に

基づく完全性テスト

動作環境 変更不可能な動作環境，限

定 動作環境又は変更可能な

動作 環境。 SSP の制御。

変更可能な動作環境。 役

割ベースの，又は任意 ア

クセス制御。 監査メカニ

ズム。

物理セキュリティ 製品グレードの部品 タンパー証跡 不透明なカ

バー又は囲い

カバー及びドアに対しての

タンパー検出・応答。強固

な囲い又はコーティング。

直接的なプロービングから

の保護。EFP 又は EFT。

タンパー検出・応答が 可

能な包被。EFP。故 障注

入への対処。

非侵襲セキュリ ティ 附属書 F で規定されている非侵襲攻撃に対処するよう設計

附属書 F で規定されている対策技術の文書化及び有効性 対処法試験。 対処法試験。

Sensitive Security

Parameter 管理

乱数ビット生成器 SSP の生成、確立、入出力、格納及びゼロ化

自動化された SSP の転送方法 又は 承認された方法を用いた SSP の確立

手動で確立される SSP は、平文で入出力されても良い 手動で確立される SSP は、暗号化された形式又は知

識分散法を使って入出力

自己テスト

動作前自己テスト：ソフトウェア・ファームウェア完全性テスト、バイパステスト、重要機能テスト

条件自己テスト：暗号アルゴリズムテスト、鍵ペア整合性テスト、ソフトウェア・ファームウェアのロードテスト、手動鍵

入力テスト、条件バイパステスト 及び 重要機能テスト

ライフサイクル保証

構成管理 暗号モジュール、部品及び文書用の構成管理システム ライ

フサイクルを通じて各々一意に識別及び追跡される。

設計 全てのセキュリティ関連サービスの試験を許すよう設計された暗号モジュール。

FSM 有限状態モデル

開発 注釈付きされたソースコー

ド、回路図又は HDL

高級言語の使用 事前条件、 事後条件の文

書化

ベンダ試験 機能試験 下位レベル試験

14 表内の略語を示す。HDL：Hardware Description Language。ハードウェア記述言語、SFMI :

software/firmware module interface、HFMI : hybrid firmware module interface、HSMI : hybrid software module interface、SSP : sensitive security parameters、PSP : public security parameter、EFP : environmental failure protection(環境故障保護)、EFT : environmental failure testing(環境故障試験)、動作前自己テスト（pre-operational self-test）、条件自己テスト（conditional self-test）

25

セキュリティレベル 1 セキュリティレベル 2 セキュリティレベル 3 セキュリティレベル 4

配付及び運用 初期化手順 配付手順 ベンダ提供認証情報に基づ

くオペレータ認証

ガイダンス 管理者 及び 非管理者ガイダンス

その他の攻撃への対 処

現在、試験要件が整備されていないような攻撃への対処技術の仕様

試験要件と攻撃への対 処

の仕様

（出典：「暗号モジュール試験及び 認証制度のご紹介」独立行政法人 情報処理推進機構 技術本部 セキュ

リティセンター）https://www.ipa.go.jp/security/jcmvp/documents/open/jcmvp_session_20160630.pdf

26

評価手法（ツール） 暗号モジュール試験項目は以下の通り。

文書ビュー – セキュリティポリシーの確認 – 有限状態モデル(FSM（Finite State Model、）15） – 設計資料の確認 – VE（Vendor Evidence ）16ドキュメント（ベンダ情報要件の説明／参照先指定）

ソースコードレビュー – FSM・設計資料とソースコードの一致

物理的セキュリティ試験（セキュリティレベル 2 以上） 暗号アルゴリズム実装試験

– 暗号アルゴリズム実装試験ツール（JCATT）を用いたセキュリティ機能のブラックボ

ックステスト オペレーションテスト

– FSM との一致（エラー状態を含む） – ガイダンス文書との一致

暗号モジュール認証取得で確認できること（JIS X 19790 のセキュリティ目標）は以下の

通り。 承認されたセキュリティ機能を採用し、正しく実装されていること。 認可されていない操作又は利用から暗号モジュールを保護すること。 暗号モジュールの内容の認可されていない開示を防ぐこと。 暗号モジュールの動作状態を表示できること。 暗号モジュール及び暗号アルゴリズムに対する認可されていない変更及び検出不

能な変更を防ぐこと。 承認された動作モードで動作するときにその暗号モジュールが適切に実行するこ

とを保証すること。 暗号モジュールの動作においてエラーを検出し、かつこれらのエラーによる重要

情報の危たい（殆）化を防ぐこと。 暗号アルゴリズム試験ツール（IPA 事業、三菱電機開発）についての詳細は。添付の開発

成果概要資料を参照願います。

15有限状態モデル 16ベンダ証拠資料。

27

3.1.4.2 認証済の IoT 機器等

JCMVP 認証適用可能な製品例は、スマートカード、スマートフォン、スマートメータ、

ソフトウェア暗号ライブラリ、暗号化 USB メモリ、暗号化 HDD、SSD、暗号化ルータ、

無線 LAN アクセスポイント等。 JCMVP で承認されたセキュリティ機能を以下に示す。

表 3.1-7 JCMVP で承認されたセキュリティ機能

技術分類 暗号名称 公開鍵暗

号 署名 DSA、 ECDSA、 RSASSA-PKCS1-v1.5、

RSASSA-PSS 守秘 RSA-OAEP

共通鍵暗

号 64 ビットブロック暗

号 3-key Triple DES

128 ビットブロック

暗号 AES、Camellia

ストリーム暗号 KCipher-2 ブロック暗号利用モ

ード ECB、CBC、CFB、OFB、CTR、XTS

ハッシュ関数 SHA-1、SHA-224、SHA-256、 SHA-384、SHA-512、SHA-512/224、 SHA-512/256

メッセージ認証 HMAC、CMAC、CCM、GCM/GMAC 乱数生成器 Hash_DRBG、HMAC_DRBG and CTR_DRBG

in NIST SP800-90A 鍵確立 DH、ECDH、MQV、ECMQV、NIST SP800-

56B KDF NIST SP800-56C、NIST SP800-108、NIST

SP800-132、NIST SP800-135 Revision 1 (TPMに基づく KDF は除く)

（出典：「暗号モジュール試験及び 認証制度のご紹介」独立行政法人 情報処理推進機構 技術本部 セキ

ュリティセンター）

https://www.ipa.go.jp/security/jcmvp/documents/asf01.pdf 、

https://www.ipa.go.jp/security/jcmvp/documents/open/jcmvp_session_20160630.pdf

28

電子政府推奨暗号リストに記載されたセキュリティ機能は太字で表示。ただし、電子政府

推奨暗号リストに記載された 3 種類の擬似乱数生成系は、JIS X 19790 に基づく暗号モジ

ュール認証では JIS X 19790 の規定により承認されない乱数生成系である。

表 3.1-8 認証済み製品リスト JCMVP

Cert. No

CMVP

Cert. No

Vendor Name Module

Type

Overall

Level

F0001 Toshiba olutions Corporation Software 1

F0002 Canon Inc Software 1

F0003 Tohoku University & AIST Hardware 1

F0004 Canon Inc Software 1

J0005 Hitachi, Ltd. Software 1

J0006 Toshiba Corporation Hardware 1

J0007 Hitachi, Ltd. Software 1

J0008 NEC Corporation Software 1

F0009 NTT Electronics Corporation Hardware 2

F0010 Canon Inc. Software 1

F0011 PGP Corporation Software 1

J0014 AIST Hardware 1

J0015 1696 Hitachi Solutions, Ltd Software 1

J0016 1697 Hitachi Solutions, Ltd Software 1

J0017 1698 Hitachi Solutions, Ltd Software 1

F0018 1269 Imation Corporation Japan Hardwa 3

J0019 NTT Electronics Corporation Hardware 3

J0020 1962 ACES Software 2

J0021 2350 Canon Inc. Hardware 2

（出典：「暗号モジュール試験及び 認証制度のご紹介」独立行政法人 情報処理推進機構 技術本部 セキュ

リティセンター）https://www.ipa.go.jp/security/jcmvp/documents/open/jcmvp_session_20160630.pdf

29

3.1.4.3 その他

その他として、申請手数料の概要を以下に示す。

表 3.1-9 申請手数料

暗号モジュール認証 暗号アルゴリズム確認 ベンダ提出物 認証申請書 、セキュリティ

ポリシ、有限状態モデル、

各種設計文書、ソースコー

ド、VE ドキュメント、マ

ニュアル、回答ファイル

確認申請書、回答ファイル

試験期間 2 ヶ月～ 1 週間程度 申請手数料 （試験費用を

除く） レベル 1 : 270,000 円 21,600 円 （セキュリティ

機能の数に 制限はありま

せん。） レベル 2： 385,700 円 レベル 3： 540,000 円 レベル 4： 756,000 円

暗号アルゴリズム確認書 の交付

○ ○

暗号モジュール認証書の 交付

○ －

認証マークの使用 ○ × （出典：「暗号モジュール試験及び 認証制度のご紹介」独立行政法人 情報処理推進機構 技術本部 セキュ

リティセンター）https://www.ipa.go.jp/security/jcmvp/documents/open/jcmvp_session_20160630.pdf

30

国内外の IoT 機器に関連するガイドライン

IoT推進コンソーシアム/総務省/経産省（IoTセキュリティガイドライン） 3.2.1.1 概要

本ガイドラインは、IoT 機器やシステム、サービスの供給者及び利用者を対象として、サ

イバー攻撃などによる新たなリスクが、モノやその利用者の安全や、個人情報・技術情報な

どの重要情報の保護に影響を与える可能性があることを認識したうえで、IoT 機器やシス

テム、サービスに対してリスクに応じた適切なサイバーセキュリティ対策を検討するため

の考え方を、分野を特定せずまとめたものである。本ガイドラインを活用することにより、

IoT 機器やシステム、サービスの供給者や利用者が自己の役割を認識しつつ、分野ごとの性

質に応じたセキュリティ確保の取組が促進することが望まれている。 第 1 章においては、本ガイドラインの背景や目的、ガイドラインの対象とする IoT、そ

して対象読者を示した。 第 2 章においては、以下に記載するとおり、IoT 機器・システム、サービスの供給者で

ある経営者、機器メーカ、システム提供者・サービス提供者（一部、企業利用者を含む）を

対象とした IoT セキュリティ対策の５指針を示す。IoT セキュリティ対策の５指針では、

IoT のライフサイクル「方針」、「分析」、「設計」、「構築・接続」、「運用・保守」に沿って複

数の要点を挙げ、要点ごとにポイントと解説、対策例を示している。 第 3 章においては、一般利用者向けの注意事項をルールとして記載している。 第 4 章においては、今後検討するべき事項を示している。

3.2.1.2 セキュリティ（機能）要件

IoT 機器の開発から IoT サービスの提供までの流れを、「方針」「分析」「設計」「構築・

接続」「運用・保守」の 5 段階に分けた上で、それぞれの段階に対するセキュリティ対策指

針が示されている。 (1) 指針 1 IoT の性質を考慮した基本方針を定める 【概要】

IoT においては、自動車や家電、ヘルスケア、ATM・決済などの機器やシステムに誤動

作や不正操作が発生することで、利用者の身体や生命、財産などに危害が発生する危険性が

ある。また、その影響はネットワークを介して広範囲に波及する可能性があったり、長期間

使われたりする機器も存在する一方で、全ての IoT 機器・システムまで監視が行き届きに

くいこと、IoT 機器・システムの機能・性能が限られることもある。IoT のセキュリティ対

策は、機器やシステムの開発企業のみならず、利用する企業にとっても存続にも関わる課題

となっており、経営者がリスクを認識し経営者のリーダーシップで対策を推進する必要が

ある。

31

要点 1. 経営者が IoT セキュリティにコミットする

IoT においては、リスクが多様化・波及し、企業の存続に関わる影響をもたらす可能性

がある。また、そのリスク対策にはコストを要するため、開発現場の判断を超える場合も

多いと想定される。そこで、経営者が率先して対応方針を示すことが必要と考えられる。 その上で、緊急対応や原因分析、抜本的な対策を行う体制や、対策の検証・評価を行う

環境が必要となる。また、IoT においては、様々な企業の機器やシステムにより構成され

るため、企業が連携して対応に当たるための「体制の連携」も必要である。さらに、知識

や技術を活用して対応に当たる人材の確保・育成も必要となる。 このため、「サイバーセキュリティ経営ガイドライン」を踏まえ IoT セキュリティに関

する基本方針を策定し、社内に周知するとともに、継続的に実現状況を把握し、見直し、

そのために必要な体制・人材を整備する必要がある。

要点 2. 内部不正やミスに備える 海外では、不満を持った退職者が遠隔から自動車の管理サービスを不正操作し、自動車

を発進できなくしたり、ホーンを鳴らしたりする事件や、銀行が管理する ATM の物理鍵

を複製し、その鍵を用いて ATM の保守扉を開けてウィルスを感染させた上で、ATM のUSB 端子にモバイルデバイスをつなげて現金を払い出させる事件が発生している。IoT のサービスを構成する機器やシステムの設計や構造を熟知していたり、アクセス権限や

鍵を不正に利用できたりする社員や退職者による「内部不正」への対策が必要である。 また悪意がない場合でも、標的型攻撃メールの添付ファイルを開封してウィルスに感

染したり、持ち出した情報を紛失したりすることにより設計情報が漏えいするような「ミ

ス」への対策が必要である。 (2) 指針２ IoT のリスクを認識する 【概要】

IoT のセキュリティ対策を行うには、守るべきものの特定とそれらに対するリスク分析

が必要である。特に IoT では、ネットワークでつながる他の機器にも影響を与えたり、つ

ながることで想定外の問題が発生したりする可能性もある。このため、改めて守るべきもの

の特定やリスクの想定をやり直す必要がある。 要点 3. 守るべきものを特定する 従来の機器やシステムは、エアコンであれば冷暖房のような固有の機能に加え、事故や

誤動作が発生してもユーザの身体や生命、財産を守るための機能も備えている。機器やシ

ステムが遠隔のサーバや他の家電とつながっても従来の安全安心を維持できるよう、こ

れらの機能（本来機能）を守る必要がある。また、機器の動作に関わる情報や機器やシス

32

テムで生成される情報も、つながることで漏えいしないよう守る必要がある。 つなげるための機能についても、外部からの攻撃の入口になったり、誤動作の影響を外

部に波及させないように守る必要がある。そこで、IoT の安全安心の観点で、本来の機能

やつなげるための機能についても守るべきものとして特定することが必要となる。 また、IoT 機器はその数が多い場合も想定したリスク認識が必要である。 要点 4. つながることによるリスクを想定する

2004 年には HDD レコーダーが踏み台にされるインシデント、2013 年、2015 年に

は複数メーカのプリンター複合機に蓄積されたデータがインターネットで公開状態とな

るというインシデントが発生した。インターネットから直接アクセスできる環境での利

用を想定しておらず、本体の初期パスワードを未設定のまま出荷したり、ユーザにパスワ

ード変更を依頼していなかったことが原因と見られる。また、インターネットから隔離し

て運用されていた工場システムが、保守時に持ち込んだ USB メモリ経由でウィルスに感

染した例もある。 要点 5. つながりで波及するリスクを想定する

IoT では機器やシステムに故障が発生したり、ウィルスに感染したりした場合に、つな

がりを通じて影響が広範囲に伝播することが懸念される。機能停止すれば連携する機器

やシステムに影響を与えるし、ウィルス感染で踏み台にされれば被害者から加害者に転

じることとなる。機器やシステムが自分自身の異常状態や他の機器を攻撃していること

を認識できない場合もありうる。 また、対策のレベルが異なる IoT 機器・システムがつながることで全体的な対策のレ

ベルが低下することも想定される。対策のレベルが低い IoT 機器・システムの脆弱性が

攻撃の入口になったり、欠陥や誤設定が IoT 全体に影響を与える可能性もある。 異なる業界では IoT 機器・システムのリスク想定や設計方針も異なると想定され、ネ

ットワークへの接続パターンも考慮し、つながりで波及するリスクへの協調した対応が

必要である。 要点 6. 物理的なリスクを認識する

IoT では、持ち歩いたり、家庭や公共空間などに設置された機器やシステムも IoT を構成するようになる。このため、盗まれたり紛失した機器が不正操作されたり、駐車場や

庭、公共空間に設置された機器が第三者によって物理的に攻撃される危険性がある。また、

廃棄した機器から情報が漏えいしたり、不正なソフトウェアを組み込んだ機器が中古販

売される可能性もある。 要点 7. 過去の事例に学ぶ

33

IoT のセキュリティ対策を実施するにあたっては、過去どのような攻撃事例や対策事

例があったかを学ぶことで、インシデントを未然に防ぐことやインシデント発生の際の

対策の参考とすることができる。 インターネット等のネットワークに接続する場合、ネットワーク経由で攻撃を受ける

等の脅威が生じる。IoT に対する攻撃は、ICT で過去に行われた攻撃手法を用いたもの

も多く発生しており、パソコン等の ICT で発生した攻撃事例や対策等を参考にし、IoT におけるセキュリティ対策を検討することが有効である。また、先行する IoT で発生し

た攻撃事例、その対策事例についてもセキュリティ対策の参考とすることができる。 IoT のセキュリティインシデントの先行事例としては、適切なセキュリティ対策を施

されていない複合機や Web カメラに対して、第三者がインターネット経由で不正にアク

セスできる状態になっていることが明らかになった。このような IoT の先行的な攻撃事

例を受けて、IPA や IoT 機器メーカ等から供給者や利用者に向けたセキュリティ対策に

関する注意喚起がなされている。 指針３ 守るべきものを守る設計を考える

【概要】 限られた予算や人材で IoT のセキュリティ対策を実現するためには、守るべきものを絞

り込んだり、特に守るべき領域を分離したりするほか、対策機能が低い IoT 機器・システ

ムを連携する他の IoT 機器・システムで守ることも有効である。また、IoT サービス事業

者やユーザが不特定の機器やシステムをつなげてもセキュリティを維持したり、異常が発

生してもつながる相手に迷惑をかけたりしない設計が望まれる。 要点 8. 個々でも全体でも守れる設計をする

IoT 機器・システムにおいて発生するリスクとしては、「外部インターフェイス（通常

使用 I/F、保守用 I/F、非正規 I/F）経由のリスク」、「内包リスク」及び「物理的接触によ

るリスク」が挙げられる。外部インターフェイス経由のリスクとしては、DoS、ウィルス、

なりすましなどの攻撃や他機器からの異常データが想定される。 内包リスクとは機器やシステムの設計や仕様、設定等においてセキュリティ上の問題

が存在することであり、具体的には、潜在的な欠陥や誤設定、出荷前に不正に埋め込まれ

たマルウェアなどが想定される。また、物理的接触によるリスクとしては、家庭や公共空

間に置かれた機器の持ち逃げ・分解、部品の不正な入れ替えなどが想定される。これらの

リスクへの対策が必要である。 IoT 機器・システムにはセンサーなど性能が低いため単独では対策機能の実装が難し

いものもある。その場合、それらを含む上位の IoT 機器・システムで守る対策を検討す

る必要がある。

34

要点 9. つながる相手に迷惑をかけない設計をする ソフトウェア／ハードウェアの不具合や攻撃などによる異常な動作が発生した場合、

影響の波及を防ぐために、まず異常な状態を検知できるようにする必要がある。また、異

常な状態が検知された場合、内容によっては影響が他の IoT 機器・システムに波及する

可能性があり、それを防ぐために当該 IoT 機器・システムをネットワークから切り離す

等の対策の検討が必要である。 IoT 機器・システムのネットワークからの切り離しや機能の停止が発生した場合、その

IoT 機器・システムの機能を利用していた他の IoT 機器・システムやユーザへの影響を

抑えるために、状況に応じて早期に復旧するための設計が必要となる。 要点 10. 安全安心を実現する設計の整合性をとる セキュリティ上の脅威がセーフティのハザード要因となるケースがある。例えば、第三

者による IoT 機器・システムへの不正侵入によりソフトウェアやデータの改ざんが行わ

れた場合、何らかのきっかけで誤動作を引き起こす可能性がある。特に、セーフティ機能

が攻撃された場合は、システムダウンや事故につながりかねず注意が必要である。また、

セキュリティ機能を実装することでセーフティ関連も含めた本来機能の性能に影響を与

える可能性もある。それらの対策が適切に行われているかどうかを確認するために、セー

フティとセキュリティの設計の「見える化」が有効である。 セーフティとセキュリティの設計品質の確認では、ハザードや脅威とそれらから引き

起こされるリスク対応だけでなく、セーフティとセキュリティの相互の影響を確認する

必要がある。その際には、それらの相互の影響を可視化し、異なる部署・異なる企業の技

術者間で設計の整合性を確認することを容易にする対策も有効である。 また、既に安全を確保するための安全規制等が存在する場合、要点 10 には、それらに

従って安全を確保することが大前提である。 要点 11. 不特定の相手とつなげられても安全安心を確保できる設計をする 機器のメーカで接続して動作確認をしていない機器の組み合わせであっても、業界の

標準規格の機能を持つ機器を接続して利用できることが多い。そのため IoT が普及する

にともない、利用されている機器のメーカが意図していない不特定の機器が、インテグレ

ータやユーザによってつなげられて利用されるケースが増えている。この状況において

は、信頼性の低い機器が接続された場合に、秘密情報が簡単に漏えいしたり、あるいは想

定していない動作が引き起こされてしまう可能性がある。また、同じメーカの製品同士で

も、時間が経つにつれて後から出荷された型式やバージョンが増え、接続動作確認が行わ

れていないケースも増加する。つながる相手やつながる状況に応じてつなぎ方を判断す

る設計を検討する必要がある。

35

要点 12. 安全安心を実現する設計の検証・評価を行う 機器やシステムにおいて、設計が実現されていることを検証・評価するスキームとして

は V 字開発モデルが挙げられる。 IoT 機器・システムについては、単独では問題がないのに、つながることにより想定さ

れなかったハザードや脅威が発生する可能性もある。安全安心の要件や設計が満たされ

ているかの「検証」だけでなく、安全安心の設計が IoT において妥当であるかの「評価」

を実施することが必要となる。 (3) 指針４ ネットワーク上での対策を考える 【概要】

多様な機能・性能を持つ機器・システムが相互に接続される IoT では、機器のみにセキ

ュリティ対策をゆだねるのでは無く、IoT 機器・システム及びネットワークの両面からセキ

ュリティ対策を考えることが重要である。 要点 13. 機器等がどのような状態かを把握し、記録する機能を設ける 様々な機器やシステムがつながった状態では、何がどのように接続し、機器やネットワ

ーク上のどこで何が発生しているかを把握することは容易ではない。異常の発生を検知・

分析して、原因を明らかにしたり、対策を検討したりするためには、個々の IoT 機器・

システムがそれぞれの状態や他機器との通信状態を収集・把握することが必要である。ま

た、発生した異常の原因究明を行う際に必要となることから、収集した情報はログとして

適切に記録することが必要である。このとき、ログとして保管しても、攻撃者等によりそ

の内容を不正に消去・改ざんされてしまうと対策が打てなくなってしまうことから、正し

く記録できるよう対策を講じる必要がある。 また、IoT 機器・システムの中にはセンサーなど低機能のものも含まれており、単独で

大量のログの管理や、ログの暗号化などの対策を行うことが難しい場合がある。そのよう

な機器については、他にログを管理するための機器を用意するなどの対策を行う必要が

ある。 要点 14. 機能及び用途に応じて適切にネットワーク接続する 提供する IoT システム・サービスの機能及び用途、IoT 機器の機能・性能等を踏まえ、

ネットワーク構成やセキュリティ機能の検討を行い、IoT システム・サービスを構築・接

続する必要がある。 機能及び用途に応じて有線接続・無線接続のどちらを選択するかを検討した上で、セキ

ュリティ対策を実施する必要がある。また、機能・性能が限られた IoT 機器については、

IoT 機器単体で必要なセキュリティ対策を実現することが困難なため、IoT システム・

サービス全体でセキュリティを確保することが必要である。

36

要点 15. 初期設定に留意する

IoT システム・サービスの提供者がシステム・サービスを構築・接続したり、その提供

を開始するにあたって、悪意のある攻撃者が容易に攻撃可能であるような脆弱なシステ

ム・サービスとならないよう、できる限り脆弱性に留意したセキュアな設定とすることが

必要である。また、利用者へ初期設定に関する注意喚起を行う必要がある。 要点 16. 認証機能を導入する 不正な IoT 機器が正規の IoT 機器のようになりすますことで、利用したユーザのプラ

イバシー情報が漏えいしたり、不正なユーザが正規のユーザになりすますことで、IoT 機器が乗っ取られて不正な動作を引き起こす可能性がある。また、ネットワークの通信路や

クラウド上のプラットフォームのデータが盗聴され、ユーザのプライバシー情報が漏え

いする可能性がある。そうしたなりすましや盗聴等の脅威への対策として、認証や暗号化

等の仕組みの導入が必要である。 (4) 指針５ 安全安心な状態を維持し、情報発信・共有を行う 【概要】

IoT では多様な機器が存在し 10 年以上の長期間利用される機器やシステムも想定され

る。そのため、機器の故障だけでなく、危殆化等によるセキュリティ対策状況の劣化やネッ

トワーク環境の変化など、多くの環境変化が考えられ、機器やシステム、サービスの出荷や

リリース後についてもセキュリティ対策を考えることが重要である。 要点 17. 出荷・リリース後も安全安心な状態を維持する

IoT 機器には製品出荷後に脆弱性が発見されることがあるため、脆弱性を対策した対

策版のソフトウェアを IoT 機器へ配布・アップデートする手段が必要である。 IoT システム・サービスの提供者等は、IoT システム・サービスの分野ごとの特徴を踏

まえて、IoT 機器のセキュリティ上重要なアップデートを必要なタイミングで適切に実施

する方法を検討し、適用する必要がある。 なお、本指針は IoT 機器に対して常に最新のアップデートを適用せよ、という趣旨で

はなく、セキュリティ上重要なアップデートを適切に行って、IoT 機器を安全安心な状態

に保つことを推奨するものである。 要点 18. 出荷・リリース後も IoT リスクを把握し、関係者に守ってもらいたいこと

を伝える 提供するシステム・サービスに関わる脆弱性情報がないか、脆弱性情報を収集・分析し、

ユーザや他のシステム・サービス提供者に情報発信を行う必要がある。

37

また、IoT システム・サービス提供者は、システム・サービスの提供条件や利用上の注

意等の中にセキュリティに関する留意事項を記載し、利用者に対してシステム・サービス

の利用開始前に説明する必要がある。 IoT では、出荷後に想定外の問題が発生するリスクもある。例えば、2013 年に米国大

手小売業が POS 用ウィルスに感染し、4 千万人のクレジット・デビッドカード情報及び

7 千万人の顧客情報が漏えいした事例がある。2011 年頃から POS 用ウィルスの新種が

急増していたにも関わらず、対策が不十分であった可能性がある。また、2014 年の

Heartbleed など、広く普及しているオープンソースソフトウェア（以下「OSS」）に重大

な脆弱性が発見された例もある。特に、セキュリティ上の脅威がセーフティの機能に影響

を与える場合、予期せぬ事故が発生する可能性もある。 IoT 機器メーカ及びシステム・サービス提供者は、これらの問題に早急に対応するため

に、関係者と協力し継続的に情報収集・分析する必要がある。 また、IoT 機器・システムは出荷・リリース後、構築・接続、運用・保守にて長期にわ

たって利用される。 その後リユースされることもあるが、最後は廃棄されることになる。この間、以下のよ

うな安全安心上の問題が想定される。 ■ 構築・接続時

- ファイアウォールの無い環境への設置 - ログイン用パスワードの未設定

■ 運用・保守時 - 経年によるセキュリティ機能の劣化 - 新たな脆弱性の発見 - 他者が推定可能なパスワード設定 - ソフトウェアアップデート未実施 - サポート期間が未通知、またはサポート期間を過ぎた継続利用 - システムや機器に設計された復旧機能でも回復が困難な障害の発生

■ リユース・廃棄時 - 内包する個人情報・秘密情報の未消去

上記の問題は、設計時等の対策だけでは対応が難しいため、構築・接続、運用・保守、

廃棄時の関係事業者に対して対応を求める必要がある。 要点 19. つながることによるリスクを一般利用者に知ってもらう 一般利用者が不用意なつなぎ方や不正な使い方をすると、不正に遠隔操作されたり、異

常動作する等のリスクが高まる。 また、IoT 機器メーカ及び IoT システム・サービス提供者が各種リスク対策を行い許

38

容できる範囲までリスクを低減したとしても、一般利用者に影響を与えるリスクが潜在

していたり、出荷・リリース時には想定できなかったリスクが発生する可能性もあるため、

そのようなリスクの存在を一般利用者に伝える必要がある。 IoT 機器を利用する際には、その利便性だけではなく、リスクがあることも一般利用者

に周知する必要がある。一般利用者に対して、IoT 機器・システムを不用意につなげたり、

不正な使い方をしないことを周知するとともに、IoT 機器・システムの脆弱性対策の必要

性を説明し、協力を得ることが必要である。 要点 20. IoT システム・サービスにおける関係者の役割を認識する インシデントが発生してから誰がどのような対応をするのか初めて協議するようでは、

セキュリティ対策が後手に回り、被害の影響が大きくなる可能性がある。また、事前に役

割を明確化しておかないことに起因する、関係者間の連携不足も懸念される。 サービス開始時までにあらかじめシステム・サービス提供者が関係者間の役割分担を

明確にし、それぞれの役割を正しく理解してもらえるよう努めておく必要がある。 IoT においては、自動車・医療機器・スマート家電・スマートホーム等の分野ごとに想

定されるインシデントやリスクは大きく異なってくるため、分野ごとに関係者の役割を

整理して理解しておくことが必要である。例えば、自動車分野では、IoT 機器メーカが自

動車メーカ、IoT システム・サービス提供者が TSP 等のネットワーク事業者や自動車メ

ーカ、一般利用者が自動車の所有者、運転手等となっている。同様に、医療分野では、IoT 機器メーカが医療機器メーカや通信機器メーカ、IoT システム・サービス提供者がネット

ワーク事業者や在宅医療サービス事業者、一般利用者が患者及びその家族、医師、看護師、

ケアマネージャ等となっている。 このように、IoT においては、多くの関係者が存在し、かつ、複雑な関係となっている

ため、あらかじめ関係者の役割を整理して理解しておくことが必要である。 要点 21. 脆弱な機器を把握し、適切に注意喚起を行う

IoT 機器に脆弱性がある場合には、その脆弱性を突いたサイバー攻撃が行われる可能

性がある。IoT システム・サービスの提供者が、提供しているシステム・サービスのため

に設置した IoT 機器のうち、脆弱性を持つものがネットワーク上に存在していないかど

うかを確認することが被害の抑制に有効である。そのためには、新たに設置する IoT 機器だけではなく、既存の IoT 機器を含めて、機器の情報を把握する手段を整備もしくは

利用し、脆弱性を持つ機器を特定する必要ある。また、脆弱性が把握された場合には、該

当する IoT 機器の管理者に対して、注意喚起を実施する必要がある。

39

NISC(IoT セキュリティのための一般的枠組) 3.2.2.1 概要

IoT(Internet of Things)システムについては、将来、個々のシステムが相互に接続される

ことを見据え、セキュリティ・バイ・デザイン(Security by Design)の思想で設計、構築、

運用されることが不可欠である。こうしたことを合理的に実現させるためには、早急にすべ

ての IoT システムにかかる設計、構築、運用に求められる事項を一般要求事項として明確

化し、その上で、個々の分野の特性を踏まえた分野固有の要求事項を追装する２段階のアプ

ローチが適切であると考えられる。 本枠組は、こうした考え方に基づき、IoT システムが具備すべき一般要求事項としてのセ

キュリティ要件の基本的要素を明らかにすることを目的としている。 本枠組において、IoT システムはモノ同士がインターネットを介して接続されることに

より新たな価値を生み出すものである。しかし、IoT システムが他の IoT システムと接続

されることによって追加的な付加価値が生みだされる反面、一つの IoT システムのリスク

が他の IoT システムに波及する可能性があることに鑑み、本枠組においては、IoT システ

ムの集合体である”System of Systems (SoS)”として捉える。

3.2.2.2 セキュリティ（機能）要件

セキュリティ要件を検討する上で、以下の取組方針を踏まえた検討を行う必要がある。

(1) 要求事項の明確化 接続するモノと使用するネットワークに関連する①法令・規制要求事項、②明示されてい

ないが不可欠な要求事項、③業界等が必要と判断する追加要求事項について明確化する必

要がある。 (2) リスクに応じた対応

あらゆるモノがネットワークに接続されるとした際、接続によってもたらされるメリッ

トとリスクは不可分であり、その両面を客観的に捉え、当初は想定されていなかったリスク

が生じうることも含め、採られるべきセキュリティ対策や実装方法等をあらかじめ明確に

する必要がある。リスク及び許容されるリスクは、ユースケースによっても異なること及び

時間の経過とともに変化することを踏まえ、機能保証の観点から柔軟に対応できるように

する必要がある。 このため、リスクアセスメントを適宜活用するものとする。その際、特定の IoT システ

ムに起因するリスクが他の IoT システムに波及するシステミックリスクを遮断する仕組み

についても明確化する必要がある。

40

(3) 性能要求と仕様要求の適切な適用

IT を取り巻く環境変化は急激であるため、要求事項は、普遍的な性能要求とその時点で

有効な手段の具体的方法を示す仕様要求の２つの要求から構成するものとする。 このうち、仕様要求は、対象とする IoT システムを明確化し、柔軟に最適な手段を選択

できるよう作成される仕組みとする。 (4) 段階的・継続的アプローチ

IoT システムは、技術革新等の環境変化によって継続的に機能等が変化していくもので

あることを踏まえ、まずは、基本的な機能要件を定め、段階的・継続的にそれを進化させて

いくものとする。 (5) 役割分担及び連携した対処のあり方の明確化

産、官、学はもちろんのこと、IoT システムに関連する者の役割分担を明確にする。あわ

せて、情報共有も含め、各主体の連携・協調によるセキュリティ確保のあり方や各主体間の

責任分界点を明確にする。 (6) その他運用ルールの検討

IoT システムの連携と個人情報保護の仕組みについて、領域を越えた社会的ルールの具

体化を図る。また、機器認証の在り方等について、主体の在り方(複数の主体による連携を

含む。) や運用ルールを明確化する。

41

JNSA(コンシューマ向け IoT セキュリティガイド) 3.2.3.1 概要

多数の IoT 製品が相互接続され、通信を行い、生活や社会インフラとして機能することを

考慮し、切な情報処理と制御行う必要があり、それを実現するためには IoT 製品のセキュ

リティ向上が重要な要素となる。ただし、現状では、セキュリティの実現と実践を一般の利

用者に任せるのは困難であるため、IoT 製品やシステム、サービスを提供する事業者の側が

利用者のセキュリティ対策を設計時から作り込み、情報提供する必要がある。 そこで IoT に関連する様々な仕様や規格、技術ドキュメント類を俯瞰するとともに、実際

の IoT 利用形態を分析した結果、IoT 製品やシステム、サービスを提供する事業者が考慮し

なければならない事項をガイドラインとして整理したドキュメントである。 ガイドラインは 4 部構成となっている。まず 1 部で IoT の概要や市場動向などを概観した

後、2 部では IoT のセキュリティとプライバシーを巡る動きをまとめ、代表的な攻撃方法を

紹介している。さらに 3 部と 4 部では一般消費者向け IoT 製品の提供者が考慮すべき点を

解説する。スマートテレビ、ウエアラブルデバイス、ネットワークカメラ、汎用マイコンボ

ードといった代表的な一般消費者向け IoT 製品を取り上げ、想定される脅威を記述した後、

具体的な対策例を示している。

3.2.3.2 セキュリティ（機能）要件

IoT 製品、システムのセキュリティ要件を検討するに当たり、ベンダ（提供者）は IoT の仕組みや構造について詳細を理解していないユーザ（利用者）が IoT 製品やサービスを安

全に利用するために考慮すべき事柄があり、サイバーセキュリティの観点から企画・開発か

ら製品・サービスの提供にわたり、どのようなことを考慮する必要がある項目を以下に示す。 個人向け IoT デバイスは、任意の利用目的で所有、利用するものであるため、製品の保証

期間をベンダが定めたとしても実際に稼働する期間を厳密に定義することはできない。こ

のため、セキュリティ含め、安全に利用することのできる期間を設定する必要がある。 上記の「製品保証期間」は製品の保証を提供する期間で、製品の不具合（ハードウェアの

材質上や製造上の瑕疵など）について保証を提供する期間は、通常 1 年程度とされる。 「セ

キュリティ更新の提供期間」とは、製品保証期間を過ぎてもユーザが使い続けることを想定

し、製品に対するセキュリティの更新を提供する期間である。この期間を過ぎた場合ユーザ

には「廃棄」することを勧めるなどの対応が望ましいと考えられる。 利用開始の際に、デバイスの導入設定がユーザにとって複雑でなく、初期設定に必要な情

報などを第三者が再利用することのできない仕組みを提供することが望ましい。 また、利用を開始した後、デバイスに異常が発生した場合、異常を解消して復旧する必要

がある。利用開始後、長期間にわたって使用せずに稼働させたまま放置することで第三者が

デバイスにアクセスすることが可能な状態はセキュリティ上好ましくない。

42

デバイスが不要となる場合には、記録・保存されたデータの消去や初期化についての手順

が準備され、ユーザが対処するか、ユーザが対処せずともよいような仕組みがあることが望

ましい。 本ガイドラインでは IoT デバイスへの脅威を以下のように定義しており、これを異なる

デバイスに当てはめて脅威分析を行っている。 【想定される脅威】

利用者による操作に起因する脅威 1. 操作ミス：デバイスやシステムを誤動作させられてしまう 2. ウィルス感染：デバイスやシステムが有する情報やデータが漏れるか誤動作させられ

てしまう 攻撃者による干渉に起因する脅威

3. 盗難：デバイスが盗まれてしまう 4. 破壊：デバイスが破壊されてしまう 5. 盗聴：通信内容を他人に知られてしまう 6. 情報漏えい：知られたくない情報を盗まれてしまう 7. 不正利用：他人にシステム、デバイス、ネットワークを使用されてしまう 8. 不正設定：他人にシステム、デバイス、ネットワークを設定変更されてしまう 9. 不正中継：無線や近接による通信内容を傍受されるか、書き換えられてしまう 10. DoS 攻撃：システム、デバイスの機能やサービスが利用できなくなる 11. 偽メッセージ：偽メッセージによるシステム、デバイスが誤動作してしまう 12. ログ喪失：動作履歴が無いため、問題発生時に対処方法がわからなくなる

ガイドラインでは想定される脅威とデバイスのライフサイクルごとに、取りうる対策を

列挙している。ガイドラインでは、スマートテレビ、ウェラブルデバイス、ネットワークカ

メラ、汎用マイコンボードに関する事例を紹介している。 ユーザは IoT の仕組みや構造について詳細を理解していなくてもベンダが提供する情報

から個々の IoT 製品やサービスについて安全に利用できる必要があるため、サイバーセキ

ュリティの観点からユーザに対してベンダが配慮すべき項目は以下の通り。 (1) デフォルト設定をセキュアに (2) 問題発生を想定する (3) 廃棄まで責任を持つ

ベンダは IoT デバイスの企画・開発、販売に際して、IoT デバイスおよびデバイスで利用

するインターネット上のサービスに対し、サイバーセキュリティ対策を施し、ユーザが行な

う必要のある操作や作業を特定して適切なガイドを行なう必要がある。

43

ユーザに適切なセキュリティ機能を提示することは、ベンダのインシデント対応コスト

を下げることにもつながるといえる。 (1) デフォルト設定をセキュアに

デフォルトの設定はセキュリティの高い方を採用する。 ユーザが設定変更を正しく実施できるスキルを持つとは限らない。 設定変更ができない場合でも一定のセキュリティが保たれるようにする。

（例) インターネットからのアクセスを不可の設定にして出荷、共通 ID・共通パスワー

ドは使わず、デバイス個々に設定する、Well－Known ポートはひとまず閉じてお

く デフォルト設定を変更せざるを得ない手順を作る

デフォルト設定をセキュアにすると動作に支障が出て、不良品と勘違い

するエンドユーザが多くなりそうな場合の次善の策 面倒だからと、マニュアルにあっても自主的な設定変更をしないユーザ

対策 （例）初期設定画面で、デフォルトパスワードを変更しないと次のステップに進めなくす

る、管理者がログインするとパスワードの変更を強制される、初回起動時に設定変

更チェックを走らせメッセージを出す (2) 問題発生を想定する

インシデント発生時の受付窓口を設ける おかしいと思っても連絡する先がないと被害は拡大する

問題発生を検知する手段を考える ユーザが気づくきっかけを作る

（例）重要な構成変更が行われたらメールで通知、何かソフトウェアがインストールされ

たら Pop up 表示 非常停止機能を作る

簡単な操作で被害を止める手段が必要 （例）リセット・データワイプボタン、無線通信停止ボタン

(3) 廃棄まで責任を持つ

デバイスが放置される可能性を考える 安価な IoT は、紛失・盗難・放置される可能性がある そのまま稼動を続けると、プライバシー侵害・BOT の温床になる

（例）有効期限を持つパラメータを仕込み、必ず停止させる、ベンダからのリモートワイ

プ

44

45

OWASP（Internet of Things Top Ten） 3.2.4.1 概要

OWASP （Open Web Application Security Project）は、安全なソフトウェアの設計・開

発・習得・運用と維持に関する活動を支援する、非営利の団体で、OWASP のツールやドキ

ュメントなど、すべての成果物は無料で利用することが可能である。 OWASP Internet of Things Project は OWASP 内のプロジェクトの一つで、製造業者、

開発者、消費者の IoT に関わるセキュリティ上の問題の理解向上を支援すること、IoT 技術

の構築・展開・評価に際して利用者のセキュリティ上の検討を支援することを目的とした活

動を行っている。

3.2.4.2 セキュリティ（機能）要件

「OWASP Internet of Things Top 10」に含まれる項目を以下に示す。 (1) Insecure Web Interface（セキュリティが確保されていない Web インターフェイ

ス） Web インターフェイスのセキュリティを確保するには：

最初のアカウント設定時に、パスワードをデフォルトのものから変更するよう、必

ずユーザに要求する。できればユーザ名も変更できるのが理想的である。 十分に堅牢なパスワード再設定メカニズムを実装する。またパスワード再設定メ

カニズムや新規ユーザページなどから、正規アカウントの情報が特定できないように

する。 ウェブインターフェイスに、XSS（クロスサイトスクリプティング）や SQL イン

ジェクション、CSRF（クロスサイトリクエストフォージェリ）への脆弱性が存在しな

いことを確認する。 内部ネットワーク/外部ネットワークに関わらず、アカウント情報がネットワーク

トラフィックに露出しないようにする。 脆弱なパスワードは許可しない。またログインに 3～5 回失敗した場合には、その

アカウントをロックアウト（一時的に使用不可能に）する。 (2) Insufficient Authentication/Authorization（不十分な認証） 十分な強度を備えた認証を実現するには：

「1234」などの簡単なものではなく、推測されにくい強力なパスワードを要求す

る。 アカウント情報がプレーンテキストで伝送されていないことを確認する。 パスワードの複雑度設定や使用履歴の確認、有効期限設定等、パスワード制御に関

46

する必要機能を実装する。また新規ユーザの場合には、必ずパスワード変更を強制する。 漏洩によって重大な問題を引き起こす機密性の高い情報にアクセスする場合には、

ユーザの再認証を要求する。 インターフェイスがユーザのロール（役割）に応じて分離可能であることを確認す

る。例えばアドミニストレータは全ての機能にアクセスできる一方で、一般ユーザはア

クセス可能な機能を制限する、といった対応が必要である。 ユーザが本来持っている権限を超えた権限を取得できる「特権昇格（privilege

escalation）」が行えないことを確認する。 必要であれば、よりきめ細かいアクセス制御を導入する。 アカウント情報が適切に保護されていることを確認する。 必要に応じて二要素認証（二段階認証）を実装する。 パスワード再設定メカニズムが安全であることを確認する。 パスワード制御の設定に関しては複数の選択肢を用意する。

(3) Insecure Network Services（セキュリティが確保されていないネットワークサービ

ス） ネットワークサービスのセキュリティを確保するには：

使用機器が開いているポートを、ポートスキャナで確認する。開いているポートに

ついては、DoS 攻撃やバッファオーバフロー、ファジング攻撃への脆弱性や、UDP サ

ービス関連の脆弱性等をテストした上で、必要最小限のポートのみを開ける。 提供サービスにバッファオーバフローやファジング攻撃、DoS 攻撃などへの脆弱

性が存在しないことを確認する。 ネットワークポートやサービスが、UPnP 等によってインターネットから直接ア

クセスできる状態になっていないことを確認する。 (4) Lack of Transport Encryption（暗号化されていないトランスポート） トランスポートに十分な暗号化を行うには：

各種デバイスやその上で動くモバイルアプリケーション、クラウド接続のトラフ

ィックについて、情報がプレーンテキストで送られていないことを確認する。ネットワ

ーク上で情報をやり取りする場合には、SSL や TLS などのプロトコルを使って暗号化

を行う。 使用している SSL や TLS が最新であり、かつ正しく実装されていることを確認す

る。 SSL や TLS が使用できない場合には、他の業界標準の暗号化技術を活用し、伝送

路におけるデータ保護を行う。 一般に推奨され認められている暗号化プロトコルのみが使用されていることを確

47

認する。 (5) Privacy Concerns（プライバシーに関する懸念） プライバシーに関する懸念を最小限に抑えるには：

各種デバイスやその上で動くモバイルアプリケーション、クラウドインターフェ

イスが、それらの機能にとって必要最小限の情報のみ収集していることを確認する。 収集するデータは、機密保持の必要性が比較的低いもののみに制限する。 適切に暗号化されていない個人情報を、ストレージ等に保存あるいはネットワー

クで伝送すると、読み取られる危険があるため、収集した全てのデータは、適切な暗号

化によって保護を行う。 収集した情報は、個人を特定できない状態にしておく。 収集した個人データには、承認を受けた者のみがアクセスできるようにする。 収集したデータには、保持期限を設定する。 製品機能やサービスの提供等に必要と想定される範囲を超えるデータを収集する

場合には、エンドユーザにそれに関する「通知と選択肢」を提供する必要がある。 (6) Insecure Cloud Interface（セキュリティが確保されていないクラウドインターフェ

イス） クラウドインターフェイスのセキュリティを確保するには：

最初のアカウント設定時に、パスワードをデフォルトのものから変更するよう、必

ずユーザに要求する。できればユーザ名も変更できるのが理想的である。 ログインに 3～5 回失敗した場合には、そのアカウントをロックアウト（一時的に

使用不可能に）する。 パスワード再設定メカニズムや新規ユーザページなどから、正規アカウントの情

報が特定できないようにする。 クラウドインターフェイスに、XSS（クロスサイトスクリプティング）や SQL イ

ンジェクション、CSRF（クロスサイトリクエストフォージェリ）への脆弱性が存在し

ないことを確認する。これは、全てのクラウドインターフェイス（API インターフェイ

スとクラウドベースの Web インターフェイス）について検証する必要がある。 アカウント情報がインターネットに露出していないことを確認する。 もし可能であれば、二要素認証（二段階認証）を実装する。

(7) Insecure Mobile Interface（セキュリティが確保されていないモバイルインターフ

ェイス） モバイルインターフェイスのセキュリティを確保するには：

最初のアカウント設定時に、パスワードをデフォルトのものから変更するよう、必

48

ずユーザに要求する。できればユーザ名も変更できるのが理想的である。 パスワード再設定メカニズム等の機能を使用することで、ユーザアカウントが列

挙表示されないことを確認する。 ログインに 3～5 回失敗した場合には、そのアカウントをロックアウト（一時的に

使用不可能に）する。 パスワード再設定メカニズムや新規ユーザページなどから、正規アカウントの情

報が特定できないようにする。 アカウント情報がワイヤレスネットワーク上で盗聴できないことを確認する。 もし可能であれば、二要素認証（二段階認証）を実装する。

(8) Insufficient Security Configurability（不十分なセキュリティ設定） 不十分なセキュリティ設定を改善するには：

機器の管理インターフェイスを見直し、より強力なパスワードの使用を必須とす

る。 管理ユーザと通常のユーザを分離する仕組みを導入する。 保管と伝送の両方の状態においてデータの暗号化を行う。 セキュリティ関連のイベントをログとして残す機能を導入する。 セキュリティ関連のイベントが発生した際に、アラートや通知をエンドユーザに

送信する仕組みを導入する。 (9) Insecure Software/Firmware（セキュリティが確保されていないソフトウェア/ファ

ームウェア） ソフトウェア/ファームウェアのセキュリティを確保するには：

最も重要なことは、機器自体がアップデート機能を実装しており、定期的にアップ

デート可能であることである。まず使用機器がこの条件を満たしていることを確認す

る。 アップデートファイル中の重要な情報が、バイナリエディタ等を使用することで

可読状態にならないことを確認する。 アップデートファイルが、一般に認められたアルゴリズムを使用し、正しく暗号化

されていることを確認する。 アップデートファイルが、暗号化された接続によって送信されていることを確認

する。 アップデート用サーバに脆弱性がなく、適切に設定され、セキュアな状態であるこ

とを確認する。 アップデートファイルが、アップロード/適用される前に正しく署名され、その内

容が検証されていることを確認する。

49

(10) Poor Physical Security（物理的セキュリティの脆弱さ） 物理的セキュリティを強化するには：

機器類が容易に分解できない状態になっていることを確認する。 データ保存用のメディアが容易に取り出せない状態になっていることを確認する。 保管時のデータが暗号化されていることを確認する。 USB などの外部ポートを使って不正に機器にアクセスできないことを確認する。 運用に本当に必要な外部ポートのみが装備されていることを確認する。 管理機能がローカルなアクセスのみに制限できることを確認する。

OWASP のサイトでは、攻撃者が攻撃可能となる条件、攻撃手法や侵入経路、脆弱性がど

のような状況で生じるのか、技術面とビジネス面へのインパクト（影響）についても解説さ

れている。

50

文献調査におけるセキュリティ要件及びユースケース等の検討

セキュリティ要件の抽出 国内外の標準規格（国際規格、民間・業界規格等）、及びガイドライン等の調査を行

い、IoT 機器に求められるセキュリティ要件を抽出した。評価・試験制度等の標準規格で

は、評価項目やセキュリティ要件を定めているが、ガイドラインでは脅威への対策として

まとめられているため、これらの対策からセキュリティ要求仕様として抽出した。詳細

は、別添 1 を参照。なお、評価・試験制度のなかで、前述した UL（Underwriters Laboratories Inc.）、UL CAP（Cybersecurity Assurance Program）については、現在、

IoT 機器等の評価に特化した規格を策定中 17であるため、詳細な評価項目、試験項目は不

明であるため、本資料の参考情報に UL2900 の目次構成を記載した。 国内外の標準規格及びガイドライン等からセキュリティ要件を抽出した結果、セキュリ

ティ要件を以下の 3 種類の対策に分類した。 • 技術的な対策 • 物理・環境的に関する対策 • 人的及び運用を伴う対策

技術的な対策は、IoT 機器等に求められるセキュリティ要件を満たす機能として実装され

たセキュリティ機能である。物理・環境的に関する対策は、入室管理や盗難防止等に関する

もの対策も含まれる対策である。人的及び運用を伴う対策は、IoT 機器の設計開発手法や

IoT 機器の運用等に関する対策である。 さらに、前述した「ISO/IEC 15408」、「IoT 開発におけるセキュリティ設計の手引き」以

外の文献について、ガイドラインの脅威への対策と評価・試験制度等の標準規格のセキュリ

ティ機能要件を抽出し、これら 10 分類に整理した。整理した結果を以下に示す。

表 3.3-1 文献調査から抽出した IoT 機器に求められるセキュリティ要件 1 1. 認証（機器認証） 2. データ暗号化（ユーザデータの暗号化、及び一部アクセス制御も含む） 3. 暗号化通信（メッセージ認証含む） 4. データ消去 5. 機能の完全性検証（実行ソフトウェアの検証/認証） 6. セキュリティパッチ／アップデート／脆弱性対策 7. 管理機能（設定変更・管理機能を提供する場合） 8. ログ／監査生成・保管機能 9. 物理セキュリティ

17 インタビュー調査の結果、IoT 機器等の評価に特化した規格は、UL2900 に追加する評価項目・試験

項目として策定する予定。

51

10. その他（以下詳細分類は要検討） 11. 開発に関するセキュリティ 12. ユーザマニュアル（ガイダンス）

その他は、対策内容として記述されているが実現方法がセキュリティ機能としての分類

が難しいものであり、実態として運用面での対策が多い内容であり、詳細分類はさらに検討

する必要がある。 • フィルタリング機能 • ファイアウォール機能 • 不正侵入検知・防御対策（IDS/IPS 等） • アンチウィルス／マルウェア対策 • DoS 対策 • 知的財産（ソフトウェア） また、「11.開発に関するセキュリティ」は、開発環境や規定及び設計書等のドキュメント

類を含んだ評価である。「12.ユーザマニュアル（ガイダンス）」は、利用者や運用者、管理

者向けの取扱説明書に機器の設定や、設置環境の設定等、機器を利用・運用するための設定

が正しく記載されているかの評価である。なお、これらの抽出結果を含めたユースケースに

基づくセキュリティ機能の抽出については、以降の 3.3.2 で詳細を記載する。

ガイドライン等におけるユースケースについて IoT 機器に求められるセキュリティ要件は想定されるユースケースにより異なるため、

また 3.3.1 で抽出したセキュリティ要件を詳細化するため、今回の文献調査対象であるガ

イドラインを基に各ユースケースに求められるセキュリティ機能と調査した。ユースケー

スを調査したガイドライン等を以下に示す。 • 「IoT 開発におけるセキュリティ設計の手引き（IPA）」 • 「コンシューマ向け IoT セキュリティガイド（JNSA）」

上記のガイドラインでは脅威への対策としてまとめられているため、これらの対策から

セキュリティ機能を想定し、さらに両ガイドラインで要求している対策内容の記載を確認

し、共通していると考えられるセキュリティ機能及び用語を「IoT 開発におけるセキュリ

ティ設計の手引き（IPA）」に統一した。両ガイドライン等に記載されているユースケース

は、IoT 開発におけるセキュリティ設計の手引き（IPA）では、デジタルテレビ、ヘルス

ケア、スマートハウス、コネクテッドカーであり、コンシューマ向け IoT セキュリティガ

イド（JNSA）では、スマートテレビ、ウエアラブルデバイス、ネットワークカメラであ

52

る。これらのユースケースで求められているセキュリティ機能を表 3.3-2 に示す。すべて

のユースケースにおいて IoT 機器に求められているセキュリティ機能は、「ユーザ認証」、

「セキュア消去」、「通信路暗号化」の 3 つである。

表 3.3-2 文献調査から抽出した IoT 機器に求められるセキュリティ要件 2 ガイドライン記載の分野

ガイドライン

記載の機能・対策

IPA JNSA

デジタルテレビ

ヘルスケア

スマートハウス

コネクテッドカー

スマートテレビ

ウエアラブルデバイス

ネットワークカメラ

1 ユーザ認証 ◯ ◯ ◯ ◯ ◯ ◯ ◯

2 セキュア消去 ◯ ◯ ◯ ◯ ◯ ◯ ◯ 3 通信路暗号化 ◯ ◯ ◯ ◯ ◯ ◯ ◯

4 脆弱性対策 ◯ ◯ ◯ ◯ ◯ ◯

5 FW 機能 ◯ ◯ ◯ ◯ ◯ ◯ 6 耐タンパーH/W ◯ ◯ ◯ ◯ ◯ ◯

7 データ暗号化 ◯ ◯ ◯ ◯ ◯ 8 出荷時状態リセット ◯ ◯ ◯ ◯ ◯

9 耐タンパーS/W ◯ ◯ ◯ ◯

10 動作のモニタリング ◯ ◯ ◯ ◯

11 説明書周知徹底 ◯

◯

◯

12 アンチウイルス ◯ ◯ ◯

13 DoS 対策 ◯ ◯ ◯

14 IDS ◯ ◯ ◯

15 構成の更新・チェック ◯ ◯ ◯

16 問合せ先表示 ◯ ◯ ◯

17 ソフトウェア署名 ◯ ◯

18 接続端末認証 ◯ ◯

19 ホワイトリスト制御 ◯ ◯

20 設定の初期化 ◯ ◯

21 ログ ◯

◯

22 遠隔ロック ◯

23 メッセージ認証 ◯

24 接続先認証 ◯

53

ガイドライン記載の分野

ガイドライン

記載の機能・対策

IPA JNSA

デジタルテレビ

ヘルスケア

スマートハウス

コネクテッドカー

スマートテレビ

ウエアラブルデバイス

ネットワークカメラ

25 異常検知・通知 ◯

26 データの初期化 ◯

27 セキュア開発

評価・試験制度における評価手法について 文献調査対象の評価・試験制度における評価手法は、以下の 3 つに大別できる。ドキュ

メント類の評価は、開発や製造に係るドキュメントに対する評価と利用者や運用・管理者

に係るガイダンスやマニュアル等の評価が含まれ、これらの記述内容と評価対象物自体の

評価を行う。実機を用いた評価は、評価対象物全体を評価する場合や評価対象物全体では

なく一部の構成物に対して評価する場合があり、評価の手法には、大きくハードウェアに

対する評価、ソフトウェアに対する評価、また、ハードウェア及びソフトウェアの評価双

方の一部として実施する場合と独立して実施する場合があるが、ソースコード解析やイン

タフェースの評価（インタフェースの評価にはプロトコルの評価も含まれる場合もある）

を行う。さらに、その他の評価として、開発環境や構成管理に関するマネジメントの評価

を行う。これらの評価の中で、インタフェース（プロトコル）評価については、一般的に

脆弱性診断等として試験する内容も含み各種のツール等もあり、セキュリティベンダがサ

ービスを行っている状況である。 1. ドキュメント類の評価

• 基本設計 • 機能仕様 • 内部設計 • 詳細設計 • 開発者テスト • ガイダンス（マニュアル類）

2. 実機を用いた評価

• ハードウェア評価

54

• ソフトウェア評価 • ソースコード解析 • インタフェース（プロトコル）評価

3. その他

• 開発環境の評価 • 構成管理を含むマネジメント

IoT 機器のリスク分析とセキュリティ評価手法の整理

3.1 節から 3.3 節にて調査した既存の要件・評価手法及び IoT 機器の特性やユースケース

等を踏まえた IoT 機器のセキュリティ要件に対する評価手法を整理し、特徴的な IoT 機器

（最大 3 製品程度）を抽出して評価手法の妥当性を検証するための試行試験（テスト評価）

の内容を検討した。以下に、その概要を報告する。なお、本調査検討に求められるセキュリ

ティ評価手法及びテスト評価については、汎用性が高く、共通した評価手法であるため、以

下の各検討においてもこれらの観点から検討した。

(1) テスト評価対象 テスト評価対象は、試行試験が可能な領域として、クラウド環境以外とした（クラウドサ

ービスに対する試行試験の影響を考慮し、クラウドサービスへの試行試験を行わないこと

とした）。また、具体的な評価対象としては、IoT 機器に IoT ゲートウェイを加えることと

した。

(2) 評価対象のセキュリティ機能 3.3.1 及び 3.3.2 に示した通り、文献調査対象のユースケースのすべてにおいて IoT 機器

に求められているセキュリティ機能である「ユーザ認証」、「セキュア消去」、「通信路暗号化」

の 3 つから以下の(3) 具体的な評価手法を考慮し、「セキュア消去」を除く、「ユーザ認証」、

「通信路暗号化」を評価対象のセキュリティ機能とした。 ユーザ認証は、IoT 機器の利用者を認証する機能であり、IoT 機器の利用者には、一般的

な利用者と IoT 機器の設定や管理を行う管理者を想定し、これら IoT 機器が提供するサー

ビスの違いを考慮し、IoT 機器が一般利用者と管理者を分けて認証する場合は、その各々の

認証機能を評価することとした。 通信路暗号化については、IoT 機器が通信相手となるサーバーとの通信において行う機能

であり、サーバとの暗号化通信の前には、サービの認証が含まれる。そのため、通信路暗号

化については、サーバ認証を加えて評価することとした。

55

さらに、ユーザ認証及び通信路暗号化が正しく動作していることを確認する意味からロ

グ機能についても補間的に確認することとした。

(3) 具体的な評価手法 3.3.3 に示した通り、各種の評価ツールがあり、セキュリティベンダがサービスを行って

いる状況であり、汎用性が高いことからインタフェース（プロトコル）の評価として脆弱性

診断の手法（ペネトレーションテスト等）を想定した評価手法とした。

56

IoT 機器のテスト評価による妥当性検証

3 章の調査・検討結果を踏まえ、国内における IoT 機器のセキュリティ評価の手法の検討

を行った。特に 4 章で整理した各評価手法に基づいて、それぞれを具体的に評価・検証した

手法を報告する。なお、これらの評価手法は、実機を用いたテスト評価を行い、前章にて定

めたセキュリティ機能を問題なく確認できた。この検証の結果、評価作業と評価レポート作

成を含めた評価期間は、1 機器につき 1 週間から 2 週間程度で完了する。以下に、これらの

評価手法及び妥当性を検証した結果を反映した内容を報告する。

通信

クライアントと IoT 機器の通信 スマートフォン・PC・専用端末などと IoT 機器が IP 通信を行う場合、中間者攻撃が行わ

れると、情報漏洩や不正な動作をさせられる可能性がある。これを防ぐには、通信の暗号化

とサーバの認証が必要になり、一般的に SSL/TLS が使われる。 クライアントと IoT 機器の通信は、管理者機能を提供するためのサーバ機能や、機器固有

の通信（IoT 機器を動作させるための命令や他の機器から情報を受け取る）が考えられる。

それぞれが異なるポートで提供されている場合は、個別に評価を行う。

4.1.1.1 IoT 機器のサービス調査

# nmap -p- -sV 192.168.126.1

Starting Nmap 7.31 ( https://nmap.org ) at 2017-02-20 15:13 JST

Nmap scan report for 192.168.126.1

Host is up (0.0011s latency).

Not shown: 39074 closed ports, 26457 filtered ports

PORT STATE SERVICE VERSION

53/tcp open domain dnsmasq 2.40

80/tcp open http Apache httpd 2.4.10 ((Unix) PHP/5.5.20 OpenSSL/0.9.8ze)

443/tcp open ssl/http Apache httpd 2.4.10 ((Unix) PHP/5.5.20 OpenSSL/0.9.8ze)

10080/tcp open http Apache httpd 2.4.10 ((Unix) PHP/5.5.20 OpenSSL/0.9.8ze)

MAC Address: XX:XX:XX:95:67:BA (Compal Information (kunshan))

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 9783.76 seconds

#

57

この例では、53,80,443,10080 の 4 つが開いていて、443 のみ SSL/TLS が使われている

ことがわかる。

4.1.1.2 IoT 機器の対応プロトコル・暗号方式

(1) SSL/TLS SSL/TLS を使用したポートがある場合、そのポートのサーバがサポートするプロトコル

や暗号方式を調査する。調査には、次のように sslscan というツールを使うと容易に確認で

きる。

# sslscan 192.168.126.1:443

Version: 1.11.8-static

OpenSSL 1.0.2k-dev xx XXX xxxx

Testing SSL server 192.168.126.1 on port 443

TLS Fallback SCSV:

Server does not support TLS Fallback SCSV

TLS renegotiation:

Secure session renegotiation supported

TLS Compression:

Compression disabled

Heartbleed:

TLS 1.2 not vulnerable to heartbleed

TLS 1.1 not vulnerable to heartbleed

TLS 1.0 not vulnerable to heartbleed

Supported Server Cipher(s):

Preferred TLSv1.0 256 bits DHE-RSA-AES256-SHA DHE 1024 bits

Accepted TLSv1.0 256 bits AES256-SHA

Accepted TLSv1.0 128 bits DHE-RSA-AES128-SHA DHE 1024 bits

Accepted TLSv1.0 128 bits AES128-SHA

Accepted TLSv1.0 128 bits IDEA-CBC-SHA

Accepted TLSv1.0 128 bits RC4-SHA

58

Accepted TLSv1.0 112 bits EDH-RSA-DES-CBC3-SHA DHE 1024 bits

Accepted TLSv1.0 112 bits DES-CBC3-SHA

Preferred SSLv3 256 bits DHE-RSA-AES256-SHA DHE 1024 bits

Accepted SSLv3 256 bits AES256-SHA

Accepted SSLv3 128 bits DHE-RSA-AES128-SHA DHE 1024 bits

Accepted SSLv3 128 bits AES128-SHA

Accepted SSLv3 128 bits IDEA-CBC-SHA

Accepted SSLv3 128 bits RC4-SHA

Accepted SSLv3 112 bits EDH-RSA-DES-CBC3-SHA DHE 1024 bits

Accepted SSLv3 112 bits DES-CBC3-SHA

SSL Certificate:

Signature Algorithm: sha1WithRSAEncryption

RSA Key Strength: 1024

Subject: www.example.jp

Issuer: www.example.jp

Not valid before: Jan 17 14:17:13 2011 GMT

Not valid after: Jan 12 14:17:13 2031 GMT

この例では、TLSv1.0 と SSLv3 をサポートしており、それぞれ８種類の暗号方式をサポ

ートしていることがわかる。

暗号ライブラリ IoT 機器が正しいプロトコルで暗号を利用しているか確認するために、実装や設計書で使

用している暗号ライブラリの種類やバージョンを確認する。一般的に安全性が確認された

ライブラリが使用されていれば問題ないが、独自実装の暗号ライブラリの場合には実装が

正しいか詳細に検証が必要となる可能性があり、その検証には設計書あるいはソースコー

ドなどが必要になる場合がある。

サーバ証明書 IoT 機器が SSL/TLS を使用する場合、信頼できる認証局から発行された証明書を使用す

ることが望ましい。管理画面等から、秘密鍵と証明書をインポートする機能があるかどうか、

あるいは秘密鍵と CSR(Certificate Signing Request)を生成し証明書をインポートする機

能があるかどうかを確認する。

59

IoT 機器と外部の通信

クラウド上のサーバなど外部のサーバに対して情報を送信する、あるいはサーバからデー

タやコマンドを受け取って動作する IoT 機器において、中間者攻撃が行われると、情報漏

洩や不正アクセスの被害を受ける可能性がある。これを防ぐには、通信の暗号化とサーバの

認証が必要になり、一般的に SSL/TLS が使われる。この SSL/TLS が安全に実装されてい

るかどうかを検証する。

IoT 機器の対応プロトコル・暗号方式 IoT 機器が対応しているプロトコルや暗号方式、実際にサーバとの通信に使用されるプロ

トコルや暗号方式は、通信パケットをキャプチャすることで確認できる。サーバと通信を行

わせ、そのパケットをキャプチャして確認する。一連のパケットのうち Client Hello メッ

セージから、IoT 機器がサポートするプロトコルと暗号方式が確認できる。Wireshark で

Client Hello メッセージをキャプチャした際の画面を図 4-1 に示す。このメッセージのう

ち、Handshake Type の項目に注目することにより、この機器は TLS 1.0 をサポートして

いることがわかる。また、同じメッセージ内に、対応する暗号方式がリストアップされてい

る（図 4-2）。この機器では、16 種類の暗号方式に対応していることがわかる。

60

図 4-1 ClientHello メッセージの Handshake Type

図 4-2 ClientHello メッセージの Ciper Suites

61

実際にサーバとの通信に使われるプロトコルと暗号方式は、サーバから送られてくる

Server Hello メッセージで確認できる。Wireshark で Server Hello メッセージをキャプチ

ャした際の画面を図 4-3 に示す。この画面より、プロトコルには TLS 1.0 を、暗号方式に

は TLS_RSA_WITH_DES_CBC_SHA が選択されたことが確認できる。

図 4-3 Server Hello メッセージ

サーバ認証 サーバの認証が正しく行われているかどうかは、自己署名の証明書を使った偽のサーバ

を用意し、そのサーバと通信させ、通信ができないことで確認できる。 IoT 機器が通信しているサーバの IP アドレスとポート番号は、パケットキャプチャで確認

できる。また、サーバのホスト名は、図 4-4 の通りサーバからの Certificates メッセージで

受け取る証明書の内容から確認できる。

62

図 4-4 Certificates メッセージ

まず、自己署名の証明書を作成する。作成には、次の通り openssl を使用し 3 つのコマン

ドを実行する。証明書のサブジェクトは、実際のサーバ証明書の内容と同一にしておく。

$ openssl genrsa -out server.key 2048

Generating RSA private key, 2048 bit long modulus

...........................+++

...............+++

e is 65537 (0x10001)

$ openssl req -new -key server.key -subj '/C=JP/ST=Kanagawa/L=Kawasaki-

shi/O=Sample Organization/OU=Sample Organization Unit/CN=example.jp' -out

server.csr

$ openssl x509 -days 10 -req -signkey server.key -in server.csr -out server.crt

Signature ok

subject=/C=JP/ST=Kanagawa/L=Kawasaki-shi/O=Sample Organization /OU=Sample

Organization Unit/CN=example.jp

Getting Private key

63

$

続いてクローズなネットワーク内で、検証用のPCにサーバと同じ IPアドレスを設定し、

上記で作成した秘密鍵と証明書を使用し次のように接続を待ち受ける。

# openssl s_server -key server.key -cert server.crt -accept 443 -quiet

正しくサーバの認証が行われている場合、中間者攻撃を検知して切断するため、HTTP リ

クエストなどの通信は行われない。サーバの認証が行われていない場合は、次のようにリク

エストが送信されて来てしまい、送られてきたリクエストが見えてしまう。

# openssl s_server -key server.key -cert server.crt -accept 443 -quiet

GET /cgi-bin/ServerCooperation/top.cgi HTTP/1.1

Host: example.jp

Cache-Control: max-age=0

Authorization: Basic cm9vdDpwYXNz

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like

Gecko) Chrome/55.0.2883.87 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Encoding: gzip, deflate, sdch

Accept-Language: ja,en-US;q=0.8,en;q=0.6

X-Forwarded-For: 192.168.126.10

X-Forwarded-Host: 192.168.126.1

Connection: Keep-Alive

サーバ証明書失効リストの確認有無 証明書内に、証明書に失効リストの公開場所が記載されている。証明書内の失効リストの

公開場所は、次のコマンドで確認できる。

$ openssl x509 -in server.crt

（一部抜粋）

X509v3 CRL Distribution Points:

Full Name:

64

URI:http://ss.symcb.com/ss.crl

この証明書失効リストへアクセスしているかどうか、パケットキャプチャを行って確認

する。

認証

管理者認証 ネットワーク経由で機器の管理を行える機能がある場合には、実機で検証を行う。管理機能

へのアクセスは一般的に、Web インタフェース、telnet や ssh 等のコンソール、独自イン

タフェースのいずれかで実装されていることが多い。

4.3.1.1 機器管理機能にパスワード認証があるか

管理機能にアクセスし、パスワード認証が要求されることを確認する。管理機能へのアクセ

ス方法や初期アカウント情報は、通常マニュアルや同封の用紙、機器本体などに記載されて

いる。一度もパスワード認証を行わずに管理機能（機器の再起動やネットワーク設定など）

を利用できた場合は、認証がないと判断する。

4.3.1.2 初回管理者認証時にパスワード変更を要求されるか

初回パスワード認証時に、新規パスワードの設定を要求されることを確認する。パスワー

ド変更画面が表示された場合は、パスワード変更をせずに切断・機器の再起動し再度初期パ

スワードで認証を行い、パスワード変更画面が表示されることを確認する。

4.3.1.3 初期パスワードの確認

製品によっては、複数の機器で同じ初期パスワードを使い回していることがある。そのパ

スワードを変えずに使用している場合、攻撃者に初期パスワードが知られ不正アクセスを

受ける可能性が高まる。機器ごとに異なる初期パスワードがつけられているかどうかを確

認する。機器自身に貼り付けられたシールに書かれている場合や、パスワードが印刷された

紙が同封されてている場合が多い。一方でマニュアルに簡単なパスワードが記載されてい

る場合は、パスワードが使い回されている可能性が高い。 正確に検証するには、2 台以上の機器を用意し初期パスワードが同一かどうかを確認する。

利用者認証 管理者機能以外に、IoT 機器で使用する各プロトコルにおいて、利用者認証が行われてい

るかどうか確認する。認証機能の有無は、以下で判断する。

65

1. 管理機能で、新規ユーザ追加やパスワード変更などアカウント管理の概念があるか

どうか 2. パケットをキャプチャし、認証情報が通信されているかどうか

より正確に確認するには、プロトコル仕様を確認しユーザ認証の機能があるか確認するこ

とが望ましい。

ログ機能

IoT 機器自身が取得するログについて検証を行う。ログ機能は、管理者機能の一部として

実装されていることが多く、管理者機能のインタフェースを操作して確認する。また、実機

で全てのログを出力させて確認することは困難であるため、マニュアルや設計書などから

出力されうるログの内容を机上で確認する。

ログの内容 どのようなログ情報が記録されるかを確認する。例えば、次のような内容が日時とともに

ログに記録されると考えられる。 管理者や一般ユーザの認証成否 設定変更内容 IoT 機器の操作内容 各種エラー

ログの保存方法 出力されたログが、どの程度の期間、どこに保存されるかを確認する。機器によってはロ

グのエクスポート機能や、syslog やメールなどで他のサーバに転送する機能がある場合も

ある。また、本体のメモリ内のみに保存される場合は、再起動や電源オフによって消失する

かどうかも確認する。

利用したツール

本章に記述した検証を行うために利用したツールを次に挙げる。 ● nmap ( https://nmap.org/ ) ● openssl ( https://www.openssl.org/ ) ● Wireshark ( https://www.wireshark.org/ ) ● sslscan ( https://gitnub.com/rbsec/sslscan )

66

国内における IoT 機器のセキュリティ評価の在り方に関する検討

3 章から 4 章の調査・検討結果を踏まえ、国内における IoT 機器のセキュリティ評価の在

り方に関する検討を行なった。この検討については、6 章で示すセキュリティに関わる専門

家、IoT 機器の製造事業者、利用者、第三者評価に関連する事業者等から構成するワーキン

ググループにて実施した。具体的には、IoT 機器の種別や特性・ユースケースに応じた評価

手法、評価ツールの機能や提供方法、想定する評価実施主体の在り方や事業性を検討した。 なお、「認証」は、国際認定機関フォーラム（International Accreditation Forum 、IAF）

に加盟する認定機関が認定した認証機関が必要である。一方、本調査検討では、既存の評価・

試験制度を調査し、その調査結果を基に比較や検討を行うため、便宜上、「認証」という呼

称で検討するが、国際標準による認証や保証を意図していない。 以下に、IoT セキュリティ評価 WG の第 1 回から第 3 回の中心的な議論であった「IoT 機

器のセキュリティ評価の必要性」を 5.1 節に、「IoT のセキュリティ評価の考え方」を 5.2 節

に、「評価の基準と表示」を 5.3 節に、「評価スキーム」を 5.4 節に、「検討課題」を 5.5 節

に報告する。

IoT 機器のセキュリティ評価の必要性

IoT 機器で構成されるシステムに関するセキュリティ機能は、基本的に既存の情報システ

ム（インターネットシステム、クラウドシステム）と同様とも考えられる。ただし、既存の

情報システムのリスクは、扱うデータのセキュリティ（完全性、可用性、機密性）であるが、

IoT 機器で構成されるシステムは、機能操作や生命安全への直接影響など、現実世界の影響

範囲が拡大していると考えられる。さらに、IoT 機器のセキュリティ機能は、その単体で完

成品として考慮され、調達されシステムに組み込まれるため、システム設計者や調達者から

みて、事前に仕様を定め、セキュリティの機能やその評価（認定）が明らかにされるよう指

標を定めていることが望ましい。そのため、これらの必要性を考慮し、IoT 機器に求められ

るセキュリティ評価を検討することとした。

IoT のセキュリティ評価の考え方

評価対象を絞り込むことで、現状の IoT を想定した評価期間、評価費用で実施可能な評

価を行うことが可能になる。これらの評価対象の絞り込みについて検討を行った結果を IoTのセキュリティ評価（案）として報告する。 既存のセキュリティ評価制度を調査した結果、 医療関係やコネクテッドカー及び制御シ

ステム等の高度なセキュリティ機能を実装し、そのセキュリティ機能を確認する一部の分

野を除き、現状の IoT を想定した評価期間、評価費用について評価要求と乖離している可

能性について議論された。例えば、現状の第三者評価による評価期間がクラウドは半年であ

67

り、GW、IoT 機器（エッジ）の各々が最短でも 3 ヶ月であり、費用感も含めて、IoT 機器

やシステムに見合わない可能性がある。そのため、IoT 機器やシステムを対象とした適切な

規模での評価の実施を行うべきかについて検討した。

評価対象の IoT 機器について 前述の通り、クラウド側（センター側）の評価は、長期間且つ評価費用が高額になる場合

がある。また、クラウドについては、すでに ISO/IEC27017 やシステム監査等の評価も存

在するため、これらの認証結果を確認することでクラウド側の評価を兼ねることも考えら

れる。そのため、クラウドと IoT 機器など分離してセキュリティの評価を行い、最終的に全

システムを統合したセキュリティ評価を行うこともできる。さらに、IoT のベンチャーは主

にエッジデバイス（IoT 機器）の製造を行うことが多く、一定のセキュリティを評価し、信

頼性を示すことで産業振興の効果も考えられる。以上のことから、IoT 機器に限定して評価

を行い、必要に応じて IoT システム全体の評価を実施することで IoT 機器やシステムを対

象とした適切な規模での評価することを検討した。

評価対象プロトコルについて 上記同様に、汎用的で様々な分野で利用可能なセキュリティ機能を評価するために、評価

対象のプロトコルを一般的なインターネットプロトコルに限定するという考え方もある。

現状の評価スキームは、評価対象物に実装しているセキュリティ機能を詳細に確認するが、

短期に確認できる方法としては、評価対象物が外部の機器やシステムをやり取りするプロ

トコルを確認し外形的に挙動を確認する方法が考えられる。プロトコル上での評価は、イン

ターネットに接続することを前提としている IoT に適した評価でもある。さらに、標準的

なインターネットを利用する IoT 機器やシステムは今後も拡大することが考えられる。標

準的なプロトコルであるため、その評価方法や手法について、標準化、一般化しやすいとい

うメリットがある。

評価対象機能について 上記の通り、 IoT 機器が外部とやり取りするプロトコル上での評価に限定することで、

IoT 機器が満たすべきセキュリティ機能の一部にはなるものの、簡易的かつ短期間にセキュ

リティ機能を評価することができる。NDcPP 等も参考に、試行試験の結果も踏まえ、本調

査検討の試行試験では、認証機能（サーバ認証機能、ユーザ認証機能を含む）、暗号化通信

機能等のセキュリティ機能に限定して評価を行った。 なお、各種のガイドライン調査の結果を踏まえると上記に追加し、今後は、DoS 対策やフ

ィルタリング機能、アップデート機能等も要検討になるが、これらは、ユースケースや特定

の分野により機能の有無及び機能自体が異なるため引き続き検討する必要がある。さらに、

外筐を操作することで容易に確認できる場合もある出荷時状態へのリセット機能等も、今

68

後のユースケースの調査に応じて要検討になる。

評価の基準と表示について

評価の基準について 評価基準については、評価対象となるセキュリティ機能について基準／ラインを示す場

合や特定のセキュリティ機能について◯✕式で示す星取表の形式で示すことも考えられる。

これらの基準について検討した結果として、評価の基準とその形式及び表示について検討

した結果を示す。「認証/合否判定」方法は、基準を示すことで合否結果を明確に示すことが

できる一方で、ユースケース毎に基準を作成する必要がある。「星取表」方法は、基準を示

さないためユースケース毎に基準を作成する必要がなく拡張性があるが、合否結果を明確

に示すことができない。

表 5.3-1 評価基準と評価結果の表示の検討概要 方法 認証／合否判定 星取表

概要 ある程度共通化されたセキュリティ要

件と、各要件の合格基準を設け、合格

した製品のみリストアップされる。

セキュリティ要件（共通機能のみであ

る必要は無い）毎に満たしているか、

否かを◯✕で示す。もしくはどのレベ

ルで満たしているかが全ての製品に関

して公示される。 関係者へ

の影響 調達者・

利用者 メリット 共通セットのセ

キュリティ機能

や脆弱性対策を

満たした製品を

簡単に見分ける

ことができる。

デメリット 共通セット以外

のセキュリティ

機能を確認した

い時は、調達者が

独自にテストを

行う必要がある。

メリット ・調達要件に併せ

てその要件を満

たす製品を選定

できる。 ・必要に応じて多

様な機能が評価

項目となる。

デメリット ・調達時に要件を

定義する知見が

必要となる。 ・○の場合でもど

の程度安全かの

理解が調達者責

任となる。 ベンダ メリット

共通セットのセ

キュリティ機能

や脆弱性対策を

満たした製品で

あることを明確

に示すことがで

きる。

デメリット ・基準を満たさな

かった場合、かか

った工数が無駄

になる。または再

開発を要する。 ・合格が出荷条件

の製品は開発ス

ケジュールと認

証取得をリンク

させる必要があ

る。

メリット ・申請したもの

は、全てリストに

載せることが可

能であり、評価コ

ストが無駄にな

らない。 ・申請開発のタイ

ミングとリンク

させる必要はな

い。

デメリット ・共通セットのセ

キュリティ機能

や脆弱性対策を

満たした製品で

あることを明確

に示すことがで

きない。 ・申請したもの

は、全てリストに

載せることが可

能であり、自らの

製品がわかりに

くくなる可能性

がある。 制度・ス

キーム 制度運用 ・要件に加え、合格基準を設ける必要

がある。 ・基準に合わない場合も想定すると認

証製品が少なくなる可能性がある。

調達からの要件に併せて評価するセキ

ュリティ機能の追加が発生する。

69

方法 認証／合否判定 星取表

対応可能

スキーム 全て可能※1

全て可能※1

評価結果

の見せ方 評価結果

提示方法 リストアップ以外に「認証書」、「認証

マーク」の発行が可能 リストアップのみ

リストア

ップ方法 ・製品毎に合否の提示 ・複数基準によるレベル分けなどは検

討可能

・○×だけではなく、○の場合、その

実装レベルを記載可能 ・脆弱性を晒すことにもなる。

ツールの適用 可能※2 可能※2 ※1：認定機関を含む第三者評価から第二者評価間まで可能。

※2：但し、脆弱性診断などツール化が困難な要件は手動によるテストや評価が必要。

評価結果の表示について 評価結果の表示（評価結果の見せ方）については、認証書及び認証マークを発行すること、

及び認証リストの公開が考えられる。これらの評価結果の見せ方に関する詳細を以下に報

告する。IoT 機器の調達者は「認定マーク」と「認証リスト」を求め、IoT 機器ベンダは「認

定マーク」を求める意見があった。

表 5.3-2 評価結果の見せ方の詳細 No 方法 検討結果

1 認証書発行 • 既存の認証スキームでは、認証書を発行することが一般的である。

• 以下 2 の認証マークとともに発行するケースも多い。

2 認証マーク

発行

• 調達者にとっては、認証取得した IoT 機器であることが理解できるた

め、認証マークの発行を求める意見があった。

• また、IoT 機器製造の一部でも自らが製造した IoT 機器のセキュリティ

対策を示すことができるため認証マークの発行を求める意見があった。

3 認証リスト

公開

• IoT 機器の問合せ等を明確にするために認証リストの公開を求める意

見があった。

• また、IoT 機器にソフトウェアやファームウェアのアップデート機能が

実装されている場合、認証された IoT 機器のリストだけではなく、IoT

機器の製造した企業の存在についてもリスト化して公開すべきである

という意見もあった。

その他、IoT 機器の調達者は、セキュリティの専門知識を持っていない一般消費者になる

場合があり、ライフサイクル（耐用年数／稼働年数）が長い傾向にある。そのため、IoT 機

器の認証評価結果を表示する場合、表示の意味と内容を上手く消費者に伝える仕組みを考

慮し、システムやサービス全体のセキュリティを保証していると誤認されない工夫も必要

である。

70

評価ツールについて 上記の認証スキームなどの検討を踏まえ、本事業で検討した評価対象となるセキュリテ

ィ機能、及び試験手順を評価ツールにすることを検討した結果を示す。 なお、本調査検討では、IoT 製品に対してテスト評価を実施した結果、機能毎に具体的な

試験項目、判断基準を提示することで求められるセキュリティ機能を確認できた。これらの

結果を基に、評価ツール等を検討することにより結果判断を自動化する評価ツールを開発

することも検討が可能である。

表 5.3-3 評価ツールの検討概要 No 提供形態 内容 想定読者 検討内容・懸念点

IoT 機器

製造者 調達者・

利用者 1 ガイドライ

ン 評価の考え方やスコープ

等を含め、評価方法や手

順等をガイドラインとし

て取り纏める

◯ ◯

IoT 関連のガイドラインが多く公表され

ているため埋もれてしまう可能性があ

る。また、IoT 推進コンソーシアムとの

関連を整理する必要もある。

2 チェックリ

スト 評価すべきセキュリティ

機能をチェックリストと

して取り纏める ◯ ◯

特に調達者からはチェックリストを要求

する意見があったため作成する必要があ

ると考えられる。

3 評価・試験

手順書 評価すべきセキュリティ

機能を試験方法及び手順

などを手順書として取り

纏める

◯ －

後述する第二者評価 2 では必須のである

ため作成する必要がある。

4 評価ツール 評価期間が、評価ツール

を開発（または委託）

し、評価申請者に貸し出

す 貸出 －

後述する第二者評価 2 では評価ツールが

あることが望ましいが、評価ツールは、

最新の脆弱性の取り込み/特定分野への

カスタマイズなどを行う必要があり、評

価者（評価主体）により対応が異なる可

能性がある。

評価スキームについて

認証には、評価申請者、評価者、認証者で構成する第三者認証スキームと評価申請者、評

価者で構成する第二者認証スキームがある。これらの認証スキームについて検討した結果

を案として示す。

(1) 第三者評価スキームについて 第三者評価は、評価及び評価結果を複数の関係者が確認するため、客観性や信頼性が担保

でき、同様の理由から評価者のスキルについても一定程度は担保できることが期待できる。

一方で、複数の関係者が関与するために、費用や期間などのコストが下記に比べ高くなる可

能性がある。第三者評価は、CC や CMVP など厳密な評価に用いられるスキームと考えら

れる。

71

(2) 第二者評価スキームについて

第二者評価は、上記の第三者評価に比べ、客観性や信頼性が担保できない場合もある。こ

の改善策として、評価者を業界団体等の複数の企業や関係者が協同で実施することで一定

程度の客観性や信頼性を担保することができる。評価者にスキルについても上記の第三者

評価に比べ、担保できない場合も考えられるが、本事業にて実施した試行試験の結果を基に

試験すべき内容や具体的な試験手順を示すことで一定程度の評価スキルを担保することが

できる。 これらの第三者評価スキーム及び第二者評価スキームを検討するために、既存の評価ス

キームに関して調査した事例を以下に示す。

表 5.4-1 評価スキームの事例 評価スキームの種類 概要

ISO/IEC 15408 及び ISO/IEC 19790 等で運用されている

評価スキームであり、評価依頼者、認証機関、評価機関の

三者で構成される評価スキームである。（正確には、評価

機関を認定する認定機関が存在する）

評価依頼者は、評価期間に評価対象物を提示し、評価期間

は評価レポートを認証機関に提示する。認証機関は、評価

レポートを確認し、規格に適合している場合には、評価依

頼者に認証書を発行する。

システム監査（クラウドサービス等を含む）等で運用され

ている評価スキームであり、評価依頼者、監査機関、評価

機関の三者で構成される評価スキームである。（正確には、

評価機関は異なる名称であるが、他の評価スキームと比較

をしやすくするため評価機関と記述する）

上記の評価スキーム①（第三者評価 1）との違いは、評価

機関は、監査機関の適切性を検査する点である。

UL 等の機器に関する評価等で運用されている評価スキ

ームであり、評価依頼者と認証機関の二者で構成される評

価スキームである。（正確には、認証機関は異なる名称で

あるが、他の評価スキームと比較をしやすくするため認証

機関と記述する）

72

評価スキームの種類 概要

機器の安全性を確認してマークを発行する活動等で運用

されているスキームであり、評価依頼者と認証機関の二者

で構成される評価スキームである。（正確には、認証機関

は異なる名称であるが、他の評価スキームと比較をしやす

くするため認証機関と記述する）

上記の評価スキーム③（第二者評価 1）との違いは、評価

ツールとして認証機関は、監査機関の適切性を検査する点

である。

既存の評価スキームの事例について、評価に必要となる機関や評価・診断ツールの有無及

び事故報告や再審査、及び評価の更新や継続等の詳細について以下に報告する。IoT 機器を

対象とし、適切な規模で評価するためには第二者評価 2 の例が望ましく、前述の評価基準

や評価結果の表示、評価ツール等を踏まえてさらに検討が必要である。

表 5.4-2 評価スキームの事例 2（詳細） 前述の区分 第三者評価 1 の例 第三者評価 2 の例 第二者評価 2 の例

名称 CC ISO/IEC15408

CMVP ISO/IEC19790

クラウド情報セキュリ

ティ監査制度(JCISPA) 安全・安心マーク （公衆無線 LAN/ISP）

期間 3 ヶ月～※1 ※2

3 ヶ月～※1

6 ヶ月～※1 ※3

審査は年 3 回

認証書・マーク

認証機器の リスト公開

有 （企業/製品等）

有 （企業/モジュール）

有 （企業/サービス）

有 （企業/サービス）

脆弱性等の診断 有 有 有（監査する） 有

診断ツール 評価者が任意指定 試験者が任意指定 監査ツール有 推奨ツール有 SAINT、NESSUS 等

事故報告 有 有 有 有

再審査 有 有 有 有

更新／継続 有 有 有 有

制度主体者 IPA/ASNITE IPA/ASNITE クラウドセキュリ

ティ推進協議会

インターネット接続サ

ービス安全・安心マー

ク推進協議会

※1：初回評価・試験で且つ設計開発ドキュメント類の品質が高く、評価・試験の戻りがない（指摘事項）

がまったくない場合の概算期間。

※2：本事業の試行試験で参考にした NDcPP を用いた場合、期間は短く、費用は低くなる可能性がある。

※3：概算期間は、内部監査を実施し、内部監査結果を外部監査が確認する工数であり、1 拠点且つ、Iaas

73

を除いて、標準的なプロシージャ、プロトコルを前提とした概算期間。

なお、上記の第二者評価 2 の例は、他の事例と比較し、評価対象のセキュリティ機能に対

する確認の厳密さ及び深さが異なることに注意が必要である。 既存の評価スキームについて「客観性・信頼性」及び「評価スキルの担保」、「評価費用・

評価期間」の概要を以下に示す。

表 5.4-3 評価スキームの事例の比較概要 区分 客観性・信頼性 スキルの担保 評価費用・評価期間

第三者評価 1 の例

○ • 第三者が関与してい

るため客観性が担保

される。 • 評価レポートを複数

が確認するため信頼

性が担保される。

○ • 第三者が関与してい

るため認証機関のス

キルも一定程度、担

保される。

△ • 評価レポートを複数

が確認するためトー

タルの評価費用が高

く、評価期間が長く

なる可能性がある。

第三者評価 2 の例

○ • 第三者が関与してい

るため客観性が担保

される。 • 評価レポートを一団

体しか確認しない

が、監査機関を検査

するスキームが存在

する。

○ • 第三者が関与してい

るため認証機関のス

キルも一定程度、担

保される。

△ • 評価レポートを一団

体が確認するため上

記に比べ、評価費用

が低くなる可能性が

あるが、監査機関を

検査、認定するスキ

ームやコストが別途

必要。

第二者評価 1 の例

△ • 第三者が関与しない

ため上記に比べ客観

性が低く、 • 評価レポートを一者

（社）しか確認しな

いため、上記に比べ

信頼性が低い。

△ • 第三者が関与しない

ため認証機関のスキ

ルが担保できるか不

明である。

○ • 第三者が関与しない

ため、上記に比べ、

評価費用が低くなる

可能性がある。

第二者評価 2 の例

△ • 上記同様に、第三者

が関与しないため客

観性、信頼性ともに

低いとも考えられる

が、認証機関を業界

団体や政府の外郭団

体とすることで一定

程度担保される。

○ • 第三者が関与しない

ため認証機関のスキ

ルが担保できるか不

明であるが、評価ツ

ールによって一定程

度担保される。

○ • 第三者関与しないた

め、上記に比べ、評

価費用が低くなる可

能性がある。 • また、評価申請者

（外部委託も可）の

評価レポートを確認

することで、さらに

評価費用を低くする

ことができる。

なお、上記のスキルや評価費用・期間については、認証機関や監査機関等の費用や期間を

比較した内容であり、評価依頼者の費用や期間については IoT 機器の実態や実装されてい

るセキュリティ機能を踏まえ、別途、検討が必要である。

74

検討課題

今後の検討課題として、以下に法制度に関する内容、IoT 機器に関する脆弱性及びバージ

ョンアップ機能に関する内容、詳細検討が必要な内容について報告する。

法制度関係について

(1) 個別の業法との関係性の整理 IoT の各分野においても求められるセキュリティ機能や評価の厳密性は異なる。特に医療

関係においては独自の機器確認制度があり、自動車関係では、開発に係る評価制度も存在し

ている。また、自動車のように業法によって規制されているもの、利用に当たって免許や資

格等が必要なものについては、それらの業法や免許・資格制度によってセキュリティを担保

することが可能であるから、本調査検討では詳細を検討していない。今後の検討においては、

個別の業法で確認、担保されるセキュリティ対策と評価に求められるセキュリティ機能の

関係性の整理が必要である。

(2) 制度化の基本的な考え方 認証を法規で必須とすることは望ましくない。IoT 機器等に係る企業が自社製品の健全性

訴求のために第三者評価の結果を利用するものであり、IoT 機器等に係る産業の全てが第三

者評価を望んでいない場合もある。そのため、商品訴求を目的に認証を企業がアピールする

ために利用可能であること、及び自治体などで必要な場合は調達要件として明記すること

などは必要であるが、製品の健全性訴求をしたい企業が選択的に実施できる評価であるこ

とが望ましい。

(3) 個人情報・プライバシーについて 今回の調査検討においては、IoT 機器に求められるセキュリティ機能の評価手法を検討し、

その検討結果を基に評価の在り方を検討した。そのため、プライバシー、個人情報保護につ

いては、詳細な調査検討を行わなかったが、今回の評価対象のセキュリティ機能は、プライ

バシー、個人情報保護にも関係する内容であり、また評価の国際標準などを考慮した場合は、

プライバシー、個人情報保護は重要な観点ではあるため引き続き、継続して検討する必要が

ある。

IoT 機器に関する脆弱性及びバージョンアップ機能について 認証した IoT 機器の脆弱性を発見した場合について検討を行なった。今後の IoT 機器の

安全な利用を考慮した場合、脆弱性に対応するために IoT 機器のアップデート機能は必要

ではあるものの、アップデートできない実装は存在する可能性もある（例えば、IoT 機器自

体にアップデート機能が実装されていない場合以外にも、IoT 機器自体にアップデート機能

75

が実装されているが、OS やファームウェアの関係でアプリケーションがアップデートでき

ない等も含む）。そのため、「アップデート機能を実装している IoT 機器」と、「アップデー

ト機能を実装していない IoT 機器」に分けて評価結果を公表することを検討したが、引き

続き検討が必要である。

図 5-1 脆弱性発見に関するイメージ図

詳細検討が必要な事項

(1) IoT システムに関するステークホルダの整理 IoT セキュリティガイドライン Ver1.0 では、IoT に係るプレイヤとして機器メーカ、シ

ステム提供者、サービス提供者、及び企業利用者と一般利用者を示している。IoT では複数

の IoT 機器・システムを相互に利用してサービスを実現することも多く、システム提供者

やサービス提供者はそれぞれが利用者でもある。また、企業利用者や工場（下表参照）では、

IoT 機器・システム、サービスを自社の生産活動やサービス供給等ビジネスの中に組み込み、

これらの管理を行い一般の利用者は IoT システムを意識せずサービス提供を行っている場

合あり、IoT はサービス形態などに応じてステークホルダが異なる状況である。そのため、

前述のユースケースに応じた検討については IoT システムに関するステークホルダの整理

を行うことが求められる。

76

表 5.5-1 IoT セキュリティガイドライン Ver1.0 における関係者の概要

(2) 業界や分野などのユースケースに応じたセキュリティ機能

今回の調査検討では、共通的かつ汎用的な評価手法を検討したため、IoT の対象となる業

界や分野などのユースケースについては詳細な調査や検討を行っていない。そのため、これ

らの詳細については、本調査検討結果を基にさらに調査を進め、業界や分野などのユースケ

ースについて検討する必要がある。一方で、IoT システムは、現時点でも仕様検討されてい

る部分もあり、各業界や分野の検討に合わせて評価すべきセキュリティ機能を詳細化する

必要がある。

(3) 国際標準及び国際連携の検討 今回の調査検討では、汎用的な IoT 機器に求められるセキュリティ機能とその評価手法

を検討した。現在の IoT 機器やシステムは、国内事業者が海外展開する場合や国内事業者

が企画した IoT 機器やシステムを海外企業が製造する場合もあり、IoT 機器に求められるセ

キュリティ機能とその評価においても国際標準化や国際連携を検討する必要がある。

(4) IoT システムを構成するアーキテクチャと評価項目 今回の調査検討では、汎用的な評価手法を検討したが、詳細には IoT 機器の具体的な実

装に照らし合わせ IoT システムを構成するアーキテクチャとそれらのアーキテクチャに係

るセキュリティ機能の評価項目を検討する必要がある。例えば、評価すべき技術を「ネット

ワーク」および「OS（ドライバー含む）」と「アプリケーション（ミドルウェア含む）」、そ

77

して、「ハード（CPU や周辺 I/F とファームウェア含む）についてそれぞれ評価すべき項目

を設定する方法や、汎用製品（たとえば、CPU や OS、ミドルウェアなど）については、各

ベンダに評価項目を明確にする等の検討も必要である。

(5) 具体的な評価ツールの検討 5.3 節及び 5.4 節に示した通り、評価スキームや評価基準の検討と評価ツールは密接に関

係しているため、具体的な評価ツールについても引き続き検討することが求められる。特に、

本調査検討では、IoT 製品に対してテスト評価を実施した結果、機能毎に具体的な試験項目、

判断基準を提示することで求められるセキュリティ機能を確認できた。これらの結果を基

に、評価ツール等を検討することにより結果判断を自動化する評価ツールを開発すること

も検討が可能であり、評価ツールの具体化に関する検討を行うため、さらなる実機検証が必

要である。

78

関係者が参画するワーキンググループの設置・運営

セキュリティに関わる専門家、IoT 機器の製造事業者、利用者、第三者評価に関連する事

業者等がメンバー及びオブザーバーを含め 11 名が参画するワーキンググループ（以下 WG）

を設置し、3 章から 4 章の調査結果を踏まえ IoT 機器のセキュリティ評価の在り方に関す

る検討を 3 回実施した。

開催日程

以下に IoT セキュリティ評価 WG の開催日程を示す。 第一回 IoT セキュリティ評価 WG 開催概要 日 時：平成２９年２月１６日（木）１０：００－１２：００ 場 所：経済産業省 1107 各省庁共用会議室 主な議題１： 事業概要について

主な議題２：文献調査結果・試行試験について 主な議題３： IoT セキュリティ評価の論点

第二回 IoT セキュリティ評価 WG 開催概要 日 時：平成２９年３月１５日（水）１０：００－１２：００ 場 所：経産省 本館１階東共用会議室 主な議題１：セキュリティ機能の抽出について 主な議題２：試行試験について 主な議題３： IoT セキュリティ評価の論点 第三回 IoT セキュリティ評価 WG 開催概要（メール審議） 日 時：平成２９年３月１７日（金）～３月２３日（木） 主な議題：IoT セキュリティ評価の在り方（案）について

79

構成員

以下に IoT セキュリティ評価 WG の構成員を示す（敬称略・五十音順）。 なお、◎は IoT セキュリティ評価 WG の座長である。

表 6.2-1 IoT セキュリティ評価 WG 構成員

No 氏名 所属

1 ◎猪俣 敦夫 東京電機大学 未来科学部 情報メディア学科 教授

2 小熊 寿 株式会社トヨタ IT 開発センター 研究部

3 濱口 総志 株式会社コスモス・コーポレイション IT セキュリティ部

4 洞田 慎一 一般社団法人 JPCERT コーディネーションセンター

5 松岡 正人 株式会社カスペルスキー／特定非営利活動法人日本ネットワ

ークセキュリティ協会 IoT セキュリティ WG

6 松本 泰 セコム株式会社 IS 研究所

7 真鍋 史明 独立行政法人情報処理推進機構 情報セキュリティ認証室

表 6.2-2 オブザーバー

No 氏名 所属

1 荒本 道隆 アドソル日進株式会社／先端 IT 活用推進コンソーシアム

2 福田 次郎 横浜市 最高情報統括責任者補佐監（CIO 補佐監）

3 湯淺 墾道 情報セキュリティ大学院大学 学長補佐

4 米田 旬 一般社団法人電子情報技術産業協会

80

まとめ

本事業では、ネットワークに接続される IoT 機器等に対して必要なセキュリティを確保

するために、IoT 機器のセキュリティ要件や評価方法を整理し、テスト評価を通じて、整理

した評価方法の妥当性を検証した。 評価方法の検討については、文献調査対象のユースケースのすべてにおいて IoT 機器に

求められているセキュリティ機能のなかから認証機能（利用者認証機能、管理者認証機能、

サーバ認証機能を含む）と通信路暗号化を評価対象とし、一般的なプロトコルを対象とした

汎用的で再利用可能な評価方法を検討した。また、検討した評価方法については実機を用い

たテスト評価を行い検証した結果、実評価及びレポーティングを含め 1 週間から 2 週間程

度でセキュリティ機能を確認、評価することが可能であった。 IoT 機器のセキュリティ評価の在り方の検討については、IoT 機器に求められる共通的か

つ汎用的なセキュリティ機能に限定した評価を行うことで、IoT 機器を対象とした適切な規

模での評価が可能であり、IoT 機器開発者の啓発の意味を含め、これらの評価方法や評価の

考え方を理解することは重要である。また、よりリスクの大きい IoT 機器については、より

広範囲で深いセキュリティ評価を行うことになるが、その際にも、共通部分のセキュリティ

評価については本検討結果を利用することが可能である。 本事業で検討した評価方法は基本的な内容ではあるがインターネットに繋がることを意

識していない IoT 機器開発者に対してセキュリティ機能を確認方法としても参考となる。

また、IoT 機器の調達者や利用者は、評価方法を最低限確認すべき内容として IoT 機器の調

達の参考にすることも可能である。IoT システムの全体のセキュリティ評価を行う場合、想

定するシステムは大規模になり、必要なセキュリティ機能が多くなることが考えられるが、

IoT 機器を対象とし、セキュリティ機能を限定することで適切な規模での評価が可能であ

り、これらの評価結果にクラウド等の他のセキュリティ評価を含めることで、IoT の評価を

段階的に進めることが可能である。本事業で検討した IoT 機器のセキュリティ評価手法や

評価の在り方については、IoT 機器等に必要なセキュリティを確保ために必要であり、安全

な社会経済の更なる発展に向けて大きく貢献するものと考える。

81

参考情報

3.1.2 参考文献 [1] セキュリティ評価基準（CC/CEM) https://www.ipa.go.jp/security/jisec/cc/ [2] COMMON CRITERIA http://www.commoncriteriaportal.org/ [3] IPA 認証申請手続 https://www.ipa.go.jp/security/jisec/application/application_2.html#T2 [4] IPA CC 評価のセキュリティアーキテクチャ 2015.7.28 https://www.ipa.go.jp/security/jisec/seminar/documents/cc_eval_20150728.pdf 3.1.3 参考文献 [5] [ﾌﾟﾚｽﾘﾘｰｽ] UL がサイバーセキュリティ認証プログラムを開始 http://japan.ul.com/news/pr_ulcap/ [6] モノづくりスペシャリストのための情報ポータル海外医療技術トレンド（14） http://monoist.atmarkit.co.jp/mn/articles/1605/26/news014_3.html [7] SYNOPSYS ニュースリリース - 2016 年 4 月 8 日 https://www.synopsys.com/Japan/press-releases/Pages/20160405.aspx https://www.synopsys.com/Japan/press-releases/Pages/20151106.aspx [8] SYNOPSYS Protecode Enterprise™ https://www.coverity.com/html_ja/library/pdf/ProtecodeEnterprise_J_0412.pdf http://www.coverity.com/html_ja/products/ [9] SYNOPSYS Defensics http://www.codenomicon.com/jp/products/defensics/ [10] ＠IT IoT デバイスのセキュリティを高める「UL CAP」とは http://www.atmarkit.co.jp/ait/articles/1606/10/news021.html 3.1.4 参考文献 [11] IPA 暗号モジュール試験及び認証制度に関する説明会(2016/6/30 開催) https://www.ipa.go.jp/security/jcmvp/open_documents.html [12] JCMVP 暗号モジュール試験及び認証制度に関する Q&A https://www.ipa.go.jp/security/jcmvp/documents/qaj01.pdf [13] IPA 暗号モジュール認証製品リスト https://www.ipa.go.jp/security/jcmvp/val.html

82

3.2.1 参考 [14] IoT 推進コンソーシアム 総務省 経済産業省 IoT セキュリティガイドライン ver

1.0 http://www.iotac.jp/wp-content/uploads/2016/01/03-IoT%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3ver1.0%E5%88%A5%E7%B4%99%EF%BC%91.pdf 3.2.2 参考文献 [15] 内閣サイバーセキュリティセンター IoT セキュリティのための一般的枠組(案) http://www.nisc.go.jp/active/kihon/pdf/iot_fw2016.pdf#search=%27IoT%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E4%B8%80%E8%88%AC%E7%9A%84%E6%9E%A0%E7%B5%84%27 3.2.3 参考文献 [16] JNSA コンシューマ向け IoT セキュリティガイド http://www.jnsa.org/result/iot/ 3.2.4 参考文献 [17] OWASP Internet of Things Top Ten https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf 3.3 及び 3.4 参考 [18] IPA 海外のプロテクションプロファイルの翻訳 https://www.ipa.go.jp/security/publications/pp-jp/index.html

ISO/IEC 15408（CC) UL2900 ISO/IEC 19790（JCMVP)

IoT開発におけるセキュリティ

設計の手引き（IPA）IoTセキュリティガイドライン

ver 1.0（IoTAC）

コンシューマ向けIoTセキュリ

ティガイド（JNSA) IoT Top10（OWASP） 脅威（NDcPP） セキュリティ機能概要 テスト項目

• デジタル複合機

• ストレージ装置制御ソフトウェア

• 複合機・プリンタ用暗号化ハードウェア

• データオーバーライトソフトウェア

• プリンタ機用制御ソフトウェア

• デジタル複合機内データ保護機能

• データベース管理システム（DBMS）• デジタル複合機用データ保護オプションソフトウェア• クラウド型電子マネー決済システム コアモジュール（※）IPAによる日本の認証製品リストを参考とした

• 産業制御システム

• 医療システム

• 自動車

• HVAC（暖房換気空調設備）

• 照明機器

• スマートホーム

• 電化製品

• 警報システム

• 消防システム

• スマートメーター

• ネットワーク機器

• 家電等に含まれるネットワークデバイス

• スマートカード

• スマートフォン

• スマートメータ

• ソフトウェア暗号ライブラリ• 暗号化USBメモリ

• 暗号化HDD• SSD• 暗号化ルータ

• 無線LANアクセスポイント等

・サービス提供サーバ・クラウド・中継機器･システム（制御システム、病院内医療ネットワーク、スマートハウス等）･直接相互通信するデバイス（ゲーム機、Car2X 等）・デバイス（情報家電、自動車、ヘルスケア機器等）

・コネクテッドカー・HEMS・在宅医療用機器・制御用機器/センサー※上記対象機器は例示されたもの

・家電制御＋音声認識＋音声合成・iBeacon（照明の自動点灯/消灯）・Blynk+ESP8266を利用した

Wake On WAN・OpenHome：Reemoによるハンドジェスチャーによる操作・Mota SmartRing（リング状通信機）・DigitSole（無線式圧力センサー）・SensorSmartAlarm（温湿度センサー利用の快眠グッズ）・スマートテレビ（ソニーBRAVIA X9300Cシリーズ）・ウェラブルデバイス（：Fitbit/surge：スマートウォッチ）・ネットワークカメラ・汎用マイコンボード

・特定のIoTシステムを対象としていない

◯

識別と認証（FIA)

※CCPART3V3.1R4参照（対応付けのために代表的なセキュリティ機能を記載（依存性は考慮していない））

・ユーザー認証とユーザー承認 • 暗号鍵管理

• 役割、サービス及び認証

・ユーザ認証・遠隔ロック

・不正な読み出しや書き換えへの想定・セキュリティ確保のための認証機能の適用

・セキュアなAPI-Key・OAuth2による認証・異常発生を検知し、遠隔ロック・認証情報の有効期限設定・相互認証方法の確認・ペアリング先や通信先、通信経路確認

・十分な強度を備えた認証の実現・クラウドインターフェースのセキュリティ確保・モバイルインターフェイスのセキュリティを確保・不十分なセキュリティ設定を改善

管理者へのなりすまし管理機能の悪用

管理者認証（パスワードベースの認証）工場出荷状態時の強制的なパスワード設定

識別認証機能、パスワード品質検査セッション管理工場出荷状態での起動確認

◯

暗号サポート（FCS）利用者データの保護（FDP）

• 暗号化 • 暗号モジュールの仕様

• 有限状態モデル

• 動作環境

・データ暗号化・耐タンパーS/W

・守るべき機能や情報の洗い出し

・通信の暗号化 ・Webインターフェースのセキュリティ確保・収集した個人情報の暗号化

対象外

◯

暗号サポート(FCS）高信頼パス/チャネル（FTP）

• 暗号化 • 暗号モジュールのポート及びインターフェース

・通信路暗号化・メッセージ認証

・機器の通信状態の把握・通信記録の不正な消去/改ざんの防止・CRYPTREC暗号リスト参照

・通信の暗号化によるコンテンツの保護・定期的な暗号化鍵の変更

・ネットワークサービスのセキュリティ確保・トランスポートに十分な暗号化

管理インタフェースの悪用管理インタフェースからの情報漏えいログデータの通信路からの漏えい

ネットワーク通信保護（管理インタフェースの暗号化）（ログサーバ間の通信暗号化）

Ipsec,TLS,SSH,RFCへの適合性暗号化処理（AES,乱数生成等）適合性エントロピー品質,X.509証明書の検証

◯

利用者データの保護（FDP） • 暗号鍵管理（CSPのゼロ化）

・出荷時状態リセット・セキュア消去・遠隔消去

・廃棄時の記録保存コンテンツや設定の初期化・物理的なデータ読み出し不可・耐タンパ性

仕様／提案の対象外

◯

TSFの保護（FPT） • 自己テスト ・ソフトウェア署名 セルフテスト（Power ON時等のファーム改ざん検知）高信頼アップデート

◯

TSFの保護（FPT）※高信頼アップデートは拡張機能要件

• 既知の脆弱性テスト ・仮想パッチ・脆弱性対策

・機器のアップデート実施・脆弱性情報の収集・分析・情報発信

・最新のセキュリティパッチ適用

・ソフトウェア/ファームウェアのセキュリティを確保（アップデートの実施）

アップデート機能を利用したファームウェア書き換えバックドアに対する不正アクセス

高信頼アップデート（ファーム更新機能の悪用防止）（ファームウェア正当性検証）

アップデート機能のアクセス制御Hashベースの完全性検証X.509証明書ベースの自己診断

◯

セキュリティ管理（FMT） • 暗号鍵管理

• 役割、サービス及び認証

管理機能の提供、役割の維持

管理者認証機能に含む

◯

セキュリティ監査（FAU） ・ログ分析 監査ログからの情報漏えい

セキュリティ監査（監査ログの取得、保護）

セキュリティ機能に関する監査ログ取得外部サーバへのエクスポート内部蓄積ログ、通信路の保護

◯TSFの保護（FPT） • 物理的セキュリティ ・耐タンパーH/W ・耐タンパ性 ・物理的セキュリティを強化 仕様／提案の対象外

NDPPによる試行試験用詳細化

機能の完全性検証（実行ソフトウェアの検証/認証）

管理機能（設定変更・管理機能を提供する場合）

関連ガイドライン評価・試験制度

対象機器

セキュリティ評価の分析（機能にか

かるもの）調査項目

セキュリティ機能

（評価・試験制度では、評価項目・セキュリティ要件。ガイドラインではセキュリティ要求仕様）

暗号化通信（メッセージ認証含む）

認証（機器認証）

データ暗号化（ユーザデータの暗号化、及び一部アクセス制御も含む）

データ消去

セキュリティパッチ／アップデート／脆弱性対策

ログ／監査生成・保管機能

物理セキュリティ

別添1：文献調査概要

ISO/IEC 15408（CC) UL2900 ISO/IEC 19790（JCMVP)

IoT開発におけるセキュリティ

設計の手引き（IPA）IoTセキュリティガイドライン

ver 1.0（IoTAC）

コンシューマ向けIoTセキュリ

ティガイド（JNSA) IoT Top10（OWASP） 脅威（NDcPP） セキュリティ機能概要 テスト項目

その他セキュリティ機能要件 •適用範囲

• 引用規格

• 用語集

• 一般的な事項・構造化ペネトレーションテスト･ソフトウェアの弱点の分析• 静的コード分析

• 静的バイナリおよびバイトコード分析

• その他の攻撃への対処

• 自己テスト

・サーバセキュリティ・データ二次利用禁止

・組織としてのセキュリティ対策・内部不正/ミスへの対策

・リスクの想定（IoT機器・シ

ステム/保守/波及するリスク/物理的リスク）・過去の事例の把握・内包リスク・盗難時のデータ保護・サイバー攻撃/システム障害対策・機能及び性能レベルの考慮

・ネットワークから切断の検知・ID管理による不正デバイス検知・不正通信の検知

暗号関連処理の正常動作確認

セキュリティ機能に関する脆弱性

セルフテスト（暗号関連ヘルステスト）

暗号スタンダードで求められるヘルステスト

脆弱性評定

フィルタリング機能△

実態として運用面での対策が多い

TSFの保護（FPT）セキュリティ監査（FAU）

• アクセス制御、ユーザー認証とユーザー承認

• リモート通信

・フィルタリング・ホワイトリスト制御

・ペアリング先や通信先、通信経路確認

ファイアウォール機能 △実態として運用面での

対策が多い

TSFの保護（FPT）セキュリティ監査（FAU）

• 不正な入力テスト ・FW機能・ホワイトリスト制御

・外部IF経由のリスク ・アクセス制御

不正侵入検知・防御対策（IDS/IPS等）

△実態として運用面での

対策が多い

TSFの保護（FPT）セキュリティ監査（FAU）

・IDS/IPS・ホワイトリスト制御

・異常状態の検知、波及防止、復旧

・動作、利用状況の監視及びログ管理（正常ログ、異常ログ）

サービス不能状態、外部からの攻撃の検知

セキュリティ監査 セキュリティ機能に関する監査ログ取得

アンチウィルス／マルウェア対策 △

実態として運用面での対策が多い

TSFの保護（FPT） • マルウェアのテスト ・アンチウィルス ・定期的なウィルスチェック・アプリケーションの最新の状態かチェック

自身のファームウェア改ざんマルウェア対策

セルフテスト（Power ON時のファーム改ざん検知）

Hashベースの完全性検証X.509証明書ベースの自己診断

DoS対策

△実態として運用面での

対策が多い

TSFの保護（FPT）資源利用（FRU）

・DoS対策 ・DoS攻撃時においてもデバイスの基本機能の継続利用・DoS攻撃終了時の機能回復

サービス不能状態、外部からの攻撃の検知

サービスの停止（新設検討中）

セキュリティ監査

サービス継続（※環境で対応することも検討）

セキュリティ機能に関する監査ログ取得

セキュリティ機能の維持

知的財産（ソフトウェア）△

実態として運用面での対策が多い

・保証要件（開発、テスト、ライフサイクルサポート）

必要に応じて考察

×開発による対策が一般

的

・保証要件（開発、テスト、ライフサイクルサポート）

• 製品ドキュメント

• 製品設計ドキュメント

• プロダクトマネジメント

• ベンダー製品リスクマネジメントプロセス

• 設計保証 ・セキュア開発 ・設計時の見える化

×ドキュメント類による

対策が一般的

・保証要件（ガイダンス文書） • 製品使用のためのドキュメント クリプトオフィサガイダンス、ユーザガイダンス

・説明書周知徹底 ・機器管理者への注意喚起

NDPPによる試行試験用詳細化セキュリティ評価の分析（機能にか

かるもの）

評価・試験制度 関連ガイドライン

調査項目

その他（以下詳細分類は要検討）

開発に関するセキュリティ

ユーザーズマニュアル（ガイダンス）

ISO/IEC 15408（CC) UL2900 ISO/IEC 19790（JCMVP)

IoT開発におけるセキュリティ

設計の手引き（IPA）IoTセキュリティガイドライン

ver 1.0（IoTAC）

コンシューマ向けIoTセキュリ

ティガイド（JNSA) IoT Top10（OWASP）

･ST（セキュリティ設計仕様書に相当）評価

・EAL（評価保証レベル）指定

・PP評価

・TOE評価

・基本仕様/設計書評価・ソースコード評価・開発環境現地調査・機能テスト侵入テスト・ガイダンス評価・構成管理/配布手続き評価

【Protecode】• ソフトウェア部品表（BOM）の生成

• セキュリティの脆弱性の評価

• オープンソースライセンスのレポート作成

• スキャン及びスニペットの検出

• ライセンス及び著作権ポリシーの定義

• 輸出規制及び暗号レポートの作成

• ソフトウェアパッケージデータ交換（SPDX）

【Coverity】• 静的コード解析ツール

• 動的解析及び障害の自動検知

• アーキテクチャ解析機能、アーキテクチャマップ、コールグラフ、依存性構造マトリックスなど、ソフトウェアシステムの可視化• ビルド処理解析機能及び遅延や非効率性判別

【Defensics】• セキュリティテスト

• 正確で実用的なレポート作成

• ワークフローを作成及び不具合の修正の簡素化

• セキュリティポリシーの確認• 有限状態モデル(FSM）

• 設計資料の確認

• ベンダー情報要件の説明／参照先指定• FSM・設計資料とソースコードの一致確認• 物理的セキュリティ試験• 暗号アルゴリズム実装試験• オペレーションテスト

・新たな脆弱性防止・既知の脆弱性解消・残留する脆弱性検出/解消・製品出荷後の脆弱性の発見・継続的な脆弱性対策情報の収集・脆弱性対策情報の利用者への通知・更新ソフトウェアの製品への適用・脆弱性対策情報データベースの利用・脆弱性届出制度遵守

評価者により任意のツールを利用 ・Protecode・Coverity・Defensics

・暗号アルゴリズム実装試験ツール（JCATT）

・脆弱性対策情報データベース：JVN iPedia

CEM (Common Methodology for InformationTechnology Security Evaluation:共通評価方法、

(ISO/IEC 18045)

米国「サイバーセキュリティ国家行動計画（CNAP：Cybersecurity National Action Plan）

・ISO/IEC 19790・JIS X 19790・ISO/IEC WD24759

・IoT Top10（OWASP）・OTA IoT Trust Framework・GSMA IoT Security Guidelines・FIPS SP800・NISTIR 7628・CRYPTREC 暗号リスト・つながる世界の開発指針（IPA)

・機能安全規格IEC61508及び派生規格・ISO/IEC15408・EDSA認証

・欧州標準（IoT-A、Internet ofThings - Architecture）

【ソフトウェア認証申請手数料】　PP 410,400円　EAL1 529,200円　EAL2 691,200円　EAL3 810,000円　EAL4 1,026,000円　EAL5以上　要相談【ハードウェア（スマートカード等）認証申請手数料】　PP 410,400円　EAL1 529,200円　EAL2 691,200円　EAL3 810,000円　EAL4 1,026,000円　EAL5 1,112,400円　EAL6 要相談

　EAL7 要相談【その他】　保証継続申請1 388,800円　英文認証書発行申請 3,800円　認証書の再交付請求 3,800円　英文認証書の再交付請求 3,800円　認証報告書の再交付請求 3,400円　保証継続報告書の再交付請求 3,400円

【暗号モジュール認証】 レベル1　270,000円 レベル2　385700円 レベル3　540000円 レベル4　756,000円【暗号アルゴリズム確認】 21,600円

評価費用・認証取得費用

評価ツール

参照規格

セキュリティ評価の分析（機能にか

かるもの）

評価・試験制度 関連ガイドライン

調査項目

評価手法