Techカテゴリ

脆弱性管理と組織組成: X.1060で考える、脆弱性管理の機能

概要

2024-02-03に塩尻市で行われた「【第10回】サイバーセキュリティ勉強会2024冬in塩尻」で私（井上）が話した、「脆弱性管理と組織組成」について概要を示します。

  • https://shiojiri-cyber.connpass.com/event/302612/
    • イベント名が進化しています
      • -2019/11 塩尻セキュリティウィークエンド(SSWE)
      • 2021/02- サイバーセキュリティ勉強会YYYY in塩尻
      • 2023/08- サイバーセキュリティ勉強会YYYY(夏|冬) in塩尻
        • 年間2会開催(予定)のため
    • 明示はしていませんが、学生向けという側面もあります

私の発表部分である「脆弱性管理と組織構成」について、このblogで概要紹介をします。
概要

脆弱性管理とリスク

脆弱性管理について、少々掘り下げました。

リスク

リスク

そもそも私たちは何に対応するために脆弱性管理をしているのでしょうか。

事業に対するリスクを低減するために、脆弱性管理をしているはずです。アップデートをしたり修正をしたりするために脆弱性管理をしているのではなく、放置することで事業に影響のある脆弱性に対応するために対応しているはずです。そうであれば、事業影響（=リスク）が許容できるものに関しては対応しないという選択もありますし、脆弱性それ自体が危険でも事業リスクとしては低めであれば対応は緊急にする必要はない、などの判断ができるはずです。所謂、リスクベースのアプローチです。

それでは「リスク」とは何でしょうか。

一般的には、 脅威×脆弱性×資産価値 と言えます。

分類 概要 利用できる情報源
脅威 脆弱性が悪用される可能性などが、本コンテキストでは想定されます EPSS, KEV Catalog
脆弱性 脆弱性それ自体の危険性 CVSS, KEV Catalog
資産価値 Value Densityやシステムの持つ価値などが、本コンテキストでは想定されます 組織自分自身で決定する必要がある

上記のように、各分類に対する提供される情報源が異なります。

  • KEV Catalogは、影響力のある脆弱性（=危険な脆弱性）が、既に悪用されている（悪用可能性が高く、脅威である）ことを示しています。
  • EPSSは、今後30日に関する悪用可能性のみを示し、脅威自体は示さない（CVSS等で補完する必要がある）。また、対象の価値については検討範囲に入っていない。
  • CVSSは、脆弱性それ自体の悪用可能性を示し、悪用確率や資産価値までは考慮されていない。一応、Temporal Score（現状値）やEnvironmental Score（環境地）で補正できる仕組みはあるが、各スコアに該当る情報は提供されていない。

データ提供元に注意が必要です。脅威情報や脆弱性情報は第三者から提供されますが、資産価値（=システムの価値）は運用組織自身で決定する必要があります。どのようなデータを保有しているか、侵害された場合の事業への影響はどの程度か、機密性完全性可用性はどの程度求められているのか、などは第三者で決定できる内容ではありません。これについては以前のBlog「 OWASP Risk Rating Methodologyについて 」を参照するとよいかもしれません。
誰がデータ提供主体になるか、組織として自分で用意しなければならない情報は何か、あたりは意識しておく必要があります。

そして、 CVSS v3.1 BaseScore 8.0以上を対応する というポリシーの場合は、脆弱性それ自体しか見ておらず、脅威（攻撃される可能性）や対象の資産価値を考慮していないため、大量の脆弱性に対応することになる場合が多いです。また、EPSSのみを使う場合は、悪用される確率が高いものを無くすことで「攻撃を受ける確率」は減らせますが、低い確率で利用される攻撃で危険な脆弱性を利用されるというリスクは残ります。そのため、バランスを取って各情報を見る必要があります。

脆弱性管理

事業リスクという観点で見ると、すべての脆弱性に対応する必要はなく、事業影響へのリスクを許容できるものは対応しないという判断も可能です。存在する脆弱性を認知し、対応が必要なものや許容できるものを判別し、必要な部分に対応する、ということが必要です。そのため、脆弱性対応というよりは「脆弱性管理」といったほうが適切な場合が多いと考えます。

