Techカテゴリ

脆弱性対応の戦略とフレームワーク(NCA Annual Conference CFPの概要)

こんにちは、井上です。
先日のNCA Annual Conference 2023に於いて、CFPに「サイバーセキュリティの新たな世界; CVSSv4,SBOM,EPSSの活用と今後の展開」として応募し、選択されて発表を行いました。
直近1年程度で、どのように脆弱性管理を進めていくかのような話をしましたので、こちらの概説を行います。

本情報について、TLP:GREEN として公開します。

  • https://www.first.org/global/sigs/tlp/
  • TLPは「機密となりうる情報の広範囲な共有と、より効果的な連携の促進を目的に作られた」ものです。
  • 4つの指標により公開範囲を制限します。
    • 今回は「TLP:GREEN」を選択したので、 情報の受信者はコミュニティ内に情報を共有できる としてください。
    • 但し、この記事の共有とし、個別の画像等のみでの使用は行わないでください。

要は、画像だけ抜き出して独り歩きさせないでください(コントロール不能になるため)、というだけです。

※本Blogの内容は会社の見解ではなく、筆者の個人的な見解です。また、認識違いなどがある可能性があるため、参考情報としてください。

全体の構成

2023年には、脆弱性対応で使える指標が何点か「そろそろ使える」状況になりました。

  • X.1060という、組織全体のセキュリティ対策のフレームワークの台頭
  • CVSS v4の公開
  • EPSSの活用についての話題
  • SBOMの活性化

その他にもありますが、講演時間の都合上 上記のものについてのみお話しました。

概要
状況説明

各フレームワークの紹介

各フレームワークについて、どのような意図があり/どのように使えるのか、を概略的に説明しました。

X.1060

X.1060は、ISOG-J WG6の成果物「セキュリティ対応組織の教科書 第二版」を基にITU-Tに提案し、採択されたものです。

脆弱性対応に直接使えるものではありませんが、組織のセキュリティ対応をどのようにするかの設計の基礎に使えるフレームワークです。
組織のセキュリティ対策について、どのようなサービスを選び、実装方法を決める指標となります。性質上、個別のサービスについてどのように実施すべきかという点は書かれていません。

  • 加盟国で合意を得る必要があり、国毎の内情により実装ポリシーは異なるためです。各国で共通して合意できる部分として書かれています。

x.1060概要

例えば、サービスリストや図などを注意深く検討することで、脆弱性対応に必要な関連機能が明確になり、現状の問題点の改善に役立ちます。

  • 下図、図1 CDCの運営における関係者とその役割のように、対応実施者(セキュリティチーム)と 所謂SOC/CSIRT(CDC)と CISOの立ち位置を再確認することで、セキュリティポリシー策定等の決定権や強制力について検討が可能です。
  • 同様に 図8 CDCサービスカテゴリー においては、やろうとしていること(赤枠)に対して、必要な周辺機能(緑枠)があり、その前提としての機能(青枠)がある、というような依存関係が見えてきます。現状の弱い部分は、実は前提機能の不足によるものである、等が分かる場合があります。

CDC運営における関係者とその役割
CDCサービスカテゴリ

尚、”どのように組織の立て付けを行うか”等の日本向けに情報を足されたものが、ISOG-J WG6で提供している「セキュリティ対応組織の教科書 第3版」以降となります。(最新は3.1版です)

X.1060(及び セキュリティ対応組織の教科書)で、脆弱性対応の周辺の備えができているかを確認していくとよいと思います。

CVSS v4

CVSS v4は、今の時点(2024-01-12)でもNVDで利用されていないので、これからどう使えそうかという観点の話をしました。

