PowerPoint プレゼンテーションIoTの特徴 4 4 IoT：モノのインターネット BInternet of Things C IoTの特徴：⧨ な⦔器・システムがつながること →より

つながる世界のセキュリティ設計入門～セキュリティ要件の見える化～

2016.7.9

情報セキュリティ大学院大学客員研究員金子朋子

1

自己紹介

金子朋子博士（情報学）公認情報セキュリティ監査人（CAIS)情報セキュリティ大学院大学客員研究員

2013年情報セキュリティ大学院大学博士後期課程修了．文部科学省認定プログラム・サーティフィケート取得者（情報セキュリティスペシャリスト，ソフトウェアスペシャリスト）

日本ネットワークセキュリティ協会(JNSA)優秀論文賞受賞（2015年）

3

目次

• IoTの特徴• IoTセキュリティの現状・課題• 安全なシステム・ソフトウェアの開発• 上流工程でのセキュリティ設計• セキュリティコンセプトの策定• セキュリティ要求分析の特徴• 脅威の特定・分析手法（STRIDE、ミスユースケース、Attack Tree）• 脅威に対するリスクの見積もり及び評価（FMEA、CVSS、ｉ*Liu法、SARM）• セキュアプログラミング• ロジカルな設計品質の説明（アシュアランスケース）• アシュアランスケースの表記法• セキュリティ設計の評価・認証（コモンクライテリア、セキュリティ要件）• IoTセキュリティ認証に対するCC-Caseの特長

IoTの特徴

4

4

IoT：モノのインターネット（Internet of Things）IoTの特徴：多様な機器・システムがつながること

→より複雑なセキュリティ要件をもつことになる

• この脅威事例は本当？スマホでATMから現金を引き出すウイルスでハッキングしたのは14歳の少年だった。

5○か×か？

6

答えは

7

14 year

olds hack

BMO bank.machine;

staff

doesn't

believe

them

CCDS資料より引用

IoTセキュリティの現状

IoTシステムへの脅威事例は日増しに増加• HDDレコーダーの踏み台化は情報家電に対する初期の攻撃事例

（2004年）• 心臓ペースメーカの不正操作（2013年）• Jeepを車載のインフォメーションシステムを経由してインターネットから操作

できる研究（2013年）• スマホでATMから現金を引き出すウイルス（2014年）• Black Hat

• HW／組込み，IoT，スマートグリッド／インダストリ・IoT関連テーマがカテゴリに登場

→IoTハッキング技術を身につけ，実践をはじめるハッカーが増加 8

IoTセキュリティの課題

9

• 業界，製品・システムごとに要件が異なるため，セキュリティの対応レベルが異なり，標準化の動向も異なっている

• 対象が情報だけでなく，実体を伴うモノになるため．与える被害も致命的であり，攻撃の被害は甚大にならざるを得ない→IoTセキュリティの確保は重大事

• IoTセキュリティの対象となる機器やシステムに対する脅威には盗聴や不正アクセスによる情報漏えいやプライバシー侵害，データやソフトウェア改ざんによる誤動作や予期せぬ停止など，様々なものが想定される

• 事故の発生や顧客の信頼失墜，機器交換・システム改修コストなど多大な損害も懸念

• IoTのセキュリティを確保するための技術や手法，標準，基準はまだ確立されていない（脅威となる対象の洗い出し・目標を設定するセキュリティ要求分析手法・リスク評価の手法，要件を可視化する技術が必要）

10

システム内ソフトウェアの中に脅威への対抗手段を含めることがより根本的な対策になりうるから

より巧妙化する脅威に対して，より安全なソフトウェアを開発するにはどうしたらよいか？

開発者に対する教育と訓練

経験の伝達

プロジェクト管理の徹底

運用管理の向上

セキュリティ方針の厳密化

開発方法論・プロセス

解決方法

セキュリティ by デザイン

安全なシステム・ソフトウェアの開発

11

セーフティよりセキュリティの方が重要である。

○か×か？

12

答えは

13