また、「事業リスク」という観点で決定するためには、CISOなどの組織の意思決定者を巻き込む必要があります。残念ながら、情シス/SOC/CSIRT の単独で決めていくのは難しいかもしれません。

  • 「バランスを取る必要がある」「取らないとどうなる？」「知らんのか　大量の脆弱性を”今すぐ”対応しろと言われる」

一般的な運用

脆弱性管理フロー

毎回提示しているような気がしますが、一般的に使う脆弱性管理のフローを示しています。主に4つのフェーズを回していくイメージです。
実際は、判断と対応は一体となって検討することも多いですが、概念として分けています。

  • 情報収集
    • 利用しているシステムに脆弱性があるかを認知するためのフェーズ
    • どのようなソフトウェアを利用しているかの一覧を基に、脆弱性情報を収集する
  • 判断
    • システムに脆弱性があることを認知した後で、どのように対応するかの決定をするフェーズ
      • 脆弱性それ自体ではなく事業リスクとしてとらえ、リスクを許容して対応しない、などのトリアージを実施する
  • 対応
    • アップデートや回避設定などを行うフェーズ
    • 通常は、判断時に対応も含めて検討するが、概念として分けている
  • 記録
    • 対応の記録を残すフェーズ
    • 設定変更で対応した場合はあとからバージョンだけを見ると脆弱性が放置されているように見えるので、記録を残す必要がある
    • 一般的にはチケット管理システムなどを利用しているため、日時や対応者や対応方法などが記録として残される

脆弱性情報収集では対象により検出/診断手法が異なるので、適切に検査をする必要があります。また、情報入手速度も企業の体力に合わせて検討する必要があります。
また、トリアージについては判断基準を明確化し納得できるものとしておくことで、判断にかかる負荷を減らすことができます。「納得のできるもの」というのが肝であり、「CVSS BaseScore8.0以上」のような場合は「8.0以上だけど影響がないかもしれない」「7.9などの8.0以下にすれば対応しなくてすむかもしれない」のようなことを考えずに済むように定義できるとよいです。

脆弱性管理の、X.1060での位置づけ

位置づけ

前項までの脆弱性管理は、企業のセキュリティ対応組織（CDC: Cyber Defence Centre）のの中では一部でしかありません。企業のセキュリティ対応部門としては、例えば以下のようなものも対応が必要です。

  • 従業員へのセキュリティ教育、セキュリティポリシーの決定、リアルタイムログ検知、フォレンジック、内部不正対応、インシデント対応、アセット管理、システムの選定や運用、等

今回は、CDCで求められている機能は脆弱性対応とどこで関係があるのかを考えようと思います。

※わかりやすさを優先して「機能」といっていますが、X.1060上では「サービス」と呼びます。各必要な機能をサービスリストとして提供し、その中から自組織で必要なサービスを選択/実装する使い方になります。
※X.1060上では、「機能」は「セキュリティ機能」として、サービスを実装したものとして定義しているようです（JT-X1060v1.1.pdf 図1 CDCの運営における関係者とその役割）。例えば、リアルタイム監視の「サービス」を実装を、xDRなどの「セキュリティ機能」として実装する、のような位置づけです。（たぶんそのはずです…）

X.1060での位置
分類と影響

X.1060での脆弱性管理の位置づけは、実際のアクションから考えると「E.診断と評価」内の「E-4.パッチ管理」付近になると考えます。

脆弱性管理がうまくできない理由の一つに、脆弱性管理に必要なサービスが存在していない（組織として脆弱性対応をするために必要な機能が不足している）という場合があります。例えばトリアージポリシーの決定であったり、ログ等の分析サービスだったりします。不足している/要求より弱い機能しか実装されていない場合は、それを強化することで後段になる脆弱性管理がうまく回ることも多いです。そのため、脆弱性管理のアクションである「パッチ適用」の部分から関連する必要なサービスを検討してみます。

直接影響のある機能
間接的に影響のある機能