全体として以下のような点を今後考えていく必要がありそうです。

  • 基本評価基準の “セキュリティのCIA” が、脆弱なシステムそれ自体と後続のシステムに分けられた
    • 例えば、WEB/DBのような場合、WEBが侵害された後でDBにも影響があるか、という観点という理解ができます
    • CVSS v4 Calculatorを見てみると、後段のシステムへの影響を重視しているように見えます
  • Supplemental Metric Groupが追加された
    • 悪用の自動化可能性やシステムの回復力、価値密度(1回の悪用で制御できるリソースの量)などが提供されます
    • しかしながら、これは各自の環境に依存する部分もあり、どの程度サプライヤから提供されるか現時点では不明だと思われます
  • 情報提供者は誰か、に注意が必要
    • 脆弱性それ自体の評価であるBase Metricsと、補足情報となるSupplemental Metric Groupは、サプライヤから提供されます
    • しかしながら、脅威の指標であるThreat Metric Groupと利用者しか知り得ないシステムの環境であるEnvironmental Metric Groupは、利用者自身で提供する必要があります
      • 攻撃される可能性であるThreat Metirc Groupは、通常自社で算出/観測することは難しい為、他の何らかの指標を利用する事になると思います
      • システムの環境であるEnvrionmental Metric Groupは、これはユーザ自身で決定する必要があります
  • Threat Metric Groupは、利用者が用意する必要がある
    • 脅威評価基準となるThreat Metirc Groupは、自分で「攻撃される可能性」の情報を入れ込む必要がある
    • CVSS v4での表現(Exploit Maturity)だと、Attacked/POC/Unreported が値としてとれます
      • KEV Catalog (今回は説明時間が無く、省略)は、登録されればAttacked扱いで使えると思います
      • 後述のEPSSは、何らかの基準値を設ければ Attacked/POC/Unreported に分類は可能と思われますが、無理にCVSS v4のスコアに組込む必要はないかもしれません
        • CVSS v4 BaseScore算出後に、EPSS Scoreで優先順位を付ける(トリアージ)という方法も考えられます

CVSSv4概要
CVSSv4の構成

今後はCVSS v4で情報が提供されると思われるので、今のうちから以下を検討しておいた方が良いと思われます。

  • システム間の 接続/関連 を確認しておく
    • 脆弱性のあるシステムとその後段のシステム、という見方を受け入れられるようにしておく
    • それにより、どこをより強固に守るべきかを明確にしておく
      • WEBサーバが侵害されても、DBへ影響が無ければ、事業的にはリスクは少ない、等
  • 攻撃される可能性について、どのように考えるのかを検討しておく
    • 現時点では EPSSやKEV Catalog 等があるが、どのように使うのか
    • この指標を使いこなせない場合は、無理に使わなくてもよいと思われる
  • Supplemental Metric Groupの扱いについて考えておく
    • 例えば、回復性は復旧作業時に影響する。攻撃を遮断すれば元に戻るとする場合、インシデントレスポンス時の負荷は多少なりとも低くなると考えられる、など
    • この指標も、無理に使う事はないと考える

EPSS

EPSSは、FIRSTがメンテナンスをしている、CVE-ID毎に今後30日以内に脆弱性が悪用される確率を示したものです。
確率論で示される為、数値N以上ならどうする、のような使い方は難しいと考えます。

  • 現状の運用に適用しやすい方法は、「CVSS BaseScoreで分類した後に、分類内での優先度付けに使う」のが、まずは良いかと思われます
    • 環境情報などを含めて 即時対応/定期メンテナンス前に実施/定期メンテナンスで実施/リスク受容 等に分け、例えば”即時対応”の中でEPSSにより優先度をつける等を想定しています
  • EPSS自体は様々な情報源からの学習で算出されているため、他の指標と連動していることが多いです
    • 例えばKEV Catalogに登録された後で確率が上がる、ようなことがあります


なお、「とりあえず、過去のEPSS値も含めたDB欲しい」に関しては、個人的にepss-dbというものを作りました。適当にSQLで調べる用途です。

  • https://github.com/hogehuga/epss-db/
    • 弊社とは無関係です。Dockerを推奨します。SQLite3版は…1日毎のデータを入れるのに2時間くらいかかることがあります。
      • 40-50GBの単一SQLite3ファイルへのアクセスなので…
    • 基本的に運用者であればそれほど長期のデータは要らないので、EPSSについて研究したい人向けではあります
      • その為、ElasticStackではなくmysql/SQLite3を使っています

現時点では、追加指標として、他の指標で優先度グループ付けした後の利用が良いように思えます。

SBOM

