Security Challenge 番外編脆弱性の評価について

サイボウズ株式会社

伊藤彰嗣

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

その他、自社のセキュリティ品質の向上のための活動をしています。

POC 対応

組織内のセキュリティ全般

Security Challenge の運営

自己紹介

専用の不具合管理（脆弱性 Box）に登録

脆弱性を CWE タイプで分類

脆弱性を CVSS v2 を使って評価

評価結果を元に、より深刻な脆弱性から改修、公開

脆弱性情報のハンドリング

脆弱性の種類を識別するための共通の基準

（Common Weakness Enumeration）

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

多くのプロジェクトやセキュリティベンダが採用

NVD

OWASP Top 10 プロジェクト

CWE

情報システムの脆弱性に対するオープンで汎用的な評価手法（ Common Vulnerability Scoring System ）

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

脆弱性のリスクを定量化できる

機密性（C）、完全性（I）、可用性（A）の侵害具合

攻撃の難易度（Ac）、攻撃者の認証要否（Au）

攻撃元区分（AV）

CVSS v2

脆弱性 BOX

CVSS 測定状況

脆弱性の深刻度を汎用的な評価手法で測定することで、自社基準ではない値で定量化できる

各プロダクトを横断して、自社の脆弱性トレンドを把握することができる

登録～公開までの管理を１つのシステムで完結できる

メリット

CWE タイプごとに、CIA の侵害度に関するガイドラインを策定

他機関（IPA / NIST）の評価結果との差異を減らすため

「攻撃の難易度」については、JVNiPedia の評価方法をベースラインとして参照

これまでに検出された脆弱性と、JVNiPedia に登録されている評価結果をもとに、ガイドラインを策定

抽象的な評価基準だけだと、担当者ごとに評価がぶれることが多い

運用上の工夫

AC ：攻撃条件の複雑さ (Access Complexity) の評価

ベースライン

特別な攻撃条件を必要とせず、対象システムを常に攻撃可能である

ガイドライン

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

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

ガイドラインの例

採用していない CWE に関する評価を行う際には、つど検討が必要

複数の脆弱性を引き起こす攻撃や、複数の脆弱性が組み合わさって被害が発生するような問題を評価できない

CVSS v3 に期待！

http://www.first.org/cvss/v3/development

運用上の課題

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