セーフティとセキュリティは両輪の輪!!どちらも大事です。ただし要件が相反することもあるので注意が必要です。

上流工程でのセキュリティ設計

上流の段階におけるセキュリティ設計の手法がセーフティ設計と比較して普及していない

要件定義

システム設計

運用テスト

システムテスト

プログラミング

ソフトウェアテストソフトウェア設計

検証

検証

検証

セーフティとセキュリティの設計（アーキテクチャ設計）

システム化の方向性・システム化計画運用・評価セーフティとセキュリティの

コンセプトの策定及び周知

リスク分析、評価及びリスク低減策検討（セーフティとセキュリティの要件定義）

セーフティとセキュリティの設計（ソフトウェア設計）

信頼性の高いソフトウェアの実装

セーフティとセキュリティの設計プロセスＶ字開発モデル

評価

運用段階で脆弱性が発見されると機器の交換、システムの改修が必要となるため、設計・開発段階と比べ、膨大なコストがかかる。

→上流工程でのセキュリティ対応が重要！！

セキュリティコンセプトの策定

利用者（調達者） VS問題点

開発者（ベンダー）

一般の機能要求

・スピード（早く）・費用（安く）・品質（良いものを）・使いやすく

変換時にギャップ

・仕様の固まり具合・利害関係者の合意・ＩＴ技術・方式・ｽｷﾙ・再利用

セキュリティ要求

・セキュリティは難しいので任せるが費用がかかるのは困る・特別な要求はないけど、個人情報漏えいは困る・内部統制も一緒に考えてほしい・社内の犯行は想定外

更に大きなギャップ

・リスクの洗い出しに漏れはないか不明・各工程ごとに何をどこまでやればいいのかわからない・新たな脅威への対処は現行の設計では無理・リスク対策の費用をお客様は負担してくれない

セキュリティ機能は非機能要件であり、お客様に納得していただき、ギャップを埋めるのは難しい 15

セキュリティ要求分析の特徴

16

• セキュリティ特有の課題：攻撃者の存在

• 攻撃：脅威を意図的に実現する手段

• 一般的な要求分析：ステークホルダ（利害関係者）の意図をシステムにより実現するのが目的。攻撃者の意図に対しては、逆に妨害することが目的

• セキュリティ要求分析：顧客は要求に基づく機能要件の分析に加えて攻撃者の存在を考慮した非機能要件の分析を必要とする．そこでセキュリティ要求はアセットに対する脅威とその対策の記述が必須となる

セキュリティ要求分析プロセス

どのような脅威が想定されるかを洗い出し、各々の脅威に対して適切な対策方針を検討する。1．分析範囲の決定 2．関係者の決定 3．保護すべき資産の抽出

4．前提条件の検討 5．脅威の洗い出し 6．対策方針の検討脅威の特定・分析手法・ＳＴＲＩＤＥ・ミスユースケース・Attack Tree

脅威に対するリスクの見積もり及び評価・ハザード分析手法を利用したリスク評価・CVSS

・ｉ＊（ＬＩＵ法）・ＳＡＲＭ

18

ＳＴＲＩＤＥ：マイクロソフトが定義する脅威モデル。アプリケーションに対するセキュリティ上の脅威の分類名の頭文字から成る語。アプリケーションの脆弱性や未知の攻撃のタイプを理解するために脅威を 6つのカテゴリに分類

Ｓ Spoofing identity

なりすましコンピュータに対し、他のユーザーを装うこと。なりすましにより、攻撃者は不法にアクセスを行い、ユーザー名やパスワードなど、他のユーザーの認証情報を使用する

Ｔ Tampering 改ざんデータを意図的に操作すること。データベースに保持されている永続データを承認を受けずに変更したり、インターネットなどのオープンなネットワークを介してコンピュータ間で伝送されるデータを改ざんすることなど

Ｒ Repudiation 否認ユーザーがあるアクションを行ったこと否認し、相手はこのアクションを証明する方法がないこと。禁止された操作をトレースする能力がないシステムで、ユーザーが不法な操作を行うことなど

Ｉ Information Disclosure

