昨今、企業が競合他社に先駆けて顧客を獲得するために、モバイル決済サービスなどの新規サービスのリリースを急ぐ、あるいは、顧客ニーズや消費市場、ＳＮＳなどの媒体や決済手段の変化にあわせるために、ＥＣポータルサイトなどの機能追加を頻繁に行うことが増えています。
これによって、リリース頻度が増えるだけでなく、開発・リリースサイクル自体が短くなり、従来の外部ベンダーによるセキュリティ診断が間に合わず、やむを得ずリリースを遅らせるケースが発生します。逆に、セキュリティ観点での設計レビューやセキュアコーディング、セキュリティ診断などの脆弱性への対応を怠ってサービスをリリースした結果、予期せぬ不正アクセスを受けてセキュリティインシデントに繋がるケースも考えられます。
リリース計画に遅れが出ないように、かつ安全にリリースを進めるうえで有効な対策の一つとして、セキュリティ診断のうち定型的な脆弱性診断の手法やツール、プロセスの一部を内製して最適化することが挙げられます。
昨今では、安全なDXサービスの開発を目的としたDevSecOpsの一環として企業内でも脆弱性診断ツールを導入することが増えてきましたが、ツール選定や活用上の課題もあります。本ブログでは、脆弱性診断の内製化に向けた検討の進め方や、診断ツール導入後の運用上の考慮点について、事例を交えながら解説します。
企業がサービスを企画する際、リリース前までに最低限対応すべき脆弱性を検出するための「脆弱性診断」を受けることが一般的になっています。脆弱性診断を外部に依頼する場合、一般的に、実施期間の調整や診断準備を開始してから、結果報告書を受領するまでに4～6週間程度を要します。
そのため、アジャイル開発のように短い期間で頻繁にリリースを行う場合、脆弱性診断の実施期間が足かせとなって予定通りのスケジュールでサービスをリリースできなくなる可能性があります。加えて、予定外の機能追加によって脆弱性診断の依頼件数の増加、リリース機能や改修内容によっては改修箇所以外の診断が必要になるケースがあります。その結果、当初の想定と比較して脆弱性診断の費用が大幅に増え、プロジェクト予算が不足して脆弱性診断を十分に実施することが難しくなる場合もあります。
このようなスケジュール遅延や予算不足のリスクへの対策の一つとして、社内で脆弱性診断を実施する「内製化」があります。
|
外部ベンダーによる診断 |
社内での診断 |
社内でのツール診断 |
|
|
手動診断 |
外部ベンダー |
社内 |
外部ベンダー |
|
ツール診断 |
外部ベンダー |
社内 |
社内（開発者） |
|
長所 |
|
|
|
|
短所 |
|
|
|
しかしながら、脆弱性診断の全てを一足飛びに内製実施へと移行することは、大幅な体制拡充や専門人材確保（または育成）が必要なため、現実的ではありません。そこで、弱性診断ツールを活用して脆弱性診断の一部を内製化する方法をご紹介します。次のような効果があります。
診断ツールでできることには限界があるため、すべてのシステム・機能に対して診断ツールのみで脆弱性診断を実施することは推奨できません。例えば、Webアプリケーションについて考えると、診断ツールは代表的なWebアプリケーションの脆弱性（例：クロスサイトスクリプティング[i]、SQLインジェクション[ii]）の検出を得意としていますが、アプリケーションの仕様の不備（例：他者の契約情報・購入履歴の閲覧、認証の仕組みを悪用した不正な商品購入など）に起因する脆弱性の検出はできません。
このような、診断ツールでの検出が困難な脆弱性は、技術者が診断ツールと自らの知見・経験を組み合わせ、システム仕様や情報の重要度を鑑みて検出を行う手動診断のほうが適しています。このように、サービスやアプリケーションの特性、リリースのスケジュールや規模、内容に応じた実施方法の選択が求められます。
導入を検討する診断ツールとして、本稿では、開発者がWebアプリケーションのリリース前に脆弱性を認識し対応することを目的としたAST（Application Security Testing）ツールを取り上げます。ASTツールにはいくつか種類がありますが、大きく以下のように分類できます。
また、それぞれの脆弱性診断ツールの適用時期とカバレッジは以下のように整理できます。
様々な脆弱性診断ツールの中から自社に適したツールを選択する際は、社内での脆弱性診断に関する課題、自社内の開発要員のセキュリティ知見の有無、導入コスト、運用コスト、対象のシステム数などを考慮する必要があります。
本稿では、上記で説明した脆弱性診断ツール（ASTツール）のうち、開発言語に依存しないことや、日本語に対応している製品もあるため導入・利用の難易度が低く、多くの企業で導入が進みつつあるDASTツールを紹介します。
DASTツールの長所として、脆弱性に関する知識、脆弱性診断ツールの実施経験がなくても扱いやすく、システム開発会社だけでなく事業会社まで幅広い企業で活用できる点が挙げられます。
具体的には、対象となるWebアプリケーションまたはWebサイトの画面や診断シナリオを最初に設定すると、シナリオに沿って自動で画面を巡回（クローリング）して定期的にスキャン（検査）を行い、継続的に検出を行うことが可能です。また、脆弱性検出率は、サーバ外部から疑似攻撃をして脆弱性を検査する特性上高くなります。
一方で、他のツールや手動での脆弱性診断と比べた注意点として、一回あたりの脆弱性診断の時間が比較的長くなる点や、診断を実施するタイミング上、脆弱性への対応による手戻りが大きくなる点が挙げられます。
今回は、DASTツール導入を検討している以下のような仮想企業を想定して、診断ツール選定の進め方を説明します。
この想定では、年間の総リリース数（対象システム数：10×年間リリース数：4＝40）に対し、脆弱性診断の予算が十分に確保できていません（平均すると1回あたり12.5万円しか割り当てられない）。そのため、現実的には年1回の実施くらい（1回あたり50万円を割り当て）になると推測できます。
また、リリースサイクルが短いために外部へ脆弱性診断を依頼しようとすると契約調整等に時間が掛かりリリースの遅延が生じる可能性があります。内製で診断を実施しようとしても脆弱性診断に関する知見が社内で成熟していないために、高度な診断ツールは利用できない、といった課題も抱える形になります。
そのため、今回のケースでは、ランニング費用を固定でき、開発言語に依存せず、診断の網羅性が高いDASTツールが適しているといえます。
DASTツールを選定するにあたり、PoC（Proof of Concept：概念実証）を実施し、実際にツールを操作して検知性能や使用感を確認するのが一般的です。そのために、まずはDASTツールの製品情報の収集を行います。
以下の観点で診断ツールの提供ベンダーから情報を収集・整理し、費用感や検出可能な脆弱性項目などからPoC対象の製品を2～3程度に絞り込みます。
|
評価観点 |
評価項目（例） |
|
ライセンス |
・ライセンスの契約条件・期間 ・課金単位（例：対象システム／画面数、利用ユーザ／アカウント数） ※製品・ベンダーごとに提供する内容や提供条件が異なるため、契約条件と、有効期間、各種プランに含まれる内容、課金単位などを整理しておきます |
|
対応スコープ |
・診断実施項目の一覧 ・検出可能な脆弱性のカテゴリの一覧 ※診断対象となるサービスまたはアプリケーションの特性や自社の開発環境・体制を考慮して、採用を検討する診断ツールで対応すべき脆弱性を整理します |
|
サポート体制 |
・問い合わせ方法 ・ツール導入時・導入後のサポート内容 ※ツールの性能やコストだけでなく、どれだけ自社に寄り添って検証や導入、運用を支援してくれるかも重要なポイントとなるためヒアリングして確認します |
|
PoCに必要な情報 |
・トライアル用ライセンスの有無、有償／無償、利用可能期間 ・PoCにおけるベンダーの支援内容 ※PoC（トライアル利用による実検証）に関する各種情報を整理し、ベンダーの支援内容をふまえて検証用環境の準備などの作業計画に使用します |
|
コスト |
・初期費用（PoC費用、導入支援費用） ・ランニング費用（基本ライセンス費用、オプション費用、サポート費用） ※PoC、導入時、導入後の費用について、前提条件（想定システム数、アカウント数、サポート内容、オプション機能など）を設定してベンダーへ見積もりを依頼します |
次に、実機を使ったPoCを実施し、選定するツールを確定します。PoC実施時には、以下のような観点で評価項目を作成し、対象のシステムへ脆弱性診断を行い評価します。これらの観点に対して自社の状況に適した優先度を定め、比較することで効率的に自社の環境特性、システム特性、運用方式に適したツールの選定が行えます。
|
評価観点 |
評価項目（例） |
|
利便性 |
・スキャンの設定が容易で直感的に操作できるか ・診断結果（スキャンの実施結果）や対応すべき内容は理解しやすいか ・レポートの出力・参照・加工がしやすいか |
|
検知性能 |
・代表的な脆弱性（XSSやSQLインジェクションなど）を検出できるか （実機評価が難しい場合はベンダーへヒアリングを行う） |
|
機能・運用性 |
・利用者を設定し、実施結果への閲覧制限を設定できるか ・対象システムへ過剰な負荷をかけないようにアクセス数を制御できるか ・対象外のシステムへの脆弱性診断の実施を制御できるか |
|
パフォーマンス |
・検出した脆弱性の種類と件数 ・脆弱性スキャンに要した時間 ・対象システムに想定通りのリクエストでの脆弱性診断を実施できるか ・対象外システムへの脆弱性診断用リクエストの総信を制御できるか |
ツールの選定・導入後の運用では、ツールで検知した脆弱性への対応方針を定めておくことでより効果的な運用ができます。検知される脆弱性の数は、対象システムの規模にもよりますが、数百件を超えることも少なくありません。
これら全ての指摘事項を精査し、対応要否を判断することは、ツール実施者の大きな負担となるため現実的ではありません。導入後の運用に向けて、ツールでの診断結果を精査し、対応要否を判断して対処するための運用ルールを設定が必要です。また、診断ツールを実際に利用することになるシステム開発担当者へ周知・説明して浸透させることを推奨します。
例えば、脆弱性への対応要否判断基準として、一般的な脆弱性の評価基準であるCVSSの値が一定以上である場合に脆弱性へ対応する、あるいは、診断ツール内の評価基準で「危険度」が一定以上となった脆弱性についてのみ対応する、などの考え方を整理しておくことが挙げられます。一度定めたら終わりではなく、対象システムの仕様や脆弱性の動向にあわせて見直していくことが重要です。
また、過去に検出したのと同一または類似の脆弱性を検知した際に迅速に判断・対応するために、検出した脆弱性に対する精査方法、対応方針を整理して保存しておくことや、ツールでの診断で使用した診断シナリオをテンプレートとして再利用することも有効です。
このように、診断ツールが浸透するにしたがって、運用ルールが会社の実態に合うように見直され、知見が徐々に蓄積されていくことで、運用が最適化されていきます。
弊社では、本稿のようなDASTツールを含むASTツールの導入をご支援しています。 脆弱性診断の運用に課題を抱えている方、内製化の方針検討されている方、あるいはツール導入や内製化の事例を聞いてみたいという方は、ぜひ一度弊社にお問い合わせください。
[i] クロスサイトスクリプティング：悪意のあるスクリプトをクライアントのWebブラウザ上で実行する攻撃
[ii] SQLインジェクション：SQL文への入力値を不正に細工することで、データベース上で不正な操作を実行する攻撃