IT 資産検出がリスクベースの脆弱性管理プログラムの基盤となる理由

現在、236,000 件以上の脆弱性が確認されています。NVD には毎日平均 61件の新しい脆弱性が追加されているため、出現するすべての CVE や脅威ベクトルを改善することは不可能です。 では、特に Everywhere Workplace のハイブリッド化とリモート化が進む中、日常的な組織はエンドユーザー、顧客、データに対する増大し続ける脅威にどのように対処すればよいのでしょうか。

第一に、ネットワークに常時接続されている資産を把握することで、リスク面をマッピングすることが重要です。 TAG Cyber のシニアセキュリティアナリストである John J. Masserini 氏と、Ivanti のセキュリティ製品管理担当部長である Chris Goettl の 2 人の専門家に、脆弱性の優先順位付けのために組織独自のサイバーリスク要因を把握する方法を聞きました。  

以下のインタビューの一部をご覧ください。また、実際の RBVM プログラムでのベストプラクティスの詳細を紹介したディスカッションの全文を視聴するには、ウェビナーの録画をご覧ください。

ネットワークのすべての (確認済みの) エンドポイントを検出

Chris Goettl: サイバーセキュリティのロードマップを理解し、策定するために、誰もがセキュリティフレームワークを頼りにしていると思います。 NIST、CIS、地域別、サイバーエッセンシャル、ASD トップ 20 など、主要なサイバーセキュリティフレームワークをすべて見てみると、そのすべてに、検出と資産管理に関する要素が含まれていることがわかります。 その理由は、環境に何があるのかがわからなければ、セキュリティを確保できないからです。 アクティブ、パッシブ、複数のデータソースに接続し、環境に関する多くの情報を集約する能力など、検出はあらゆるセキュリティプログラムの基礎となる部分です。  

Ivanti は検出に関する多数の機能を備えています。お客様との関わりやセキュリティに関する調査を通じてわかったことは、ほとんどの組織では、実際に環境で管理されているすべてのデバイスに関する理解に 20～30% のギャップがあるということです。  

エンドポイント管理ソリューション、資産管理ソリューション、エンドポイント保護 (EDR や何らかの種類の脅威保護プラットフォーム) といった環境全体で 6、7 個のデータポイントを取ると、それぞれに管理対象コンピューターのセットがあります。 それを調達チームと照らし合わせると、異なるデータソース間で、あるコンピューターで管理され、別のコンピューター管理されていないコンピューター割合が 2 桁になることを保証します。 そのため、1 つのデータソースからでは、環境の30% 以上が見えなくなってしまいます。  

サイバーセキュリティフレームワークの基礎となる最も重要な理由の 1 つは、環境における死角の 30% 以上を把握する必要があるからです。把握しなければ、脅威の脅威にさらされることになるからです。

不明な IoT デバイスが IT 環境にとって脅威となりうる理由

Chris Goettl: 懸案事項となりうる点がいくつかあります。 1 つは、そのデバイスに脆弱性がある場合です。私は、広範な DDoS 攻撃で電球が使用されているのを見たことがあります。 これは、誰も脅威になるとは思っていないシンプルな IoT デバイスが、はるかに大規模な攻撃の一部になる可能性があることの一例に過ぎません。

そのデバイスに欠陥があった場合、誰かが遠隔操作で強制的に、そのデバイスを発熱体がオンになる状態にして、火災を発生させる可能性があります。 デバイスがそのような方法で使用されるさまざまな可能性があります。  

最近、医療関連の種類の IoT デバイスがありました。 このロボットは病院内にあり、動き回り、患者の治療に必要なものを運んできたり、研究室に何かを届けたり、さまざまなことをするスタッフをサポートすることができます。 これらのデバイスで、そのデバイスが近接している会話を誰かが傍受できるという脆弱性群が発見されました。 デバイスは強制的に停止させることができました。 デバイスは出入り口を塞いでしまうほどの大きさでした。 医療施設では、重要な出入り口をふさぐと、そのデバイスが基本的にロックされ、障壁となるため、時に不利になることがあります。  

