IoT セキュリティ評価検証ガイドライン
Rev1.0

一般社団法人重要生活機器連携セキュリティ協議会
2017 年 6 月 30 日

Copyright 2017 Connected Consumer Device Security Council Proprietary

更新履歴
リビジョン

更新日

更新内容

担当者

Rev1.02016/6/30

新規作成

CCDS
IoT セキュリティ評価
検証ガイドライン策定
準備委員会

Copyright 2017 Connected Consumer Device Security Council Proprietary目次
1. はじめに ............................................................................................................................................... 1
1-1. IoT セキュリティの現状と脅威 ...................................................................................................... 1
1-2. 評価検証ガイドラインにおける対象範囲 ...................................................................................... 2
2. セキュリティ評価検証プロセス ........................................................................................................... 6
2-1. 製品ライフサイクルにおける評価検証プロセスの位置づけ ......................................................... 6
3. セキュリティ評価検証の方針・計画策定 ............................................................................................. 7
4. 評価検証設計 ........................................................................................................................................ 9
4-1. 製品開発ライフサイクルと関連するセキュリティ対策................................................................. 9
4-2. セキュリティ評価検証の手法 ...................................................................................................... 10
4-2-1. 静的検証手法 ........................................................................................................................ 10
4-2-2. 動的検証手法 ......................................................................................................................... 11
4-3. 評価検証仕様書の策定及び、評価検証ツールの選定 .................................................................. 13
参考 1）機器構成と想定脅威の記載ガイド...................................................................................... 16
参考 2）対策に対する評価検証手法の検討ガイド ........................................................................... 17参考 3）評価検証（監査）レベルの定義ガイド .............................................................................. 18
4-4. 評価検証手順書の策定 ................................................................................................................. 19
4-5．評価検証データの準備 ................................................................................................................ 19
5. 評価検証実行 ...................................................................................................................................... 21
5-1. セキュリティ評価検証の実行 ...................................................................................................... 21
5-2. 検出されたインシデント情報の管理方法 .................................................................................... 22
5-2-1.

インシデントレポートフロー ............................................................................................. 22

5-2-2.

セキュリティインシデントレポートの記載項目 ................................................................. 22

5-2-3.

セキュリティインシデントの深刻度基準について ............................................................. 29

5-3. 報告・評価検証完了 .................................................................................................................... 32
5-3-1. 評価検証の実施状況に関する報告 ........................................................................................ 32
5-3-2. 評価検証の完了報告.............................................................................................................. 33
6．評価検証プロジェクトの総括・フィードバック ............................................................................... 33
7．まとめ ................................................................................................................................................ 35
7-1. 総括 ............................................................................................................................................. 36
Copyright 2017 Connected Consumer Device Security Council ProprietaryAppendix1

セキュリティ検証ツール一覧 ............................................................................................ 37

表 A1-1.

主要な静的脆弱性検証ツール一覧 ...................................................................................... 38

表 A1-2.

主要な脆弱性スキャンツール一覧 ...................................................................................... 39

表 A1-3.

主要なペネトレーションツール一覧 ................................................................................... 40

表 A1-4.

主要なファジングツール一覧 ............................................................................................. 41

Appendix2

評価検証計画書の実例集 ................................................................................................ 42

Appendix3

評価検証仕様書の実例集 ................................................................................................ 49

Appendix4

リスク評価手法の紹介 ................................................................................................... 61

1. CVSSv3 ........................................................................................................................................... 62
1-1. 概要 .......................................................................................................................................... 62
1-2. リスクファクタ ........................................................................................................................ 62
1-3. リスク計算式............................................................................................................................ 62
2. NIST SP800-30 ............................................................................................................................... 67
2-1. 概要 .......................................................................................................................................... 67
2-2. リスクファクタ ........................................................................................................................ 67
2-3. リスク計算式............................................................................................................................ 67
2-4. 備考 .......................................................................................................................................... 67
3. GMITS（ISO/IEC TR 13335） ...................................................................................................... 67
3-1. 概要 .......................................................................................................................................... 67
3-2. リスクファクタ ........................................................................................................................ 67
3-3. リスク計算式............................................................................................................................ 68
3-4. 備考 .......................................................................................................................................... 68
4. ETSI TS102 165-1 .......................................................................................................................... 68
4-1. 概要 .......................................................................................................................................... 68
4-2. リスクファクタ ........................................................................................................................ 68
4-3. リスク計算式............................................................................................................................ 68
4-4. 備考 .......................................................................................................................................... 71
5. 情報セキュリティマネジメントシステム(ISMS) ISO/IEC27001................................................... 72
5-1. 概要 .......................................................................................................................................... 72
5-2. リスクファクタ ........................................................................................................................ 72
Copyright 2017 Connected Consumer Device Security Council Proprietary5-3. リスク計算式............................................................................................................................ 72
5-4. 備考 .......................................................................................................................................... 72
6. OCTAVE Allegro ............................................................................................................................. 72
6-1. 概要 .......................................................................................................................................... 72
6-2. リスクファクタ ........................................................................................................................ 72
6-3. リスク計算式............................................................................................................................ 73
6-4. 備考 .......................................................................................................................................... 73
7. The OWASP Risk Rating Methodology ......................................................................................... 73
7-1. 概要 .......................................................................................................................................... 73
7-2. リスクファクタ ........................................................................................................................ 73
7-3. リスク計算式............................................................................................................................ 74
7-4. 備考 .......................................................................................................................................... 75
8. FAIR ................................................................................................................................................ 75
8-1. 概要 .......................................................................................................................................... 75
8-2. リスクファクタ ........................................................................................................................ 75
8-3. リスク算出 ............................................................................................................................... 76
8-4. 備考 .......................................................................................................................................... 76
9. CCDS 改良方式 ............................................................................................................................... 76
9-1. 概要 .......................................................................................................................................... 76
9-2. リスクファクタ ........................................................................................................................ 77
9-3. リスク計算式............................................................................................................................ 77
9-4. 備考 .......................................................................................................................................... 78
７．引用・参考文献 ................................................................................................................................ 79

Copyright 2017 Connected Consumer Device Security Council Proprietary1. はじめに1. はじめに1-1. IoT セキュリティの現状と脅威
1)生活機器のネットワーク化
様々な生活機器に ICT(情報通信)技術が組み込まれ、生活機器がインターネットにつながる IoT（Internet of Things）の時代が到来し、製品の更なる高度化、自動化を実現することとなった。一方で、これまでは個々に独立していた機器が、通信ネットワークに接続することでセキュリティ攻撃の潜在的なリスクを高めることにつながっている。
実際に米国ではスーパーなどの POS 端末を狙ったマルウェアにより、約 4000 万件のカード情報を流出する事例(2013 年)や、携帯メール送信により、ATM から現金を引き出せるマルウェアが発見された事例（2014 年）が報告されている。このことはこれまで想定でしかなかった生活機器のネットワークアクセス
によるウィルスや不正アクセスなどの脅威が、実際にユーザの安全・安心を阻害し得ることを実証し、産業界に生活機器のセキュリティ対策を促す大きな警鐘となった。

2)日本における研究開発動向
国内においても 2020 年の東京オリンピック開催に向けて IT 戦略とセキュリティ対策戦略が加速す
し、官民連携によるセキュリティ対策が進行している。2014 年 1 月に CCDSSG（重要生活機器セキュリティ研究会）が発足し、生活機器のネットワーク連携によるセキュリティ対策に関する研究活動を開始。2014 年 6 月には CCDSSG による提言を受け、NISC（内閣サイバーセキュリティセンター）は「情報セキュリティ研究開発戦略（改訂版）」の中で、今後の研究開発のスコープとして、情報家電、自動車、在宅医療機器、HEMS 等の生活機器を含める指針を発表している(2014 年 7 月)。

3)組込み機器メーカの課題及びニーズ
こうした状況を踏まえ、各産業分野ではセキュリティ対策の重要性を認識しているものの、具体的な対策にあたっての標準規格やガイドラインの整備は、現状では不十分な状況にある。下記図 1-1 のように、機能安全（セーフティ）の領域では、ISO26262 をはじめとする具体的な対応基準が整備されているが、セキュリティの領域では、ISO27001 にて組織マネージメントに対するセキュリティ規格はあるものの、具体的なセキュリティ標準規格を策定しているのは、原子力等の重要インフラに関するセキュリティ基準を定めた「IEC64223 汎用制御システ
ムのセキュリティ」のみである。生活機器セキュリティに関しては、2016 年に、内閣サイバーセキュリティセンター
（NISC）が、新たなサイバーセキュリティ戦略の一環として、セキュリティ ・バイ ・デザインの考え方を踏まえた
IoT システム開発の推進を提唱し、8 月には具体的な対策を盛り込んだ「安全な IoT システムのためのセキュリ
Copyright 2017 Connected Consumer Device Security Council Proprietary11. はじめにティに関する一般的枠組」が公開された。また、経済産業省及び総務省の IoT 推進コンソ―シアムからも「IoT
セキュリティガイドライン ver1.0」が公開され、ガイドライン策定を含めた民間のセキュリティ団体の活動も活性化しつつあるが、何をどこまで対応すべきか明確な基準が整備されたとは言えないのが実状である。
まとめると組込み機器メーカの課題は以下となっている。
・製品の競争力向上のためには、通信ネットワーク連携による高度化が必要であるが、そのためには
具体的なセキュリティ基準の策定が急務である。
・同時にセキュリティ検査ツールや、検査、認証基準の整備を行い、セーフティで実施されているよ
うな第三者による客観的、定量的な検査・検証が行われる仕組みづくりが必要である。

図 1-1. 日本におけるセーフティとセキュリティの国際規格の策定状況（出典：CCDS 発行「一般社団法人 重要生活機器連携セキュリティ協議会の概要」[1]に加筆修正）

1-2. 評価検証ガイドラインにおける対象範囲
1)本文書の位置づけ
本文書は下記の団体より発行されたセキュリティガイドラインの評価検証に関する項目に対して、ス
マートホーム分野での実例を取り入れつつ、IoT 機器全般を対象に、具体的なセキュリティの評価検証プ
Copyright 2017 Connected Consumer Device Security Council Proprietary21. はじめにロセスを更に掘り下げた内容として策定している。
本書は広く IoT 機器全般を対象に活用できることを念頭に作成しているが、記載事例については、ス
マートホームシステムに対するセキュリティ評価検証の実証実験結果をもとに作成しており、他分野に応用する場合には注意が必要である。
また本文書における評価検証部門は独立した第三者機関を想定しており、顧客や開発部門と協議や意思疎通を図りつつも、自らがセキュリティ評価検証の各プロセスを通じて、設計、提案、実行、管理、そして継続的な改善を行うことを前提としている。

[本書と関連するセキュリティガイドライン]①IoT 推進コンソーシアム「IoT セキュリティガイドライン（要点 12 安全安心を実現する設計の検証・評価を行う）」[2]②独立行政法人

情報処理推進機構（以下 IPA）

「つながる世界の開発指針（指針 12 安全安心を実現する設計の検証・評価を行う）」[3]③一般社団法人 重要生活機器連携セキュリティ協議会（以下 CCDS）「CCDS 製品分野別セキュリティガイドライン 車載器編 Ver.1.01（4.2.2 項 企画・開発フェーズ）」[4]「CCDS 製品分野別セキュリティガイドライン IoT-GW 編 Ver.1.01（4.2.3 項 評価フェーズ）」[5]「CCDS 製品分野別セキュリティガイドライン 金融端末(ATM)編 Ver.1.0（5.2 項 各フェーズの詳細説
明）」[6]「CCDS 製品分野別セキュリティガイドライン オープン POS 編 Ver.1.0（5.2.2 項 開発フェーズ）[7]2)本書の対象者
本文書はセキュリティの評価検証にかかわる下記の担当者を対象としている。
①IoT 機器の設計を行う設計者、開発者、及び開発責任者②IoT 機器の評価検証を行う、テストエンジニア、及び責任者③IoT 機器の設計、開発及び評価検証において、予算や人員を決定する意思決定者

3)本文書の対象範囲
本文書はセキュリティの評価検証に焦点を絞って記載するものとする。脆弱性の原因となる不具合の作り込みを低減するため、ISO/IEC 25010[8]に基づき、対象システム/ソフトウェアの各品質特性に対して、別途テストが実施されていることを前提とする。また組織的評価検証方針・組織的評価検証戦略につCopyright 2017 Connected Consumer Device Security Council Proprietary31. はじめにいて本文書では記載していないが、ISO/IEC/IEEE29119[9]に則り、定義されていることを前提とする。

3)略称、用語
表 1-1. 略称、用語一覧
略称

名称

CCDS

Connected Consumer Device Security council

CUI

Character User Interface

CVSS

Common Vulnerability Scoring System

CWE

Common Weakness Enumeration

DoS

Denial of Service

DUT

Devise Under TestETSIEuropean Telecommunications Standards Institute

FIRST

Forum of Incident Response and Security Teams

GMITS

Guidelines for the Management for IT Security

HAN

Home Area Network

HEMS

Home Energy Management System

HTTP

Hyper Transfer Text Protocol

HNW

Home Network

IoT-GW

Internet of Things-Gate Way

IPA

Information-technology Promotion Agency

IT

Information Technology

JVN

Japan Vulnerability Notes

NVD

National Vulnerability Database

OSDBD

The Open Source Database Network

OSS

Open Source Software

OTA

Online Trust AllianceOWASPThe Open Web Application Security Project

SQL

Structured Query Language

TCP/IP

Transmission Control Protocol/Internet Protocol

WASC

Web Application Security Consortium

Copyright 2017 Connected Consumer Device Security Council Proprietary41. はじめに
WAN

Wide Area Network

XSS

Cross Site Scripting

Copyright 2017 Connected Consumer Device Security Council Proprietary52. セキュリティ評価検証プロセス

2. セキュリティ評価検証プロセス
2-1. 製品ライフサイクルにおける評価検証プロセスの位置づけ「CCDS 製品分野別セキュリティガイドライン IoT-GW 編 Ver.1.01」[5]では製品の開発フェーズを「製品企画」、「設計・製造」、「評価」、「運用保守」、「廃棄」と大きく５つに分類している。当ガイドライ
ンでは、上記の「評価」フェーズについて、セキュリティ評価検証を行う上での詳細プロセスを規定するものとする。

図 2-1.「CCDS 製品分野別セキュリティガイドライン IoT-GW 編」[5]における製品ライフサイクルとフ
ェーズ定義

製品企画

設計・製造

評価

運用保守

廃棄

当ガイドラインでは評価フェーズの詳細プロセスを定義する

評価検証方針・計画策定

評価検証設計評価検証実行

評価検証完了・
報告

総括・
フィードバック

表 2-1. 製品ライフサイクルにおける各フェーズの説明
フェーズ

説明

評価検証方針・計画策定

評価検証の対象範囲や対応人員(工数)、評価検証スケジュール等の実施計を策定する。

評価検証設計

実施する評価検証の内容や手順等について、要件及び仕様として整理を行う。

評価検証実行

策定した計画、仕様に従って、セキュリティ評価検証を実施する。

結果総括・フィードバッ

評価検証の実施結果を総括し、次回以降の改善点を明確化した上で、今後の開ク発や評価検証プロジェクトにフィードバックを行う。

Copyright 2017 Connected Consumer Device Security Council Proprietary6

3. セキュリティ評価検証の方針・計画策定

3. セキュリティ評価検証の方針・計画策定
セキュリティ評価検証の方針・計画策定を行うにあたり、「評価検証計画書」を策定し、対象プロジェ
クトの背景や具体的な計画を明確化しておく。
「評価検証計画書」の記載要件として推奨する内容については、以下に記載する。評価検証計画書の記載内容については顧客あるいは開発部門と協議を行い、合意の上で策定を行う。
※本文書記載の評価検証計画書の記載要件は、テストプロセスに関する国際標準を定めた
ISO/IEC/IEEE29119[9]を参考に作成している。
※評価検証計画書の具体的には作成事例は、「Appedix2.評価検証計画書」の事例集を参照。

表 3-1.

評価検証計画書の記載要件

計画書の項目名称

記載内容

1)評価検証の背景①評価検証サブプロセ検証を行うべきシステムやソフトウェアの開発背景や、想定しているユースシー

ス

ンを概要として記載する。

②評価検証対象の構成

システム構成図等を用いて、評価検証対象となるシステムやソフトウェアの全容を示す。

③評価検証範囲

上記システム構成図において、評価検証対象範囲を明示する。また、評価検証範囲において、具体的な想定機能や保護すべき資産を明確化しておく。

④前提及び制約条件

評価検証を進める上で前提条件や制約事項があれば記述する。（工数や期間、環境上の制約事項、事前に所得しておくべき認証基準、機密保持方針など）⑤利害関係者

対象の評価検証プロジェクトにおいて、顧客を含む、利害関係者を一覧として記載する。（顧客以外のプロジェクト関係企業についても記載）

２）評価・検証コミュニケーション①実行体制図対象の評価検証プロジェクトにおける実行体制図を記載する。開発や評価検証の責任者や指揮命令系統も含めて、明示しておく。

３）リスク一覧表①リスク一覧

対象の評価検証プロジェクトにおいて、製品開発上のリスク、プロジェクトの進行に関するリスクを記載する。

４）評価・検証方針①評価検証サブプロセ

評価検証対象となるシステムやソフトウェアにおいて、評価検証範囲となる機

Copyright 2017 Connected Consumer Device Security Council Proprietary7

3. セキュリティ評価検証の方針・計画策定
ス

能を明示しておく。

②成果物

対象となる評価検証プロジェクトの最終成果物を記載する。

③評価検証設計手法

今回利用を想定しているセキュリティ評価検証手法を記載する。
詳細な評価検証要件については、後述の評価検証設計フェーズにて検討を行う。

④完了基準

検証完了の条件や判定基準について、記載を行う。

⑤収集するメトリクス

検証完了後、次回以降の評価検証プロセスを改善（フィードバック）するために必要な収集メトリクスを定義しておく。
※フィードバックのプロセスについては「6.評価検証プロジェクトの総括・フィードバック」を参照。

⑥必要となるデータ・

評価検証のテストベースとなる対象機器（以下 DUT）の要件定義書、設計ドキ

ドキュメントュメント等。

⑦必要となる環境必要とされるテスト環境を記載する。

⑧評価検証の再実施

不具合、インシデントが検出された場合、改修後の再評価検証の実施に関する条（回帰テスト）件を記載する。

⑨中断及び再開基準

ブロッキングとなる課題が検出された場合など、評価検証を中断する条件や、再開の条件について記載する。

５）評価検証活動の役割分担、要求スキルレベル及び工数見積り
役割分担、スキル、工数

検証想定内容を各サブプロセスに分解し、サブプロセス毎の役割分担、見積工数、見積もり一覧

業務内容と必要なスキルレベルについて記載する。

６）人材①役割、活動、責任評価検証を実施する体制において、各人の役割、活動範囲、責任を一覧として作成する。

②雇用の必要性

評価検証を進めるにあたり、雇用の必要があれば、スキルイメージも含めて記載する。

③教育の必要性

評価検証の実行において、教育すべき内容があれば、記載する。

7)スケジュール
検証スケジュール表

評価検証全体のスケジュール及び、マイルトーンを表としてまとめる。
評価検証環境の構築や、評価検証要件（仕様書）及び、検証項目のレビュー日程、評価検証完了日（報告日）等のマイルストンについても明記しておく。また、評価検証状況の中間報告のタイミングや周期についても、記載しておく。

Copyright 2017 Connected Consumer Device Security Council Proprietary8

4. 評価検証設計

4. 評価検証設計
4-1. 製品開発ライフサイクルと関連するセキュリティ対策
セキュリティ検証では、「製品企画」フェーズにて脅威分析を行い、対象となるシステムやソフトウェ
アに、具体的にどのような脅威が潜在、どのような対策が必要となるかを事前に分析した上で評価検証
設計に移行する。
以下の図に、製品ライフサイクルの各工程において必要なプロセスを記載する。
「評価」フェーズ単独
としてではなく、製品ライフルサイクル全体においてセキュリティ対策を念頭に置いた取り組みが必要である。またセキュリティ以外の品質特性についても、脆弱性の原因につながる可能性があるため、既存の製品品質を対象としたプロセスとも統合された管理体系が必要となる。
※具体的な脅威分析の手法については、「CCDS 製品分野別セキュリティガイドライン」[4][5][6][7]並びに IPA「つながる世界のセーフティ＆セキュリティ設計入門」[13]等の参考資料を参照。
図 4-1. 製品ライフサイクルの各工程におけるセキュリティ対策
製品企画（要件定義）

製品品質を
対象とした
既存の評価
領域

