セキュリティ品質向上に向けたサイボウズの取り組み

セキュリティ品質向上に向けたサイボウズの取り組み

伊藤彰嗣

Copyright (C) Cybozu,Inc. 1

自己紹介

•伊藤彰嗣（@springmoon6）

•グローバル開発本部品質保証部セキュリティチーム• サイボウズの CSIRT（Cy-SIRT）で窓口（PoC）を担当（兼務）

•経歴• 2006年新卒入社

• 2009年サイボウズ Garoon 品質保証責任者

• 2011年 cybozu.com 品質保証責任者

• 2011年 Cy-SIRT 立ち上げ

• 2014年脆弱性報奨金制度運営

• 2016年セキュリティキャンプ講師


Cy-SIRT

•サイボウズの CSIRT• Computer Security Incident Response Team


https://www.cybozu.com/jp/features/mana

gement/cysirt.html

https://www.cybozu.com/jp/features/mana

gement/cysirt.html

https://www.cybozu.com/jp/features/management/cysirt.html

https://www.cybozu.com/jp/features/management/cysirt.html

２つの役割

• Cybozu,Inc. Product Security Incident Response Team

• 製品に関する脆弱性情報を取り扱うチーム

Cy-PSIRT

• Cybozu,Inc. Computer Security Incident Response Team

• インシデント対応を行うチーム

Cy-SIRT


PSIRT としての活動


脆弱性情報管理

報奨金制度運営

脆弱性検査

外部機関との連携

セキュリティチームと連携しサービスを提供

脆弱性情報ハンドリングポリシー


http://cybozu.co.jp/company/internal_control/security/vulnerability.html

http://cybozu.co.jp/company/internal_control/security/vulnerability.html


外部からの脆弱性報告

社内からの脆弱性報告

脆弱性情報の受付

脆弱性情報の検証

脆弱性認定？

改修

回避策の配布

脆弱性情報の公開

報告者に連絡

脆弱性情報公開フロー脆弱性対応フロー

ISO/IEC 29147 より引用

No

Yes

今日お話しすること


脆弱性報奨金制度を開始することを検討されている組織の皆様に、制度を安定して運用するためのポイントをお伝えします。

脆弱性情報の受付事例報奨金制度における諸課題

脆弱性報奨金制度


サービスをセキュアにする活動


セキュア

開発訓練

コーディン

グ規約

フレームワー

クの利用

開発脆弱性の

即応体制

オペレー

ター教育

運用脆弱性検査

脆弱性情報

管理

外部機関と

の連携

QA

脆弱性報奨金制度

Copyright (C) Cybozu,Inc.

サイボウズでは発見できない未知の脅威への対策

11

制度の推移

170件

118件

95 件729万円

446万円

304万円

0

100

200

300

400

500

600

700

800

0

20

40

60

80

100

120

140

160

180

2014 年 2015 年 2016 年

認定件数報奨金額


大まかな流れ


報告者 Cy-SIRT

調整機関

開発本部

運用本部サイボウズ

情報公開

脆弱性報奨金制度による変化


脆弱性改修脆弱性情報

公開

Before

After

脆弱性改修脆弱性情報

公開

脆弱性情報受付

報奨金お支払い

脆弱性情報の受付事例


PDF Formcalc Attack


https://dl.dropboxusercontent.com/u/13018058/poc/appsec.pdf

セッション

被害サイト攻撃者被害者

APPSEC EU 2015 で公開された攻撃手法

https://dl.dropboxusercontent.com/u/13018058/poc/appsec.pdf

FormCalc


http://help.adobe.com/ja_JP/livecycle/9.0/FormCalc.pdf

演算関数文字列関数

日付と時間関数 URL 関数

会計関数その他の関数

論理関数

Adobe 社が開発した演算言語

http://help.adobe.com/ja_JP/livecycle/9.0/FormCalc.pdf

DEMO


問題点


ファイルがアップロードされているOrigin で任意のリクエストを発行することができる

http://insert-script.blogspot.jp/2015/05/pdf-mess-with-web.html

http://insert-script.blogspot.jp/2015/05/pdf-mess-with-web.html

タイムライン

Feb Mar Aug Sep Oct Nov


第一報受信

評価開始

Adobe 社と相談

脆弱性認定せず

議論の結果認定

評価について有識者と議論

制限事項に決定

情報公開

受領から対応完了までに 9 カ月

Adobe 社の見解


