ウェブアプリケーションを運用する企業にとって、脆弱性診断の実施はもはや不可避となっています。
一方で、今まで脆弱性診断を実施したことが無い場合、何から始めたらよいかわからないという声も良く聞きます。
そこで脆弱性診断サービス/脆弱性診断ツールのサポートの双方を提供しているテクマトリックスから、外部診断を依頼する、または内部診断を実施する際のフローをご案内いたします。

※この項目では主に動的診断を実施する際のフローを説明いたします。
　実際の診断方法やテクニックについては解説いたしませんのでご注意ください。

※本コラムは「脆弱性診断ことはじめイントロダクション ＜前半＞」の後半となります。

＜目次＞

診断実施

今回のコラムでは診断テクニックは対象外となっているため、診断対象のウェブアプリケーションを運営する側が注意する点として説明いたします。

診断環境の準備

ステージング環境の用意

動的診断の実施により、テストデータの大量作成、既存データの削除や破壊が起こる可能性があります。
そのため本番環境での実施は避けることを強く推奨いたします。

インターネットから診断環境へのアクセス

多くの場合、動的診断はサービス企業のサーバーからインターネット経由で実施します。
診断環境がインターネット経由で接続可能かご確認ください。
なお、診断環境に関係者以外のアクセスがされないか気になる場合はBasic認証やIPアドレス制限の実施が一般的です。
インターネット経由で接続する構成が難しい場合は診断チームが訪問してのオンサイト診断も可能です。
ただし、スケジュールの調整や訪問手続きが必要となり、価格もインターネット経由の診断より割高となります。

クラウドサービス上のWebアプリケーションへの脆弱性診断

かつてAWSやAzureなどのクラウドサービス(IaaS,PaaS)上のWebアプリケーションに対しては、脆弱性診断を実施する前に「ペネトレーション(侵入)テスト申請」を提出する必要がありました。
しかし脆弱性診断が普及したことにより、今では多くのクラウドサービス事業者は申請不要としています。
クラウドサービス事業者により対応が異なりますので、クラウドサービスのQ&Aやお問い合わせ等で事前に確認されることを推奨します。
質問の際は下記点をご確認ください。

• DOS(DDOS)等のネットワーク負荷のかかる診断は実施しない
• あくまでWebアプリケーションが対象であり、管理コンソールは診断対象外

SaaS,ASPへの脆弱性診断

脆弱性診断は基本的に診断依頼者がオーナーであるWebアプリケーションに限られます。
SaaSやASPのセキュリティ保全責任はサービス事業者となるため、ユーザーが脆弱性診断を行うことはできません。
(IaaSやPaaSは責任共有モデルにより、Webアプリケーションの責任範囲はユーザーとなります)
ただし契約内容やサービス事業者との調整により、ユーザーとして脆弱性診断を行うこともあるので、脆弱性診断を希望する場合はサービス事業者との合意を得てください。

データの準備・バックアップ

診断対象の画面を全て巡回できるように、アカウントやテストデータをご準備ください。
基本的には「診断対象の調査」にて確認した際のデータがあれば十分です。
また先述のように既存データの削除や破壊が起こる可能性があるため、バックアップの作成を推奨します。

WAF・IDS・IPS・監視の無効化

また診断中はテストリクエストが攻撃と判断される恐れがあるため、WAF・IDS・IPSのような防御装置は診断中の無効化を推奨しています。
事前にウェブアプリケーション本体の脆弱性を修正したうえで、防御装置にてより強固なセキュリティを推奨しているためです。
同様にネットワーク監視なども攻撃として検知される恐れがあるため、事前に静観依頼を推奨します。

診断中の対応

問い合わせ対応

診断チームから事前に洗い出せていなかった仕様に関する質問をされることがあります。
回答まで診断が停止することもありますため、早めに回答ください。
逆に社内関係部署から不審なデータや通信を検知したとの報告が来ることもあります。
なるべく大ごとにならないよう、事前の調査と連絡が重要です。

診断対象ウェブアプリケーションの管理

診断中は負荷や不正なデータが原因で診断対象ウェブアプリケーションが停止したり、スローダウンすることがあります。
その間は診断が遅延したり、中断することがありますのでお早めに解決ください。

結果報告

診断結果の確認

診断完了後数日で診断報告書が提出されます。
また、外注している場合はサービス企業によって基本サービス、オプションサービスとして下記が用意されていることがあります。

• 重大度が高い問題を検出した場合に「速報」として通知
• 報告会(対面/Web会議形式)
• 再診断(修正後の確認)

脆弱性が報告される際、どのくらい深刻な問題かを表す指標として重大度(用語は異なる場合があります)が用いられます。
重大度はサービス企業ごとに細かい差はありますが、4段階での分類が一般的です。

弊社での分類例
高：直接悪用される可能性が高い脆弱性で、一刻も早い修正を推奨
中：悪用の恐れがあるため、なるべく早い修正を推奨
低：すぐに悪用される可能性は低いものの、計画的な修正を推奨
情報：脆弱性ではなく、より安全に運用するための予防策

脆弱性の分類例

診断結果への対応

修正

脆弱性を修正する場合、まずは開発側で再現確認を推奨いたします。
診断報告書には再現方法が書かれていることが多いので、それに基づいて再現を実施してください。
ただし、場合によっては専用のツールを使わないと再現できないこともあるため、サービス企業にお問い合わせください。
修正後に再現確認を再度実施し、再現しないことを確認します。

差戻し

報告された脆弱性に異論がある場合には診断側に差戻を行う場合があります。
差戻しが求められた場合、報告書からも記載が除かれます。

1. 診断チームが仕様を誤解していた
2. 誤検知(偽陽性)

リスク受容

修正を行った場合と行わなかった場合のリスク/ベネフィットを比べた結果
修正を行わないという選択もあります。
この場合報告書から除外はせず、運営企業の責任による判断という扱いになります

1. 重大度が低い、または予防策としての検出
2. 診断範囲外のサービスや運用で実質的な被害を防止する措置が講ぜられている
3. 脆弱性を修正すると、Webアプリケーションの重要な機能に影響する

終わりに

以上、外部診断を依頼する、または内部診断を実施する際のフローをご紹介いたしました。
テクマトリックスでは脆弱性診断サービス/脆弱性診断ツールのサポートの両方を行っていることから外部診断、内部診断を行いたいお客様のニーズに沿ったサービスをご提供しております。
詳しくはこちら【お問い合わせ】よりお気軽にお問合せください。

脆弱性コラム「サイト脆弱性をチェックしよう！」についてはこちらからご確認ください。