信頼できるコンピューティングのセキュリティ開発ライフサイクル

[アーティクル]
08/29/2008

Steve Lipner
Michael Howard
Security Engineering and Communications
Security Business and Technology Unit
Microsoft Corporation

March 2005
日本語版最終更新日 2005 年 5 月 27 日

概要 : この文書では、マイクロソフトが悪質な攻撃に耐える必要のあるソフトウェア向けに採用した開発プロセスである、信頼できるコンピューティング (Trustworthy Computing) のセキュリティ開発ライフサイクル (Security Development Lifecycle : SDL) について説明します。このプロセスでは、マイクロソフトのソフトウェア開発プロセスの各フェーズに、セキュリティに重点を置いた一連の開発活動とその成果物が追加されています。この開発活動とその成果物には、ソフトウェア設計時の脅威モデルの開発、実装時の静的分析コードスキャンツールの使用、および重点的な "セキュリティプッシュ" 時のコードレビューとセキュリティテストなどがあります。 SDL の対象となるソフトウェアは、開発グループ以外のチームによる最終的なセキュリティレビュー (Final Security Review) を実施しないとリリースできません。 SDL を実施したソフトウェアは、SDL 対象外のソフトウェアに比べて、マイクロソフト外でのセキュリティの脆弱性の発見率が大幅に減少しています。ここでは SDL について説明し、さらにマイクロソフトのソフトウェアへの SDL の導入経緯をご紹介します。

注 : この文書は、2004 年 12 月にアリゾナ州ツーソンで IEEE と共同開催した 2004 Annual Computer Security Applications Conference で発表された『The Trustworthy Computing Security Development Lifecycle』の最新バージョンです。

1. はじめに
   1.1 ベースラインプロセス
   1.2 セキュリティ開発ライフサイクルの概要
2. セキュリティ開発ライフサイクルプロセス
   2.1 要件フェーズ
   2.2 設計フェーズ
   2.3 実装フェーズ
   2.4 検証フェーズ
   2.5 リリースフェーズ
   2.6 サポートおよびサービスフェーズ
3. マイクロソフトでのセキュリティ開発ライフサイクルの実装
   3.1 SDL 適用の義務付け
   3.2 必須教育
   3.3 製品チームの基準
   3.4 中心となるセキュリティチーム
4. マイクロソフトでのセキュリティ開発ライフサイクルの実装結果
5. セキュリティ開発ライフサイクルの適用に関する意見
   5.1 SDL の要素の効果
   5.2 ツール、テストおよびコードレビュー
   5.3 投資
   5.4 成果
6. まとめ
7. 謝辞
8. 参考資料
9. ご注意

1. はじめに

すべてのソフトウェアベンダは、セキュリティの脅威に必ず取り組まなければなりません。セキュリティは、重要なインフラストラクチャを保護する必要性やコンピューティングに対する幅広い信頼を確立して維持する必要性などの市場動向を受け、ソフトウェアベンダの中核をなす要件となっています。すべてのソフトウェアベンダの主要課題は、更新プログラムの必要性が少なく、面倒なセキュリティ管理の必要性も少ない、より安全なソフトウェアを作成することです。

ソフトウェア業界にとって、セキュリティの向上に対する今日の要求を満たす鍵となるのは、適度に向上したセキュリティを確実に提供できる反復可能なプロセスを実装することです。このため、ソフトウェアベンダは、より広い範囲に及ぶセキュリティに重点を置いた一層厳格な開発プロセスに移行する必要があります。このようなプロセスの目的は、設計、コーディング、およびドキュメントに潜むセキュリティの脆弱性を最小限にすること、開発ライフサイクルのできるだけ早い段階で脆弱性を見つけて取り除くことにあります。このようなプロセスに対するニーズは、インターネットから受信した情報を処理したり、攻撃を受ける可能性のある重要なシステムを制御したり、個人を識別できる情報を処理したりするために使用されることの多い、企業および一般ユーザー向けソフトウェアで非常に大きくなっています。

より安全なソフトウェアの構築には、3 つの側面があります。それは、反復可能なプロセス、エンジニアの教育、および基準と責任です。この文書では、エンジニアの教育についてや、SDL の一部を適用した場合の影響を示すいくつかの全体的な基準についても説明しますが、主に SDL の反復可能なプロセスに重点を置いて説明します。

マイクロソフトの経験を参考にすれば、他の組織で SDL を採用しても、ソフトウェア開発に不当なコストがかからなくなるはずです。マイクロソフトの経験では、より安全なソフトウェア (更新プログラムが少ない、顧客の満足度が高いなど) を提供することの利点はコストよりも重要です。

SDL は、ソフトウェアのセキュリティの向上につながる手段を統合することにより、ソフトウェア開発組織のプロセスを変更します。この文書では、その手段の概要を紹介し、それを通常のソフトウェア開発のライフサイクルに組み込む方法を説明します。変更の目的は、プロセスを全体的に見直すことにあるのではなく、優れた定義のセキュリティチェックおよびセキュリティ機能を追加することにあります。

この文書では、セキュリティのベストプラクティスおよびプロセスの改善箇所の開発と発展を推進して、組織全体に専門知識として提供し、ソフトウェアのリリース前にレビュー (FSR : Final Security Review) を実施する中心的グループが社内に存在することを前提としています。マイクロソフトの経験では、このような組織の存在は、SDL を問題なく実装して、ソフトウェアのセキュリティを向上させるために重要です。組織によっては、受託業者やコンサルタントが "中心となるセキュリティチーム" の役割を担う場合があります。この文書では、大規模なソフトウェア開発組織で一般的に使用されているソフトウェア開発プロセスに、ソフトウェアのセキュリティを向上させる一連の手順を組み込む方法について説明します。これらの手順は、マイクロソフトが、信頼できるコンピューティングイニシアチブ (Trustworthy Computing Initiative) の一部として設計しました。このプロセス改善の目標は、顧客が使用するソフトウェアのセキュリティの脆弱性の量と深刻度を減らすことにあります。この文書では、マイクロソフトで現在実装している変更したソフトウェア開発プロセスを、信頼できるコンピューティングのソフトウェア開発ライフサイクル (Trustworthy Computing Software Development Lifecycle : SDL) と呼んでいます。