In the absence of content-injection attacks (or arbitrary file upload attacks) in a domain, we feel the path for an attacker to abuse CVE-2014-8453 has been closed. Earlier, the attacker could use redirects (in a domain he controlled) to trick Reader into thinking a cross-origin PDF was same-origin with a victim domain, and that attack vector has been resolved.

From our perspective, website owners must realize that PDF is active content, and serving user-uploaded/malicious PDFs from a non-throwaway domain is effectively an XSS (just like hosting an arbitrary/malicious HTML).

PDF は Active Contents であることを認識し、ユーザーがアップロードする PDF ファイルをプログラムが動作するオリジンには配置しないようにしなければならない。

サイボウズの見解

• 非互換な仕様変更に伴うユーザーへの説明コストが高く、ユーザーにとっても負担が大きい。特にオンプレミス版では別オリジンの設定を行うことが困難。

• 再現する環境の条件が限定的（他社製品の利用が前提となる）


本現象について、制限事項として情報公開する。サイボウズ製品を利用するユーザーに脅威があることを考慮し、回避策として、下記をアナウンスする。・IE/ Firefox でAdobe Reader プラグインを利用することは避ける

https://github.com/cybozu/bugbounty/tree/master/scope/PDFFormcalcAttack.md

https://github.com/cybozu/bugbounty/tree/master/scope/PDFFormcalcAttack.md

報奨金制度における諸課題5 つの課題をご紹介します



外部からの脆弱性報告

社内からの脆弱性報告



脆弱性認定？

改修

回避策の配布


報告者に連絡

脆弱性情報公開フロー脆弱性対応フロー

ISO/IEC 29147 より引用

No

Yes

1. 海外からの報告

• スコープ外にある運用中のWeb サイトのアカウントを

窃取することに成功したとの報告を受けた

各国の法律の違い

• 「報告者と協調する」ことが最優先であることを社内に周知

• 海外の方が参照できるように、規約の英語化を進める

解決策



2. 脆弱性の評価

• 複数の報告者からの問い合わせに対して、

同一の評価基準で脆弱性認定することが難しい

脆弱性の認定基準

• 脆弱性認定のためのガイドラインを策定する

• https://github.com/cybozu/bugbounty/tree/master/scope

解決策


脆弱性認定？

https://github.com/cybozu/bugbounty/tree/master/scope

脆弱性認定ガイドライン


https://github.com/cybozu/bugbounty/blob/master/scope/PDFFormCalcAttack.md

脆弱性概要認定可否対策箇所 /

認定しない理由

https://github.com/cybozu/bugbounty/blob/master/scope/PDFFormCalcAttack.md

3. 脆弱性情報の検証

• 認定基準に定められていない複雑な問題が多数寄せられる

• トリアージ / 評価チームを維持することが困難

認定基準に収まらない問題

• 分業体制の構築（開発者に評価を協力してもらう）

• トリアージチームが参照できる「共通仕様」の策定

解決策



サイボウズの評価体制

受付

• 非技術スタッフ

• ２名

トリアージ

• 技術スタッフ

• ２名

技術会議 (TLM)

• 全開発責任者

• オンライン

オフライン


脆弱性情報の受付件数


13

53

241208

183

0

50

100

150

200

250

2012 年 2013 年 2014 年 2015 年 2016 年

報告件数

Cybozu.com

Security Challenge

脆弱性報奨金制度常設

http://2013.seccon.jp/cybozucom-security-challenge.html

http://2013.seccon.jp/cybozucom-security-challenge.html

複雑な問題の例

• Reflected File Download• https://drive.google.com/file/d/0B0KLoHg_gR_XQnV4RVhlNl96MHM/view

• CSV Injection with the CVS export feature• https://hackerone.com/reports/72785

• CSV Excel Macro Injection• https://github.com/cybozu/bugbounty/blob/master/scope/CEMI.md

• PDF Formcalc Attack• http://insert-script.blogspot.jp/2014/12/multiple-pdf-vulnerabilites-text-

and.html


いずれも外部の評価事例が少なく、評価コストが高い

https://drive.google.com/file/d/0B0KLoHg_gR_XQnV4RVhlNl96MHM/view

https://hackerone.com/reports/72785

https://github.com/cybozu/bugbounty/blob/master/scope/CEMI.md

http://insert-script.blogspot.jp/2014/12/multiple-pdf-vulnerabilites-text-and.html

共通仕様


全製品が守ることを期待される仕様をまとめたドキュメント

TLM

提案承認

共通仕様

