セキュリティに関するブリーフィング
セキュリティ バグ バーを Microsoft Team Foundation Server 2010 に追加する
製品ライフサイクルの過程で、ソフトウェア開発チームが直面する数々のタスクの中で最も論争を引き起こすタスクの 1 つが、バグのトリアージです。特定のバグの相対的な重要度を決めること、ひいては、製品リリースまでにバグを解決できない可能性を判断することは、製品開発に関与するあらゆるメンバーにとって重大な問題です。
プログラマ、テスタ、アーキテクト、プログラム マネージャーは、次のように本質的に異なる要因についてトリアージを決定する際に、それぞれ独自の立場での見解があり、その基盤も異なります。
- バグを解決した後に回帰テストを行わなければならないコードの量
- プロジェクトをリリースするまでの時間
- 変更によって影響を受けるユーザーの数
- そのバグが他の問題のテストや解決の妨げになっているかどうか
これらはすべて、製品機能の機能的なバグをトリアージする際に考慮すべき重要な要因であることは認めます。しかし、セキュリティ バグを解決するかどうかを判断する際には、これらの要因は何の役割も果たしません。ここで言うセキュリティ バグとは、製品におけるセキュリティの脆弱性につながりかねないバグのことです。セキュリティ バグの分類は、客観的かつ一貫性のあるものでなければなりません。攻撃者にとっては、脆弱性がコード完成マイルストーンのほんの 1 週間前に見つかったことなどどうでもいいことで、その脆弱性を悪用することには変わりありません。
今回のコラムでは、マイクロソフト社内の製品チームやオンライン サービス チームが採用し、セキュリティ開発ライフサイクル (SDL) の要件にもなっている、客観的セキュリティ バグ分類システム ("バグ バー") について説明します。また、Microsoft Team Foundation Server 2010 を使用して、この分類システムをユーザー独自の開発環境に組み込む方法についても紹介します。
DREAD
現在マイクロソフト社内で使われるようになったバグ バーについて説明する前に、それ以前にマイクロソフトでセキュリティ バグを分類する取り組みとして行われていた DREAD について触れておきましょう。DREAD とは、次の 5 つの分類方法の頭文字からなる略語です。
- Damage Potential (損傷可能性)
- Reproducibility (再現性)
- Exploitability (悪用の可能性)
- Affected Users (影響を受けるユーザー数)
- Discoverability (判明の可能性)
新しいセキュリティ バグをファイリングする場合、DREAD パラメーターの各分類項目に 1 から 10 までの値を割り当てることになります。値 10 は深刻度が最も高く、値 1 は最も低くなります。その後、各項目に割り当てられた値は、DREAD の全体評価として平均値が取られます。たとえば、Doug という開発者が、所属チームの新しい Web アプリケーションの管理ポータル ページに、ブラインド SQL インジェクションに関する脆弱性があることを発見したとします。このとき、Doug はこの脆弱性を 図 1のように分類するとします。
図 1 セキュリティの脆弱性の開発者による分類
| DREAD パラメーター | 評価 | 根拠 |
| Damage Potential | 5 | 攻撃者は、製品データベース内のデータを読み取ったり変更したりできる可能性がある |
| Reproducibility | 10 | 毎回再現できる |
| Exploitability | 2 | 悪用するには専門的知識が必要で、膨大な時間がかかる |
| Affected Users | 1 | ユーザー ベースの中でも少数のサブセットにしか影響しない |
| Discoverability | 1 | 影響するページには、どのユーザー ページからもリンクされていない |
| 全体評価 | 3.8 |
図 1 に示す分類は、かなり率直かつ実質的であるように思えます。しかし、Doug の同僚でテスターでもある Tina は、まったく同じ脆弱性をまったく違う立場から見ていると考えてください (図 2 参照)。
図 2 同じバグのテスターによる分類
| DREAD パラメーター | 評価 | 根拠 |
| Damage Potential | 10 | 攻撃者は、製品データベース内のデータを読み取ったり変更したりできる可能性がある |
| Reproducibility | 10 | 毎回再現できる |
| Exploitability | 10 | インターネット上に公開されている自動ツールを使えば簡単に悪用できる |
| Affected Users | 10 | 重要な管理ユーザーに影響する |
| Discoverability | 10 | 影響を受けるページ "admin.aspx" は攻撃者が簡単に推測できる |
| 全体評価 | 10.0 |
Tina はブラインド SQL インジェクション攻撃を自動的に行うツールがあることを認識しているため、Exploitability を 10 と評価しました。これに対して Doug は、手動による攻撃は困難であると見ていたため、Exploitability を 2 と評価しました。Doug は、システム ユーザーのごく一部にしか影響しないため Affected Users を 1 と評価しましたが、Tina は影響を受けるユーザーが管理ユーザーであるため 10 と評価しています。おそらく、最も考えなければならないパラメーターは Damage Potential です。Doug も Tina もまったく同じ根拠を挙げているにもかかわらず、評価の値が異なっています。
ここで問い掛けなければならない疑問点は、「どちらのチーム メンバーの DREAD 評価が適切だろうか」ではなく、「このように主観によって結果が異なるシステムを信頼できるだろうか」ではないでしょうか。Tina がこのバグの最初の発見者であれば、リリース前には確実に解決されることになるでしょう。しかし、Doug が最初の発見者であれば、解決が先送りされ、アプリケーションは脆弱性を抱えたままリリースされる可能性が高くなります。SDL チームがこのようなシステムは信頼できないと結論付けたため、マイクロソフトはその結論を受け、より一貫性の高い手法としてセキュリティ バグ バーを開発しました。
Microsoft セキュリティ バグ バー
Microsoft セキュリティ バグ バーは、脆弱性をその影響力に基づいて分類します。バグをファイリングするときは、STRIDE 値の一覧からセキュリティの影響度をバグに割り当てることから始めます。STRIDE も頭文字からなる略称ですが、この場合は脅威を分類するために使用します。DREAD とは異なり、STRIDE は今もなお SDL によって使用されており、SDL Threat Modeling Tool など、複数の SDL ツールの中核コンポーネントです。STRIDE は次の脅威の頭文字をとったものです。
- Spoofing (なりすまし)
- Tampering (改ざん)
- Repudiation (否認)
- Information Disclosure (情報漏えい)
- Denial of Service (DoS: サービス拒否)
- Elevation of Privilege (EoP: 特権の昇格)
ただし、バグを分類し、トリアージするには、STRIDE という幅広い脅威のカテゴリだけでは不十分です。ほとんどの場合、バグがクライアント側のコードに影響するか、サーバー側のコードに影響するかを把握する必要があります。たとえば、単一のユーザーだけを対象とする DoS 攻撃は、サーバー全体を対象とする攻撃よりも深刻度は低いと考えられます。また、STRIDE とクライアント/サーバーの分類に応じた、バグについての明確なスコープ情報を把握することも必要です。
引き続き DoS 攻撃に関する脆弱性の例を取り上げますが、攻撃を実行できるのはだれか (特権のレベルなど)、およびどの程度の期間その影響が続くのかということも把握する必要があります。匿名ユーザーが悪用できる脆弱性は、認証済みのユーザーのみが悪用できる脆弱性よりも深刻です。サーバーを物理的に再起動するまで影響を受け続ける脆弱性は、ほんの数秒間利用できない状態にする脆弱性よりも深刻です。
STRIDE の主要分類にスコープの特性を追加することで、バグのトリアージを行う担当者は、バグの深刻度をバグ バーで調べる際にこうした情報を使用できるようになります。図 3 に、Security Development Lifecycle Process Guidance ドキュメント Version 4.1a (英語) で公開されているセキュリティ バグ バーのサンプルを示します。バグ バーでは、Critical (致命的)、Important (重要)、Moderate (中)、Low (低) という 4 段階の深刻度レベルを定義します。
図 3 セキュリティ バグ バーのサンプル
| STRIDE 値 | クライアント/ サーバー |
スコープ | 深刻度 |
| Spoofing | クライアント | 攻撃者が、"既定のシナリオや一般的なシナリオでユーザーが正当な信頼の決定を下すために信用しなければならない UI" と、見た目が同じで内容が異なる UI を表示できる。信頼の決定とは、特定のエンティティ (システム、またはある具体的なローカル ソースやリモート ソース) が表示するなんらかの情報を、常にユーザーが信用して行動することです。 | Important |
| 攻撃者が、"ある特定のシナリオで信頼することが通例となっている UI" と、見た目が同じで内容が異なる UI を表示できる。"信頼することが通例となっている" とは、ユーザーが OS やアプリケーションの通常操作に基づき、普通に使い慣れている操作で、通常は "信頼の決定" とは考えられない操作のことです。 | Moderate | ||
| 攻撃者が、"大きな攻撃シナリオの一部である 1 つの UI" と、見た目が同じで内容が異なる UI を表示できる。 | Low | ||
| サーバー | 厳密な認証を提供するように設計されて市場に投入されている "プロトコルを使用して"、サーバーに接続しているコンピューターを、選択した別のユーザーやコンピューターに見せかけることができる。 | Important | |
| 厳密な認証を提供するように設計されて市場に投入されているプロトコルを使用して、クライアント ユーザーまたはクライアント コンピューターを、無作為に選択した別のユーザーやコンピューターに見せかけることができる。 | Moderate | ||
| Tampering/ Repudiation | クライアント | 任意のユーザー データや、一般的なシナリオや既定のシナリオで信頼の決定を下すために使用するデータを永続的に変更し、OS やアプリケーションの再起動後も変更された状態を維持する。 | Important |
| 任意のデータを一時的に変更し、OS やアプリケーションが再起動されるとその変更が維持されない。 | Low | ||
| サーバー | 任意のユーザー データや、"一般的なシナリオや既定のシナリオ" で信頼の決定を下すために使用するデータを永続的に変更し、OS やアプリケーションの再起動後も変更された状態を維持する。 | Important | |
| 任意のユーザー データや、"ある特定のシナリオ" で信頼の決定を下すために使用するデータを永続的に変更し、OS やアプリケーションの再起動後も変更された状態を維持する。 | Moderate | ||
| "一般的なシナリオや既定のシナリオ" でデータを一時的に変更し、OS やアプリケーションが再起動されるとその変更が維持されない。 | Moderate | ||
| "ある特定のシナリオ" でデータを一時的に変更し、OS やアプリケーションが再起動されるとその変更が維持されない。 | Low | ||
| Information Disclosure | クライアント | 公開するつもりのない、または公開するよう設計されていないシステム情報などのシステム上の情報を、攻撃者が検索したり、読み取ったりできる。 | Important |
| 公開するつもりのない、または公開するよう設計されていないシステム情報などのシステム上の情報を、攻撃者が "既知の場所" から読み取ることができる。 | Moderate | ||
| 特に対象が定められていない情報漏えい (無作為のデータ漏えい)。 | Low | ||
| サーバー | 公開するつもりのない、または公開するよう設計されていないシステム情報などのシステム上の情報を、攻撃者が "あらゆる場所から" 検索したり、読み取ったりできる。 | Important | |
| 公開するつもりのない、または公開するよう設計されていないシステム情報などのシステム上の情報を、攻撃者が "既知の場所" から容易に読み取ることができる。 | Moderate | ||
| 実行時データなど、特に対象が定められていない情報漏えい (無作為のデータ漏えい)。 | Low | ||
| Denial of Service | クライアント | "システムを損傷する DoS": システムやコンポーネントの再インストールが必要。 | Important |
| "永続 DoS": コールド リブートが必要、またはブルー スクリーンやバグ チェックの原因になる。 | Moderate | ||
| "一時 DoS": アプリケーションの再起動が必要。 | Low | ||
| サーバー | 匿名ユーザー、少量のデータを送信することで "容易に悪用できる" か、さもなければすぐに誘導される。 | Important | |
| 匿名ユーザー、既定のインストールまたは一般的なインストールでは増幅されない一時 DoS。 | Moderate | ||
| 認証済みユーザー、永続 DoS。 | Moderate | ||
| 認証済みユーザー、既定のインストールまたは一般的なインストールで増幅される一時 DoS。 | Moderate | ||
| Elevation of Privilege | クライアント | リモート ユーザー、任意のコードを実行できるか、意図したよりも高い特権を取得できる。 | Critical |
| リモート ユーザー、広範囲に及ぶユーザー操作を伴う任意のコードの実行。 | Important | ||
| ローカル、特権の低いユーザーが自身を別のユーザー、管理者、またはローカル システムに昇格できる。 | Important | ||
| サーバー | 匿名リモート ユーザー、任意のコードを実行できるか、意図したよりも高い特権を取得できる。 | Critical | |
| 認証済みリモート ユーザー、任意のコードを実行できるか、意図したよりも高い特権を取得できる。 | Important | ||
| 認証済みローカル ユーザー、任意のコードを実行できるか、意図したよりも高い特権を取得できる。 | Important |
このシステムが機能するためには、使用するバグ追跡データベースに STRIDE のセキュリティへの影響度についてのフィールドが必要です。このフィールドを用意することで、セキュリティ バグと機能バグを簡単に切り分けられるようになり、適切なバグ バーの分類も決定できます。バグのセキュリティへの影響度を追跡することは非常に重要で、実際、これを行うことが SDL の要件の 1 つにもなっています。さいわいなことに、ほとんどの場合、実に簡単に行うことができます。そこで、ここからは、Team Foundation Server (TFS) を使用して、チーム プロジェクトのバグ作業項目に、セキュリティへの影響度を示すフィールドとバグ バーの評価を追加する方法について説明します。
バグ バーの機能を Team Foundation Server に追加する
TFS チーム プロジェクトにバグ バーを追加するには、プロジェクトの作成元の基盤となるプロセス テンプレートに変更を加える必要があります。今回のコラムの目的から、プロジェクトは TFS 2010 ベータ 2 に付属する MSF-Agile for Software Development version 5.0 (ベータ) テンプレートから作成されているものとします。ただし、MSF for CMMI Process Improvement テンプレートなどの別のプロセス テンプレートや、サードパーティ製のカスタム テンプレートを主に使用する場合でも、テンプレートの編集に使用する手法は同じです。
まず、作業する TFS 2010 サーバーのプロセス テンプレート マネージャーを開きます。これを行うには、チーム エクスプローラー ウィンドウでサーバーのコンテキスト メニューを表示し、[Team Project Collection Settings] (チーム プロジェクト コレクションの設定)、[Process Template Manager] (プロセス テンプレート マネージャー) の順にクリックします (図 4 参照)。
.png)
図 4 TFS 2010 サーバーのプロセス テンプレート マネージャー
プロセス テンプレート マネージャーでは、[MSF for Agile Software Development v5.0] を選択し、[Download] (ダウンロード) をクリックして、テンプレートのソース ファイルをローカルにダウンロードします。ダウンロードしたソース ファイルは、選択したフォルダーに保存します。
ダウンロードが完了したら、プロセス テンプレート マネージャーを閉じます。作業項目の種類 Bug (バグ) にバグ バーを追加するため、今 MSF-Agile テンプレートをダウンロードしたフォルダーを開き、ファイル \WorkItem Tracking\TypeDefinitions\Bug.xml を任意の XML エディターで開きます。
まず、セキュリティの影響度 (Effect)、セキュリティに影響するスコープ (EffectScope)、およびバグ バーの深刻度 (BugBarSeverity) に関する 3 つのフィールドを追加します (これから説明する理由により、バグ バーの深刻度と従来からある Severity フィールドは別に扱います)。witd:WITD/WORKITEMTYPE/FIELDS 要素の下に、図 5 に示す XML のブロックを追加します。
図 5 セキュリティの影響度、セキュリティに影響するスコープ、およびバグ バーの深刻度に関するフィールドの追加
<FIELD
reportable="dimension"
type="String"
name="Effect"
refname="MSDN.SDL.Security.Effect">
<HELPTEXT>The effect of the security bug</HELPTEXT>
</FIELD>
<FIELD
reportable="dimension"
type="String"
name="EffectScope"
refname="MSDN.SDL.Security.Effect.Scope">
<HELPTEXT>The scope of the effect of the security bug. This value is used to determine the default bug bar severity</HELPTEXT>
</FIELD>
<FIELD
reportable="dimension"
type="String"
name="BugBarSeverity"
refname="MSDN.SDL.Security.Severity.BugBar">
<HELPTEXT>The suggested severity of the bug as determined by the security bug bar</HELPTEXT>
</FIELD>
このコードでは、3 つの新しいフィールドを定義し、そこにフィールド名、型、およびヘルプ テキストを含めています。ただし、ロジックはまだ実装していません。最初に追加するロジックは、フィールドに使用できる値を限定する許容値の制約です。
Effect の許容値は各 STRIDE 値で、Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、および Elevation of Privilege のいずれかです。Attack Surface Reduction を許容値に含めておくのもお勧めです。これ自体は脆弱性とは直接結び付きませんが、将来脆弱性が生じる可能性を削減するよいチャンスになります。最後に、Not a Security Bug を許容値に追加します。これは、セキュリティに影響しない通常の機能バグに使用します (図 6 参照)。
図 6 Effect に関する許容値の追加
<FIELD
reportable="dimension"
type="String"
name="Effect"
refname="MSDN.SDL.Security.Effect">
<HELPTEXT>The effect of the security bug</HELPTEXT>
<ALLOWEDVALUES>
<LISTITEM value="Not a Security Bug" />
<LISTITEM value="Spoofing" />
<LISTITEM value="Tampering" />
<LISTITEM value="Repudiation" />
<LISTITEM value="Information Disclosure" />
<LISTITEM value="Denial of Service" />
<LISTITEM value="Elevation of Privilege" />
<LISTITEM value="Attack Surface Reduction" />
</ALLOWEDVALUES>
<DEFAULT from="value" value="Not a Security Bug" />
</FIELD>
EffectScope については、バグ バーで可能性のあるスコープ項目をそれぞれ概要にまとめ、その概要を EffectScope の許容値に追加します (図 7 参照)。
図 7 EffectScope に関する許容値の追加
<FIELD
reportable="dimension"
type="String"
name="EffectScope"
refname="MSDN.SDL.Security.Effect.Scope">
<HELPTEXT>The scope of the effect of the security bug. This value is used to determine the default bug bar severity</HELPTEXT>
<ALLOWEDVALUES>
<LISTITEM value="Not Applicable" />
<LISTITEM value="Client - Spoofed trusted UI in common/default scenario" />
<LISTITEM value="Client - Spoofed trusted UI in specific other scenario" />
<LISTITEM value="Client - Spoofed UI as part of a larger attack scenario" />
<LISTITEM value="Server - Spoofed specific user or computer over secure protocol" />
<LISTITEM value="Server - Spoofed random user or computer over secure protocol" />
<LISTITEM value="Client - Tampered trusted data that persists after restart" />
<LISTITEM value="Client - Tampered data that does not persist after restart" />
<!-- additional allowed values omitted for brevity -->
</ALLOWEDVALUES>
<DEFAULT from="value" value="Not Applicable" />
</FIELD>
また、Effect の現在値に応じて、EffectScope の許容値をさらに限定することを考えました。Effect が現在 Spoofing に設定されているのであれば、Spoofing 関連の EffectScope だけを有効にすべきです。同様に、Effect が Tampering に設定されているのであれば、Tampering 関連の EffectScope だけを有効にすべきです。これは、WHEN 句要素を FIELD 定義に追加すれば実現できます (図 8 参照)。
図 8 EffectScope の許容値を制限する WHEN 句の追加
<FIELD
reportable="dimension"
type="String"
name="EffectScope"
refname="MSDN.SDL.Security.Effect.Scope">
<HELPTEXT>The scope of the effect of the security bug. This value is used to determine the default bug bar severity</HELPTEXT>
<ALLOWEDVALUES>
<!-- omitted for brevity -->
</ALLOWEDVALUES>
<DEFAULT from="value" value="Not Applicable" />
<WHEN field="MSDN.SDL.Security.Effect" value="Not a Security Bug">
<ALLOWEDVALUES>
<LISTITEM value="Not Applicable" />
</ALLOWEDVALUES>
</WHEN>
<WHEN field="MSDN.SDL.Security.Effect" value="Attack Surface Reduction">
<ALLOWEDVALUES>
<LISTITEM value="Not Applicable" />
</ALLOWEDVALUES>
</WHEN>
<WHEN field="MSDN.SDL.Security.Effect" value="Spoofing">
<ALLOWEDVALUES>
<LISTITEM value="Client - Spoofed trusted UI in common/default scenario" />
<LISTITEM value="Client - Spoofed trusted UI in specific other scenario" />
<LISTITEM value="Client - Spoofed UI as part of a larger attack scenario" />
<LISTITEM value="Server - Spoofed specific user or computer over secure protocol" />
<LISTITEM value="Server - Spoofed random user or computer over secure protocol" />
<LISTITEM value="Not Applicable" />
</ALLOWEDVALUES>
</WHEN>
<!-- Additional WHEN elements for the other STRIDE values omitted for brevity -->
</FIELD>
これで、BugBarSeverity フィールドに許容値ロジックを実装する準備が整いました。BugBarSeverity のロジックは、Effect のロジックとはやや異なり、BugBarSeverity フィールドの値をユーザーが直接設定できるようにはしていません。バグ バーをこのように実装するのは、深刻度には脆弱性の特性を反映することが重要であるためです。ユーザーの希望どおりに深刻度を設定できてしまえば、本来の目的がまったく失われてしまうことになります。
BugBarSeverity の許容値の一覧を作成する代わりに、上記で定義したバグ バーの取り決めどおりに、Effect の値を基に WHEN フィールドを使用して、適切な値を BugBarSeverity フィールドにコピーします。たとえば、バグ バーでは、一般的なシナリオまたは既定のシナリオで信頼の決定を下す UI がなりすましの攻撃を受ける可能性のあるバグを Important に分類するように指定されています。そのため、Effect が "Client – Spoofed trusted UI in common/default scenario" のときは、"2 – Important" を BugBarSeverity にコピーします (図 9 参照)。
図 9 BugBarSeverity フィールドに値を設定するロジックの実装
<FIELD
reportable="dimension"
type="String"
name="BugBarSeverity"
refname="MSDN.SDL.Security.Severity.BugBar">
<HELPTEXT>The suggested severity of the bug as determined by the security bug bar</HELPTEXT>
<WHEN field="MSDN.SDL.Security.Effect.Scope" value="Not Applicable">
<COPY from="value" value="4 - Low"/>
</WHEN>
<WHEN field="MSDN.SDL.Security.Effect.Scope" value="Client - Spoofed trusted UI in common/default scenario">
<COPY from="value" value="2 - Important"/>
</WHEN>
<WHEN field="MSDN.SDL.Security.Effect.Scope" value="Client - Spoofed trusted UI in specific other scenario">
<COPY from="value" value="3 - Moderate"/>
</WHEN>
<WHEN field="MSDN.SDL.Security.Effect.Scope" value="Client - Spoofed UI as part of a larger attack scenario">
<COPY from="value" value="4 - Low"/>
</WHEN>
<WHEN field="MSDN.SDL.Security.Effect.Scope" value="Server - Spoofed specific user or computer over secure protocol">
<COPY from="value" value="2 - Important"/>
</WHEN>
<WHEN field="MSDN.SDL.Security.Effect.Scope" value="Server - Spoofed random user or computer over secure protocol">
<COPY from="value" value="3 - Moderate"/>
</WHEN>
<!-- additional WHEN clauses omitted for brevity -->
</FIELD>
ここで値を指定するときに、単に "Critical" や "Important" のように定義するのではなく、"1 – Critical" や "2 – Important" のように値の前に数値をプレフィックスとして追加していることを疑問に思われるかもしれません。これは、TFS が許容値の一覧を自動的にアルファベット順に並べ替えてしまうためです。数値をプレフィックスとして追加しておかないと、表示される選択肢が深刻度の順番に並ばないため、ユーザーが混乱する可能性があります。
また、従来からある MSF-Agile Severity (深刻度) フィールド (Microsoft.VSTS.Common.Severity) の値にも同様のプレフィックスが付けられているため、BugBarSeverity フィールドにもプレフィックスを追加することで、この 2 つのフィールドに関連性があることを強調しています。
Severity と BugBarSeverity の関連性は、テンプレートで設定します。つまり、次の手順として、Severity フィールドの値が、少なくとも BugBarSeverity フィールドの深刻度よりも高くなるよう制約します。チームにビジネス上の明確な理由がある場合、実際の深刻度をバグ バーによって決まる深刻度よりも高く設定してもかまいません。ただし、逆に低く設定することは望んでいません。
この作用を行うには、Effect フィールドの値を基に EffectScope フィールドの値を限定したときに使用したのと同じ手法を使用します (図 10 参照)。
図 10 Severity フィールドの許容値の限定
<FIELD
name="Severity"
refname="Microsoft.VSTS.Common.Severity"
type="String"
reportable="dimension">
<HELPTEXT>Assessment of the effect of the bug on the project</HELPTEXT>
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="1 - Critical"/>
<LISTITEM value="2 - High"/>
<LISTITEM value="3 - Medium"/>
<LISTITEM value="4 - Low"/>
</ALLOWEDVALUES>
<DEFAULT from="value "value="3 - Medium" />
<WHEN field="MSDN.SDL.Security.Severity.BugBar"value="1 - Critical">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="1 - Critical"/>
</ALLOWEDVALUES>
</WHEN>
<WHEN field="MSDN.SDL.Security.Severity.BugBar" value="2 - Important">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="1 - Critical"/>
<LISTITEM value="2 - High"/>
</ALLOWEDVALUES>
</WHEN>
<WHEN field="MSDN.SDL.Security.Severity.BugBar" value="3 - Moderate">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="1 - Critical"/>
<LISTITEM value="2 - High"/>
<LISTITEM value="3 - Medium"/>
</ALLOWEDVALUES>
</WHEN>
</FIELD>
最後にもう 1 つ Bug 作業項目に変更を加える必要があります。つまり、以下のスニペットに示すように、ここで追加した新しいフィールドの UI コントロールを追加します。作業項目のコントロールは、ドキュメントの witd:WITD/WORKITEMTYPE/FORM/Layout セクションで定義されています。新しいフィールドの追加は課題として残しておきます。ただし、参考のため、メインの TabGroup に新しく "Security" タブを追加し、そこにフィールドを追加する方法を示しておきます。
<Tab Label="Security">
<Control Field Name="MSDN.SDL.Security.Effect" Type="FieldControl" Label="Effect "LabelPosition="Top" />
<Control Field Name="MSDN.SDL.Security.Effect.Scope" Type="FieldControl" Label="Scope" LabelPosition="Top" />
<Control Field Name="MSDN.SDL.Security.Severity.BugBar" Type="FieldControl" Label="Bug Bar Rating" ReadOnly="True" LabelPosition="Top" />
</Tab>
これで、Bug 作業項目の定義の編集は終わりです。ただし、新しいバグ バー機能を使用する前に、変更したプロセス テンプレートの定義を Team Foundation Server にインポートして戻す必要があります。これには 2 つの方法があります。1 つは既存の MSF-Agile for Software Development テンプレートを新しいテンプレートに置き換える方法、もう 1 つは新しいテンプレートを以前のバージョンとサイドバイサイドで追加する方法です。
既存のテンプレートを置き換える場合は、プロセス テンプレート マネージャーを開き、MSF-Agile for Software Development テンプレートを選択して、[Delete] (削除) をクリックします。この操作は元に戻せないことに注意してください。Team Foundation Server を再インストールしなければ、元のテンプレートに戻すことはできません。既存の MSF-Agile テンプレートを削除したら、[Upload] (アップロード) をクリックして、編集済みのプロセス テンプレートを含むフォルダーを選択します。テンプレートは、以前とまったく同様に "MSF-Agile for Software Development" と表示されますが、今後このテンプレートから作成されるプロジェクトには、バグ バー機能が含まれることになります。
新しいテンプレートに置き換えるのではなく、既存の MSF-Agile テンプレートとサイドバイサイドで追加する場合は、既存のテンプレートと競合しないように、新しいテンプレートの名前を変更する必要があります。これを行うには、もう 1 回編集を行う必要があります。任意の XML エディターで、最初にテンプレートをダウンロードしたフォルダーにある ProcessTemplate.xml ファイルを編集します。ProcessTemplate/metadata/name 要素の値を "MSF for Agile Software Development plus Bug Bar" のような名前に変更してファイルを保存し、エディターを終了します。プロセス テンプレート マネージャを開き、[Upload] (アップロード) をクリックし、編集済みのテンプレートを含むフォルダーを選択します。新しいテンプレートが指定した名前で表示されます。今後このテンプレートから作成されるプロジェクトにはバグ バーが含まれます。
バグ バーを使用して終了基準を判断する
当然ながら、どのようなプロセス テンプレート機能であっても、それを支える組織的なポリシーがなければ、あまり役には立ちません。マイクロソフトの社内開発チームの標準では、バグ バーの "Low" カテゴリよりも高い深刻度に分類されるセキュリティ バグはリリース前に解決しなければなりません。この標準は、どんなに製品リリースが間近に迫っていようとも、決して緩められることはありません。こうした手法により、バグが影響する可能性とそのスコープのみに基づいて、セキュリティ バグのトリアージが客観的かつ確実に行われます。
これが、一般的な Severity フィールドの値を EffectScope フィールドに基づいて制約するだけでなく、BugBarSeverity フィールドを別に定義している理由です。厳密にセキュリティの観点から言えば、製品に深刻度 Critical のバグが含まれていたとしても、それがセキュリティに影響しなければ問題ありません。問題にするのは、BugBarSeverity フィールドに "4 – Low" よりも高い深刻度を持つバグだけです。そのようなバグがあれば、リリース前に解決しなければなりません。
実施要請
セキュリティ バグのトリアージに一貫性があり、客観的なプロセスがなければ、セキュリティが確保されるアプリケーションは作成できません。マイクロソフトのセキュリティ バグ バーは、これを実現する優れた方法です。このセキュリティ バグ バーは、ソフトウェアの脆弱性が削減されることが実証されている、セキュリティ開発ライフサイクル (SDL) の重要なコンポーネントです。
また、Microsoft Team Foundation Server を使用していれば、バグ バー機能を簡単にチーム プロジェクトに追加できます。その結果、チームはセキュリティ バグを簡単かつ適切に分類できるようになり、開発者がセキュリティの専門家になる必要もありません。
最後に、Visual Studio 2010 向けの MSF-Agile + SDL プロセス テンプレートをダウンロードすることをお勧めします。このプロセス テンプレートは、Visual Studio 2010 のリリース後すぐに microsoft.com/sdl から無償で入手できるようになる予定です。このプロセス テンプレートには、このコラムで説明したバグ バーが組み込まれているだけでなく、よりセキュアなソフトウェアを作成できるように設計された機能が多数組み込まれています。
Bryan Sullivan は、マイクロソフトのセキュリティ開発ライフサイクル チームのセキュリティ プログラム マネージャーであり、Web アプリケーションと .NET のセキュリティ問題を専門に扱っています。『Ajax セキュリティ』(毎日コミュニケーションズ、2008 年) の著者でもあります。
この記事のレビューに協力してくれた技術スタッフの Brian Harry に心より感謝いたします。