組織や見る観点により異なるとは思いますが、今回は脆弱性管理に直接的に影響のあるサービスはおおよそ以下として見てみます。

  • F.脅威情報の収集及び分析と評価
    • 内部/外部の脅威情報の収集・分析・評価、辺りが関連すると思われます
      • WEBサービスなので外部からの脅威を優先的に対応したいのであれば、 F-3外部脅威情報の収集・計画 にリソースを多めにとるという判断もできます。
      • いま、このサービスはどのように実装しているか、などを検討するとよさそうです。
        • 例えば「空き時間にネットニュースで見ている」「専任のリサーチャーが調査している」などがあり、それが脆弱性対応で要求される速度間や制度に合致するかを検討するとよいと思われます。
  • E.診断と評価
    • こちらは全体的に、脆弱性診断や資産情報整理が適切に行われているか、が指標になりそうです。
  • G.CDCプラットフォームの開発・保守
    • 利用するセキュリティ製品の選定や運用などが該当すると思われます。
    • SaaSサービスを使うことで保守運用コストを外に出したり、より高度な運用や対応を期待することができます。

間接的な観点だと以下が影響するとも言えます。

  • A.CDCの戦略マネジメント
    • やはり、ポリシーの策定と管理は重要です。そしてCISOとコミットすることで効果があります。ポリシーはCDCの戦略の一環なので現場からは声を上げずらいかもしれませんが、必要に応じてCISOと協議していく必要はあります。
      • そもそも、日本ではCISOの役割の人が少ない、という話もありますが…
  • B.即時分析
    • リアルタイム監視などは、自システムへの脅威がすでにあるのかを確認することができます。どの程度の応答速度が必要とされるのか、などで組織組成を検討する必要があるかもしれません。
  • C.深堀分析
    • 自組織でどこまでやるか次第で、アウトソースを検討します。
    • アウトソースをする場合でも、データがなければ何もできないので、どこまでは自社でやるのかという最低限のラインを決めておく必要があります。
  • I.外部組織との積極的連携
    • JPCERT/CCやIPAなどの組織と連携しておくとよいかもしれません。中小企業であれば、インシデント発生時にIPAのお助け隊に協力要請するのもありかもしれません。

全体として、必要なサービスが必要なタイミングで利用できるか、などの備えに対するチェックに使えればよいかもしれません。

  • 不足しているサービス部分に人員を割く、手順等備えが漏れていないか確認する、など。

まとめ

まとめ

脆弱性管理をするときに、脆弱性だけと向き合うのではなく組織のセキュリティ対応全体での位置づけや整合性を考えることで、今までより楽に脆弱性管理ができるようになるかもしれないという意図で現地では講演しました。
組織のサイバーセキュリティにおいての位置づけを再確認しておくことで、過剰なパッチ適用の負荷も再考できるかもしれません。

事業リスク対応という観点からは、KEV Catalogを優先して対応するのは比較的筋の良い対応だと考えられます。中小企業などは基本的にセキュリティ対応にコストがかけられないため、CVSSやEPSSや脅威情報を収集/分析する時間がないことが多いです。それであればはじめの一歩としてKEV Catalogをターゲットとし、組織環境を順次整えつつCVSSや脆弱性情報を組み合わせた対応に移行していくのが現実的と思われます。または、脆弱性の判定を自動化するサービスを導入し、コスト見合いですが外部の力を借りるほうが良いコアもしれません。例えば、本サービス「 FutureVuls 」などが該当します(PR)。

また、学生の方は比較的B2Bや組織としての脆弱性対応をご存じないことが多いので、それがイメージできるような話を現地ではしたはずです。

デジタル庁DS-201

これらの脆弱性管理の全体感を考えていた時に、デジタル庁の「デジタル社会推進標準ガイドライン」が非常に有用だということを確認しました。
例えば DS-201 政府システムに於けるセキュリティリスク分析ガイドライン などは非常に有用と思われますので、一読したほうが良いと感じています。

脆弱性管理は、脆弱性それ自体に注目しがちですが、リスクや組織のセキュリティ対応全体像をイメージすることで、もう少し対応のしやすい環境が作れるかもしれません。そのための道具として、X.1060やデジタル庁のガイドラインを使っていただければと思います。

参照情報

お決まりの、宣伝

このような記事を継続して書くためには、記事があることでFuturVulsトップページへの流入や問い合わせがが増える、という( 私の )内部評価爆上げが必要です。

もしよろしければ FutureVulsのトップページ https://vuls.biz/ も訪問いただけると助かります。

  • https://vuls.biz/
    • 必要ならお問い合わせください。その際は本記事を見た等の記載を頂ければ幸いです。

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

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

以上