Chapter9: 脅威対策時の
トレードオフ
情報セキュリティ大学院大学
大久保
概要
脅威リストの作成⇒
標準的なアプローチが使えれば、トレードオフより は早く解決
8 章で学んだこと以外のリスク管理手法が学べるなら それもよし
リスクに対するアプローチ
受容
対策
回避
転嫁
いつ、どのよ うに
古典的リスク管理
脅威に対する 3 つの判断
1. リスクのレベル
2. リスク対策に何をしたいか 3. どのように実現するか
しかし、上記はコストがかかるため、通
常はもっと楽な手法を使う
古典的リスク管理
リスクの回避
リスクの対策
リスクの受容
リスクの転嫁
リスクを無視
古典的リスク管理
リスクの回避
リスクが得られる対価より大きければ、回避 ( 君子危うきに近寄らず )
a ship in the harbor is safe, but that is not wh at ships are for
実装しないか、別の設計にする
リスクの対策
まっとうな手段
詳細は 8 章
古典的リスク管理
リスクの受容
対策がコストに見合わなければ、受け入れる のもあり
脅威の可能性が非常に低いか、被害が小さい
危険性の表示
妊娠あるいは妊娠の可能性のある場合には Pa nexa は服用しないでください
古典的リスク管理
リスクの転嫁
発注者やエンドユーザに
サービス、ライセンス同意書
ユーザインタフェース
リスクを無視
かつてはよく行われていた
法律的や訴訟的にこの選択は適切でなくなり つつある
対策の選択
設計の変更
標準的な対策の採用
独自実装
設計の変更
設計における対策のファーストチョイス
はその機能をなくすこと？
本来実現したいことができなくなるかも
ですね ⇒そんな時はセカンドチョイス = 設計変
更
設計変更の例 : 認証、認可を追加など
設計変更のしかた
反復
比較⇒こっちの方が効率的
設計変更の例 : ワンタイム
トークン
情報漏洩の脅威が ある
設計変更の例 : ワンタイムトー
クン 暗号化したノンスをスマートフォンに送
り、復号して認証サーバに送る。端末を
確認しトランザクションを認可
ノンスをスマートフォンに送り、署名し
てサーバに送信
ノンスをスマートフォンに送り、ハッ
シュをとってサーバに送信
設計の比較 : どっちがセキュ
ア？
標準的対策技術
プラットフォーム提供
高信頼レベルで稼働
よく設計されている
ただ、か既に標準装備されている
開発者が実装
ほとんどの場合がこれ
インジェクション、バッファオーバーフロー など
標準的対策技術
運用時
運用時の対策は広い範囲をカバーするが、効 果的かは別の話
ex) ファイアウォールと、パケットの「意 味」を考慮した実効性
商用化されているものは、「 arms race( 軍拡 競争？いたちごっこのことか ) 」技術
Acme における対策の例
脅威 開発者の実装対象 運用者の対策例
なりすまし Web/SQLetcへのブルートフォース DBA,DBユーザの認証
認証基盤
改ざん データ、管理、ログの完全性保護 フロントエンド、 DB 管理機能 の完全性保護
否認 ログ ( ログ解析の保護 )
Web,SQLクライアントの操作ログ DBAの操作ログ
ログ ( ログ解析の保護 )
DBAが信頼できない場合、他 の特権ドメインシステムに採取 させる
情報漏洩 データ、管理、ログの保護
フロントエンドへのアクセス制御の実装 フロントエンドのみにデータへのアクセスを 許可
ACL、セキュリティグループ の管理
バックアップの保護
Dos フロントエンドにおける Dos リスクの最小化 十分なシステム資源の確保 権限昇格 信頼できるクライアント
パラメータバインド ( インジェクション対策 ) サーバ上では原則コマンド実行できな
い。 exec() や system() 実行には許可が必要
ローカルに書かれた不適切な信 頼クライアントの除去
DBを適切に設定
対策の独自実装
高リスクかつ、検証にコストがかかるが
、選択の余地がない場合もあり
低コストのデバイスで、 2048 ビット RSA 鍵 が使えばい場合など
ファジングは対策ではない
ファジング : ランダムな入力データの大量
生成によるテスト
バグを見つけるには適しているが、脅威
の対策ではなく、対策のテスト手段であ
る
脅威固有の対策優先度付け
単純アプローチ
Bug bar による脅威のランク付け
コスト見積もりによるアプローチ
単純アプローチ
様子見
うまくいく場合もあるが、カタストロフィも
…
チーズバーガー・ケース
先生、心臓発作が起きるまでチーズバーガー を食べ続けます！それから考えましょう
“see” の部分を計画的に行う必要がある
変更の検知
シグネチャ検知
アノマリ検知
影響の検知
単純アプローチ
簡単な修正優先
効果を考え、無駄のないようにやるべき
Bug bar による脅威のランク付
け
バグに影響についての共通理解に基づく深刻度を付ける 共通理解は、 bug bar テーブルから得る
バグを分類する基準
例
Microsoft SDL bug bar がオンラインで参照可能
セキュリティ bug bar( サンプル ) https://
msdn.microsoft.com/ja-jp/library/windows/desktop/cc307404.asp x
プライバシ bug bar( サンプル ) https://
msdn.microsoft.com/ja-jp/library/windows/desktop/cc307403.asp x
DREAD
Microsoft SDL チームはもはや DREAD を
推奨していない
主観的とか、望ましい結果が得られない
という評価により
Damage potential( 潜在的な損害 )
Reproductivity( 再現可能性 )
Exploitability( 攻撃利用可能性 )
Affected users( 影響ユーザ )
Discoverability( 発見可能性 )
コスト見積もりによるアプローチ
発生確率と被害による評価
自然現象と悪意は違う
しかし、保険会社は盗難保険をやっているし
、それにより倒産することはない
セキュリティにおいて適切な「発生確率」を 算出するのは容易ではない
大がかりな技術をかけて作られたシステムが 非常に安価なツールでやぶられる
FAIR
Factor Analysis of Information Risk
( 情報セキュリティの因子分析 )
発生確率ではなく、損害イベントの発生頻度 と損害の大きさによる見積もりを行う
FAIR
FAIR
問題点
同じシステムで繰り返し評価するのはよいが
、他のシステムの結果と比べられない
ステップ中の「資産」の定義が広すぎ
⇒解析コストを増大させる
対策 vs リスク受容
対策 vs 受容 ( 業務として )
多くの場合、他の要素 ( プライバシー、目的 合致性、コンプライアンス ) を考慮する必要 あり
対策 vs 受容 ( ユーザとして )
開発側のリスクとユーザ側のリスクは異なる
警告を出す場合の注意点 :NEAT
Necessary, Explanatory, Actionable, Tested ( 必要、説明的、実用的、テスト済み )
Arms Races( 軍拡競争 )
攻撃側、防御側がお互いに勝つことに躍起にな る
シグネチャベースのアンチウィルスソフト
完璧な防御が難しい場合に起きる
ゲーム理論的 : コストの最小化、利益の最大化
Last mover advantage
最後に動いたものが有利になる
あらゆる手段 (bag of tricks)
まとめ
古典的リスク管理手法は使える
より脅威に特化したアプローチ
設計変更、標準的対策、独自対策 ( は金がか かる )
ファジングが対策という誤解
対策の優先度付けが必要になる
様々なアプローチがある
受容と無視は違うよ
軍拡競争は避けられない面もある
