Chapter 10 Validating That Threats Are Addressed 20160613

(1)

Chapter 10

Validating That Threats Are Addressed

脅威分析研究会

片岡　良典

(2)

Chapter 10 • Chapter10 は Testing(=Quality Assurance: テス

トの生成と管理 ) についての話題

– 対象は Testing の中で Threat Modeling に関わる部分

• _主な内容

– Threat Modeling はテストプロセスに組み込んでしまうとよい

– バイナリやソースコードしかない場合の検証について

– 脅威モデルの検証では確認すべき 3 つの点について

– Threat Modeling と検証が補完しあうようにするには

– バグ管理で Threat Modeling 結果を扱う場合の管理方法

(3)

Testing Threat Mitigations

• 脅威に対処する場合、テストは必須なのでテストプロセ

スと統合すればよい

– 1 つの脅威に対してテストは 2 つ

• 攻撃をして成功しないことを確認するテスト

• 対策を迂回できないことを確認するテスト

– バグ管理に入れる場合、脅威を追跡するバグ票とテストコードのバグ票の 2 つを

作成することになるが、それぞれ「 threatmodel 」「 tmtest 」といったタグ付

けをすればよい

• バグとして登録した場合に再現方法を用意する

– 1 つの脅威でも攻撃方法は複数のバリエーションがあるのでテスト方法も複数用

意する

• 例えば XSS の場合だと、 JavaScript の攻撃コード中の ” alert” を ” %61%6C%65%7

2%74%0A” に変えてみたテストなども用意する

– 対策を迂回できないことを確認するテストでも同様に攻撃のバリエーションを想

定して複数用意する

(4)

Testing Threat Mitigations

• ペネトレーションテスト

– ペンテストは Threat Modeling を補うものだが、”製品の品質を高め

る”ことにはつながらない

– たまたま見つけた不具合を直す助けにしかならず、 Threat Modeling

を置き換えることはできない

– ペンテストを行う際には、テスターとどの範囲でテストを行うか認識

があっていることが重要

(5)

Checking Code You Acquire

• バイナリやソースコードの形でもってきたソフ

トウェアをチェックする場合の話

• Threat Modeling では以下を行う

1. Threat Modeling を行うためにモデルを作る

2. モデルを使って分析を行い、脅威に十分対応できていない場合

にアクションを起こす

(6)

Checking Code You Acquire

• ソフトウェアのモデルを作る

– ソフトウェアを調べる　 ( 右のリストのような項目→ )

– ソフトウェアのモデルを書く

• コンポーネントが信頼の境界

• コンポーネント内それぞれのプロセスがモデルのプロセス

• リスニングポートがデータフローの末端

• ( もしあれば )Web とデータベースをより深く調べる

• 管理者のインターフェースは信頼の境界とデータフローに加える

• Web サーバーとかフレームワークのような依存しているものをプロセスやデータ

フローに加える

– 依存関係に再帰的に手順を適用する

– 依存関係にあるものにセキュリティ fix が適用されているか US National DB などを活用して確認する

(7)

Checking Code You Acquire

• 脅威に十分対応できていない場合にアクション

を起こす

• アクションの選択肢は以下の 3 つ

– ソフトウェアの提供元に知らせる

– 別の代替となるソフトウェアを探す

– 自分自身で脅威に対応する

(8)

QA’ing Threat Modeling

• 脅威モデルの検証で確認すべき 3 点

– 分析に使用したモデルが現実のソフトウェアに即していること

• Threat Modeling 後にソフトウェアに改修が加えられていると実物とモデル

が乖離する

• モデルから抽出した脅威は最終的なソフトウェアにはない脅威かもしれない

– 脅威リストにある脅威全てが対処され、テスト計画が完了して

いること

• 既存のバグ管理の方法が存在するはずなので、その流れに脅威も乗せれば同

じ流れで自動的に処理される

• バグ管理を Threat Modeling の出口にできれば、そこまでで Threat Modeli

ng が完了したと言える

– 脅威モデルのバグ票が閉じられていること

• ソフトウェアのリリース前にバグ票が閉じられていることを確認するが、その際に”

tmtest” のタグでフィルタすると確認しやすい

(9)

Process Aspects of Addressing Threats

• Threat Modeling Empowers Testing; Testing E

