クラウドに CVE は 必要？ 不要？：変容する脆弱性の管理について考える – Veracode

Why cloud vulnerabilities need CVEs

2024/05/01 HelpNetSecurity — いまの世界において、脆弱性の管理の目的を考えるとき、新しいテクノロジーへの大きな移行を認識する必要がある。たとえばクラウドなどの、各種のパラダイムや環境の中で、リスクを管理する方式を認識することが不可欠となる。ネットワーク・セキュリティの継ぎ接ぎは、同じようにクラウド環境に適用できないだろうし、脆弱性に CVE 識別子を割り当てるクラウド・プロバイダーもほとんどいないという状況である。

この CVE ベースの構造のみで話を進める脆弱性管理チームにとって、クラウド・サービスにおける CVE 欠如は重要な課題である。クラウド特有の脆弱性が、毎週のようにニュースに散見される中において、クラウド・サービス・プロバイダーが CVE 識別子 (または類するもの) を使用すべきかどうかという問題は、これまで以上に重要な意味を持つ。

リスクと脆弱性の管理にクラウドが与える影響

なぜ、この議論が必要なのかを理解するために、クラウド・サービスが脆弱性管理者の役割を、どのように変えるかを考えてみよう。従来のネットワークでは、脆弱性アナリストがインフラへのパッチ適用を担当する。しかし、クラウド・サービスにおいては、ユーザー組織がインフラを管理しないため、パッチ管理はクラウド・サービス・プロバイダーにオフロードされる。つまり、脆弱性チームの責任は、パッチ管理からコンフィグレーション管理に移ったことになる。

結局のところ、コンフィグ管理こそが、組織がコントロール可能なリスクの、大部分を占める場所なのだ。それ以外にも、クラウドには多くのリスクがあるが、もはや脆弱性管理チームは、それをコントロールできない。もちろん、そこには長所と短所がある。長所は、クラウド・プロバイダーがセキュリティ・リスクの大部分を引き受けるだけでなく、脆弱性へのパッチ適用の作業も引き受けることだ。裏を返せば、脆弱性管理者は、組織のインフラのセキュリティを、ほとんど、あるいは、まったく、コントロールできないという新たな領域に身を置くことになる。

コンフィグ管理の重要性と、クラウド・サービスに CVE を付けることの正当性を示す悪名高い例として、MongoDB のデフォルト・パスワード・コンフィグの問題がある。ここで問題となるのは、デフォルトの設定に CVE 識別子を付けるべきだったかどうかだ。もしスタンドアロンのソフトウェアで、このようなことが起きていたのなら、CVE が存在する可能性は非常に高い。そして、このミス・コンフィグは、何十万ものサーバに影響を与えた。

クラウドは、きわめて多くの場所で複製が可能である。もし、Terraform のデプロイ・コンフィグが、１つのクラウド環境で破綻してしまうと、おそらく組織全体のクラウド環境に複製されるだろう。クラウドの脆弱性には、大規模なセキュリティ問題につながる可能性があるのだ。

CVE が無いことで、脆弱性管理に生じる影響は？

興味深いことに、クラウド・プロバイダーは CVE ID を割り当てることができるはずだが、多くのケースで割り当てられないため、脆弱性アナリストは難しい状況に置かれている。CVE は、潜在的なリスクを特定し、その脆弱性を追跡／分析して、確実に是正する上で大きなメリットがある。

この共通の識別子が存在しないと、脆弱性アナリストは、ミス・コンフィグされた S3 バケットなどの漠然としたアラートや、絶えず変化する名前 (heavily misconfigured S3 bucket) に基づいてミス・コンフィグを追跡するという、複雑で苛立たしい作業に取り組む機会を増やすことになる。このプロセスでは、結論が出るまでに、数週間から数カ月かかることもある。このリスクを受け入れるか、改善するかである。

何が CVE になるのか？