設計・製造（実装）

評価

運用保守

廃棄

●静的検証（ドキュメントレビュー）①設計ドキュメントに対する静的検証（非セキュリティ領域）●セキュリティ以外の品質特性の評価・テスト－単体、結合テスト－システムテスト※セキュリティ関連機能に対するテスト含む●脅威分析－守るべき資産の想定－過去の脅威事例の分析－脅威の洗い出し－ビジネスインパクトの分析●対策方針や設計方針の決定

セキュリティ
を対象とし
た新しい評
価検証の領
域

●静的検証（セキュアプログラミング）①設計ドキュメントに対する静的検証●静的検証（ソースコード）①ソースコードに対する静的検証

本書が特に定義の対本書が特に定義の象としている箇所
対象としている箇所●（セキュリティ）動的検証②脆弱性スキャンチェック③ペネトレーションテスト（DoS攻撃）④ファジングテスト●運用時対策
●脆弱性対策Copyright 2017 Connected Consumer Device Security Council Proprietary9

4. 評価検証設計

4-2. セキュリティ評価検証の手法
4-1 項に記載したセキュリティ評価検証の各手法について、以下にて説明を行う。評価検証手法はプトグラムの実行を伴わずにロジックの評価検証を行う静的な検証手法と、実際にプログラムを動作させた上で挙動を確認する動的な検証手法に大別され、それぞれ適応可能なフェーズが異なる。
また情報セキュリティに関する評価検証の手法については、NIST SP800-115[10]に、より詳細な内容が記載されており、本文書とあわせて参照を推奨する。

表 4-1. セキュリティ評価検証手法の分類
種別

静的検証手法
名称

既知の①設計ドキュメントレ

脆弱性

ビュー
①ソースコードレビュ

動的検証手法

利用フェーズ

名称

利用フェーズ設計・製造（実装） ②脆弱性スキャンチェック

評価検証

設計・製造（実装） ③ペネトレーションテスト

評価検証ー①コード規約検証

設計・製造（実装）

未知の④ファジング

評価検証

脆弱性4-2-1. 静的検証手法①設計ドキュメントやソースコードに対する静的検証
・設計ドキュメントレビュー
各種設計ドキュメントに対して、「セキュリティバイデザイン」の考え方に基づき、必要なセキュリテ
ィ対策が組み込まれているかどうかをレビューによって確認する。

・ソースコードレビュー(解析)、コーディング規約検証
ソースコードに対して、セキュリティ上の脆弱性の検証や、コーディング規約に基づく実装が行われているかどうかの検証を行う。ソースコードに対する検証は各種静的検証ツールによる検証の自動化が主流であり、業務効率化のためにも有効に活用することが望ましい。
※静的脆弱性検証ツールについては、巻末の Appendix1.セキュリティ検証ツール一覧にて、
Copyright 2017 Connected Consumer Device Security Council Proprietary10

4. 評価検証設計「表 A1-1.

主要な静的脆弱性検証ツール一覧」を掲載。

4-2-2. 動的検証手法
1)既知の脆弱性検証手法
各種検証ツールを使用することで、既知の脆弱性情報を元に、ソフトウェアやネットワーク上の脅威を自動で検査することが可能となる。

②既知の脆弱性スキャンチェック
・Web アプリケーション脆弱性スキャンツール
Web アプリケーションの脆弱性を検出することを主としたツールであり、OWASP や WASC が外部に公開している脆弱性情報を元に、主要な脆弱性の検出を行うことができる。一例を挙げると、不正なHTTP リクエストを送信し擬似攻撃を行うことで、クロスサイトスクリプティングや SQL インジェクシ
ョン、Server Side Code インジェクション等の脆弱性を検出する事が可能である。

・ネットワーク脆弱性スキャンツール
ネットワークレイヤーの脆弱性を見つけることを目的としたツールであり、サーバやネットワーク機
器の設定不備やパッチ適用の不備による、バッファオーバーフロー等の脆弱性を検出することができる。
ネットワーク脆弱性スキャンツールは、正常あるいは不正なパケットを送信し、対象の DUT の挙動をモニターすることで脆弱性の有無を判定する。
※脆弱性スキャンツールについては、巻末の Appendix1.セキュリティ検証ツール一覧にて、「表 A1-2.主要な脆弱性スキャンツール一覧」を掲載。

③既知の脆弱性情報に基づくペネトレーションテスト
既知の脆弱性情報を元に、実際に攻撃対象への侵入を想定したシナリオ（exploit データ）によって侵入可否の検証を行う。検証ツールの多くは、脆弱性スキャンツールと連携し、検出された脆弱性情報を元に exploit データの作成から侵入試験までをほぼ自動で実施可能となる。
また、攻撃対象への侵入の入り口として、ポートスキャンや DoS 攻撃が行われる可能性が高いため、解放ポートに対するスキャンチェックや各種 OSS を活用した DoS 攻撃に対する堅牢性をテストしておくことがセキュリティリスクを低減する上でも有効である。
※ペネトレーションツールについては、巻末の Appendix1.セキュリティ検証ツール一覧にて、
Copyright 2017 Connected Consumer Device Security Council Proprietary11

4. 評価検証設計「表 A1-3.主要なペネトレーションツール一覧」を掲載。

2)未知の脆弱性検証手法④ファジングテスト
ファジングテストとは、対象機器に対して「ファズ（fuzz）」と呼ばれる不正データを大量に送信し、その応答や挙動を監視することで脆弱性を検出する検査手法を指す。ファジングテストは、既知の情報として公開されていない潜在的な脆弱性を検出することに効果的と言われる手法である。

表 4-2. ファジングテストの種類
ファジングの種類

説明①コマンドラインのファジング

コマンドライン引数をファジングデータとして入力する。

②環境変数のファジング

CUI に対する環境変数をファジングデータとして入力する。

③ファイル形式のファジング

不正な画像や音声、動画データなどを作成し、メディア再生機器に読み込ませることで脆弱性を検出する。

④Web ブラウザのファジング

サーバからの HTTP レスポンスをファジングデータとして入力する。
Web アプリケーションが広く用いられるため、検証用のツールも数多くリリースされている⑤ネットワークプロトコルのTCP/IP や HTTP など、ネットワークプロトコルのデータ構造を元に

ファジング

入力データを作成する。

⑥Web アプリケーションのフォームへの入力値など、Web アプリケーションを対象としたファジ

ファジング

ング。

※ファジングツールについては、巻末の Appendix1.セキュリティ検証ツール一覧にて、「表 A1-4.主要なファジングツール一覧」を掲載。

Copyright 2017 Connected Consumer Device Security Council Proprietary12

4. 評価検証設計
4-3. 評価検証仕様書の策定及び、評価検証ツールの選定
対象機器（DUT）に対する具体的な評価検証要件や、具体的な実施内容を決定するため、評価検証仕様書を策定する。評価検証仕様書では、製品企画フェーズで行った脅威分析結果をシステム構成に落とし込む「分析フェーズ」、対策の妥当性を評価検証するための手法やツールを調査するための「技術調査フェーズ」、調査結果をもとに具体的なテストケースを作成するための「評価検証仕様フェーズ」と順を追って進めていく。各フェーズの記録を文書化しておく事で、実施内容の策定経緯をエビデンスとして記録しておけると同時に、今後のプロセス改善にも活用することができる。
また、評価検証仕様については、該当のプロジェクトでどこまで評価検証（監査）を行うかを、明確にレベル定義しておき、顧客あるいは管理層や開発部門と協議のもと、合意の上で決定する必要がある。

図 4-2. 脅威分析～評価検証仕様書策定プロセス
STEP2
評価検証調査フェーズ

STEP1
分析フェーズ「脅威」・「対策」の具体化対策の妥当性をどのような評価
検証手法、評価検証ツールで確認可能かを調査する「対策」の妥当性をどう評価検証するか？

製品企画フェーズで実施した脅威分析結果をもとに、DUTのシステ
ム構成の中で、守るべき資産と想定脅威及び対策を具体化する

STEP3
評価検証仕様フェーズ

調査結果をもとに、評価検証の内容をテストケースとして具体化する「評価検証」内容の具体化

表 4-3．評価検証仕様書の策定プロセス詳細手順
フェーズ

文書名

説明

STEP1

DUT の機器構成を理解し、守るべき資産と想定脅威、対策を明確化する

分析フェーズ1-1)機器構成と想定脅威

DUT のシステム構成図において、データの入出力やインタフェー
スを踏まえ、想定される脅威を明確化する。
※「参考 1）機器構成と想定脅威の記載ガイド」を参照。

Copyright 2017 Connected Consumer Device Security Council Proprietary13

4. 評価検証設計
1-2)想定脅威への対策検討

保護すべき資産への想定脅威に対して、どのような対策が必要であるかを、Online Trust Alliance （ O TA） の 「 OTA IoT
Trust Frame work」 [11] や 、OWASP の「OWASP Top 10 IoT
Vulnerabilities」[12]等のフレームワークを参考に検討し、対応する対策番号を記載する。
※脅威と対策の検討用に、「参考 1）機器構成と想定脅威の記載
ガイド」として、スマートホームで想定される脅威や対策の記載事例を掲載。

STEP2実施した対策が実際に機能しているか、有効であるかを検証するため、適切な評価検証手法やツ

評価検証ツール調査

ールを選定する。

フェーズ2-1)通信プロトコル調査

DUT のインタフェース及び、通信プロトコルの仕様調査を行う。

2-2)評価検証ツール調査①評価検証ツール選定対策を実施した OTA、OWASP の番号を参考に、評価検証の目的に合致したツールの調査を行う。上記の分析フェーズでまとめた
脅威、対策に対して、必要な評価検証技術や評価検証ツールを対応づける。
※調査結果をまとめる上での参考用として、下記に「参考 2）対策に対する評価検証手法の検討ガイド」を掲載。
※ツール選定は、「Appendix1 セキュリティ検証ツール一覧」を参考とする。
②インタフェース・プロトコル調査
上記①のツールが、DUT のインタフェースや通信プロトコルに適合しているか調査を行う。

2-3)入出力解析

スキャンツール等を活用し、DUT 側へのデータ入出力方法の調査を行う。
※TCP/IP ポートスキャン、Bluetooth の UUID 検索など、インタ
フェース毎に調査を行う。

2-4)接続確認

DUT と評価検証ツールで接続試験を行い、検証結果の応答があるかを確認する。

Copyright 2017 Connected Consumer Device Security Council Proprietary14

4. 評価検証設計
STEP3

必要な評価検証(監査)レベルの設定及び、ツールが保有する機能から、テストケースを作成する。

評価検証仕様フェー3-1) 評価検証（監査）レベ

予算や環境、ユースケースや運用状況に応じて、今回の検証にお

ズ

ルの定義

いて、どこまでの評価検証を実施するか、レベル定義を行う。
※評価検証（監査）レベルの定義は、企業やプロジェクトの状況によって異なるため、顧客や意思決定層との合意の元に設定すること。
※参考指標として、「参考 3）評価検証（監査）レベルの定義ガ
イド」を掲載。

3-2)テストケース策定

選定したツールが有する評価検証機能を細分化し、具体的な検証
内容を評価者が理解できるよう、テストケースとして整理する。
※対応する評価検証データが存在する場合は、テストケースの個
別項目と対応させて記載しておく。

3-3)実行優先度設定

上記 3-2)のテストケースに対して、評価検証の優先順位を設定する。

注記）
評価検証仕様書の策定プロセスを定義するにあたり、IPA 発行の「IoT 開発におけるセキュリティ設計の手引き」[13]を参考資料としており、本文書とあわせて参照を推奨する。
また、以下に記載している「参考１）～参考３）」については、本章記載の策定プロセスにおいて、具体的なアウトプットを想定した参考事例となる。本文書の巻末には「Appendix3

評価検証仕様書の実例集」として、実際にスマートホームを対象に評価検証の実証実験を行った際の、仕様書をサンプル事例として掲載している。

Copyright 2017 Connected Consumer Device Security Council Proprietary15

4. 評価検証設計

参考 1）機器構成と想定脅威の記載ガイド
図 4-3. スマートホームにおける想定脅威と対策一覧※参考用にスマートホームで想定される脅威と OTA、OWASP のフレームワークに基づく対策を抽出し、図表化した。

Copyright 2017 Connected Consumer Device Security Council Proprietary16

4. 評価検証設計参考 2）対策に対する評価検証手法の検討ガイド
表 4-4. 想定脅威と対策及び、評価検証手法(ツール)の一覧
脅威発生個所

保護すべき資産

・個人情報
・設定情報
・ログ情報
・セキュリティ情報
サービスアプリ（電子証明書、暗（サーバ）
号鍵、パスワード）・金銭に紐づけられる情報・サーバ機器本体

不正アクセスウィルス感染
DoS攻撃

ユーザ認証

OTA11,12,13,14 OWASP1,2,6,8

対策名

FW/IDS/IPS
ログ分析
脆弱性対策
ソフトウェア署名

情報漏洩

不正アクセスOWASP3
OTA15
OTA4,5OTA6DoS対策
データ暗号化

盗聴・改竄

・個人情報
・設定情報
・ログ情報
IoT-GW（ホーム・セキュリティ情報
ルータ）（電子証明書、暗号鍵、パスワード）
・IoT-GW本体

サーバセキュリティ
脆弱性対策

対策候補
他のガイドラインとの関係
OTA
OWASP
OTA4
OTA5
OWASP1,6

脅威名

OWASP9OWASP3OTA2OWASP5,8

データ二次利用禁止 OTA25
OTA1.3
OTA5

ユーザ認証

OTA11,12,13,14 OWASP2,8

不正アクセス

情報漏洩

OTA1.3OWASP4,8－

ファジングテスト

Sulley

脆弱性対策

OTA5

脆弱性検査※※DUTがサーバ機能を有する場合にのみ有効

ユーザ認証

OTA11,12,13,14 OWASP2,8

ペネトレーション（Password攻撃対策）

Hydra

OTA2

DoS対策

OWASP3

データ暗号化OTA2

出荷状態リセット

OTA24

耐タンパ性S/WOTA7OWASP5.8

OWASP3OTA4.5

その他
未知の脆弱性

脆弱性検査※
脆弱性検査※
システムテストドキュメントレビュー※

ソフトウェア署名

OTA6

セキュア開発OTA2

DoS対策
データ暗号化OTA2

出荷状態リセット

OTA24

セキュア消去OTA30,31

HydraOpen VAS
Open VAS
Open VAS
Ostinate、GatlingOpen VAS※ユーザマニュアルを含めた確認を実施
Open VAS※DUTがサーバ機能を有する場合にのみ有効※DUTがサーバ機能を有する場合にのみ有効※ユーザへの注意喚起

OWASP9OWASP3

耐タンパ性H/W

盗聴・改竄

Ostinate、Gatling
OWASP ZAP※運用時のプライバシー
ポリシーを確認OWASP ZAP
Open VAS－

セキュア開発OWASP9アンチウィルスDoS攻撃OWASP ZAPOWASP ZAPOWASP ZAP

通信経路暗号化

OTA4.5
OTA6

脆弱性対策

・個人情報
・設定情報
・ログ情報
・セキュリティ情報
HNWにつながる（電子証明書、暗機器
号鍵、パスワード）・金銭に紐づけら
れる情報
・機器本体

Hydra

－

OWASP3

FW機能

ウィルス感染

検証ツール
Metasploit
OWASP ZAP

脆弱性検査
ネットワーク脆弱性検査
ペネトレーション（Password攻撃対策）
ネットワーク脆弱性検査
ネットワーク脆弱性検査
ネットワーク脆弱性検査
設計ドキュメントレビュー
ソースコードレビュー
コード規約検証
ペネトレーション（DoS攻撃対策）
ネットワーク脆弱性検査
システムテストドキュメントレビュー※
設計ドキュメントレビュー
ソースコードレビュー
コード規約検証
ネットワーク脆弱性検査

FW機能
脆弱性対策
ソフトウェア署名OWASP4,8

情報漏洩

盗聴・改竄
その他
未知の脆弱性ペネトレーションテスト
Webアプリ脆弱性検査
ペネトレーション（Password攻撃対策）
脆弱性検査
システムテスト
脆弱性検査
脆弱性検査
ペネトレーション（DoS攻撃対策）
脆弱性検査
ドキュメントレビュー※

通信経路暗号化
脆弱性対策

ウィルス感染

DoS攻撃

検証手段
検証手法

OWASP5.8

設計ドキュメントレビュー
ソースコードレビュー
コード規約検証
ペネトレーション
Ostinate、Gatling（DoS攻撃対策）※DUTがサーバ機能を脆弱性検査※
有する場合にのみ有効
システムテストドキュメントレビュー※OWASP10耐タンパ性S/W

OTA7

通信経路暗号化OTA1OWASP8－－－※ユーザマニュアルを含めた確認を実施

システムテスト
リバースエンジニアリング※必要に応じて対応※
設計ドキュメントレビュー
ソースコードレビュー
コード規約検証※DUTがサーバ機能を脆弱性検査※
有する場合にのみ有効
ファジングテスト

SulleyCopyright 2017 Connected Consumer Device Security Council Proprietary17

4. 評価検証設計参考 3）評価検証（監査）レベルの定義ガイド
表 4-5. スマートホームにおける評価検証（監査）レベルの定義事例※以下の表では HAN 側の機器をまとめて定義しているが、実際の評価検証では個別機器ごとに要件定義を行う必要がある。
対象（保護すべき資産）

守るべき資産Level1

想定脅威
検証内容

サービスアプリ（サーバ）

IoT-GW（ルータ）

HAN側の接続機器

・個人情報
・設定情報
・ログ情報
不正アクセスウィルス感染・セキュリティ情報（電子証明書、暗号鍵、パス DoS攻撃
情報漏洩
ワード）
・金銭に紐づけられる情報・サーバ機器本体

・個人情報
・設定情報
不正アクセス・ログ情報
ウィルス感染・セキュリティ情報
DoS攻撃（電子証明書、暗号鍵、パス 情報漏洩
ワード）
盗聴・改竄
・IoT-GW本体

・個人情報
・設定情報
不正アクセス・ログ情報
ウィルス感染・セキュリティ情報
DoS攻撃（電子証明書、暗号鍵、パス
情報漏洩
ワード）
盗聴・改竄
・金銭に紐づけられる情報
・機器本体

利用ツール（例）・Webアプリ脆弱性スキャン
OWASP ZAP
チェック
・ペネトレーションテスト1－DoS攻撃対策

Ostinate、Gatling・ペネトレーションテスト1－Password攻撃

hydra

・ファジングテスト

Sulley（HTTP、CoAP対応）

・ネットワーク脆弱性スキャ
Open VAS
ンチェック

対策レベル
Level2
検証内容
利用ツール（例）
Level1の検証－

Level3
検証内容
Level2の検証

備考・留意事項
利用ツール（例）－・静的脆弱性検証－設計ドキュメントレビュー iCodeChecker（※）－ソースコードレビュー※ソースコード－コーディング規約検証

・ペネトレーションテスト3－既知の脆弱性に対する Metasploit
総合的な検証Level1の検証

Level2の検証－

・静的脆弱性検証－設計ドキュメントレビュー iCodeChecker（※）－ソースコードレビュー※ソースコード－コーディング規約検証

・ペネトレーションテスト1－DoS攻撃検査

Ostinate、Gatling・ペネトレーションテスト1－Password攻撃

hydra

・ペネトレーションテスト２－WiFI攻撃Aircracking-ng

・ファジングテスト

Sulley（HTTP、CoAP対応）

Level1の検証－

・ペネトレーションテスト1－DoS攻撃検査

Ostinate、Gatling・ペネトレーションテスト1－Password攻撃

hydra

・静的脆弱性検証－設計ドキュメントレビュー iCodeChecker（※）－ソースコードレビュー※ソースコード－コーディング規約検証－

・ペネトレーションテスト3－既知の脆弱性に対する Metasploit
総合的な検証Level2の検証

ファジングについては、対応プロトコルに合わ
せてツールの選定を行
うこと－・ペネトレーションテスト3－既知の脆弱性に対する Metasploit
総合的な検証Copyright 2017 Connected Consumer Device Security Council Proprietary

サーバに対する検査は、不正アクセス禁止法に抵触しないよう、サーバ管理企業（サービス提供企業）との合意において検証を行う必要がある。

ファジングについては、対応プロトコルに合わ
せてツールの選定を行
うこと18

4. 評価検証設計