マイクロソフトの経験では、セキュリティチームは、ソフトウェアの設計および開発中に頻繁に交流する必要があり、また、機密性の高い技術およびビジネス情報で信頼を受ける必要があります。これらの点から、ソフトウェア開発組織内でセキュリティチームを作ることをお勧めします (コンサルタントと契約して、チームの構築とメンバのトレーニングを手助けしてもらう方が良い場合もあります)。

1.1 ベースラインプロセス

マイクロソフトで通常受け入れられているソフトウェア開発プロセスの概略を図 1 に示します。高いレベルでは、これは、業界で実践されている典型的なプロセスです。

図 1 マイクロソフトの標準的な開発プロセス (クリックすると拡大表示されます)

図 1 は 5 つのマイルストーンを示し、"ウォーターフォール" 型の開発プロセスを提案しているように見えますが、実際にはスパイラル型です。要件と設計は、市場のニーズの変化とソフトウェアの実装中に生じる現実に対応して頻繁に見直されます。さらに、この開発プロセスは、ほぼすべてのポイントに実行コードが必要なことを強調しているため、主要な各マイルストーンが、実際には一連のビルドの成果物に分割されて、開発チームが操作面から継続的にテストして使用できるようになっています。

1.2 セキュリティ開発ライフサイクルの概要

実際のソフトウェアのセキュリティに関する経験が、より安全なソフトウェアを構築するための高水準の原則につながっています。マイクロソフトでは、この原則をSD³+C ? 設計による安全性確保 (Secure by Design)、既定設定による安全性確保 (Secure by Default)、導入/展開時の安全性確保 (Secure in Deployment)、およびコミュニケーション (Communications) と呼んでいます。これらの原理について、次に簡単に説明します。

設計による安全性確保 (Secure by Design) : ソフトウェアは、ソフトウェア本体とソフトウェアが処理する情報を保護し、攻撃を防ぐように、構成、設計、および実装する必要があります。
既定設定による安全性確保 (Secure by Default) : 現実の世界では、ソフトウェアが完全なセキュリティを達成することはないため、設計者はセキュリティに欠陥があることを前提にしなければなりません。残存するセキュリティの欠陥を攻撃者が標的にした場合の被害を最小限に食い止めるために、ソフトウェアの既定の設定でも安全性を確保できるようにする必要があります。たとえば、ソフトウェアを必要最低限の権限で実行する必要があり、またあまり必要でないサービスや機能は既定で無効にするか、少数のユーザーだけがアクセスできるようにする必要があります。
導入/展開時の安全性確保 (Secure in Deployment) : ソフトウェアにツールやガイダンスを添付して、エンドユーザーや管理者がソフトウェアを安全に使用できるようにする必要があります。さらに、更新プログラムは簡単に展開できなければなりません。
コミュニケーション (Communications) : ソフトウェア開発者は、製品の脆弱性が発見された場合に備える必要があり、エンドユーザーや管理者が防御手段 (更新プログラムの適用や対策の実行) を取ることができるように率直に責任を持って伝える必要があります。

SD³+C の各要素が開発プロセスに要件を課しますが、最初の 2 つの要素 (設計による安全性確保と既定設定による安全性確保) が最も大きなセキュリティ上の利点を提供します。設計による安全性確保は、脆弱性の公開の防止を第 1 の目的としたプロセスを義務付け、既定設定による安全性確保は、ソフトウェアの既定の危険度 ("攻撃される面") を最小にするよう要求します。

SD³+C パラダイムを既存の開発プロセスに統合することを目的とするセキュリティ手段を導入すると、全体的なプロセスの構成は図 2 のようになります。

図 2 SDL によって改善されたマイクロソフトの開発プロセス (クリックすると拡大表示されます)

この文書のセクション 2 では、高いレベルでの SDL のコンポーネントについて説明します。セクション 3 では、マイクロソフトの SDL の実装に関する詳細を要約します。セクション 4 では、Microsoft Windows Server 2003 およびその他のソフトウェアの開発時に早い段階から SDL を適用したことにより、旧バージョンと比較してセキュリティの脆弱性の数が減り、その深刻度も低下したことを示すグラフを紹介します。セクション 5 では、マイクロソフトで SDL を適用した経験に基づく、プロセスの要素の定性的観察を紹介します。最後に、セクション 6 では全体のまとめを紹介します。

2. セキュリティ開発ライフサイクルプロセス

前述のとおり、この文書ではエンジニアの教育について取り上げません。しかし、教育プログラムが SDL の成功に重要である点に注意することは大切です。コンピュータサイエンスや関連分野の大学新卒者には、安全なソフトウェアを設計、開発、またはテストする準備をして実行できるようになるためのトレーニングが、一般的に不足しています。セキュリティを取り扱うコースを終了した学生でも、バッファオーバーランや正規化の欠陥よりも暗号アルゴリズムやアクセス制御モデルを扱う機会が多くなりがちです。一般的に、この業界のソフトウェア設計者、エンジニア、およびテスト担当者も、セキュリティに関する適切なスキルが不足しています。

このような状況の下では、安全なソフトウェアの開発を求める組織が、エンジニアリング要員を適切に教育する責任を負わなければなりません。この課題に見合う手段は、組織の規模や利用可能なリソースによって異なります。多数のエンジニアリング要員を抱える組織では、エンジニアに継続的なセキュリティトレーニングを提供する社内プログラムを作成できますが、小規模の組織では外部のトレーニングに頼らざるを得ません。マイクロソフトでは、ソフトウェアの開発に関与する人員は全員、毎年行われる "セキュリティリフレッシャ (security refresher)" トレーニングを受けなければなりません。

