Management for Security Life Cycle （日本語版）

脆弱性ライフサイクル管理

Akitsugu Ito@springmoon6

About Me

• サイボウズ株式会社でサービス / プロダクトの脆弱性検証を行うチームに所属しています

• その他に、自社のセキュリティ品質の向上のための活動をしています– 脆弱性対応の統括と対外窓口（ POC ）– 組織内のセキュリティ全般について議論– Security Challenge の運営を行いました

http://group.cybozu.jp/news/13092401.html

今日お話しすること

• 脆弱性のライフサイクル管理– 受け付けた脆弱性を、どのように取り扱うか

Accept Develop Publish

Vulnerability disclosure

Vulnerability handling processes

• サイボウズの脆弱性情報ハンドリング• 定量的な脆弱性情報の評価プロセス• 自社の開発プロセスへの取り込み• プロセスの改善• ISO/IEC 29147 および ISO/IEC 30111

Agenda

サイボウズの脆弱性情報ハンドリング

社内検出評価改修

報告者へ返答

外部からの

報告

各サービス

サポート窓口

• 脆弱性情報ハンドリングフロー（～ 2006 年）

自社公開


• 2006 年以前– 脆弱性情報を扱うチームはありませんでした• 通常の問い合わせ窓口で対応していました

– 脆弱性情報は、自社で定めた不具合重要度判定ルールに沿って、評価していました• これまでに検出されてきた不具合を抽象化• 抽象化した不具合ごとに、不具合の重要度を設定

し、重要度の高い問題から、優先して改修– 脆弱性の評価は各製品の品質保証担当者が

行っていました


• 2006 年– 改修された脆弱性情報が適切に公開されてい

ない旨、ご指摘をいただきました• 改修した脆弱性のうち、サイボウズが非公開の脆

弱性が存在した• サポート担当者が適切な回答が出来なかった

http://web.archive.org/web/20120315061523/http:/takagi-hiromitsu.jp/diary/20060830.html


• 脆弱性情報の取り扱い方に問題– 脆弱性情報について、お客様からのお問い合

わせを受け付ける専門のチームが無い– どのような現象を脆弱性として捉えるか、整

理できていない– 脆弱性情報を公開するポリシーが明確ではな

い


• 2006 年～ 2009 年– 外部の方との調整を行う PSIRT を設立• 各製品のマネージャー担当が有志で活動

– PSIRT は対外窓口業務に専念– 脆弱性の評価や公開調整は各サービスが権限

を持つことになりました• 自社の独自基準に沿って脆弱性情報の判定を行っ

ていました• 対応基準、公開基準は、サービスごとに異なりま

した


社内検出評価改修

報告者へ返答

外部からの

報告

各サービス

PSIRT

• 脆弱性情報ハンドリングフロー（～ 2009 年）

自社公開

外部公開


• 2011 年～– サイボウズに組織内 CSIRT が作成されました• 自社クラウドサービスを開始することがきっかけ• 専任の POC 担当者（２名）を設置

– 社内で検出された脆弱性情報は、 CSIRT に集約することにしました• サービス、担当者ごとに脆弱性の評価が異なって

いた問題点を解消することが目的• 脆弱性情報を公開可否を判断する権限は各サービ

スが持つ


社内検出改修

報告者へ返答

外部からの

報告

各サービス

Cy-SIRT

• 脆弱性情報ハンドリングフロー（ 2011 年～）

自社公開

評価外部公開


• 発生した問題– 評価への納得感が得られない• 多くの脆弱性が「緊急対応」と判断されていた

– 攻撃の容易さが評価されていない• 攻撃が成功した時の危険性のみを評価していた

– 第三者が作成したソフトウェアの脆弱性を評価することができない• パッチを適用するべきかどうかが判断できなかっ

た


• 問題解決のために– 定量的な脆弱性情報の評価プロセスを調査– 脆弱性情報のハンドリングプロセスについて

調査

• 調査結果をもとに、新たなプロセスを策定


Agenda

定量的な脆弱性情報の評価プロセス

• 採用要件– 脆弱性の評価基準を標準化できること– 脆弱性のリスクを定量的に測定できるフレー

