脆弱性診断は無料ツールで足りる？OSSで調べる範囲と手動診断の違い

無料の脆弱性診断ツールで足りるのは、既知の脆弱性、古いソフトウェア、設定の不備を広く洗い出す部分までだ。

他人のデータを読めるか、申込や決済の手順を飛ばせるかといった権限や業務の流れに関わる弱点は、ZAPの公式文書やOWASPの検査ガイドが自動の検査では見つからないとしている。

ツールが何も検出しなくても、分かるのはツールが届いた画面と、ツールが持つ検査項目の範囲で見つからなかったことだけだ。

無料の脆弱性診断ツールと手動診断の違い

無料ツールは検査項目に当てはまる既知の不備を探し、手動診断は業務上の正しい動作に照らして弱点を確かめる。

デジタル庁は『政府情報システムにおける脆弱性診断導入ガイドライン』で、Webアプリの脆弱性を3つに分けている。仕様に起因するもの（他人のデータを読み書きできる、ID連携の不備でなりすませる等）、実装に起因するもの（SQLインジェクション、XSS等）、ミドルウェア固有のもの（ライブラリやCMSの既知の脆弱性等）だ。

同じガイドラインは、ツールによる自動診断は効率の面で有用だが、仕様に起因する脆弱性は全般に検出が難しいとし、実装の不備でも、作りを深く理解しないと見つからないものは見落とされやすいとしている。

無料・OSSの脆弱性診断ツールの検査対象

主なOSSは、調べる対象がそれぞれ違う（各ツールの公式文書による）。

どれも、ツールが持つ検査項目に当てはまるものを探す仕組みだ。NISTは『情報セキュリティのテストと評価の技術ガイド』で、脆弱性スキャナーはシグネチャの蓄積に頼るため、実行の前に脆弱性データベースを最新にする必要があるとしている。

ログイン後の画面は、設定しないと検査の対象に入らない。ZAPの認証の設定では、ログインの方法、セッションの管理方法、診断用の利用者、ログイン中かどうかを見分ける目印を、使う側が決める。

URLを入れるだけで検査するサービスにも無料のプランがある。ログイン後の画面を調べるか、疑似攻撃を送るかはサービスごとに違い、疑似攻撃を送るなら次の章の許可が要る。

脆弱性診断のツールと手動の結果の違い

ツールの結果を使える形にするには、担い手の違う3つの作業がある。

2つ目について、NISTは同じガイドで、脆弱性スキャナーは存在しない脆弱性を報告する誤検出の率が高いことがあり、詳しい人が結果を解釈すべきだとしている。3つ目について、ZAPのアクティブスキャンの文書は、アクセス制御の不備のような論理的な脆弱性は、自動の検査では見つからないと明記し、手作業のペネトレーションテストを併せて行うよう求めている。

3つ目は、何が正しい動作かを知らないと判定できない。OWASPは『Webセキュリティテストガイド』で、手順の1から3へ飛んだらどうなるか、確認画面へ戻って金額を変えたまま購入を確定できるかといった例を挙げ、ツールには業務の流れを迂回できるかを見分ける手段がないとしている。

ZAPにも利用者ごとに開いてよいページを照合する追加機能があるが、その規則を書くのは使う側で、業務の仕様を知る人の作業が要る。

他人のデータを読めてしまう認可の不備がなぜ起き、修正後に何を確かめるかは、BOLAを解説した記事で整理している。

無料の脆弱性診断ツールを使う際の許可と業務影響

無料ツールでも、疑似攻撃を送る検査は実際の攻撃と同じ通信を送るので、自社のサイトでも関係者の許可が要り、データの変更や停止が起こりうる。ZAPの文書は、アクティブスキャンは対象への攻撃であり、自分が所有していないWebアプリには使わないよう書いている。FAQでは、アクティブスキャンはアプリによってデータを作成・変更・削除しうるとし、許可のないアプリに行えば違法と見なされうると説明している。

