2021.12.20 更新

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

この記事について

自社プロダクトのセキュリティを高めるために脆弱性診断を行いたいが、どのタイミングで行うのが適切なのか判断が難しいという開発者の方は多いのではないでしょうか。実際に、判断基準は多岐にわたり「いついかなる場合でもこのタイミングに行うのがベスト」というものはありません。しかしそのタイミングを見極める基準をゼロから構築するのも一定の根拠などがなければ難しいと思います。今回は「プロダクトの脆弱性診断をいつどのように行うと効果が高いのか」を弊社にご依頼いただいたお客様の事例を交えながらお伝えします。

needs_and_frequency_thumbnail

1.「脆弱性診断を今やるべきか」に関しての種々の課題について

まずは脆弱性診断を依頼しようとしたときに、どのような悩みがあるのかを整理します。悩みの例を並べてみると、以下のようなものでしょうか。

サービスがどの程度の規模になったら診断を実施すべきタイミングなのか
どのような頻度でどのように行うのが良いのか
- リリースタイミングに合わせて(リリース前に)必ず実施すべきなのか
- 毎月や毎年など、決まったタイミングで行うほうが良いのか
診断を行うことで開発スケジュールに影響はあるのか
- 診断を行う際は開発をストップさせないといけないのか
- 診断を実施後に改修のリソースコストを割くことが出来るのか

これらについてお答えします。

2.サービスがどの程度の規模になったら診断を実施すべきタイミングなのか

こちらについては様々な判断基準があり、技術的な面だけでは適切なタイミングを見計らうのは難しいです。依頼タイミングの判断を他社がどのように行っているのかについて、弊社のお客様の事例を見てみましょう。

timing_and_frequency_1

まず、大前提として新規プロダクトのリリースや機能追加のタイミングでの実施は多く、最も適切なタイミングであると言えます。弊社の公開事例では下記のようなお客様がいらっしゃいます。

グッドパッチ様
- 2020年4月にβ版リリースを予定していたので、2019年の末ごろからセキュリティ診断を依頼できる企業を探していた。
タメニー様
- 新規事業のローンチ前には、外部によるセキュリティ診断が必要だと判断したため。

また、顧客数が一定の基準を超えたタイミングなど、ビジネス規模が拡大してきたタイミングにセキュリティ強化を行う方も多いといえます。上場や資金調達、他社のサービスを買収した等のビジネス上の明確なきっかけが存在することもあります。

エン・ジャパン様
- 今後の拡大を見据えプロダクトのセキュリティをより強固にする必要があると判断したため。
freee 様
- サービスを買収するにあたり、セキュリティ診断が必要になったため。

3.どのような頻度でどのように実施すると良いのか

前項で紹介したように、基本的には新規プロダクトやその機能の一部を新たにリリースする前に行うことを推奨しています。プロダクトのテストフェーズと並行して行う会社が多い様です。

しかし、必ずそういったタイミングでなくとも、開発や予算の都合の良いタイミングで行ったり、「3ヶ月や半年に1回は行う」のような時期による判断を行ったりするのも良いと思います。

というのも、昨今のSaaSを始めとするWebプロダクトやスマホアプリの増加で脆弱性診断は需要が過多で、診断ベンダー側がリソース不足となり、必ずしも顧客側の希望するタイミングで行えないケースもあるのです。

また、顧客側の専門的な要件や、AWS・GCP・Azureなどのパブリッククラウド、Firebase等のモダンな技術に対応出来るベンダーが見つからず、診断を実施したくてもできていないというケースも増えてきているようです。

JIEM 様
- AWSを診断するメニューにCognitoまで含めているベンダーは見当たらなかったが、Cognito利用時のリスクについて記載した弊社のブログを見つけた。
スミレナ様
- 既存の発注先はFirebaseを利用したサービスを診断した経験が少なく、技術面に課題を感じていた中、技術ブログでFirebase利用時のセキュリティに関する高度な情報を発信している弊社を見つけた。

診断を行う予定が立ったらまずは一度診断ベンダーに連絡を行い、相談してみるのが良いでしょう。

timing_and_frequency_2

脆弱性診断はプロダクトの品質を高めるためのものですので、なるべく高頻度で行うことが望ましいです。しかし、例えば「3ヶ月に一度プロダクト全体に脆弱性診断を実施する」というのは時間的にも金銭的にも現実的ではありません。

そこで、プロダクト全体の診断では無く、優先度の高いエンドポイントに診断対象を絞って実施する方法もあります。弊社としましては、「大きなプロダクトの診断も優先度順に、複数回に分けて診断する」「重要な機能のリリース前にその部分だけ診断する」など診断対象を弊社も協力をしてスコープし、柔軟なご提案をさせていただくことで、期間・予算内での効果最大化がされた診断を提供しております。

ただ、診断対象のスコープは「診断を行わない範囲が存在する」ことになるので、デメリットもあることは意識しなければいけません。あくまで、限られた期間・予算の中での効果の最大化です。

4.診断を行うことで開発スケジュールに影響はあるのか

脆弱性診断は開発の終盤に行うため多くの脆弱性が検出された場合、その改修に時間がかかりリリースに影響を与えるケースがあります。そのため、できるだけ早く診断を実施することや、脆弱性を作り込まないようにセキュリティを考慮した設計や開発を行うことが重要です。

その上で脆弱性診断を行うことで開発スケジュールが遅延しないことは、もちろん皆様のご尽力や入念なプロジェクトマネジメントの賜物によるところもありますが、診断が一般的な検証環境などを用いて行えるものだからということもあります。

多くのお客様はステージング環境、検証環境と呼ばれるようなテストフェーズに用いる環境を流用して脆弱性診断を行っています。リリース前のプロダクトであれば本番環境でそのような検証を行っている場合もあると思いますが、脆弱性診断も同様に行っています。ただしリリース後の本番環境における診断は、十分に注意をして診断を実施したとしてもプロダクトが正常に動作しなくなるなどビジネスへの影響が生じる可能性があります。そのためケースによっては診断を実施できないこともあります。

また、診断実施後に発見された脆弱性に対する改修に不安をお持ちの方も多いかと思います。発見された脆弱性に対して何からどのように改修していけばよいか、考える部分にも時間がかかることがあります。この負担を軽減するために弊社では脆弱性を改修しやすい報告書の作成を心がけています。

独自指標「攻撃成立の可能性」を報告書に含めたり、脆弱性の再現方法や発生原因を明確に記載したりすることで、短時間で改修の優先度を判断し対応を行えるようにしており、ご評価をいただいています。