PowerPoint プレゼンテーション

つながる世界のセキュリティ設計入門

～セキュリティ要件の見える化～

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ハッキング技術を身につけ，実践をはじめるハッカーが増加

₈

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

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

ミスユースケース

：

ユースケースに攻撃者を追加したミスユースケース図を作成し、攻撃者

が対象の機器やシステムに対して攻撃する目的や得ようとする利益を

想定することで、脅威を特定する手法

20

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

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 Date2008/10/26 潜 在 的 故 障 モ ード 潜 在 的 故 障 影 響 S e v 潜 在 的 故 障 原 因 ・ メカ ニ ズ ム P r o b 現 在 の 設 計 ・ 工 程 管 理 予 防 ・ 検 出 D e t R P N 推 奨 処 置 口座登録情報の漏 えい 不正アクセスの発生 4 保護されていないデータパケットは途 中で傍聴されて変更される 4 重要なデータの保護、保護した データの安全な伝送 4 64 ①ハッシュとデジタル署名を使用して 暗号化する ②ＳＳＬ／ＴＬＳやＩＰｓｅｃなどの安全な エンドツーエンドプロトコルの使用 口座登録情報の漏 えい 不正アクセスの発生 4 保護されていないデータパケットは途 中で傍聴されて変更される 4 重要なデータの保護、保護した データの安全な伝送 4 64 ①ハッシュとデジタル署名を使用して 暗号化する ②ＳＳＬ／ＴＬＳやＩＰｓｅｃなどの安全な エンドツーエンドプロトコルの使用 注文情報の改竄 誤った注文による損失 6 保護されていないデータパケットは途 中で傍聴されて変更される 4 重要なデータの保護、保護した データの安全な伝送 4 96 ①ハッシュとデジタル署名を使用して 暗号化する ②ＳＳＬ／ＴＬＳやＩＰｓｅｃなどの安全な エンドツーエンドプロトコルの使用 なりすましによる誤 注文 悪意の攻撃者がパスワー ドを盗用して、ユーザーに なりすます 8 ユーザの認証シーケンスを盗用した り、再現することで、なりすまし攻撃を 行う 8 強力な認証手段を使用すること 4 256 kerberos認証やクライアント認証証明 書の使用 仲買人・管理人へ の権限昇格 アプリケーションやデータ の中でユーザがアクセスで きない部分への特権アクセ スをユーザが取得してしま う 8 攻撃者がバッファオーバフローの脆 弱性等を利用してアプリケーションと 同じセキュリティコンテキストで有害な コードを実行する可能性がある 6 アプリケーションはできる限り低い セキュリティコンテキストで動作す るようにしておく必要がある。 6 288 バッファ オーバーフローが発生する のを防ぐ 商品注文への否認 ユーザが商品注文を否認 し、利益が下がる 6 ユーザが注文した商品を否認するこ とで、虚偽に利益を得ようとする。 4 権限のないユーザに今後は行わ せたくない行動を記録しておく。 4 96 デジタル署名とタイムスタンプの使用 システムへのＤｏｓ攻 撃等 正当なサービス要求を処 理できなくなるほど大量の トラフィックをシステム上に 発生させる。 10 T CP /IP プロトコルの欠点を利用し たり、オペレーティング システムにお ける T CP /IP の実装のバグを突い たりする方法を取る 8 DoS 攻撃は撃退することが困難 なだけでなく、予測することさえ困 難。更にDoS 攻撃は簡単に実行 可能。 10 800 ファイアウォールを使用してパケットの フィルタ処理を行い、正当なパケットと 有害なパケットを分離する

21

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

CVSS(Common Vulnerability Scoring System)

:

共通脆弱性評価システム CVSS は、情報システムの脆弱性に対する

オープンで汎用的な評価手法｡ベンダーに依存しない共通の評価方法

を提供。CVSSを用いると、脆弱性の深刻度を同一の基準の下で定

量的に比較できる｡ベンダー、セキュリティ専門家、管理者、ユーザ等の

間で、脆弱性に関して共通の言葉で議論できる｡

CVSSv2は、攻撃対象となるホストや

システムにおいての「脆弱性による深刻

度」を評価｡

CVSSv3では、仮想化やサンドボックス

化などが進んできていることから、コン

ポーネント単位で評価する手法を取り

込んだ仕様｡

_{IPA資料 CVSSとは？より}

22

23

ｉ＊（ＬＩＵ法）

：

ゴール指向要求分析手法のひとつであるi*（アイスター）手法を拡張したセキュリティ

要求分析手法。通常のアクターおよびゴールの特定に加えて、悪意のあるアクター

およびゴールも特定することで、セキュリティ攻撃方法と対策を特定する。

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

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

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

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)

情報セキュリティに関する品質保証→より困難（

新たな脅威がどのように発生するか予測不可能な

ため）

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

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

主張

主張

説明

主張

主張

説明

主張

主張

前提

証拠

証拠

主張

未定義要素

主張

証拠

主張

説明

説明

主張

主張

未定義要素

主張

前提

前提

説明

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

主張

証拠

主張

説明

説明

主張

主張

未定義要素

主張

前提

前提

説明

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

きます。

木構造を用いてシステムが満たすべき「主張」が最下位の「証

