18 章 実験的手法
名古屋工業大学
越島研究室
平井 秀和
18 章 チャプターの構成
実験的手法
Looking in the Seams
Intersystem Review
オペレーショナル脅威モデリング
FlipIT
LM キルチェーン
脅威ジェノミクス
Broad Street Taxonomy
敵対型機械学習
誤った脅威モデリング
実験方法
2
Looking in the Seams
Looking in the Seams
システムに関わる組織間で、システムの機能方法につい
て、異なった視点が存在するのであれば、そのシステム
にはバグが存在する可能性がある
Intersystem review
Microsoft は Intersystem review と呼ばれる手法を開発
した（ 2013 ）
本文では、この手法の一般化した手法を紹介している
Intersystem Review
Intersystem Review に関わる組織
開発・実験の部署、セキュリティ専門家、システム間の
連絡窓口
Intersystem Review の手順
各システムにおいて、他のシステムから受信するデータ
を文書化
各システムにおいて、他のシステムに送信するデータを
文書化
（各システムと信頼境界線を含む）システムモデル図を
作成
システム間で会議を実施
4
Intersystem Review
1/4
1. 各システムにおいて、他のシステムから受
信するデータを文書化
データを検証する目的は何か？
考慮されていないユースケースシナリオは何か？
データの受け手が実施すべきデータの検証は何か？（そ
のことは開発者用ドキュメントと任意のサンプルコード
の中に記載されているか？）
インバウンドデータはどれだけの容量、どのようなセ
キュリティ、検証の概念を持っているのか？
考慮すべき例外はあるか？
Intersystem Review
2/4,3/4
2. 各システムにおいて、他のシステムに送信
するデータを文書化
送信するデータの内容、形式、完全性、信頼性は何に
よって保証するのか？
データが持つ目的は何か？
データの受け手が実施すべきデータの検証は何か？その
ことはどこで記されているか？
データの受け手が持つプライバシー、データ保護に関す
る要件は何か？
考慮すべき例外は存在するか？
3. （各システムと信頼境界線を含む）システ
ムモデル図を作成
6
Intersystem Review
4/4
4. システム間で会議を実施
参加者が Intersystem Review を初めて行う場合、会議
の目的を説明
各システムの図とシナリオに関して、議論
各システムが作成した文書と仮説に関して、議論
エラー処理と復旧に関して、議論
信頼境界線で公開されているサービス、インターフェイ
スのバグに関して、レビュー
5. 会議中に特定されたバグの決定モデルを作
成
決定モデルは、（会議に参加していない）他のシステム
間のバグを特定し、対処する際に役立つ
オペレーショナル脅威モデル
FlipIT
攻撃者と防御者がシステムを奪い合うゲーム
目的
相手より長い時間、安いコストでシステムをコントールすること
条件
プレーヤーはいつでも「システムをコントロールする」ことが可能
システムの状態は、「攻撃者によるコントロール」、「防御者によるコント ロール」の二つのみ
「システムをコントロールする」には一定のコストが必要
プレーヤーはリアルタイムでシステムをコントールしているのが自分か、敵か
、分からない
この条件により、プレーヤーが「システムをコントロールする」を実行しても
、自身がシステムをコントールしている可能性があり、その場合はコストの無 駄である
今後 FlipIT はシステムのセキュリティを効率的にモデル化
できる手法になると期待されている
FlipIT の開発者はパスワードを安全に管理する方法を実証
する手段として FlipIT を用いた
https://www.rsaconference.com/writable/presentations/file_upload
/iam-108_juels.pdf
8オペレーショナル脅威モデル
LM キルチェーン
標的型サイバー攻撃のプロセスのモデル
米空軍のキルチェーンを基に、ロッキード・マーチン社が作成した標的
型サイバー攻撃のプロセスモデル (2009)
攻撃プロセスを 7 段階に分類
攻撃プロセス
偵察
標的の分析、特定、選別
武器化
デリバリを行うパッケージに、エクスプロイトとリモートアクセスを行うツー
ルを組み込む
デリバリ
（メール、 Web サイト、 USB を介して）ターゲットにパッケージを送る
エクスプロイト
インストール
標的システムにリモートアクセスツールをインストールする
コマンド＆コントロール (C2)
通信経路を確立し、利用する
目的の実行
防御策
10 http://special.nikkeibp.co.jp/ts/article/ac0g/148622/
オペレーショナル脅威モデル
脅威ジェノミクス
検出されたシステムの変動に基づく、攻撃モデル
キルチェーンでは攻撃プロセスにのみ焦点を当てたが、脅威ジェノミク
スはシステムの変化に焦点を当てる
システムの変化に基づき、攻撃モデルを作成し、検知と予測能力の向上
を目指す
脅威シーケンスを利用する
脅威シーケンス
Reconnaissance ：偵察
Commencement ：開始
Entry ：エントリ
Foothold ：踏み台、（拠点）
Lateral movement ：横方向の動き
Acquired control ：コントロール取得
Acquired target ：ターゲット取得
Implement/execute ：実行
Conceal and maintain ：隠匿し、維持
Withdraw ：撤退
データソースのマッピング
12
脅威ジェノミクスのモデル図
Broad Street Taxonomy
インシデントの原因分析モデル
マルウェアのコンピューターへの侵入方法を明らかにすることが目的で
ある
セキュリティ分野で何度も議論されている侵入方法にのみ焦点を当てる
このモデルは完璧でない
証明書を盗むことで始まる侵入は扱わない
マルウェアが他のマルウェアをインストールする侵入は扱わない
モデルの利用方法
侵入に関する質問にフローチャート形式で回答する
フローの終点で侵入は分類される
質問内容
侵入の過程に関すること
（システム侵害に異なったアプローチをする）例外的なマルウェアの場合は、 技術に関すること
モデルの問題点
大雑把な質問であるため、微妙な違いが判別しにくい
分類が困難な場合
I'm unsure
hard to categorize
14
Broad Street Taxonomy
フローチャート形式の質問
Broad Street Taxonomy
質問事項 1/3
1. ユーザーは侵害に関与したか ?
Yes: 質問 2 へ移行
No: 質問 6 へ移行
2. ユーザーは欺かれたのか ?
Yes: 質問 3 へ移行
No: 質問 5 へ移行
3. ユーザーはソフトウェアの実行やインストールを行うつもりで
あったか ?
Yes:User ran/installed software (with unexpected functionality) に分類
No: 質問 4 へ移行
4. sploit を利用しているか、または CVE に当てはまるか ?
Yes: ソーシャルエンジニアリングの脆弱性として細分類可能 ( 質問 8 ～ 10)
No:User tricked into running software に分類
5. CVE に当てはまるか ? （質問 2 から派生）
Yes:user-interaction vulnerability
No: 質問 11 へ移行
Broad Street Taxonomy
質問事項 2/3
6. CVE に当てはまるか ? （質問 1 から派生）
Yes:classic vulnerability として細分類可能
No: 質問 7 へ移行
7. 侵害はソフトウェアの設定変更によって取り除くこ
とは可能であるか ?
Yes: 次の 4 つのいずれかに分類可能
オートラン (USB/ リムーバブル )
オートラン ( ネットワーク / マッピングされたドライブ )
オフィスマクロ
他の設定問題
No:feature abuse として次の 3 つのいずれかに分類可能
ファイル感染型ウィルス
パスワードブルートフォース
その他の特徴の悪用
Broad Street Taxonomy
質問事項 3/3
8. 特注のソフトウェアか ?
COTS や FOSS ：質問 10 へ移行
特注のソフトウェア：質問 9 へ移行
9. 脆弱性は周知であったか ?
Yes:Custom software, known (to owner) に分類
No:Custom software, discovered (by attacker) に分類
10. アップデートを利用するのにどれくらいかかるの
か ?
ゼロデイ
1 年以内アップデート
1 年以降のアップデート
非サポート
Adversarial Machine Learning
敵対型機械学習
機械学習がセキュリティに利用されつつあるが、攻撃者は
その事実を知っている
攻撃者は機会学習システムに対する攻撃を既に始めている
攻撃概要
攻撃の種類
標的型攻撃
無差別型攻撃
影響を与える
機会学習のトレーニングデータに影響を与える
トレーニングデータの運用システムを調査する
セキュリティ目標の破綻
完全性の破綻（侵入を検知しないポイントに対して攻撃する）
可用性の破綻（検出もれ、誤検知により、システムを利用できないようにす
る）
敵対型機械学習がどのように役立つかはまだわかっていな
い
Threat Modeling a Business
ビジネスに対する脅威モデリング
ビジネスに対する脅威モデリングは技術的
な脅威モデリングより難しい
ビジネスには組織ごとにユニークな資産、それに基づく
脅威がある
OCTAVE Allegro
ビジネスに対する脅威モデリングで最も発展した手法
組織がリスクアセスメントを実施するために重大な資産
、脅威、脆弱性を評価する手法
オペレーショナルリスクに焦点を当てている
CERT.org の web サイトから無料で利用できる
20
OCTAVE Allegro
4 フェーズで実施される
リスク評価の基準を作成する
作成を担当する人を決定することも含む
重要な情報資産のプロファイルを作成する
情報資産の脅威を特定する
情報資産に対するリスクの特定と分析を行い、リスクの軽減策
を作成する
リスク評価の基準作成時に取り扱うべきリスク
評判、顧客の信頼
財政
生産性
安全性と健康
罰金と罰則
ユーザーの定義
誤った脅威モデリング
脅威モデリングの弊害となる成果物
すべての仮説を列挙したリスト
コンサルタントによる脅威モデルレポート
脅威モデリングに関する誤った考え方
カーゴカルト
キッチンシンク
攻撃者のように考えること
脅威モデリングは必ずしも必要でない
脅威モデリングを行う正しい方法が一つあると信じるこ
と
自身の脅威モデリングの手法に固執すること
守るべき資産以上にセキュリティに投資を行うこと
22
脅威モデリングの弊害となる成果物
すべての仮説を列挙したリスト
仮説の列挙には際限がない
コミュニティによって、仮説は異なる
専門家による仮説であっても、正しいとは限らない
しかし、仮説を深化する作業は価値がある
仮説を深化する際のポイント
このことが脅威モデリングを始める妨げにならないようにする
判明したことを文書化する
脅威モデリングレポート
コンサルタントによる脅威モデリングレポートは内容自
体は悪くないが、顧客が利用しにくい表現がされている
顧客が脅威を理解しやすいように意味付けして、表現さ
れるべきである
脅威モデリングに関する誤った考え方
1/2
カーゴカルト
脅威モデリングの本質 ( 内容、意味 ) を理解せずに実施するこ
と
意味が理解できない脅威モデリングであれば、行うべきでない
キッチンシンク
脅威モデリングに関わる各人が異なる脅威モデリングの手法を
もちこみ、手法の取捨選択を行わないこと
攻撃者のように考えること
理想であるが、現実的には実現は困難である
実現を目指すのであれば、攻撃者の技術や目的の一覧を作成す
べきである
脅威モデリングは必ずしも必要でない
仕事のスケジュールが組めない、必要な成果物がわからないの
であれば、脅威モデリングは必ずしも必要不可欠でない
24
脅威モデリングに関する誤った考え方
2/2
脅威モデリングを行う正しい方法が一つあると信じ
ること
シチューモデルが正しいと信じること
シチューモデルとは多くの手法・アドバイスを用いて脅威モデリン
グを行う手法である
手法・アドバイスを無作為に用いるのではなく、よい手法・アドバ
イスを見極めることが重要
自身の脅威モデリングの手法に固執すること
この本の目的は費用対効果の良い方法で開発手法、またはオペ
レーション手法を統合する構造化された脅威モデリングを提供
することであるため、この本で自身のアプローチが批判された
人も、批判を受け止めるべきである
守るべき資産以上にセキュリティに投資を行うこと
脅威モデリングを行う理由は資産の保護であるため、脅威モデ
リングに資産以上の投資を行うべきでない
実験方法
脅威モデリングは容易ではない
脅威モデリングによって、何を改善したい
のか、何を失敗したのか、理解することが
重要である
実験の手順
改善したい問題を決める
測定可能な側面を見つけ、測定する
結果を分析する
26
改善したい問題を決める
改善したい問題を決める
システムの不十分な点を考える
システムがうまく機能しない原因を考える
目標を設定する
目標が定まっていなければ、本来の問題ではない問題を解決し
てしまう
目標が定まっていなければ、問題が解決されたかどうかわから
ない
目標が定まっていれば、脅威モデリングの先駆者に有効な質問
ができる
良い脅威モデリングを行うためには、先駆者に質問することが重要
質問例
脅威モデリングは意味のあるものだったか
いくつのバグを整理したか
測定可能な側面を見つけ、測定する
測定可能な実験を構築する
実験の中心には複数の仮説が存在しなけれ
ばならない
実験は仮説を基に作成したテストを含む
テストと同じ環境（人・システム）で実験したとしても
、同じ結果が得られるとは限らない
テストと実験が同じ結果になることをどのように保証す
るのか ?
15 章「ヒューマンファクターとユーザビリティ」のランニ
ングユーザーテストを参照すべきである
28
