ソフトウェアセキュリティ保証の三要素とは？

TL;DR

ソフトウェアの安全性は、脅威モデリング、コードレビュー、侵入試験を連携させ、事業リスクの高い問題から対処することで継続的に保証できる。設計時に脅威を洗い出し、静的分析で原因箇所を絞り込み、侵入試験で想定した攻撃を検証することが重要である。

Transcript

こ ん に ち は 、Jacob West で す 。 先 日 、 ヒ ュ ー レ ッ ト パ ッ カ ー ド に 買 収 さ れ た Forty Five Software で セ キ ュ リ テ ィ リ サ ー チ 部 門 の デ ィ レ ク タ ー を 務 め て い ま す 。 本 日 の プ レ ゼ ン テ ー シ ョ ン で は 、 ソ フ ト ウ ェ ア セ キ ュ リ テ ィ の 発 展 、 今 日 私 た ち が 当 然 の も の と 考 え て い る セ キ ュ リ テ ィ プ ラ ク テ ィ ス の 起 源 、 そ し て そ の 今 後 に つ い て お 話 し し た い と 思 い ま す 。 私 が セ キ ュ リ テ ィ 分 野 に 足 を 踏 み 入 ... Read More

Key Insights

• ソフトウェアセキュリティは、攻撃や防御を扱う専門家と、開発者やQAエンジニアによるシステム構築の実務を結び付ける独立した分野である。
• セキュリティ保証の主要素は、脅威モデリング、コードレビュー、侵入試験の三つであり、コンプライアンスとリスク管理の視点から統合する必要がある。
• 脅威モデリングは、システムの構造と技術を理解し、起こり得る侵害を仮説として列挙して、事業リスクの大きさに基づき対応順を決める活動である。
• 脅威は、潜在的な脆弱性、侵害の動機を持つ攻撃者、脆弱性を利用する攻撃という要素を組み合わせて把握すべき潜在的な侵害要因である。
• 脅威モデルは、攻撃対象や危険にさらされるコードを明確にし、コードレビューの範囲と静的分析結果の修正優先度を決めるための情報源である。
• 脅威モデルは、想定される攻撃が侵入試験で実行されたかを評価するスコアカードとなり、不足する攻撃手法や試験範囲を特定できる。
• 静的分析は、ソースコードをアプリケーションのモデルへ変換し、データフローなど複数の分析を適用して、攻撃可能な脆弱性を識別する手法である。
• 静的分析の結果は、ツールだけで完結するものではなく、事業上の重要性、真の脆弱性か否か、修正の優先順位を人間が判断して初めて活用できる。

Questions & Answers

Q: ソフトウェアセキュリティとは何ですか？

ソフトウェアセキュリティとは、ファイアウォール設定や攻撃を扱うセキュリティ専門家の領域と、ソフトウェアを構築する開発者やQAエンジニアの領域を統合した分野である。複数のベンダーから得たハードウェア、ソフトウェア、サービスを一つのシステムへ統合する必要が生じたことで、独立した課題として重要になった。

Q: ソフトウェアセキュリティを継続的に保証する方法は？

継続的な保証には、脅威モデリング、コードレビュー、侵入試験の三つを個別に実施するだけでなく、相互に連携させる必要がある。脅威モデルで重要な攻撃対象を特定し、その情報でコードレビューと静的分析の優先順位を決め、さらに侵入試験が想定した攻撃を十分に再現できているかを確認する。

Q: 脅威モデリングの進め方は？

最初にシステムの設計、主要コンポーネント、機能の実装場所、基盤技術とセキュリティへの影響を理解する。次に侵害の仮説を可能な限り列挙し、発生可能性と事業へのリスクで優先順位を付ける。最後に、設計変更による軽減、対応不要とする理由、将来のリリースでの対応方針などを各脅威へ関連付けて記録する。

Q: 脅威、攻撃、攻撃者の違いとは何ですか？

脅威はセキュリティを侵害する潜在的な要因であり、実在が確認された欠陥だけを意味するものではない。攻撃は侵害の原因となる行為であり、攻撃者はその行為を実行する、または実行させる主体である。脅威を具体的に捉える際には、潜在的な脆弱性、動機を持つ攻撃者、脆弱性を利用する攻撃の組み合わせを考える。

Q: 脅威モデルはコードレビューにどう役立ちますか？

脅威モデルによって、アプリケーションの攻撃対象、リスクにさらされるコード、列挙した脅威の標的となる機能を特定できる。その情報を使えば、コードレビューで先に確認すべき範囲を決められるほか、静的分析が出した多数の発見事項のうち、レビューと修正を優先すべき結果を選別できる。

Q: 静的分析によるコードレビューの利点は何ですか？

静的分析は、ソフトウェアを実行せずにソースコードを検査でき、コードベース全体を一貫して対象にできる。問題が疑われるURLやパラメータを示すだけでなく、脆弱性が存在し、修正を実装すべきコード行へ開発者を導ける。また、手動レビューや実行時試験より迅速に、多数の想定状態を安全かつ一貫して確認できる。

Q: 初期と最近の静的分析ツールは何が違いますか？

2000年から2001年頃のRAT、ITS4、FlowFinderなどは、脆弱性を招き得る関数を探す検索ツールに近く、実際に攻撃可能な箇所と安全な使用箇所を区別できないため、多くの誤検出を生んだ。最近のツールはコードからモデルを構築し、データフローなど複数の分析を組み合わせて、攻撃可能性に基づく順位付けを行える。

Q: 侵入試験に脅威モデルを活用する方法は？

脅威モデルを、侵入試験の有効性を測るスコアカードとして使う。システム展開後に起こり得る事態として列挙した攻撃が、実際の侵入試験で実行されたかを照合することで、試験範囲の不足を発見できる。不足があれば攻撃のレパートリーを広げ、既存の脅威モデルに沿って試験対象を追加する。

Summary & Key Takeaways

• ソフトウェアセキュリティは、セキュリティ専門家の知見と、開発者やQAエンジニアによるシステム構築の実務を統合する分野である。その保証を構成する主要素は、設計段階で問題を予測する脅威モデリング、ソースコードから欠陥を探すコードレビュー、攻撃者の行動を再現する侵入試験であり、三つをリスク管理の観点から連携させる必要がある。

• 脅威モデリングでは、システムの設計、構成要素、機能の実装場所、採用技術とその影響を理解したうえで、侵害シナリオを仮説として列挙する。次に、各シナリオの発生可能性と事業への影響を基に優先順位を決め、設計変更による軽減、リスク受容、将来のリリースでの対応などを理由とともに記録し、後続のレビューや試験へ情報を渡す。

• コードレビューは、実行時試験だけでは得にくいコードベース全体の一貫した確認と、脆弱性の根本原因となる行の特定を可能にする。初期の静的分析ツールは危険な関数を検索する性格が強く誤検出も多かったが、最近のツールはコードのモデル化、データフロー分析など複数の手法を組み合わせる。ただし、真の脆弱性や修正順位の最終判断には人間が必要である。