mpowers Threat Modeling

– Threat Modeling が Testing に含まれれば、開発の早い段階からテ

スターが参加でき、テストが始められる

– Threat Modeling のためにテスターを早期に投入するなら、 Threat Mo

deling のプロセスを効果的に進めることができる

→ 　 Threat Modeling のおかげでテスターが早い段階から開発 PJ に参加

することができ、また逆に Threat Modeling を早くから始められるという

相乗効果がある

(10)

Process Aspects of Addressing Threats

• Validation/Transformation

– 入力データの検証では、目的に沿ったデータかどうかを検証できるこ

とが重要

• 「 http://www.example.org/this/url/will/pwn/you 」は RFC1738 に従っているの

で有効な URL だが、「 this/url/will/pwn/you 」は安全とは言えないため RFC に沿っ

ていることだけでは検証が不十分

• メールアドレス中に” ’ + “ があれば RFC822 に従っていても攻撃文字列と判断する

SQL インジェクション抑止のためのフィルタは、” O’Malley” のような名前の人も

想定される場合には誤検知を起こす可能性がある

– Filter → Transform のアプローチ

• まずホワイトリストでフィルタして、その後変換を行う方法

• セーフティ by デザインであることにアドバンテージがある

• 攻撃しようとすると複数のバグを突かないといけなくなるので攻撃難易度が上がる

• ( 例 ) HTML で A-Z,0-9 と一部の記号だけにフィルタした後、＜＞や＆等を &lt,&gt,&a

mp 等に変換する

(11)

Process Aspects of Addressing Threats

• Document Assumptions as You Go

– Threat Modeling を行っているときには頭の中に何か想定がある。その

ような想定 ( 前提 ) をドキュメント化しておくこと

– テストを行う時にはその前提も含めて行う必要がある

(12)

Tables and Lists

• _{一般的なバグ管理}

• 脅威に関しても、全ての脅威 ( バグ ) に対処で

き、対応方針が立てられるならこのままでいい

が、現実にはリスクを受容したり転嫁したりす

ることがある

(13)

Tables and Lists

• Threat Modeling Bug Tracking

– 総合すると以下のような項目が Threat Modeling の結果の管理には適

している

• _{Bug ID}

• _脅威

• 対応 ( 対応する / 受容する / 転嫁する等 )

• _対応内容

• _対応状況

• テストコードの ID(Optional)

(14)

Tables and Lists

• _{受容したリスクの管理}

– 受容したリスクの追跡をするときに重要なことは、受容したリスクを

理解できるようにすること

– リスクを理解できるためには、少なくとも以下の項目を追跡すべき

• _{Bug ID}

• _脅威

• 被害額や被害のインパクト

• 被害の大きさを見積もった人と評価方法 (Optional)

• _{受容した理由}

• 受容した人 (= 決裁者 )

• バグ票を閉じる方法 (Optional)

(15)

Tables and Lists

• _{転嫁したリスクの管理}

– リスクの転嫁先は、場合によっては他の組織かもしれないが、多くの

場合顧客である。従って転嫁先は必要に応じて項目に加えればよい

– リスクをどこに転嫁させたか追跡する場合は、以下の項目にすればよ

い

• _{Bug ID}

• _脅威

• _{修正できない理由}

• 転嫁先 (Optional)

• _{転嫁する方法}

• _転嫁状況

(16)

まとめ

• Threat Modeling はテストプロセスに組み込んでしまう

とよい

• 脅威モデルの検証では確認すべき点が 3 つある

– 分析に使用したモデルが現実の ( 最終的な ) ソフトウェアから乖離していないこ

と

– 脅威リストにある脅威全てが対処され、テスト計画が完了していること

– 脅威モデルのバグ票が閉じられていること

• バグとして Threat Modeling 結果を管理する場合、リス

クの受容や転嫁に対応できるようバグ票の項目の拡張が

必要となる

Chapter 10 Validating That Threats Are Addressed 20160613

Chapter 10

Validating That Threats Are Addressed

脅威分析研究会

片岡 良典

Chapter 10

• Chapter10 は Testing(=Quality Assurance: テス

トの生成と管理 ) についての話題

– 対象は Testing の中で Threat Modeling に関わる部分

• 主な内容

