2024-02-03に塩尻市で行われた「【第10回】サイバーセキュリティ勉強会2024冬in塩尻」で私（井上）が話した、「脆弱性管理と組織組成」について概要を示します。
私の発表部分である「脆弱性管理と組織構成」について、このblogで概要紹介をします。
脆弱性管理について、少々掘り下げました。
そもそも私たちは何に対応するために脆弱性管理をしているのでしょうか。
事業に対するリスクを低減するために、脆弱性管理をしているはずです。アップデートをしたり修正をしたりするために脆弱性管理をしているのではなく、放置することで事業に影響のある脆弱性に対応するために対応しているはずです。そうであれば、事業影響（=リスク）が許容できるものに関しては対応しないという選択もありますし、脆弱性それ自体が危険でも事業リスクとしては低めであれば対応は緊急にする必要はない、などの判断ができるはずです。所謂、リスクベースのアプローチです。
それでは「リスク」とは何でしょうか。
一般的には、 脅威×脆弱性×資産価値 と言えます。
| 分類 | 概要 | 利用できる情報源 |
|---|---|---|
| 脅威 | 脆弱性が悪用される可能性などが、本コンテキストでは想定されます | EPSS, KEV Catalog |
| 脆弱性 | 脆弱性それ自体の危険性 | CVSS, KEV Catalog |
| 資産価値 | Value Densityやシステムの持つ価値などが、本コンテキストでは想定されます | 組織自分自身で決定する必要がある |
上記のように、各分類に対する提供される情報源が異なります。
データ提供元に注意が必要です。脅威情報や脆弱性情報は第三者から提供されますが、資産価値（=システムの価値）は運用組織自身で決定する必要があります。どのようなデータを保有しているか、侵害された場合の事業への影響はどの程度か、機密性完全性可用性はどの程度求められているのか、などは第三者で決定できる内容ではありません。これについては以前の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以下にすれば対応しなくてすむかもしれない」のようなことを考えずに済むように定義できるとよいです。
前項までの脆弱性管理は、企業のセキュリティ対応組織（CDC: Cyber Defence Centre）のの中では一部でしかありません。企業のセキュリティ対応部門としては、例えば以下のようなものも対応が必要です。
今回は、CDCで求められている機能は脆弱性対応とどこで関係があるのかを考えようと思います。
※わかりやすさを優先して「機能」といっていますが、X.1060上では「サービス」と呼びます。各必要な機能をサービスリストとして提供し、その中から自組織で必要なサービスを選択/実装する使い方になります。
※X.1060上では、「機能」は「セキュリティ機能」として、サービスを実装したものとして定義しているようです（JT-X1060v1.1.pdf 図1 CDCの運営における関係者とその役割）。例えば、リアルタイム監視の「サービス」を実装を、xDRなどの「セキュリティ機能」として実装する、のような位置づけです。（たぶんそのはずです…）
X.1060での脆弱性管理の位置づけは、実際のアクションから考えると「E.診断と評価」内の「E-4.パッチ管理」付近になると考えます。
脆弱性管理がうまくできない理由の一つに、脆弱性管理に必要なサービスが存在していない（組織として脆弱性対応をするために必要な機能が不足している）という場合があります。例えばトリアージポリシーの決定であったり、ログ等の分析サービスだったりします。不足している/要求より弱い機能しか実装されていない場合は、それを強化することで後段になる脆弱性管理がうまく回ることも多いです。そのため、脆弱性管理のアクションである「パッチ適用」の部分から関連する必要なサービスを検討してみます。
組織や見る観点により異なるとは思いますが、今回は脆弱性管理に直接的に影響のあるサービスはおおよそ以下として見てみます。
F-3外部脅威情報の収集・計画 にリソースを多めにとるという判断もできます。間接的な観点だと以下が影響するとも言えます。
全体として、必要なサービスが必要なタイミングで利用できるか、などの備えに対するチェックに使えればよいかもしれません。
脆弱性管理をするときに、脆弱性だけと向き合うのではなく組織のセキュリティ対応全体での位置づけや整合性を考えることで、今までより楽に脆弱性管理ができるようになるかもしれないという意図で現地では講演しました。
組織のサイバーセキュリティにおいての位置づけを再確認しておくことで、過剰なパッチ適用の負荷も再考できるかもしれません。
事業リスク対応という観点からは、KEV Catalogを優先して対応するのは比較的筋の良い対応だと考えられます。中小企業などは基本的にセキュリティ対応にコストがかけられないため、CVSSやEPSSや脅威情報を収集/分析する時間がないことが多いです。それであればはじめの一歩としてKEV Catalogをターゲットとし、組織環境を順次整えつつCVSSや脆弱性情報を組み合わせた対応に移行していくのが現実的と思われます。または、脆弱性の判定を自動化するサービスを導入し、コスト見合いですが外部の力を借りるほうが良いコアもしれません。例えば、本サービス「 FutureVuls 」などが該当します(PR)。
また、学生の方は比較的B2Bや組織としての脆弱性対応をご存じないことが多いので、それがイメージできるような話を現地ではしたはずです。
これらの脆弱性管理の全体感を考えていた時に、デジタル庁の「デジタル社会推進標準ガイドライン」が非常に有用だということを確認しました。
例えば DS-201 政府システムに於けるセキュリティリスク分析ガイドライン などは非常に有用と思われますので、一読したほうが良いと感じています。
脆弱性管理は、脆弱性それ自体に注目しがちですが、リスクや組織のセキュリティ対応全体像をイメージすることで、もう少し対応のしやすい環境が作れるかもしれません。そのための道具として、X.1060やデジタル庁のガイドラインを使っていただければと思います。
このような記事を継続して書くためには、記事があることでFuturVulsトップページへの流入や問い合わせがが増える、という( 私の )内部評価爆上げが必要です。
もしよろしければ FutureVulsのトップページ https://vuls.biz/ も訪問いただけると助かります。
また、セキュリティコンサル/脆弱性対応コンサルも行っております。ある程度は無償でご相談をお受けすることはできると思いますので、本件ご興味があればお問い合わせフォームからご連絡ください。
よろしくお願いいたします。
以上