Ivantiブログ: 投稿者

効果的な最新パッチ管理プロセスとパッチ運用のベストプラクティス

Thu, 01 Aug 2024 06:01:00 Z

リスクベースの脆弱性管理プログラムを運用することは、安全なビジネスコンピューティング環境を維持するうえで不可欠です。以前のブログ「リスクベースのパッチ管理の実装が、悪用が確認されている脆弱性への対応を優先させる仕組み」では、脆弱性の優先順位付けについて考察しました。そのプロセスでは、システムを保護するための運用面を磨き上げることが不可欠です。

組織でパッチ運用を実施することは、複雑なプロセスになり得ます。脆弱性の優先順位について一定の見通しがあったとしても、次の点を考慮する必要があります。

パッチのリリース頻度。
このプロセスを効果的にするための支援ポリシー。
更新プログラムを展開するためのキャンペーン。
サービスレベル契約（SLA）とコンプライアンス測定。

調整すべきことが多いように感じられるかもしれませんが、計画済みのイベントを管理し、予期しない事態にも対応できる柔軟なシステムがあれば、完全にコントロールできます。

貴社はコントロールできていますか。

パッチリリースには、計画できる側面と計画できない側面があります。

たとえば、セキュリティパッチのリリース頻度を考えてみましょう。毎月第2火曜日のPatch Tuesdayに、Microsoftは最新の更新プログラムをまとめてリリースしようとします。これには、オペレーティングシステム、Officeやその他のユーザーアプリケーション、Visual Studioなどの開発ツール、Azureのクラウドコンポーネントなどの更新プログラムが含まれます。

2023年10月に20周年を迎えたPatch Tuesdayは、多くのパッチプログラムの基盤であり、最新のMicrosoft更新プログラムと利用可能なサードパーティ更新プログラムを一括配布するためのタイミングを提供しています。組織のパッチプログラムを推進するうえで、これほど大きな影響を与えたベンダーは他にありません。そして現在でも、Patch Tuesdayを基準とする月次パッチサイクルは業界標準であり続けています。

他のベンダーもこれに倣い、スケジュールに沿って更新プログラムをリリースしようとしてきました。

OracleはCritical Patch Updateを四半期に1回リリースしています。
Adobeは通常、月に1回、Patch Tuesdayと同期する形で更新プログラムをリリースしています。
Googleは最近、週に1回の単一更新プログラムのリリースを開始しました。

しかし、ほとんどのベンダーは脆弱性にできるだけ迅速に対応するため、可能な限り早く、また頻繁にセキュリティ更新プログラムをリリースします。その結果、組織全体で継続的に優先順位を付け、配布しなければならない更新プログラムが、予測しにくく終わりなく発生し続けます。

ポリシーとキャンペーンのためのパッチ管理プロセス

パッチリリースの混沌を制御するには、明確に定義された一連のルールと、それを適用するためのインフラストラクチャが必要です。パッチの領域では、これはポリシーとキャンペーンに相当します。

パッチポリシーでは、脆弱性の優先順位付けだけでなく、更新プログラムが業務運用に与える影響、異なる種類のシステムへの適用性、更新プログラムに対する制御の度合い、その他の要因など、幅広い事項を考慮する必要があります。

パッチポリシーは、ビジネスによって大きく対照的な内容になります。重要なビジネスアプリケーションをホストするサーバーの場合、そのポリシーには、厳格な構成管理の下で明確に定義された一連の更新プログラムが含まれ、定義済みのメンテナンスウィンドウ内でのみ実施され、完了時にはシステムが完全に更新されるよう必ず再起動が強制されます。一方、マーケティング担当ユーザーのノートPC向けのパッチポリシーでは、存在する場合としない場合がある承認済み更新プログラムを含む一連のアプリケーションを特定し、ユーザーが都合のよいタイミングまで更新と再起動を延期できるようにします。

キャンペーンはこれらのポリシーを考慮に入れながら、絶えずリリースされる多数のパッチを制御します。