脆弱性診断を自分で行う際の実施許可と対象範囲

自社のWebサイトでも、許可を取る相手は社内の担当者だけでは済まない。デジタル庁のガイドラインは、事前に周知して診断してよいかを確かめる相手として、システムの責任者、開発・運用の担当、監視の担当、クラウド事業者などのインフラ提供者を挙げている。

インフラ提供者が禁じている診断項目は行わない。たとえばAWSは、一覧にあるサービスなら事前承認なしで評価してよいとする一方、サービス妨害（DoS）にあたる検査や大量のリクエストの送信を禁じ、検査で他の利用者に与えた損害は検査した側の責任としている。

制作や運用を委託しているサイトでは、委託先とインフラ提供者の両方に、検査してよい範囲を確かめてから始めるのがよいと我々は考える。対象のURLやIPアドレス、検査の種類、日時を書面に残しておくと、後で範囲の食い違いが起きにくい。監視の担当にも、診断元のIPアドレスと日時を伝えておく。

診断による業務影響と停止条件

デジタル庁のガイドラインは、診断で起こりうることとして次を挙げている。

• 通信帯域の圧迫や、システムのクラッシュによるサービス停止
• 疑似攻撃の値を含むダミーデータがデータベースに残る
• 大量のメール送信
• データの破損や消失、個人情報の意図しない閲覧
• 監視のアラートの大量発生

対策には、検証環境での診断、本番ならデータのバックアップ、休日・夜間・メンテナンス時間での実施、異常時の連絡の順番の確認を挙げている。NISTも、テストの取り決め（ROE）に連絡先の一覧とテストを止める基準を入れ、スキャナーのDoSの検査を外せるとしている。

無料の脆弱性診断ツールで足りず外部診断が必要になる条件

権限の種類が複数ある、順番のある手続きがあるといった箇所は、外部診断の対象にする。

政府のシステムの調達要件として、デジタル庁のガイドラインは、サーバーや機器の診断に商用ツールを、Webアプリの仕様に起因する脆弱性などにはツールの誤検出の除去にとどめない人の手での診断を必須にしている。民間への要件ではないが、外部に頼む範囲の目安になる。

自社で検証できない範囲

無料ツールの結果だけで判断が残るのは、次の条件に当てはまる箇所だ。

• 一般の利用者、管理者、取引先など権限の種類が複数あり、種類ごとに見えるデータや使える機能が違う
• 申込、決済、ポイント付与、パスワードの再設定など、順番のある手続きがある
• ファイルのアップロードやID連携を使っている
• 検証環境がなく、本番でしか試せない
• 検出結果が本物の脆弱性かを判断できる人が社内にいない

当てはまる箇所を一覧にし、外部診断の対象として切り出す。

外部診断へ引き継ぐツール結果

外部に頼むときは、自社で回したツールの結果を渡す。ISOG-JとOWASP Japanによる『脆弱性診断士（Webアプリケーション）スキルマップ』は、自動診断の結果の精査として、誤検出の確認と、対象の画面で検査が実際に行えたかの確認を挙げている。この2つを自社で済ませて渡せば、外部の診断は自社の検査が届かなかった範囲から始められると我々は考える。

デジタル庁のガイドラインは、同じ条件の診断を繰り返すと初回以降は脆弱性が見つからないことがあるとして、ツールや手法、診断する人を変えるよう勧めている。自社のツールの条件を伝えておくと、外部はそれと違う方法を選べる。

デジタル庁のガイドラインは、入力フォームやAPI、認証の処理を変えたときや開発の委託先が変わったときを、改修後に診断する目安にしている。ZAPには攻撃を送らず数分で終わる検査があり、CI/CDで回すことを想定している。自社のWebアプリについて、権限の種類と順番のある手続きを書き出し、ツールの結果がそこまで届いているかを確かめるところから始めるとよい。