4-4. 評価検証手順書の策定
4-3 項で作成したテストケースをもとに、具体的な検証手順を追加した評価検証手順書を策定する。評
価検証手順書は、評価検証者が正確に評価検証を行えるよう、詳細化した実施手順を記載しておく。また、使用する評価検証データやパラメータを明確化しておくで、評価検証結果のエビデンスとしての精度を高めることができる。
評価検証手順書はシステムテスト等に用いる標準的なテストフォーマットを利用しても問題ないが、ツール側が出力した結果と、評価検証者が最終的に判定した結果を、それぞれ区別して記録できる形式が必要である。

4-5．評価検証データの準備
・例）ファジングデータの作成方法
脆弱性スキャンやペネトレーションテストについては、既知の脆弱性や exploit データをもとに検証を行うため、ツール側が利用している脆弱性情報が最新であるかが重要であり、評価検証者が新規に評価検証用のデータを作成するケースは少ない。一方でファジングテストについては、特に OSS を使用する
場合、ファズデータを評価検証者が新規に作成する場合がある。以下では、一般的なファジングデータの作成方法について記載するが、詳細については、IPA「ファジング実践資料」[14]等の参照を推奨する。

表 4-7. ファジングデータの種類
データ構造のデータ作成手法

説明

ス マ ー ト フ ァ ジ ン グ （ Smart

データ構造の要素をそれぞれ細工してデータを作成

fuzzing）

する。データ作成は非常に時間が掛かるが、効率は高※ Generation based fuzzing 、

い

解釈
解釈する

Intelligent fuzzing とも呼ばれ
る。
解釈しない

ミューテーションファジング

正常なデータを読み込み、そのデータをランダムな値（Mutation fuzzing）に変更する。データ作成はある程度容易であり、効率性も比較的高い。

ラ ン ダ ム フ ァ ジ ン グ (Dumb

まったくランダムな値からデータを作成する。データ

Copyright 2017 Connected Consumer Device Security Council Proprietary19

4. 評価検証設計

その他

fuzzing)

作成は容易だが、効率が悪い

自動（プロトコル）生成

一定の原則に従って、指定の範囲内で連続的に値を変化させてデータを生成する。

表 4-8. データの作成方法の一例
特定の脆弱性検出に特化した値
バッファオーバーフローの脆弱

極端に長い文字列（例：「A」1000 個以上）

性
書式文字列の問題

C 言語の printf()関数などで使う書式文字列（例：「%s%s%s%s」）

数値処理に関する問題（整数オ

バッファの上限値や下限値として使われそうな数値やプログラミングーバーフローの脆弱性など）言語のデータ型のサイズに関連する数値（例：0、65535 や 65536）

特別な意味を持つ値
ヌルバイト（NULL）「0x00」（16 進数表記）（C 言語などの言語処理系では、文字列の終端を意味する）

区切り文字

データ構造におけるデータの区切りを意味する値
例１：改行コードや（「0x0d」(16 進数表記)や「0x0a」（16 進数表記）
例２：「“」や「＃」（出典：IPA 発行「ファジング実践資料」[14]）Copyright 2017 Connected Consumer Device Security Council Proprietary20

5. 評価検証実行

5. 評価検証実行
5-1. セキュリティ評価検証の実行
セキュリティ評価検証の実行は、自動化されたツールを用いた場合でも評価検証内容の組み合わせによって、実行処理完了までに時間を要する可能性がある。ツールの実行所要時間については、事前に把握しておくことが望ましい。
ツールによる検証完了後の出力結果については、ツールが出力した結果に対して、ログ情報等をもとに、結果の正当性を評価検証者が解析し、結果判定を行う必要がある。また評価検証者が正しい判定を行うためには、DUT 側のプログラムに関する知識や、ツール側の結果判定ロジックについても理解しておくことが必要となる。以下では、評価検証者が結果判定を行うために必要な情報やナレッジを記載する。

表 5-1. 評価検証の実行及び、最終的な結果判定に必要な情報・ナレッジ※評価検証ツールによっては、ログ情報を外部ファイルとして出力する機能を持たない場合があり、注意が必要である。

名称検証ツールの操作、設定

情報種別

説明

マニュアル

検証ツールの操作、構築、設定方法に関する知識。

評価検証 内容に関する知評価検証仕様、ツール側の検評価証内容の詳細項目及び、その内容に関する知

識

検証項目

識。

評価検証 ツールの結果判ドキュメント

ツール側がどのようなロジックで結果判定処理を行うのか、そに関する知識定処理に関する知識の内容に関する知識。
例）ファジングでは不正データ送信後、正常なリクエストを
DUT に送信し、DUT からの応答の挙動や遅延を監視する。
※ツールによっては、判定ロジックがブラックボックスのものも存在する。

DUT 側のプログラムに設計ドキュメDUT に関する要件定義、設計ドキュメント及び、その内容に

関する知識

ント

関する知識。

DUT 側のプログラムの

ログ情報

原因の切り分けに活用するための、プログラムのログ及び解析

ログ

知識。

評価検証 ツールの実行ロ

グ

ログ情報

ツール側の実行過程を記録したログ情報及び、その内容を解析できる知識。
※例）シーケンスログ、DUT 側の応答シーケンスや応答パラ

Copyright 2017 Connected Consumer Device Security Council Proprietary21

5. 評価検証実行
メータ値など評価検証 ツールの結果ロ

ログ情報

グ

ツール側の判定処理を経由した出力結果及び、その内容を解析できる知識。
※例）判定結果、脆弱性と想定される理由や箇所などの情報を含めた詳細※検証実行時の注意事項
セキュリティ検証は DUT に対して、不正信号を送信するものが多いため、DUT 以外のデバイスに誤送信しないよう十分注意する必要がある。可能であれば、シールドルーム等の電波遮断環境を利用し、DUT と検証ツールが 1 対１で検証を行うことが望ましい。

5-2. 検出されたインシデント情報の管理方法
評価検証実行によりインシデントが検出された場合には、以下の項目を参考に、インシデントレポー
トを起票し、情報管理を行う。インシデント情報は、評価検証部門と顧客あるいは開発部門で共有し、該当する問題が、セキュリティの脆弱性にかかわる内容かどうかを両部門で精査を行うことを推奨する。

5-2-1.

インシデントレポートフロー

評価検証実行の結果、不正な挙動が確認された場合、インシデントとしてレポート報告を行うが、評価
検証部門単独ではセキュリティ上の脆弱性につながるインシデントかどうかは、プログラム側の解析が必要となり、判断が難しいケースもある。推奨する報告フローとしては、判断が難しい場合には DUT 側の不正な挙動を不具合インシデントとしてレポート報告の上、開発部門との協議を経て、脆弱性につながる課題については、別途セキュリティインシデントとしてレポート報告することが望ましい。レポー
ト報告や管理が煩雑になるようであれば、セキュリティインシデントのレポートのみの運用とし、評価検証部門と開発部門でディスカッション可能なフォームを設定し、双方の意見をエビデンスとして記録しておくことで、効率化を図ることも可能である。

5-2-2.

セキュリティインシデントレポートの記載項目

セキュリティインシデントのレポート記載項目については、IPA が IEEE1044 などのグローバル標準との整合性を考慮した作成した ESBR[15]を参考にセキュリティに関する項目を追加した案を以下に記
Copyright 2017 Connected Consumer Device Security Council Proprietary22

5. 評価検証実行載する。例えば、インシデントの深刻度や、既存の脆弱性データベース（JVN や、NVD、OSDBD）に登録されている脆弱性識別番号、CWE（共通脆弱性識別子）などは、インシデントの改修優先度の判定
や原因分析に有効な情報である。

表 5-2. インシデント情報の記載項目要件
項目名

担当

記載内容の説明検証部門

インシデント管理番号１）インシデント内容
管理番号※各検証プロジェクトを通じて、一意の値が望ましい。
※同一原因の管理番号を記載できることを推奨。
プロジェクト名

検証部門

検証あるいは開発プロジェクト名

深刻度基準

検証部門

※4-2-4 項を参照

ステータス

検証部門

インシデントレポートのステータス例）作成中、仮登録済み、本登録済み、差戻し、改修中、改修完了、
クローズ等

クローズ理由検証部門

インシデントレポートをクローズした理由を記載
例）改修済、次機種検討、現状通り、ドキュメント修正

発行日

検証部門

インシデントレポートの発行日(登録日)を記載

完了日

検証部門

インシデントレポートをクローズした日付を記載

レポートタイトル

検証部門

インシデントレポートのタイトル※200 文字以内で、簡潔かつインシデントの重要性を示すタイトルが
望ましい。

発行者名

検証部門

インシデントレポートの起票者名を記載

内容

検証部門

下記の記載内容をカバーすること
・試験環境
・設定条件
・試験手順
・発生する問題・期待する動作・発生条件

Copyright 2017 Connected Consumer Device Security Council Proprietary23

5. 評価検証実行
添付ファイル

検証部門

内容を補足するログデータ等、添付資料を付加する。

機能名

検証部門

対象のシステムやソフトウェアの機能名を記載する

発見バージョン

検証部門

インシデントを確認したバージョンを記載する

発生環境

検証部門

インシデントを確認した環境を記載する（サブシステム名）

例）テスト環境など、
発生頻度

検証部門

試行回数に対するインシデントの発生回数を記載する例）XX（発生回数）/YY（試行回数）

発見工程

検証部門

インシデントを発見した工程

発見手段

検証部門

コードレビューやテスト名称等、インシデントを発見した工程名称を記載する。

評価検証項目番号

検証部門

インシデントを発見した評価検証項目の番号を記載する。

検証シナリオ名

検証部門

インシデントを発見した検証シナリオ名（あるいはシナリオ番号）を記載する。

影響を受けるシステ

検証部門

ム

インシデントによって影響が想定される機能名やサブプロセスを記載する。

想定される影響検証部門

インシデントによって、どのような影響が想定されるのか具体的な内容を記載する。

参考情報

検証部門

JVN、NVD における関連インシデント番号。CVE 番号や CWE 識別
子等、解析に役立つ情報や関連情報を記載する。

２）開発調査内容/対策
処置担当者

開発部門

インシデントの原因調査や改修対応等の処置に対する担当者名を記
載する。

処置完了日

開発部門

処置の完了日を記載する。

発生原因

開発部門

インデントの発生原因を記載する。

原因箇所

開発部門

バグが発生した原因を含むソフトウェア成果物。仕様書であれば仕様
書名（ファイル名）とその頁、行数など。ソースコードであれば、ファイル名、関数名、行数なし。

対応見積工数開発部門

修正を行う場合の見積工数を記載する

解決方法/処置内容

開発部門

解決方法、修正内容あるいは対応方針を記載する。

Copyright 2017 Connected Consumer Device Security Council Proprietary24

5. 評価検証実行
処置区分

開発部門

開発部門としての対応方針を記載する。
例）仕様通り、プログラム改修、ドキュメント対応、次機種対応、対応見送り等。

修正対象

開発部門

修正や改修を行った仕様書名や、ソフトウェアコードのファイル名等を記載する。

修正バージョン

開発部門

修正を行ったバージョン名称を記載する。

リリース日

開発部門

修正バージョンのリリースに日時を記載する。

３）その他、分析やフォードバックに活用する項目
不具合区分

開発部門

インシデントの原因となった不具合の分類区分を記載する。今後のフィードバックや分析に活用できるよう IPA 発行の ESBR[15]等に準拠した分類項目が望ましい。

作り込み工程

開発部門

インシデント原因となる不具合を作り込んだ工程を記載する。
例）システム要求定義（ システム要求分析）、システムアーキテクチャ設計（ システム方式設計）、ソフトウェア要求定義（ ソフトウェア
要求分析）、ソフトウェアアーキテクチャ設計（ソフトウェア方式設計）、ソフトウェア詳細設計（ソフト ウェア詳細設計）、実装（コーデ
ィング）。

調査工数

開発部門

インシデントの原因調査に要した工数を記載する。

処置工数

開発部門

インシデントの改修対応に要した工数を記載する。

発見すべき工程

開発部門

本来インシデントや原因となった不具合を発見すべき工程を記載する。

発見すべきアクティ

開発部門

ビティ

本来インシデントや原因となった不具合を発見すべきアクティビテ
ィを記載する。※アクティビティ：工程作業を、さらに分割し、順序付けした作業要素。

４）ディスカッションエリア
ディスカッション

開発部門

検出されたインシデントについて、実際にセキュリティの脆弱性につ及びながる問題かどうかを、検証部門と開発部門とでディスカッションを開発部門

行い、精査する。ディスカッション内容はエビデンスとして、インシデント情報の一要素として管理しておく。

Copyright 2017 Connected Consumer Device Security Council Proprietary25

5. 評価検証実行■インシデントレポートのフォーマット事例
CCDS が構築した「組込機器検証基盤システム」では、上記の要件を網羅したインシデントレポートの作成、管理が可能であり、レポートフォーマットの参考例として掲載する。CCDS の検証基盤システ
ムでは、CVSSv3[16]による深刻度判定を機能として組込んでおり、必要事項を入力する事で、深刻度の数値判定が自動で出力される。また検証基盤では、インシデントレポートとセキュリティ品質レポートが連携しており、インシデントの数や深刻度に応じて、品質判定のスコアリングが自動的に決定する機能を実装している。※詳細は「5-3. 報告・評価検証完了」）を参照。

図 5-1. 脅威内容のフォーム事例

出展：CCDS「組込機器検証基盤システム」の脅威レポート作成機能より

Copyright 2017 Connected Consumer Device Security Council Proprietary26

5. 評価検証実行
図 5-2.

CVSSv3 による深刻度入力フォーム事例

出展：CCDS「組込機器検証基盤システム」の脅威レポート作成機能より

図 5-3. 脅威に関する影響や補足情報のフォーム事例

出展：CCDS「組込機器検証基盤システム」の脅威レポート作成機能より
Copyright 2017 Connected Consumer Device Security Council Proprietary27

5. 評価検証実行
図 5-4. ディカッションエリアのフォーム事例

出展：CCDS「組込機器検証基盤システム」の脅威レポート作成機能より

図 5-4．インシデントの要因や対応方針などのフォーム事例

出展：CCDS「組込機器検証基盤システム」の脅威レポート作成機能より

Copyright 2017 Connected Consumer Device Security Council Proprietary28

5. 評価検証実行
5-2-3.

セキュリティインシデントの深刻度基準について検出されたインシデントについては、リスク評価手法による判断基準に沿って深刻度を記載する。リ
スク評価手法については、既に各種団体より公開されており、それぞれにリスクファクタや特徴が異なり、評価検証対象によって判定の妥当性に差異が生じる恐れがある。以下に記載した代表的なリスク評
価手法から、対象となるシステムやソフトウェアによって適切な深刻度基準を選択し、判定を行うことを推奨する。

表 5-3. スマートホーム分野への活用可能なインシデント(リスク)評価手法の紹介※詳細については、巻末の「Appendix4

リスク評価手法の紹介」を参照。

名称
1

CVSSv3[16]リスクファクタ・特徴■リスクファクタ
詳細は、巻末の「Appendix4 リスク評価手法の紹介」を参照。
1)基本評価基準（Base Metrics）
・「機密性」、「完全性」、「可用性」に対する影響から評価
2)現状評価基準（Temporal Metrics）
・攻撃コードの出現有無や対策情報が利用可能といった基準で評価
3)環境評価基準（Environment Metrics）
・二次的被害の大きさや、対象製品の使用状況といった基準で評価■特徴
機密性、完全性、可用性に対する影響を主軸に、詳細なリスク評価が可能。
リスクファクタが詳細に定義されており、NIST SP800-30 と同様に具体的な脆弱性が明確になっていないと、評価が困難なファクタが存在する。

2

NIST SP800-30[17]■リスクファクタ
1)THREAT SOURCES（脅威源）
2)THREAT EVENTS（脅威内容）
3)VULNERABILITIES AND PREDIPONSING CONDITIONS（脆弱性と発生条件）
4)LIKELIHOOD OCCURRENCE（発生の可能性）
5)IMPACT（影響度）■特徴

Copyright 2017 Connected Consumer Device Security Council Proprietary29

5. 評価検証実行
リスクファクタに対する計算式が定義されていない。脅威に関する評価項
目は、充実しているが、具体的なインシデントが明らかになっていないと評
価が困難なパラメータが存在する。
3

GMITS(ISO/IEC■リスクファクタ

TR13335[18]1)Asset（資産価値）
2)Threat（脅威）3)Vulnerability（脆弱性）■特徴
リスクファクタに対する計算式は定義されていない。リスクファクタの数は少ないが、「資産価値」が定義されている。

4

ETSI TS102 165-1[19]■リスクファクタ
1)Likelihood（攻撃の可能性）
1-1)Time（攻撃に要する時間）
1-2)Expertise(攻撃者のスキル)
1-3)Knowledge(システム知識)
1-4)Opportunity（攻撃の機会）
1-5)Equipment（設備）2)Impact（影響度）
2-1)Asset Impact（資産への影響）
2-2)Attack Intensity（攻撃の強度）■特徴
リスクファクタが詳細なため、具体的な脆弱性に対する分析に向いているが、事前の脅威分析では判定が困難なファクタがある。Time に高いウェイ
トが設定されているため、注意が必要。

5

情報マネジメントシステ■リスクファクタム(ISMS)ISO/IEC27001

1)資産の価値
2)脅威
3)脆弱性
■特徴
具体的な計算式については、JPDEC(日本情報経済社会推進協会)による例

Copyright 2017 Connected Consumer Device Security Council Proprietary30

5. 評価検証実行
示のみであり、規格としては提示されていない。
6

OCTAVE Allegro[20]■リスクファクタ
1)Impact Area：
1.評判（Reputation）
2.Financial（金銭）3.Productivity（生産性）、
4.Safety&Health（安全、健康）
5.Fines/Legal（罰金・法律）
2)Impact Value：Impact Area に対する影響度を High、Mid、Low の 3 段
階に分けたもの。
■特徴「Safety & Health（安全・健康）」がリスクファクタとして組み込まれている一方で脆弱性に関するファクタが存在しない。優先度や影響度の設定において主観に左右されやすい。

7

The

OWASP

Risk

Rating Methodology[21]■リスクファクタ
1)Threat agent（脅威の要因）
2)Vulnerability（脆弱性の要因）
3)Technical Impact(テクニカルインパクト)
4)Business Impact（ビジネス上の影響度）の４つの値の平均値によって、全体的なリスクを計算。
■特徴
金銭等の資産損失や、ブランド・信用棄損がリスクファクタに含まれる特徴がある。ファクタが多く、平均値によって総合リスクを判定するため、個別ファクタの数値にウェイトが存在しないため、全体に影響しにくい。

8

FAIR[22]■リスクファクタ
1)LEF：損失発生頻度（発生頻度、脅威難易度、保護強度、脆弱性）
2)PLM：金銭的な影響度によって評価。
■特徴
PLM の評価値が全体の結果に与える影響度が大きいという特徴がある。

Copyright 2017 Connected Consumer Device Security Council Proprietary31

5. 評価検証実行
9

CCDS 改良方式 0■リスクファクタ
1)難易度
2)影響度
3)攻撃者のモチベーション■特徴
特徴としては既存のリスク評価手法と比較し、より簡易に分析が可能であり、またリスクファクタに「攻撃者のモチベーション」が組み込まれ、影響度の基準として「人命リスク」を想定した基準を定義している。

5-3. 報告・評価検証完了
5-3-1. 評価検証の実施状況に関する報告
セキュリティ検証の実行状況に関する報告（中間報告）の頻度やタイミングについては、顧客あるいは開発部門と協議の上、決定し、評価検証計画書に記載しておく。
なお評価検証の実行状況については、ISO/IEC/IEEE29119[9]のマネージメントプロセスに従い、評価検証計画書に記載されたスケジュールやマイルストン通りに進んでいるかを監視し、実行管理される。

表 5-4. 中間報告における記載要件
項目

記載内容

進捗に関する報告事項
進捗状況のサマリ

簡潔なコメントにて、現状の進捗状況を説明する。

検証実行の進捗状況

検証手順書項目における実施完了数／全検証項目に対する進捗率を記載する。

実績工数

計画工数に対して現在までに要した実績工数を記載。

課題

現状の進捗において課題があれば、対策も含めて記載する。

セキュリティ品質に関する報告
セキュリティ品質状況のサマリ

簡潔なコメントにて、現在のセキュリティ品質の状況を説明。

不具合・セキュリティインシデント

これまで検出されたインシデントの総数、内容のサマリ一覧(タイトル、概要、深刻度、クローズ状況等)を記載。

検証実行における現状課題

Copyright 2017 Connected Consumer Device Security Council Proprietary32

6．評価検証プロジェクトの総括・フィードバック
課題

検証環境やデータ、進捗、インシデントに関する問題など、評価検証全般に係る課題事項を報告する。

