Panasonic Advanced Technology Development Co. Ltd.
Chapter 7
Processing and Managing Threats Chapter 7
Processing and Managing Threats
2016/6/9
パナソニック アドバンストテクノロジー ( 株 )
1
Tracking with Tables and Lists
テーブルとリストによる脅威の追跡について
脅威の追跡のためのより良い機構は、脅威モデリングに
大きな違いを生み出す
本章では、ベストな追跡機構の参考となるいくつかのサ
ンプルを紹介する。ただし、これらの例はアドバイスで
強制するものではない
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
3
脅威の追跡
脅威の追跡には、以下の３つに着目する方法がある
ダイアグラムの要素
脅威の種別
脅威の発見順
これらについて、１章の「 Dive In and Threat Mode
l! 」の図を用いて説明する
Web browser Web server Business Logic Database
Corporate data center Web storage (offsite)
1 2 3 4 5 6 7
Tracking with Tables and Lists
脅威の追跡
「ダイアグラムの要素」でまとめる場合
STRIDE-per-element を使用している場合、各ダイアグラムの要素
ダイアグラム要素 脅威の種別 脅威 バグ ID ・タイトル
Web serverと Business Logic 間のデータフロー (4)
改ざん 支払いチェック無しに注文を追 加する
4553
「チャネル上の完全性制 御の必要性」
情報漏えい 平文で扱っている支払い機器 4554
「 PCI P0 の暗号化の必要 性」
サービス拒
否 データセンター内の全てを受け 入れ可能か？
4555「これらが受容可能かは IT部門のアリスに確認し てください」
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
5
脅威の追跡
「脅威の種別」でまとめる場合
「脅威の種別」をダイアグラムの各要素に繰り返し当てはめて考え る
脅威の種別 ダイアグラム要素 脅威 バグ ID ・タイトル
改ざん Web browser (1) 攻撃者が JavaScript の注文チェッ カーを修正する
4556
「サーバに注文チェックのロジ ックを追加する」
Data flow (2) HTTPS通信の失敗 4557
「このデータフローの末端で HTTPリスナーが存在し無い事を 確認する単体テストを構築」 Web server (3) Web serverを改ざんした何者か
が、顧客に攻撃可能
4558
「サーバのソースコードの全ての 変更は、変更が追跡可能なソース 制御から行われることを確認」 Web server (3) Web serverが注文アイテムを追
加可能である
4559
「より攻撃者からアクセスしにく い Business Logic に制御を移す よう検討」
Tracking with Tables and Lists
脅威の追跡
「脅威の発見順」でまとめる場合
脅威を発見した順に記載していくので、脅威の追加が一番簡単 追加は簡単だが脅威が雑然となるので、後で検証が困難
脅威の種別 ダイアグラム要素 脅威 バグ ID ・タイトル
改ざん Web browser (1) 攻撃者が JavaScript の注 文チェッカーを修正する
4556
「サーバに注文チェック のロジックを追加する」
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
7
脅威の追跡
以上３つのバリエーションを紹介したが、どれを使用するべき か？
新しく脅威モデリングを行うのであれば、最初の２つ「ダイアグ ラムの要素」・ 「脅威の種別」のどちらかを使用するのが良い
「脅威の発見順」のやり方はより自然なやり方で、思いついたも のをどんどん書いていくような場合は有用。しかし、最後にしっ かりチェックする必要がある
Tracking with Tables and Lists
前提条件をおく
問題に対する対策を決めてかからないように、前提条件を追跡す る事が重要である
前提条件の追跡には、以下を追跡する必要がある
① 前提条件
② 前提条件が間違っていた時の影響
③ 前提条件が間違っていた場合、誰がそれを分かるか
④ 誰が前提条件を追跡するか
⑤ 前提条件を追跡する必要があるのはいつか
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
9
前提条件をおく
以下は前提条件の例である
① 前提条件 ② 間違っていた場合の 影響（明らかでなけれ ば）
③ 誰が教えて くれるか（知っ ている場合に）
④ 誰が追
跡するか ⑤ 追跡した日 ⑥ バグ管理
Data center の範囲内は、 サービス拒否 は無視してよ い
捉えられなかった脆弱 性
(Unhandled vulnerabilities)
アリス ボブ 4/15 4555
Tracking with Tables and Lists
外部セキュリティに関する注釈
マイクロソフトの脅威モデリングに関するドキュメントの多くで
、外部のセキュリティーに関する注釈が記載されている
これらの注釈は、外部の脅威を発見するためのメモとなるもので
、これまでの内容と同様に追跡した方がよい
「顧客」と「 API の呼び出し元」の二つの観点がある ※詳細は RFC 3552
「 Guidelines for Writing RFC Text on Security Considerations 」を 参照
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
11
外部セキュリティに関する注釈
「顧客」向けの注釈
顧客向けのセキュリティに関する注釈は、概して「我々は問題 X を解決する事が出来ない」と言ったようなものである
例えば、「この製品は、システム管理者から身を守るために設計 されていません」、というような内容であると、顧客は受け入れ てしまうかもしれない
このような注釈内容は”非要件”であり、 12 章 “ Requirements Cookbook” で議論する
Tracking with Tables and Lists
外部セキュリティに関する注釈
「 API の呼び出し元」向けの注釈
API の設計は、ユーティリティ、ユーザビリティ、セキュリティ のトレードオフである
API の呼び出し元に対するセキュリティに関する注釈は、脅威モ デリングにおいては以下の役割がある
• その API がセキュリティに与える影響を理解する為の助けに なる
• 「顧客」がセキュリティへの影響を理解するのに役に立つ
（呼び出し元に脅威を教えないことは問題がある、 16 章のケルク
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
13
外部セキュリティに関する注釈
「 API の呼び出し元」向けの注釈
「 API の呼び出し元」に対する注釈は、大体以下のどれかに当て はまる
我々の脅威モデルはＸＸＸである
我々のコードはＸＸＸのような入力のみ受け付ける
これは、「送信するものに関しては厳密に、受信するものに関しては寛容 に」というインターネットの堅牢性の原則と、表面的には対立するが、受け 入れよう。
ＸＸＸを含む我々のコードの使用時の良くある間違い
・呼び出し元が何をチェックするべきなのか
・我々のコードが対処しない、対処できないような間違い
Tracking with Tables and Lists
外部セキュリティに関する注釈
「 API の呼び出し元」向けの注釈
“strcpy” のマニュアルの例
「 S2 が S1 のバッファー領域にあっているか検証をしない、または strcpy は、 S1 領域は少なくとも S2 の長さ＋１の領域が必要」
ここで、良いマニュアルなら、「 strcpy の使用は避けよ」、と続くだろう。
上記マニュアルの文言は最終的に追加されたが、結局 stcpy を正しく使うのは難し いままであった。
誤って使う事が避けられないような API であるなら、 API を変えるべ き（もしくはそれが許容されるような、傑出したビジネス価値を提供
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
15
外部セキュリティに関する注釈
RFC のセキュリティ上の考慮事項
IETF RFC(※) は、外部セキュリティに関する注釈の例である
※ RFC 3552 「 Guidelines for Writing RFC Text on Security Considerations 」
RFC のセキュリティの考慮事項は、次の議論が含まれる
スコープは何か
スコープ外のものは何か、何故スコープ外か
プロトコルが影響を受けやすい予測可能な脅威
ユーザまたはオペレータの残存リスク
プロトコルの保護に対する脅威
セキュリティの基礎となる前提条件
上記は、残存リスクをスコープ外とするかについての議論を含んでい る。残存リスクは 12 章の”非要件”と似ており、 12 章にて議論する
Scenario-Specific Elements of Threat Modeling
脅威モデリングのシナリオ固有の要素
脅威モデリングにおいて、同じ問題を含むよくあるシナ
リオがある
それらはカスタマ／ベンダの境界、脅威モデルの新しい
技術、 API の脅威モデル ( 前節の注釈より広い範囲 ) の
３つが含まれる
本セクションでは上記３つにかかわるシナリオを説明す
る
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
17
カスタマ／ベンダの信頼境界
カスタマ／ベンダの信頼境界を適切に設計する事は、よりよいセ キュリティ設計であり、リスクを最小限にする
• 顧客は、あなたから受け取ったコードを慎重に監査しなければならない
• あなたが顧客の暗号鍵のバックアップを持っている場合、顧客は情報漏えい のリスクをおうことになる
コードが信頼できる領域から離れる境界に注意を払うことが重要
• HTTPS 通信のエンドポイントはブラウザでないかもしれない
• ブラウザの場合でも、ブラウザ上の Javascript が改ざんされているかもし れないし、プロキシを通して返ってきたデータが改ざんされているかもしれ ない
Tracking with Tables and Lists
新しい技術
新しい技術は新しい脅威カテゴリを伴うが、多くの場合で似たよ うな脅威が現れる
STRIDE 等の脅威のモデルは、新しい技術に対する脅威モデリング に役立つ
脅威モデリングにおいて重要な事は、新しい技術が出来ることを 明確化し、信頼の境界を描いて、信頼の関係を伝えることである
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
19
新しい技術
例えば、初期の Web における信頼モデルは、以下のように大雑把 であった
上記の様に、信頼の境界は、明確に描写可能であった
Origin 1
Server context Origin 2
Web browser
Browser context
Web server
Tracking with Tables and Lists
新しい技術
現在ではクライアント上でコードを実行する様々な方法 (JavaScript/ ActiveX/Flash など ) が追加され、セキュリティモデルは以下のように 変わってしまった
Origin 1
Server context Origin 2
Web browser
Browser context
Web server
Active content Flash
Java
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
21
新しい技術
この様な Web の進化は、良くも悪くも、開発者と攻撃者の両者に とって Web 上で出来る事に劇的に変化をもたらした
Web の進化において境界が明確に定義されていれば、もっとより 良いセキュリティと共になされたであろう
Tracking with Tables and Lists
API の脅威モデリング
ユーザプログラムはカーネルに比べて低い信頼レベルで実行されている
低信頼側で出来ることは少ない。例えば低信頼側において、悪質なカーネル から自身を守るような事はできないし、するべきではない
API の高信頼側において、セキュリティ上実施すべき７つの点を説明する
① 信頼の境界内で全てのセキュリティチェックを実施すること
② データ読み込み時、全データが検証前にコピーされている事を確認
③ データが置かれる目的を知り、システムが期待する事と一致しているか確 認
④ メッセージが秘密を与える事なくトラブルシューティングを有効とする事 を確認
⑤ どのようなセキュリティチェックを行っているか、呼び出し元はどう使う
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
23
API の脅威モデリング
① 信頼の境界内で全てのセキュリティチェックを実施すること
信頼の境界の外側 ( 低信頼側 ) でセキュリティチェックを実施す ると、境界のポイントを見失ってしまう
送信前に入力をテストする事は多くの場合有用であるが、それは ユーザビリティの話であって、セキュリティ機能ではない
例えば、 Web フォームに記入する際に、記入ミスがあるとエラーメッセージ が返ってくる、など
信頼の境界の内側でテストを実施しなければならない
加えて、ネットワークにおける API/RESTful API/ プロトコルエン ドポイントでは、認証、認可、および失効を考慮することが重要
Tracking with Tables and Lists
API の脅威モデリング
② データ読み込み時、全データが検証前にコピーされている事を確 認
これに違反すると、 TOCTOU (“time of check, time of use”) と呼ぶセキュリティ上の欠陥となる
TOCTOU ：データに問題が無いかチェックし、その後データを使用するまでの 間に攻撃者がデータを変更できてしまう脆弱性
低信頼側から取得するデータは、セキュアなメモリにコピーして
、低信頼側から参照されないようにして使用する必要がある
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
25
API の脅威モデリング
③ データが置かれる目的を知り、システムが期待する事と一致して いるか確認
データがどのように使われるかを知る。例えば以下のようなこと
・ IPv4 のアドレスは、 4 オクテット確保せよ
・ E メールのアドレスには、いくつかの正規表現に合うようにせよ
API がパススルー ( 例えば、 socket の listen) である場合、デー タ長や C スタイル文字列の長さを検証することが制限されるかも しれないし、もしくは何も制限されないかもしれない
このようなケースでは、ドキュメントにて、まったく検証を実施 していない事を明確化するべきで、呼び出し元は注意が必要であ る
Tracking with Tables and Lists
API の脅威モデリング
④ メッセージが秘密を与える事なくトラブルシューティングを有効と する事を確認
デバッグ機能と出力する情報の量についてバランスを取る必要があ る
データベースに接続する際に、「ユーザ名 DBA のパスワード dfug90 845b4j でサーバーインスタンスに接続できません」、のようなエ ラーを出力すると、パスワードがばれてしまう
「タイプ X のエラーが発生しました。これは、エラーログ Z のイン スタンス Y です」、というようなエラーだと、システム管理者はロ グ Z 内の Y を検索できるが、攻撃者にはログの存在しかわからない
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
27
API の脅威モデリング
⑤ どのようなセキュリティチェックを行っているか、呼び出し元は どう使うべきかをドキュメント化する
入力に制約のない API は非常に少ない
HTTP インターフェースの場合、 CGI プログラムは Web サーバから の HTTP ヘッダなどを環境変数から取得可能だったが、環境変数は 数々のバグにつながるものであった
CGI プログラムが何を信頼できるかは文書化されたが、文書から 読み取る事が出来る攻撃や前提は文書化されなかった
Tracking with Tables and Lists
API の脅威モデリング
⑥ 暗号機能は、一定の時間で実行していることを確認
すべての暗号化機能は、低信頼側の観点から一定の時間で実行す る必要がある
暗号鍵は、たいてい踏み台となる資産であり、保護したい資産で もある。暗号システムへの脅威は第 16 章を参照
Panasonic Advanced Technology Development Co. Ltd.
Tracking with Tables and Lists
29
API の脅威モデリング
⑦API の一意なセキュリティ要求を扱う
新たな API を追加するとき、新たなリスクをもたらす可能性があ る
「我々は API で間違って何ができるか？」、という問いに対して は、「不正なインサイダー」 (rogue insider) モデルが役に立つ
API の追加時は、類似または競合する API を見つけ出し、 API 実 行時にどのようなセキュリティ上の変化が起こるのか、を確認す る事が役に立つ
Summary
脅威モデリングの助けとなるツールやテクニックがある
脅威モデリングは、ソフトウェア・ダイアグラムの作成から開始 し、脅威をセキュリティバグとして管理する
ダイアグラムの作成は出来る限り広い記述から始めて、必要に応 じて詳細を追加していき、信頼境界、ソフトウェア要素、脅威の モデルにより、トップダウンで分析する
緩和策については、攻撃者は緩和策を回避しようとする事に注意 すること
脅威、前提条件、および顧客が知っておくべきことなどを追跡す る
カスタマ／ベンダの信頼境界を適切に設計する事が重要