これらのデバイスは、無害であるように思われても、環境に対して潜在的なリスクをもたらします。 この場合、検出によって、本来あるべきデバイスを特定しましたが、管理できないものであるため、セグメント化される可能性があります。では、パッチを適用できるのでしょうか。 実際にはそうではありません。 ファームウェア更新はあるかもしれませんが、そこまでして管理するものでもないでしょう。 それらをセグメント化しますが、環境に何があるのか、何が不利になるのか、きちんと理解しておく必要があります。

資産情報がどのようにパッチの優先順位付けに役立つのか

John Masserini 氏: 所有している資産を把握することは、脆弱性管理プログラムを構築するための基礎のようなものです。 しかし、次のステップでは、組織の収益源にとってのこれらのデバイスの重要性を理解する必要があると思います。  

パッチの内容や適用方法については、すべて、プログラムに関係なく、どの程度の停止を許容できるか、そのデバイスやデバイスの流れから生み出される収益はどの程度か、停止をどのように管理するか、脆弱性を解消しない場合のリスクを誰が引き受けるかという点が重要になります。 そのため、業務にとってデバイスがどれだけ重要であるかを理解することは、あらゆる種類のリスク測定において大きな原動力となると考えています。 リスクに基づく脆弱性管理について話すときには、個々のデバイスや個々のワークストリームでどのようにリスクを活用できるかを理解することが重要です。  

私は、そのために、いつも BCP プログラムを活用しています。 事業継続プログラムにとって重要なビジネスインパクト分析の実施も、アプリケーションや環境などのリスクを理解するうえで、脆弱性管理プログラムにとっても同様に重要です。 ビジネスインパクト分析を行うと、ビジネスにとって非常に優れた知見が得られるのと同時に、IT 側にとっても貴重なものとなります。  

ビジネスに足を踏み入れるたびに、「すぐに対応してほしい。 停止は絶対に避けたい。顧客満足度を保証したい」などと言われます。 そして、「それなら、これがかかるコストです」と言うと、「そんな予算はない」と返されます。すぐにこのような議論に突入してしまいますが、その際の最低限、許容できる基準は何でしょうか。 隔週金曜日の午前 2 時から 4 時までの 2 時間の停止枠を確保できるのかなどと言うことができるのでしょうか。 そして、これが会社の収益の 80% を支えていることを理解し、それに対して非常に敏感でなければならないのです。 四半期ごとにパッチを適用することもありますが、そのような環境では、ミームなどを共有するための社内サイトとは異なるレベルのテストが行われるのは確かです。  

インフラストラクチャにあるさまざまなデバイスの重要性は根本的に異なり、リスク分析を正しく行うために評価、測定する必要があります。  

信じられないかもしれませんが、そのようなものの多くは、レガシーなものばかりです。 古いメインフレームを運用していても、AS/400を運用していても、最先端のデバイスを運用していても、しかし、脆弱性は、ライブラリにパッチを展開するのではなく、新しいファームウェアフラッシュでなければなりません。 これらはまったく異なるモデルであり、まったく異なるリスク分析の断片です。 アプリケーションにパッチを適用する。WindowsのノートパソコンでChromeにパッチを適用する必要がある場合は、「この重要なルーターまで行って、夜間にファームウェアをフラッシュする」と言うのとはまったく異なるリスクプロファイルがあります。まるで異なるリスクなのです。  

そこで、これらすべてがどのように連携しているかを理解することで、 BIA から得られる資産の検出とリスク分析の間に、この 2 つが、リスクに基づく脆弱性管理を中心としたあらゆる種類の長期戦略を構築するための驚異的な基礎となるのだと考えています。

ネットワークに何があるのかを知ることは、セキュリティ対策にどのような優先順位をつけるべきかを理解するための第一歩です。 リスクベースのアプローチで脆弱性管理を行うことで、最も弱い部分に集中できます。資産検出では、隠れた部分まで含めてすべてを特定することができます。  

実際の RBVM プログラムのベストプラクティスの詳細については、このディスカッションの続きをご覧ください。