5-3-2. 評価検証の完了報告
セキュリティ評価検証の完了については、計画書記載の完了条件に従うものとし、完了時には完了報告を行う。完了条件については、製品品質のテストと同様に、実施すべき全評価検証項目の完了及び、イ
ンデントレポートの全件完了をもって、完了することが望ましい。

表 5-5. 完了報告における記載要件
項目

記載内容

セキュリティ品質に関する報告
セキュリティ品質判定

評価検証結果として、合格／不合格の結果を判定基準と共に記載。

品質状況のサマリ

簡潔なコメントにて、完了時点のセキュリティ品質状況を説明する。

不具合・セキュリティインシデント

評価検証を通じて検出された全インシデントの総数、内容のサマリ一覧(タイトル、概要、深刻度、クローズ状況等)を記載。

評価検証実施項目に関する報告
評価検証実行状況に関するコメント

簡潔なコメントにて、完了時の状況を説明する

評価検証完了状況

評価検証手順書項目における実施完了数／全評価検証項目に対する進捗率（全件完了していることを前提とする）

実績工数

計画工数に対して、完了までに要した実績工数を記載。

その他申し送り事項等
課題

評価検証環境やデータ、進捗、インシデントに関する問題など、
評価検証全般に係る課題事項を報告する。

6．評価検証プロジェクトの総括・フィードバック
評価検証完了後は、検証用ドキュメントを情報資産として管理しておくと共に、評価検証計画書において「収集するメトリクス」として定義した項目については、次回の開発や評価検証プロセスにフィード
Copyright 2017 Connected Consumer Device Security Council Proprietary33

6．評価検証プロジェクトの総括・フィードバック
バックを行い、評価検証の効率や品質の向上に活用する。収集するメトリクスについては、評価検証完了
時にプロジェクトとして総括を行い、次回以降のデータ活用に向けて整理をしておく。

表 6-1. 収集メトリクスとフィードバック活用
1)効率向上に利用可能なメトリクス
収集メトリクス

説明①評価検証内容

・評価検証ツールが実行完了に要した時間②計画予定工数と実績工数

・予定工数を超過した場合には、その理由や対象のサブプロセス
名称・1 日/1 工数に対する検証項目数③評価検証スケジュール/マイルスト

・遅延が発生した場合には、その理由と対象サブプロセス名称

ンに対する進捗の予実

・1 日あたり検証項目数④その他

・事前準備や環境構築において、想定通りにいかなかったことなど

2)開発、評価検証プロセスの品質向上に利用可能なメトリクス①検証内容

・実施した評価検証項目(手順)・評価検証実施結果（検証ツール別のインシデントヒット数など）
・追加した評価検証データ、評価検証シナリオ②セキュリティインシデントレポー

・インシデントレポートの内容

ト・インシデントの原因（不具合レポート）・発見した手法（ツール名、シナリオ名）③開発部門、顧客からの指摘事項

・問い合わせ、クレーム、アドバイス事項など④その他

・品質上の改善点や気づいた点など

Copyright 2017 Connected Consumer Device Security Council Proprietary34

7．まとめ

7．まとめ
各団体が作成したセキュリティガイドラインと本書との対応関係を以下に示す。（枠内の評価検証プロセスを詳細に定義したものが本文書となる）
表 7-1. 本書と対応する他団体のガイドラインとの対応表
Io T推進コ ンソーシアム「 IoTセキュリティガイドライン」
要点1

IPA「 つながる世界の開発指針」

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

2.1 方針・管理

CCDS「 セ キュリティ ガイド ライン I o T- GW編」

指針1

安心安全の基本方針を策定する

4.2.1

製品企画フェーズ項番3:施策として情報
セキュリティ方針について記載。

指針2

安心安全のための体制・人材をも見直す

4.2.1

製品企画フェーズ項番3:施策として情報
セキュリティ方針について記載。

4.2.4

運用フェーズ2:施策として組織の体制につ
いて記載。

方針

要点2

内部不正やミスに備える

指針3

内部不正やミスに備える

4.2.2

要点3

守るべきものを特定する

指針4

守るべきものを特定する

2

要点4

指針5

つながることによるリスクを想定する

2.2 分析

つながることによるリスクを想定する

分析

4.2.1

製品企画フェーズ項番1,2:施策としてリスク分析について記載。

5

5章:実施例としてリスク分析の中で保護すべき資産について記載。

2

2章：実施例として各ユースケースにおける被害・影響をリストアップ。

3.3

3.3:想定されるセキュリティ上のリスク例について記載。

4.2.1

製品企画フェーズ項番1,2:施策としてリスク分析について記載。

5

5章:ユースケースにおけるリスク例につい
て記載。

要点5

つながりで波及するリスクを想定する

指針6

つながりで波及するリスクを想定する(同上)

指針5と同一。

要点6

物理的なリスクを認識する

指針7

物理的なリスクを認識する

4.2.1

製品企画フェーズ項番1,2:施策としてリスク分析について記載。

4.2.2

設計・製造フェーズ項番5:施策として物理的な攻撃に対する対策について記載。

5

5章:ユースケースにおける物理的リスク例について記載。

要点7

過去の事例に学ぶ

要点8

個々でも全体でも守れる設計をする

指針8

個々でも全体でも守れる設計をする

4.2.2

設計・製造フェーズ項番2,5:施策としてセキュリティ機能の実装について記載。

要点9

つながる相手に迷惑をかけない設計をする

指針9

つながる相手に迷惑をかけない設計をす
る

4.2.2

設計・製造フェーズ項番2:施策として迷惑をかけないための機能について記載。

指針10 安全安心を実現する設計の整合性をとる

4.2.1

要点10 安全安心を実現する設計の整合性をとる
2.3 設計設計
4.2.2
不特定の相手とつなげられても安全安心

不特定の相手とつなげられても安全安心

要点11 を確保できる設計をする

指針11 を確保できる設計をする

安全安心を実現する設計の検証・評価を

安全安心を実現する設計の検証・評価を

要点12 行う

指針12 行う機器等がどのような状態かを把握し、記録

自身がどのような状態かを把握し、記録す

要点13 する機能を設ける
2.4 構築・接続

設計・製造フェーズ項番6:施策として開発時の外部委託における取り組みについて記載。
2章：実施例としてシステム構成を定義し、各ユースケースにおける保護すべき資産をリストアップ。

指針13 る機能を設ける

4.2.2

製品企画フェーズ項番1,2:施策として安心安全を実現するための脅威の抽出について記載。
設計・製造フェーズ項番1,2,3,4,5:施策として抽出した脅威に対する対策について記載。
設計・製造フェーズ項番3:施策として相手との通信に使用するプロトコルについて記
載。

4.2.3

評価フェーズ1:施策として設計に問題がな
いかを確認する評価について記載。

4.2.2

設計・製造フェーズ項番2:自装置の状態を記録するためのロギング機能について記
載。

4.2.2

設計・製造フェーズ項番2:施策としてプログラムアップデート機能実装について記
載。

4.2.4

運用フェーズ項番1:施策としてプログラムのアップデートに関して記載。

4.2.4

運用フェーズ項番1,2:施策として最新の脆弱性への対応と、組織の対応内容につい
て記載。

4.2.4

運用フェーズ項番1,2:施策として出荷後組織がとるべき体制について記載。

4.2.５

廃棄フェーズ項番1:施策として廃棄時のリスク表示について記載。

4.2.2

設計・製造フェーズ項番2:施策として取扱説明書へのリスク、脅威の表示について記載。

機能及び用途に応じて適切にネットワーク

要点14 接続する

要点15 初期設定に留意する
要点16 認証機能を導入する

保守

出荷・リリース後も安全安心な状態を維持

時間が経っても安全安心を維持する機能

要点17 する

指針14 を設ける

出荷後もIoTリスクを把握し、情報発信す指針15 る
出荷・リリース後もIoTリスクを把握し、関出荷後の関係事業者に守ってもらいたい

要点18 係者に守ってもらいたいことを伝える
2.5 運用保守

指針16 ことをy伝える
運用

つながることによるリスクを一般利用者に要点19 知ってもらう

つながることによるリスクを一般利用者に指針17 知ってもらう

IoTシステム・サービスにおける関係者の要点20 役割を認識する

脆弱な機器を把握し、適切に注意喚起を要点21 行う

Copyright 2017 Connected Consumer Device Security Council Proprietary35

7．まとめ7-1. 総括
市場では次々と新たな攻撃手法が考案され、IoT によりつながる世界は日々脅威にさらされている。
最近では 2016 年 9 月に確認された Mirai あるいは Bashlight というマルウェアの存在は、史上最大規模の DDoS 攻撃の脅威により、大きな話題となった。同時にこの脅威により、インターネット上には工場出荷時のままの（あるいは推測が容易な）ID/Password で放置されている IoT デバイスが無数にあり、対策が急務であることを知らしめる結果となった（一説には Bashlight は 100 万台もの IoT デバイ
スをスレーブ化しているとも言われている）。
今回作成したガイドラインは、こうした状況の中で、高価な評価検証ツールや特別な知識がなくとも、必要なセキュリティ評価検証を実施できることを前提に作成している。分野によっては評価検証の充分条件に満たない可能性もあり、また現時点で確認されている脅威及び評価検証手法に基づいて記載しているため、今後の技術革新によっては新たな脅威が生じ、今後も情報を更新する必要性があると考えている。次版を更新する機会があれば、IoT のより広い分野において利用可能なように、最新情報の収集を行い、更新を行っていきたい。

Copyright 2017 Connected Consumer Device Security Council Proprietary36

Appendix1

Appendix1

セキュリティ検証ツール一覧

セキュリティ検証ツール一覧

Copyright 2017 Connected Consumer Device Security Council Proprietary37

Appendix1
表 A1-1.

セキュリティ検証ツール一覧

主要な静的脆弱性検証ツール一覧
検査対象

ツール名

NO

提供元

特徴

URL

日本語

有償/無償

認証と

クロスサ

インジェ

セッショ

イトスク

クション

ン管理の

リプティ

不備

ング

オブジェ

セキュリ

クト直接

ティ設定

参照

のミス

機能レベ
機密デー

ルアクセ

タの露出

ス制御の
⽋落

クロスサ

既知の脆

未検証の

イトリク

弱性を持

リダイレ

エスト

つコン

クトと

フォー

ポーネン

フォワー

ジェリ

トの利⽤

ド

C言語のみ対象とした無償の脆弱性検査ツール※注意︓2017年6⽉13日、クロスサイト・スク
1

iCodeChecker

IPA

リプティングの脆弱性のため、提供・サポート
https://www.ipa.go.jp/secur
ity/vuln/iCodeChecker/ind を停止
ex.html
VMイメージ、パッケージ形式、ソースコード形

○

無償

△

×

×

△

×

×

△

×

×

△

×

無償

○

×

○

△

×

△

△

×

×

×

式が利⽤可能ウェブアプリケーションとして動作、⼊⼒され

2

RIPS

Johannes
Dahse

http://ripsscanner.sourceforge.net/

3

LAPSE+OWASP

https://www.owasp.org/ind Eclipseプラグインで動作、JAVAのソースコード
ex.php/OWASP_LAPSE_Proj
に対して脆弱性解析が可能
ect

○

無償

○

×

○

△

×

△

△

×

×

×

4

Fortify SCA

Hewlett
Packard多くの開発環境、言語、プラットフォーム、おhttp://www8.hp.com/jp/ja/
software-solutions/static- よびフレームワークをサポートし幅広い脆弱性
code-analysis-sast/
検査が可能

○

有償

○

○

○

○

○

○

○

○

△

○

5

CxSASTOWASPトップ10、SANS 25、PCI DSS、HIPAA、https://www.checkmarx.co
MISRA、マイターCWE、FISMA、BSIMMの多く
Checkmarx m/technology/staticcode-analysis-sca/の脆弱性解析に対応

×

有償

○

○

○

○

○

○

○

○

○

○

6

Coverity

Synopsys

http://www.coverity.com/h 誤検知率が非常に低く、様々な脆弱性解析が可tml_ja/security/
能

○

有償

○

○

○

○

○

○

○

○

×

○

7

Klocwork

Rogue
Wave

http://www.roguewave.jp/p チーム開発における様々なワークフローにシー
roducts-services/klocwork ムレスに統合し、開発中のソースをリアルタイ

○

有償

○

○

○

○

○

○

×

×

×

○

○

有償

○

×

○

○

×

×

×

×

×

○

たPHPソースコードを解析が可能

静的コード解析のみではなく、統合開発環境 やムに解析が可能
テストケースを自動生成し、アプリケーション
8

Jtest

parasoft

https://www.parasoft.com/
product/jtest/の単体テストを自動実⾏
セキュリティのみではなく一般的なバグとなる
コードも検知が可能

9

C++testparasoft10

dotTEST

parasoft

https://www.parasoft.com/ 上記JtestのC/C++版
product/cpptest/
https://www.parasoft.com/ 上記Jtestの.net版
product/dottest/

○

有償

○

×

○

○

×

×

×

×

×

○

○

有償

○

×

○

○

×

×

×

×

×

○

Copyright 2017 Connected Consumer Device Security Council Proprietary38

Appendix1
表 A1-2.

主要な脆弱性スキャンツール一覧

セキュリティ検証ツール一覧※印は CCDS の検証ツールにパッケージされているもの
検査対象

NO

1

ツール名

提供元

特徴

URL

Owasp ZAP※

OwaspProject https://www.owasp.org/inde WEBアプリケーションの脆弱性を診断するため※CCDS-HNW x.php/OWASP_Zed_Attack_Prのオープンソースのテストツール
oxy_Project
評価ツール

w3af※

w3af.org※CCDS-汎用
http://w3af.org/
脆弱性検証ツー
ル

日本語

有償/無償

認証と

クロスサ

インジェ

セッショ

イトスク

クション

ン管理の

リプティ

不備

ング

オブジェ

セキュリ

クト直接

ティ設定

参照

のミス

機能レベ
機密デー

ルアクセ

タの露出

ス制御の
⽋落

クロスサ

既知の脆

未検証の

イトリク

弱性を持

リダイレ

エスト

つコン

クトと

フォー

ポーネン

フォワー

ジェリ

トの利⽤

ド

○

無償

○

○

○

○

○

○

○

○

○

○

×

無償

○

○

○

○

○

○

○

○

○

○

○

無償

○

○

×

△

○

×

×

×

○

×

Webアプリケーションの攻撃および監査フレー
2

ムワーク、SQLインジェクションのチェックやク
ロスサイトスクリプティング（XSS）、ローカル/リモートファイルインクルージョンなどを含めた130以上のプラグインで実⾏可能

3

OpenVAS※

Greenbone
Networks
http://www.openvas.org/
GmbH※CCDS-HNW
評価ツール

4

NessusTenalble
network
security

ネットワーク経由でターゲットの脆弱性を収
http://www.tenable.com/pro
ducts/nessus-vulnerability- 集、レポートすることができる世界で最も使⽤
scanner
されている脆弱性スキャナ

○

有償

○

○

×

△

○

×

×

×

○

×

5

NexposeRapid737,000種類以上の脆弱性定義と100,500以上のス
https://www.rapid7.com/jp/ キャンパターンやPCI DSSのセキュリティ基準を
products/nexpose/
順守しているか確認できる脆弱性スキャナ

○

有償

○

○

×

△

○

×

×

×

○

×

6

WebInspectHP

http://www8.hp.com/jp/ja/s
業界最多クラスの脆弱性情報を保有するWebア
oftwaresolutions/webinspectプリケーション脆弱性診断ツール
dynamic-analysis-dast/

○

有償

○

○

○

○

○

○

○

○

○

○

7

Vulnerability
Explorer

Ubsecure

http://www.ubsecure.jp/vex 純国産のWebアプリケーション脆弱性テスト/vex.html
ツール

○

有償

○

○

○

○

○

○

○

○

○

○

8

AppScanIBM

http://wwwWebアプリケーションに潜む脆弱性を検査する
03.ibm.com/software/produ
ツール
cts/ja/appscan

○

有償

○

○

○

○

○

○

○

○

○

○

Nessusから派生したオープンソースの脆弱性ス
キャナ

Copyright 2017 Connected Consumer Device Security Council Proprietary39

Appendix1
表 A1-3.

主要なペネトレーションツール一覧
ツール名

NO

1

LOIC※
（Low Orbit Ion
Canon）

提供元
オープンソース※CCDS-汎⽤脆弱性
検証ツール
オープンソース

2

aircrack-ng※※CCDS-汎⽤脆弱性
検証ツール

3

4

5

セキュリティ検証ツール一覧

Medusa※（Medusa Parallel
Network Login
Auditor）
Hydra※（THC Hydra）

Paros※（Paros proxy）

オープンソース※CCDS-汎⽤脆弱性
検証ツール
オープンソース※CCDS-汎⽤脆弱性
検証ツール
オープンソース※CCDS-汎⽤脆弱性検証ツール※印は CCDS の検証ツールにパッケージされているもの
日本語

有償/無償

http://sourceforge.net 負荷試験ツール。IRCを使ったDDoS攻撃のシミュレーションが可能。
/projects/loic/

×

無償

http://www.aircrack- WiFiのパスワード解析ツールで、WEP and
ng.org/×

無償

http://foofus.net/goon パスワード解析ツールで、
s/jmk/medusa/medus HTTP,POP,SSH,RDP等多くのプロトコルに対応。
a.html×

無償

http://www.thc.org/th パスワード解析ツールで、HTTP,POP,FTP等
多くのプロトコルに対応。
c-hydra/×

無償

http://sourceforge.net Proxyを通過した内容を書き換えて、データ送信が可能なツール。
/projects/paros/

×

無償

×

無償

×

無償

×

無償

○

無償

×

無償

×

無償

×

無償

×

無償

○

有償/無償

WPA PSK (WPA 1 and 2)に対応。

オープンソース
6

Ostinate※※CCDS-HNW評価

http://ostinato.org/

ツール
オープンソース
7

Gatling※※CCDS-HNW評価

特徴

URL

http://gatling.io/

ツール

Wiresharkでキャプチャしたパケットを編集し、その編集したパケットを送信できる
負荷試験ツールで、実施結果をレポート出⼒可能。

オープンソース8

hydra※

ftp, ssh, http, imap, pop3などなど、多くのプ※CCDS-汎⽤脆弱性 https://www.thc.org/thc- ロトコルをサポートし総当たり法でログオ
hydra/
検証ツール
ン侵⼊テストが可能

9Kali Linux

Offensive Security

https://www.kali.org/

様々機能を搭載したペネトレーションテス
ト向けのLinuxディストリビューション
SQLインジェクションの脆弱性を利⽤し、10オープンソース

sqlmaphttp://sqlmap.org/

データベース・サーバーの引き継ぐのプロ
セスを自動化するオープンソースの侵⼊テ
ストツール

11

Social Engineer
Toolkit

オープンソース

ソーシャルエンジニアリングのために設計
https://www.trustedsec.co されたオープンソースの侵⼊テストのフ
m/social-engineer-toolkit/
レームワーク

12

BeEF

オープンソース

http://beefproject.com/

13

Dradis Framework

オープンソース

Webアプリケーションとして動作し、他のhttp://dradisframework.org ツールと豊富なプラグインで連携を⾏い侵/⼊テストが⾏える

Rapid7https://www.rapid7.com/jp てマシンの制御とネットワークの乗っ取/products/metasploit/
り、検出事項を含むレポートの自動生成がWebブラウザに焦点を当てた侵⼊テスト
ツール

豊富なエクスプロイトライブラリを使⽤し
14

Metasploit

⾏える

15

Penetrator

Bluestar Corporation

700以上の実際のエクスプロイトを起動しhttp://penetrator.blue.co.jp て、Windows、Unix，ルータやファイアウ/portable.html
オール等の診断が可能

×

有償

16

core impact

Core Security SDI
Corporation

ネットワーク、Web、およびモバイルアク
https://www.coresecurity. ロスマルチベクトルテスト機能および豊富
com/core-impact
な脆弱性のエクスプロイトが⾏える×

有償

Copyright 2017 Connected Consumer Device Security Council Proprietary40

Appendix1
表 A1-4.

主要なファジングツール一覧

セキュリティ検証ツール一覧※印は CCDS の検証ツールにパッケージされているもの
検査手段

NO

ツール名

提供元

URL

特徴

日本語

有償/無償

ネット
ワーク

オープンソース
1※CCDS-HNW

Sulley※

評価ツール

ファイル

プログラ
ム

ファジングデータを条件に応じて自動生成可
https://github.com/O 能。
penRCE/sulley/tree/
別途作成した通信プロトコルのシナリオファイ
master/sulley
ルに挿⼊し、ファジングが可能。