この議論の微妙なニュアンスの１つは、伝統的な意味での、脆弱性を構成するものは何か？ そして、何が CVE になるのか？ ここで考えてみたいのは、中国のハッカーにより署名キーが盗まれ悪用された、Microsoft のインシデントだ。盗まれたキーに起因するハッキングなので CVE は存在しなかったが、不適切な鍵の検証は確かに CVE 識別子に値する脆弱性のようにも思える。少なくとも、脆弱性アナリストがリスクを理解する際の助けになるだろう。

クラウド・サービスにおける CVE を定義するときの要点は、そこにあるのかもしれない。つまり、セキュリティ・アナリストが組織のリスクについて、情報を提供し、また、教育し、リスクを軽減するための行動を起こす際に、CVE 識別子は役立つのだろうか？もしそうなら、CVE 識別子を付けるべきだ。

CVE ではないなら、何になるのか？

CVE の要点は、固有の脆弱性を正確に特定し、その情報を業界全体に迅速に伝達する方法を提供することだ。しかし、クラウドの脆弱性に関しては、固有の識別システムは無く、業界内で発生しがちなミス・コンフィグについて、話し合う場もほとんどない。

ユーザー組織は、クラウド・セキュリティの基準を策定した、Center for Internet Security (CIS) のようなコンプライアンス・フレームワークをベンチマークとしている。NIST 800-171 や 800-53 のような、政府が作成した基準もあるが、これらは広範なフレームワークであり、ここでのニーズに対応したものではない。

また、クラウド・リソース全体における、ミス・コンフィグの検出と修復を自動化する Cloud Security Posture Management (CSPM) ベンダーに注目するのも良いだろう。これらのベンダーは、いずれも独自の識別基準を策定している。しかし、ユーザー組織がマルチクラウド戦略を採用し、複数の CSPM ツールを使用している場合において、それらを統合する方法はない。

では、私たちは、どうすれば良いのだろうか？ 業界としては、クラウドのミス・コンフィグについて、より明確で実用的な方法での話し合いを促進するための、一意の識別子を持つべきだと思う。おそらく、それが、クラウドのための CVE だろう。それを、クラウドの CCVE (Common Cloud Vulnerability Enumeration) などと、呼ぶこともできるだろう。

想像してみてほしい。”MongoDB のデフォルト・パスワード” という曖昧なアラートの代わりに、このバージョンでは “CCVE 1-1.2” というアラートが表示され、それが “Amazon S3 バケットのデフォルト・パスワード” を意味することが、アナリストたちに伝わるかもしれない。

このレベルの、詳細で標準的な定義は、ミス・コンフィグを追跡して修正するワークフローを、きわめて単純なものに置き換える。

クラウド・サービスに CVE のような識別子を付けるメリットは？

Veracode の調査によると、一般的な組織では１カ月の期間において、環境内の脆弱性の約 10％しか修正できないことが分かっている。このままでは、ユーザー組織は公表済みの脆弱性を大量に抱えることになる。この脆弱性の負債は、年を追うごとに増えている。それは、金融の負債とは異なり、破産を宣言することができない。したがって、修正するか、無視するかして、最善を望むしかない。

すべての脆弱性を追跡／修正することは、すでに上流における戦いとなっている。おそらく、クラウド固有の CVE にインスパイアされた識別は、こうした問題の追跡と修正の作業を容易にするために、業界にとって取り得る一歩になるだろう。もしそうでないなら、より良い解決策を見つけるために、オープンな議論を開始すべき時である。なぜなら、私たちの集団的な脆弱性の負債が積み重なり続け、私たち全員がリスクの量を判定できず、どれくらいが多すぎるのかと問いかける日が、そう遠くないからだ。

クラウドの脆弱性にも CVE をという意見には大賛成です。しかし、CSP 側としては、CVE を採番して公にすると、その後が面倒になるという考えがあるのだろうと推測します。似たような記事があったと思い、検索してみたら、2021/08/07 に「Black Hat 2021：クラウドの脆弱性にも CVE アプローチが必要なのか？」をポストしていました。よろしければ、Veracode のレポートと併せて、ご参照ください。