2.1 要件フェーズ

セキュリティを "根底から" 見直す必要は、安全なシステム開発の基本原理です。多くの開発プロジェクトでは旧リリースに基づいて "次期バージョン" を開発しますが、新規リリースまたはバージョンの要件フェーズと初期プランニングは、安全なソフトウェアを作成するための最良の機会となります。

要件フェーズでは、製品チームが、中心となるセキュリティチームに連絡を取り、計画を進める上での窓口、人員、および指導者となるセキュリティアドバイザ (マイクロソフトにおける SDL の実装では "セキュリティ支援者 (security buddy)" といいます) の割り当てを要求します。セキュリティアドバイザは、計画をレビューして提言し、製品チームのスケジュールをサポートする適切なリソースをセキュリティチームが計画できるようにすることで、製品チームを支援します。セキュリティアドバイザはプロジェクトの規模、複雑さ、およびリスクに基づいて、必要なセキュリティのマイルストーンと終了基準を製品チームにアドバイスします。セキュリティアドバイザは、プロジェクトの開始から Final Security Review の完了とソフトウェアのリリースまで、製品チームにおけるセキュリティチームとの窓口となります。セキュリティアドバイザは、セキュリティチームと製品チーム間の管理窓口としても機能し、プロセスの後半でセキュリティ関連の突発的な問題が起きないように、プロジェクトのセキュリティ原理が順調に反映されているかどうかをチーム管理担当にアドバイスします。

要件フェーズは、製品チームにとって、セキュリティをどのように開発プロセスに組み込むかを検討し、セキュリティの主要な目的を特定し、あるいは計画やスケジュールの中断を最小にしながらソフトウェアのセキュリティを最大化するための機会です。このプロセスの一部として、チームは、ソフトウェアのセキュリティ機能や検証手段を、そのソフトウェアと一緒に使われる可能性の高い他のソフトウェアと統合する方法を検討する必要があります (他のソフトウェアとのインターフェイスは、個々の製品を安全なシステムに統合するというユーザーのニーズを満たすための重要な検討事項です)。製品チームのセキュリティの目標、課題、および計画に対する全体的な観点が、要件フェーズで作成される計画文書に反映されている必要があります。計画はプロジェクトの進行に応じて変更されますが、こうした計画を早期に構成すれば、要件が見過ごされたり、最後の段階で急に浮上することがなくなります。

各製品チームは、このフェーズの一部としてセキュリティ機能の要件を検討する必要があります。一部のセキュリティ機能要件は脅威モデリングに対応して特定されますが、ユーザー要件は顧客の要求に対応したセキュリティ機能を含めることを定める可能性が高いです。セキュリティ機能要件は、業界標準への準拠の必要性およびセキュリティ共通評価基準 (Common Criteria) などの認定プロセスによって生じることもあります。製品チームはこれらの要件を認識して、通常の計画プロセスの一部として反映させる必要があります。

2.2 設計フェーズ

設計フェーズでは、ソフトウェアの全体的な要件と構造を特定します。セキュリティの観点から見た場合、設計フェーズの主な要素は次のとおりです。

セキュリティアーキテクチャおよび設計のガイドラインを定義します。ソフトウェアの全体的な構造をセキュリティの観点から定義し、セキュリティ上、正しく機能する必要のある重要なコンポーネント ("Trusted Computing Base") を特定します。階層化、強く型付けされた言語 (strongly typed language) の使用、必要最小限の権限しか持たないアプリケーション、攻撃対象領域の最小化などの、ソフトウェアにグローバルに適用される設計テクニックを特定します (階層化 とは、コンポーネント間の循環依存を防ぐように構成され適切に定義されたコンポーネントにソフトウェアの組織を組み込むことです。この場合、コンポーネントが階層状に構成され、上位層は下位層のサービスに依存できますが、下位層は上位層に依存できなくなります)。アーキテクチャの個々の要素の仕様はそれぞれの設計仕様に詳しく指定されていますが、セキュリティアーキテクチャがセキュリティ設計の全体的な観点を特定します。
ソフトウェアの攻撃対象領域の要素を文書化します。ソフトウェアが完全なセキュリティを実現できないことを前提とすると、ほとんどのユーザーが使用する機能のみをすべてのユーザーに既定で公開し、これらの機能を最小限必要なレベルの権限でインストールできるようにすることが重要です。攻撃対象領域の要素を測定すると、製品チームに既定のセキュリティの継続的な基準が提供され、ソフトウェアが攻撃を受けやすくなっているインスタンスを検出できるようになります。攻撃対象領域が増加したインスタンスを製品の機能や利便性の向上によって正当化できる場合もありますが、設計および実装中にこのようなインスタンスを検出し、問題として取り上げ、ソフトウェアを既定の構成で可能な限り安全な状態で出荷することが重要です。
脅威モデリングを実施します。製品チームは、コンポーネント単位で脅威モデリングを実施します。コンポーネントチームは、構造化された手法を使用して、ソフトウェアが管理しなければならない資産と資産にアクセスできるインターフェイスを特定します。脅威モデリングのプロセスでは、各資産に危害を及ぼす脅威と危害が及ぶ可能性 (リスクの見積もり) を特定します。コンポーネントチームは、次に、暗号化などのセキュリティ機能を利用する形式、または資産を危害から守るソフトウェアが適切に機能する形式で、リスクを軽減する対抗手段を特定します。このように脅威モデリングは、製品チームが、セキュリティ機能のニーズと、特に慎重なコードレビューおよびセキュリティテストが必要な領域を特定するのに役立ちます。脅威モデリングのプロセスは、脅威モデルを保存と更新用に機械可読形式で取り込むツールによってサポートされる必要があります。
補足的な出荷基準を定義します。基本的なセキュリティ出荷基準は組織レベルで定義する必要がありますが、個々の製品チームまたはやソフトウェアリリースには、ソフトウェアをリリースする前に満たす必要のある特定の基準が存在する場合があります。たとえば、顧客に出荷され、広範な攻撃の対象となるソフトウェアの更新バージョンを開発する製品チームは、リリースの準備ができたと見なす前に、一定期間、新バージョンの脆弱性を外部から報告されないことを義務付ける場合があります (つまり、脆弱性が報告されてから、製品チームがそれらを "修正" するのではなく、報告される前に開発プロセスで脆弱性を見つけて取り除く必要があります)。