最新のパッチ管理のベストプラクティスでは、月1回にとどまらない、より頻繁なパッチ適用が求められます。Google Chromeのパッチは毎週リリースされており、ゼロデイパッチはいつでもリリースされる可能性があります。月次キャンペーンだけでは、多くのシステムが長期間にわたり脆弱な状態に置かれます。

3種類のキャンペーンを確立する

ベストプラクティスは、定期メンテナンス、優先更新、緊急展開という3種類のキャンペーンを確立することです。

定期メンテナンスキャンペーン

定期メンテナンスキャンペーンでは、現在ほとんどの組織が使用している標準的な月次の段階的パッチ展開を実施します。このキャンペーンには次が含まれます。

パッチが計画どおりにインストールされることを確認するため、管理された環境で初期テストを実施する。
問題を報告できるよう注視している早期導入者からなる、より大きなパイロットグループへ展開する。
全体的な配布を完了するため、事前に定義された本番システムのグループへ展開する。

メンテナンスキャンペーンに含まれるパッチには、Microsoft Patch Tuesdayのリリースのように比較的頻度の低いセキュリティ更新プログラムに加え、パフォーマンス改善やアプリケーションのアップグレードが含まれます。このキャンペーンの対象システムには、メンテナンスウィンドウが限られており、業務への大きな影響なしには中断できないシステムも含まれる場合があります。ほとんどのパッチは、優先更新キャンペーンに分類される可能性が高いでしょう。

優先更新キャンペーン

優先更新キャンペーンは、新たな脆弱性に継続的にさらされているものの、より頻繁に更新できるシステムに迅速に対応するために設計されています。生産性アプリケーションやブラウザを実行しているユーザーシステムはこのキャンペーンの対象となり、フィッシング、マルウェア、ランサムウェアにさらされるため、多くの場合、最も高いリスクに置かれます。

このキャンペーンに関連するパッチは、悪用が確認されている脆弱性に対応するため優先度が最も高いことが多い一方で、ブラウザやアプリケーションの再起動を必要とする程度で、業務への影響が比較的低い場合もあります。そのため、ポリシーではリリース前のテストサイクルを短縮し、ビジネスクリティカルではない大規模なシステム群へより迅速に配布することがあります。たとえば、サーバーにはブラウザがインストールされていない場合がありますが、営業担当者のノートPCにはインストールされています。

ゼロデイ対応キャンペーン

ゼロデイ対応キャンペーンは、短期間で適用しなければならない、企業または業界の要請による緊急パッチ展開のために用意されます。このキャンペーンは他のすべてに優先します。

このキャンペーンのポリシーでは、満たすべきSLAに応じて、段階的展開の各ゲート間の期間を短縮したり基準を緩和したりすることも、場合によってはそれらを完全に省略することもできます。ゼロデイ対応キャンペーンで最も重要なのは、これが依然として管理されたパッチ配布であり、キャンペーンイベントの完了までを正確に追跡するため、すべてのアクティビティが引き続き報告されるという点です。

曝露時間がコンプライアンスを左右する

コンプライアンスを完全にパッチ適用済みのマシン数で測定する場合、この指標では、ほとんどのシステムが毎月限られた時間しか準拠状態にないことになります。技術的には正確ですが、リスクベースのプログラムにおいて、時間の経過に伴うシステムのセキュリティを示す指標としては不十分です。特定の脆弱性または脆弱性群に対する「曝露時間」を示すことで、リスクをより適切に把握できます。

例を挙げます。CVE-2024-4761は、5月14日にリリースされたGoogle Chromeの更新プログラムで修正されたと報告されました。この日は偶然にも5月のPatch Tuesdayでした。翌日、このChromeパッチは優先更新キャンペーンに追加され、グループ1の500台のシステムとグループ2の1,000台のシステムに対して、2週間の配布期間が設定されました。ほとんどのシステムがその2週間の期間内に正常に更新されたと仮定すると、レポートには各システムがいつ更新されたかが示されます。しかし、さらに重要なのは、これら1,500台の各システムがどれだけの期間パッチ未適用のまま、つまりその脆弱性にさらされリスクを抱えた状態にあったかが示されることです。

