初めまして、Flatt Security社のブログに寄稿させていただくことになりました、西川と申します。
普段は、SaaS企業でプロダクトセキュリティをメインの仕事としていますが、一般社団法人鹿児島県サイバーセキュリティ協議会の代表理事として活動しております。
さて、今回はプロダクトセキュリティを生業としている私が、脆弱性診断を外注することと内製化すること、それからバグバウンティについてそれぞれの役割を記していきたいと思います。
本記事の目的
脆弱性診断を外注した方が良い、あるいは、内製化した方が良い、という話ではなく、それぞれ役割が異なると考えています。つまりそれは、それぞれが補い合う形で存在しているというものです。そして、これらをさらに補う要素としてバグバウンティがあるという話を通して、みなさまの組織で脆弱性診断をどのようにセキュリティ運用に組み込んでいくのかを検討したり、バグバウンティの運用を開始したりするきっかけとなりましたら幸いです。なお、本記事はバグハンター向けの記事ではございませんのでご了承ください。
- 本記事の目的
- 脆弱性診断の外注のメリット
- 脆弱性診断の内製化のメリット
- 内製化と注意点
- バグバウンティ
- バグバウンティの提供方式
- まとめ
- おわりに
- Flatt Securityは外部パートナーと連携して技術記事を発信しています
脆弱性診断の外注のメリット
「脆弱性診断を外注していますが、内製化を検討しています」
時々そんな声を聞くことがありますが、目的が広義の意味での脆弱性を管理するということであれば内製化に移行することはよいかもしれません。
しかし、外注する場合には脆弱性管理のメリットが他にもあります。
1.客観的に脆弱性の状況を把握することができる
客観的な視点で脆弱性診断を行うということは非常に重要なポイントで、例えば、サービスのコンテキストを知りすぎてしまっている場合などではバイアスにより脆弱性を見逃してしまうことがあります。「ここはこの前重点的に見たし大丈夫だろう」「ここは優秀なAが実装しているし問題ないだろう」などの意識により脆弱性が見逃されてしまう可能性があります。逆に内製化をするときはこういった考え方をせずに、フラットな目線で脆弱性診断を行うことを心がけるとよいでしょう。
2.セキュリティベンダーの社内で生きた知見が共有されている
当然ながら脆弱性診断を請け負っているセキュリティベンダーでは様々な業種、業態のサービスに対して脆弱性診断を行う機会があります。そういった経験を通してセキュリティベンダーの元には知見が蓄積されており、蓄積された知見を元に脆弱性診断が実施されるため、教科書通りの脆弱性診断では見つけられない脆弱性を見つけられる可能性が内製の脆弱性診断よりは高いと考えられます。
また、新しい技術などに対してもいち早くキャッチアップしてセキュリティ上の懸念などを調査しているセキュリティベンダーもあります。ここら辺はセキュリティベンダーに依頼する強みだと思っていますが、一方で、そういうところまで力が入れられていないセキュリティベンダーもあるかもしれません。
3.第三者のお墨付き
SaaSを提供している場合に、そのSaaSを利用しようと検討している企業からセキュリティチェックリストが送られてくることがあります。セキュリティチェックリストというのは、セキュリティ上のチェック項目が羅列されたリストで、それが一定満たされているかどうかを確認することによって、そのSaaSを利用して良いかを判断する一つの基準となっています。
そのセキュリティチェックリストには「第三者の脆弱性診断を受けていること」という項目が入っていることがあります。特に大企業の場合、「内製の脆弱性診断は客観性がなく、本当に実施するかどうかも疑わしい」と思われてしまい、内製の脆弱性診断だけを実施している場合は導入を躊躇われてしまうかもしれません。このようなケースは少なからず起こる可能性があるので、セキュリティベンダーによる脆弱性診断は必須と言えるのではないでしょうか。ですので、「サービスのターゲットが誰なのか？」が外注すべきか、内製でもよいのか検討するポイントの一つとしてありそうです。
脆弱性診断の内製化のメリット
一方で内製化のメリットもあります。
1.任意のタイミングで脆弱性診断ができる
もちろん社内リソースには限りがありますから、ある程度の調整は必要かと思いますが、重要な機能をリリースするが外部と調整して脆弱性診断を行っている余裕はない場合や、急に脆弱性診断を実施することになった場合などに効果が発揮されます。
2.内部の事情を汲み取って柔軟に脆弱性診断ができる
特定の環境や機能の一部を対象とするケース、検証環境がなく本番環境で負荷をかけずに実施する必要があるケース、社内からしかアクセスできない環境で実施する必要があるケースなど、脆弱性診断をより柔軟に実施することが求められるケースがあります。もちろんセキュリティベンダーの中には、一定このような要件を汲んでくれるところもあるかと思いますが、より込み入った要件になってくると依頼をする側が内部事情を説明する負荷も高まってきます。事情を知っている内部の人に気軽に依頼できるというのは良い点です。
3.コストが削減できる
これも大きなメリットですよね。必ずしもというわけではないですが、多くの場合でコストが削減できるはずです。特にAPIの本数というよりは担当者の工数単位というところでコストメリットが考えられます。
内製化と注意点
一方で、内製化するときに気を付けなければいけないところもあります。それはサステナブルかどうかという観点です。例えば、「Aさんはセキュリティベンダーで脆弱性診断の経験があるから脆弱性診断は内製化しましょう」というように誰かに依存してしまっている仕組みの場合、Aさんが退職などの理由によりいなくなってしまうと、本来の目的が果たせなくなってしまうことが考えられます。「また外注にお願いすればいいや」で済むのであればよいのですが、予算が確保できておらず脆弱性診断が実施しなくてはいけない時期にできなかったり、セキュリティベンダーと日程の調整ができなかったりする可能性が考えられます。
また、内製化する際には、内部への依頼から対応までのフローを整えているはずで、その運用が回らなくなってしまうのでは勿体ないです。せっかく時間というコストもかけているのですから、運用開始後は、人を採用したり、内部で教育して同じように脆弱性診断ができて、同じようにリスクが判断できるような仕組みを整えたりするなどの工夫もしておきたいところです。加えて、内製化した後もこういったことに備えて外部に脆弱性診断を依頼できる予算をあらかじめ確保しておくことも検討しておきたいです。
なお、脆弱性診断の内製化支援サービスを提供している企業もあります。こういった懸念に関しても色々とアドバイスしてくれるかもしれないので相談をしてみるのもよいでしょう。 もちろん最初から仕組みが整えられていないからダメなわけではなく、なるべく運用を最初に決めてしまってから、セキュリティの施策を実施する方が何かあったときに混乱せずに済むかなと思います。そういった意味でもサステナブルな運用を目指していくのが重要で、外部の脆弱性診断をただ「内製化しました」だけだと、そこはまだゴールではなく道半ばなのではないかと考えています。
とはいえ、せっかく採用できたセキュリティエンジニアの工数を脆弱性診断のためだけに奪われてしまうのはもったいないですよね。よほどセキュリティエンジニアがたくさんいる企業であればよいのかもしれませんが、実のところ脆弱性診断よりも前にやらなければならないセキュリティ施策がたくさんあって、それだけで外注をなくすという選択をすることは難しいのではないでしょうか。
バグバウンティ
さて、これまで脆弱性診断の外注と内製化について話をしてきました。他にも外部の力を借りて脆弱性を検出する方法があります。それがバグバウンティです。
バグバウンティのメリット
24時間365日リスクにフォーカスした診断を受けることが可能です。頻繁にリリースが行われるサービスなどではその都度脆弱性診断をするのは難しく、SASTやDASTなどでセキュリティを一定に保つのが精一杯ではないでしょうか。
脆弱性診断ではサービスのコンテキストを踏まえずに診断が行われることも少なくありませんが、バグバウンティではありとあらゆる脆弱性を発見しようと色々な試みが行われます。そういったところが最大のメリットだと感じています。また、「こんな観点で攻撃してくるのか！」という学びになることさえあり、特にマルチプロダクトを提供している企業にとっては別のプロダクトにも知見を共有できるのが良いところであると思っています。
バグバウンティのデメリット
費用的なコストは安い一方で、人的コストが掛かることがあります。報奨金の金額を安く設定すると日本人よりも外国の方からの報告が多くなりがちです。英語が得意な方が対応する分には問題ないかもしれませんが、細かいニュアンスが伝わりにくかったり、時差の関係などでやりとりが長期化したりすることも考えられます。
また、レギュレーションを作っていてもそれを守らない人が時々見受けられます。なので、スコープを定めているはずなのに、スコープ外に対して診断されてしまうこともある程度想定しておく必要があります。ただし、それがいい方向に作用する場合もあるので一概にデメリットとは言えないのですが、状況によっては問題が発生する可能性も考えられます。
ですので、できるだけ本番環境相当のバグバウンティ専用の環境を用意した方がよいです。なぜかというと、レギュレーションを守らない人がいるというだけではなく、本物の攻撃かどうかを見分けることができなくなってしまうからです。「バグバウンティで何かやっているのかな？」なんて思ってたら実は攻撃だった、みたいなことも考えられます。もちろん本当の攻撃であれば即時に対応をしなければいけませんし、バグバウンティの調査の一環かもしれないというところで対応が後手後手になってしまったら本末転倒です。万一、本番環境のデータが消えたり、改竄されてしまったりというリスクを考えるとそれ専用の環境を用意するのが良いでしょう。
また、中には報告されたバグに関する判定に対して不服に思って、ごねられることがあります。認定しても報奨金の金額が安過ぎるとか、リジェクトした場合でも納得してもらえなかったり、サービス上の仕様であっても「これは脆弱性である」と主張してきたり、既知の脆弱性においても「証拠を見せてくれ、俺が最初に見つけたはずだ」と主張してきたりする場合もあり、根気強いやり取りが求められることがあります。
運用がきちんと回る体制が作れるのであれば、こういったデメリットはあるものの個人的にはそれに勝るメリットがあると思っています。が、人手が割けないなどで運用が回らなくなってしまうと報告が積み重なって大変なことになってしまう可能性も考えられます。
それから注意点としては、サービスによっては海外のIPアドレスをブロックしているサービスもあると思います。その場合バグハンターが適切に診断ができないということが考えられます。そのようなケースではあまり効果が期待できないかもしれません。
バグバウンティの提供方式
バグバウンティプログラムの提供方法は主に二つあるかと思います。
1.自社で運営する
一つ目が自社で運営する物で、自分たちで報告フォームを設けて、報告者と何らかの形でやり取りを行います。 サイボウズ社やLINEヤフー社などはこういった形式でバグバウンティを提供している(いた)ことで有名ですが、提供側や報告者にそれぞれメリット、デメリットがあるのかなと思います。私はこう言った形での提供側に所属していたことがないので企業側の観点ではお答えできませんが、考えられる範囲ではユーザーとしてはどのような脆弱性を発見したかが対外的にわかりづらく公開しにくいというデメリットが考えられます。
2.プラットフォームを利用する
二つ目がバグバウンティ提供プラットフォームを利用するというものです。日本ではバグバウンティプログラムを提供している企業はまだまだ多くありません。HackerOne、Bugcrowd などの世界的に有名なプラットフォームを使おうものなら登録するだけで非常に高額であると聞いたことがあります。なかなかそこに投資するのは難しいですよね。 でも、日本にも IssueHunt のようなバグバウンティのプラットフォームがあります。
プラットフォームを利用する利点
海外のサービスは高価ですが、IssueHunt は比較的安価に利用することが可能で、これらを利用することによってサービスのセキュリティを維持することも可能です。また、IssueHuntの場合、バグバウンティ運用のサポートも提供していて、特に負荷のかかる報告者とのコミュニケーションやトリアージを依頼することも可能で、これは利用者側にとっては非常に嬉しいポイントです。さらに、IssueHunt は学生向けにバグバウンティの機会を提供していて、サービスを学生に診断してもらうことが可能です。こういったみんなが幸せになれる取り組みは素敵です。
さて、さきほど安価に利用することが可能と説明しましたが、それはどういうことかというと、こういったサービスでは予算を設定して、その予算内でバグバウンティプログラムを提供することができます。例えば10万円という予算設定をして、発見された脆弱性に応じて報酬の上限額を設定しておきます。支払い報酬額がそこに達したらプログラムは自動で停止します。 10万円は安いと思うかもしれませんが、それでも国によっては大金になりますし、報告も月に10件程度はあります。もちろんプラットフォームにもよりますが、これぐらいの予算でこれぐらいの件数が報告されます。
まとめ
ここまで挙げてきた外注、内製化、バグバウンティそれぞれのメリット、デメリットなどをまとめると以下のようになります。
- 外注
- 客観的に脆弱性を把握できる
- セキュリティベンダーの知見を持って診断してもらえる
- 第三者のお墨付きがもらえる
- 内製化
- スケジュールの融通が効きやすい
- 内部の事情に柔軟に対応した診断を実施できる
- 外注に比べ費用面でのコストの削減が見込める
- サステナビリティを担保する労力がかかる
- バグバウンティ
- 24時間365日、常に診断を受けている状態にできる
- 攻撃のバリエーションが豊富になり、通常より知見を獲得できる可能性が高まる
- 予算に合わせた導入が可能で、比較的安価に運用を開始することもできる
- 効果的な運用の難易度が高い
おわりに
ということでそれぞれ組み合わせると最強のセキュリティができるわけですね！
とはいえ費用的なコストと人的コスト両方関わってくるというのは重々承知していて、上記の組み合わせは、「それができたら苦労しないよ！」という内容だと理解しています。ですので取捨選択していくことになるわけですが、私が言いたいのは脆弱性診断を外注から内製化しました！で終わりではなく、それぞれの役割があって、補い合う形で存在しているということです。
何のために脆弱性診断を実施するか、脆弱性を管理していくか、脆弱性が見つかったときにどのように行動するかが決められたあとでないと、その本来の効果というのが出づらい印象があります。
まずは徹底的に何のためにそれをやるのかを考え尽くし、そのうえでどういう方法を選択するか検討していきたいですね。 長文にお付き合いくださりありがとうございました。
Flatt Securityは外部パートナーと連携して技術記事を発信しています
本稿はFlatt Securityの外部パートナーが執筆し、Flatt Securityが監修を行った記事です。通常、企業の技術ブログは自社の技術力やカルチャーの発信のため、雇用関係にある社内メンバーの執筆によって発信されることがほとんどだと思います。
一方、Flatt Securityの技術ブログでは、本稿のようにセキュリティの知見をお持ちの外部の方に依頼しているケースがあります。種々の脆弱性情報や情報発信に知見を持つFlatt Securityの技術ブログ編集部が執筆者の方と連携することで、テーマや構成の検討・レビューをサポートしています。
これは、Flatt Securityの技術ブログの目的が自社のアピールにとどまらず、セキュリティに関する有益な情報をより多く社会に還元し、セキュリティ企業とセキュリティサービス利用者の間の情報の非対称性を無くすことを目的としているためです。
本文章は執筆者がセキュリティ診断のようなFlatt Securityのサービス提供に直接的に関わっているかのような誤解を防ぐために明記していますが、執筆にご興味を持たれた方はお問い合わせください。
※Flatt Securityが技術ブログ企画において重視している考え方については、以下の記事をご覧ください。
