脆弱性診断を内製化する方法｜DevSecOps実現の最初の一歩

昨今、企業が競合他社に先駆けて顧客を獲得するために、モバイル決済サービスなどの新規サービスのリリースを急ぐ、あるいは、顧客ニーズや消費市場、ＳＮＳなどの媒体や決済手段の変化にあわせるために、ＥＣポータルサイトなどの機能追加を頻繁に行うことが増えています。

これによって、リリース頻度が増えるだけでなく、開発・リリースサイクル自体が短くなり、従来の外部ベンダーによるセキュリティ診断が間に合わず、やむを得ずリリースを遅らせるケースが発生します。逆に、セキュリティ観点での設計レビューやセキュアコーディング、セキュリティ診断などの脆弱性への対応を怠ってサービスをリリースした結果、予期せぬ不正アクセスを受けてセキュリティインシデントに繋がるケースも考えられます。

リリース計画に遅れが出ないように、かつ安全にリリースを進めるうえで有効な対策の一つとして、セキュリティ診断のうち定型的な脆弱性診断の手法やツール、プロセスの一部を内製して最適化することが挙げられます。

昨今では、安全なDXサービスの開発を目的としたDevSecOpsの一環として企業内でも脆弱性診断ツールを導入することが増えてきましたが、ツール選定や活用上の課題もあります。本ブログでは、脆弱性診断の内製化に向けた検討の進め方や、診断ツール導入後の運用上の考慮点について、事例を交えながら解説します。

開発の足かせとなりうる脆弱性診断

企業がサービスを企画する際、リリース前までに最低限対応すべき脆弱性を検出するための「脆弱性診断」を受けることが一般的になっています。脆弱性診断を外部に依頼する場合、一般的に、実施期間の調整や診断準備を開始してから、結果報告書を受領するまでに4～6週間程度を要します。

そのため、アジャイル開発のように短い期間で頻繁にリリースを行う場合、脆弱性診断の実施期間が足かせとなって予定通りのスケジュールでサービスをリリースできなくなる可能性があります。加えて、予定外の機能追加によって脆弱性診断の依頼件数の増加、リリース機能や改修内容によっては改修箇所以外の診断が必要になるケースがあります。その結果、当初の想定と比較して脆弱性診断の費用が大幅に増え、プロジェクト予算が不足して脆弱性診断を十分に実施することが難しくなる場合もあります。

脆弱性診断を効率化する方法としての「内製化」

このようなスケジュール遅延や予算不足のリスクへの対策の一つとして、社内で脆弱性診断を実施する「内製化」があります。

脆弱性診断の外部ベンダーでの実施と内製実施の特徴

しかしながら、脆弱性診断の全てを一足飛びに内製実施へと移行することは、大幅な体制拡充や専門人材確保（または育成）が必要なため、現実的ではありません。そこで、弱性診断ツールを活用して脆弱性診断の一部を内製化する方法をご紹介します。次のような効果があります。

• 脆弱性診断ツールのライセンスは、一般的には年単位で一定期金額での購入となるため、リリース数が大幅に増加したとしても、年間の診断コストを固定することができる
• 開発スケジュールにおいて任意のタイミングで脆弱性診断を実施可能となり、事前調整にかかる工数を大幅に減らし、検知した脆弱性への再診断も柔軟に対応することができる
• 開発者が脆弱性診断ツールを利用することで、脆弱性に関する知見を深め、脆弱性の作りこみの減少や脆弱性に関する知見を蓄積することができる

診断ツールに適したシステムや用途の見極めが必要

診断ツールでできることには限界があるため、すべてのシステム・機能に対して診断ツールのみで脆弱性診断を実施することは推奨できません。例えば、Webアプリケーションについて考えると、診断ツールは代表的なWebアプリケーションの脆弱性（例：クロスサイトスクリプティング^[i]、SQLインジェクション^[ii]）の検出を得意としていますが、アプリケーションの仕様の不備（例：他者の契約情報・購入履歴の閲覧、認証の仕組みを悪用した不正な商品購入など）に起因する脆弱性の検出はできません。

このような、診断ツールでの検出が困難な脆弱性は、技術者が診断ツールと自らの知見・経験を組み合わせ、システム仕様や情報の重要度を鑑みて検出を行う手動診断のほうが適しています。このように、サービスやアプリケーションの特性、リリースのスケジュールや規模、内容に応じた実施方法の選択が求められます。

診断ツールは、導入目的や運用体制に応じて選択

導入を検討する診断ツールとして、本稿では、開発者がWebアプリケーションのリリース前に脆弱性を認識し対応することを目的としたAST（Application Security Testing）ツールを取り上げます。ASTツールにはいくつか種類がありますが、大きく以下のように分類できます。

• SAST（Static Application Security Testing）：静的診断ツール
  ソースコードなどをインプットとし、脆弱性への対策がされているか既知の脆弱性が報告されているライブラリが利用していないかなど、脆弱性の有無を静的に確認するツール群
• DAST（Dynamic Application Security Testing）：動的診断ツール
  Webサーバの外部から疑似攻撃リクエストを送信し、そのレスポンスを解析して脆弱性の有無を確認するツール群
• IAST（Interactive Application Security Testing）：対話型診断ツール
  動的環境で実際のアプリケーション内部の動作・データの流れ等の情報から脆弱性の有無を調査するツール群

また、それぞれの脆弱性診断ツールの適用時期とカバレッジは以下のように整理できます。

