ソフトウェア・インテグリティ

 

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

エージェントのインストルメンテーションを利用したファジングに関する前回のWebセミナーで寄せられた、ファジングテストに関するご質問に対する回答、説明、推奨事項を用意しました。

ファジングテストに関する質問、回答、推奨事項

作成者:Rikke KuipersDennis Kengo Oka

最近のファジングテストに関するWebセミナーでは、Defensics製品マネージャーのRikke KuipersとシニアソリューションアーキテクトのDennis Kengo Okaが、エージェントのインストルメンテーションを利用してインフォテインメント・システムとテレメータ装置のファジングを向上させる方法について説明しました。視聴者からはファジングテスト、Agent Instrumentation Framework、Defensics、シノプシスのファジングテスト・ツールに関する質問が寄せられました。そこで、これらの質問にここでお答えしたいと思います。

Webセミナーを視聴する

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

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

通常、ファジングには誤検知率が存在しませんが、テストを実行する際には、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プラットフォームではこれを主目的としていません。

Defensicsに関する質問

シノプシスはAUTOSAR Classic Platformをターゲットにしたエージェントを開発していますか?

AUTOSAR Classic Platform専用のエージェントは開発していませんが、ユーザーが独自のエージェントを作成して実行できるようになっています。シノプシスのエージェントフレームワークはユーザーが必要なエージェントを作成できる柔軟性を備えているため、Defensicsファジング・ツールを使用すれば、その中で使用されるインストルメンテーションを誰でも簡単に拡張できます。エージェント自体は単純なPythonスクリプトであり、実行できるエージェントは無数にあります。たとえば、AUTOSAR Classic Platformでも、その他のターゲットシステムでも、テストする機能を自分の環境に手軽にドロップできるスケルトン・エージェントがあります。

ファジング・ツールはセキュリティ上の脆弱性によって引き起こされる異常を理解するために、通常の状況でのプロトコルの使われ方を認識している必要がありますか?

いいえ。Defensicsでは仕様ベースのファジング手法を採用しているので、モデル全体がツール自体にミラーリングされ、それに基づいてテストケースを実行および生成できます。Defensicsは、基本的にSUTに対する本物のエンドポイントのように動作します。プロトコルを完全に理解しているので、(うまくいけば)ターゲットで特定の例外をトリガーするテストケースを作成し、プロトコル・インストルメンテーション自体を使用してターゲットの正常性を評価できます。

プロトコルを理解しているので、たとえば、特定の機能をテストする一連のメソッドやパッケージを実行することもできます。たとえば、Bluetoothの場合は、ターゲットへのオーディオ・ファイルのストリーミングをテストできます。これには、ターゲットへの接続から、ストリーミングや切断まで、すべてが含まれます。このシーケンスが一定の時間枠(プロトコルに応じて500または1,000ミリ秒)で実行され、ターゲットから返されるメッセージに関して正しく実行されれば、テストケース合格のマークを付けることができます。Defensicsはプロトコル自体がそのレベルの認識を持っています。

ネットワーク通信の場合、SUTに送信されるデータの速度を制御できますか?

はい。SUTに送信されるデータの速度を制御できますが、プロトコルによって大きく異なります。270を超えるプロトコルがあり、各プロトコルが固有のコンフィギュラブルなカスタムオプションを備えている場合があります。たとえば、CAN Busでは、フレームレート制限の設定を使用して、1秒あたりにバスに注入されるフレームの量を制御できます。無線での注入用にBluetoothで設定できるオプションや、各種プロトコルに対応するその他のオプションなど、さまざまなオプションがあります。

今すぐWebセミナーを視聴する

 

この著者によるその他の情報