More Related Content
Similar to Management for Security Life Cycle (日本語版) (20)
Management for Security Life Cycle (日本語版)
- 2. About Me
• サイボウズ株式会社でサービス / プロダク
トの脆弱性検証を行うチームに所属して
います
• その他に、自社のセキュリティ品質の向
上のための活動をしています
– 脆弱性対応の統括と対外窓口(POC)
– 組織内のセキュリティ全般について議論
– Security Challenge の運営を行いました
- 7. サイボウズの
脆弱性情報ハンドリング
• 2006 年以前
– 脆弱性情報を扱うチームはありませんでした
• 通常の問い合わせ窓口で対応していました
– 脆弱性情報は、自社で定めた不具合重要度判
定ルールに沿って、評価していました
• これまでに検出されてきた不具合を抽象化
• 抽象化した不具合ごとに、不具合の重要度を設定
し、重要度の高い問題から、優先して改修
– 脆弱性の評価は各製品の品質保証担当者が
行っていました
- 10. サイボウズの
脆弱性情報ハンドリング
• 2006 年 ~ 2009 年
– 外部の方との調整を行う PSIRT を設立
• 各製品のマネージャー担当が有志で活動
– PSIRT は対外窓口業務に専念
– 脆弱性の評価や公開調整は各サービスが権限
を持つことになりました
• 自社の独自基準に沿って脆弱性情報の判定を行っ
ていました
• 対応基準、公開基準は、サービスごとに異なりま
した
- 12. サイボウズの
脆弱性情報ハンドリング
• 2011 年 ~
– サイボウズに組織内 CSIRT が作成されました
• 自社クラウドサービスを開始することがきっかけ
• 専任の POC 担当者(2名)を設置
– 社内で検出された脆弱性情報は、CSIRT に集約
することにしました
• サービス、担当者ごとに脆弱性の評価が異なって
いた問題点を解消することが目的
• 脆弱性情報を公開可否を判断する権限は各サービ
スが持つ
- 18. 定量的な脆弱性情報の
評価プロセス
• OWASP Risk Methodology
– OWASP が提唱する Web アプリケーションの
脆弱性がビジネスに与えるリスクの見積もり
方
• Risk = Likelihood(攻撃可能性) * Impact
– 攻撃可能性と影響度をそれぞれ2つの観点で
10 段階評価(0 ~ 9)し、平均値を算出
– 評価結果をマトリクスに割り当て、脆弱性の
深刻度を測定
- 21. 定量的な脆弱性情報の
評価プロセス
• 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)
- 23. 定量的な脆弱性情報の
評価プロセス
• CVSS v2
– 情報システムの脆弱性に対するオープンで汎
用的な評価手法( Common Vulnerability Scoring
System )
– http://www.ipa.go.jp/security/vuln/CVSS.html
• 脆弱性のリスクを定量化できる
– 脆弱性の深刻度を 0.0 ~ 10.0 のスコアで評価
- 24. 定量的な脆弱性情報の
評価プロセス
• CVSS v2 の評価観点
– 攻撃元区分(AV)
– 攻撃の難易度(Ac)、攻撃者の認証要否
(Au)
– 機密性(C)、完全性(I)、可用性(A)の侵
害具合
• 各評価観点を3段階で評価
– 評価結果は独自の計算式で基本値を算出
– 脆弱性の種別(CWE)を評価に加味する
- 26. 定量的な脆弱性情報の
評価プロセス
• 良いところ
– 評価実績が豊富
• 2012 年時点で 30000 件以上の評価が JVN iPedia で
公開されていた
– 自社の脆弱性情報を外部の機関に評価いただ
いたことがある
• 2011 年 12 月までに、19 件
• 使いづらいところ
– 評価に参考になる資料が少ない
• 評価のための Tips は存在する
- 34. 自社の開発プロセスへの
取り込み
• CWE の選定
– 過去2年間に検出された脆弱性
– 外部のプロジェクトで検査基準として採用さ
れている CWE を収集し、共通して採用されて
いる脆弱性を抽出
• JVNiPedia
• IPA Web 健康診断
• OWASP Top 10 Project
- 36. 自社の開発プロセスへの
取り込み
• CVSS v2 を開発プロセスに組み込む
– 3段階の脆弱性の深刻度に応じて、脆弱性を
改修する優先度を設定
• 深刻度の高い脆弱性を優先して改修する
– CWE の種別によって、優先度を上げて対応す
るべき脆弱性は個別にルール化
• SQL Injection は 「レベルⅡ(警告)」 でも優先し
て改修する
• XSS の中でもより深刻な物は、優先して改修する
- 41. 自社の開発プロセスへの
取り込み
• 現在の課題
– CVSS v2 では評価できない脆弱性
• 2つ以上の脆弱性が組み合わさってより大きなイ
ンシデントが発生する場合、それぞれの脆弱性を
評価することしかできない
• 発生する被害を考慮して、柔軟に対応する
– CVSS v3 の採用検討
• 2014 年 6 月にリリースされる予定
• 評価方式が大きく変わるので、再評価が必要
- 48. ISO/IEC 29147
ISO/IEC 30111
• 脆弱性の取り扱い方法に関する国際規格
– ISO29147 Vulnerability disclosure
– ISO30111 Vulnerability handling processes
– 脆弱性情報の開示と脆弱性の対応に関して標
準化することを目的とした国際規格
• 2013 年初頭はどちらも DIS 投票中
– 国際基準として採択されるための投票
- 49. ISO/IEC 29147
ISO/IEC 30111
• イメージ
Accept Develop Publish
Vulnerability disclosure
(ISO/IEC 30111)
Vulnerability handling processes
(ISO/IEC 29147)
- 50. ISO/IEC 29147 の活用
• Vulnerability disclosure
• ベンダーと外部の関係者とのやり取り (イン
ターフェース)に着目して記述
– 脆弱性を検出したユーザー(またはコーディネー
ター)がベンダーに連絡する
– 届け出を受けたベンダーが脆弱性情報を公開する
• 2014 年 2 月 5 日に公開
– http://www.webstore.jsa.or.jp/webstore/Com/FlowCo
ntrol.jsp?lang=jp&bunsyoId=ISO%2FIEC+29147%3A20
14&dantaiCd=ISO&status=1&pageNo=1
- 51. ISO / IEC 30111
• Vulnerability handling processes
• ベンダー内部の取扱いに着目して記述
– CSIRT / PSIRT や各部門の役割と責任範囲を例示
– オンラインサービスとプロダクトの対応が分けて
記載されている
• 2013 年 10 月 22 日に公開
– http://www.webstore.jsa.or.jp/webstore/Com/FlowCo
ntrol.jsp?lang=jp&bunsyoId=ISO%2FIEC+30111%3A20
13&dantaiCd=ISO&status=1&pageNo=0
- 55. ISO/IEC 29147 の活用
• 脆弱性情報の受付窓口を明確にしました
– CSIRT 記述書を公開しました
– https://www.cybozu.com/jp/features/manageme
nt/cysirt.html
• 自社から公開する脆弱性情報の内容を改
善
– 自社で公開する脆弱性記事に自社の CVSS v2
の評価結果を付記しました
– 外部に公開した脆弱性情報には CVE 番号を付
記するようにしました
- 57. ISO / IEC 29147 の活用
• 謝辞ページを公開
– 脆弱性情報を報告いただいた方に、お名前の
掲載を許可いただいた場合、ホームページに
情報を掲載しています。
– http://cybozu.co.jp/specialthanks.html
- 58. ISO / IEC 30111 の活用
• 脆弱性情報を登録したデータベースを活
用
– 自社の不具合情報を公開する各チームと脆弱
性情報データベースを共有
– 脆弱性情報を公開するためのワークフローを
データベースに実装
– 脆弱性情報を外部に公開する前に、Cy-SIRT が
レビューするように変更
- 59. ISO / IEC 30111 の活用
• 自社で利用する第三者が作成したソフト
ウェアの棚卸し
– 第三者が作成したソフトウェアの脆弱性情報
を日時で収集し、関係者に共有
– 第三者が作成したソフトウェアに起因する脆
弱性が検出された際には、開発元に連絡
– 利用するソフトウェアに脆弱性が含まれた場
合の対応ポリシーを策定
- 61. ISO/IEC 29147
ISO/IEC 30111
• 脆弱性情報公開フロー
– 以下のいずれかに当てはまる場合、情報を公開す
る
• お客様が対抗策を導入する際に、作業が発生する場合
• 弊社内で情報セキュリティインシデントが発生した結
果、お客様に被害が発生した場合
• 外部の方から指摘いただいた場合
• 脆弱性対応フロー
– 検出された脆弱性は脆弱性の深刻度に 対
応する
- 62. ISO/IEC 29147
ISO/IEC 30111
• 導入の効果(脆弱性情報公開フロー)
– 脆弱性情報の公開内容を標準化できた
• 脆弱性情報を利用する方に役立つ情報を掲載でき
るようになった
– 外部の方とより積極的な協力体制を築くこと
ができるようになった
• 脆弱性発見コンテストの開催(2013 年 11 月開
催)
• 脆弱性検証環境提供プログラム (2 月開始)
• 脆弱性報奨金プログラムの開始 (4月予定)
- 63. ISO/IEC 29147
ISO/IEC 30111
• 現在の課題(脆弱性情報公開フロー)
– 外部の評価機関との連携
• 外部の評価期間が評価した深刻度と差異が出た場
合、説明が困難になる
• 評価機関と連携し、適切な脅威評価を行う
– 第三者が作成したソフトウェアの脆弱性管理
• 十分なセキュリティ情報が公開されない場合、自
社のソフトウェアでどのように対抗策を打つべき
か
- 64. ISO/IEC 29147
ISO/IEC 30111
• 導入の効果(脆弱性対応フロー)
– 脆弱性に対応する基準を外部に公開し、明確
化することが出来た
– 全社的に利用できる脆弱性情報データベース
を構築できた
– 第三者が作成したソフトウェアの脆弱性情報
を収集し、計画的に更新できるようになった
- 65. ISO/IEC 29147
ISO/IEC 30111
• 現在の課題(脆弱性対応フロー)
– 脆弱性として受理するかどうか
• CWE として定義されていないような攻撃方法
• ソーシャルエンジニアリングを活用した攻撃方法
– 一般的な不具合と脆弱性の対応優先度
• セキュリティ以外の品質を侵害する不具合と、脆
弱性をどのような優先度で対応するか
- 68. 参照資料
• 共通脆弱性識別子 CVE 概説(IPA)
– http://www.ipa.go.jp/security/vuln/CVE.html
• 脆弱性対策の効果的な進め方(IPA)
– https://www.ipa.go.jp/files/000035701.pdf
• 一般社団法人JPCERTコーディネーションセ
ンター 様ご提供資料
- 69. 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 認可・権限・アクセス制御
- 70. 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(システム設計上の問題)
- 71. References 2
• AC(攻撃条件の複雑さ):「低」
• 具体的なガイドライン
– 任意のパラメータに攻撃コードを登録することで
リスクが顕在化する
– 入力フォームに登録された値が起因となって、リ
スクが顕在化する
– API の JSON 文字列の中に含まれる値を改ざんする
ことで、リスクが顕在化する
– 外部から読み込むメールに、一般的な攻撃パター
ンが含まれている場合に、リスクが顕在化する
- 72. Reference 3
• CVE(Common Vulnerabilities and
Exposure)
– 個別の製品中の脆弱性を対象として、米国政
府の支援を受けた非営利団体の MITRE 社が採
番する識別子
– 一意の識別番号となる 「CVE 識別番号(CVE-
ID)」が付与される
– 日本では JPCERT/CC が CVE を割り当て
• 脆弱性情報の公開調整時に、CVE 番号を連絡いた
だき、弊社サイトから情報を公開時に掲載