情報の暴露アクセス権限を持たない個人に情報が公開されること。アクセスを許可されていないファイルを読むことができたり、侵入者がコンピュータ間で伝送されているデータを読むことができる場合など

Ｄ Denial of Service

サービス不能攻撃により正規のユーザーへのサービスが中断される。Web サーバーを一時的に使用できない状態にするなどがDoS攻撃。

Ｅ Elevation of Privilege

権限の昇格権限のないユーザーがアクセス権限を得ること。システム全体を使用不可にしたり、破壊するために十分なアクセス権限を得ること。

脅威の特定・分析手法(1)

19


ミスユースケース：ユースケースに攻撃者を追加したミスユースケース図を作成し、攻撃者が対象の機器やシステムに対して攻撃する目的や得ようとする利益を想定することで、脅威を特定する手法

20


Attack Tree：攻撃者のゴールを設定し、ゴールに至る攻撃手順をツリー上に展開することで脅威分析を行う手法

攻撃者の目標（ゴール）

手法1 手法2 手法3

手法2-1 手法2-2

最初の手順

次の手順

その次の手順手法2-2-1

攻撃者の手順にそって上からツリーを記述

脅威に対するリスクの見積もり及び評価(1)

ハザード分析手法を利用したリスク評価：ＦＴA、FＭＥＡ、HAZOPなどのセーフティ手法の利用

金融証券会社のシステム Potential

Failure Mode and Effects Analysis

(Design FMEA)

Key Date 2008/10/26

潜在的故障モード潜在的故障影響

S

e

v

潜在的故障原因・

メカニズム

P

r

o

b

現在の設計・

工程管理予防・

検出

D

e

t

R

P

N

推奨処置

口座登録情報の漏

えい

不正アクセスの発生 4 保護されていないデータパケットは途

中で傍聴されて変更される4 重要なデータの保護、保護した

データの安全な伝送4 64 ①ハッシュとデジタル署名を使用して

暗号化する

②ＳＳＬ／ＴＬＳやＩＰｓｅｃなどの安全な

エンドツーエンドプロトコルの使用

口座登録情報の漏

えい

不正アクセスの発生 4 保護されていないデータパケットは途



暗号化する



注文情報の改竄誤った注文による損失 6 保護されていないデータパケットは途



暗号化する



なりすましによる誤

注文

悪意の攻撃者がパスワー

ドを盗用して、ユーザーに

なりすます

8 ユーザの認証シーケンスを盗用した

り、再現することで、なりすまし攻撃を

行う

8 強力な認証手段を使用すること 4 256 kerberos認証やクライアント認証証明

書の使用

仲買人・管理人へ

の権限昇格

アプリケーションやデータ

の中でユーザがアクセスで

きない部分への特権アクセ

スをユーザが取得してしま

う

8 攻撃者がバッファオーバフローの脆

弱性等を利用してアプリケーションと

同じセキュリティコンテキストで有害な

コードを実行する可能性がある

6 アプリケーションはできる限り低い

セキュリティコンテキストで動作す

るようにしておく必要がある。

6 288 バッファオーバーフローが発生する

のを防ぐ

商品注文への否認ユーザが商品注文を否認

し、利益が下がる6 ユーザが注文した商品を否認するこ

とで、虚偽に利益を得ようとする。4 権限のないユーザに今後は行わ

せたくない行動を記録しておく。4 96 デジタル署名とタイムスタンプの使用

システムへのＤｏｓ攻

撃等

正当なサービス要求を処

理できなくなるほど大量の

トラフィックをシステム上に

発生させる。

10 TCP/IP プロトコルの欠点を利用し

たり、オペレーティングシステムにお

ける TCP/IP の実装のバグを突い

たりする方法を取る

8 DoS 攻撃は撃退することが困難

なだけでなく、予測することさえ困

難。更にDoS 攻撃は簡単に実行

可能。

10 800 ファイアウォールを使用してパケットの

フィルタ処理を行い、正当なパケットと

有害なパケットを分離する

21


CVSS(Common Vulnerability Scoring System):

