サイボウズ流・脆弱性情報との付き合い方：検証環境提供プログラムも開始

サイボウズは2014年2月26日から、常設型の「脆弱性検証環境提供プログラム」を開始した。その背景には、脆弱性情報の取り扱いに関する同社の経験と問題意識があった。

[高橋睦美，＠IT]

　サイボウズは2014年2月26日から、常設型の「脆弱性検証環境提供プログラム」を開始した。同社のクラウドサービス「cybozu.com」と同等の環境を無償で提供し、そこで稼働しているサービスの脆弱性を検証、発見してもらうことが目的だ。セキュリティ研究者の他、同社サービスの導入を検討し、事前監査を行いたいと考えている大手企業向けにも提供する。

　同社は2013年11月に、サービスの品質向上を目的とした脆弱性発見コンテスト「cybozu.com Security Challenge」を実施している。脆弱性検証環境提供プログラムはその経験を踏まえ、対象範囲を「kintone」から、「Office」「Garoon」「メールワイズ」や共通管理基盤、kintone APIやkintone アプリストアまで含めた全サービスに拡大して実施するものだ。不正アクセス禁止法に抵触するといった懸念なく、安全に検証作業を行える環境を提供する。

　ここで見付けられた脆弱性は、2013年12月に公開した「脆弱性情報ハンドリングポリシー」に基づいて処理し、パッチ適用やサービス修正などの対応を取るという。

　企業がクラウドサービスを利用する場合、そのリスクは、サービスを提供するベンダーに転嫁されることが多い。しかし業種や業態によっては、リスクを転嫁するにしても自社できちんと検証した上でなくては受け入れれない、つまりクラウドサービスを導入できないケースもあり、サイボウズではこれまで、個別に覚え書きを結ぶ形で対応してきたという。

　サイボウズ グローバル開発本部 品質保証部の伊藤彰嗣氏は、脆弱性検証環境提供プログラムの提供により、「自社の監査の一環としてわれわれのサービスを確認し、より安全に利用してもらえるようになる」と述べている。

適切な粒度での情報公開を

サイボウズ グローバル開発本部 品質保証部の伊藤彰嗣氏

　脆弱性検証環境提供プログラムの背景には、ベンダーとして脆弱性情報とどのように向き合い、「責任ある情報開示」を進めていくべきかというサイボウズの問題意識があるそうだ。

　同社なりのその答えが、先に触れた「脆弱性情報ハンドリングポリシー」だ。「受付」「対応」「公開」の全プロセスにまたがり、どのようなフローで脆弱性情報を受け付け、どんなルールで深刻度を判断し、修正した上で公開するかという基準をまとめている。作成に際しては、ISO 29147などの国際規格も参考にした。

　「ベンダーには、適切な粒度で正しい情報を公開することが求められている。信頼感を高めるためにも、脆弱性の情報を広く受け付け、一定のルールに基づいてきちんと対応し、謝辞などとともに公表するという姿勢をきちんと作ることが必要だ」（伊藤氏）。

　これは、利用しているソフトウェアのパッチ適用作業をどうするかという、ユーザーとしての立場からの課題からも痛感していることだという。

　「サイボウズで利用している第三者のソフトウェアのパッチ作業で、非常に頭を悩ませている。というのも、情報の粒度はベンダーごとにバラバラで、場合によっては通常アップデートの中にセキュリティ情報が混じっていたり、詳細情報が公開されていなかったりで、優先順位をどのように付ければいいか分からない」（同氏）。ユーザーに判断材料を提供し、安全に使ってもらう環境を整えるためにも、脆弱性情報の適切な取り扱いが求められているという。

　残念ながらまだ国内では、「喜んで脆弱性情報を受け付けます」という会社は少数派というのが現状だ。だが、JVNなども活用しつつ、ベンダー側に脆弱性情報を受け付ける体制が広がれば、「世の中も変わるかもしれない」と伊藤氏はいう。

脆弱性発見コンテストを通じて見えてきたもの

　2013年11月に実施した脆弱性発見コンテストの根本も、同じところにつながっている。

　このコンテストには95名がエントリーし、うち14名から「脆弱性ではないか」という報告が41件寄せられた。サイボウズ側で検証した結果、最終的に20件の報告を「脆弱性」として認定したという。上位入賞者への表彰式は、3月2日に開催される「SECCON東京大会2013」で行われる予定だ。

　伊藤氏によると、「クロスサイトスクリプティングやアクセス権限設定の不備、入力確認の不備などを指摘してもらったが、侵入につながるような深刻な不具合はなかった」という。

　それでもコンテスト期間中には、検証環境に対し、スクリプトや「OWASP ZAP」などのツールによるものも含め、のべ50万件以上の検査用リクエストがあった。「自分たちでやってもせいぜい1日当たり3000件。つまり（粗く見積もって）200人日分ものリクエストがあった。短期間で、内部でやっている検査では見付けられないような脆弱性を報告してもらった。また、監査など異なる視点からの指摘もあった」（同氏）。

　一方、コンテストを運営する中で最も頭を悩ませたのは、「ソーシャルエンジニアリングを誘発するものは脆弱性なのかどうか」といった脆弱性判断の基準だったという。「41件の報告をいただいたが、これは脆弱性なのかどうか、その切り分けがとても難しかった」（同氏）。加えて、寄せられた情報の検証やフィードバックに忙殺され、「最初の数日は頑張っていたが、運営側もパンクしてしまった（苦笑）」そうだ。こうした経験も、社内の脆弱性情報取り扱いプロセスの中に取り込んでいくという。

　また一連のやりとりの中で、報告された情報をどう扱っているかを報告者にフィードバックしていくことも重要だと感じたそうだ。「脆弱性は修正が終わるまで公開しないのが原則だが、例えば『暫定的に対処している』などの状況を、一定の間隔で伝えていくことも大事だと感じた」（伊藤氏）。

　サイボウズでは一連の経験を踏まえて、脆弱性報告に対する報奨金制度の常設化に向けた準備も進めているという。