IoT脅威分析チュートリアル

2016/11/16

情報セキュリティ大学院大学

大久保 隆夫

本日の内容

• 脅威分析法

• IoT、組み込み向け脅威分析のチュートリアル

2

講師紹介

• 大久保 隆夫

• 情報セキュリティ大学院大学

情報セキュリティ研究科 教授

• (株)富士通研究所 (〜2013)

• 専門

– セキュリティ・バイ・デザイン

– システムセキュリティ

• aviation security研究会幹事

• 東京オリンピック・パラリンピックに向けた交通機関へのサイバーテロ対策に関する調査研究」検討委員会

航空ワーキンググループ主査

• 脅威分析(脅威分析研究会SIGSTA)幹事)

3

ご参考

• 情報処理学会誌 2016年7月号

• 小特集「乗り物の情報セキュリティと安全性」 – 情報セキュリティと乗り物

大久保 隆夫

– セーフティとセキュリティ

大久保 隆夫

– 車載機器のセキュリティと安全性

倉地 亮、松原 豊、高田 広章(名古屋大)

– 鉄道のセキュリティと安全性

森 崇、谷田部 俊介(JR西日本)

– 乗り物のハッキングと安全性

堀合 啓一(FSI)

4

セキュリティ・バイ・デザイン

5

セキュリティ・バイ・デザインとは

• ソフトウェアやシステム開発の課程で

開発の早期段階(分析、設計)からセキュリティを作りこむ

• 対義語？ セキュアプログラミング

プログラミング工程での脆弱性排除

6

セキュリティ・バイ・デザインの

必要性(1) • ソフトウェア、システム開発における一般的法則

問題解決が後工程になるほど、解決コストが急激に増大

• プログラミングやテストで見つかった問題を修正するのには、費用、工数がかかる

場合によっては、修正不可能な場合も

設計にまだ遡らなければならない場合も

要件定義 設計 プログラム 開発

結合 テスト

受入 テスト

運用

相対修正コスト

7

セキュリティ・バイ・デザインの必要性(2)

8

要件定義 設計 プログラム 開発

結合 テスト

受入 テスト

運用

相対修正コスト

早ければ早いセキュリティ対策ほど

コストがかからない！

セキュリティ要求分析

セキュリティ要求分析=セキュリティ要求仕様の策定

整理する要素

• 資産

– 何を守るべきか

– 個人情報データ、パスワード、重要な機能etc

• セキュリティゴール

– 資産をどう守るかの目標

– 機密性，完全性，可用性などのセキュリティ特性の観点で規定

• セキュリティ上のリスク

– 対策しない場合のリスクを明確化

• セキュリティ要求

– リスクとその脅威にどのような対策を行い，セキュリティゴールを達成すべきかをセキュリティ要求として明確に

• セキュリティ機能要求

– 認証や，暗号化などのセキュリティの機能を明確に

9

セキュリティ要求分析技術

• 故障木分析(FTA)

• FMEA

• ゴール指向(KAOS)の応用

• エージェント指向の応用

• UMLの応用

– ミスユースケース

10

ゴール指向分析

• ゴール(目標)を詳細化することで要求を的確に獲得

• KAOS • まずトップレベルのゴールを决め、順に詳細化する（サブゴール）

• サブゴールどうしと上位ゴールはAND/OR

関係で連結

11

KAOS

• 要求工学的手法の中では、わりと使われている方

• 後述のエージェント指向的手法にも関連

• 応用としては、形式検証など

12

KAOSによるゴールモデル(例)

学生にもっと来てほしい！

来てくれる学生の傾向を

分析したい

説明会の効果を知りたい 学生候補の属性を知りたい

説明会の参加履歴を知りたい

学生候補にコンタクトしたい

13

ゴール指向のセキュリティへの応用

• 脅威をKAOSで分析

–脅威に相当するゴールモデル

⇒その手段、要因を詳細に分析していく

• 反(anti) モデル

–セキュリティゴールが達成できなくなる条件を，障害分析のトップゴールとする

–障害を達成するサブゴールを導出

• 分析には、特殊な(セキュリティ)知識が必要

14

ゴール指向のセキュリティ応用の例

15

サービスを妨害する

DDoS攻撃

攻撃に使う機器を乗っ取る 攻撃機器を調達

管理者になりすまし

DoS攻撃

バッファオーバーフロー

脅威分析