共通脆弱性評価システム CVSS は、情報システムの脆弱性に対するオープンで汎用的な評価手法｡ベンダーに依存しない共通の評価方法を提供。CVSSを用いると、脆弱性の深刻度を同一の基準の下で定量的に比較できる｡ベンダー、セキュリティ専門家、管理者、ユーザ等の間で、脆弱性に関して共通の言葉で議論できる｡

CVSSv2は、攻撃対象となるホストやシステムにおいての「脆弱性による深刻度」を評価｡CVSSv3では、仮想化やサンドボックス化などが進んできていることから、コンポーネント単位で評価する手法を取り込んだ仕様｡IPA資料 CVSSとは？より

22

23

ｉ＊（ＬＩＵ法）：ゴール指向要求分析手法のひとつであるi*（アイスター）手法を拡張したセキュリティ要求分析手法。通常のアクターおよびゴールの特定に加えて、悪意のあるアクターおよびゴールも特定することで、セキュリティ攻撃方法と対策を特定する。

なりすましによる不正注文のｉ＊（ＬＩＵ法）図



24

一般者Ａ一般者Ｂ攻撃者C

一般者Ａ ○Gab,Gac

◇

□ -

☆Iab

◇

□

☆Ic

◇

□ --

一般者Ｂ ☆Iba

◇

□

○Gba,Gbc

◇

□

☆Ibc

◇

□ --

攻撃者Ｃ ★Ica

◆

→ ++対策：A

★cb

◆

→ +対策：B

● Gca,

Gcb

◆

→対策：C攻撃者に対する対策案の特定を行い、ユーザに

提示する

&◆&◆｜◆

他者に対する攻撃者のタスクを挙げる

攻撃者、悪意、攻撃方法、脆弱性の特定を行う

＜一般者のマーク＞

○：期待としてのゴール

☆：ソフトゴール

◇：タスク、機能

□：資源情報

＜攻撃者のマーク＞

●：攻撃者の期待としてのゴール

★：攻撃者のソフトゴール

◆：攻撃者のタスク、機能

■：攻撃者の資源情報

<論理関係性のマーク＞

＆：論理積（and）

｜：論理和(or)

アクタ関係表に基づくセキュリティ要求分析手法（ＳＡＲＭ）:攻撃と通常のシステム機能との間のセキュリティ上の関係を分析するための要求分析手法＊一般者（アクタ）を機器に置き換えると複数機器の相互作用分析に応用可能。

一般者Ａのゴール（対角要素）

一般者Ｂの一般者Ａへのゴール（非対角要素）

セキュア・プログラミング

IPA資料セキュア・プログラミング講座より

Webアプリケーションの脆弱性対策にはさまざまなものがあり、実装段階で考慮すれば済むものもあれば、設計の上流段階から考慮したほうがよいものもある。

目に見えないものであるソフトウェアに対し，理論的な論理関係と根拠を示すことによって品質説明力を強化し，お客様の納得を得ることでお客様と合意した内容について保証が必要

セキュリティ機能へのお客様の納得←セキュリティ機能の品質説明力の強化

ソフトウェア＝目に見えないもの

ソフトウェアの品質保証→困難（なぜならばどのような機能をどのように実現して、それがどのような投資効果をもつのかを示す必要がある）

情報セキュリティと保証②（品質説明力の強化）

理論的な論理関係と根拠を示すアシュアランスケース

（Assurance Case）の保証

26

ロジカルな設計品質の説明(1)

情報セキュリティに関する品質保証→より困難（新たな脅威がどのように発生するか予測不可能なため）

アシュアランスケースの表記法アシュアランスケースを表記するときに基本ルールを説明します。

主張

主張

説明

主張

主張

説明

主張

主張前提

証拠証拠

主張

未定義要素

主張

証拠

主張

説明

説明

主張

主張

未定義要素

主張前提説明前提

参考：松野、高井、山本「D-Case入門～ディペンダビリティ・ケースを書いてみよう！～」

アシュアランスケースの表記法

主張

証拠

主張

説明

