第0回脆弱性対応勉強会 2018/12/08-

発言は個人の見解であり、所属組織を代表 するものではありません。 また、所属組織の情報をもとにした見解で はなく、過去の経験や他のインシデントを 観察し、得た知見です。

脆弱性対応研 究会、とは サーバ等の運用をしていると、脆弱性対 応を定期的に実施する必要があるとおも います。 しかしながらこれらについて、 「どのように脆弱性を発見し、影響を判 断するのか」 がまとまった情報が少なく、そのノウハ ウを共有したく、この勉強会を作りまし た。 特に、OSやフレームワークやライブラ リの階層について検討したいと思います。

本日の進め方 脆弱性対応の基礎知識部分を再確認し、特定のCVE番号が振られ た脆弱性について考えてみようと思います。 • 脆弱性対応の基礎知識 ➢CVE、CVSS v2/v3、CVSS[Score|Vector|Environment]、脆弱性の報告経路、OSSと パッケージのOSS ➢脆弱性情報の収集 ➢脆弱性情報の調査方法 ➢自組織への適用判断 • 脆弱性対応ロールプレイ ➢特定のCVE-IDを調査し、トリアージや更新計画を立てて見舞う

脆弱性対応の基礎復習

An overview of this section ここでは、脆弱性対応に関する知識の再 確認をしようと思います。 • 利用しているスキームの再確認 • CVE, CVSS, CVSS[ Score | Vector | Environment ] • 脆弱性発見後の、通常の報告経路 • どのようなフローで対応するのか • フローごとの検討事項 • 情報収集、脆弱性認知 • 脆弱性の詳細確認 • 自組織への適用判定 • 適用と、適用情報の管理

利用しているスキームの再確認 CVSS ScoreやCVE-IDなどを利用していますが、これはどういうものなのでしょうか。 • SCAP(Security Content Automation Protocol：セキュリティ設定共通化手順)の中で定 義されています。 • 2002年に連邦情報セキュリティマネジメン法(FISMA)が施行 • 政府省庁ではFISMAに対応するため、他の様々な法律や連邦政府情報処理規格等の 要求事項に対応する必要が発生 • とても人力では無理 • 情報セキュリティ対策の自動化と標準化を目指し、SCAPを開発 FISMA (2002年) の施行 各種のセキュリ ティ要求事項に 対応が必要 自動化や効率化 が求められる 自動化と標準化 を目指したSCAP が開発

SCAPの構成 SCAPは以下の6つの仕様から構成されています。 • 脆弱性を識別するCVE • セキュリティ設定を識別するCCE • 製品を識別するCPE • 脆弱性の深刻度を評価するCVSS • チェックリストを記述するためのXCCDF • 脆弱性やセキュリティ設定をチェックするOVAL このうち、よく利用する以下について再確認します。 • CVSS • CVE IPA：セキュリティ設定共通化手順SCAP概説 https://www.ipa.go.jp/security/vuln/SCAP.html SCAP • CVE • CVSS • CPE • OVAL • CCE • XCCDF 頻繁に使う 頻繁に使う 頻繁に使う

CVSSの詳細 v2とv3の、2つのバージョンがあります。 • 評価方法を変更 • https://www.ipa.go.jp/security/vuln/CVSSv3.html 双方とも以下の3分類に分かれています。 • 基本評価基準(Base Metrics) • 機密性(Confidential Impact)、完全性(Integrity Impact)、可用性(Availability Impact)に対する影響 を評価 • 現状評価基準(Temporal Metrics) • 攻撃コードの有無等の、脆弱性の現在のの深刻度を 評価 • 環境評価基準(Environmental Metrics) • 利用者の環境を含め、最終的な深刻度を評価 IPA:共通脆弱性評価システムCVSS概説 https://www.ipa.go.jp/security/vuln/CVSS.html CVSS • Base Metrics ←いつも使っているはず • Temporal Metrics • Environmental Metrics

CVSS BaseMetrics BaseMetricsは、脆弱性そのものの特性で変化のないもの、の情 報です。 • いつも見てるはずの、アレ • CVSS v2 BaseScore: 7.5 High • CVSS v2 Vector: (AV:N/AC:L/Au:N/C:P/I:P/A:P) • CVSS v3 BaseScore: 9.8 CRITICAL • CVSS v3 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H • これらは、CVE-2018-3259 Oracle Database ServerのJavaVMにおける脆弱性。 • https://nvd.nist.gov/vuln/detail/CVE-2018-3259 • https://jvndb.jvn.jp/ja/contents/2018/JVNDB-2018-008642.html