16

脅威分析とは

• 対象のソフトウェアやシステムに対する脅威を識別し、その影響を評価し、対策を策定する

分析

• 「脅威」が、第三者の悪意に基づくため、このような(通常の開発にはない)分析が必要

• 分析工程における脅威分析

=セキュリティ要求工学

• 設計工程における脅威分析

17

脅威分析の手順

1. 資産の識別

2. セキュリティ目標の設定

3. 脅威の識別

4. 脅威の評価

5. 対策設計

18

脅威モデリング

• 設計したシステムにおける脅威分析(脅威の抽出、評価)を行う手法

– Data Flow Diagram(DFD)を用いた脅威抽出

– STRIDEによる脅威分類

– Attack treeによる脅威評価

• アーキテクチャが明確なとき、脅威抽出の手法としては有効

19

DFD

20

出典：文献[Swiderski05]

STRIDE

• Spoofing(なりすまし)

• Tampering(改竄)

• Repudiation(否認)

• Information disclosure(情報の漏洩)

• Denial of service (DoS攻撃)

• Elevation of privilege(権限昇格)

21

Attack Treeとは

• 脅威分析手法の一つ

• 脅威をTree状に詳細化していく

–具体的な攻撃手段とその可能性を明確化

–⇒対策の糸口

• 原典 – [SCH99] B. Schneier, “Attack trees: modeling security

threats,” Dr. Dobb’s Journal, December 1999.

– [MEL01] B A. P. Moore, R. J. Ellison, and R. C. Linger,

“Attack modeling for information security and

survivability,” CMU/SEI-2001-TN-001, March 2001.

Attack Tree

• rootのattack treeを詳細化

• ANDとORがある

[SCH99]では、

ANDの場合のみ

記載(デフォルトは

OR)

出典:[SCH99]

Attack Treeの課題

• 共通のノードが出現⇒”tree”ではなくなる

• 網羅性の確認

• 攻撃の導出→ライブラリ、パターンとの対応

アーキテクチャとの対応

例:オンラインバンク

• インターネット経由で口座所有者が自身の口座にアクセス

• 何が脅威？

25

脅威の識別(1)

• データフロー(データの流れ)を書いてみる

26

ブラウザ オンラインバンク

残高情報

送金

脅威の識別(2)

• 信頼境界を設定する

27

ブラウザ オンラインバンク

残高情報

送金

脅威の識別(3)

• 攻撃ポイント(エントリポイント)を識別する

28

ブラウザ オンラインバンク

残高情報

送金

脅威の識別(4)

• エントリポイントで起きる脅威を考える

29

ブラウザ オンラインバンク

残高情報

送金

漏洩？

改ざん？

脅威評価(1)

• 脅威の細分化:具体的条件、攻撃手段の検証

30

Attack tree

31

なりすまし

される

ID、パスワードが盗まれる

IDが盗まれる パスワードが盗まれる

パスワードを推測される

パスワード盗聴

AND

総当たり

セーフティとセキュリティを考慮した分析

32

IoT、組込みにおける「安全」を考える

• ITと同様の考え方でできるものもある

– Webサーバが組込まれた機器

Webカメラ、ルータetc.

• 「セーフティ」を考慮しなければならないものも

–機械の無故障、人命の安全、事故防止etc.

–家電(エアコン、冷蔵庫)

–交通系(車、鉄道、航空)

–制御系(エレベータ等)

33

セーフティとセキュリティの

相違(私見)

• セーフティ:物理的な安全、人命等の安全に関するもの

• セキュリティ:第三者による意図的な攻撃/脅威から守ることに関するもの

• つまり、両者は背反ではなく、定義のベクトルが違う

34

機器の安全

人命

事故防止

機密性

完全性

可用性

セーフティ セキュリティ

35

セーフティ セキュリティ

衝突安全

自動ブレーキ

ブレーキ踏んでないと

発進しない

位置情報を盗まれない

ナビ情報を

改竄されない

36

セーフティ分析とセキュリティ

分析の相違

• 守る対象の観点

• 脅威の見つけ方

• リスク評価の手法

• 対策

• (規格/標準の差異)

37

守る対象

• 情報セキュリティの守る対象

=「情報資産」情報やデータ、サービス等が中心

– IT系だとPL法を意識してない場合もほとんど

–乗り物では物理、人命は考慮せざるをえない

• セーフティ系の対象