説明

主張

主張

未定義要素

主張前提説明前提


「主張」は「説明」を用いて、下位の「主張」に展開することができます。

木構造を用いてシステムが満たすべき「主張」が最下位の「証拠」と「前提」によって成立することを確認します。なお、最下位が「未定義要素」となるときもあります。

矢印は「」と「」の2種類あります。前提は主張または説明に付与されます

主張

主張

説明

主張

（例）

主張

説明

主張

主張前提

証拠証拠

主張

未定義要素

（例）

（例）

29

•主張（ゴール）はS + Vの形をした、命題である–システムはディペンダブルである–ゴールは命令であったり挨拶などではない•×プログラムを実行せよ, ×こんにちは…

•説明（戦略）はゴールをサブゴールに分割するときの議論の仕方を説明する–識別されたハザードごとに議論する, ライフサイクルフェーズごとに議論する, …

•証拠は物 (ドキュメント)であり、文章ではない。証拠はゴールを最終的に論拠付けるものである

–テスト結果, 専門家の意見, 運用訓練結果, …

•前提はシステム運用環境、定義などをゴールまたは戦略を議論する上での前提となる情報

–例：運用環境、リスクのリスト、システム構造、ディペンダビリティ要求リスト, 語彙の定義–前提はそれが付与されたゴールや戦略以下のサブツリー全体にかかる

記述基本規則

アシュアランスケースの表記法【例題】間違った表記について指摘してください。

参考：松野、高井、山本「D-Case入門～ディペンダビリティ・ケースを書いてみよう！～」」


～解答～





～解答～





～解答～



主張と証拠より

アシュアランスケースの表記法～解答～


「保証」を英語でいうと何？

assurance「製品が品質基準に合致しているかを、設計・試作・製造・検査の全ての工程で確認する仕組みがあり、それを実行していることを保証する、請合う、自信をもって言うこと」

warranty「出荷後製品が故障したら，無料で修理又は取り替えをする事を利用者に対して保証すること」

guarantee 「もし保証したことが出来なければ、賠償責任が生じるような保証」

38

セキュリティ設計の評価・認証(1)

情報セキュリティとは「正当な権限をもつ個人や組織が、情報を適切に管理できる」こと

個人情報や機密情報を防露されたり、システムの稼働を妨害されたりすることがないように、情報を管理する機能=情報セキュリティ機能

情報セキュリティ機能の確からしさを確保するのがセキュリティ保証：セキュリティ機能が正確に動作し、有効に機能することの保証

利用者は一般のＩＴ機能については、実際に利用してみることで保証されていることを確認できる

セキュリティ機能には以下が要求される動作しないことはない不当な干渉をうけることはない動作不能に陥ることはない

利用者が不測の事態を発生させてセキュリティ機能が正確かつ有効に動くことを確認することは困難

開発者がセキュリティ保証を検証しなければならない

？

確認可能

一般のＩＴ機能

セキュリティ機能

このセキュリティ保証を確認するのが、セキュリティ評価（by第三者）

セキュリティ評価の国際規格コモンクライテリア（ＣＣ）の保証

情報セキュリティと保証①（規格準拠）

39


ST概説適合性主張セキュリティ課題定義

脅威組織のセキュリティ方針前提条件

セキュリティ対策方針TOEのセキュリティ対策方針運用環境のセキュリティ対策方針セキュリティ対策

拡張コンポーネント定義

セキュリティ要件セキュリティ機能要件セキュリティ要件根拠セキュリティ保証要件

TOE要約仕様

コモンクライテリア（ＣＣ）とは？ＣＣパート１概説と一般モデルセキュリティ目標（ＳＴ）

ＣＣパート２機能コンポーネント

ＣＣパート３保証コンポーネント

ＣＥＭ情報セキュリティ評価方法

ＣＣﾊﾟｰﾄ３（ＥＡＬ保証要件）

ＣＣﾊﾟｰﾄ２（セキュリティ機能要件）

プロテクションプロフェイル（ＰＰ）

CCはITセキュリティ評価の国際標準（ISO/IEC15408）