2.3 実装フェーズ

実装フェーズでは、製品チームがソフトウェアのコードを書き、テストし、統合します。実装フェーズ中に、セキュリティの欠陥を取り除いたり、欠陥が入り込むのを初期の段階で防ぐための手順が大いに活用され、顧客にリリースされるソフトウェアの最終バージョンでセキュリティの脆弱性が生じる可能性を大幅に減らします。

脅威モデリングの結果は、実装フェーズ中に特に重要なガイダンスとなります。開発者は、優先度の高い脅威を減らすコードの正確さを確保することに特別な注意を払い、テスト担当者は、このような脅威が実際に阻止または軽減されることを確認することに重点を置きます。

実装フェーズで適用される SDL の要素は次のとおりです。

コーディングおよびテストの標準の適用。コーディングの標準は、開発者がセキュリティの脆弱性につながる欠陥を取り込むのを防ぐために役立ちます。たとえば、より安全でより一貫した文字列処理やバッファ操作を使用することで、バッファオーバーランの脆弱性が生じるのを防ぐことができます。テストの標準とベストプラクティスは、テスト時にソフトウェアの機能や特長が正しく動作することにだけ集中するのではなく、セキュリティの脆弱性の可能性検出に重点を置くのに役立ちます。
ファジー化ツールなどのセキュリティテストツールの適用。 "ファジー化 (Fuzzing)" により、構造化されてはいるが無意味な入力データがアプリケーションプログラミングインターフェイス (API) とネットワークインターフェイスに提供され、ソフトウェアの脆弱性につながるエラー検出の可能性が最大になります。
静的分析コードスキャンツールの適用。このツールにより、バッファオーバーラン、整数オーバーラン、および初期化されていない変数などの脆弱性をもたらすコーディングの欠陥を検出できます。マイクロソフトは、このようなツール (一番長く使われている 2 つのツールは PREfix および PREfast の名前で知られています) の開発に大規模な投資を行ってきており、新たな種類のコーディングの欠陥やソフトウェアの脆弱性が見つかるたびに、これらのツールを絶えず拡張しています。
コードレビューの実行。コードレビューでは、訓練された開発者の労力により、自動化されたツールやテストを補って、ソースコードを検証し、セキュリティの脆弱性の可能性を見つけて取り除きます。これらは、開発プロセス中の、ソフトウェアからセキュリティの脆弱性を取り除くプロセスにおいて重要な手順です。

2.4 検証フェーズ

検証フェーズは、ソフトウェアが機能的に完成して、ユーザーによるベータテストに入るポイントです。このフェーズでは、ソフトウェアでベータテストを実行している間、製品チームが、実装フェーズで完了したレビュー以上のセキュリティコードレビューと重点的なセキュリティテストを含む "セキュリティプッシュ (security push)" を実行します。

マイクロソフトは、2002 年初頭に Windows Server 2003 およびその他の一部のソフトウェアバージョンの検証フェーズでセキュリティプッシュを導入しました。セキュリティプッシュをプロセスに導入した理由は、次の 2 つです。

問題のバージョンのソフトウェアライフサイクルが検証フェーズに達し、このフェーズが、必要な重点的なコードレビューとテストを実行する適切なポイントだったため。
検証フェーズ中にセキュリティプッシュを実行することにより、ソフトウェアの完成バージョンを対象にコードレビューとテストを確実に実施し、実装フェーズ中に開発または更新したコードと変更されなかった "レガシーコード" の両方をレビューする機会が提供されるため。

1 番目の理由には、歴史的な偶然が反映されています。セキュリティプッシュを開始する決断は、当初、検証フェーズ中に行なわれました。しかし、マイクロソフトは、検証フェーズ中にセキュリティプッシュを実行することが、最終ソフトウェアが要件を満たすことを保証し、旧バージョンから継承されたレガシーコードをより詳細にレビューできるようにする、本当に優れた慣習であるという結論に達しました。

優先度の高いコード (ソフトウェアの "攻撃対象領域" となるコード) に対するコードレビューとテストは、SDL のいくつかの部分において非常に重要あることに注意してください。たとえば、このようなレビューとテストは、問題の早期の修正や問題の原因の特定と修正を可能にするため、実装フェーズに必要です。製品が完成に近い検証フェーズでも、レビューとテストは重要です。

2.5 リリースフェーズ

リリースフェーズでは、ソフトウェアの最終的なセキュリティレビュー (FSR : Final Security Review) を実施する必要があります。 FSR の目標は、「セキュリティの観点から見て、このソフトウェアは顧客に提供する準備ができているか?」という問いの回答を出すことにあります。FSR は、ソフトウェアの対応範囲に応じて、ソフトウェアの完成の 2 ～ 6 か月前に実施されます。それまでに、ソフトウェアは、セキュリティ関連以外の変更をほとんど必要としないリリース前の安定した状態になっている必要があります。

