ソフトウェアの脆弱性検出におけるファジングの活用

第3回 開発ライフサイクルにおけるファジングの活用

この記事を読むのに必要な時間:およそ 1.5 分

ソフトウェアに対する脆弱性の混入を防止するには,開発ライフサイクルの全体に渡って脆弱性検出のための仕組みを適切に取り入れることが不可欠です。本特集では,IPA セキュリティセンターの協力の下で,脆弱性検出手法のひとつである「ファジング」について,その特徴や効果,導入に向けた留意点,導入事例などを解説します。

前回説明したように,ファジングを使って脆弱性を減らすためには,開発ライフサイクルの中の適切な場所で活用することが重要です。そこで今回は,ファジングを開発ライフサイクルのなかに取り込むためのポイントを紹介します。

ファジングを活用できる工程

セキュリティ対策は,開発ライフサイクルの特定の工程でのみ実施すればいいというものではなく,要件定義からはじまって廃棄(サービス終了)にいたるまで,すべての工程で継続的に実施しなければなりません。ソフトウェア製品の一般的な開発ライフサイクルは,要件定義,設計,実装,テスト,運用/利用といった工程に分けることができます。図1は,各工程において実施すべきおもなセキュリティ対策をまとめたものです。

図1 開発ライフサイクルの各工程におけるおもなセキュリティ対策

図1 開発ライフサイクルの各工程におけるおもなセキュリティ対策

このうち,特にファジングが有効なのは「実装」「テスト」の2つの工程になります。実装の工程では,セキュアなプログラミングを徹底することや,ソースコードレビューなどによる検証を実施するなど,ソースコードレベルでセキュリティ対策を行うことが重要です。この段階でファジングを活用すれば,早い段階での入力値に関連する問題の発見が期待できます。

一般的に,開発ライフサイクルの後の工程になるほど,脆弱性を修正するコストは増大することが知られています。実装工程で脆弱性を発見できれば,対策を反映させながらコーディングを進めることができるため,テスト工程からの手戻りを減らせるというメリットがあります。また,ファジングツールで生成されるファズを単体テストや結合テスト用の入力値として利用するといった活用方法もあります。ファジングツールのファズ生成には,問題の生じやすい入力値を構成するノウハウが反映されているため,効果的な入力値のチェックが行えるからです。

テスト工程では,ソフトウェアが仕様通りに動くことを確認するために,実際にプログラムを動作させ,その挙動の詳細な検証を行います。具体的には,プログラムの動作を監視して,メモリ破壊などのセキュリティ上の問題が生じていないことを確認するわけです。ファジングはそのための手法のひとつとして,不適切なデータが入力された場合の動作検証に利用することができます。

なお本特集の第4回では,ソフトウェアの開発ライフサイクルの中でどのようにファジングが活用されているのかを具体的な事例を挙げながら紹介する予定です。

ファジングの実施手順

続いて,実際にファジングを実施する際の手順について解説します。一般的に,ファジングは大きく分けて「実行の準備」⁠⁠検出の実行」⁠⁠結果の分析」という3段階の手順で行います図2)⁠

図2 ファジングの実施手順の例

図2ファジングの実施手順の例

ファジングを実行するには,準備段階としてファジングの対象となる入力先の決定や入力するファズの生成,監視方法の決定などを行い,具体的な作業計画を立てる必要があります。入力先やファズは対象とするソフトウェアによって異なります。ファジングに利用するツールの選定もこの段階で行います。ファズはツールによって自動生成することができますが,ツールごとに生成方法や入力方法が違ってくるため,目的に応じて最適なツールを選択しましょう。

監視の方法も対象とするソフトウェアや使用するファジングツールによって異なります。重要なのは,問題が発生した場合にそれを正しく検出できるだけでなく,原因となるファズの特定や,セキュリティ上の脅威につながるかどうかの判断を行うための情報を取得できる方法を選択することです。

準備ができたら,実際に検出作業を実行します。ここで重要なのは,ファジングによって問題が発覚した場合に,どのファズが原因になったのかをしっかりと特定することです。たとえば1000個のファズを送った結果システムがクラッシュしたとしても,その1000個のうちのどのファズが実際にクラッシュにつながったのかを特定できなければ意味がありません。ファズの特定はログファイルやパケットなどの監視結果を元にして行います。再現性がある問題なのか否かもこのときに調査します。

ファジングが完了して結果が出揃ったら,その結果が客観的に正しいかどうかのレビューを行います。そして,検出できたすべての問題に対して,それがセキュリティ上の脅威につながるかどうかを判定します。この分析が必要な理由は,ファジングによって検出した問題が必ずしもセキュリティ上の脅威となる類のものであるとは限らないためです。

発見できた問題については,レポートとしてしかるべき部署や機関に報告します。たとえばソフトウェア開発におけるテスト段階での実施であれば,結果は設計や実装の工程に差し戻されて修正されます。そして修正後のソフトウェアに対して,再度テストを実施します。報告にあたっては,受け取った担当者が実際に問題を再現できることを意識して,発生する条件や挙動をできるだけ具体的に伝えましょう。

ファジングの手順については,IPAによるファジング活用の手引きに具体的な実践例が掲載されているので,本稿とあわせて参考にしてください。

著者プロフィール

杉山貴章(すぎやまたかあき)

ONGS Inc.所属のプログラマ兼テクニカルライター。雑誌,書籍,Webメディアで多数の著作をもつ。

著書

コメント

コメントの記入