Chapter 17 Bringing Threat Modeling to Your Organization WITZ

(1)

～ Chapter 17 ～

Bringing Threat Modeling to Y

our Organization （後編）

2016 年 09 月 14 日

株式会社ヴィッツ

杉山歩

Threat Modeling _{本勉強}

会

(2)

ESTIC2016 ～ Embedded System Technology and Innovation Conference ～

2

アジェンダ



_…



Threat Modeling within a Development Life Cycle

 Development Process Issues

 Organizational Issues

 Customizing a Process For Your Organization



Overcoming Objections to Threat Modeling

 Resource Objections

 Value Objections

 Objections to the Plan



_Summary

大久保先生の担当箇所大久保先生の

担当箇所

WITZ（杉山）の担当箇所 WITZ（杉山）

の担当箇所

(3)

3



Threat Modeling within a Development Life Cycle

 Organizational Issues （つづき）

(4)

4

Organizational Issues （組織的な課題）

開発ライフサイクルに Threat Modeling を導入するにあた

り，

プロセスではなく、組織的な課題として以下がある．



Thread Modeling を誰がリードするのか？



Thread Modeling を行うためのトレーニング



Modifying Ladders” （スキルレベルの設定）



Threat Modeling を行うためのインタビュー方法

(5)

5

Thread Modeling を誰がリードするのか？

Thread Modeling プロセスを誰の責任でまわすかは，組織に依存する .

 Developer （開発者）

 開発者が多量の技術的情報を保持しており，発言権が強い場合，リーダとして有効である．しかし，“ Creator blindness” と言われる自身が配置した故に気付かない脅威が残ってしまうリスクがある．

 Tester （評価者）

 テスタがプロセスを推し進める技術を保持している場合，リーダとして有効である．※“ Testing and Threat Modeling” の内容と同様．

 Manager （管理者）

 プログラムマネージャ／プログラムマネージャはリーダとして有効である．脅威モデル図や脅威リストは，製品開発のサブタスクとして実行される．

 Security Practitioner （専門家）

 セキュリティの専門家であれば，豊富な経験をもとに脅威の列挙から緩和契約，および，検証までの各プロセスにおいて大いに役に立つだろう．

 Architecture （アーキテクト）

 アーキテクトも十分にプロセスをまわすことができるが開発者と同様に Creator blindness のリスクがある．

(6)

6

Thread Modeling を行うためのトレーニング



_昔から…

 Thread Modeling は師匠から弟子に受け継がれてきた…

⇒ 構造的な教育方法がなく，体験による学習（ OJT ）がメイン．

 師弟制度のメリット／デメリット

 _メリット：弟子が師匠にすぐに質問ができること．

 デメリット：師匠が弟子を見放す場合もある…．

 組織が Thread Modeling の活動を開始すると，各タスクの達成目標が定義される．定義された目標をどのように達成するか？を明確化し，参加者に必要な訓練を受けさせる必要がある．

 プロセスドキュメントに従ったトレーニング

 brown bag lunches （ブレインストーミング）

 正式な教室でのトレーニング

 コンピュータベースのトレーニング

 Elevation of Privilege （←こちらの意味がわかりませんでした）

(7)

7

“Modifying Ladders” （スキルレベルの設定）

 “Ladders” とは，組織内の序列を区別するためのレベルを指す．

例：ジュニアエンジニア ⇒ 一般エンジニア ⇒ シニアエンジニア

 スキルレベルの概念を導入することで， Thread Modeling の際に

「レベルに応じたアウトプット」が期待できるようになる．　⇒ Thread Modeling の計画を立てるのに有効！



スキルレベルの決め方．

 レベル１（大卒直後）～レベル５（トップエンジニア）の５段階

 保有スキルに応じた区別を目指す．例えば STRIDE の記法で脅威モデリングに利用する図が書ければ，レベル○…など．

 担当者に依って，参考情報の選び方，タスクの進め方，成果物の品質などにバラつきがないか？

バラつきがあるなら，それに応じたスキルレベルを設定し，運用しながらリファクタリングしていく必要がある．

(8)

8

Threat Modeling を行うためのインタビュー方法

 Thread Modeling を行うメンバを選定するための面接テクニックを紹介する．ただし，相手が SW エンジニアかオペレータか等に依って，回答が変わってくるため注意が必要．

一般知識

 質問：① Thread Modeling とは？② DFD の長所／短所は？③ STRIDE とは？④脅威“ X” の緩和方法は？⑤あなたはどうやって脅威“ X” を緩和する？

⇒④ は手段を挙げるだけであるのに対して，⑤は制約条件とのトレード

オフを含めて，どのようなセキュリティ対策を選択するか？の質問．

