テクノロジー

サービスのセキュリティを守る、脆弱性報奨金制度との上手な付き合い方!

edvakf
2016.12.25
シェア
ツイート
ブックマーク

サービスのセキュリティを守るための方法として、社外のセキュリティ脆弱性を探すエキスパートに委ねるという手段があります。彼らのようなホワイトハッカーの力を借りて、サービスの脆弱性を発見し、その報酬として脆弱性報奨金をお支払する。日本だとCybozuさんとかLINEさんの事例が有名です。

ピクシブでも、「脆弱性報奨金制度」として同様の取り組みを進めており、サービスのセキュリティリスクを下げています。今回、その導入事例を元に、脆弱性報奨金とどう付き合っていくのが良いのか、考えてみましょう。

BugBounty.jp

BugBounty.jpというサービスがあります。脆弱性報奨金制度を、運営してくれるサービスです。

CybozuさんやLINEさんは自前で脆弱性報奨金の窓口を運営されていますが、ピクシブでは以下の理由があり、BugBounty.jpを活用しています。

  • 特に宣伝しなくても、ホワイトハッカーたちを集めて、脆弱性報告してくれる。
  • 日本以外のホワイトハッカーからも脆弱性報告があがってくる。
  • 報奨金の支払いにまつわる面倒な手続きを、丸投げできる。(海外送金とか消費税)
  • 報告された脆弱性について、運営さんに質問できる「トリアージサービス」がある。

pixivの報奨金プログラム詳細は、こちらです。

なぜ脆弱性報奨金制度を導入したか

Webサービスの脆弱性は、皆無であることが当然望ましいです。しかし、皆無であることを証明するのは不可能です。これは悪魔の証明のようなもので、どれだけコストをかけてセキュリティ対策をしても、脆弱性が100%無いと言い切ることはできません。

脆弱性が無いと言い切れない以上、セキュリティにどの程度予算を割けば完璧かという議論をしても、永遠に終わりは来ません。それぞれの会社が規模や扱っている情報の内容によって、現実的な範囲で予算を割き、セキュリティリスクをコントロールしていくべきです。

外部からの攻撃に対するセキュリティリスクをコントロールする方法として、開発の現場で安全なフレームワークを採用したり、社内にセキュリティを専門とする部署を立ち上げ対策していく、などが挙げられます。

ピクシブでは、よくある脆弱性が起こりやすいプログラムをそもそも書けないようにフレームワークを育ててきたりしましたが、そのフレームワークに脆弱性が無いとは言い切れません。また、セキュリティを専門とする部署も持っていません。これは、多くのスタートアップ企業でも同様の状況でしょう。ミニマルでセキュリティ対策をやり始めるには脆弱性報奨金制度が最適です。脆弱性が報告されなければ、1円も払う必要はありません。

報奨金額の設定

BugBounty.jpに登録したのは2016年の4月でした。当時は様子見で上限価格を5万円としていましたが、現在は上限価格を10万円としています。

報奨金の額は、一概にXSSなら◯円、CSRFなら◯円と決められるものではありません。先述のように、その脆弱性のもたらす問題の規模によって決まってくるもので、会社によってもバラバラでしょう。

私は「需要と供給」の考え方で決めるべきと考えています。報奨金を低く設定すれば報告は来にくくなりますし、いたずらに報奨金を高く設定すれば脆弱性報告が来すぎてしまって、すべてを精査することができなくなってしまい、本末転倒です。

ピクシブでは、リスクの高さに応じて、おおよそ次のような基準で報奨金額を設定しています。

  • サーバーに侵入可能 10万円
  • サーバー上のファイルが閲覧可能 10万円
  • リモートで不特定多数に攻撃が可能 3万円
  • 課金を迂回可能 3万円
  • 同じネットワーク内で攻撃が可能 1万円
  • 難しいが理論的には不特定多数に攻撃が可能 5千円
  • 危ない設計 5千円
  • 端末にアクセスすれば攻撃が可能 除外

ピクシブでは、過去に10万円を支払ったことが1回だけあります。

この基準は内部的な目安で、随時アップデートしていっていますが、報奨金プログラムに反映させられていないのが現在の課題です。きちんと報奨金目安や対象外とする条件などはアップデートしていくべきでしょう。

現在はバランスよく報告が上がってきていますが、対策が進むと報告が減っていきます。ある程度、報告が少なくなってきたら、金額を上げる予定です。このように様子を見ながら報奨金額を上げていけるのは良いところです。

報告が来たときの対応

報告が来ると、自分ともう一人が精査して返信しています。脆弱性であると判断したものはissue化して、数日以内に対策することがほとんどです。設計レベルから対策が必要なものは残りがちになりますが、これはどうしても仕方ないですね。

報告の件数は今のところ週に数件程度です。脆弱性報告の精査にあてる時間を週に1時間ぐらい確保すればまわるぐらいなので、なんとか他の業務を圧迫せずにやっていけています。

脆弱性報告の精査に当てられる人数を増やせばもっと金額を上げてどんどん報告を受け付けられるのですが、際どいケースを脆弱性と扱うかどうかは会社のポリシーに関わってきますので、誰でもできる仕事というわけではありません。このあたりの社内体制をどうしていくかも今後の課題です。(BugBounty.jpで有償の「トリアージサービス」を使えば良いかもしれません)

BugBounty.jpでは半分ぐらいの報告は英語です。英語でやり取りできる人が一時精査担当になるとスムーズに応対できますが、引き継ぎコストは多少上がります。これも「トリアージサービス」で英語の応対も頼むことができますので、そちらを検討しても良いかもしれません。

どのような報告が来るか

報告の半分以上はよく知られたソフトウェアの脆弱性を応用したものです。

  • HTTPやDOMで特定のAPIを使えば対策できる脆弱性
  • WordPressの脆弱性(たいていバージョンアップで直る)
  • ImageMagickの脆弱性

などです。本来は利用しているすべてのソフトウェアのアップデートをきちんとチェックしていれば回避できるものですが、現代のソフトウェア開発ではオープンソースソフトを多数利用していたりするので、全部をチェックするのは現実的ではありません。そういった部分に対して目を向けるというか、気を引き締めることができるのは、脆弱性報奨金制度をやっていて良かったことです。

明らかな脆弱性ではない報告をどう扱うかは悩ましいところです。無下に却下してしまっては、せっかく時間をかけて報告してくれた人のモチベーションを削ぐことになってしまいますので、どう伝えるかは悩ましいです。「我々の基準では脆弱性ではないと考えるけれど、設計を変えたほうがいいね。報告ありがとう」といって報奨金を払うこともたまにあります。

おわりに

色々な課題もありますが、ピクシブでは脆弱性報奨金制度とうまく付き合えていますので、今後の利用も拡大していきたいです。

我々の今の規模では週に数件という件数が精一杯ですが、徐々に体制を整えていき、週に10件以上処理できるようになっていきたいところです。重ね重ねになりますが、このようにミニマルで初めて進化させていけるのがBugBounty.jpの良いところとです。

pixivの脆弱性に興味のある方は、こちらから、報告をお願いします!

シェア
ツイート
ブックマーク