検索
連載

10分で脆弱性が見つかった、バグハンターと開発者が共同合宿で得たことセキュリティ・アディッショナルタイム(21)(1/3 ページ)

缶詰め状態で集中して脆弱(ぜいじゃく)性を見つけてもらう「バグハンター合宿」を、サイボウズが2017年11月3〜4日に実施。予想以上に多くの報告を受理しただけでなく、サービス開発者とバグハンターの双方に気付きが生まれた。

Share
Tweet
LINE
Hatena

 開発者にとって、セキュリティ担当者や外部のコンサルティング、そして「バグハンター」は、ちょっと面倒くさい存在かもしれない。

 少しでも早く製品やサービスを市場に投入したいのに、セキュリティ上の問題や脆弱(ぜいじゃく)性を指摘し、やむを得ないときにはリリースに待ったをかけるからだ。海外では、脆弱性を報告してきたエンジニアに、詳細の公表を控えるよう求めたベンダーがあったことまで報じられている。

 だが、開発者とバグハンターの関係にはもっとよい形があるはずだ。ユーザーに安心して使ってもらえる高い品質とセキュリティを備えた製品やサービス、これを提供するという共通のゴールを目指す「仲間」と捉えることはできないだろうか。

 サイボウズではそんな考え方に基づいて、2014年6月から「脆弱性報奨金制度」を展開してきた(関連記事)。

 もともと同社では、「Cy-PSIRT(Cybozu Product Security Incident Response Team)」が主導する形で、製品・サービスのセキュリティ品質向上に取り組んできた。開発プロセスにおけるセキュリティテストや、外部の専門企業によるセキュリティ診断を受けないと製品をリリースできない。

 しかし、100%バグのないプログラムが存在しないように、検査をすり抜けた脆弱性が残っている可能性は否めない。

 そこで、さまざまなサービスや製品の脆弱性を善意で発見する外部のセキュリティ専門家、いわゆる「バグハンター」の力を借り、脆弱性を少しでも早く見つけ出すために設けられたのが脆弱性報奨金制度だ。「kintone」「Garoon」「サイボウズOffice」「メールワイズ」といった「cybozu.com」のクラウドサービスの他、パッケージ製品やモバイルサービス、APIなどの周辺サービスを対象とする。

 自分たちだけでは全てを見つけることができない問題を指摘してもらい、修正することで、顧客が安心して利用できる環境を整えることが狙いだ。こうした制度は、海外ではGoogleをはじめ多くの企業が採用しており、日本でもLINEのように制度を整備する企業が現れてきた。

 サイボウズでは毎年、期間を区切って脆弱性報告を受け付け、評価した後にやり方を見直す形で、少しずつ脆弱性報奨金制度を更新してきた。数年の蓄積を経て徐々に脆弱性に関する知見を開発サイドが共有でき、セキュリティ品質が向上してきたこともあってか、なかなか脆弱性を見つけてもらえない時期もあったという。

 そんな理由から、2017年7月7日以降、報奨金の「最大5倍キャンペーン」を実施。この結果、外部からの脆弱性報告が2倍以上に伸び、今度は報告内容の確認に追われ、うれしい悲鳴を上げることになったという。

 2017年11月3〜4日には、脆弱性の発見に協力してもらっているバグハンターを1泊2日の日程で招待し、缶詰め状態で集中して脆弱性を見つけてもらう「バグハンター合宿」を行った。日本全国から、業務や学業の傍ら、あるいは専業でバグハンティングに取り組む15人のバグハンターが、三浦半島のとあるホテルに集合し、脆弱性探しに取り組んだ。

個人戦からチーム戦に変え、報告数と認定数の比率も評価

 サイボウズはバグハンター合宿を3年前にも一度実施しており、このときは100件を超える脆弱性が見つかった。今回は「ほとんどのメンバーが前回の担当から入れ替わったこともあり、ほぼゼロからのスタート。前回とはまた違うものを作りたいと考えた」と、合宿運営に携わった大塚由梨子氏(サイボウズグローバル開発本部東京品質保証部Cy-PSIRT)は述べている。

 例えば競技形式。前回は「個人戦」だったが、今回は4人1組のチーム戦で得点を争う形とした。サイボウズは通常の報奨金制度でも「共通脆弱性評価システムCVSS v3(Common Vulnerability Scoring System v3)」に基づいて、脆弱性の深刻さを評価し、報奨金を支払っている。合宿でも基本的に同じ仕組みを採用して脆弱性の深刻度を判定し、深刻度に応じて得点を付け、チームの合計得点を競う形とした。

 さらに脆弱性と認定されないものも含め「細かな問題を多数」報告してもらうよりも、本当に深刻な問題の発見に力を注いでもらうことを狙った。そのために認定数と報告数の割合も加味するルールを採用した。これが、参加したバグハンターの戦略に影響を与えたようだ。

 11月3日、会場に集合した各チームは13時のスタート前から準備万端で、サイボウズ側の説明が終わるか終わらないかのうちに作業を始めた。中でもMasato Kinugawa氏は開始後わずか10分ほどで、Garoonに1つ目の脆弱性を見つける早業を披露した。「昨晩思い付いて、ある程度目星は付けていたもの」だというが、会場からは「おぉー!」と感嘆の声が上がっていた。

 他の参加者も、時々会話を挟みながら基本的にはもくもくと作業に取り組み、クロスサイトスクリプティング(XSS)や権限設定の不備、バリデーションのバイパスといったさまざまな脆弱性を指摘していった。

 公式には初日の13〜17時半まで、そして翌日9〜11時までの時間がバグハンティングに当てられていた。しかし参加したバグハンターは、夕食を挟んで部屋に戻ってからも、おのおの深夜まで作業にいそしみ、中には受け付け締め切り後も取り組んだメンバーもいたという。

 今回の合宿限定の試みもあった。これまで外部に環境の提供が困難だった「cybozu.com Store」についても、検証環境を用意し、バグハンターが実際に触って検証できるようにした。業務フローをともに提供することで、実装だけでなくビジネスロジックに問題がないか、第三者の目でチェックしてもらう狙いだ。

 既に何度かサイボウズに脆弱性を報告した経験のあるバグハンターは、製品ごとの傾向も把握していたようだ。前回の合宿にも参加した東内裕二氏(NTTコミュニケーションズ)をはじめ、何人かは「kintoneのようにクラウドを前提として開発されたものは、脆弱性を作り込みにくい設計が採用されており、非常に固い」と評価し、他のプロダクトに注力していたようだ。

 逆に、「Garoon」のように、オンプレミス時代に開発され、後にクラウドに載せ替えられたサービスには弱い部分があり、修正もアドホックになされるためか、比較的多くの脆弱性が指摘される傾向にあるという。

Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ

Security & Trust 記事ランキング

ページトップに戻る