スキルテスト

 実際に DFD を書き，脅威と対策方法を導出してもらう．体験ベースの問診

 質問：①最後に行った Thread Modeling の経験は？②脅威モデリングで検出したバグは？③モデル図の欠落を見つける方法は？④前の Thread M odeling の際にどのようなインタビューを受けた？

⇒ 決まり文句ではなく，相手の実経験を聞き出すため質問を利用する．

(9)

9

Threat Modeling の修養

（ Threat Modeling As a Discipline ）



現在，ソフトウェア品質保証の活動は組織に認められ，

キャリアパスを形成するスキルの１つとされている．

 しかし，品質保証の仕組みが確立する前は，エンジニアが品質を保証するために何をすべきかについて何時間も議論を重ねており，それらが数十年続いた結果として，現在の品質保証に地位がある．



Threat Modeling の活動も同じようにキャリアパスの１つ

となり，組織から報酬を得るための基準となるか？

 Threat Modeling は組織における全ての人が知っているべきスキルではないため，一般的なキャリアパスにはならない（？）

⇒Threat Modeling はキャリアパスの１つにならない！とは

　言っていない．が，専門家が持っているスキルとして，

　専門家のコミュニティの中で Threat Modeling の価値を

　向上させるための提案をしていく必要がある．

　

(10)

10

組織におけるプロセスのカスタマイズ

 組織の標準化アプローチとして Internet Engineering Task Forc e (IETF) がある．※ Chapter 6 で議論済み．

 アプローチの内容は，“ Guidelines for Writing RFC Text on Sec urity Considerations” (Rescorla, 2003) がカバーしている．

⇒ どのように脅威を特定し，どのように脅威に対処し，様々な相手と　どのように通信を行うか…などのアプローチが定義されている．

 Rescorla では， 3 つのセキュリティ特性にフォーカスしている．

特性：①機密性，②データの完全性，③相互認証　 + 可用性

⇒ 「通信チャネルの制御が乗っ取られる」という攻撃を防ぎ，上記の　 3 特性を保護するための緩和策とそれに伴うトレードオフを考える．

 セキュリティの考慮を行うフェーズで，脅威の特定と緩和策を実装者向けの RFC (Request for Comments) としてまとめる．なお，ここには残留脅威、非要件などの定義も必要．

⇒IETF のアプローチは緩和技術を組み立てるアプローチと

して　重要であるため，参考にしましょう！…と書かれてまし

た．

(11)

11



Overcoming Objections to Threat Modeling

 Resource Objections

 Value Objections

 Objections to the Plan

(12)

12

Threat Modeling に対する“不平・不満”の克服

 組織に対して Threat Modeling の導入計画を立案し，それを説明すると，必ずそれに対する不平・不満が出てくる．

 不平・不満の多くは，計画を改善する上に有効に利用できる．また，なるべく多く不満を聞き，計画に支障が出ない範囲でそれを解消することで，彼らの支持を得ることができる．

※ ただし，明らかに計画に対して影響のある様な意見（例えば， Threat Modeling なんてやらなくてもいいんじゃない？）には　ビシっと反論する必要がある．

 具体的に，挙がってきた不平・不満を取り込み，計画を改善する必要がある内容として，代表的なものが以下の３つ．

 リソースの課題（ Resource Objections ）

 バリューの課題（ Value Objections ）

 計画の課題（ Objections to the Plan ）

(13)

13

リソースへの不満（ Resource Objections ）

 計画を立てるにあたり，セキュリティにおけるトレードオフを考慮して，予算とリソースに対して不満が発生する可能性がある多すぎる人々（ Too Many People ）

 Threat Modeling に多くの人が巻き込まれ，多すぎる工数が掛っているケースがある．それに対して，リソース観点での異議，価値観点での異議，および，証明観点での異議を唱えることができる．

多すぎる仕事（ Too Much Work per Person ）

 24 時間のうち、 8 ～ 10 時間を業務時間と想定する．計画ではエンジニアに 1 日の大部分を Threat Modeling に費やして欲しいが，実際には他要素（ security, privacy, usability, reliability, programmability, accessibility, internationalization ）の取り込みに多くの時間がかかっている．これを防ぐために 1 日の作業時間の時間制約を提案し，調整する必要がある．

多すぎる無駄な仕事（ Too Much Busywork/YAGNI ）

 古いアプローチで活動すると，無駄な作業が発生する可能性がある．無駄に対して異議を唱え，アプローチの改善を行う必要がある．

(14)

14

価値への不満（ Value Objections ）

 セキュリティの“良いアイデア”であっても，それが投資に見合う価値（基準）に達していない場合がある．

Threat Modeling をやってみましたが…

 Threat Modeling を試してみたが，費用対効果が恐ろしく低い場合… 失敗例）