開発本部の共通言語。車輪の再発明を抑止し、トリアージチームも判断基準として使うことができる。

4. 影響が広い脆弱性情報の公開

• サイボウズをご利用中のユーザーだけでなく、

特定の条件を満たす多くの Web サイトに影響する問題が報告された

サードパーティ製品の仕様に起因する問題

• 当該サードパーティ製品ベンダーと相談する

• 公開時には、JPCERT/CC 様と相談する

解決策



JPCERT/CC 様との連携事例


https://jvn.jp/ta/JVNTA94087669/index.html

https://jvn.jp/ta/JVNTA94087669/index.html

5. 脆弱性情報の公開

• 脆弱性を公開していることが失注に繋がる事例が度々ある

• 脆弱性の公開にかかるコストが少なくない

経済的合理性

• 自社製品届け出に対して CVE 番号をスムーズに発券する仕組み

• １社だけでは難しく、脆弱性情報を流通させることの意義を広めたい

解決策



脆弱性報奨金制度を検討する組織の皆様へ


５つのポイント


脆弱性ハンドリングポリシー

ルールの明文化

報奨金の設計規約の設計どこまで

自社でやるか

1. 脆弱性ハンドリングポリシーの策定


脆弱性報奨金制度を支える仕組みを整備

2. 報奨金獲得ルールを明文化


事前にルールを定め公開すること

対象となるサービス

脆弱性認定ルール

脆弱性評価ルール

報奨金獲得に関するガイドライン

http://cybozu.co.jp/company/security/bug-bounty/guideline.pdf

http://cybozu.co.jp/company/security/bug-bounty/guideline.pdf

対象とするサービスを明記する


対象外環境への報告があった場合に、どのように対処するかを決めておく

報告者

対象外のサービス

Internet

対象となるサービス

様々なケースを想定してルールを決める


対処方針を明確に公開することで、報告者の方と円滑にコミュニケーションが可能に

Cybozu.com Security

Challenge

広告宣伝

目的の賞金

源泉徴収を

行う

常設の報奨金制度

情報提供料源泉徴収を

行わない

3. 報奨金の設計


施策の目的に応じた設計が必要

サイボウズでの事例紹介です。詳しくは各社様の顧問会計士・税理士の方とご相談ください。

4. 規約の設計


規約で抑えるべきリスクを最小限にする

協調的な脆弱性公開が

破たん

ライセンスの商用利用

収集した個人情報の漏洩

規約改定時の通知コスト

どういう目的でやるものかを明確にすること

お客様環境の保護

お客様がご利用中の環境

プログラム参加者が利用する環境

お客様がご利用中の環境と物理的に隔離。診断が原因となる障害は発生しない

2016 年 9 月現在のべ178 名の方が利用

http://cybozu.co.jp/securityprogram.html


http://cybozu.co.jp/securityprogram.html

5. どこまで自社で実装するか


報告者 POC

開発

運用ベンダー

情報公開

評価受付

支払

改修

公開

ベンダー以外でも出来る

ベンダーのみ出来る

報奨金制度運営業者の活用


https://hackerone.com/

https://bugcrowd.com/ https://bugbounty.jp/

https://www.vulbox.com/

https://hackerone.com/

https://bugcrowd.com/

https://bugbounty.jp/

https://www.vulbox.com/

活用する際の留意点


コミュニティの規模

脆弱性情報の委託

脆弱性評価

報告者とのコミュニケー

ション

報奨金の対象とする脆弱性

運営業者に支払う費用

Full Disclosure 型の Bug Bounty


https://www.openbugbounty.org/about/

外部からの脆弱性情報を受け付ける体制を整え、情報公開しておくことが重要

https://www.openbugbounty.org/about/

まとめ


セキュリティと報奨金制度

Copyright (C) Cybozu,Inc.

• 自社で行う様々な施策で脆弱性を減らす

• 脆弱性報奨金制度を活用し、未知の脅威を知る

サービスをセキュアにする活動

• 脆弱性ハンドリングポリシーの策定

• 報告窓口を設け、窓口情報を公開する

脆弱性報奨金制度を検討する皆様へ

50

Q&Aご清聴いただきありがとうございました


参考文書

• ISO/IEC 29147 Information technology — Security techniques —Vulnerability disclosure

• ISO/IEC 30111 Information technology — Security techniques —Vulnerability handling processes


セキュリティ品質向上に向けたサイボウズの取り組み

Internet

Transcript of セキュリティ品質向上に向けたサイボウズの取り組み