脆弱性診断(セキュリティ診断)の価格や見積もり検討時点で知っておきたいこと。Webアプリケーション診断を始めよう

話を聞いた人：豊田恵二郎 Flatt Security執行役員。車とサウナが好き。

回答した人：村上弘樹 Flatt Securityセキュリティエンジニア。ラーメン二郎を健康食だと信じている。

Webアプリケーション診断とは

豊田：まずは脆弱性診断(セキュリティ診断)の中でも最も一般的な、Webアプリケーション診断がどのようなものか教えてください。

村上：Webアプリケーション診断とは、お客様のWebアプリケーションに対し、情報漏洩やデータ改ざんにつながるような脆弱性がないかをエンジニアが診断するサービスです。脆弱性診断の手法は大きく分けると「手動診断」と「ツール診断」の2種類あります。

手動診断ではエンジニアが直接脆弱性を調査するため精度が高い一方、時間と手間がかかります。ツール診断では手動に比べ安価に実施可能で、一度に大量の項目を診断できますが、誤った結果が出ることも頻繁に起きますし、診断ができない要素もかなり存在します。

極端な例ですが、「他のユーザーのプロフィールが見れる」という事象はSNSのようなtoCサービスではむしろ期待されるべき挙動ですが、toBのSaaSで他社の情報が見えてしまったら間違いなく脆弱性ですよね。こういったサービスの文脈に応じた脆弱性の検知は人間が手動で行わなければいけません。

手動診断とツール診断を組み合わせることによって、効率的かつ網羅的な脆弱性診断が可能です。脆弱性診断の見積先を検討する際には、診断の種類によって、診断できる要素や価格が変わってくるという観点も重要でしょう。

Webアプリケーション診断では最終的に、発見した脆弱性についてまとめた報告書を提出します。報告書には、それぞれの脆弱性についてリスクや攻撃される可能性、どのような対策をすればいいのかといった内容が盛り込まれています。

診断の価格算出方法

豊田：診断を検討している人はざっくりと自社サービスの診断に必要な価格を把握したいことが多いと思います。どのように計算すればいいでしょうか？

村上：多くの場合はHTTPリクエストのリクエスト数をもとに、「リクエスト数 × 1リクエストあたりの価格」で計算します。1リクエストあたりの相場は数万円の場合が多いでしょう。

(図: リクエスト発生の例)

とはいえ、企業ごとに価格算出方法は異なるので事前に確認しましょう。

リクエスト数とは

豊田：HTTPリクエストの数ですか...もうちょっと簡易に、画面数とかで計算するのではダメなのですか？

村上：画面数から価格算出を行うことはありますが、正確さを欠く場合が多いです。

Flatt Securityではリクエスト数の数え方を「リクエストメソッド(GET, POSTなど) × URI × 利用用途」の組み合わせで計算しています。

例えば、GET /example と POST /example のようなリクエストメソッドが異なる場合は、同じURIに対してのリクエストでも異なるリクエストとして扱います。また、ログインのチェック(GET /user?checkLogin=user1)と権限の追加(GET /user?name=user1&add=write)のように、同じURIに対するリクエストでも利用用途が異なっている場合は、別のリクエストとしてカウント。逆に、ブログの記事のように同じ挙動をしているページに関してはまとめて1リクエストとして計算します。

そのため、ほとんどの場合はリクエスト数と画面数は異なります。

診断の見積もりに必要なもの

豊田：価格算出方法に関しては理解しました。正式に見積もりを依頼するときには何を提供すればいいですか？

村上：以下3つの情報が揃っていることが望ましいですね。もちろん揃っていなくともお気軽にご相談いただければと思います。

（1）診断対象の概要についてわかる情報 サービスのホームページやサービスの説明資料など。

（2）サービスでどのような技術が使われているか どのような言語を利用しているのか、FirebaseやAWSなどのクラウドサービスは利用しているかなど。

（3）リクエスト数を数えるのに必要な情報 以下のいずれか、もしくは複数をリクエスト数を確認するために頂いています。

• サービスの検証環境
• URL一覧
• 画面仕様書
• API仕様書

URL一覧やAPI仕様書に関しては、Ruby on RailsやLaravelといったフレームワークのコマンドで出力できるものや、OpenAPI(Swagger)のyamlファイルをご提供いただく場合もあります。どれか一つではなく複数いただけた場合には正確かつ短時間で見積もりを行うことができます。

