新CTOの@edvakfです。
今年のピクシブ株式会社アドベントカレンダーも無事最終日を迎えることができました。
http://qiita.com/advent-calendar/2016/pixiv
脆弱性報奨金というものがありまして、日本だとCybozuさんとかLINEさんの事例が有名です。
今回はピクシブで脆弱性報奨金の導入事例を元に、脆弱性報奨金とどう付き合っていくのが良いかを考えていきます。
忙しい人向けのまとめ
- BugBounty.jpを利用して脆弱性報奨金制度を導入した
- セキュリティ部署を作らなくてもミニマルに始められて良い
- 会社の規模に合わせて報告件数をコントロールしながら報奨金額を設定しよう
BugBounty.jp
CybozuさんやLINEさんは自前で脆弱性報奨金の窓口を運営されていますが、ピクシブではBugBounty.jpというサービスを利用しています。(pixivの報奨金プログラム詳細)
このサービスの良いところは、
- 日本以外のホワイトハッカー達も報告してくれる
- 報奨金の支払いにまつわる面倒を丸投げできる(海外送金とか消費税)
- 報告された脆弱性について運営さんに質問できる「トリアージサービス」
などがあります。
なぜ脆弱性報奨金制度を導入したか
ウェブサービスの脆弱性は皆無であることが当然望ましいですが、皆無であることを証明するのは不可能です。悪魔証明のようなもので、どれだけコストをかけてセキュリティ対策をしても、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の脆弱性に興味のある方は是非報告をお願いします!