Internet Week 2018「Internet Week 流 Security Bootcamp」での講演資料です。 https://www.nic.ad.jp/iw2018/2018/d1/

1. 1
Tomohiro Nakashima
Internet Week 2018 | 2018.11.27 | Asakusabashi
脆弱性ハンドリングと耐える設計
Internet Week流Security Bootcamp

2. 2
本発表の内容は、10年以上にわたり、セキュリティの実務
運用に携わってきた筆者の経験に基づく、個人の見解です。
現在、過去の所属組織の公式見解ではありません。
Disclaimer

3. 3
はじめに
<概要>
脆弱性ハンドリング（脆弱性情報を収集、対処し、攻撃の
被害から防ぐこと）を基礎から取り上げるチュートリアル
セッション。運用水準と運用負荷の改善を目的とする。
<対象>
• 事業部門でシステムの脆弱性管理をしている方
• CSIRTなどで間接的に事業部の支援に当たっている方
• その他セキュリティに関心の高い方

4. 4
何気なく目にしているCVSSの理解を深めることで、脆弱性
ハンドリングが効率化されます。そして、その重要性を周
囲に説明できるようになります
そのほか、脆弱性ハンドリングを効率化する現場ノウハウ
を共有します。
今日伝えたいこと

5. Agenda
1. 脆弱性ハンドリング概要
2. 前提
3. 情報収集
4. トリアージ
5. 対処

6. 脆弱性ハンドリング概要

7. 7
今年もありました
円滑に対応できましたか？

8. 8
・・・
今日の情報システムと脆弱性
今日の情報システムはさまざまな製品群に依存する複合体
おのおのに脆弱性が報告される可能性がある
Application
Middleware
(含む設定)
OS Kernel
・・・
・・・
依存関係が多すぎて
把握することさえ困難

9. 9
脆弱性ハンドリングとは
今すぐ緊急対応
1週間程度で対応
定期メンテで対応
機会があれば対応
対応しない
振り分け
脆弱性情報
（セキュリティアドバイザリ）
極力右下↘️の分類に振り分けたい
「迅速に」「効率よく」「精度よく」
対処

10. 10
善管注意義務
業務を委任された人の職業や専門家としての能力、社会的
地位などから考えて通常期待される注意義務のこと。
（デジタル大辞泉より一部引用）
これを最低限満たさなければ
説明責任を果たすことができない

11. 11
公表日一致の原則
情報セキュリティ
早期警戒
パートナーシップ
Coordinated Vulnerability
Disclosure (CVD)

12. 12
脆弱性ハンドリングのながれ
情報収集 トリアージ※ 対処
※取捨選択

13. 13
システムライフサイクルと脆弱性ハンドリング
設計・構築 運用 廃止・更改
どのように効率よくやるかが鍵
情報収集
トリアージ
対処

14. 14
システムライフサイクルと脆弱性ハンドリング
運用負荷は実は設計・構築に依存する
設計・構築 運用 廃止・更改
情報収集
トリアージ
対処

15. 前提

16. 16
脆弱性ハンドリングが捗る状態
管理するべき対象が少ない
見るべき情報ソースが少ない
ハンドリングするべき脆弱性が少ない

17. 17
所有と利用
所有 利用
脆弱性管理は
原則所有者の責任
脆弱性管理は
原則委託先の責任
厳密には、委託先との契約条件、関係性に
よって責任の範囲、内容が変わってくる

18. 18
しばしば耳にする不幸な光景①
宛先：サービスサポート窓口
発信者：情シス担当者
件名：【至急】脆弱性○○について
担当者様
○○の脆弱性が報告されています。
当社にて利用しているサービス○○
への影響をお知らせください。
利用を選んだのに
負荷が減っていない！
脆弱性公表 5分後

19. 19
委託先管理の罠
本当に必要な委託先管理はどちら？
もし適切に対応されないとすれば委託先選定のミスでは？
委託先の対応状況を
リアルタイムに
ウォッチすること
脆弱性対応を適切に
行われた実績の確認

20. 20
見るべき情報ソースは少ないほうが捗る
オープン
ソース
本家
オープン
ソース
Web/ML
製品
ベンダ
商用製品
ベンダ
OS
ベンダ
商用OS
ベンダ
OS
ベンダ
その他
ベンダ
OS
ベンダ
その他
情報網