– Threat Modeling はテストプロセスに組み込んでしまうとよい

– バイナリやソースコードしかない場合の検証について

– 脅威モデルの検証では確認すべき 3 つの点について

– Threat Modeling と検証が補完しあうようにするには

– バグ管理で Threat Modeling 結果を扱う場合の管理方法

Testing Threat Mitigations

• 脅威に対処する場合、テストは必須なのでテストプロセ

スと統合すればよい

– 1 つの脅威に対してテストは 2 つ

• 攻撃をして成功しないことを確認するテスト

• 対策を迂回できないことを確認するテスト

– バグ管理に入れる場合、脅威を追跡するバグ票とテストコードのバグ票の 2 つを

作成することになるが、それぞれ「 threatmodel 」「 tmtest 」といったタグ付

けをすればよい

• バグとして登録した場合に再現方法を用意する

– 1 つの脅威でも攻撃方法は複数のバリエーションがあるのでテスト方法も複数用

意する

• 例えば XSS の場合だと、 JavaScript の攻撃コード中の ” alert” を ” %61%6C%65%7

2%74%0A” に変えてみたテストなども用意する

– 対策を迂回できないことを確認するテストでも同様に攻撃のバリエーションを想

定して複数用意する

Testing Threat Mitigations

• ペネトレーションテスト

– ペンテストは Threat Modeling を補うものだが、”製品の品質を高め

る”ことにはつながらない

– たまたま見つけた不具合を直す助けにしかならず、 Threat Modeling

を置き換えることはできない

– ペンテストを行う際には、テスターとどの範囲でテストを行うか認識

があっていることが重要

Checking Code You Acquire

• バイナリやソースコードの形でもってきたソフ

トウェアをチェックする場合の話

• Threat Modeling では以下を行う

1. Threat Modeling を行うためにモデルを作る

2. モデルを使って分析を行い、脅威に十分対応できていない場合

にアクションを起こす

Checking Code You Acquire

• ソフトウェアのモデルを作る

– ソフトウェアを調べる ( 右のリストのような項目→ )

– ソフトウェアのモデルを書く

• コンポーネントが信頼の境界

• コンポーネント内それぞれのプロセスがモデルのプロセス

• リスニングポートがデータフローの末端

• ( もしあれば )Web とデータベースをより深く調べる

• 管理者のインターフェースは信頼の境界とデータフローに加える

• Web サーバーとかフレームワークのような依存しているものをプロセスやデータ

フローに加える

Checking Code You Acquire

• 脅威に十分対応できていない場合にアクション

を起こす

• アクションの選択肢は以下の 3 つ

– ソフトウェアの提供元に知らせる

– 別の代替となるソフトウェアを探す

– 自分自身で脅威に対応する

QA’ing Threat Modeling

• 脅威モデルの検証で確認すべき 3 点

– 分析に使用したモデルが現実のソフトウェアに即していること

• Threat Modeling 後にソフトウェアに改修が加えられていると実物とモデル

が乖離する

• モデルから抽出した脅威は最終的なソフトウェアにはない脅威かもしれない

– 脅威リストにある脅威全てが対処され、テスト計画が完了して

いること

• 既存のバグ管理の方法が存在するはずなので、その流れに脅威も乗せれば同

じ流れで自動的に処理される

• バグ管理を Threat Modeling の出口にできれば、そこまでで Threat Modeli

ng が完了したと言える

– 脅威モデルのバグ票が閉じられていること

• ソフトウェアのリリース前にバグ票が閉じられていることを確認するが、その際に”

tmtest” のタグでフィルタすると確認しやすい

Process Aspects of Addressing Threats

片岡　良典

• _主な内容

– ソフトウェアを調べる　 ( 右のリストのような項目→ )

→ 　 Threat Modeling のおかげでテスターが早い段階から開発 PJ に参加

• 「 http://www.example.org/this/url/will/pwn/you 」は RFC1738 に従っているの

• _{一般的なバグ管理}

• _{Bug ID}

• _脅威

• _対応内容

• _対応状況

• _{受容したリスクの管理}

• _{Bug ID}

• _脅威

• _{受容した理由}

• _{転嫁したリスクの管理}

• _{Bug ID}

• _脅威

• _{修正できない理由}

• _{転嫁する方法}

• _転嫁状況