Upgrade to Pro — share decks privately, control downloads, hide ads and more …

第0回 脆弱性対応勉強会 資料

hogehuga
December 08, 2018

第0回 脆弱性対応勉強会 資料

脆弱性対応について、再確認する資料。

hogehuga

December 08, 2018
Tweet

More Decks by hogehuga

Other Decks in Technology

Transcript

  1. An overview of this section ここでは、脆弱性対応に関する知識の再 確認をしようと思います。 • 利用しているスキームの再確認 •

    CVE, CVSS, CVSS[ Score | Vector | Environment ] • 脆弱性発見後の、通常の報告経路 • どのようなフローで対応するのか • フローごとの検討事項 • 情報収集、脆弱性認知 • 脆弱性の詳細確認 • 自組織への適用判定 • 適用と、適用情報の管理
  2. 利用しているスキームの再確認 CVSS ScoreやCVE-IDなどを利用していますが、これはどういうものなのでしょうか。 • SCAP(Security Content Automation Protocol:セキュリティ設定共通化手順)の中で定 義されています。 •

    2002年に連邦情報セキュリティマネジメン法(FISMA)が施行 • 政府省庁ではFISMAに対応するため、他の様々な法律や連邦政府情報処理規格等の 要求事項に対応する必要が発生 • とても人力では無理 • 情報セキュリティ対策の自動化と標準化を目指し、SCAPを開発 FISMA (2002年) の施行 各種のセキュリ ティ要求事項に 対応が必要 自動化や効率化 が求められる 自動化と標準化 を目指したSCAP が開発
  3. 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 頻繁に使う 頻繁に使う 頻繁に使う
  4. 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
  5. 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
  6. CVSS Temporal/Environmental Metrics IPAの資料が詳しい。 • https://www.ipa.go.jp/security/vuln/CVSSv3.html • Temporalは、時間が経過すると変化する特性を加味している • Exploit

    code(攻撃コード)が出回っているか、情報元の信頼性など。 • Environmental Metricsは、ユーザの利用環境等により変化する ものを加味している • 対象システムのセキュリティ要求度(停止しても構わない、漏洩しても問題ない情 報しかない、等)など。 BaseScoreを状況に応じて下げる=緊急度を下げる、妥当な判断 情報、として扱えます。
  7. CVSSの何を重視すればいいのか おおよそ以下を重要視するのが良い、と考えています。 • 攻撃元区分 • ネットワークの攻撃は、単独で攻撃される可能性 • ローカルの攻撃は、内部不正 もしくは ネットワーク攻撃成功後に利用される可能性。

    • CIA(機密性/完全性/可用性) • 情報の漏洩、情報改ざん、業務停止 の影響 • 攻撃される可能性 • 攻撃コードが既に存在しているか 他の評価値も重要ですが、まず最初に見るのはこれでよいはず。
  8. 脆弱性の発見と登録 脆弱性の発見と修正は、以下のプロセスで行われます • 脆弱性を発見する • 研究者等により発見される • 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 発見 採番 登録 調整 公開 配布
  9. 脆弱性対応のフロー 脆弱性対応をする際に、一般的には以下のような 対応フローが存在します。 1. 脆弱性情報の収集 ➢ 脆弱性が発見されたことを認知 2. 脆弱性の調査 ➢

    どのような脆弱性かを調査 3. 管理対象への影響評価と決定 ➢ 管理対象への影響と適用要否の決定 4. 実対応 ➢ 実サーバに適用をし、適用管理する 情報収集 脆弱性 の調査 対象への影響調査 /適用可否 更新と 更新管理
  10. 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見ておけばよいかもしれ ない。
  11. 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/ どれが確定した情報なのか、を気にする必要がある。
  12. 3.管理対象への影響評価と決定 • 自組織の特性を事前に把握しておくことが重要 • 事前の対応フロー用意 • 保有している情報資産の棚卸を事前に済ませておく • 搾取される情報が無いサーバであれば、機密性への影響は評価を下げてもよい •

    可用性が求められていない利用形態であれば、可用性の評価は下げてもよい • など、システムの特性に合わせてCVSSの環境値相当を柔軟に考える • CSIRTのような組織ができているのであれば、環境値は事前に設定したい • システマチックに「CVSS Base Score再計算」して「直近の優先順位付け」をし た方がよい。俗人的なものが入り込まず安定した判断が可能かも。 • 逆に、独り情シスの場合は、再計算する余裕が無ければ環境値相当をおおよそ重 視して判断するのがよさそう。
  13. 情報収集 以下の情報を取得してみましょう • NVD • CVSS Score • CVSS Vector

    • ベンダ(Red Hat)の情報 • CVSS Score • CVSS Vector • ベンダのバグトラッカーの情報 • Bugzilla • 原因 • 影響 • 対策、軽減措置
  14. 情報収集 以下の情報を取得してみましょう • 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 • 原因、影響、対策、軽減措置 • 上記情報源から得られる。情報元の確度 信頼度は高い。 • 影響範囲等から、適用タイミング等が判断できる。