拠」と「前提」によって成立することを確認します。なお、最下位

が「未定義要素」となるときもあります。

矢印は「

」と「

」の2種類あります。前提は主張または説

明に付与 されます

主張

主張

説明

主張

（例）

主張

説明

主張

主張

前提

証拠

証拠

主張

未定義要素

（例）

（例）

29

•

主張（ゴール）はS + Vの形をした、命題である

–システムはディペンダブルである

–ゴールは命令であったり挨拶などではない

•×プログラムを実行せよ, ×こんにちは…

•説明（戦略）はゴールをサブゴールに分割するときの議論の仕方を説明する

–識別されたハザードごとに議論する, ライフサイクルフェーズごとに議論する, …

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

である

–

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

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

報

–例：運用環境、リスクのリスト、システム構造、 ディペンダビリティ要求リスト, 語彙の定義

–前提はそれが付与されたゴールや 戦略以下のサブツリー全体にかかる

記述基本規則

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

【

例題】間違った表記について指摘してください。

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

～解答～

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

【例題】間違った表記について指摘してください。

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

～解答～

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

【例題】間違った表記について指摘してください。

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

～解答～

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

【例題】間違った表記について指摘してください。

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

～解答～

「

保証

」を英語でいうと何？

assurance

「製品が品質基準に合致しているかを、設計・試

作・製造・検査の全ての工程で確認する仕組みが

あり、それを実行していることを保証する、請合う、自

信をもって言うこと」

warranty

「出荷後製品が故障したら，無料で修理又は

取り替えをする事を利用者に対して保証するこ

と」

guarantee

「もし保証したことが出来なければ、賠償責任が生

じるような保証」

38

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

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

個人情報や機密情報を防露されたり、システムの稼働を妨害されたり

することがないように、情報を管理する機能=情報セキュリティ機能

情報セキュリティ機能の確からしさを確保するのがセキュリティ保証

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

利用者は一般のＩＴ機能については、

実際に利

用してみること

で保証されていることを

確認できる

セキュリティ機能には以下が要求される

 動作しないことはない

 不当な干渉をうけることはない

 動作不能に陥ることはない

利用者が不測の事態を発生させてセキュリティ機能

が正確かつ有効に動くことを

確認することは困難

開発者がセキュリティ保証を

検証しなければならない

？

確認可能

一般のＩＴ機能

セキュリティ機能

このセキュリティ保証を確認するのが、

セキュリティ評価（by第三者）

セキュリティ評価の国際規格

コモンクライテリア（ＣＣ）の保証

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

39

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

ST概説

適合性主張

セキュリティ課題定義

セキュリティ対策方針

拡張コンポーネント定義

セキュリティ要件

TOE要約仕様

コモンクライテリア（ＣＣ）とは？

 ＣＣパート１ 概説と一般モデル

セキュリティ目標（ＳＴ）

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

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

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

ＣＣﾊﾟｰﾄ３

（ＥＡＬ保

証要件）

ＣＣﾊﾟｰﾄ２

（セキュリティ

機能要件）

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

CCはITセキュリティ評価の国際標準

（ISO/IEC15408）

•開発者が主張する

セキュリティ保証の

信頼性に関する評価の枠組み

を規定

STはセキュリティ保証の目標を規定した文書

•評価対象のシステムが装備するセキュ

リティ機能を定義

•必須のセキュリティ評価対象

40

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

コモンクライテリアにおけるセキュリティ機能の評価保証レベル

：

ＥＡＬ（保証要求内容）

想定されるセキュリティ保証レベル

EAL1（機能テスト）

クローズドな環境での運用を前提に安全な利用や運用が保証された場合に用いられる製

品の保証レベル

EAL2（構造化テスト）

利用者や開発者が限定されており、安全な運用を脅かす重大な脅威が存在しない場合に

用いられる保証レベル

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

ク）

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

証レベル

EAL4（方式的設計、テスト及び

レビュー）

商用機器やシステムにおいて高度なセキュリティ確保を実現するために、セキュリティを考慮し

た開発と生産ラインを導入して生産される製品の保証レベル

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

ト）

特定の分野の商用製品・システムにおいて、最大限のセキュリティ確保をするためにセキュリ

ティの専門家の支援により開発、生産された製品の保証レベル

EAL6（準形式検証済み設計及

びテスト）

重大なリスクに対応して高い価値のある資産を保護するために、開発環境にセキュリティ工

学技術を適用して開発された特別性の製品の保証レベル

EAL7（形式的検証済み設計及

びテスト）

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

の保証レベル

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

42

コモンクライテリア（ＣＣ）のIT

セキュリティ評価における

相互認証国は１２か国である。

43

答えは

トルコ オランダ フランス 日 本 アメリカ イギリス ドイツ ノルウェー ニュージー ランド カナダ 韓 国 スペイン イタリア スウェーデン オーストラリア マレーシア インド

認証書生成国：17 か国

認証書受入国：8カ国

＊シンガポールは6月19日に加盟

を自主的に取り止め。

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

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

旨の協定。

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

認証国 : 自国に認証制度を持つ国々

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

CCRA

(Common Criteria Recognition Arrangement)

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 残存リスク を影響分析する

Ｔｈａｎｋ

ｙｏｕ