最近はセキュリティ製品ベンダーからSBOMについて広報が多いですが、自組織への適用はSBOMツール導入だけでは意味がない点に注意が必要です。
; それを言うと、弊社製品もSBOM機能を売りにするので、商売上はあまりよくないのですが…

  • サプライチェーン セキュリティ対策の「銀の弾丸」ではない、事に留意する必要があります

    • SBOMとして手元に残るソフトウェアリストを「どのように利用するか」が重要です。「SBOMを取得する事」それ自体を目的にしない事が重要です。
      • どの範囲までを対象にするのか。特定部門、自社全てのシステム、サプライチェーン上前後1Tir程度、サプライチェーン全て、等。
        • 例えば、下請けにSBOMを強制する場合、法的拘束力はあるのか/商取引情報的に問題は無いのか/費用はどこが負担するのか、等の考慮が必要です
        • 例えば、「ルータのSBOM」は必要ですか？それはルータを作ったベンダの責任範囲で、自社でSBOM管理する必要があると言えますか？

  • どのように使うか、を設計してから製品導入でもよいと考えます

    • SBOMを使った活動のライフサイクルを設計する必要があります
      • SBOMは「出力した時点のソフトウェア一覧」と言えるので、更新が必要です
        • 構成変更時、ソフトウェアアップデート時、ファームウェア更新時、等適当なタイミングで更新する必要があります。
      • 集めたSBOMをどのように使うかを設計する必要があります
        • 定期的に「脆弱性が残っているバージョンを使っていないかを確認する」「ライセンスが適切かを確認する」などの、”SBOMを使ったアクション”を設計します
        • 例えば脆弱性判断の場合、どのように判別するか、自動的にできるか、等を実証しておく必要があります

  • SBOM自体は今後必要になっていくと思われます

    • 米国がSBOMを推し進めているのは、国としてサイバーセキュリティを推し進めているからです

    • 現時点で、例えば総務省や経済産業省で「日本としてはどう進める(進めるべきな)のか」は出ていないと考えます。その為、国としての推進力は低く、おそらく外圧により適用せざるを得ないという状況になると考えられます。

      • 外圧: 米国との取引上必須になる、等
      • とはいえ、一応は医療機器のJIS規格や自動車関連では、SBOMは必須とされてはいるのでその分野から進むとは思われます
      • そのような縛りの無いWEB系IT業界だと、導入するモチベーションは低いかもしれません
        • 例えば、決済関係のシステム以外は、セキュリティ対策として有用なPCI-DSSやCIS Benchmarkなどの指標の適用はあまり進んでいない

    • 今後外的要因で必要になると思われるので、準備だけは進めておいた方が良いと考えます

      • 適用範囲、どのように使うか、関係するステークホルダーは協力できるのか、等です

      • 実証事件をしたが 何が取得できるかを確認した、とりあえずSBOMを出す方法を提示した、どまりと考えます

今すぐにSBOMに対応しないといけない、というわけではないですが、今から制度設計等の準備はしておく必要はあると考えます。

まとめ

脆弱性対応が回らない主な原因は「対応すべき脆弱性が多すぎる」「対応工数が高すぎる」という点だと思われます。
将来的にはシフトレフトにより「脆弱性対応がやりやすいシステム設計/構成」にしていくことが重要ですが、目の前の対応として「フレームワーク等を用いて負荷の少ない運用にしていく」ことはになると思います。これは並行して進める必要がありますし、設計段階で運用を考慮しておく=システム設計や構築の初期の段階から運用メンバが関わっていく、必要があるという事になります。

まずは現実問題として現行の運用負荷を下げる必要があると思うので、今回ご紹介した指標やフレームワーク、またそれ以外も用いて楽に運用できるようにしたいですね。

様々な指標やフレームワークがありますが、複雑化させずにシンプルに/楽に対応ができるようにしたいですね。

参照先情報

お決まりの、宣伝

このような記事を継続して書くためには、記事があることでFuturVulsトップページへの流入が増える、という(私の)内部評価爆上げが必要です。
もしよろしければ FutureVulsのトップページ https://vuls.biz/ も訪問いただけると助かります。

また、セキュリティコンサル/脆弱性対応コンサルも行っております。ある程度は無償でご相談をお受けすることはできると思いますので、本件ご興味があれば私のメールまでご連絡ください。

  • k。inoue。xz@future。co。jp
    • 。を.に変換ください。

よろしくお願いいたします。

以上