CVSS Base Metrics Vector IPAの資料が詳しい。 • https://www.ipa.go.jp/security/vuln/CVSSv3.html

CVSS Temporal/Environmental Metrics IPAの資料が詳しい。 • https://www.ipa.go.jp/security/vuln/CVSSv3.html • Temporalは、時間が経過すると変化する特性を加味している • Exploit code（攻撃コード）が出回っているか、情報元の信頼性など。 • Environmental Metricsは、ユーザの利用環境等により変化する ものを加味している • 対象システムのセキュリティ要求度（停止しても構わない、漏洩しても問題ない情 報しかない、等）など。 BaseScoreを状況に応じて下げる=緊急度を下げる、妥当な判断 情報、として扱えます。

CVSSの何を重視すればいいのか おおよそ以下を重要視するのが良い、と考えています。 • 攻撃元区分 • ネットワークの攻撃は、単独で攻撃される可能性 • ローカルの攻撃は、内部不正 もしくは ネットワーク攻撃成功後に利用される可能性。 • CIA(機密性/完全性/可用性) • 情報の漏洩、情報改ざん、業務停止 の影響 • 攻撃される可能性 • 攻撃コードが既に存在しているか 他の評価値も重要ですが、まず最初に見るのはこれでよいはず。

CVE-IDとは IPAの資料が詳しい • https://www.ipa.go.jp/security/vuln/CVE.html • 「プログラム上のセキュリティ問題を一意に識別する」目的 • 米国Mitre社により登録申請…だったが、今はCNA(CVE numbering Authorities)により採番されている。 • https://cve.mitre.org/cve/cna.html • https://internet.watch.impress.co.jp/docs/column/security/1104483.html

脆弱性の発見と登録 脆弱性の発見と修正は、以下のプロセスで行われます • 脆弱性を発見する • 研究者等により発見される • CVE-IDの採番 • 発見した脆弱性を採番する。 • 情報の登録 • NISTのNVDに登録される。 • 開発元との調整、修正 • 開発元に脆弱性を告知。修正を行う。 • 情報の公開 • 脆弱性と対策の公表 • 修正プログラムの配布 • 開発元から、更新プログラムの公開。 日本の同様なものとして JVN(Japan Vulnerability Notes) がある。 ベンダとの調整により公開に至った脆弱性情報を公開 している。 自社で発見した場合、自組織の脆弱性識別番号とCVE-IDの 両方が付与されることが多い。 例 Redhat RHSA-2018:2919 - CVE-2018-10194 - CVE-2018-15910 - CVE-2018-16509 - CVE-2018-16542 発見 採番 登録 調整 公開 配布

脆弱性対応のフロー 脆弱性対応をする際に、一般的には以下のような 対応フローが存在します。 1. 脆弱性情報の収集 ➢ 脆弱性が発見されたことを認知 2. 脆弱性の調査 ➢ どのような脆弱性かを調査 3. 管理対象への影響評価と決定 ➢ 管理対象への影響と適用要否の決定 4. 実対応 ➢ 実サーバに適用をし、適用管理する 情報収集 脆弱性 の調査 対象への影響調査 /適用可否 更新と 更新管理

1.脆弱性情報の収集 様々なソースで脆弱性情報が公開されている • メーリングリスト、github、チケット管理システム、など どの段階の情報を収集するか • 発見者の申請（信頼性は？影響度は正しい？） • CVE-ID採番（Status:Received, Awaiting Analyss） • CNAによる内容確認後（Status:Analyzed） • ベンダーによる対策プログラム公開時 どのように収集するか • 収集：RSSリーダ、google alert、SNS(Twitter)、等 • 通知：Slack、メール、RSSリーダ等 • 受領：いつ受け取りたいか（24/365, 営業時間、etc） CVEのステータス https://nvd.nist.gov/vuln • Received • Awaiting Analysis • Undergoing Analysis <- ほぼ見ない？ • Analyzed • Modified • Deferred • Rejected おすすめは、 • Slack通知 • 種類により分類(Channnelわけ)可能 • Slack RSS を利用する • Google AlertでRSS生成 • NVDのRSS登録 ふつうは、NVDのanalyzedとディストリ ビュータのErrata見ておけばよいかもしれ ない。