脆弱性診断ツールごとの適用工程とカバレッジ

様々な脆弱性診断ツールの中から自社に適したツールを選択する際は、社内での脆弱性診断に関する課題、自社内の開発要員のセキュリティ知見の有無、導入コスト、運用コスト、対象のシステム数などを考慮する必要があります。

本稿では、上記で説明した脆弱性診断ツール（ASTツール）のうち、開発言語に依存しないことや、日本語に対応している製品もあるため導入・利用の難易度が低く、多くの企業で導入が進みつつあるDASTツールを紹介します。

DevSecOpsの第一歩を踏み出すのに最適なDASTツール

DASTツールの長所として、脆弱性に関する知識、脆弱性診断ツールの実施経験がなくても扱いやすく、システム開発会社だけでなく事業会社まで幅広い企業で活用できる点が挙げられます。

具体的には、対象となるWebアプリケーションまたはWebサイトの画面や診断シナリオを最初に設定すると、シナリオに沿って自動で画面を巡回（クローリング）して定期的にスキャン（検査）を行い、継続的に検出を行うことが可能です。また、脆弱性検出率は、サーバ外部から疑似攻撃をして脆弱性を検査する特性上高くなります。

一方で、他のツールや手動での脆弱性診断と比べた注意点として、一回あたりの脆弱性診断の時間が比較的長くなる点や、診断を実施するタイミング上、脆弱性への対応による手戻りが大きくなる点が挙げられます。

今回は、DASTツール導入を検討している以下のような仮想企業を想定して、診断ツール選定の進め方を説明します。

• 脆弱性診断予算：年間500万円未満
• 対象システム数：10
• リリースサイクル：3ヶ月に1回程度
• 脆弱性に関する知識、脆弱性診断ツールの実施経験、脆弱性診断に関しての知見が薄い

この想定では、年間の総リリース数（対象システム数：10×年間リリース数：4＝40）に対し、脆弱性診断の予算が十分に確保できていません（平均すると1回あたり12.5万円しか割り当てられない）。そのため、現実的には年1回の実施くらい（1回あたり50万円を割り当て）になると推測できます。

また、リリースサイクルが短いために外部へ脆弱性診断を依頼しようとすると契約調整等に時間が掛かりリリースの遅延が生じる可能性があります。内製で診断を実施しようとしても脆弱性診断に関する知見が社内で成熟していないために、高度な診断ツールは利用できない、といった課題も抱える形になります。

そのため、今回のケースでは、ランニング費用を固定でき、開発言語に依存せず、診断の網羅性が高いDASTツールが適しているといえます。

DASTツールの選定は、机上・実機の2ステップ

DASTツールを選定するにあたり、PoC（Proof of Concept：概念実証）を実施し、実際にツールを操作して検知性能や使用感を確認するのが一般的です。そのために、まずはDASTツールの製品情報の収集を行います。

以下の観点で診断ツールの提供ベンダーから情報を収集・整理し、費用感や検出可能な脆弱性項目などからPoC対象の製品を2～3程度に絞り込みます。

机上評価の観点

次に、実機を使ったPoCを実施し、選定するツールを確定します。PoC実施時には、以下のような観点で評価項目を作成し、対象のシステムへ脆弱性診断を行い評価します。これらの観点に対して自社の状況に適した優先度を定め、比較することで効率的に自社の環境特性、システム特性、運用方式に適したツールの選定が行えます。

実機評価の観点

運用の設計と継続的な見直しで導入効果を最大化

ツールの選定・導入後の運用では、ツールで検知した脆弱性への対応方針を定めておくことでより効果的な運用ができます。検知される脆弱性の数は、対象システムの規模にもよりますが、数百件を超えることも少なくありません。

これら全ての指摘事項を精査し、対応要否を判断することは、ツール実施者の大きな負担となるため現実的ではありません。導入後の運用に向けて、ツールでの診断結果を精査し、対応要否を判断して対処するための運用ルールを設定が必要です。また、診断ツールを実際に利用することになるシステム開発担当者へ周知・説明して浸透させることを推奨します。

例えば、脆弱性への対応要否判断基準として、一般的な脆弱性の評価基準であるCVSSの値が一定以上である場合に脆弱性へ対応する、あるいは、診断ツール内の評価基準で「危険度」が一定以上となった脆弱性についてのみ対応する、などの考え方を整理しておくことが挙げられます。一度定めたら終わりではなく、対象システムの仕様や脆弱性の動向にあわせて見直していくことが重要です。

また、過去に検出したのと同一または類似の脆弱性を検知した際に迅速に判断・対応するために、検出した脆弱性に対する精査方法、対応方針を整理して保存しておくことや、ツールでの診断で使用した診断シナリオをテンプレートとして再利用することも有効です。

このように、診断ツールが浸透するにしたがって、運用ルールが会社の実態に合うように見直され、知見が徐々に蓄積されていくことで、運用が最適化されていきます。

脆弱性診断にお悩みの方は弊社までご相談を

弊社では、本稿のようなDASTツールを含むASTツールの導入をご支援しています。　脆弱性診断の運用に課題を抱えている方、内製化の方針検討されている方、あるいはツール導入や内製化の事例を聞いてみたいという方は、ぜひ一度弊社にお問い合わせください。

[i] クロスサイトスクリプティング：悪意のあるスクリプトをクライアントのWebブラウザ上で実行する攻撃

[ii] SQLインジェクション：SQL文への入力値を不正に細工することで、データベース上で不正な操作を実行する攻撃