×

無償

○

×

×

2

Taof

ネットワークの上のデータをキャプチャし改変
オープンソース https://sourceforge.n
et/projects/taof/
したデータを送信したファジングが可能

×

無償

○

×

×

3

ISIC

ネットワーク機器・ソフトウェアに対してのパ
オープンソース http://isic.sourceforg
e.net/
ケットファジングが可能

×

無償

○

×

×

4

american fuzzylopプログラム内の条件を網羅的にファジングが可
オープンソース http://lcamtuf.coredu
mp.cx/afl/
能

×

無償

×

×

○

5

radamsa

有効なデータファイルからファズを生成、スク
オープンソース https://github.com/aoh/radamsa
リプト化し自動的に実⾏が可能

×

無償

○

○

○

6

ProxyFuzz

https://www.secforce TCPおよびUDPプロトコルに対してのファジン
オープンソース .com/media/tools/pro
グが可能
xyfuzz.py.txt

×

無償

○

×

×

7

Basic Fuzzing
Frameworkhttps://www.cert.org/
ファイルを読み込むアプリケーションに対してCarnegie Mellon vulnerabilityanalysis/tools/bff.cfm ファジングが可能
University
?

×

無償

×

○

×

8

Peach
Community
Edition v3

Peach Fuzzer

ファイルを読み込む画像ソフト、TCP/IP などで
http://www.peachfuzz 通信するソフトやウェブアプリケーションなど
er.com/resources/pe
幅広いソフトウェア製品に対してファジングがachcommunity/
可能

×

無償

○

○

○

9

iFuzzMaker

IPA

http://www.ipa.go.jp/s JPEG画像を読み込む機能を持つ製品に対する
ecurity/vuln/iFuzzMa
ファジングが可能
ker/

○

無償

×

○

×

10

SDL Regex
FuzzerMicrosoft

https://www.microsof
正規表現ファジングデータでのDoS攻撃ファジ
t.com/enus/download/details.a ングが可能
spx?id=20095

×

無償

×

×

○

11

SDL MiniFuzz
File Fuzzer

Microsoft

https://www.microsof
実⾏形式のアプリケーションに対してファイル
t.com/enus/download/details.a によるファジングが可能
spx?id=21769

×

無償

×

○

×

12

beSTORM

任意のネットワーク・ソフトウェアを対象に
http://www.beyondse
Beyond Security curity.com/bestorm.ht ファジングを⾏い包括的なセキュリティ分析が
ml
可能

×

有償

○

○

○

13

Defensics

100種類以上のプロトコルやファイルフォー
http://www.codenomi
CODENOMICON con.com/jp/products マットをサポートしたファズテストプラット/defensics/
フォーム

×

有償

○

○

○

14

FFR Raven

FFRI

○

有償

○

○

○

http://www.ffri.jp/pro ネットワーク組み込み機器の脆弱性のファジン
ducts/raven/
グが可能

Copyright 2017 Connected Consumer Device Security Council Proprietary41

Appendix2

Appendix2

評価検証計画書の実例集

評価検証計画書の実例集

Copyright 2017 Connected Consumer Device Security Council Proprietary42

Appendix2

評価検証計画書の実例集

Copyright 2017 Connected Consumer Device Security Council Proprietary43

評価検証計画書の実例集

Appendix2④前提及び制約条件※技適やWiFi/Bluetoothの認証マーク等、評価検証を実施する上で 、事前にクリア しておくべき基準があれば、記載して おくこと。
※機密情報管理に対する方針や、検証仕様に関するレビューな ど顧客と合意して おくべき条件があれば、記載しておくこと。

■実網許可及び、評価検証実施環境について－対象となるDUTについては、技適マークの認証は完了した状態で貸与を受け、実網接続には問題ない状態であることを確認する。
－誤って、テスト対象機器以外に、不正な信号（エクスプロイトデータやDoS信号等）を送信してしまう事を防ぐため、可能な限り、実網での接続を避け、電波暗室内に試験環境を構築し、評価検証を実施すること。
■機密情報管理について－顧客から提供を受けた各種設計ドキュメントについては、当社の情報管理規定（l顧客提出済み）に則り、機密保持を徹底すること。
－期間中は、本プロジェクトに関係するスタッフ以外の立ち入りができないよう、クリーンルームにより業務を行う。
－検出されたインシデント情報については、CCDS検証基盤システムを用いて、顧客と情報交換を行う。
検証基盤システムからダウンロードしたインシデント情報については、メール添付を含め、社内外への情報送信を禁止するものとする。
■評価検証仕様書の合意について－評価検証実施内容については、作成した評価検証仕様書の内容を顧客側に説明し、合意の上で実施するものとする。
⑤利害関係者※品質部門や、顧客以外の企業担当者（顧客にとって の発注元）等、評価検証情報を共有すべき関係者については、記載を行うこと

業態
IoT機器開発メーカ
IoT機器開発メーカ
IoT機器開発メーカ

役割名プロジェクトリーダー
開発担当者
品質部門担当者
開発担当者
ソフトウェア開発業者
評価/評価検証事業者 テストリーダー
評価/評価検証事業者 テストエンジニア
評価/評価検証事業者 テストエンジニア

2)評価検証コミュニケーション

氏名

会社名
ABC株式会社
ABC株式会社
ABC株式会社
株式会社DEF株式会社CCDS
株式会社CCDS
株式会社CCDS

E-Mail
役割内容
tanaka@abc.co.jp
開発プロジェクト統括
yamada@abc.co.jp
対象IoT機器の開発担当
kawatani@abc.co.jp 対象IoT機器の品質担当
shimoyama@def.co.jp ソフトウェアの開発担当
sato@ccds.co.jp
評価検証のとりまとめ
watanabe@ccds.co.jp 評価検証の設計を担当
suzuki@ccds.co.jp
評価検証の実行を担当

田中 一郎
山田 次郎
川田 六郎
下山 七郎
佐藤 三郎
渡辺 四朗
鈴木 五郎

※プロジェクトの体制を貼付

・当該プロジェクトについては、下記の体制にて実施し、コミュニケーションを行うものとする。
【評価検証事業者（当社）】株式会社CCDS【車載端末メーカ（顧客）】ABC株式会社
・開発資料
・設計ドキュメント

管理者（テストリーダー）
佐藤 三郎

プロジェクトリーダー
田中 一郎

・進捗報告
・問題報告
・顧客レビュー

開発者
山田 次郎

体制図を挿入
・進捗報告
・問題報告

・業務指示

テストエンジニア（テスト設計）
渡辺 四朗

・業務指示

・レクチャー・仕様問題対応・不明点確認

・進捗報告
・問題報告

テストエンジニア（テスト実行）鈴木 五郎※適宜情報共有【ソフトウェア開発企業】
株式会社EDF
開発者
下山 七郎

Copyright 2017 Connected Consumer Device Security Council Proprietary44

評価検証計画書の実例集

Appendix2
3)リスク一覧表①プロジェクト推進に関するリスク
A)想定されるリスクの抽出
区分

評価検証実行による対象
機器への影響非常に小さい

小さい

普通

大きい

非常に大きい

1

2

3

4

5

-

メインユースケース
受け入れ時の製品品質以外の機能に軽微（不具合検出等）
な影響あり

DUT接続時の調査、準備

-

-

-

メインユースケース
以外の機能に影響あり

メインユースケースの機能に軽微影響

評価検証実行が原 評価検証実行が原因で、因で、仕様動作と異 メインユースケースの機能なる挙動が確認され に重大な影響が確認された場合た場合
メインユースケースの機能に影響あり

メインユースケースの機能に重大な影響あり

当初計画と比較し、 当初計画と比較し、評価検証ツールを 評価検証ツールを 想定していたツールがDUTに接続する際の DUTに接続する際の DUTと接続できず、工数
調査、準備に軽微な 調査、準備に大幅な 計画に抜本的な見直しが工数超過が発生す 工数超過が発生す 必要となる
る
る-

評価検証実行にス 評価検証実行にス
評価検証仕様策定 調達を予定していた人員キル不足により、当 キル不足により、当において、不備があ の確保ができず、プロジェ
初見積もりと比較し、 初見積もりと比較し、り、リカバリに多大な クト全体の計画、期間に軽微な期間超過が 大幅な期間超過が期間を要する
重大な影響がある
発生する
発生する

評価検証実行時のスキル
不足
（調達）

-

機材・環境

テスト機材・環境の準備/調達が遅延（1日以内）

テスト機材・環境の準備/調達が遅延（2～3日以内）

テスト機材・環境の準備/調達が遅延（4～5日以内）

テスト機材・環境の準備/調達が遅延（1Week以上）

テスト機材・環境の調達が困難

非常にまれに起こる

まれに起こる普通

起こる可能性がある

ほぼ確実に起こる

1

2

3

4

5

非常に小さい
1

小さい
2

普通
3

大きい
4

非常に大きい5B)リスク値の算出基準
B-1)発生率基準
区分B-2)影響度算出基準
区分
コスト

コスト増は軽微

コスト増10％

コスト増10-20％

コスト増20-40％

コスト増40％

タイム

期間延長は軽微

期間延長5％未満

期間延長5-10％

期間延長10-20%

期間延長20％A）影響度（ I ） ②発生確率（P）③リスク値（R＝I×P）

リスク対策

C)想定されるリスクを踏まえたリスク値の算出及び、リスク対策
項目名

リスク
コスト

-

-

-

タイム

2

4

8

コスト

-

-

-

タイム

2

2

4

コスト

3

3

9

タイム

-

-

-

コスト

-

-

-

タイム

3

2

6

コスト

-

-

-

タイム

1

1

1

評価検証実行による対象
機器への影響受け入れ時の製品品質（不具合検出等）

DUT接続時の調査、準備

評価検証実行時のリスク
不足
（調達）

機材・環境

・ファジングやペネトレーション等を実施する際は、日程含め、顧客への事
前合意を得る。
・評価検証の実施順を考慮し、DUTに影響が想定される項目について
は、最後に実施する形とする。
・代替用の試験端末を用意いただ
く。
事前に顧客より、システムテスト結果を受領予定。

・過去の調査結果をもとにトレーニングを実施しておき、準備工程を円滑に進められるよう配慮する。
・候補ツールを複数選定しておく。

セキュリティ評価検証において実績のあるスタッフをアサイン可能。人材採用の目途がある。

調達依頼済みCopyright 2017 Connected Consumer Device Security Council Proprietary45

Appendix2

評価検証計画書の実例集

4)評価検証戦略①評価検証サブプロセス
本プロジェクトにおける評価検証は、以下のサブプロセスに分けて進めるものとする。
１．評価検証の方針/仕様（手順書）の策定
・システムテストの設計を行うサブプロセスであり、セキュリティ評価検証手順ガイドラインに沿って、評価検証仕様書、手順書（結果表）の策定を行う。
２．評価検証環境の構築
・評価検証環境の構築を行うサブプロセスであり。本プロジェクトでは、電波暗室内にネットワーク及び、
評価検証環境の構築が準備作業として必要となる。
３．評価検証の実行・策定した仕様書、手順書に沿って、評価検証作業の実行を行う。問題点や不具合を認識した場合には、別途インシデントレポートを起票する。
②成果物
・下記の成果物を納品するものとする。
※仕様書/手順書については、実行開始前に顧客レビューを行うものとする。
－セキュリティ評価検証仕様書/手順書（※）－セキュリティ評価検証結果表－脅威（セキュリティインシデント）レポート報告書－セキュリティ品質報告書③評価検証設計技法
・セキュリティ評価検証手順ガイドラインに沿って、リスク分析から評価検証手法（ツール）の選定を行う。

④完了基準
・起票したインシデントは全てクローズとなり、評価検証項目の保留、NG項目がゼロとなった時点で評価完了とする。

⑤収集するメトリクス
・本プロジェクトでは、以下のメトリクスを収集する。
－各サブプロセス毎の工数：今後の見積もり精度の向上のため。
－評価検証計画に対する予実：今後の進捗管理に活用するため。
－発生インシデント数及び内容：今後の評価検証使用にフィードバックさせるため。
⑥必要となるデータやドキュメント
・評価検証要件の策定にあたり、下記のドキュメントは顧客より提供される。
－無線アクセスポイントの操作マニュアル－要求仕様書－設計ドキュメント
⑦必要となる環境
・本プロジェクトで必要となる環境は、以下となる。
[ハードウェア]－評価検証ツール使用時（特にペネトレーションツール利用時）は電波暗室を用いる。
－試験対象（DUT）となるWiFi無線アクセスポイント端末－オンラインシステムにアクセス可能なインターネット環境－評価検証作業用PC[ソフトウェア]－評価検証仕様策定時に選定した各種セキュリティ評価検証ツール⑧評価検証の再実施及び回帰テスト
・起票したインシデントの改修（対応）後、問題の解消を確認し、関連する評価検証項目対して、回帰テストを実施する。

Copyright 2017 Connected Consumer Device Security Council Proprietary46

Appendix2

評価検証計画書の実例集⑨中断及び、再開基準
・万一、ブロッキングとなる不具合が見つかり、評価検証の継続が困難な場合には、顧客と調整の上、評価検証を中断し、該当不具合の改修が確認された時点で再開するものとする。
⑩「組織的評価検証戦略」からの逸脱事項
・本プロジェクトはセキュリティ評価検証の実施のみを前提としており、単体テスト、結合テスト、システムテスト、ユー
ザビリティテストは、評価の対象から除外するものとする。

5)評価検証活動の役割分担、要求スキルレベル及び工数見積り
・本プロジェクトの業務内容と要求スキルレベル、想定工数は、以下となる
プロセス

役割

工数（人日）

業務内容・要求スキルレベル【業務内容】
評価検証の統括、業務指示、顧客への進捗報告、問題報告

評価検証管理テストリーダー

45.0 【要求スキルレベル】
・評価検証のマネージメント経験3年以上・セキュリティ評価検証の実務経験5件以上【業務内容】
評価検証計画の策定、計画に対する顧客との調整

評価検証計画

テストリーダー

5.0 【要求スキルレベル】
・評価検証のマネージメント経験3年以上・セキュリティ評価検証の実務経験5件以上【業務内容】
セキュリティ評価検証仕様書、手順書の作成

評価検証設計テストエンジニア

10.0 【要求スキルレベル】
・開発エンジニアとしての経験3年以上・セキュリティ評価検証の実務経験1件以上

環境構築【業務内容】
電波暗室内のネットワーク、試験環境の構築、試験対象とな
10.0 るIoT機器（DUT）の貸与

開発担当者

評価検証実行

テストエンジニア

セキュリティ品質報告

テストリーダー【要求スキルレベル】－【業務内容】
評価検証作業の実行、問題点やインシデント報告レポートの作成
30.0 【要求スキルレベル】
・開発エンジニアとしての経験3年以上・セキュリティ評価検証の実務経験1件以上【業務内容】
評価検証完了時点でセキュリティ品質報告書を作成、顧客へ報告

5.0【要求スキルレベル】
・評価検証のマネージメント経験3年以上・セキュリティ評価検証の実務経験5件以上

6)人材①役割、活動、責任業態
車載端末メーカ
車載端末メーカ
評価検証事業者
評価検証事業者
評価検証事業者
評価検証事業者

役割名
プロジェクトリーダー
開発担当者
テストリーダーテストエンジニア
テストエンジニア
テストエンジニア

会社名
ABC株式会社
ABC株式会社
株式会社CCDS
株式会社CCDS
株式会社CCDS
株式会社CCDS

氏名
田中 一郎
山田 次郎
佐藤 三郎
渡辺 四朗
鈴木 五郎
※新規雇用を予定

E-Mail

役割内容

tanaka@abc.co.jp
開発プロジェクト統括
yamada@abc.co.jp
IoT端末の開発担当
sato@ccds.co.jp
評価検証のとりまとめ
watanabe@ccds.co.jp 評価検証の設計を担当
suzuki@ccds.co.jp
評価検証の実行を担当
評価検証の実行を担当

Copyright 2017 Connected Consumer Device Security Council Proprietary47

評価検証計画書の実例集

Appendix2②雇用の必要性・評価検証実行を担当する評価検証エンジニアを1名新規採用にて、雇用する。
【採用する人材のスキル要件】－開発業務において3年以上の経験があり、設計ドキュメントの読解に問題がないこと－JAVAによるコーディングの経験が1年以上あり、ソースコードからプログラム内容を理解できること－単体、結合、システムテストのいずれかを実施した実務経験が5件以上あること③教育の必要性・インシデントの妥当性については、顧客側の開発担当者と協議の上、深刻度及び登録内容を調整する。
・評価検証仕様書及び手順書の内容については、設計担当のテストエンジニアよりレクチャーを行う。
7)スケジュール
・本プロジェクトのスケジュールは以下の沿って進めるものとする。
Week1
マイルストン

Week2▼X/XX：計画レビュー▼X/XX：設計レビュー

Week3

Week4

▼X/XX：検証完了▼X/XX：セキュリティ品質報告提出

評価検証計画
評価検証設計環境構築
評価検証実行
改修期間
セキュリティ
品質報告

Copyright 2017 Connected Consumer Device Security Council Proprietary48

Appendix3

Appendix3

評価検証仕様書の実例集

評価検証仕様書の実例集

Copyright 2017 Connected Consumer Device Security Council Proprietary49

Appendix3

評価検証仕様書の実例集

・以下に参考資料として、本事業で実施したスマートホームテストベッドの実環境に対する評価検証仕様書を実例として記載する。

Copyright 2017 Connected Consumer Device Security Council Proprietary50

Appendix3

評価検証仕様書の実例集

3 脅威対策及び検証手法

前項でスマートホームの接続構成を整理し、想定される脅威を検討している。その検討した脅威に対する対策と検証手法についてまとめる。
脅威発生個所

IoT-GW(ホームルータ)

検証⽤ルータWiFi/有線LAN

対策候補
保護すべき資産

設定情報

検証手段

他のガイドラインとの関係

脅威名

対策名

不正アクセス

脆弱性対策

OTA5

ネットワーク脆弱性検査

Open VAS

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

aircrack-ng(通信解析・ブルートフォース

Hydra

セキュリティ情報
・ログインパスワード

OTA

検証手法

OWASP

・SSIDキー

検証ツール

攻撃対策)
FW機能

OWASP3

脆弱性検査

Open VAS

DoS攻撃

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling

盗聴・改ざん

通信路暗号化

OTA1

脆弱性検査

Open VAS

不正アクセス

脆弱性対策

OTA5

Webアプリ脆弱性検査

Open VAS

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Hydra(DoS攻撃対策)
HNWにつながる
機器

HEMS

設定情報

本体機器

セキュリティ情報

コントローラ・ログインパスワード(ブルートフォース攻撃対策)

無線アダプタTV

FW機能

OWASP3

脆弱性検査

Open VAS

DoS攻撃

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling

盗聴・改ざん

通信路暗号化OTA1

ウィルス感染

脆弱性対策

OTA4,OTA5(DoS攻撃対策)

ソフトウェア署名OTA6
セキュア開発

OTA7

脆弱性対策

OTA5

OWASP8OWASP9

ネットワーク脆弱性検査

Open VAS

WEBアプリ脆弱性検査

OWASP ZAP

ネットワーク脆弱性検査

Open VAS

ネットワーク脆弱性検査

Open VAS

設計ドキュメント確認－

ソースコード確認
BDレコーダ

設定情報

不正アクセス

セキュリティ情報
・ログインパスワード

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

機器本体

WEBアプリ脆弱性検査

OWASP ZAP

ネットワーク脆弱性検査

Open VAS

ペネトレーション

Hydra(ブルートフォース攻撃対策)
FW機能

OWASP3

脆弱性検査

Open VAS

DoS攻撃

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling

不正利⽤

ユーザ認証

(DoS攻撃対策)
OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Hydra(ブルートフォース攻撃対策)
スマート照明機器本体

不正アクセス

脆弱性対策
ユーザ認証

OTA5
OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

WEBアプリ脆弱性検査

OWASP ZAP

ネットワーク脆弱性検査

Open VAS

ペネトレーション

Hydra(ブルートフォース攻撃対策)
DoS攻撃

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)
不正利⽤

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Hydra(ブルートフォース攻撃対策)
ネットワークカメラ

映像情報

不正アクセス

脆弱性対策

OTA5

機器本体
ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

WEBアプリ脆弱性検査

OWASP ZAP

ネットワーク脆弱性検査

Open VAS

ペネトレーション

Hydra(ブルートフォース攻撃対策)
DoS攻撃

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)
盗聴・改ざんOTA1OWASP8
脆弱性検査
Copyright
2017 通信路暗号化
Connected
Consumer Device
Security Council
Proprietary

