セキュリティには報奨金

「求職者にとっての最善を果たそう」

これは、Indeed 設立当初からの基本理念です。求職者の情報を安全かつ確実に保つのも、求職者を第一に考える取り組みの一つです。毎日何百万人のユーザーが使用するサービスを開発するにあたり、私たちは常にシステムのセキュリティについて考えています。それでも、誰かが私たちのシステムの裏をかくこともあるでしょう。ハッカーは、いつでもセキュリティをくぐり抜け、システムや情報への不正アクセスを行うために新たな方法を試みているからです。私たちの取り組みは、言わばセキュリティに関してはプロであるハッカーに逆に協力してもらい、彼らの発見に助けてもらおうというものでした。

画像: stockarch – stockarch.com ( ライセンス: Creative Commons

この挑戦に対し、私たちの出した答えは…… お金でした。実際には、名声です。

Indeedはセキュリティのチェックを行う有志の協力者に、彼らがまっとうな方法でそれを報告できるような手段を提供し、貢献してくれた時間を称えて、彼らに現金と表彰を報奨として与えています。我々のバグ・バウンティ・プログラムを通じて過去一年半の間で、これまで300件ほどの通知を表彰してきました。一番深刻なバグには最も高い賞金である$5000を贈りました。一番成功した参加者(あなたのことですよ、Angrylogic さんAvlidienbrunn さん、それからMongo さん)はIndeedで最も評価されているテスターとしての評判を手にしました。

過去 18 か月間における各バグ報告に対する報奨金の金額
重要度 報奨金額 関連性のある報告数 (割合)
重要 最大 $5000 0.7%
最大 $1800 4%
最大 $600 31%
最大 $100 64%

このプログラムを始めた理由

バグ・バウンティ・プログラムを始める以前には、時折、脅迫めいたメッセージを受け取ることがありました。匿名のユーザーが連絡してきては、「支払をしろ、さもなくば、まだ言えないけど非常に重要なセキュリティバグをばらす」というのです。こういう方々は、前払いを求めるのですが、そもそもそんな公開するようなバグが、本当に存在するかも確かめようがありません。Indeed のサービスを改善・向上するために、バグ・リサーチの協力者の皆さんには喜んでお礼をお支払したいのですが、こういった威圧的な行動の後押しはしたくありませんでした。何かが間違っている気がしたのです。

こうした相互間の不信感を取り除くために、わたしたちは  Bugcrowd.com(バグ・クラウド)に公正なアービターとして機能してもらうべく採用しました。 バグ・クラウドを使用することで、セキュリティのリサーチに協力してくださる皆さんは、エビデンスを前もって提供することに積極的になってくれましたし、私たち自身にもバグの深刻度を公平に評価する機会が与えられました。 Indeed はこれで弊害などなく賞金を提供できるようになり、皆末永く幸せにくらしましたとさ….

理論 vs 実践

「末永く幸せに……」というのは、実践するにはもっと難しいものです。プログラムが開始してから、およそ2500件ほどのバグ報告を受けました。もしかすると、各問題を確認するのに、それぞれ長時間かかるかもしれません。バウンティ・プログラムのことを宣伝したり、支払額をアップする度にバグ報告の数が跳ねあがるのですが、外部の方から見たら、私たちはのんびりやっているように見えるかもしれません。しかし、実際には総動員でこれらの報告に返信しています。このブログの記事だけでも、プログラムの認知度があがるおかげで、あらたに数時間分のバグ検証を生み出すはずです。

当初は、検証者の報告に素早く返答するのに苦労し、処理待ちのものも発生していました。処理しきれないくらいの数の報告をもらい、このバックログは膨らんでいきました。倍以上の時間を投資した、しんどい数週間を経て、私たちは応答時間の新しいスタンダードとなるものを実装しました。それ以来、応答時間はきちんと制御下にあります。

時間の経過に伴う管理中チケットの合計数

: チケット日の値は、ある特定の日にオープンになった全てのチケットの日数の合計です。たとえば、ある日に、一つのチケットが三日間オープンになっていて、もう一つのチケットが二日間オープンだったのならば、合計5チケット日と換算します

バグ・リサーチ協力者の皆さんが、自分が Indeed にうまく利用されていると誤解しないように彼らと明快なコミュニケーションをとることも重要でした。私たちに比べて、彼らにはプロセスがあまりよく見えないという事も念頭においています。共通した問題としては重複した事象の取り扱いです。初めて報告を受けた問題に対してお金を払うのは、納得がいきますが、その重複した報告を別のリサーチ協力者から受けた場合どう対応すべきなのでしょうか?二件目の報告は、何か付加価値をもたらすものではありませんが、報告した方にしてみれば、彼らはきちんと本物のバグを見つけているのです。チケットに、重複と記載する理由を明白に書き、特定された問題を素早く修正することで、この懸念点を最小限にとどめています。ある場合においては、もし素晴らしい再現工程や、概念証明を示している重複のケースにも報奨金をお支払いしています。

さらには、わたしたちは新規バグ発見と、既知のバグ修正の時間のバランスを取るように心がけています。人気のあるバウンティ・プログラムを組み立て管理することは、多くの良質な報告につながっていますが、もしバグ修正に時間をかけなければ、意味がなくなってしまいます。Indeed では、バグ・バウンティ・プログラムを改善するために投資する時間は大げさでなく、非常に大事なものです。

ここまでの成功

どうやらいい方向に向かっているようです。Bugcrowd は最近バグ・リサーチ協力者の皆さんに、どの企業のプログラムが一番好きか質問をしていたのですが、さて一番はいったいどの企業だったでしょうか!?

正解は…… Tesla です。(素敵な Tesla のせいなら仕方ないですね)しかし、Indeed は全投票の 8% を獲得し、競合社他 35 社のなかで二位になりました。私たちのプログラムに対しての具体的なコメントとしては、わたしたちが公平に支払いをすること、きちんとしたコミュニケーションをとること、そして伝播性のないスコープ、などが挙げられていました。まだまだ、向上の余地があると思いますが、私たちがちゃんと正しい道を進んでいるという「検証」がもらえて嬉しいです。

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone