Security Challenge 番外編
脆弱性の評価について
サイボウズ株式会社
伊藤 彰嗣
自己紹介

サイボウズ株式会社でサービス / プロダクトの脆弱
性検証を行うチームに所属しています
その他、自社のセキュリティ品質の向上のための
活動をしています。
POC 対応
組織内のセキュリティ全般
Security Challenge の運営
脆弱性情報のハンドリング

専用の不具合管理(脆弱性 Box)に登録
脆弱性を CWE タイプで分類
脆弱性を CVSS v2 を使って評価
評価結果を元に、より深刻な脆弱性から改修、公
開
CWE

脆弱性の種類を識別するための共通の基準
(Common Weakness Enumeration)
http://www.ipa.go.jp/security/vuln/CWE.html

多くのプロジェクトやセキュリティベンダが採用
NVD
OWASP Top 10 プロジェクト
CVSS v2

情報システムの脆弱性に対するオープンで汎用的
な評価手法( Common Vulnerability Scoring
System )
http://www.ipa.go.jp/security/vuln/CVSS.html

脆弱性のリスクを定量化できる
機密性(C)、完全性(I)、可用性(A)の侵害具合
攻撃の難易度(Ac)、攻撃者の認証要否(Au)
攻撃元区分(AV)
脆弱性 BOX
CVSS 測定状況
メリット

脆弱性の深刻度を汎用的な評価手法で測定するこ
とで、自社基準ではない値で定量化できる
各プロダクトを横断して、自社の脆弱性トレンド
を把握することができる
登録 ~ 公開までの管理を1つのシステムで完結で
きる
運用上の工夫

CWE タイプごとに、CIA の侵害度に関するガイド
ラインを策定
他機関(IPA / NIST)の評価結果との差異を減らすた
め

「攻撃の難易度」については、JVNiPedia の評価方
法をベースラインとして参照
これまでに検出された脆弱性と、JVNiPedia に登録さ
れている評価結果をもとに、ガイドラインを策定
抽象的な評価基準だけだと、担当者ごとに評価がぶ
れることが多い
ガイドラインの例

AC :攻撃条件の複雑さ (Access Complexity) の評価
ベースライン
特別な攻撃条件を必要とせず、対象システムを常に
攻撃可能である

ガイドライン
入力フォームに登録された値が原因となって、リス
クが顕在化
API の JSON 文字列の中に含まれる値を改ざんするこ
とで、リスクが顕在化
運用上の課題

採用していない CWE に関する評価を行う際には、
つど検討が必要
複数の脆弱性を引き起こす攻撃や、複数の脆弱性
が組み合わさって被害が発生するような問題を評
価できない
CVSS v3 に期待!
http://www.first.org/cvss/v3/development
ご清聴いただきありがとうございました!

seccon 富山前日勉強会 LT