OWASP ZAP

51

Appendix3

評価検証仕様書の実例集

3 脅威対策及び検証手法

前項でスマートホームの接続構成を整理し、想定される脅威を検討している。その検討した脅威に対する対策と検証手法についてまとめる。
脅威発生個所
IoT-GW(ホームルータ)

検証⽤ルータWiFi/有線LAN

対策候補
保護すべき資産

設定情報

検証手段

他のガイドラインとの関係

脅威名

対策名

不正アクセス

脆弱性対策

OTA5

ネットワーク脆弱性検査

Open VAS（CCDS）

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

aircrack-ng（CCDS）(通信解析・ブルートフォース

Hydra（CCDS）

セキュリティ情報
・ログインパスワード

OTA

OWASP

・SSIDキー

機器

HEMS

検証ツール

攻撃対策)
DoS攻撃

HNWにつながる

検証手法

設定情報

本体機器

セキュリティ情報

コントローラ・ログインパスワードOWASP3

脆弱性検査

Open VAS（CCDS）

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

盗聴・改ざん

通信路暗号化

OTA1

脆弱性検査

Open VAS（CCDS）

不正アクセス

脆弱性対策

OTA5

Webアプリ脆弱性検査

Open VAS（CCDS）

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)

無線アダプタ
TV

FW機能

DoS攻撃

FW機能

OWASP3

脆弱性検査

Open VAS（CCDS）

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

WEBアプリ脆弱性検査

OWASP ZAP（CCDS）

盗聴・改ざん

通信路暗号化OTA1

ウィルス感染

脆弱性対策

OTA4,OTA5

ソフトウェア署名OTA6
セキュア開発OWASP8OWASP9

OTA7

ネットワーク脆弱性検査

Open VAS（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

設計ドキュメント確認－

ソースコード確認
BDレコーダ

設定情報

不正アクセス

脆弱性対策

OTA5

セキュリティ情報
・ログインパスワード

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

機器本体

WEBアプリ脆弱性検査

OWASP ZAP（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
DoS攻撃
不正利⽤

FW機能

OWASP3

脆弱性検査

Open VAS（CCDS）

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーション

Hydra（CCDS）

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8(ブルートフォース攻撃対策)
スマート照明機器本体

不正アクセス

脆弱性対策
ユーザ認証

OTA5
OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

WEBアプリ脆弱性検査

OWASP ZAP（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
DoS攻撃
不正利⽤

DoS対策
ユーザ認証

OWASP3
OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
ネットワークカメラ

映像情報

不正アクセス

脆弱性対策

OTA5

機器本体
ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

WEBアプリ脆弱性検査

OWASP ZAP（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
DoS攻撃
盗聴・改ざん

DoS対策
通信路暗号化OWASP3OTA1OWASP8ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

脆弱性検査

Copyright 2017 Connected Consumer Device Security Council Proprietary

Ostinate,Gatling（CCDS）

52

Appendix3
HNWにつながる

ネットワークリモコン

機器

制御情報

不正アクセス

脆弱性対策

評価検証仕様書の実例集

OTA5

WEBアプリ脆弱性検査

機器本体
ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8OWASP ZAP（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
FW機能

OWASP3

脆弱性検査

Open VAS（CCDS）

DoS攻撃

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

不正利⽤

ユーザ認証

ペネトレーション

Hydra（CCDS）

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8(ブルートフォース攻撃対策)
温湿度センサー

計測情報

盗聴・改ざん

通信路暗号化不正アクセス

脆弱性対策

OTA1

OWASP8

機器本体
ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

脆弱性検査

OWASP ZAP（CCDS）

WEBアプリ脆弱性検査

OWASP ZAP（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
DoS攻撃
不正利⽤

DoS対策
ユーザ認証

OWASP3
OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
ロボット掃除機

機器本体

盗聴・改ざん

通信路暗号化

DoS攻撃

DoS対策

不正利⽤

ユーザ認証

OTA1

OWASP8脆弱性検査

OWASP ZAP（CCDS）

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーション

Hydra（CCDS）

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8(ブルートフォース攻撃対策)
スマートカーテン

機器本体

DoS攻撃
不正利⽤

DoS対策
ユーザ認証

OWASP3
OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
スマートコンセント

機器本体

DoS攻撃
不正利⽤

DoS対策
ユーザ認証

OWASP3
OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8

ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
タブレット端末

不正アクセス

設定情報

脆弱性対策

OTA5

WEBアプリ脆弱性検査

セキュリティ情報
・ログインパスワード

ユーザ認証

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8OWASP ZAP（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

ペネトレーション

Hydra（CCDS）(ブルートフォース攻撃対策)
FW機能

OWASP3

脆弱性検査

Open VAS

DoS攻撃

DoS対策

OWASP3ペネトレーション

Ostinate,Gatling(DoS攻撃対策)（CCDS）

不正利⽤

ユーザ認証

ペネトレーション

Hydra（CCDS）

OTA11,OTA12,OTA13,OTA14 OWASP2,OWASP8(ブルートフォース攻撃対策)
ウィルス感染

脆弱性対策

OTA4,OTA5

ソフトウェア署名OTA6
セキュア開発WEBアプリ脆弱性検査
OWASP9OTA7OWASP ZAP（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

設計ドキュメント確認－

ソースコード確認
人感センサー

検知情報

盗聴・改ざん

機器本体

なりすまし
DoS攻撃

通信路暗号化OTA1OWASP8

脆弱性検査※要調査
Bluetooth⽤ツール

DoS対策

OWASP3ペネトレーション※要調査(DoS攻撃対策)

Bluetooth⽤ツール

Copyright 2017 Connected Consumer Device Security Council Proprietary53

Appendix3

評価検証仕様書の実例集

4 検証の目標レベル

今回の検証における検証の目標レベルを定義
対策レベル
対象機器

保護すべき資産

Level1

想定脅威
検証内容

IoT-GW

検証⽤ルータ

設定情報

不正アクセス(ホームルータ)

WiFi/有線LAN

セキュリティ情報

DoS攻撃

・ログインパスワード

盗聴・改ざん・SSIDキーLevel2
利⽤ツール

ファジングテスト

Sulley（CCDS）←Level1で検証

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

ペネトレーションテスト1

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーションテスト1

Hydra（CCDS）(ブルートフォース攻撃対策)
HNWにつながる
機器

HEMS

設定情報

不正アクセス

本体機器

セキュリティ情報

DoS攻撃

コントローラ・ログインパスワード

盗聴・改ざん

無線アダプタウィルス感染TV

検証内容←Level1で検証

Level3
利⽤ツール(例)

Wireshark

OWASP ZAP（CCDS）(Zad Attach Proxy)

Hydra（CCDS）

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

Webアプリ脆弱性検査

OWASP ZAP（CCDS）

ペネトレーションテスト1

Ostinate,Gatling

Wireshark(Zad Attach Proxy)

aircrack-ng（CCDS）＊WiFi接続情報解読(暗号強度変更)←Level1で検証

リプレイ攻撃OWASP ZAP（CCDS） なりすまし(通信解析、ブルートフォース)
Sulley（CCDS）

利⽤ツール(例)←Level1で検証

ペネトレーションテスト2＊設定画面ログイン
ファジングテスト

検証内容←Level1で検証←Level2で検証←Level1で検証
Wireshark

リプレイ攻撃Wireshark

OWASP ZAP（CCDS） なりすましOWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証←Level1で検証(DoS攻撃対策)（CCDS）

ペネトレーションテスト1

Hydra（CCDS）←Level1で検証←Level1で検証

ファジングテスト

Sulley（CCDS）←Level1で検証←Level1で検証

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

Webアプリ脆弱性検査

OWASP ZAP（CCDS）

ペネトレーションテスト1

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ペネトレーションテスト1

Hydra（CCDS）(ブルートフォース攻撃対策)＊設定画面ログイン
BDレコーダ

設定情報

不正アクセス

セキュリティ情報

DoS攻撃

・ログインパスワード

不正利⽤

機器本体

←Level1で検証

Wireshark

リプレイ攻撃Wireshark

OWASP ZAP（CCDS） なりすましOWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証←Level1で検証←Level1で検証(ブルートフォース攻撃対策)＊設定画面ログイン
スマート照明機器本体

不正アクセス

ファジングテスト

Sulley（CCDS）←Level1で検証

DoS攻撃

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

不正利⽤

ネットワークカメラ

映像情報

不正アクセス

機器本体

DoS攻撃
盗聴

ペネトレーションテスト1

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ファジングテスト

Sulley（CCDS）←Level1で検証

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

ペネトレーションテスト1

Ostinate,Gatling(DoS攻撃対策)（CCDS）←Level1で検証←Level1で検証
Wireshark

リプレイ攻撃Wireshark

OWASP ZAP（CCDS） なりすましOWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証←Level1で検証

Wireshark

リプレイ攻撃Wireshark

OWASP ZAP（CCDS） なりすましOWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証

Copyright 2017 Connected Consumer Device Security Council Proprietary←Level1で検証

54Appendix3
HNWにつながる

ネットワークリモコン

機器

制御情報

不正アクセス

機器本体

DoS攻撃
不正利⽤
盗聴・改ざん

温湿度センサー

計測情報

不正アクセス

機器本体

DoS攻撃
不正利⽤

評価検証仕様書の実例集

ファジングテスト

Sulley（CCDS）←Level1で検証

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

Webアプリ脆弱性検査

OWASP ZAP（CCDS）

ペネトレーションテスト1

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ファジングテスト
ネットワーク脆弱性検査

機器本体

スマートカーテン

機器本体

スマートコンセント

機器本体

タブレット端末

Open VAS（CCDS）

通信の解析(DoS攻撃対策)（CCDS）

ファジングテスト

Sulley（CCDS）←Level1で検証

不正利⽤

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

Ostinate,Gatling(DoS攻撃対策)（CCDS）

ファジングテスト

Sulley（CCDS）←Level1で検証

不正利⽤

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析(DoS攻撃対策)（CCDS）

ファジングテスト

Sulley（CCDS）←Level1で検証

不正利⽤

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

Ostinate,Gatling(DoS攻撃対策)（CCDS）

不正アクセス

ファジングテスト

Sulley（CCDS）←Level1で検証

セキュリティ情報

DoS攻撃

ネットワーク脆弱性検査

Open VAS（CCDS）

通信の解析

・ログインパスワード

不正利⽤
Webアプリ脆弱性検査

OWASP ZAP（CCDS）

ペネトレーションテスト1

Ostinate,Gatling

OWASP ZAP（CCDS）(Zad Attach Proxy)←Level1で検証←Level1で検証
Wireshark

リプレイ攻撃OWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証←Level1で検証

Wireshark

リプレイ攻撃OWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証←Level1で検証

Wireshark

リプレイ攻撃OWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証←Level1で検証

Wireshark

リプレイ攻撃←Level1で検証※Bluetooth⽤ツール

通信の解析

Wireshark

OWASP ZAP（CCDS） なりすましOWASP ZAP（CCDS）(Zad Attach Proxy)(Zad Attach Proxy)←Level1で検証（CCDS）
Hydra（CCDS）

Wireshark

OWASP ZAP（CCDS） なりすまし←Level1で検証(DoS攻撃対策)

Wireshark

OWASP ZAP（CCDS） なりすまし←Level1で検証

ペネトレーションテスト1

Wireshark

OWASP ZAP（CCDS） なりすまし←Level1で検証

設定情報

Wireshark(Zad Attach Proxy)←Level1で検証

DoS攻撃

リプレイ攻撃OWASP ZAP（CCDS） なりすまし←Level1で検証

DoS攻撃

Ostinate,Gatling

Wireshark←Level1で検証

DoS攻撃

ウィルス感染(Zad Attach Proxy)←Level1で検証

Ostinate,Gatling

ペネトレーションテスト1

OWASP ZAP（CCDS）←Level1で検証

ペネトレーションテスト1

Wireshark(Zad Attach Proxy)

Sulley（CCDS）

OWASP ZAP（CCDS）

ペネトレーションテスト1

リプレイ攻撃OWASP ZAP（CCDS） なりすまし←Level1で検証

Webアプリ脆弱性検査

ペネトレーションテスト1

Wireshark←Level1で検証

盗聴・改ざん

ロボット掃除機←Level1で検証(ブルートフォース攻撃対策)＊設定画面ログイン
人感センサー

検知情報

盗聴・改ざんペネトレーションテスト1

機器本体

なりすまし

(不正ペアリング対策)

DoS攻撃

ペネトレーションテスト1※Buletooth⽤ツール

リプレイ攻撃※Bluetooth⽤ツール

なりすまし※Bluetooth⽤ツール←Level1で検証←Level1で検証(DoS攻撃対策)

Copyright 2017 Connected Consumer Device Security Council Proprietary55

Appendix3

評価検証仕様書の実例集

５．DUTのインタフェースと通信プロトコル調査（連携動作の分析）
DUTとなるIoT機器のユースシーン、インタフェースや通信プロトコル、連携動作に関する調査結果を以下にまとめる。
[省エネ]
No ユースシーン名トリガー(input)

機器と接続方式

制御(output)

機器と接続方式

1

人感センサー

人感センサー︓Bluetooth

照明

LED電球︓有線LAN 人感センサーアプリとLED電球が連携し照明を制御

エアコン(ネットワークリモ

ネットワークリモコ 人感センサーからIFTTTにEventIDを送付

コン)

ン︓WiFi

EventIDをキーにMakerChannelと連携しネットワークリモコンのAPIにコンセント

スマートコンセン

人感センサーからIFTTTにEventIDを送付

ト︓WiFi

EventIDをキーにスマートコンセントと連携しコンセントのスイッチを消し忘れ防止連携方法

EventID/キーワード/補足

EventID＝AbsenceInRoom

requestを投げる
EventID＝AbsenceInRoom

OFFする
2

無駄使い防止(空調)

外気温の温湿度センサー

温湿度センサー︓WiFi

エアコン(ネットワークリモ

ネットワークリモコ 温湿度センサーからIFTTT使ってMakerChannelと連携

外気温20℃以上になったときエアコンOFF

コン)

ン︓WiFi

外気温25℃以下になったときエアコンOFF

MakerChannelからネットワークリモコンのAPIにrequestを投げる

3

無駄使い防止(照明)時間

IFTTTのサーバー

照明

LED電球︓有線LAN 決まった時刻にIFTTTからLED電球に対し制御

午前10時

4

省エネ運転(通知)

電⼒使⽤量

HEMS︓有線LAN

メール

G-Mail

省エネ運転(検知・制御)

メール

Gmail

照明

LED電球︓有線LAN IFTTTがキーワードを含むメールを受けたことを検知しLED電球を制御

キーワード＝[HEMS]AttentionToPowerConsumption

エアコン(ネットワークリモ

ネットワークリモコ IFTTTがキーワードを含むメールを受けたことを検知しMakerChannel

キーワード＝[HEMS]AttentionToPowerConsumption

コン)

ン︓WiFiと連携してネットワークリモコンのAPIにrequestを投げる

コンセント

スマートコンセン

IFTTTがキーワードを含むメールを受けたことを検知しスマートコンセ

ト︓WiFi

ントを制御

HEMSを分析し電⼒が基準を超えた場合G-Mailを送付

キーワード＝[HEMS]AttentionToPowerConsumption[防犯]
No ユースシーン名トリガー(input)

機器と接続方式

制御(output)

機器と接続方式

連携方法

EventID/キーワード/補足

1

時計

IFTTTのサーバー

人感センサー

人感センサー︓

決まった時間にIFTTTから人感センサーに対しEventIDを送付

居るふり開始 19:00

Bluetooth

EventIDをキーに人感センサーが在室を確認

居るふり終了 20:00 EventID＝CamouﬂageStop

居るふり(在室確認)

EventID＝CamouﬂageGo

・在室の場合︓制御終了
・不在の場合︓EventIDをIFTTTに送付居るふり(不在の場合)

人感センサー

人感センサー︓BluetoothTV(ネットワークリモコン)

コンセント

2

監視カメラ

顔を認識し知らない顔を検

netatom security︓有線

知

LAN

照明

ネットワークリモコ 人感センサーからIFTTTにEventIDを送付

開始︓EventID＝CamouﬂageスマートコンセントON

ン︓WiFi

EventIDをキーにMakerChannelと連携しネットワークリモコンのAPIに 終了︓EventID＝CamouﬂageスマートコンセントOFF

スマートコンセン

requestを投げる
人感センサーからIFTTTにEventIDを送付

開始︓EventID＝CamouﬂageスマートコンセントON

ト︓WiFi

EventIDをキーにスマートコンセントと連携しコンセントのスイッチを

終了︓EventID＝CamouﬂageスマートコンセントOFF

ON/OFFする
LED電球︓有線LAN IFTTTからLED電球に対し制御

Copyright 2017 Connected Consumer Device Security Council Proprietary