•開発者が主張するセキュリティ保証の信頼性に関する評価の枠組みを規定

STはセキュリティ保証の目標を規定した文書•評価対象のシステムが装備するセキュリティ機能を定義•必須のセキュリティ評価対象

40


コモンクライテリアにおけるセキュリティ機能の評価保証レベル：ＥＡＬ（保証要求内容）想定されるセキュリティ保証レベル

EAL1（機能テスト）クローズドな環境での運用を前提に安全な利用や運用が保証された場合に用いられる製品の保証レベル

EAL2（構造化テスト）利用者や開発者が限定されており、安全な運用を脅かす重大な脅威が存在しない場合に用いられる保証レベル

EAL3（方式的テスト及びチェック）

不特定な利用者が利用できる環境、不正対策が要求される場合に用いられる製品の保証レベル

EAL4（方式的設計、テスト及びレビュー）

商用機器やシステムにおいて高度なセキュリティ確保を実現するために、セキュリティを考慮した開発と生産ラインを導入して生産される製品の保証レベル

EAL5（準形式的設計及びテスト）

特定の分野の商用製品・システムにおいて、最大限のセキュリティ確保をするためにセキュリティの専門家の支援により開発、生産された製品の保証レベル

EAL6（準形式検証済み設計及びテスト）

重大なリスクに対応して高い価値のある資産を保護するために、開発環境にセキュリティ工学技術を適用して開発された特別性の製品の保証レベル

EAL7（形式的検証済み設計及びテスト）

非常にリスクが大きい環境や高い開発費用に見合う資産を保護するために開発された製品の保証レベル

セキュリティレベルの指標

42

コモンクライテリア（ＣＣ）のITセキュリティ評価における相互認証国は１２か国である。

○か×か？

43

答えは（25か国）

トルコ

オランダ

フランス日本

アメリカイギリス

ドイツ

ノルウェー

ニュージーランド

カナダ

韓国スペイン

イタリアスウェーデン

オーストラリア

マレーシア

インド認証書生成国：17か国

ギリシャイスラエルオーストリア

ハンガリー

フィンランド

デンマークチェコパキスタン

認証書受入国：8カ国

＊シンガポールは6月19日に加盟を自主的に取り止め。

• セキュリティ評価における相互認証を実現（CCRA）

– ある国が、ISO/IEC15408の認証を与えた製品については、他の国でも同じレベルで通用する主旨の協定。

– 評価・認証にかかるコストを削減することがねらい。

認証国 : 自国に認証制度を持つ国々認証受入国 : 自国に認証制度を持たない国々

CCRA(Common Criteria Recognition Arrangement)

44

CC-Caseとは？

45

CC-Caseの定義 CC-Caseの目的

セキュリティ要求分析と保証の統合開発方法論

開発のセキュリティ上の課題を解決するため、セキュアなシステム開発への対応を実施すること

CCとアシュアランスケースの長所を統合したセキュリティ要求分析手法かつ保証手法

＜構造・適用対象＞論理モデルと具体モデルに分類される

適用対象はシステムまたは製品。仕様を決める際に承認を取る特定の顧客がいない場合は要件を決めるうえでの関係者と読み替える．

IoTセキュリティ認証に対するCC-Caseの特長

1. 主張の見える化：ゴールとしての主張とその主張の正しさを裏付ける証跡が存在すること

• GSNはトップゴールの主張を満たすことを図の最下層に証跡として示すことで可視化する手法だから

2.論理の見える化：前提条件・戦略・ゴールの関係性の明示により，トップの主張から証跡までの論理が明確化されること

• IoT対応に際しては当該製品の技術分野に適したPPを利用して当該製品のセキュリティ機能の論理を見える化し，証跡としてセキュリティ仕様を提示する

3.保証ストーリーの見える化：アシュアランスケースの論理モデル（プロセスと実施事項の明確化）による可視化

• CCに規定されたセキュリティ保証要件に対応し，セキュリティ機能に対してどのレベルまでの対応が達成できているのかを提示して保証