ムワークであること

• 調査対象– OWASP Risk Methodology– CVSS v2


• OWASP Risk Methodology– OWASP が提唱する Web アプリケーションの

脆弱性がビジネスに与えるリスクの見積もり方

• Risk = Likelihood （攻撃可能性） * Impact– 攻撃可能性と影響度をそれぞれ２つの観点で

10 段階評価（ 0 ～ 9 ）し、平均値を算出– 評価結果をマトリクスに割り当て、脆弱性の深刻度を測定

https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology


• 評価結果の平均値を３段階に分類– Low （ 0 to < 3 ）– Medium （ 3 to < 6 ）– High （ 6 to 9 ）


• 良いところ– リスク評価の判断軸が分かり易い–詳細にリスク評価できる– 各評価項目に判断用の具体的なガイドライン

が存在する


• Likelihood - Threat Agent Factor (Skill Level)– Security penetration skills (1)– network and programming skills (3)– advanced computer user (4)– some technical skills (6)– no technical skills (9)


• 使いづらいところ–採用実績が少ない（もしくは無い）• 社内向けに説明する際には必要• 自社向けにガイドラインを作成する際にも、他機関の評価結果を参考にしたい

– 12 ～ 16 項目の評価が必要で評価工数は高め–過去に判断した脆弱性との整合性を確保する

ことが難しい• １６項目の評価基準が 10 段階評価


•CVSS v2– 情報システムの脆弱性に対するオープンで汎

用的な評価手法（ Common Vulnerability Scoring System ）

– http://www.ipa.go.jp/security/vuln/CVSS.html

• 脆弱性のリスクを定量化できる– 脆弱性の深刻度を 0.0 ～ 10.0 のスコアで評

価

http://www.ipa.go.jp/security/vuln/CVSS.html


•CVSS v2 の評価観点– 攻撃元区分（ AV ）– 攻撃の難易度（ Ac ）、攻撃者の認証要否（ Au ）–機密性（ C ）、完全性（ I ）、可用性（ A ）の侵害具合

• 各評価観点を３段階で評価– 評価結果は独自の計算式で基本値を算出– 脆弱性の種別（ CWE ）を評価に加味する


• 基本値を元に、脆弱性の深刻度を評価– CVSS スコア：レベルⅢ （危険）（ 7.0 ～

10.0 ）– CVSS スコア：レベルⅡ （警告）（ 4.0 ～ 6.9 ）– CVSS スコア：レベルⅠ （注意）（ 0.0 ～ 3.9 ）

• ベンダーからリリースされた基本値を元に、利用者は自社への影響度を測定できる


• 良いところ– 評価実績が豊富

• 2012 年時点で 30000 件以上の評価が JVN iPedia で公開されていた

– 自社の脆弱性情報を外部の機関に評価いただいたことがある• ２０１１年 12 月までに、１９件

• 使いづらいところ– 評価に参考になる資料が少ない

• 評価のための Tips は存在する


• CVSS v2 を採用することにしました– 脆弱性の評価を標準化する目的に合致してい

た– 第三者が作成したソフトウェアでも広く利用

されていた


Agenda

自社の開発プロセスへの取り込み

• 採用にあたって準備したこと– 自社の脆弱性の調査– 評価プロセスの策定– 脆弱性対応フローへの適用

• 準備期間–１か月程度


• 自社の脆弱性の調査– 2010 年～ 2011 年に検出された自社の全製品

の脆弱性情報を１つのデータベースに集約• 120 件前後

– 全ての脆弱性情報を、 CVSS v2 を使って評価– 当初は複数人で調査• 複数人で作業すると、評価結果が合わないことが頻発し、まずは１名で作業することに


• これまでの社内基準

• CVSS v2 をつかった評価結果

緊急対応 49

警告 65

Level (HIGH)Ⅲ 17Level (MIDDLE)Ⅱ 59Level (LOW)Ⅰ 38


• 採用する脆弱性タイプ（ CWE ）を検討– CVSS 評価を行う際に、脆弱性タイプごとに、