LED電球の色を変える(CSS #800000)

56

Appendix3

評価検証仕様書の実例集[快適]
No ユースシーン名トリガー(input)

機器と接続方式

制御(output)

機器と接続方式

1

自動点灯

人感センサー

人感センサー︓Bluetooth

照明

LED電球︓有線LAN 人感センサーアプリとLED電球が連携し照明を制御

連携方法

2

熱中症防止(在室確認)

室内の温湿度センサー

温湿度センサー︓WiFi

人感センサー

人感センサー︓

室内の温度が30℃以上なった時IFTTTから人感センサーに対しEventID

Bluetoothを送付

EventID/キーワード/補足

EventID＝CriticalTemperature

EventIDをキーに人感センサーが在室を確認
・在室の場合︓EventIDをIFTTTに送付
・不在の場合︓制御終了
熱中症防止(在室の場合)

人感センサー

人感センサー︓Bluetooth

エアコン(ネットワークリモ

ネットワークリモコ 人感センサーからIFTTTにEventIDを送付

コン)

ン︓WiFi

EventID＝CoolingStart

エアコン(ネットワークリモ

ネットワークリモコ 温湿度センサーからIFTTT使ってMakerChannelと連携

室内の湿度が80％を超えたとき エアコンON

コン)

ン︓WiFi

MakerChannelからネットワークリモコンのAPIにrequestを投げる

室内の湿度が60％を下回ったとき エアコンOFF

連携方法

EventID/キーワード/補足

EventIDをキーにMakerChannelと連携しネットワークリモコンのAPIに
requestを投げる

3

定期換気

室内の温湿度センサー

温湿度センサー︓WiFi[防災]
No ユースシーン名トリガー(input)

機器と接続方式

制御(output)

機器と接続方式

1

天気予報①

Yahoo天気Yahoo提供サービス

照明

LED電球︓有線LAN MyThingsからLED電球に対し制御

最⾼気温が35〜40℃の範囲の場合

天気予報②

Yahoo天気Yahoo提供サービス

照明

LED電球︓有線LAN MyThingsからLED電球に対し制御

朝7時の天気予報が⾬の場合

防災通知①(照明)Yahoo防災

Yahoo提供サービス

照明

LED電球︓有線LAN MyThingsからLED電球に対し制御

防災速報で、地震情報がでたら

2

Dining1の電球を⻩色

Dining2の電球を⻘色
沖縄県︓震度5弱以上

電球すべての色を変える(CSS #FF00FF)
防災通知①(その他)Yahoo防災

Yahoo提供サービス

メール

Gmail

メール

Gmail

TV(ネットワークリモコン)ネットワークリモコ IFTTTがキーワードを含むメールを受けたことを検知しMakerChannel
ン︓WiFi

防災通知②

Yahoo防災

Yahoo提供サービス

照明

MyThingsからGmailにメールを送付
キーワード＝EarthquakeInfomationと連携してネットワークリモコンのAPIにrequestを投げる

LED電球︓有線LAN MyThingsからLED電球に対し制御

防災速報で、津波警報・注意方法が発令されたら

沖縄県

電球の色をランダムに光る

Copyright 2017 Connected Consumer Device Security Council Proprietary57

Appendix3

評価検証仕様書の実例集

ツール活⽤検討資料
６．検証ツール調査結果※CCDS(一般社団法人 重要生活機器連携セキュリティ協議会)で保有している検証基盤システムとそのほかのセキュリティ検証ツールについて整理し、検証での使⽤方針を検討する■CCDSツール一覧
CCDSツール
HNW評価ツール（検証基盤システム）

オープンソース脆弱性検証ツール

ツール名

機能概要

Gatling

HTTPリクエスト負荷

OpenVAS

ネットワーク脆弱性確認

接続されている全機器に対し調査を実施

脆弱性検査

Ostinato

IPパケット生成

キャプチャしたパケットを編集し送信

なりすまし

OWASP ZAP

Webアプリ脆弱性確認

接続されている全機器に対し調査を実施

検査

Sulleyファジング

ファジング攻撃

脆弱性検査

LOIC

ネットワーク負荷テストツール

SET-Metasploit

ネットワーク負荷テストツール

W3af

SQLインジェクション・XSS

Paros

プロキシー

hydoraパスワードクラック

medusaパスワードクラック

aicack-ng

WiFiハック

利⽤方法
対象脅威
空いているポートに対し攻撃し、機器の動作や他への
DoS攻撃
影響を確認

空いているポートに対し攻撃し、機器の動作や他への影響を確認
空いているポートに対し攻撃し、機器の動作や他への影響を確認
サーバーやデータベースに対し、インジェクション攻撃を⾏い、不正に情報を取得する
Proxyを通過した通信内容を書換えて攻撃可能
認証画面を持つ機器に対し、ID/パスワードを解読する
認証画面を持つ機器に対し、ID/パスワードを解読す
る
WiFiルーターに設定されている暗号(WEP・WPAな
ど)を解読

DoS攻撃
DoS攻撃
情報漏洩
盗聴
不正アクセス
不正アクセス
不正アクセス■各システムの概要
検証基盤システム
検証基盤で検証手順書、結果表を作成、管理することが出来る。
検証手順書は、検証基盤と連携しているツールを組合わせて作成することが出来る。
検証手順書を作成すると同時に検証シナリオを組み⽴てることで、その次の検証実⾏が自動化できる検証実施した結果、問題が発⾒された内容については脅威レポートを作成。作成した脅威レポートは検証基盤内で管理できるため検証手順と紐づけられる
脅威レポートからセキュリテイ評価レポートを発⾏できる※セキュリティ評価を一貫して対応が可能
オープンソース脆弱性検証ツール
各ツールが仮想空間上で起動、加えてターゲットも仮想空間に起動でき、PC内部でセキュリティ検証を実践できる導⼊されたツールを使って、実際に外部の機器に対して攻撃が可能※実際に攻撃に使⽤するより、セキュリティ検証のシミュレーションできることが特徴的■ツールの選定・活⽤方法※今回のスマートホームの環境で使⽤しないツールをグレーアウト
CCDSツール
HNW評価ツール（検証基盤システム）

オープンソース脆弱性検証ツール

ツール名

機能概要

Gatling

HTTPリクエスト負荷

OpenVAS

ネットワーク脆弱性確認

接続されている全機器に対し調査を実施

脆弱性検査

Ostinato

IPパケット生成

キャプチャしたパケットを編集し送信

なりすまし

OWASP ZAP

Webアプリ脆弱性確認

接続されている全機器に対し調査を実施

検査

Sulleyファジング

ファジング攻撃

脆弱性検査

LOIC

ネットワーク負荷テストツール

SET-Metasploit

ネットワーク負荷テストツール

W3af

SQLインジェクション・XSS

Paros

プロキシー

Proxyを通過した通信内容を書換えて攻撃可能

盗聴hydoraパスワードクラック

medusaパスワードクラック

aricack-ng

WiFiハック

ツールの活⽤方法
対象脅威
空いているポートに対し攻撃し、機器の動作や他への
DoS攻撃
影響を確認

認証画面を持つ機器に対し、ID/パスワードを解読する
認証画面を持つ機器に対し、ID/パスワードを解読す
る
WiFiルーターに設定されている暗号(WEP・WPAなど)を解読

不正アクセス
不正アクセス
不正アクセス[方針]
基本的な検証は検証基盤システムを活⽤。
検証手順書→検証結果→脅威レポート→セキュリティ検証レポートの一連の流れを実践
検証基盤システムにない、パスワードクラック(hydora)とWiFiハック(aricack-ng)はオープンソース脆弱性検証ツールを利⽤

Copyright 2017 Connected Consumer Device Security Council Proprietary58

Appendix3

評価検証仕様書の実例集

ツール活⽤検討資料
６．検証ツール調査結果※CCDS(一般社団法人 重要生活機器連携セキュリティ協議会)で保有している検証基盤システムとそのほかのセキュリティ検証ツールについて整理し、検証での使⽤方針を検討する■CCDSツール一覧
CCDSツール
HNW評価ツール

利⽤オープンソースツール 機能概要

（検証基盤システム）

汎⽤脆弱性検証ツール

利⽤方法
対象脅威
空いているポートに対し攻撃し、機器の動作や他への
DoS攻撃
影響を確認

Gatling

HTTPリクエスト負荷

OpenVAS

ネットワーク脆弱性確認

接続されている全機器に対し調査を実施

脆弱性検査

Ostinato

IPパケット生成

キャプチャしたパケットを編集し送信

なりすまし

OWASP ZAP

Webアプリ脆弱性確認

接続されている全機器に対し調査を実施

検査

Sulleyファジング

ファジング攻撃

脆弱性検査

LOIC

ネットワーク負荷テストツール

SET-Metasploit

ネットワーク負荷テストツール

W3af

SQLインジェクション・XSS

Paros

プロキシー

hydoraパスワードクラック

medusaパスワードクラック

aicack-ng

WiFiハック

空いているポートに対し攻撃し、機器の動作や他への影響を確認
空いているポートに対し攻撃し、機器の動作や他への影響を確認
サーバーやデータベースに対し、インジェクション攻撃を⾏い、不正に情報を取得する
Proxyを通過した通信内容を書換えて攻撃可能
認証画面を持つ機器に対し、ID/パスワードを解読する
認証画面を持つ機器に対し、ID/パスワードを解読す
る
WiFiルーターに設定されている暗号(WEP・WPAな
ど)を解読

DoS攻撃
DoS攻撃
情報漏洩
盗聴
不正アクセス
不正アクセス
不正アクセス■各システムの概要
検証基盤システム
検証基盤で検証手順書、結果表を作成、管理することが出来る。
検証手順書は、検証基盤と連携しているツールを組合わせて作成することが出来る。
検証手順書を作成すると同時に検証シナリオを組み⽴てることで、その次の検証実⾏が自動化できる検証実施した結果、問題が発⾒された内容については脅威レポートを作成。作成した脅威レポートは検証基盤内で管理できるため検証手順と紐づけられる
脅威レポートからセキュリテイ評価レポートを発⾏できる※セキュリティ評価を一貫して対応が可能
オープンソース脆弱性検証ツール
各ツールが仮想空間上で起動、加えてターゲットも仮想空間に起動でき、PC内部でセキュリティ検証を実践できる導⼊されたツールを使って、実際に外部の機器に対して攻撃が可能※実際に攻撃に使⽤するより、セキュリティ検証のシミュレーションできることが特徴的■ツールの選定・活⽤方法※今回のスマートホームの環境で使⽤しないツールをグレーアウト
CCDSツール
HNW評価ツール

利⽤オープンソースツール 機能概要

（検証基盤システム）

汎⽤脆弱性検証ツール

ツールの活⽤方法
対象脅威
空いているポートに対し攻撃し、機器の動作や他への
DoS攻撃
影響を確認

Gatling

HTTPリクエスト負荷

OpenVAS

ネットワーク脆弱性確認

接続されている全機器に対し調査を実施

脆弱性検査

Ostinato

IPパケット生成

キャプチャしたパケットを編集し送信

なりすまし

OWASP ZAP

Webアプリ脆弱性確認

接続されている全機器に対し調査を実施

検査

Sulleyファジング

ファジング攻撃

脆弱性検査

LOIC

ネットワーク負荷テストツール

SET-Metasploit

ネットワーク負荷テストツール

W3af

SQLインジェクション・XSS

Paros

プロキシー

Proxyを通過した通信内容を書換えて攻撃可能

盗聴hydoraパスワードクラック

medusaパスワードクラック

aricack-ng

WiFiハック

認証画面を持つ機器に対し、ID/パスワードを解読する
認証画面を持つ機器に対し、ID/パスワードを解読す
る
WiFiルーターに設定されている暗号(WEP・WPAなど)を解読

不正アクセス
不正アクセス
不正アクセス[方針]
基本的な検証は検証基盤システムを活⽤。
検証手順書→検証結果→脅威レポート→セキュリティ検証レポートの一連の流れを実践
検証基盤システムにない、パスワードクラック(hydora)とWiFiハック(aricack-ng)はオープンソース脆弱性検証ツールを利⽤

Copyright 2017 Connected Consumer Device Security Council Proprietary59

Appendix3

評価検証仕様書の実例集

７．テストケース及び評価検証手順書の記載実例（一部を抜粋）
手順書ID
タイトル
説明

23
(総務省)IoTサービス創出支援事業 CCDS-HNW社ツール検証2
CCDS-HNW社ツールを使用してのセキュリティ検証を実施する

実施期間

2017/02/01
TestItemIODtoList
行番号

項目ID

～

大項目

2017/02/10

中項目

小項目

前提条件

実行手順

確認項目

CCDS-HNW社のデフォルトの設定状態での検証

1

230

不正アクセス
Dos攻撃

プロトコル UDP：53
機器：スマートコンセント
サービス：domain
CCDS-HNW社ツール検 2回目
IPアドレス：192.168.0.7
証ダッシュボードより結果を確認しログを確認する
ダッシュボード画面より実行ボタンを押下し検証※検証結果でABORTEDになった場合はCCDS-HNW社ツールよりロを開始する
グを確認する■OSSツール(CCDS-HNW社)
・OpenVAS(ネットワーク脆弱性)
・Ostinato(IPパケット生成)
CCDS-HNW社のデフォルトの設定状態での検証

2231

不正アクセスDos攻撃

CCDS-HNW社ツール検 機器：LED電球証
OWASP,Ostinato

プロトコル TCP：80
サービス：httpIPアドレス：192.168.0.4

ダッシュボードより結果を確認しログを確認する
ダッシュボード画面より実行ボタンを押下し検証※検証結果でABORTEDになった場合はCCDS-HNW社ツールよりロを開始する
グを確認する■OSSツール(CCDS-HNW社)
・OWASPZAP(Webアプリ脆弱性)
・Ostinato(IPパケット生成)
CCDS-HNW社のデフォルトの設定状態での検証

3

232

不正アクセス
Dos攻撃

プロトコル TCP：80
サービス：httpCCDS-HNW社ツール検 機器：ネットワークリモコ
IPアドレス：192.168.0.13
証
ン OWASP,Ostinato

ダッシュボードより結果を確認しログを確認する
ダッシュボード画面より実行ボタンを押下し検証※検証結果でABORTEDになった場合はCCDS-HNW社ツールよりロを開始する
グを確認する■OSSツール(CCDS-HNW社)
・OWASPZAP(Webアプリ脆弱性)
・Ostinato(IPパケット生成)
CCDS-HNW社のデフォルトの設定状態での検証

4233

不正アクセスDos攻撃

CCDS-HNW社ツール検 機器：HEMS(無線アダプ
証ター) OWASP,Ostinato

プロトコル TCP：80
サービス：httpIPアドレス：192.168.0.10

ダッシュボードより結果を確認しログを確認する
ダッシュボード画面より実行ボタンを押下し検証※検証結果でABORTEDになった場合はCCDS-HNW社ツールよりロを開始する
グを確認する■OSSツール(CCDS-HNW社)
・OWASPZAP(Webアプリ脆弱性)
・Ostinato(IPパケット生成)
CCDS-HNW社のデフォルトの設定状態での検証

5234

不正アクセスDos攻撃

CCDS-HNW社ツール検 機器：HEMS(本体)証
OWASP,Ostinato

プロトコル TCP：80
サービス：httpIPアドレス：192.168.0.216

ダッシュボードより結果を確認しログを確認する
ダッシュボード画面より実行ボタンを押下し検証※検証結果でABORTEDになった場合はCCDS-HNW社ツールよりロを開始する
グを確認する■OSSツール(CCDS-HNW社)
・OWASPZAP(Webアプリ脆弱性)
・Ostinato(IPパケット生成)
CCDS-HNW社のデフォルトの設定状態での検証

6235

不正アクセスDos攻撃

CCDS-HNW社ツール検証

プロトコル TCP：49153
機器：スマートコンセント サービス：upnp
3回目IPアドレス：192.168.0.7※TCPのポートで検証を行う■OSSツール(CCDS-HNW社)
・Sulley(ファジング攻撃)
・OpenVAS(ネットワーク脆弱性)
・Ostinato(IPパケット生成)
・Gatling(HTTPリクエスト負荷)

ダッシュボードより結果を確認しログを確認する
ダッシュボード画面より実行ボタンを押下し検証※検証結果でABORTEDになった場合はCCDS-HNW社ツールよりロを開始する
グを確認する

Copyright 2017 Connected Consumer Device Security Council Proprietary60

Appendix4

Appendix4

リスク評価手法の紹介

リスク評価手法の紹介

Copyright 2017 Connected Consumer Device Security Council Proprietary61

Appendix4

リスク評価手法の紹介

参考資料として、主要なリスク評価手法の詳細を以下に記載する。

1. CVSSv3[16]1-1. 概要
CVSS は Common Vulnerability Scoring System の略称。コンピュータ・セキュリティの非営利団体「FIRST」（Forum of Incident Response and Security Teams）が推進する、脆弱性評価システムのこと。
脆弱性ごとにパラメータを設定して値を求めることで、深刻度の判断材料を得ることができる。現在、最新のバージョンとして version3 が公開されている。

1-2. リスクファクタ
1)基本評価基準（Base Metrics）：「機密性」、「完全性」、「可用性」に対する影響から評価
2)現状評価基準（Temporal Metrics）：攻撃コードの出現有無や対策情報が利用可能といった基準で評価
3)環境評価基準（Environment Metrics）：二次的被害の大きさや、対象製品の使用状況といった基準で評価

1-3. リスク計算式
1)基本評価基準（Base Metrics）①影響度

調整前影響度 = 1 - (1 - C)×(1 - I)×(1 - A)…式(1)

影響度(スコープ変更なし)= 6.42×調整前影響度…式(2)

影響度(スコープ変更あり)=…式(3)7.52×(調整前影響度 - 0.029) - 3.25×(調整前影響度 - 0.02)15（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）②攻撃容易性Copyright 2017 Connected Consumer Device Security Council Proprietary62

Appendix4

リスク評価手法の紹介

攻撃容易性 = 8.22×AV×AC×PR×UI…式(4)（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）③基本値
・影響度がゼロ以下の場合

基本値 = 0…式(5)

（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）・影響度がゼロよりも大きい場合

スコープ変更なし…式(6)基本値 = RoundUp1(min [(影響度＋攻撃容易性), 10])
(小数点第 1 位切り上げ)

スコープ変更あり…式(7)

基本値 = RoundUp1(min [(1.08×(影響度＋攻撃容易性)), 10])
(小数点第 1 位切り上げ)（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）基本評価基準
評価項目

評価結果と値

攻撃元区分（AV）

ネットワーク（N）

隣接（A）

ローカル（L）

物理（P）

0.85

0.62

0.55

0.20

低（L）

高（H）

－

－

0.77

0.44

攻撃条件の複雑さ（AC）※（）内の値はスコープ変更ありの場合

Copyright 2017 Connected Consumer Device Security Council Proprietary63リスク評価手法の紹介

Appendix4
必要な特権レベル

不要（N）

低（L）

高（H）

0.85

0.62（0.68）※

0.27（0.50）※

不要（N）

要（R）

－

－

0.85

0.62

変更なし（U）

変更あり（C）

－

－

高（H）

低（L）

なし（N）

－

0.56

0.22

0

高（H）

低（L）

なし（N）

0.56

0.22

0

高（H）

低（L）

なし（N）

0.56

0.22

0

（PR）
ユーザ関与レベル（UI）
スコープ（S）
機密性への影響（C）

完全性への影響（I）

可用性への影響（A）

－

－

－

（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）2)現状評価基準（Temporal Metrics）①現状値
現状値 = RoundUp1(基本値×E×RL×RC)…式(8)(小数点第 1 位切り上げ)（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）現状評価基準
評価項目

評価結果と値攻撃される可能未評価（X）

容易に攻撃可能（H）

攻撃可能（F）

実証可能（P）

未実証（U）

性（E）

1.00

1.00

0.97

0.94

0.91

利用可能な対策

未評価（X）なし（U）

非公式（W）

暫定（T）

正式（O）

のレベル（RL）

1.00

1.00

0.97

0.96

0.95

脆弱性情報の信未評価（X）

確認済（C）

未確証（R）

未確認（U）－

頼性（RC）

1.00

1.00

0.96

0.92

（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）Copyright 2017 Connected Consumer Device Security Council Proprietary64

Appendix4

リスク評価手法の紹介

3)環境評価基準（Environment Metrics）①緩和策後影響度

緩和策後調整前影響度 =…式(9)min [(1 -(1 - MC×CR)×(1 - MI×IR)×(1 - MA×AR)), 0.915]

緩和策後影響度(スコープ変更なし)= 6.42×緩和策後調整前影響度…式(10)

緩和策後影響度(スコープ変更あり)=…式(11)

7.52×(緩和策後調整前影響度 - 0.029) - 3.25×(緩和策後調整前影響度 0.02)15（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）②緩和策後攻撃容易性

緩和策後攻撃容易性 = 8.22×MAV×MAC×MPR×MUI…式(12)（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）③環境値
・緩和策後影響度がゼロ以下の場合

環境値 = 0…式(13)（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）・緩和策後影響度がゼロよりも大きい場合

Copyright 2017 Connected Consumer Device Security Council Proprietary65

Appendix4

リスク評価手法の紹介

スコープ変更なし…式(14)

緩和策後基本値 =RoundUp1(min [(緩和策後影響度＋緩和策後攻撃容易性), 10])
環境値 = RoundUp1(緩和策後基本値×E×RL×RC)(小数点第 1 位切り上げ)

スコープ変更あり…式(15)

緩和策後基本値 =RoundUp1(min [(1.08×(緩和策後影響度＋緩和策後攻撃容易性)), 10])
環境値 = RoundUp1(緩和策後基本値×E×RL×RC)…式(15)(小数点第 1 位切り上げ)（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）環境評価基準
評価項目

評価結果と値

対象システムのセキュリティ要求度（CR、IR、AR）

未評価（X）

高(H)

中（M）

低（L）

1.0

1.5

1.0

0.5

※評価結果に対応する値は、基本評価基準と同一となる。

・緩和策後の攻撃元区分(MAV)・緩和策後の攻撃条件の複雑さ(MAC)・緩和策後の必要な特権レベル(MPR)
・緩和策後のユーザ関与レベル(MUI)
・緩和策後のスコープ(MS)・緩和策後の機密性への影響(MC)・緩和策後の完全性への影響(MI)・緩和策後の可用性への影響(MA)（出典：IPA「共通脆弱性評価システム CVSS v3 概説」[16]）Copyright 2017 Connected Consumer Device Security Council Proprietary66

Appendix4

リスク評価手法の紹介

2. NIST SP800-30 [17]2-1. 概要NIST SP800-30 は米港連邦政府の情報システムのリスクアセスメント実施方法を提供するために、NIST
SP800-39 を詳説したドキュメント。

2-2. リスクファクタ
1)THREAT SOURCES（脅威源）
2)THREAT EVEVTS（脅威内容）
3)VULNERABILITIES AND PREDIPONSING CONDITIONS（脆弱性と発生条件）
4)LIKELIHOOD OCCURRENCE（発生の可能性）
5)IMPACT（影響度）

2-3. リスク計算式
リスクファクタは例示されているが、各ファクタを結合する計算アルゴリズムは各組織においてリス
クモデルを定義し、それを含むとしている。
（Organization-specific risk models include algorithms(e.g., formulas, tables, rules) for
combining risk factors）

2-4. 備考
各リスクファクタを利用した計算式は定義されておらず、組織毎に設定する必要がある。

3. GMITS（ISO/IEC TR 13335）[18]
3-1. 概要GMITS（ISO/IEC TR 13335）[18]は IT セキュリティマネジメントのガイドライン。現在存在する各種リスクマネジメント手法のベースとなっている規格。

3-2. リスクファクタ
1)Asset（資産価値）
2)Threat（脅威）Copyright 2017 Connected Consumer Device Security Council Proprietary67

Appendix4

リスク評価手法の紹介

3)Vulnerability（脆弱性）

3-3. リスク計算式
リスクファクタは例示されているが、各ファクタを結合する計算アルゴリズムは記載されていない。

3-4. 備考
各リスクファクタの重み付け、リスクファクタを利用した計算式は定義されておらず、組織毎に設定する必要あり。

4. ETSI TS102 165-1[19]4-1. 概要ETSI TS102 165-1 は European Telecommunications Standards Institute によって策定された詳細
リスク評価アプローチ手法となる。