2.脆弱性の調査 どの段階で情報を手にしているかで変わります。 • CVE-ID採番前 • 開発者コミュニティの動きを確認する、自分でソースを呼んで推測する、くらい？ • そもそも情報がないので、自分で検証していく • Securty Mailing List Archive https://seclists.org とか • CVE-ID採番後 • 基本的には Status:Analyzed になれば、CVSS等が公開される • CVD-IDをキーにググレカスする • PoCが公開されている https://www.exploit-db.com/ , Pastebin , github , etc… • 誰かがSNSで検証結果を… • ベンダによる修正プログラム公開後 • ベンダのerrata情報を見るのが一番正しい。 • Amazon Linux Security Center: https://alas.aws.amazon.com/ • Ubuntu Security noitces: https://usn.ubuntu.com/ どれが確定した情報なのか、を気にする必要がある。

ディストリビュータとOSSの違い まれに頻繁に、OpenSSLの脆弱性が公開されたが、ディストリ ビュータのパッケージでは影響がないとされている、ことがあります。 • ディストリビュータのパッケージは、バックポート（コミュニティ の最新バージョンに含まれるバグ修正を、製品に含まれるかこの バージョンに適用）していることが多いです。 • その為、公開された（コミュニティの版）の脆弱性は 利用してい るディストリビューションに影響があるのか、を確認する必要があ ります。 詳しくは、RHのMoriwakaさんが作った資料を参照 • Red Hat Enterprise Linuxの修正はどのように出荷されるのか • https://speakerdeck.com/moriwaka/red-hat-enterprise-linuxfalsexiu-zheng- hadofalseyounichu-he-sareruka

3.管理対象への影響評価と決定 • 自組織の特性を事前に把握しておくことが重要 • 事前の対応フロー用意 • 保有している情報資産の棚卸を事前に済ませておく • 搾取される情報が無いサーバであれば、機密性への影響は評価を下げてもよい • 可用性が求められていない利用形態であれば、可用性の評価は下げてもよい • など、システムの特性に合わせてCVSSの環境値相当を柔軟に考える • CSIRTのような組織ができているのであれば、環境値は事前に設定したい • システマチックに「CVSS Base Score再計算」して「直近の優先順位付け」をし た方がよい。俗人的なものが入り込まず安定した判断が可能かも。 • 逆に、独り情シスの場合は、再計算する余裕が無ければ環境値相当をおおよそ重 視して判断するのがよさそう。

4.実対応 • 検討 • パッケージと野良ビルド • 影響範囲 • 確認方法

ハンズオン

対応してみよう 脆弱性情報が公開されたところから、対応してみましょう。 • 「 CVE-2018-5740 」が公開された想定とします • 対応すべきホストは社内のDNSサーバ、と仮定します。 • 脆弱性を認知したのは、公表日以降 以下を実施してみましょう • 情報収集 • トリアージ • 対処の検討

情報収集 以下の情報を取得してみましょう • NVD • CVSS Score • CVSS Vector • ベンダ(Red Hat)の情報 • CVSS Score • CVSS Vector • ベンダのバグトラッカーの情報 • Bugzilla • 原因 • 影響 • 対策、軽減措置

情報収集 以下の情報を取得してみましょう • NVD • http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5740 • RESERVED • ベンダ(Red Hat)の情報 • https://access.redhat.com/security/cve/cve-2018-5740 • ベンダのバグトラッカーの情報 • https://bugzilla.redhat.com/show_bug.cgi?id=1613595 • JPCERT/CC • https://www.jpcert.or.jp/at/2018/at180031.html • 原因、影響、対策、軽減措置 • 上記情報源から得られる。情報元の確度 信頼度は高い。 • 影響範囲等から、適用タイミング等が判断できる。

適用計画 適用する場合の計画を立ててみよう • 適用の緊急性 • 適用の必要性 • 適用時期 • 想定される作業と作業時間（1台）

以上です。 • 資料の公判は手抜きではなくて、力尽きただけです… • 口頭できちんと説明しました。次回はこれを土台に後半部分の文字を作っていって、 徐々に参考資料にします。 • ご参加いただいた方、ありがとうございました。