評価観点が統一されるため– XSS （ AV/Ac/Au/C/I/A:-/-/-/N/P/N ）

• 外部の機関と評価結果を合わせるためには、自社で採用する脆弱性タイプを決める必要がある


• CWE （ Common Weakness Enumeration ）–共通脆弱性タイプ一覧– 脆弱性の種類を識別し、体系立てて管理する

ことが目的–米国政府の支援を受けて MITRE が中心に仕様

を策定• 米国政府向けの技術支援や研究開発を行う非営利

組織– 2008 年 9 月 9 日にバージョン 1.0 が公開


• CWE の選定–過去２年間に検出された脆弱性– 外部のプロジェクトで検査基準として採用さ

れている CWE を収集し、共通して採用されている脆弱性を抽出• JVNiPedia• IPA Web 健康診断• OWASP Top 10 Project

http://www.ipa.go.jp/security/vuln/documents/website_security_shindan.pdf

http://www.ipa.go.jp/security/vuln/documents/website_security_shindan.pdf


• 評価プロセスの策定–複数人で評価しても評価結果がある程度ぶれな

いようにする仕組みが必要

• ガイドラインの策定– 120 件の脆弱性情報を評価した結果を元に、自

社で使いやすい具体的な評価ガイドラインを策定

–ガイドラインを元に評価した内容を、２名以上でレビューする


• CVSS v2 を開発プロセスに組み込む–３段階の脆弱性の深刻度に応じて、脆弱性を

改修する優先度を設定• 深刻度の高い脆弱性を優先して改修する

– CWE の種別によって、優先度を上げて対応するべき脆弱性は個別にルール化• SQL Injection は「レベルⅡ（警告）」でも優先し

て改修する• XSS の中でもより深刻な物は、優先して改修する


• 導入後２年間の深刻度分布

33

99178

レベルⅢ レベルⅡ レベルⅠ


• 導入後２年間の脆弱性分布

CWE-26429%

CWE-7924%

CWE-2012%

CWE-899%

CWE-3996%

CWE-2005%


• 導入後２年間の脆弱性分布– 以下の脆弱性が全体の７割を占める• CWE-264 認可・権限・アクセス制御• CWE-79 クロスサイト・スクリプティング (XSS) ）• CWE-20 不適切な入力確認• CWE-89 SQL インジェクション


• 導入の効果– 脆弱性の評価を標準化できた– 脆弱性の深刻度を社外に説明できた• ベンダーとして脆弱性の詳細情報を伝えずに、脆

弱性の深刻度を説明することは困難だった• 同じように非公開の脆弱性情報を元に、外部機関

が脆弱性の深刻度を評価するのは困難だと思います

– 脆弱性情報を集約することで、他のプロジェクトへの情報共有が可能になった


• 現在の課題– CVSS v2 では評価できない脆弱性• ２つ以上の脆弱性が組み合わさってより大きなイ

ンシデントが発生する場合、それぞれの脆弱性を評価することしかできない• 発生する被害を考慮して、柔軟に対応する

– CVSS v3 の採用検討• 2014 年 6 月にリリースされる予定• 評価方式が大きく変わるので、再評価が必要


Agenda

プロセスの改善

社内検出改修

報告者へ返答

外部からの

報告

各サービス

Cy-SIRT


自社公開

評価外部公開


• 実際に起きたインシデント– 外部機関と脆弱性情報の公開時期を調整中に、

自社で不具合として公開してしまった– 公開した情報を元に、お問い合わせを複数いた

だき、当初想定していた脆弱性情報の外部公開時期を早めた

脆弱性への対抗策のリリースポリシーが不明確である点について、多くの方からご指摘いただく


• 問題点– 自社で不具合情報を公開するチームと、 CSIRT

で脆弱性情報が一元管理されていない– 脆弱性に対応する基準が公開されていない– 脆弱性情報を公開する基準が明確に定められ

ていない


• 課題に解決にあたって–体系立ててまとめられたフレームワークに

沿って、情報を公開することはできないか

• ちょうどその頃、 JPCERT/CC 様から良い情報をいただく– ISO/IEC 29147– ISO/IEC 30111