個別の見積もりが必要な場合

豊田：すべてのWebアプリケーション診断がリクエスト数で価格を計算できるのですか？例外があれば教えてほしいです。

村上：基本的には計算できますが、例外もあります。

例えば、GraphQLやFirebaseを使っている場合、それらのサービスやプラットフォーム特有の脆弱性が存在する可能性があります。それらの脆弱性は、通常のリクエストごとの診断では発見できない可能性も。その際はサービスに詳しいエンジニアによる高度な診断を実施する必要があるため、リクエスト数をベースとした計算ではなく個別のお見積もりとなります。

診断にかかる時間

豊田：報告書を受け取ったら改修を行わなければいけないので、スケジュールも気になるところですね。発注から報告書の納品まではどの程度の期間がかかるでしょうか。

村上：サイトの規模にもよりますが、対象のリクエストが15リクエストくらいの小規模なものの場合は1～2週間で診断が完了します。しかし、サイトの規模が大きかったり複雑だったりした場合は、数週間から1ヶ月以上かかるということもあります。

時期によってはすでに診断企業の稼働が埋まってしまっているということもあります。スケジュール通りのリリースを行うためにもなるべく早い段階からの相談をお待ちしています。

診断を実施するべきタイミング

豊田：そもそも診断をいつ実施したらいいんだろうという悩みもありますよね。

村上：理想としてはリリースするすべてのタイミングで診断を実施することを推奨します。しかし、すべてのリリースで診断するのは予算やスケジュールの制約によって難しく、現実的ではないことも多いでしょう。それでも、大きなリリースや機能追加のタイミングには診断することが望ましいと思います。

診断の実施タイミングについてはこちらの記事にまとめています。

脆弱性診断実施の必要性はいつ生じる？事例をベースにタイミングや頻度を考える

また、一般的にはサービスの開発が終わってからセキュリティ対策を実施する場合が多いのですが、Flatt Securityではより早い開発の段階からセキュリティ対策に取り組むことを推奨しています。

修正にかかるコストは初期の段階で脆弱性が発見された場合は低く、開発の後半になるにつれて高くなることが多いと考えます。

そのため、Flatt Securityでは一番脆弱性修正のコストが低い開発の設計段階でのレビューの相談や、そもそも脆弱性を作らないために、開発者向けのセキュアコーディングのトレーニングKENROといったサービスも提供しています。

Webアプリケーション診断と同時に実施可能なオプション

豊田：まずは診断することが大事だとは思うんですが、Webアプリケーションだけ診断しても完璧というわけではないですよね。予算に余裕があれば同時に実施した方がいいオプションなどあれば教えて欲しいです。

村上：その通りですね。実装したアプリケーションがセキュアだったとしても、例えば利用しているクラウドプラットフォームの設定が脆弱だったり使い方を誤っていたりしたら、攻撃者に攻撃される可能性も。

そのような攻撃に対応するため、自社サーバーなどのプラットフォームや、AWS・GCP・Azureといったクラウドプラットフォームの診断も合わせて実施することが望ましいです。また、FirebaseのようなmBaaS、SPA、GraphQL API各種CMSに対しての診断も実施可能です。

多すぎて組み合わせ方や料金も想像しにくいと思いますので、是非我々のような専門家にご相談ください。これだけ選択肢が多いと予算も無尽蔵に膨らみそうなイメージをするかもしれませんが、実際には下のデータが示すように幅広いご予算に応じて提案を行っています。

概算料金を計算できる資料も配布しておりますので、是非ダウンロードしてご利用ください。

料金を「自分で計算できる資料」のダウンロードはこちら

豊田：よくわかりました。ありがとうございました！

まとめ

• Webアプリケーション診断には手動診断とツール診断があり、診断の発注を考えるときはそれぞれの特性を考慮する必要がある。2つを組み合わせて行うような提案もある。
• Flatt SecurityのWebアプリケーション診断では見積もりを「リクエスト数」で行っており見積もりには以下の情報が必要。
  • サービスの説明資料
  • 開発で利用している技術についての情報
  • リクエスト数を確認するための情報
• 診断にかかる期間は小規模なものであれば1,2週間程度で報告書の納品まで可能。サービスの規模が大きいものや機能が複雑なものの場合は1ヶ月以上かかる場合もある。