これは、1つの脆弱性と1つのパッチによるシンプルな例です。しかし、キャンペーンに複数のパッチが含まれ、それぞれに複数の脆弱性がある場合、その情報を集約して、より包括的なキャンペーンビューを提供できます。同じ期間に複数のキャンペーンが実行された場合は、結果を重ね合わせたり統合したりすることで、さらに正確なリスク評価を提供できます。

このデータがあれば、監査担当者にシステムの真のセキュリティ状態を示すことができます。さらに重要なのは、結果の評価を始め、最新のパッチ管理運用の有効性を向上できることです。その時点で、運用に振り回されるのではなく、貴社が運用を主導している状態になります。

リスクベースのパッチ管理を導入することで、アクティブなエクスプロイトに優先順位付けする方法

Tue, 20 Jun 2023 15:01:46 Z

特に実行中であり効率的で有効と考えている処理についての変更には、常に抵抗があります。セキュリティの違反もしくは事故が発生し、何が間違っていたかについて疑問に思うまでは、多くの組織がそのソフトウェア管理手順についてこう思います。

現実には、ほとんどのパッチ管理プログラムが、活発にエクスポロイとされている脆弱性についての事実ではなく、推定と推奨に基づいていると言う事です。リスクベースのパッチ管理がこの問題に対する答えです。

この記事でご覧下さい、

典型的な優先順位に従う事にどんな問題があるのか
リスクベースのパッチ管理とは
リスクベースのパッチ管理を採用する最適な時である理由

典型的な優先順位付けに従う事にどんな問題があるのか

ソフトウェア産業が始まって以来、ソフトウェア特性の更新、セキュリティー修正、バグ修正、パフォーマンスの向上、および多くのその他のタイプのソフトウェアリリースがありました。ベンダーはしばしば、それぞれに強度評価やその他のスコアを付けて、顧客に何が重要と考えられているかを伝えます。

残念ながら、これ等の評価には紐づけられた業界の水準が無く、我々は推奨に基づいてシステムでの展開についてリリースされたものを比較し優先順位を付けなければならないのです。この上に、その様な評価は脆弱性が変化してもアクティブな脅威の環境に対応するために更新される事が先ず無いのです。

悪用される脆弱性の見落とし

全く何も無いよりはましであっても、ベンダーの強度評価は余り良いものでもありません。 Follina脆弱性(CVE-2022-30190) 2022年5月公表について考えて下さい。このMicrosoft Windows Support Diagnostic Tool (MSDT)の脆弱性は、リモートコード実行を許容します。

マイクロソフトが最終的に幾つかの更新により対応するまでに、Follinaは数か月間攻撃を受けました。驚いた事に、マイクロソフトはこの脆弱性には通常の脆弱性スコアシステム（CVSS）v3にて7.8の評価と重大性を付けました。最大深刻度に基づいてパッチをするのみの場合は、あなたはこれを落とす事により重大な隙間を残してしまいます。

さらに悪い事に、FollinaのCVSSスコアは脆弱性が7.8のままとなり、活発にエクスポロイとされBisamwareランサムウェアの配布用に積極的に悪用され、これを見落とした組織をこれ以上のリスクに露呈するのです.。

Ivanti Neurons for VULN KBに表示された、CVE-2022-30190関連のランサムウェアの脅威に関連する情報があります

CVSSの短所

深刻度評価は、FIRSTのCVSSスコアで「補強」されます。各CVEにはCVSS番号が割り当てられており、上の例ではCVE-2022-30190に7.8が与えられています。