Agenda

ISO/IEC 29147ISO/IEC 30111

• 脆弱性の取り扱い方法に関する国際規格– ISO29147 Vulnerability disclosure– ISO30111 Vulnerability handling processes– 脆弱性情報の開示と脆弱性の対応に関して標

準化することを目的とした国際規格

• 2013 年初頭はどちらも DIS 投票中–国際基準として採択されるための投票


• イメージ

Accept Develop Publish

Vulnerability disclosure(ISO/IEC 30111)

Vulnerability handling processes（ ISO/IEC 29147）

ISO/IEC 29147 の活用

• Vulnerability disclosure• ベンダーと外部の関係者とのやり取り ( インター

フェース ) に着目して記述– 脆弱性を検出したユーザー（またはコーディネーター）がベンダーに連絡する

– 届け出を受けたベンダーが脆弱性情報を公開する

• 2014 年 2 月 5 日に公開– http://

www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=ISO%2FIEC+29147%3A2014&dantaiCd=ISO&status=1&pageNo=1　

http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=ISO/IEC+29147:2014&dantaiCd=ISO&status=1&pageNo=1




ISO / IEC 30111

• Vulnerability handling processes• ベンダー内部の取扱いに着目して記述– CSIRT / PSIRT や各部門の役割と責任範囲を例示– オンラインサービスとプロダクトの対応が分けて記載されている

• 2013 年 10 月 22 日に公開– http://

www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=ISO%2FIEC+30111%3A2013&dantaiCd=ISO&status=1&pageNo=0






• 自社で採用するにあたり–国際規格に準拠することが目的では無い– プロセスを改善するためのガイドラインとし

て利用–急がない

• 大きな枠組みはそのまま採用する– 脆弱性対応フロー– 脆弱性情報公開フロー


社内検出改修

報告者へ返答

外部からの

報告

各サービス

Cy-SIRT


自社公開

評価外部公開

ISO/IEC 29147 の活用

•脆弱性情報の受付窓口を明確にしました– CSIRT 記述書を公開しました– https://www.cybozu.com/jp/features/managemen

t/cysirt.html

• 自社から公開する脆弱性情報の内容を改善– 自社で公開する脆弱性記事に自社の CVSS v2

の評価結果を付記しました– 外部に公開した脆弱性情報には CVE 番号を付記するようにしました

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

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

ISO / IEC 29147 の活用


• 謝辞ページを公開– 脆弱性情報を報告いただいた方に、お名前の掲載を許可いただいた場合、ホームページに情報を掲載しています。

– http://cybozu.co.jp/specialthanks.html

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




• 脆弱性情報を登録したデータベースを活用– 自社の不具合情報を公開する各チームと脆弱

性情報データベースを共有– 脆弱性情報を公開するためのワークフローをデータベースに実装

– 脆弱性情報を外部に公開する前に、 Cy-SIRT がレビューするように変更


• 自社で利用する第三者が作成したソフトウェアの棚卸し– 第三者が作成したソフトウェアの脆弱性情報

を日時で収集し、関係者に共有– 第三者が作成したソフトウェアに起因する脆

弱性が検出された際には、開発元に連絡–利用するソフトウェアに脆弱性が含まれた場

合の対応ポリシーを策定


• 脆弱性への対応と、情報公開基準の公開


• 脆弱性情報公開フロー– 以下のいずれかに当てはまる場合、情報を公開す

る• お客様が対抗策を導入する際に、作業が発生する場合• 弊社内で情報セキュリティインシデントが発生した結

果、お客様に被害が発生した場合• 外部の方から指摘いただいた場合

• 脆弱性対応フロー– 検出された脆弱性は脆弱性の深刻度に応じて対応

する


• 導入の効果（脆弱性情報公開フロー）– 脆弱性情報の公開内容を標準化できた• 脆弱性情報を利用する方に役立つ情報を掲載でき

るようになった– 外部の方とより積極的な協力体制を築くこと

ができるようになった• 脆弱性発見コンテストの開催（ 2013 年 11 月開催）• 脆弱性検証環境提供プログラム（ 2 月開始）• 脆弱性報奨金プログラムの開始（４月予定）