–情報の保護は主目的ではないが…？

–情報保護の不備により、安全性に危険を及ぼす可能性も

38

脅威の見つけ方

• セキュリティの他の要求との違い(難しさ)

–要求策定者、利害関係者(ステークホルダー)ではない他者(悪意を持つ者)の要求に基づく

–特定の攻撃に対する対策を考慮した要求が必要(になる場合あり)

• 脅威(攻撃)に対する対策仕様≒セキュリティ要求仕様

• セーフティでこのような脅威が抽出できるか？

39

脅威の識別

attack tree法

• 脅威分析手法の一つ

• 脅威をTree状に詳細化していく

–具体的な攻撃手段とその可能性を明確化

–⇒対策の糸口

• 原典 – [SCH99] B. Schneier, “Attack trees: modeling security

threats,” Dr. Dobb’s Journal, December 1999.

– [MEL01] B A. P. Moore, R. J. Ellison, and R. C. Linger,

“Attack modeling for information security and

survivability,” CMU/SEI-2001-TN-001, March 2001.

40

脅威の識別

• attack treeは結果の整理に使われるもので、実際の脅威の識別には、分析者の専門的知識や経験を要する

• 攻撃ライブラリやパターンをうまく使いたい

41

リスク評価の手法

• 従来のセーフティを対象としたリスク評価

=物理現象、自然災害、ヒューマンエラー、

=蓋然性による確率を用いることが可能

リスク=発生確率×被害の大きさ

• セキュリティ

=第三者の悪意による「人工リスク」 =蓋然性に基づく発生確率の適用が困難

42

セーフティ系で用いられるリスク分析

• FTA(故障の木解析)

• FMEA

• HAZOPなど

43

FTAにおけるリスク評価

• 各葉ノードごとに「故障率」を計算

• 故障率を集計→ルートへ

• 故障率=蓋然性に準拠

• 第三者による恣意的な攻撃=「人工リスク」への適用には注意が必要

44

蓋然性リスクと人工リスク(1)

• FTAにおける多重化(冗長化)の

蓋然性評価

45

ブレーキが故障

ブレーキAが故障 ブレーキBが故障 ブレーキCが故障

故障率0.01 故障率0.01 故障率0.01

故障率=0.01×0.01×0.01

=0.0001

蓋然性リスクと人工リスク(2)

• 悪性ソフトウェアによる人工リスクの評価

46

ソフトが故障

ソフトAが故障 ソフトBが故障 ソフトCが故障

故障率0.01 故障率0.01 故障率0.01

故障率=0.01×0.01×0.01

=0.0001

故障率は0.01

対策

• 機器の制約により、IT系対策では対応できない場合

– 例:車載CAN(64bit)でAES(128bit)のメッセージ認証コードが使えない

• アップデート問題

– 家電感覚では、利用者に適切なアップデートは期待できない→脆弱性(ルータ、カメラetc)

• 機器間認証

– 厳密にすれば、守ることはできるがIoTのメリットは相殺

– 人の不在(M2M)ー何を根拠に認証？

47

IOT的脅威分析手法

48

ポイント

• 資産の識別

• 対象のモデル化

• 脅威の識別、脅威の詳細化

• リスク評価

• 対策

49

資産

• 情報セキュリティ的資産

–情報の機密性

–情報の完全性

–情報、サービスの可用性

• セーフティ的資産

–機器、人体の安全

• 多角的な観点

–他者の資産

乗っ取りにより他者に被害を及ぼす(ボット化)

50

対象のモデル化

• ＩｏＴでは、データの流れが重要なので、DFDによるモデル化は有効

• 注意すべき点

–内部構造の変化→動的なフローの変化

–ストレージの書き換え

–システム外部からのデータは信頼できない

51

脅威の識別

• rootの脅威

– STRIDE

–プラスアルファ(セーフティ的ハザード)

• 詳細化

–攻撃ライブラリ(CAPEC,CWE等)の活用

52

リスク評価、対策

• リスク評価

–人工リスクの扱いに注意

• 対策

–ハードウェア制約(メモリ、帯域等)等を考慮し、対策案を立案

53

まとめ

• IoTの脅威分析は、従来のITにおける手法(attack treeや脅威モデリング)が使えるが、IoT

の特性を考慮した観点も必要

–セーフティ

–ハードウェア特性

–プロトコル

– リスク評価

54