実際のCVSS番号を算出する主な目的の1つは、すべてのCVEが一貫してスコア付けされ、正確に比較できるように標準化を確実にすることです。脆弱性と関連するパッチのCVSSスコアが高ければ高いほど、ほとんどの環境において、そのパッチはよりクリティカルであることを意味します。

複数のCVEに対応するソフトウェアアップデートの場合、通常は最も高いCVSS値が優先順位付けのために考慮されます。しかしながら、この値は正確でしょうか？

最近の記事でCVSSスコアの分析の結果が発表され、CVSSスコアの20%近く(25,000)に不一致があった事が示されました。この分析はNIST National Vulnerability Database（NVD）に報告されたスコアとベンダーが直接報告したスコアの比較に基づいています。

ベンダーの脅威度についての不一致

留意すべき重要な点の1つは、ベンダーが従来より脅威度について独自の用語を割り当てている事です（例えば、クリティカル、重要）。ベンダーの重大度スコアリングを優先順位のメカニズムとして使用することは、あるベンダーのすべてのパッチを比較する場合にはうまくいくかもしれませんが、ベンダー間のパッチを必ずしも正確に比較できるわけではありません。実際、多くのベンダーはまったく異なる用語を使用しています。

同様に、ベンダーの脅威度は必ずしも肯定的な指標とはならないのです。ゼロデイ脆弱性の多くは、マイクロソフトによって「重要（Important）」としか評価されていませんが、これには高いCVSSの数値が付いています。重要度やCVSSを優先順位付けに使用したパッチ適用が、いかに仮定や推奨を使用しており、脆弱な環境をもたらす可能性があることが分かります。

何故その他の優先順位方法を取らずに、アクティブなエクスプロイトを優先するのでしょうか？

米国のCybersecurity and Infrastructure Security Agency (CISA)によると、積極的に悪用される脆弱性は、「システム所有者の許可なく、システム上でアクターによって悪意のあるコードの実行が行われたという信頼できる証拠があるもの」を指します。平たく言えば、積極的に悪用されている脆弱性とは、脅威アクターがサイバー攻撃を仕掛けるために利用した脆弱性です。

したがって、組織への攻撃のリスクを最小限化する為に、その他の全てよりアクティブにエクスポロイトされている脆弱性を優先すべきなのです。ほとんどの脆弱性はアクティブにエクスプロイトされておらず、組織へのリスクも小さいので良い知らせです。リスクベースのパッチ管理を通じてエクスプロイトされたものは識別可能です。

リスクベースのパッチ管理とは

によると、リスクベースのパッチ管理におけるガイドブック:

「リスクベースのパッチ管理は、ベンダーの脅威度と組織に対する最も重要なリスクとなる特定の脆弱性を識別し判別する為の基本のCVSSスコアに勝ります。

このリスクベースの脆弱性管理の拡張により、組織のセキュリティ態勢にとって最も重要である悪用された既知の脆弱性の更新を取り入れることで、現実のリスク状況をパッチマネジメントプロセスに反映させることができます。

組織はどの様にリスクベースのパッチ管理を取り入れる事が出来るのでしょうか？

パッチ管理についてリスクベースのアプローチを採用可能な組織については、CISA から始めると良いでしょう、既知のエクスポロイトされた脆弱性 (KEV) カタログ。 CISAは脆弱性と優先順位付けについて手助けをする為に大きな一歩を踏み出しました、拘束力のある運用指令22–01 、と共にKEV カタログであり、先ず発行された時に、カタログには約200のアクティブにエクスプロイトされた脆弱性があります。以降これは約900に増えました。

CISAは、含まれた脆弱性がアクティブな脅威にエクスプロイトされている知識を持ち、リストを作成しています。しかし、リストには短所も有り現在はランサムウェアに関連した131の脆弱性が除外されています。

CISA　KEVカタログのみがリスクベースのパッチ管理用のリソースでしょうか？

