トリアージの例

この例では、セキュリティー・アナリストが使用する AppScan® Source トリアージ・ワークフローについて説明します。トリアージ・ワークフローは、ビジネス上の要求によって変わる場合があります。

企業のセキュリティー・アナリストを務める Jones さんは、スキャン結果をトリアージしたいと考えています。彼は似たような検出結果をグループ化して優先順位を付けた後、問題の解決を担当する開発者に検出結果を送信します。

Jones さんはまず、アプリケーションのソース・コードをスキャンします。スキャンが完了すると「トリアージ」パースペクティブで評価を開きます。スキャンによって生成された約 2,000 件の検出結果はすべて、「検出結果」ビューで確認できます。ただし、Jones さんは最初に結果の概要を把握するために、「脆弱性マトリックス」ビューを開きます。このビューには、重大度と検出結果のタイプ (セキュリティーまたはスキャン範囲) ごとの内訳が表示されます。スキャン範囲検出結果と要確認セキュリティー検出結果については、詳しく調査してリスクを判別する必要があります。

「脆弱性マトリックス」ビューで、Jones さんは高重大度の確定セキュリティー検出結果が 8 件あることを確認しました。8 件の確定検出結果を示すマトリックス・ボックスをクリックして、自動的にフィルターを作成すると、「検出結果」ビューが更新されて該当する 8 件の重大な問題だけが表示されます。Jones さんは、これらの問題をバグとして処理することにしました。彼は 8 件のすべてを選択して障害追跡システムに送信します。続いて、彼は「脆弱性マトリックス」ビューでフィルターをリセットします。

Jones さんが次に注目するのは、「評価の概要」ビューです。彼は 2,000 件の検出結果に 6 つ以上の脆弱性タイプが含まれていることに気付きました。検証の問題に集中することに決めた彼は、「評価の概要」ビューで別のフィルターを作成します。グラフで Validation.EncodingRequired および Validation.Required をクリックし、「検出結果」ビュー内の検出結果の数を、約 500 個に減らします。

検出結果を 500 件に減らしても、トリアージするのは困難です。そこで、Jones さんは結果をさらに絞り込むことにしました。彼は「評価の概要」で作成したフィルターを補強するために、「フィルター・エディター」ビューで高重大度の要件をフィルターに追加します。これで、検出結果表に表示されている検出結果は、150 件になりました。

ファイル名を基準に検出結果をソートしたところ、結果の一部は、ある特定のサード・パーティー・ライブラリーに含まれるコードで検出されたことがわかりました。Jones さんは、このライブラリーは分離して使用されていることを知っているため、このセキュリティー問題に対処するつもりはありません。彼がこれらの検出結果を除外すると、直ちに「検出結果」ビューとメトリックが更新されます。以降のスキャンでは、これらの結果が引き続き検出されますが、それらの検出結果は分離されるためメトリックには寄与しません。

Jones さんは、タイプが Validation.Required である、重大度の高い要注意セキュリティー検出結果がいくつかあることに気付きます。彼はデータが検証されずに使用されていることを把握しました。そこで、これらの検出結果を要確認から確定にプロモートすることにします。この変更を行う際に、彼はこの変更について説明する注釈を追加します。その上で、「変更された検出結果」ビューで修復の優先順位を付けるため、または検出結果をレビューするために、リマインダーとして自分自身に検出結果をメールで送信します。

続いて Jones さんはファイル名を基準に検出結果を再度ソートします。すると、検出結果の中には、バックエンド・サーバーで検出されたもの、ユーザー・インターフェースで検出されたものがあることに気付きます。すべてのバックエンドの検出結果を選択し、Backend Server - Validation Required というラベルを付けた新規バンドルを作成します。残りの検出結果を選択し、それらを UI - Validation Required というラベルを付けたバンドルに入れます。トリアージは、対象を重大度の高い Validation.EncodingRequired タイプに絞り込んで続行されます。

この日の終わりまでに、Jones さんは 12 個のバンドルを作成しました。1 日で、彼はグラフ、フィルダー、脆弱性マトリックスを使用して、ビューに表示される検出結果を一度で管理可能な数にまで絞り込みました。場合によっては、彼は個々の検出結果をバンドルに含めます。また、重要でない検出結果を除外することもあります。ときには、特定の検出結果を対象に新しいバンドルを作成することも、検出結果を既存のバンドルに追加することもあります。

現在 Jones さんがレビューしているバンドルは 12 個です。Backend Server - Validation Required バンドルおよび UI - Validation Required バンドルを、会社の障害追跡システムに送信して、これらの問題となる分野の開発者に通知します。

Jones さんは、「バンドル」ビューに移動し、Backend Server - Validation Required バンドルを開きます。「Backend Server - Validation Required」というタイトルの新規ビューが開き、バンドルに入れた検出結果のリストが表示されます。彼はこのバンドルを障害追跡システムに送信します。その夜遅く、開発者が Rational® ClearQuest® にログインして、自分に割り当てられたバグがあることを確認した場合、AppScan® Source for Development で検出結果を開くことができます。

Jones さんは他のバンドルをレビューします。彼はバンドルの一部を障害追跡システムに送信し、他のバンドルを同僚にメールで送信します。ただし、一部のバンドルには、さらにレビューする際にそれほど重要にはならない検出結果が含まれています。それらの重要性の低い検出結果を、By Design および Irrelevant という 2 つの新規バンドルに移動します。Jones さんは、それらの検出結果は許容できるものとして判断し、コードの変更を行うつもりはありません。Jones さんは、By Design および Irrelevant の検出結果だけでなく、Cryptography.PoorEntropy のすべての検出結果も自分にとって重要ではないと認識します。彼は、これらの暗号化呼び出しにはエントロピーが不十分であることを理解しました。高速なコンピューターであれば 1 週間未満で鍵を解読できる可能性もありますが、暗号化された後 2、3 時間でデータが役に立たなくなるようなアプリケーションにとってこれは大した問題ではありません。Jones さんは、これらの検出結果も削除することにしました。

そこで Jones さんは、By Design バンドルおよび Irrelevant バンドルを「プロパティー」ビューの「除外されたバンドル」リストに追加します。また、フィルター・エディターを開いて、脆弱性タイプ Cryptography.PoorEntropy の別のフィルターを作成し、Crypto という名前でフィルターを保存して、Crypto フィルターの動作を「反転 (Inverted)」に設定します (「フィルターの選択」ダイアログ・ボックスで、「フィルターの反転 (Invert filter)」を選択します)。彼は、スキャンを開始して帰宅の途に就きます。次のスキャンが完了するまでは、メトリックにこれらの除外は反映されません。