サイボウズの理念は「チームワークあふれる社会を創る」こと。その企業理念に沿ってチームワークを支えるソフトウェアを開発し続けてきたサイボウズ、現在では、中小企業から大企業まで業種を問わず幅広く利用者は増加しており、サイボウズ製品の国内販売実績は12万社を超えました（2020年7月末時点）また、2011年に開始したクラウドサービス「cybozu.com」は順調に発展しており、今ではグループ売上の過半を占めるまでになっています。
本稿では、そんなサイボウズのソフトウェアセキュリティをお手伝いしているアスタリスク・リサーチの岡田良太郎が、これまでの取り組みや組織体制、直近のセキュリティ課題や今後への展望などを、PSIRTの大塚由梨子様と新関和貴様に幅広く伺いました。
現状の取り組みと課題
岡田： サイボウズのセキュリティ確保の取り組みは、多くのお客様からの期待が高いですね。現在、サイボウズではセキュリティ課題をどのようなサイクルで拾い、また開発や企画チームにフィードバックしているのでしょうか。
大塚：弊社では、PSIRTが現在23人いますが、「この人ならこの製品」と担当者を決めています。開発者側が「PSIRTの誰に相談したらいいんだろう」と迷うことがありませんし、PSIRTの中でも密な連携ができるようになっています。製品担当のメンバーは開発工程のレビューミーティングにも出るようにして、疑問点があればPSIRT内で共有して、検討結果をまた開発側に伝える、という流れです。
プロダクトから出た脆弱性は全てPSIRTで拾って、外部からの報告も含め、データベースで一元管理しています。ここでPSIRTがやっていることは、共通脆弱性評価システムCVSS（Common Vulnerability Scoring System)で評価して、開発チームに情報提供することです。PSIRTは直接の改修権限を持っていませんので、私たちの役割は、これらの情報をもとにプロダクトを改修するかしないかの最終的な判断を下しやすいようにすることです。
基本的に、ソフトウェアに「脆弱性」があるからといって、必ずしも「直ちに、最優先で改修しなければならない」ものではない、ということは繰り返し繰り返し、製品側に伝えています。開発者の中には「脆弱性の報告です」と言うと、ちょっと身構えてしまって、どんな不具合の優先度よりもプライオリティを高くして改修しなければならないんじゃないか・・・と思ってしまう人もいることも事実です。
ですが、PSIRTとしては「まずは脆弱性によるリスクを正確に理解してもらうこと」が重要であると考えています。そのため、PSIRTが脆弱性情報をお伝えする時には、この脆弱性によりどのようなリスクが考えられるのか、攻撃が成立する条件、たとえば攻撃に必要な権限はどういうものか、攻撃が成功した場合に何が侵害されるのか、一般ユーザなのか等、具体的に、細かく伝えるように意識しています。
プロダクトの開発サイクルにおいては、脆弱性の修正よりも先に手がけるべきこともありますので、それらを限られた工数の中で対応しなければなりません。あらゆる情報を比較して、対応優先度を決めるようサポートしたい、と考えています。このサイクルを回し続けることが、PSIRTが考える製品セキュリティの向上に繋がると考えて、進めています。
脆弱性検証の実施と、運用・開発・ユーザとのコミュニケーション
岡田：御社の脆弱性検証はどのような視点で行われているのでしょうか。
大塚： 複数の観点から脆弱性検証をしています。社内の体制による検証とセキュリティ診断専門の会社による監査、そしてアスタリスク・リサーチにご提供頂いているセキュリティ診断サービスを活用しています。
社内でのチェックは、手動の検証はもちろん権限昇格の確認など、仕様書や設計を元に網羅的に実施できるところがポイントになっていると思います。監査は、特定のリクエストに対して、ピンポイントでより攻撃者視点でのチェックを行なっています。社内検証と監査は、新しい機能や追加になった機能や仕様変更になった部分をメインに行います。毎回、システム全体をチェックしているわけではありません。一方で、アスタリスク・リサーチ提供のサービスでは、より広い視野での診断があり、サードパーティのバージョンアップデート状況や、システム全体のリスクの視点で検査できる特徴があります。
実は、こうした複数の脆弱性検証が、全く同じ脆弱性を報告してきた、というのは一度も無いんです。視点が違うからですね。脆弱性検証を内製化しても、それだけでは不十分で、第三者の目から見てもらうのは大切だと考えています。御社のサービスでは再テストも容易にできますので、それも大きなメリットとして考えています。
岡田：セキュリティテストには、それぞれ視点と役割があるということですね。ところで、チームのコミュニケーションについてお尋ねしたいんですが、たとえば、開発とセキュリティ、開発と運用は、往々にしてモチベーションの衝突といいますか、コンフリクトがあって、ややもすれば押し付け合いなどが発生してしまいがちだと言われています。サイボウズでは、コミュニケーションを円滑にするために、何か工夫をされているのでしょうか。
新関：弊社の運用チームと開発チームに、壁はないですね。たとえば、OSS の脆弱性情報が共有された場合には、お互いに把握している情報共有をしあって、「これは影響無いよね」「すぐやりましょう」などと判断し、確認する、といったコミュニケーションは頻繁にあります。
大塚：日々の監視は運用サイドにお任せしていて、何かあった場合はPSIRT にも共有してもらっています。
岡田：すばらしい連携が実現できているんですね。サイボウズは、プロダクトを使っている顧客との会話を促進するユーザコミュニティとのコミュニケーションも重視していますよね。また、2019年は2年ぶりに「サイボウズ バグハンター合宿 2019」を開催しておられました。興味深いですね。いかがでしたか？
大塚：はい、バグ・バウンティ(Bug Bounty：公に外部からのセキュリティ問題の指摘を受け付け、表彰する仕組み)自体は2014年から始めています。3 年ほど実施して報告内容が落ち着いてきたことを受けて、2年前から「バグハンター合宿」を実施するにあたって“チーム戦”に変更しました。狙いとしては、ハンター同士の横のつながりや知見を共有して頂くこと。これにより更なる脆弱性が見つかるのではないかと考えました。この狙いが見事に当たりまして、報告数が増えました。それを踏まえた上で、ハンターの数を今年は減らしてみました。
わたしたちは日々報告頂いているものを改修し続けている状況ですので、さすがに前回の報告数を上回ることはないだろうという予想だったのですが、今回は200件近い、過去最高の報告数がありまして、そのうち150件近い数が「認定」されました。ですので、まだまだ脆弱性はあるな、というのが実感として認識できました。
面白かったのは、報告内容がハンター間でほとんど重複しなかったことです。皆さんやっぱり、見る観点が違うんだなというのを改めて感じましたね。この「バグ・バウンティ」という制度自体が、窓口を置くだけでは意味が無く、多くのハンターに参加してもらって初めて効果が出るものなんだなということを改めて実感しました。
岡田：お話しになりにくいかもしれませんが、報告されたバグには、何か傾向がありましたか？ 設計ミス、実装ミス、ムラやブレ、認証がすっぽ抜けている・・・など。
大塚：我々としては実装ミスの指摘しか出てこないだろうと思っていたのですが、仕様レベルの報告が、実は、結構ありました。すごく古くから「前提」としてできあがっている部分でしたので、社内の目では気付きにくいところもあります。実装上のバグに対しては検証もしているし、コストをかけているという自信もあったんですが、仕様上のバグに関してはご指摘を受けてみて初めて、「えっ」と気付く感じでした。
ハンターの方から「これ、まずいんじゃないですか？」と指摘を受けるわけなんですが、内容を見ると、確かに、マズイんです。歴史的背景のある仕様なのですが、いつかは直したい。こうした指摘により、仕様そのものを見直し、調整していくことになります。
また、脆弱性を全てCVSS評価していく方針のなかで、仕様の問題については評価し切れないところがあることもにも気がつきました。これは社内でものすごく議論になった気づきです。
新関：実装レベルで出ているもの、上流工程での注意漏れから生じている問題、あとは、実装者も想定しなかったようなセキュリティ問題。それぞれを組織的にどう解決していくか、継続的に検討しなければいけないと思っています。
岡田：テックデット(tech debt)、技術負債と呼ばれる問題ですね。ソフトウェアのセキュリティ問題の原因は、設計半分、実装半分。また、セキュリティテストのコストプレッシャーやスピードプレッシャーによって、過去の資産まで手が回らないというか、改めてテストすることを省略してしまうんですよね。テストするとしても、新機能部分だけをちょろちょろっとテストするというような具合です。実際には、利用しているコンポーネントがずいぶんアップデートされていて、古いモジュールに対する攻撃が多くなるなど、外部脅威も変わっています。例えば、仮に一年前に「セキュア」だという評価を得ても、今この時点でセキュアだとは言いきれないという。本当にソフトウェアって生モノですよね。
今後の課題と望むこと
岡田：脅威そのものの多様化と共に、昨今はユーザというか、ユーザのソフトウェアの使い方が多様化していて、予測できないことも多いのではないでしょうか。これまでの「セキュリティ」といえば、インシデントが起きたらどうにかする、ということが目標だったかもしれませんが、今後は予防に努めよう、そもそもインシデントが起こりにくくしよう、など意識の変化はありますか。
大塚：そこはまさに、問題として意識しているところです。“何か起きた時”に動く体制というのは割とキチッとできているんですが、その“何か”が起きる前の手立てをとる、という体制の強化が必要です。
また、おっしゃる通り、ユーザの多様化も進んでいて、我々の側での検証段階では全く想定していなかった使い方も出てきています。お客様からご指摘いただく不具合をお聞きして初めて、「ええっそんな使い方が・・・？」と驚く事もあるんです。
岡田：お客さんのニーズとして、セキュリティ面や安心して使えるものを、というプレッシャーはありますか？
大塚：もちろん、あります。特にクラウドサービスについてはそれが顕著で、第三者サービスの検証を受けていることは、確実に要望としてあります。その他、弊社の取り組みの中で安心感・信頼感を与えられているのではないか、と思うことは、監査テストのテスト結果をホームページ上で公開している事ですね。テストしたバージョンと、テスト実施月、そして見つかった脆弱性を公開しています。弊社の中では、公明正大に、皆様に公開していこうという思いでやっています。
岡田：時折、新しいソフトウェアをリリースしたその日に「Known Issue（把握している問題）」のリストをバーンと出しているプロダクトがあります。「こんなに問題がある状態で、よく出荷できたものだ」という人もいるけれど、リスクコントロールの視点から見ると、よくそこまで課題を正確に把握しているものだと感心するんですよ。その上で、継続的に着々と改修されていく気持ち良さといいますか、カッコよさがありますよね。ソフトウェア開発の上では、そういう透明性というか、潔く公明正大なところを示すというのは、分かる人にはしっかり伝わっていくと思います。
最後に質問ですが、弊社のサービスに対して忌憚のないご要望をいただけますか。
大塚：いえいえ、大変助かっています！ とにかく、テスト・ファシリテーションだけでなく、問題や質問が発生した時のレスポンスが早いですね。他に何か困ったことがあった時でも、とにかく、何か聞いたらすぐに返事が戻ってくるだろうという安心感があります。
岡田：そうでしたか。お褒めいただいてありがとうございます。ソフトウェアを扱うにあたって、 “早さ”って、とても大事ですよね。最近、「DevOps」をF1 に例えて考えてみたんですけど、もっともスリルがあり、注目を集める状態、つまり全力でマシンが走っているレースそのものは、Ops ですよね。だとすると、Devはどこかと考えると、“ピット”だと思うんですね。短時間で、スタッフが一斉にマシンに群がって調整を施して、リリース判断のフラグが上がり、またレースへ送り出すわけです。
ここで、大事なのは、Ops からのインプットと、それを受け取るコミュニケーションです。これが、Dev は「次、何する？」ということを決めることができる。単に駆動に関わる機能だけでなく、「今、何が起こってます？」「どのくらいの何が必要？」と状況をモニタリングし、レポートさせることも、DevOps が成り立つために不可欠な仕事なんじゃないかと思うんです。
そこに対して、「ケイパビリティ」すなわち、問題をクリアにする仕組みや、その性能にアドバイスすることや、そうすることができる「パーツづくり」を推進することが必要。そういうことを特定していく視点の重要な部分が、セキュリティテストなんじゃないか。そう考えています。
今日はサイボウズの大塚さんと新関さんから、多面的なセキュリティ検査、運用と開発チームのスムースなコミュニケーション、オープンでスピーディな製品情報の開示が大切というお話を頂きました。今後も、サイボウズのプロダクトセキュリティにスピーディーに貢献していきたいと思います。引き続きどうぞよろしくお願いします。