CC-Caseは３つの見える化の特長をもつ．

スマートハウス：家庭内機器を一元管理することによって、省エネルギーを実現するIoT システム

スマートハウスの脅威分析と対策の検討例

脅威対策候補

発生箇所脅威名対策名他のガイドとの関係

OTA OWASP

スマートハウス（屋内）

HEMS

コントローラウイルス感染脆弱性対策 OTA4,OTA5

アンチウイルス

ソフトウェア署名 OTA6 OWASP9

セキュア開発 OTA7

ホームルータ不正アクセス脆弱性対策 OTA5

ユーザ認証 OTA11,OTA12,OTA1

3,OTA14

OWASP2,OWASP8

FW機能 OWASP3

DoS攻撃 DoS対策 OWASP3

無線通信（特定小電力、

WiSUN、Wi-Fi）

盗聴・改ざん通信路暗号化 OTA1 OWASP8

タブレット端末不正利用ユーザ認証 OTA11,OTA12,OTA1

3,OTA14

OWASP2,OWASP8

遠隔ロック

ウイルス感染脆弱性対策 OTA4,OTA5

アンチウイルス

ソフトウェア署名 OTA6 OWASP9

セキュア開発 OTA7

Goal: G_1

スマートハウスのセキュリティ設計は安全である

Strategy: S_1

脅威分析の洗い出しと対策を示す

Context: C_1

スマートハウス分野の動向・特徴全体構成図

Goal: G_2

スマートハウスの脅威分析は妥当である

S_2 スマートハウスの機器ごとに脅威を洗い出す

G_4

屋内のHEMSコン

ロトーラの脅威を洗い出せている

G_5

屋内のホームルータの脅威を洗い出せている

G_9

無線通信（特定小電力、WiSUN、Wifi）の脅威を洗い出せている

G_6

屋外の

タブレット端末の脅威を洗い出せている

G_7

屋外の

スマートメータの脅威を洗い出せている

G_8

ユーザのスマートフォンの脅威を洗い出せている

S_3 機器間の通信ごとに脅威を洗い出す

G_10

モバイル通信（LTE

等）の脅威を洗い出せている

G_11

クラウドサービスの脅威を洗い出せている

E_1

ウイルス感染

E_2

①不正アクセス②Dos攻撃

E_6

盗聴改ざん

E_7

盗聴改ざん

E_8

①不正アクセス②Dos攻撃③情報漏えい

E_4

①不正アクセス②情報漏えい

E_5

①不正利用②ウィルス感染

E_3

①不正利用②ウィルス感染

Goal: G_3

スマートハウスの脅威に対する対策立案と選択は妥当である

Goal: G_3

スマートハウスの脅威に対する対策立案と選択は妥当である

S_4 対策ごとに分けて論証する

G_12

ウイルス感染対策は妥当である

G_13

不正アクセス対策は妥当である

G_17

盗聴・改ざん対策は妥当である

G_14

Dos攻撃

対策は妥当である

G_15

不正利用対策は妥当である

G_16情報

漏えい対策は妥当である

S_5対策選択に合意する

G_18

選択された対策が妥当である

G_19

残存リスクが妥当である

E_7

選択対策への承認結果

E_8

残存リスク一覧

E_3

Dos対策の実施方法

E_1

脆弱性対策アンチウイルスソフトウェア署名セキュリティ開発の実施方法

E_2

脆弱性対策ユーザ認証FW機能＊IDS/IPS/

サーバセキュリティ（クラウドサービスの場合）の実施方法

E_4

ユーザ認証遠隔ロックの実施方法

E_45

データ暗号化出荷時状態リセットセキュア消去耐タンパH/W

耐アンパS/W

の実施方法

E_6

通信路暗号化の実施方法

S_6 残存リスクを影響分析する

Ｔｈａｎｋｙｏｕ

Ｄａｎｋｅ

Documents

PowerPoint プレゼンテーションIoTの特徴 4 4 IoT：モノのインターネット BInternet of Things C IoTの特徴：⧨ な⦔器・システムがつながること →より