FSR とは、組織の中心となるセキュリティチームが実施するソフトウェアの独立したレビューです。セキュリティチームのセキュリティアドバイザが製品チームに、ソフトウェアに必要な FSR の対象範囲をアドバイスし、FSR の前にリソースのリストを提示します。製品チームは、セキュリティチームに FSR を完了するために必要なリソースと情報を提供します。 FSR は、まず、製品チームによる調査を完了させることと、FSR の担当となったセキュリティチームメンバとのインタビューから開始します。 FSR では、当初セキュリティのバグとして識別されたが、その後の分析でセキュリティに影響がないと判断されたバグについてもレビューし、その分析が正しく行なわれたことを確認する必要があります。また、このソフトウェアが、新たに報告された同種のソフトウェアに影響を与える脆弱性に耐えるかどうかのレビューも行います。重要なソフトウェアのバージョンの FSR には、ペネトレーションテストが必要で、外部のセキュリティレビュー委託業者を利用してセキュリティチームを補足しなければならないこともあります。

FSR は、単純に合格/不合格を決めるものではなく、また、ソフトウェアに残っているセキュリティの脆弱性をすべて見つけることが目的ではありません。これは明らかに不可能です。それよりも、製品チームや組織の経営陣に、ソフトウェアのセキュリティ状態とリリース後の攻撃に耐えられる可能性の全体像を示すためのものです。 FSR により、残存する脆弱性のパターンが見つかった場合は、見つかった脆弱性を修正するだけでなく、前のフェーズに戻って、根本原因を解決する適切な処置 (トレーニングの改善やツールの拡張など) を取る必要があります。

2.6 サポートおよびサービスフェーズ

開発中に SDL を実施しても、現在の開発技術では完全に脆弱性のないソフトウェアを出荷することはできません。また、不可能である十分な理由があります。開発プロセスでソフトウェアからすべての脆弱性を排除して出荷できたとしても、新しい攻撃が見つかって、"安全" であったソフトウェアに脆弱性があることがわかる場合があります。このために、製品チームは、出荷されるソフトウェアに対し、新たに見つかった脆弱性に対応する準備をしておく必要があります。

対応プロセスには、脆弱性のレポートを評価し、セキュリティ勧告をリリースして、適切な時期に更新する準備が含まれます。他には、レポートされた脆弱性の事後検証を実施し、必要に応じて対処することも含まれます。脆弱性への対処には、単独のエラーに対応する更新プログラムを発行することから、コードスキャンツールを更新して主要なサブシステムのコードレビューを開始することまで広い範囲にわたります。対応フェーズの目的は、エラーから学ぶことと、現場で脆弱性が見つかったり顧客にリスクを与える前に脆弱性を見つけて排除できるよう、脆弱性レポートの情報を利用することにあります。この対応プロセスは、将来的に同様のエラーが起きないように、製品チームとセキュリティチームがプロセスを調整する際にも役立ちます。

3. マイクロソフトでのセキュリティ開発ライフサイクルの実装

マイクロソフトの SDL の実装は、2002 年初めの "セキュリティプッシュ (security pushes)" 以来、進化してきました。プロセスを開始し、製品の開発段階にまで影響を与えるには、セキュリティプッシュを比較的短期間の活動に圧縮し、SDL の複数のフェーズに分散させる必要がありました。セキュリティプッシュは製品チームの計画、リソース、およびスケジュールに多大な影響を与えたため、マイクロソフトの経営陣からの積極的な支援がなければ、もっと難しいものになっていたでしょう。セキュリティプッシュでは、脅威モデリング、コードレビュー、およびセキュリティ (ペネトレーションを含む) テストに重点を置きました。最終的なセキュリティレビュー (FSR) は、2002 年末から 2003 年初めにかけて、Windows Server 2003 のリリース前に導入され、出荷時の Windows Server 2003 の既定の構成に大きな影響を与えました。

初期セキュリティフェーズと FSR の後、マイクロソフトは SDL プロセスを形式化するプロジェクトを開始しました。次に挙げる、このプロジェクト独自の 4 つの成果は特に注目に値します。

SDL の実装必須アプリケーションのポリシー
エンジニアリング要員向けの必須教育
製品チームの基準
中心となるセキュリティチームの役割

次の各セクションでは、これらの各分野について説明します。

3.1 SDL 適用の義務付け

SDL の利点が実証されたことから (セクション 5 を参照)、マイクロソフトは SDL を広範囲にわたるソフトウェアに適用するための要件を形式化することを決めました。この文書の執筆時点では、次のようなソフトウェアに SDL の適用が義務付けられています。

個人的な情報や機密性の高い情報を処理するために使われると予測される
企業やその他の組織 (学術機関、政府、非営利団体など) で使用されると予測される
インターネットに接続されるか、その他のネットワーク化された環境で使用されると予測される

適用が 義務付けられていない ソフトウェアには、上記の基準に該当しないスタンドアロンのアプリケーション (「The Magic School Bus」シリーズのような子供向けのゲームなど) があります。注目すべき点は、SDL では、このようなソフトウェアが、動作するプラットフォーム (オペレーティングシステムまたはその他のソフトウェア) のセキュリティによって中断されることを禁じているこです。

3.2 必須教育

2002 年初めのセキュリティプッシュでは、すべての開発者、テスト担当者、プログラム管理者、およびドキュメント担当者に対する製品グループチーム全体のトレーニングが重要な特徴の 1 つでした。そのため、マイクロソフトは、SDL の対象となっているソフトウェアを抱える組織のエンジニア向けに年に 1 度実施されるセキュリティ教育の要件を形式化しました。ところが、セキュリティが静的な分野ではなく、脅威、攻撃、および防御が変化することから、毎年更新する必要が生じています。その結果として、セキュリティに関して非常に優秀で能力のあるエンジニアであっても、脅威の状況が変わると、追加のトレーニングを受けなくてはなりません。たとえば、整数オーバーフローの脆弱性の重要性はこの 4 年間に急速に高まっています。また、最近は、一部の暗号化アルゴリズムに以前には知られていなかった脆弱性が見られようになりました。