より熟成したリスクベースのパッチ管理方法を持つ組織は、この代わりにあるいは、CVSSに追加した高度なリスク評価方法でレバレッジしています。これ等の方法は組織環境で識別された全ての脆弱性についてスコアを与え、これ等の組織のCISA KEVを超えるリスクベースへの拡張を許容します。

リスクベースの脆弱性管理領域の多くのベンダーは、脆弱性がもたらす本当のリスクを表す独自の採点方法を開発しました。ベンダーは、積極的にエクスプロイトされたリスクに重みを付ける事により、動的なリスク評価を出します。

例えば、Ivantiの脆弱性リスク評価 (VRR) 、はFollinaに7.8のCVSSスコアよりも脆弱性のリスクを表す10のスコアを付けています。

VRRとCVSSｖ３スコア間とIvanti Neurons for VULN KBに示されたCVE-2022-30190の脅威度レベルの差です

リスクベースのパッチ管理を採用する最適な時である理由

システム更新が遅れたり、御社の新しいシステムやアプリケーションに圧倒されたと感じたら、リスクベースのパッチ管理. を採用する丁度良いタイミングです。

脅威度のレーティングやCVSSスコアに基づいた実質的なプログラムを持ち、変化への抵抗を捨ててて事業がエクスプロイトされた脆弱性. からのデータ侵害により途方に暮れる前に、新しいプロセスを開始して下さい。

CISA KEVを使用して更新と、割り当て、予算、リスクと脆弱性のパッチ管理ソリューションを優先して下さい。適切なツールの使用で、迅速で最も高度なリスクシステムを識別し、パッチを行い、システムをセキュアな状態するためにリストに従って下さい。

最初の一歩を踏み出そうとしていますか？リスクベースのパッチ管理におけるガイドブックをご覧ください。

デバイスコントロール：見落とされがちな技術

Mon, 18 Feb 2019 05:48:31 Z

ITのセキュリティに関してIvantiは、米国のインターネットセキュリティセンター（CIS）の基本的なセキュリティコントロールを支える製品を提供することで、多層防御を強く支持しています。CISの上位1と上位2の基本的なセキュリティコントロールには、それぞれ「許可されたデバイスと無許可のデバイスのインベントリ」と「許可されたソフトウェアと無許可のソフトウェアのインベントリ」となっています。デバイスコントロールは、セキュリティ対策を直接的に強化できる方法ですが、多くの場合パッチやアプリケーション管理技術の影に隠れてしまっています。

見落とされがちなこの技術に目を向ける

基本的なデバイスコントロールは一般的に、ワークステーションやサーバー、もしくはノートパソコンなどのモバイルシステムに接続される物理的なコンポーネントの管理を提供します。通常システムには、現在インストールされているハードウェアを検出し、インベントリ（目録）を作成し、他のデバイスの接続をモニタリングするエージェントがインストールされています。

接続される他のデバイスの中で最も懸念されるのが、USBドライブです。USBドライブには機密データがコピーされ、施設から持ち出される可能性があります。しかも多くの場合、形跡が残りません。デバイスコントロールでは、この種のデバイスの接続を完全に阻止する設定を行うことができます。または、ベンダーやモデル、シリアル番号までをも追跡することで、この種のデバイスを管理することを可能にします。例えば、社内でSanDisk Model xy12 USBデバイスの使用を許可し、他のUSBデバイスの使用を許可しない設定を行うことができます。これにより、事前にマルウェアがインストールされている可能性のある不明なデバイスがユーザーによって挿入されることを防止できます。

当社はこれまで、データ保存機能が装備されたスマートキーボードやBluetoothトランスミッタ、追加のネットワークカードなど、追加のリスクを伴う多数の種類のデバイスをブロックしている企業の例をたくさん見てきました。デバイスコントロールは成熟した技術です。お客様の必要な要件に合わせた機能を提供するための柔軟性の範囲は、無限といっても過言ではありません。

物理デバイスの管理に留まらない

