Q&A：ファジングテスト、エージェントのインストルメンテーション、Defensics

ファジングテストに関する質問

ファジングツールの誤検知/未検知率を下げるにはどうすればよいですか？

通常、ファジングには誤検知率が存在しませんが、テストを実行する際には、1つのテストケースを単独で実行してもすぐには再現されない結果が生じることがあります。想定外の動作やクラッシュなどがその例です。これによりさまざまな混乱が生じます。

システムと入力を等しい状態にしておいた場合、つまり同じテストケースを使用した場合は、SUTで常に同じ結果が得られるはずです。ところが、たとえば20のテストケースを実行する場合、テストケース20でバッファーがオーバーフローし、クラッシュが生じたとしても、ターゲットシステムを再起動してテストケース20を実行しただけではこの現象が起こりません。

外部インストルメンテーション（Agent Instrumentation Framework）を利用すると、テストケースごとにインストルメント化できるため、プロセスが使用するメモリやそれを検出する機能など、1 つのテスト ケースの影響をすぐに確認できます。

ファジングを停止するタイミングはどうすれば分かりますか？

それは結局メトリクスの問題になります。ファジングは、ネガティブテストであるため範囲に限界がないことが問題になります。つまり、テストケースの数に裁量の余地が大きいということです。たとえば、パケット内の1つのフィールドを受け取り、1文字（たとえば「A」）を挿入する場合、これが1つのテストケースになります。フィールドにAを2つ挿入するテストケースを作成することもできます。フィールドにAを10億個挿入するまで同様のテストケースを続けることも可能です。その間のすべてがテストケースになります。特定の機能分野に対して10億のテストケースを用意することは、マーケティングスライドを飾り立てるには良いかもしれませんが、ターゲットシステムに対して実行するにはあまり意味がありません。

優れたファジングツールに必要な要素の定義には、さまざまなメトリクスがあります。まず、質の高い異常系ケースです。正規化データベースには、コードのさまざまな部分に挿入されたときに問題を引き起こす可能性が高い異常系ケースを含める必要があります。

次に、特定の関数がクラッシュするかどうかに関する情報を取得するためにインストルメンテーションを適切に設定し、その特定のバグをトリガーするための追加テストケースの実行を不要にする必要があります。たとえば、特定のフィールドのテストでオーバーフローをトリガーする場合、100のテストケースを追加して実行することに無駄な時間を費やす必要はありません。

カバレッジも重要です。ファジングツールは、テスト対象のプロトコルを理解し、プロトコルの全範囲をカバーするテストケースを作成する必要があります。また、テストケースの実行中にプロトコルのステージに深く入り込むことができる必要があります。

Defensicsはこうしたファジング・ツールの好例です。シノプシスのツールはプロトコルを完全に実装しているので、プロトコルのすべての構成要素が反映されています。そのため、モデルを取得し、そのモデルに正規化エンジンで用意された異常系データを乗算してテストケースを動的に作成することができます。

パフォーマンステストにファジングを利用できますか？

シノプシスのファジング手法はパフォーマンステストを意図していません。ファジングはターゲットで実行されているプロトコルの実装を確認することが目的です。

ターゲットをインストルメント化するには、SNMPや外部インストルメンテーションなどのさまざまな方法があるので、ターゲットからパフォーマンス関連のデータを取得することは簡単です。たとえば、テストケースを実行すると、CPUとメモリの使用量が急増することがよくあります。Defensicsは、すべての異なる入力を関連付けるグラフなど、こうしたデータを視覚化するさまざまな手段を提供します。この情報を用いてCPUスパイクの原因となるテストケースを相互に関連付けることができます。その後、特定のテストケースをループし、ターゲットに与える影響を確認できます。しかし、前述したように、Defensicsはロードテスターのようなツールを意図していません。その専用機能を備えた他のツールがあるので、Defensicsプラットフォームではこれを主目的としていません。