• 現在の課題（脆弱性情報公開フロー）– 外部の評価機関との連携• 外部の評価期間が評価した深刻度と差異が出た場

合、説明が困難になる• 評価機関と連携し、適切な脅威評価を行う

– 第三者が作成したソフトウェアの脆弱性管理• 十分なセキュリティ情報が公開されない場合、自

社のソフトウェアでどのように対抗策を打つべきか


• 導入の効果（脆弱性対応フロー）– 脆弱性に対応する基準を外部に公開し、明確

化することが出来た– 全社的に利用できる脆弱性情報データベース

を構築できた– 第三者が作成したソフトウェアの脆弱性情報

を収集し、計画的に更新できるようになった


• 現在の課題（脆弱性対応フロー）– 脆弱性として受理するかどうか• CWE として定義されていないような攻撃方法• ソーシャルエンジニアリングを活用した攻撃方法

–一般的な不具合と脆弱性の対応優先度• セキュリティ以外の品質を侵害する不具合と、脆

弱性をどのような優先度で対応するか

まとめ

• 国際標準規格を参考に、脆弱性情報の取り扱い方法を改善しました– Vulnerability handling processes• CVSS v2 の採用• 第三者ソフトウェアの取り扱い

– Vulnerability disclosure• 公開プロセス / 公開内容の改善（ CVE ）• 外部の方との協力体制（謝辞 / Bug Bounty

Proglam ）

ご質問など

• ご清聴いただきありがとうございました

参照資料

• 共通脆弱性識別子 CVE 概説（ IPA ）– http://www.ipa.go.jp/security/vuln/CVE.html

• 脆弱性対策の効果的な進め方（ IPA ）– https://www.ipa.go.jp/files/000035701.pdf

• 一般社団法人 JPCERTコーディネーションセンター様ご提供資料

http://www.ipa.go.jp/security/vuln/CVE.html



https://www.ipa.go.jp/files/000035701.pdf

https://www.ipa.go.jp/files/000035701.pdf

References 1

• サイボウズが採用する CWE （ 17 種類）– CWE-16 環境設定– CWE-20 不適切な入力確認– CWE-22 パストラバーサル– CWE-78 OS コマンドインジェクション– CWE-79 クロスサイト・スクリプティング (XSS) ）– CWE-89 SQL インジェクション– CWE-93 CRLF Injection （メールヘッダ・インジェクション）– CWE-113 HTTPヘッダ・インジェクション– CWE-200 情報漏えい– CWE-264 認可・権限・アクセス制御

References 1

• サイボウズが採用する CWE （ 17 種類）– CWE-287 不適切な認証– CWE-352 クロスサイト・リクエスト・フォージェリ

（ CSRF ）– CWE-362 競合状態– CWE-384 Session Fixation– CWE-399 リソース管理の問題– CWE-601 オープンリダイレクタ– CWE-614 ログインの不備 - クッキーのセキュア属性

不備– CWE-Other （その他）– CWE-DesignError （システム設計上の問題）

References 2

• AC （攻撃条件の複雑さ）：「低」• 具体的なガイドライン– 任意のパラメータに攻撃コードを登録することで

リスクが顕在化する– 入力フォームに登録された値が起因となって、リ

スクが顕在化する– API の JSON 文字列の中に含まれる値を改ざんす

ることで、リスクが顕在化する– 外部から読み込むメールに、一般的な攻撃パター

ンが含まれている場合に、リスクが顕在化する

Reference 3

• CVE （ Common Vulnerabilities and Exposure ）–個別の製品中の脆弱性を対象として、米国政府の支援を受けた非営利団体の MITRE 社が採番する識別子

–一意の識別番号となる「 CVE 識別番号（ CVE-ID ）」が付与される

– 日本では JPCERT/CC が CVE を割り当て• 脆弱性情報の公開調整時に、 CVE 番号を連絡いた

だき、弊社サイトから情報を公開時に掲載

Management for Security Life Cycle （日本語版）

Engineering

Transcript of Management for Security Life Cycle （日本語版）