マイクロソフトは、"ライブトレーニング" とデジタルメディア形式の両方で提供する、エンジニア向けのセキュリティに関する一般的な手引きと最新情報のコースを開発しました。マイクロソフトでは、ソフトウェアテクノロジ単位およびエンジニアの役割単位の専門トレーニングの基礎としてこのコースを利用しています。マイクロソフトは、テクノロジ、役割、および学習者の経験レベルに応じてさらに専門化した内容のセキュリティ教育カリキュラムを構築しています。

マイクロソフトのパートナーやお客様の多くから、マイクロソフトのセキュリティ教育およびプロセスの利用についてお問い合わせをいただいています。 Microsoft Press では、安全な設計、コーディング、および脅威モデリングに関して、マイクロソフトの社内事例に基づく書籍を発行しています。

3.3 製品チームの基準

マイクロソフトは、会社全体が "測定できないものは管理できない" という法則に従って運営されています。ソフトウェアのセキュリティを確実に測定する基準を立てるのは非常に難しいことですが、ソフトウェアセキュリティの代わりとなる明確な基準があります。その基準は、開発ライフサイクルの開始時におけるエンジニアリングスタッフのトレーニング範囲から、リリース済みのソフトウェアに存在する脆弱性の検出比率にまでわたります。

マイクロソフトは、製品チームが自分達の SDL の実装が成功しているかどうかを監視するために使用するセキュリティ基準を作成しました。これらの基準は、脅威モデリングから FSR でのソフトウェアのセキュリティに対するコードレビューとセキュリティテストに至る、チームの SDL の実装に対応します。これらの基準が長期にわたって実装すると、チーム自体のパフォーマンス (向上、レベル、または低下) や、他のチームのパフォーマンスとの比較を追跡できるようになります。これらの基準は収集されて、シニアプロダクトチームの幹部とマイクロソフトの経営陣に定期的に報告されます。

3.4 中心となるセキュリティチーム

マイクロソフトは、2002 年のセキュリティプッシュ以前に、Secure Windows Initiative (SWI) チームを設立しました。このチームの役割は、ソフトウェアのセキュリティを向上させ、Windows の脆弱性を縮小化し、Windows の開発チーム以外の製品チームにセキュリティサポートを提供することにあります。 SWI チームは、Windows Server 2003 のセキュリティプッシュを組織して管理する上で中心的な役割を果たし、2002 年から始められたセキュリティプッシュのすべての活動に対してトレーニングおよびコンサルティングサポートを提供しました。さらに、SWI チームは FSR プロセスの先駆けとなる Windows Server 2003 の FSR も実行しました。

SDL の正式な公開と共に、SWI チームはマイクロソフトの中心的なセキュリティチームの役割を果たしています。 SWI チームには、次のような責任が課せられています。

プロセスに必須の局面の定義を含む、SDL を開発、メンテナンス、および拡張する。
エンジニア教育を開発、拡張、および提供する。
プロセスを通して製品チームを指導し、製品チームのレビューを実施し、製品チームの質問にタイムリーかつ正確で信頼できる回答をする "セキュリティアドバイザ (security advisor)" を提供する
セキュリティについて幅広い知識を持つ専門家として機能し、質問がセキュリティアドバイザに届けられ、正確な答えをタイムリーに提供できるにする。
ソフトウェアがリリースされる前に、最終的なセキュリティレビュー (Final Security Review) を実施する。
リリース済みのソフトウェアについてレポートされた脆弱性の技術調査を実施し、根本原因の理解を促進して適切なレベルの対応が取られるようにする。

SWI チームの可用性と効果は、マイクロソフトにおける SDL の実装の大きな要因であることが証明されました。マイクロソフトは、より安全なソフトウェアを開発するためのスケーラブルなプロセスの確立を目標としており、この目標には、セキュリティの能力をすべての製品チームに広く浸透させる必要があるという意味が含まれています。その一方で、中心となる有能なセキュリティチームを持つことは、社内の製品チームの効率を上げ、チームがより安全なソフトウェアを構築できるようにサポートするために重要です。また、このようなセキュリティチームを持つことにより、製品チーム外の人間が FSR を実行できます。

4. マイクロソフトでのセキュリティ開発ライフサイクルの実装結果

マイクロソフトにとって、SDL がマイクロソフトのソフトウェアのセキュリティを向上させると結論付けることは時期尚早ですが、これまでのところは有望な結果が出ています。

Windows Server 2003 は、SDL の大部分を実装するものとしてマイクロソフトが最初にリリースしたオペレーティングシステムです。図 3 は、最新のマイクロソフトのサーバーオペレーティングシステム (Windows 2000 と Windows Server 2003) のリリース後 1 年以内に発行されたセキュリティ情報の数を示しています (Windows 2000 のリリース時には、マイクロソフトにはセキュリティ情報の正式な深刻度評価システムがありませんでした。そのため、Windows 2000 に適用されるそれぞれのセキュリティ情報を現在の深刻度評価システムに照らして評価しています)。この文書で既に説明したとおり、 Windows Server 2003 は、すべてではありませんがほとんどの SDL プロセスを利用して開発されました。Windows 2000 の開発では SDL プロセスは利用されていません。

図 3 SDL 以前および SDL 以後の Windows の重要なセキュリティ情報

深刻度クラスは、 https://www.microsoft.com/japan/technet/security/bulletin/rating.mspx で定義されています。