そのバグは修正する必要がない

 Threat Modeling により，修正する必要のないバグが数多く見つかる場合，分析アプローチに問題がある．例えば，境界外に対する分析や許容可能な脅威に対する分析を省くことで，効率化が可能！

誰もそんなことはしない…

 そんなこと誰もしないだろう…という脅威への対策を講じるのはムダ． Appendix C の攻撃者リストを見て，妥当な攻撃方法を予測すべき．

 何の訓練もせずに Threat Modeling を実施する．

 実施者に対して矛盾した混乱を招くアドバイスをする．

 システム構成を変更できない（遅すぎる）タイミングで実施する．

 へりくだり過ぎ（遠慮のし過ぎ）で失敗したり，

 結果を見ずに，プロセスにこだわりすぎることで失敗したりする．

やり方の問題実施者の問題

(15)

15

計画への不満（ Objections to the Plan ）

 投資に対して妥当な価値が得られる「だけ」では，足りない場合があるため，組織の状況を考慮した計画の立案が必要！

タイミング

 既に 2 ～ 3 のパイロットプロジェクトが進んでいたり，予算が確定した直後だったり，景気悪化したタイミングでの提案では，承認が下りない．

変更

 個人の振る舞い／組織の振る舞いを変更することは難しい．立案した計画の内容によっては，関連するメンバが変更に対して抵抗する可能性がある．

他のセキュリティ活動

 他の優れたセキュリティ活動に負けない様に， Threat Modeling は，“早く”かつ“安く”バグ修正ができることを強調しなければならない．

エビデンスの質

 計画の妥当性を説明するためのエビデンスを準備しておく必要がある．

ローカルで実施したパイロットプロジェクトの成果などは有効活用できる．

(16)

16

まとめ

 組織に対して新しいプラクティスを導入することは難しいが，その課題を克服して導入されてきた前例があるため，その前例を

「売り」として経営者への説得を試みる必要がある．

 Threat Modeling を導入するにあたり，組織において誰がどの様な役割と責任を持ち，どのように管理を行う課を明確化する．その上で， Threat Modeling の実施に必要なタスクとその成果物，また，利用する技術をまとめ，経営者からの質問に答えていく必要がある．

 Threat Modeling を導入するにあたり，提案者は組織の承認フローを正しく理解した上で，導入に必要な人材の確保から訓練計画，キャリアパスを明確化する．また， Threat Modeling を実際の組織に導入しようとした際に考えられる“不平・不満”を予め想定し，対処するための方法を検討しておかなければならない．

Chapter 17 Bringing Threat Modeling to Your Organization WITZ

～ Chapter 17 ～

Bringing Threat Modeling to Y

our Organization （後編）

2016 年 09 月 14 日

株式会社ヴィッツ

杉山 歩

Threat Modeling 本 勉強

会

アジェンダ

…

Threat Modeling within a Development Life Cycle

Overcoming Objections to Threat Modeling

Summary

Threat Modeling within a Development Life Cycle

Organizational Issues （組織的な課題）

開発ライフサイクルに Threat Modeling を導入するにあた

り，

プロセスではなく、組織的な課題として以下がある．

Thread Modeling を誰がリードするのか？

Thread Modeling を行うためのトレーニング

Modifying Ladders” （スキルレベルの設定）

Threat Modeling を行うためのインタビュー方法

Thread Modeling を誰がリードするのか？

Thread Modeling を行うためのトレーニング

昔から…

“Modifying Ladders” （スキルレベルの設定）

スキルレベルの決め方．

Threat Modeling を行うためのインタビュー方法

Threat Modeling の修養

現在，ソフトウェア品質保証の活動は組織に認められ，

キャリアパスを形成するスキルの１つとされている．

Threat Modeling の活動も同じようにキャリアパスの１つ

となり，組織から報酬を得るための基準となるか？

⇒Threat Modeling はキャリアパスの１つにならない！とは

言っていない．が，専門家が持っているスキルとして，

専門家のコミュニティの中で Threat Modeling の価値を

向上させるための提案をしていく必要がある．

組織におけるプロセスのカスタマイズ

⇒IETF のアプローチは緩和技術を組み立てるアプローチと

して 重要であるため，参考にしましょう！…と書かれてまし

た．

Overcoming Objections to Threat Modeling

Threat Modeling に対する“不平・不満”の克服

リソースへの不満（ Resource Objections ）

価値への不満（ Value Objections ）

計画への不満（ Objections to the Plan ）

まとめ

杉山歩

Threat Modeling _{本勉強}

_…

_Summary

_昔から…

　言っていない．が，専門家が持っているスキルとして，

　専門家のコミュニティの中で Threat Modeling の価値を

　向上させるための提案をしていく必要がある．

して　重要であるため，参考にしましょう！…と書かれてまし