21. 21
商用OSと同梱オープンソースを利用する意義
• OSの一環として同梱オープンソースもサポート
• オリジナルとは独立したライフサイクル（長期間）
• 機能追加、仕様変更は極力しない（デグレード回避）
• 脆弱性対策のみのパッチを提供（バックポート）

22. 22
たとえば、Redhat Enterprise Linux
リリースから10年＋αのメンテナンス
引用元：https://access.redhat.com/support/policy/updates/errata

23. 23
しばしば耳にする不幸な光景②
OpenSSLに脆弱性があるらしいので
openssl.orgからダウンロードして
ビルドしておきました

24. 24
さらに悪いこと
/usr/bin, /usr/sbin
OS同梱のパッケージで導入されたもの
/opt/
OS同梱ではないパッケージから導入されたもの
/usr/local/bin, /usr/local/sbin,
/usr/local/*****, and so on
ソースコードなどから
ユーザが独自に導入されたもの
OSから管理可能
(パッケージ管理ツール)
人力でしか
管理運用が不可能

25. 25
現場の罠
啓蒙や明文化の不足
(当たり前過ぎて)
作業結果が設計やドキュ
メントに反映されない
教育・啓蒙不足
場当たり作業
分業の溝
指示者の意図と作業
者の理解の乖離

26. 26
製品選定の重要性
危険性の高い脆弱性が頻発する
ソフトウェアにはある程度傾向がある
【引用元】https://www.cvedetails.com/product/6117/Apache-Struts.html

27. 27
サポート切れ製品の利用
脆弱性情報自体が流通しない、パッチの提供も基本ない
リスクは未知数、そして最大

28. 28
脆弱性ハンドリングが捗る前提
オフロードできる対応はオフロードしましょう
「所有と利用」の選択は、最も大きな選択の一つ
エンタープライズでは商用OSの利用が一般的、
その恩恵をきちんと享受しましょう
製品選定は重要、サポート切れソフトウェアの利用は論外

29. 情報収集

30. 30
主な情報収集元
オープン
ソース
Web/ML
商用製品
ベンダ
商用OS
ベンダ その他

31. 31
確定情報はどこから得られるか？
たとえば、商用OS同梱のApache httpd
オープン
ソース
Web/ML
商用製品
ベンダ
商用OS
ベンダ その他
参考情報 参考情報確定情報

32. 32
確定情報はどこから得られるか？
たとえば、商用データベース製品
オープン
ソース
Web/ML
商用製品
ベンダ
商用OS
ベンダ その他
参考情報確定情報

33. 33
確定情報の重要性とジレンマ
最終的には確定情報が必要
パッチやワークアラウンドあって初めて対応に着手可能
対応できないのに対応しろと騒がれても現場は困る
参考情報が先行する場合には、それらを活用してプロアク
ティブに対応したい欲もあるが、何より現場がほしいのは
確定情報である

34. 34
インベントリ管理・突き合わせの手法
OS
独自ビルド
Webフレームワーク
パッケージ
OS同梱製品
商用製品
OS標準
管理ツール
脆弱性スキャナ
（クレデンシャル型、
エージェント型）
脆弱性スキャナ
（リポジトリ型）
手動管理

35. 35
クレデンシャル型脆弱性スキャン例 (Nessus)

36. 36
リポジトリ型脆弱性スキャン例 (Snyk)

37. 37
有償情報配信サービス
適材適所を考えて活用
垂れ流し型 インテリジェント型ピンポイント型
本当に危険なものだけ
厳選して通知
公開情報をそのまま
まとめて通知
$ $$ $$$
専門家による分析
や脅威動向込み

38. 38
ISAC(Information Sharing and Analysis Center)
脅威に関する情報を収集し、情報の双方向共有を提供する
ための非営利団体
業界業種ごとの組織が多い
（＝近しい立場同士で共有できるネットワーク）
たとえば、
金融、ICT(旧Telecom）、交通、Automotiveなど

39. 39
情報収集のポイント
確定情報の所在を見定めた情報収集
ツールを活用したインベントリ管理
有償サービスは適材適所の活用が有効
ISACなど近しい立場同士で共有できるネットワークは貴重

40. トリアージ

41. 41
トリアージとは
限られたリソースで最大の効果を得るための取り組み
トリアージとは、患者の重症度に基づい
て、治療の優先度を決定して選別を行う
こと(wikipediaより)
セキュリティに関する問題解決の「優先
順位」を決める事
転じて

42. 42
脆弱性情報のトリアージ
今すぐ緊急対応
1週間程度で対応
定期メンテで対応
機会があれば対応
対応しない
振り分け
脆弱性情報
（セキュリティアドバイザリ）
極力右下↘️の分類に振り分けたい
「迅速に」「効率よく」「精度よく」

43. 43
運用者にとって大事なこと
(できるだけ)攻撃の被害が生じる前に対処
(できるだけ)攻撃の被害が生じても極小化
(できるだけ)低工数、低コストで対応
(なにより)従業員のQOL(生活の質)を守る
脆弱性の「深刻度」と「緊急度」を見極めたい

44. 44
トリアージのすすめ
減 減
Step 1 Step 2 Step 3
対応不要なものを
定性的特性から除外
情報を精査し、
自社への影響を吟味
第三者情報も含めた
最終確認
CVSS Score
脆弱性情報中の
キーワード、表現
CVSS CalculatorCVSS Vector
Web/SNS巡回
外部との情報交換
考
え
方
ツ
ー
ル
・方
法
論 定型的対応 属人的対応
イ
ン
プ
ッ
ト

45. 45
脆弱性情報ちゃんと読めてますか？
Affected Version：対象
Description：解説
Impact：影響
Workaround：回避策
Mitigation：軽減策
Solution：解決策
特にココ

46. 46
CVSS：共通脆弱性評価システム
Common Vulunerability Scoring System：脆弱性の定性的な
評価を組み合わせ、深刻度を計算式で定量化する仕組み
専門家の知見を誰でも使えるフレームワークに集約したもの
CVSSv2 Score：7.8
CVSS Vector:
(AV:N/AC:L/Au:N/C:N/I:N/A:C)
CVSSv3 Score：7.5
CVSS Vector:
(AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

47. 47
運用者がCVSSを活用するべき3つの理由
一次判断の
効率化・迅速化
緊急度を下げる
妥当なロジック
見えないもの
が見えてくる
(場合がある)

48. 48
定量化による一次判断の効率化・迅速化
脆弱性情報の対応要否、深刻度や概要を迅速に判断
Score=深刻度
Vector=概要とScoreの根拠
CVSS Score Severity
9.0～10.0 Critical
7.0～8.9 High
4.0～6.9 Middle/Medium
0～3.9 Low
[共通脆弱性評価システムCVSS概説]
https://www.ipa.go.jp/security/vuln/CVSS.html
[共通脆弱性評価システムCVSS v3概説]
https://www.ipa.go.jp/security/vuln/CVSSv3.html
AV(攻撃元区分) N(ネットワーク経由)
AC(攻撃の複雑さ) L(低)
PR(必要な特権レベル) N(不要)
UI(ユーザ関与レベル) N(不要)
S(スコープ) U(変更なし)
C(機密性への影響) N(なし)
I(完全性への影響) N(なし)
A(可用性への影響) C(完全)
CVSSv3 Score：7.5
CVSS Vector:
(AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

49. 49
ケーススタディ：Jenkins Remote Code Execution
CVSS v3 内容
PR：Privileges Required
（必要な特権レベル）
不要(N) 特別な権限を有する必要はない。
低(L)
コンポーネントに対する基本的な権限を有していれば良い。
例えば、秘密情報以外にアクセスできるなど
高(H)
コンポーネントに対する管理者権限相当を有する必要がある。
例えば、秘密情報にアクセスできるなど
悪用するためには、
認証済みユーザであることが前提

50. 50
対応緊急度を下げる妥当なロジック
Base
Metrics
Temporal
Metrics
Environmental
Metrics
Base
Score
Temporal
Score
Environmental
Score≧ ≧
脆弱性そのもの
の特性を示す、
時間の経過や利
用環境によって
変化しない
攻撃コードや対
策情報の有無を
加味し、脆弱性
の現在の深刻度
を示す
利用環境も含め
て算出された最
終的な深刻度
補正 補正

51. 51
情報の質と量の非対称性
運用者<<発信者
(メーカー/ベンダー)

52. 52
CVSSから滲み出てくる発信者の想い
Case1)説明は”Unspecified Vulnerability”なのに
Vectorは細かく明記
Case2)CVSS ScoreとSeverityの乖離
• CVSS Score < Severity
やばそう
• CVSS Score > Severity
たいしたことなさそう
CVSS Score Severity
9.0～10.0 Critical
7.0～8.9 High
4.0～6.9 Middle/Medium
0～3.9 Low
Base AV:N/AC:L/Au:N/C:N/I:N/A:C
Temporal E:POC/RL:OF/RC:C
Environmental CDP:ND/TD:H/CR:ND/IR:ND/AR:ND
最悪でもサービス停止

53. 53
使いこなす
https://nvd.nist.gov/

54. 54
読みといてみる、再計算してみる

55. 55
CVSSのバージョン
歴史
• バージョン1：2005年2月リリース
• バージョン2：2007年6月リリース
• バージョン3：2015年6月リリース
現在
• 現在はv2/v3併記が多い
• v3はv2の評価基準を見直し、さらに細分化、再整理したもの、
より脅威の実態に即したに評価ができるようになった一方、少
し複雑化している
[参考]
共通脆弱性評価システムCVSS概説
https://www.ipa.go.jp/security/vuln/CVSS.html
共通脆弱性評価システムCVSS v3概説
https://www.ipa.go.jp/security/vuln/CVSSv3.html

56. 56
【再掲】運用者がCVSSを活用するべき3つの理由
一次判断の
効率化・迅速化
緊急度を下げる
妥当なロジック
見えないもの
が見えてくる
(場合がある)

57. 57
緊急性を考える判断指標
Unproven
PoC
Exists
High
Not
Defined
容易に
攻撃可能
攻撃コードがいかなる状況でも利用可能である
攻撃コードを必要とせず、攻撃可能である
攻撃可能 攻撃コードが存在し、ほとんどの状況で使用可能である
実証可能
実証コードが存在している
完成度の低い攻撃コードが存在している
未実証
実証コードや攻撃コードが利用可能でない
攻撃手法が理論上のみで存在している
未評価 この項目を評価しない
Exploitability：攻撃コードの実在状況

58. 58
緊急性を考える判断指標
修正差分(diff)を
チェックすることで
比較的推測が容易
詳細がつまびらかに
ならないため一般に
推測が困難
オープンソース プロプライエタリ

59. 59
緊急性を考える判断指標
発見者のリーク、あ
るいは示唆により推
測される可能性あり
自主的に改修された
ものであり、詳細が
市中に出回る可能性
は低い
謝辞有り 謝辞無し

60. 60
緊急性を考える判断指標
• 昔
• 大学でコンピュータサイエンスを嗜んだ学生
であれば攻撃および攻撃コードの作成が可能
• 現在
• OSの保護機能によりそんなに簡単ではない
メモリ保護 Stack Smash Protection
RELRO(RELocation ReadOnly)
メモリ
ランダマイズ
ASLR(Address Space Layout Randomization)
PIE(Position Independent Executable)
データ実行防止 NXbit(No eXecute bit)
DEP(Data Execution Prevention)
その他 Control Flow Guard
RCE
DoSなど
PoC
GOAL
RCE: Remote Code Execution
Buffer over Flow脆弱性とメモリ保護機能

61. 61
緊急性を考える判断指標
• 攻撃コードデータベースサイト
• 脆弱性情報データベースサイト
• Pastebin
• GitHub

62. 62
トリアージのポイント
脆弱性の「深刻度」と「緊急度」を把握したい
CVSSは情報の宝庫、うまく使いこなすことで脆弱性ハンド
リングが楽になる
緊急度の判断には攻撃コード流通のトレンドを取り入れる

63. 対処

64. 64
対処
パッチ ワークアラウンド
代替コントロール
（WAFなど）
システム停止

65. 65
パッチ/ワークアラウンド
間に合わなければ意味がない、そのためにできること
例えば
緊急リリースフロー整備、テスト項目厳選 など
迅速性
お作法

66. 66
代替コントロール（WAFなど）
備えなければすぐ使えない
ホスト型
ネットワーク型
クラウド型

67. 67
防御策がない
システムを止めますか？
Yes or No

68. 68
現実問題として止めることは難しい
しかし、最後の手段の選択肢として想定はしておきたい
その場でゼロからの止める判断、止める対応は難しく、
あらかじめの備え（訓練）が必要

69. 69
参考資料
NTT Communications様の取り組み 於 Internet Week2017
「Webサイトの脆弱性対策 ～サービスを止めるという判断
～」
https://www.nic.ad.jp/ja/materials/iw/2017/proceedin
gs/d1/d1-3-kamiyama.pdf

70. まとめ

71. 71
CVSSを適切に理解することで、脆弱性ハンドリングが効率
化されます。そして、その重要性を周囲に説明できるよう
になります。
そのほか、脆弱性ハンドリングを効率化する現場ノウハウ
を共有します。
今日伝えたかったこと

72. 72
Thank you！