4-2. リスクファクタ
表 A2-1. ETSI TS102 165-1 のリスクファクタ
1)Likelihood（攻撃の可能性）

2)Impact（影響度）

1-1)Time（攻撃に要する時間）2-1)Asset Impact（資産への影響）

1-2)Expertise(攻撃者のスキル)

2-2)Attack Intensity（攻撃の強度）

1-3)Knowledge(システム知識)
1-4)Opportunity（攻撃の機会）
1-5)Equipment（設備）（出典： ETSI TS102 165-1[19]）4-3. リスク計算式
Risk＝

Likelihood ×

Impact※Likelihood と Impact は、それぞれ以下 1)～2)の算定プロセスによって、値を計算する。

表 A2-2
Value

リスク算定の基準
Risk

Explanation

Copyright 2017 Connected Consumer Device Security Council Proprietary68Appendix4
1, 2

Minor

リスク評価手法の紹介

No essential assets are concerned, or the attack is unlikely.
Threats causing minor risks have no primary need for counter measures.

3, 4

Major

Threats on relevant assets are likely to occur although their impact isunlikely to be fatal.
Major risks should be handled seriously and should be minimized by theappropriate use of countermeasures.

6 ,9CriticalThe primary interests of the providers and/or subscribers are threatened andthe effort required from a potential attacker's to implement the threat(s) is
not high.
Critical risks should be minimized with highest priority.

Note: Because risk is calculated as the product of likelihood and impact the values 5, 7 and 8 cannot
occur.

（出典： ETSI TS102 165-1[19]）1)Likelihood（攻撃の可能性）の計算
Likelihood ＝Time ＋

Expertise＋Knowledge＋Opportunity※合計値を表 A2-4 及び、表 A2-5 に当てはめて、最終的な Likelihood の値を算出する。

表 A2-3.

Likelihood のリスク評価基準
Factor

Range

Value

Time(1 point per week)

≦1day

0

（攻撃に要する時間）≦1week1≦1month4≦3months

13≦6months

26> 6months

See note 1

Expertise（攻撃者のスキル） Laymen

Knowledge（知識）0Proficient2

Expert5

Public0

Copyright 2017 Connected Consumer Device Security Council Proprietary69Appendix4

Opportunity（攻撃の機会）

Equipment（機器）リスク評価手法の紹介

Restricted

1

Sensitive

4

Critical

10

Unnecessary/unlimited access

0

Easy

1

Moderate

4

Difficult

12

None

See note 2Standard

0

Specialized

3

Bespoke7Note1：Attack potential is beyond highNote2：Attack path is not exploitable（出典： ETSI TS102 165-1[19]）表 A2-4.

リスク評価の結果と脆弱性レベルとの対応

Range of values

Resistant to attacker with attack potential of：

0 to 2

No rating

3 to 6Basic

7 to 14

Moderate

15 to 26

High

> 26

Beyond high

（出典： ETSI TS102 165-1[19]）表 A2-5. 脆弱性レベルと攻撃が発生する可能性との対応
Vulnerability rating
Beyond highLikelihood

value

Unlikely

1Moderate

Possible2

Basic

Likely3High

No rating

Copyright 2017 Connected Consumer Device Security Council Proprietary70Appendix4

リスク評価手法の紹介

Note：Motivation is not considered explicitly in the vulnerability rating.

（出典： ETSI TS102 165-1[19]）2)Impact（影響度）の計算
Result Impact ＝Asset Impact ＋

Attack Intensity※合計値が 3 以上の場合も、上限は 3 となる。

表 A2-6.

2-1)Asset Impact（資産への影響）の評価基準

ImpactExplanation

Value

Low

The concerned party is not harmed very strongly; the possible damage1

is low.
MediumThe threat addresses the interests of providers/subscribers and cannot

2

be neglected.
High

A basis of business is threatened and severe damage might occur in this3

context.

（出典： ETSI TS102 165-1[19]）表 A2-7.

2-2) Attack Intensity（攻撃の強度）の評価基準
Attack intensity

valueSingle instance of attack

0Moderate level of multiple instances

1

Heavy level of multiple instances2（出典： ETSI TS102 165-1[19]）4-4. 備考
各リスクファクタへの重み付けが同一ではないため、Time ファクタの見積を間違えると結果に与える影響が大きい。

Copyright 2017 Connected Consumer Device Security Council Proprietary71

Appendix4

リスク評価手法の紹介

5. 情報セキュリティマネジメントシステム(ISMS) ISO/IEC27001
5-1. 概要
情報セキュリティマネジメントシステム(ISMS) ISO/IEC27001 は、情報資産のセキュリティを管理するための枠組みを策定し、実施するための規格である。

5-2. リスクファクタ
1)資産の価値
2)脅威
3)脆弱性

5-3. リスク計算式
リスク値

＝

資産の価値

×

脅威

×

脆弱性

※計算式は JPDEC（日本情報経済社会推進協会）による例示であり、規格自体には計算式は示されていない。
5-4. 備考
各リスクファクタへの重み付けは同一（1～3）

6. OCTAVE Allegro[20]6-1. 概要
OCTAVE（Operationally Critical Threat, Asset, and Vulnerability Evaluation）Allegro[20]はカー
ネギーメロン大学（米国）により 1999 年に発行された OCTAVE をベースに作られた脆弱性評価フレー
ムワーク。

6-2. リスクファクタ
1)Impact Area：
1.評判（Reputation）、2.Financial（金銭）、3.Productivity（生産性）、
4.Safety&Health（安全、健康）、5.Fines/Legal（罰）※Ranking については、1~5 の優先順位(1～5)値。
2)Impact Value：Impact Area に対する影響度を High、Mid、Low の 3 段階に分けたもの。

Copyright 2017 Connected Consumer Device Security Council Proprietary72リスク評価手法の紹介

Appendix4
6-3. リスク計算式
×Impact Value の合計値

Risk＝Ranking

表 A2-8.

各リスクファクタの評価入力例

Impact Area

Ranking

Impact Value

Score

Reputation（評判）4Moderate(2)8Financial（金銭）5

Low(1)

5

Productivity（生産性）

3

Low(1)

3

Safety and Health（安全、健康）1

Low(1)

1

Fines/Legal（罰）2High(3)

6

Total

23

(出典：OCTAVE Allegro[20])6-4. 備考
他の規格等と異なり、リスクファクタで脆弱性を考慮していない。

7. The OWASP Risk Rating Methodology [21]7-1. 概要
The OWASP Risk Rating Methodology は OWASP（Open Web Application Security Project）によって開発された脆弱性評価の手法となる。

7-2. リスクファクタ①Threat Agent（脅威の要因）②Vulnerability（脆弱性の要因）③Technical Impact（テクニカルインパクト）④Business Impact（ビジネスへの影響度）①Threat Agent（脅威の要因）③Technical Impact（テクニカルインパクト）①-1：Skill Level（技術水準）③-1：Loss of confidentiality（機密性の喪失）①-2：Motive（動機）③-2：Loss of integrity（完全性の喪失）①-3：Opportunity（機会）③-3：Loss of availability（可用性の喪失）①-4：Size（影響範囲）③-4：Loss of accountability（説明責任の喪失）

Copyright 2017 Connected Consumer Device Security Council Proprietary73

Appendix4

リスク評価手法の紹介②Vulnerability（脆弱性の要因）④Business Impact（ビジネスへの影響度）②-1：Ease of discovery（発見のしやすさ）④-1：Financial damage（資産損失）②-2：Ease of exploit（悪用のしやすさ）④-2：Reputation damage（ブランド失墜）②-3：Awareness（既知の脆弱性かどうか）④-3：Non compliance（法例違反）②-4：Intrusion detection（侵入検知）④-4：Privacy violation（プライバシー侵害）（出典：The OWASP Risk Rating Methodology[21]より邦訳）

7-3. リスク計算式
Risk Severity ＝（（①＋②）/2）×（（③＋④）/2）

1)リスク評価基準
発生確率と影響レベルの算出基準
0～＜3

Low（低）

3～＜6Medium（中）6～9High（高）（出典：The OWASP Risk Rating Methodology[21]より邦訳）

2)発生確率と影響レベルの計算式
発生確率（攻撃の可能性）
脅威の要因
技術水準

X1

動機

X2

機会

X3

脆弱性の要因
影響範囲

X4

発見の

悪用の

既知の

しやすさ

しやすさ

脆弱性か

X5

X6

X7

侵入検知

X8

全体としての発生確率＝X1～X8 の平均値

影響レベル
テクニカルインパクト

ビジネスへの影響

機密性

完全性

可用性

説明責任

の喪失

の喪失

の喪失

の喪失

Y1

Y2

Y3

Y4

資産損失

ブランド

法律違反

失墜
Y5

Y6

プライバシ
ー侵害

Y7

Y8

Copyright 2017 Connected Consumer Device Security Council Proprietary74

Appendix4

リスク評価手法の紹介

総合的なテクニカルインパクト

総合的なビジネスへの影響＝Y1～Y4 の平均値

＝Y5～Y8 の平均値

全体として影響レベル＝Y1～Y8 の平均値

（出典：The OWASP Risk Rating Methodology [21]より邦訳）

3)全体的なリスクの重大性基準
全体的なリスクの重大性
high（高）Medium（中）High（高）Critical（クリティカル）

影響レベル

Medium（中）Low（低）

Medium（中）High（高）Low（低）

Note（注意）

Low（低）

Medium（中）Low（低）

Medium（中）high（高）発生確率（攻撃の可能性）（出典：The OWASP Risk Rating Methodology[21]より邦訳）

7-4. 備考
・リスクファクタが多いので、どれか一つの要素に対するリスクを排除したとしてもトタルのリスクには大きな影響が出ない（複数の要素のリスク排除が必要）
・各リスクファクタにウェイト(優先度)の概念がない。

8. FAIR[22]8-1. 概要
FAIR（Factor Analysis of Information Risk）[22]は Risk Management Insight LLC によって開発されたリスク評価方法。

8-2. リスクファクタ
1)Loss Event Frequency（LEF）：損失発生頻度（TEF、Vuln）
Copyright 2017 Connected Consumer Device Security Council Proprietary75リスク評価手法の紹介

Appendix41-1)Threat Event Frequency（TEF）：発生頻度1-2)Threat Capability（Tcap）：脅威難易度1-3)Control Strength（CS）：保護強度1-4)Vulnerability（Vuln）：脆弱性（Tcap、CS）
2)Probable Loss Magnitude（PLM）：金銭的な影響度

8-3. リスク算出
RISK

PLM

Severe

H

H

C

C

C

High

M

H

H

C

C

Significant

M

M

H

H

C

Moderate

L

M

M

H

H

Low

L

L

M

M

M

Very Low

L

L

M

M

M

VL

L

M

H

VH

LEF

（出典：Risk Management Insight LLC

FAIR[22]）8-4. 備考
LEF は４つのファクタにより決まるが、最終的なリスクは LEF と PLM との組み合わせによって決定される。仮に LEF が小さかったとしても金額による影響（PLM）が大きければリスクが高いことになる。（PLM の値が結果に対して影響度が大きい）

9. CCDS 改良方式[4]9-1. 概要
CCDS によって考案され、「CCDS 製品分野別セキュリティガイドライン 車載器編 Ver.1.01」[4]において公開されている。特徴としては既存のリスク評価手法と比較し、より簡易に分析が可能であり、またリ
スクファクタに「攻撃者のモチベーション」が組み込まれ、影響度の基準として「人命リスク」を想定した基準を定義している。

Copyright 2017 Connected Consumer Device Security Council Proprietary76

Appendix4

リスク評価手法の紹介

9-2. リスクファクタ
1)難易度：S~A の 4 段階で攻撃の難易度を評価する
2)影響度：「軽微」～「壊滅的」までの 4 段階で攻撃による影響度を評価する
3)攻撃者のモチベーション：小～大までの 3 段階で攻撃者のモチベーションを評価する。

9-3. リスク計算式
リスク値

＝

（難易度

＋

影響度）

リスク値

×

攻撃者のモチベーション

基準

Low

8 未満

Middle8 以上 12 未満

High

12 以上 17 未満

Must

17 以上

（出典：CCDS「CCDS 製品分野別セキュリティガイドライン 車載器編 Ver.1.01」[4]）

1)難易度の判定基準
評価項目
難易度

ランク
S

判定基準

値

複数の条件（認証、特別な権限など）が必要。かつ、ローカルからのみ

1

接続（攻撃）が可能。
A

単一の条件（認証、特別な権限など）が必要。かつ、ローカルからのみ

3

接続（攻撃）が可能。
B

一つ以上の条件（認証、特別な権限など）が必要。もしくは、ローカル

5からのみ接続（攻撃）が可能。
C

攻撃するための条件が不要。かつ、無線ネットワークからの接続（攻撃） 10が可能。

（出典：CCDS「CCDS 製品分野別セキュリティガイドライン 車載器編 Ver.1.01」[4]）2)影響度の評価基準
評価項目
影響度

ランク
軽微

判定基準

値

攻撃を受けてもユーザに影響がない、もしくは軽微な表示異常しか発生

Copyright 2017 Connected Consumer Device Security Council Proprietary77

1Appendix4

リスク評価手法の紹介

しない。かつ、漏えいする情報も個人を特定できるような情報は漏洩しない。
中程度

攻撃を受けた場合に、ユーザに不利益をもたらす。

3

もしくは、漏えいした情報から個人が特定される。
重大

攻撃を受けた場合に、ユーザに不利益をもたらし、二次的被害も発生。 5もしくは、漏えいした情報から複数の個人が特定される。

壊滅的攻撃を受けた場合に、人命に関わるような被害や二次的被害が発生す10る。

（出典：CCDS「CCDS 製品分野別セキュリティガイドライン 車載器編 Ver.1.01」[4]）

3)攻撃者のモチベーションの評価基準
評価項目

ランク

判定基準

値

攻撃者のモ

小

偶発的に発生し攻撃者には何の意図もない。

1

チベーショ

中

実験や気晴らし、自己顕示などの目的を持つ。

1.25

ン

大

金銭的な利益を得たり、安全保障に影響を与えるなどの具体的な強い目

1.5

的を持つ。

（出典：CCDS「CCDS 製品分野別セキュリティガイドライン 車載器編 Ver.1.01」[4]）9-4. 備考「CCDS 製品分野別セキュリティガイドライン 車載器編 Ver.1.01」においては、車載分野における他のリスク評価手法との結果比較も掲載されている。

Copyright 2017 Connected Consumer Device Security Council Proprietary78７．引用・参考文献

７．引用・参考文献[1] 一般社団法人 重要生活機器連携セキュリティ協議会(2015)「一般社団法人 重要生活機器連携セキュリティ協議会の概要」,[online] https://www.ccds.or.jp/public/document/other/CCDS_Info_v1.6.pdf (11)[2] 総務省 IoT 推進コンソーシアム(2016)「IoT セキュリティガイドライン」,[online]
http://www.meti.go.jp/press/2016/07/20160705002/20160705002-1.pdf (36)[3] 独立行政法人 情報処理推進機構(2016)「つながる世界の開発指針」,[online]
http://www.ipa.go.jp/files/000051411.pdf (65)[4] 一般社団法人 重要生活機器連携セキュリティ協議会(2016)「CCDS 製品分野別セキュリティガイドライン-概要説
明資料 車載器編 Ver.1.01」,[online]https://www.ccds.or.jp/public/document/other/guidelines/CCDS%E8%A3%BD%E5%93%81%E5%88%86%E9%
87%8E%E5%88%A5%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%B3_%E8%BB%8A%E8%BC%89%E5%99%A8%E7%B7%A8_Ver.1.01.pdf[5] 一般社団法人 重要生活機器連携セキュリティ協議会(2016)「CCDS 製品分野別セキュリティガイドライン-概要説
明資料 IoT-GW 編 Ver.1.01」,[online]https://www.ccds.or.jp/public/document/other/guidelines/CCDS%E8%A3%BD%E5%93%81%E5%88%86%E9%
87%8E%E5%88%A5%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%B3_IoT-GW%E7%B7%A8_Ver.1.01.pdf[6] 一般社団法人 重要生活機器連携セキュリティ協議会(2016)「CCDS 製品分野別セキュリティガイドライン-概要説
明資料 ATM 編 Ver.1.0」,[online]https://www.ccds.or.jp/public/document/other/guidelines/CCDS%E8%A3%BD%E5%93%81%E5%88%86%E9%
87%8E%E5%88%A5%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%B3_%E9%87%91%E8%9E%8D%E7%AB%AF%E6%9C%AB(ATM)%E7%B7%A8_Ver.1.
0.pdf[7] 一般社団法人 重要生活機器連携セキュリティ協議会(2016)「CCDS 製品分野別セキュリティガイドライン-概要説
明資料 POS 編 Ver.1.0」,

Copyright 2017 Connected Consumer Device Security Council Proprietary79７．引用・参考文献[online]https://www.ccds.or.jp/public/document/other/guidelines/CCDS%E8%A3%BD%E5%93%81%E5%88%86%E9%
87%8E%E5%88%A5%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%B3_%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3POS%E7%B7%A8_Ver.1.0.p
df[8] ISO/IEC 25010:2011: "Systems and software engineering -- Systems and software Quality Requirements and

Evaluation (SQuaRE) – System and software quality models."[9] ISO/IEC/IEEE29119: "Software and system engineering - Software Testing -."[10] NIST SP800-115: "Technical Guide to Information Security Testing and Assessment – Recommendations of the

National Institute of Standards Technology."[11] Online Trust Alliance(2016): "OTA IoT Trust Framework Update July12, 2016"[12] Open Web Application Security Project(2014) "Internet of Things Top Ten" ,[online]
https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf[13] 独立行政法人 情報処理推進機構(2016) 「IoT 開発におけるセキュリティ設計の手引き」,[online]
https://www.ipa.go.jp/files/000052459.pdf[14] 独立行政法人 情報処理推進機構(2013)「ファジング実践資料（テストデータ編）」,[online]
https://www.ipa.go.jp/files/000035160.pdf[15] ESBR:独立行政法人 情報処理推進機構(2013) 「組込みソフトウェア開発における品質向上の勧め[バグ管理/手法編]」,[online] http://www.ipa.go.jp/files/000027629.pdf[16] 独立行政法人 情報処理推進機構(2015)「共通脆弱性評価システム CVSS v3 概説」,[online]
https://www.ipa.go.jp/security/vuln/CVSSv3.html[17] NIST SP800-30: "Guide for Conducting Risk Assessments – INFORMATION SECURITY -."[18] ISO/IEC TR 13335-3 (GMITS part3): "Information technology - Guidelines for the management of IT Security -Part 3: Techniques for the management of IT Security."

Copyright 2017 Connected Consumer Device Security Council Proprietary80７．引用・参考文献[19] ETSI TS 102 165-1: “Telecommunications and Internet converged Services and Protocols for Advanced

Networking (TISPAN); Methods and protocols; Part 1: Method and proforma for Threat, Risk, Vulnerability
Analysis,” V4.2.3 (2011-03).
[20] [Caralli 2007] Caralli, Richard; Stevens, James; Young, Lisa; Wilson, William. “Introducing OCTAVE

Allegro:Improving the Information Security Risk Assessment Process.” CMU/SEI-2007-TR-012. Carnegie Mellon
University, Software Engineering Institute, May 2007.
[21] Open Web Application Security Project “The OWASP Risk Rating Methodology”,[online]
https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology[22] Risk Management Insight “An Introduction to Factor Analysis of Information Risk(FAIR),”[online]
ftp://mail.im.tku.edu.tw/Prof_Liang/IRM/10%20An%20Introduction%20to%20Factor%20Analysis%20of%20Informatio
n%20Risk.pdf

Copyright 2017 Connected Consumer Device Security Council Proprietary81７．引用・参考文献
本書は、一般社団法人 重要生活機器連携セキュリティ協議会(CCDS)において作成しました。

編著者（敬称略）
委

員

三上

清一

一般社団法人 重要生活機器連携セキュリティ協議会

車載 SWG 主査

株式会社 JVC ケンウッド
渡邉充

一般社団法人 重要生活機器連携セキュリティ協議会

IoT-GW SWG 主査

株式会社日立製作所
緒方日佐男

一般社団法人 重要生活機器連携セキュリティ協議会

IoT-GW SWG 主査

日立オムロンターミナルソリューションズ株式会社
矢是泰士

一般社団法人 重要生活機器連携セキュリティ協議会

IoT-GW SWG 主査

オムロンソーシアルソリューションズ株式会社
事務局

田久保

順

一般社団法人 重要生活機器連携セキュリティ協議会

作成支援

合同会社ゼロワン研究所

Copyright 2017 Connected Consumer Device Security Council Proprietary82