「デバイスコントロール」という言葉は多くの場合、単純に物理デバイスのみの管理を示す言葉として解釈されるため、デバイスコントロールには、考慮すべき追加の側面があります。Ivantiのデバイスコントロールには、物理的な管理だけでなく、情報漏洩対策（DLP）の観点からデータの暗号化やデータのモニタリング/管理も含まれます。

基本オペレーティングシステムは、データが盗難された場合に、強化された水準のセキュリティをノートパソコンに提供するシステムディスクの暗号化を提供できるように設定することができます。ただし、この暗号化の対象範囲は、通常リムーバルドライブまで及びません。デバイスコントロールは、この追加の保護を提供し、リムーバルドライブも暗号化できます。このため、パスワード認証を使用してその他のマシンでリムーバルドライブを使用することや、リムーバルドライブをデバイスコントロールエージェントがインストールされたマシン上でのみ使用できる場合にリムーバルドライブをロックダウンすることが可能となります。

また、デバイスコントロールはデバイスへのデータ通信量とデータの種類もモニタリングできます。パスワード認証を使用してその他のマシンでリムーバルドライブを使用できる場合、マシンやユーザーがリムーバルメディアにコピーできるデータ量の制限を設定できます。同様に、デバイスコントロールエージェントは、使用中のファイルの名前と種類をモニタリングし、記録します。ファイルシャドーイングは、このオプションの拡張機能で、ファイル全体のコピーがレビュー用に第2のストレージに送信されます。さらにデバイスコントロールエージェントによってキーワード検索が実行され、ファイルがコピーされるとファイル自体の中身が検索され、事前に設定されたポリシーにしたがって適切な措置がとられることがあります。お読みいただいた通り、Ivantiのデバイスコントロールは単にUSBデバイスをブロックすることに留まらないのです。

デバイスコントロールの実装

デバイスコントロールの実装は、簡単で論理的なプロセスです。デバイスコントロールエージェントが希望のエンドポイントすべてにインストールされ、最初にデバイスの使用状況を取得するための設定が行われます。この情報は、ログアクティビティとして収集され、分析のために管理コンソールに送り返されます。管理者は使用中のデバイスをレビューし、企業のニーズに基づいてポリシーを構築します。

このブログで主に取り上げられている通り、このポリシーは、セキュリティの物理的側面、暗号化の側面、そしてDLPの側面に対応できるだけでなく、必要に応じてシンプルにも複雑にもできます。構築されるとこのポリシーはエンドポイントに適用され、監査モードに設定されます。ベストプラクティスでは、サンプルテストグループとしてシステムのサブセットを設定する必要があると指示されています。監査モードでは、阻止するデバイスと許可するデバイスを特定するために、どのようにポリシーが実行されているかが表示されます。これは、コンセプトの点でアプリケーションコントロールが通常展開される方法と類似しています。この時点で、ポリシーをアップデートもしくは「微調整」し、強制モードに設定できます。一定期間が経過し、十分なフィードバックが得られたら、ポリシーをさらに大規模なシステムグループに展開できます。繰り返しとなりますが、実装は自社のペースで進めることができ、自社のセキュリティ目標を確実に実現できます。

デバイスコントロールは、ハードウェアの詳細なインベントリ（目録）と各種デバイスの使用状況の高水準管理を実現できるだけでなく、各種デバイス上でのデータのコピーや保管も管理できます。ソフトウェア資産を直接管理することはありませんが、デバイスコントロールは、使用中のソフトウェアに関する詳細情報を提供します。デバイスコントロールは、実装が容易で、すべての注意がネットワークベースの攻撃に向けられている場合に見落とされていることが多いエリアに保護を提供できます。

自社のセキュリティプログラムを構築する際、デバイスコントロールを考慮してください。デバイスコントロールは、多層防御戦略において、極めて有用な技術と追加の保護層を提供します。

ぜひこの機会に、Ivantiの実証されたデバイスコントロール技術に関する詳細をご確認ください。

製品ページはこちらから>> https://www.ivanti.co.jp/products/device-control <<