マイクロソフトのその他のソフトウェアリリースにも SDL の要素が適用されています。 SQL Server および Exchange Server の製品チームは、Service Pack (セキュリティの脆弱性やその他の問題の修正をまとめたソフトウェア) をリリースする前に、セキュリティプッシュ (脅威モデリング、コードレビュー、セキュリティテストなど) を実施しました。 SQL Server のセキュリティプッシュの結果は SQL Server 2000 Service Pack 3 に、Exchange Server のセキュリティプッシュの結果は Exchange 2000 Server Service Pack 3 に組み込まれました。図 4 と 5 は、各 Service Pack のリリース前後の同期間 (SQL Server 2000 は 24 か月、Exchange 2000 Server は 18 か月) にリリースされたセキュリティ情報の数を示しています。

図 4 SDL 前後の SQL Server 2000 のセキュリティ情報

図 5 SDL 前後の Exchange Server 2000 のセキュリティ情報

もう 1 つの有望な例に、Windows Server 2003 の Internet Information Server (IIS 6) コンポーネントがあります。マイクロソフトは、リリース後の 2 年間に Web サーバーに影響するセキュリティ情報を 1 件発行しましたが、これは、既定ではインストールされないコンポーネント (WebDAV) に含まれているものでした。

セキュリティの脆弱性の例はまだ少なく、期間も限定されていますが、これらの結果は SDL が有効であることの証拠となります。マイクロソフトは、Windows Server 2003、Exchange Server、および SQL Server Service Pack の脆弱性発生率の監視を続け、この初期の傾向が持続するかどうかを見守っています。さらに、マイクロソフトの他のソフトウェアについても、SDL の完全な実装後、新バージョンが出荷されるたびにセキュリティの脆弱性の数と深刻度の比率が減りつづけているかどうかを調べています。

5. セキュリティ開発ライフサイクル適用に関する意見

前のセクションで示したデータは、SDL で "何" を達成できるのかについて概要を示すものでした。このセクションでは、SDL のプロセスが "どのように" 機能するかという点について、いくつかの疑問にお答えしたいと思います。前のセクションは具体的な数字に基づいていましたが (マイクロソフトでは脆弱性レポートとセキュリティ情報を厳密に追跡しています)、このセクションは SWI チームのメンバから得た観察や意見形式の事例に基づいています。

5.1 SDL の要素の効果

SDL は、ソフトウェア開発ライフサイクルの全体に分散した多数のコンポーネントサブプロセスで構成されています。 SDL チームは、これらのサブプロセスを効果によって、つまり最も効果が高いプロセス、試したが効果が低かったプロセスなどと、優先順位を付けるように求められています。

脅威モデリングが SDL のコンポーネントで最も優先順位が高いというのが SWI チームの共通の認識です。脅威モデリングが単独では適用されないことは明白です。脅威モデリングでは、設計、コードレビュー、およびテストが実施しされますが、脅威モデリングにのみ実装され、(軽減の効果のテストに失敗するなどによって) モデルに対応した処置を取らなかったプロセスは、まったく効果がありません。脅威モデリングの意味の多くは、セキュリティの脆弱性につながるバグが生じないことを保証するものであるため、バグカウントなどの形式の統計情報は、脅威モデリングを軽視する傾向にあります。とはいえ、安全なソフトウェアの開発プロセスに重点を置く脅威モデリングの役割は非常に重要で、リストの最上位に位置付けらることは明らかです。

マイクロソフトでは、現在でも SDL は比較的新しいプロセスであるため、プロセスのコンポーネントが削除された例はまだありません。しかし、長期のセキュリティ調査で、ペネトレーションテストがセキュリティを達成する方法ではないと判明しても不思議ではありません。ペネトレーションテストは主要なソフトウェアリリースの最終的なセキュリティレビュー (FSR) の要素ですが、ライフサイクル全体を通した製品チームの活動は、ペネトレーションテストよりも脅威モデリング、コードレビュー、自動化ツールの使用、およびファジーテストに重点を置いています。後者の手段の方が、セキュリティのバグを防止または排除する上で、従来のアドホックなペネトレーションテストよりもはるかに厳密です。 FSR のペネトレーションテストは、セキュリティのバグを見つけて修正するというよりも、ソフトウェアのリリース準備ができているかどうかを判断するために役立ちます。 FSR のペネトレーションテストでセキュリティのバグが非常に多く発生した場合、それは前のフェーズが十分に効果的でなかったためです。この場合、単にペネトレーションテストのバグを修正してソフトウェアをリリースするのではなく、前のフェーズで完了する予定であった作業を見直すことが正しい対応と言えます。

5.2 ツール、テストおよびコードレビュー

静的分析ツール、ファジーテスト、およびコードレビューは補完的です。マイクロソフトでは、静的解析コードスキャンツールで詳細な調査を行っており、これらのツールの使用は SDL に不可欠となっています。これらツールは、セキュリティの脆弱性につながる多くのコーディングエラー (特にバッファオーバーラン) を見つけるのに効果的です。ただし、現在の最新技術のツールではすべてのエラーを見つけることはできません。 SDL では、ツールで解決できないエラーを検出したり、ツールの改善の機会を特定するために、依然として手動によるコードレビューが欠かせません。「参考資料」に挙げた Michael Howard による Microsoft Developer Network (MSDN) の記事では、マイクロソフトでエンジニアに指導しているコードセキュリティレビューを実施するための一般的な方法の概要を紹介しています。

ファジーテストに重点を置く方法は、比較的最近 SDL に追加されましたが、今のところ結果は良好です。静的コードスキャンツールとは異なり、ファジーテストツールは、ファイル形式やネットワークプロトコルごとに作成 (または少なくとも設定) する必要があります。このため、静的分析ツールで見落とされたエラーが発見されることが頻繁にあります。脅威モデルは、製品チームがテスト用のインターフェイスとフォーマットの優先度を決定するのに役立ちます。ファジーテストの結果は、全体として確定的なものではありません (これらのツールは限られた数のサイクルで実行され、すべてのバグを検出することが保証されていません) が、手頃なレベルのファジーテストにより、セキュリティの脆弱性として悪用される可能性のある "興味深い" バグが見つかりやすいということが経験的にわかっています。

5.3 投資

必須のセキュリティトレーニングは、マイクロソフトのエンジニアリング要員の人数規模ではかなりの投資になります。トレーニングは、講師が指導する実際のクラスとオンライン資料の組み合わせで提供されます。オンライン資料は、マイクロソフト本社から離れた地域の小規模のエンジニアリングチームにトレーニングを実施する場合に特に役立ちます。講師主導のトレーニングは、セキュリティプッシュやその他の主要な作業を準備しているチーム全体に提供する場合に特に効果的です。このような場合、マイクロソフトの経験では、チームトレーニングは教室でのトレーニングだけでなく、セキュリティプッシュの実行によっても効果があることがわかっています。セキュリティトレーニング (通常は半日) は、ワークグループ内の全員がセキュリティに集中することで効果が増幅されます。

過去数年間、マイクロソフトがセキュリティに重点を置くにつれ、中心となるセキュリティチーム (SWI チーム) の重要性が増してきました。設計では、マイクロソフトのエンジニアリング全体の人数に比べるとこのチームの規模は小さく、より安全なソフトウェアを作成する責任とリソースが確実に製品チームに属していること "評価" するアプローチに重点を置いています。この評価に重点を置く方法には、トレーニングとツールの重視、製品チームが自らの問題を解決できるように手助けをする (チームの代わりに解決するのではありません) セキュリティアドバイザの提供、ソフトウェアのリリース準備状況に関するフィードバックを製品チームに提供するレビュー (FSR を含む) の使用などが含まれます。

5.4 成果

SDL の最終段階のテストは、マイクロソフトのソフトウェアの脆弱性をどの程度取り除き、軽減できるかについてです。セクション 4 で概説した経験では、SDL はこのテストの条件を満たしています。マイクロソフトでは、外部から報告された脆弱性についても、開発中のソフトウェアバージョンへの影響を評価します。最近の経験では、新バージョン用に計画または実装されたセキュリティ手段が、旧バージョンに影響を与えると判明した攻撃を阻止する事例が増えています。最近リリースされた Windows XP Service Pack 2 は、このような方法でレビューされており、計画中でまだ実装されていなかったり公には話題になっていないセキュリティの変更が、旧バージョンの Windows に対して報告された相当数の脆弱性をなくすことがマイクロソフト社外のセキュリティ研究者によってわかっています。

6. まとめ

マイクロソフトの経験から、SDL がセキュリティの脆弱性の軽減に効果があるがわかっています。 SDL の初期の実装 (Windows Server 2003、SQL Server 2000 Service Pack 3、および Exchange 2000 Server Service Pack 3) ではソフトウェアのセキュリティが大幅に向上しており、強化された SDL が反映されたその後のソフトウェアバージョンではソフトウェアのセキュリティがさらに向上しています。

SDL を構成する要素の実装が増加するとともにセキュリティも向上しており、マイクロソフトでは、これを効果的なプロセスのしるしと解釈しています。このプロセスは完全なものではなく、進化を続けており、近い将来に完成することも、進化を止めることもあるとは思われません。

セキュリティ開発ライフサイクル (SDL) の開発と実装は、マイクロソフトにとっては重要な投資であり、ソフトウェアの設計、開発、およびテスト方法の重要な変更です。社会に対するソフトウェアの重要度の高まりにより、マイクロソフトおよび業界全体において、ソフトウェアのセキュリティを継続的に向上させる必要性が強調されています。このため、マイクロソフトの経験を業界全体で共有しようという活動の中で SDL に関するこの文書や特定の技術に関する書籍 (「参考資料」参照) が発行されました。

7. 謝辞

この文書の最初の執筆は、2002 年末に現在の筆者による共同執筆という形で始まりました。 SDL が進化するにつれて、草稿が改訂され、現在のバージョンは 2004 年の夏から秋にかけて準備されました。執筆者は、SDL の定義と改良に貢献していただいた Matt Thomlinson、Matt Lyons、Jamil Villani、および Eric Bidstrup (すべて Microsoft Secure Windows Initiative チームのメンバ) に感謝の意を表します。上記の方々に加えて、マイクロソフトの Scott Charney と Phil Reitinger およびカーネギーメロン大学の Jeannette Wing 氏に対しては、草稿に特に有益な助言をいただいたことに感謝いたします。さらに、Martin Abadi、Virgil Gligor、Dick Kemmerer、Chris Mitchell、Fred Schneider、Neeraj Suri、および James Whittaker にはこの文書への意見と提案をいただいたことに感謝いたします。

8. 参考資料

Craig Mundie 著「Trustworthy Computing」ホワイトペーパー (英語)

Michael Howard 著「Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users」(MSDN Magazine、2004 年 11 月) (英語)

Michael Howard 著「Expert Tips for Finding Security Defects in Your Code」(MSDN Magazine、2003 年 11 月) (英語)

Michael Howard、David LeBlanc 共著『Writing Secure Code』第 2 版、Microsoft Press、Redmond、Washington、2003 年 (英語)

Frank Swiderski、Window Snyder 共著『Threat Modeling』Microsoft Press、Redmond Washington、2004 年 (英語)

9. ご注意

このドキュメントに記載されている情報は、このドキュメントの発行日におけるマイクロソフトの見解を示すものです。マイクロソフトは市場の変化に対応する必要があるため、このドキュメントの内容に関する責任をマイクロソフトは問われないものとします。また、発行日以降に発表される情報の正確性を保証できません。

このドキュメントに記載された内容は情報提供のみを目的としており、明示的、黙示的または法的に関わらず、本書中の情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

Microsoft、MSDN、Windows、および Windows Server は、米国 Microsoft Corporation の米国およびその他の国における商標または登録商標です。