😽

パッチ・ポスチャー・レポーティングでセキュリティが大幅に向上

2021/12/11に公開

Android

著者: I-Lung Kao / Product Manager

脆弱性の特定と修正は、安全な環境を維持する上で非常に重要です。今日、ほとんどの企業は、1つまたは複数の脆弱性スキャンツールを使用して、ビジネスに不可欠なサーバ、ラップトップ、デスクトップなどのエンドポイントの脆弱性を特定しています。また、プラットフォームやアプリケーション・ソフトウェアのベンダーが提供するセキュリティ・パッチを適用して脆弱性を修正するプロセスも導入されています。しかし、多くのセキュリティチームは、自社のITインフラが、新たに出現したマルウェアや悪用される可能性のあるベクターからの攻撃に対して、依然として脆弱であることを懸念しています。

では、現在の脆弱性の特定やパッチ適用のプロセスやツールには何が欠けているのでしょうか。私たちは、脆弱性とパッチ管理のプロセスを慎重に分析し、これらの分野に携わる複数のお客様のチームと交流して詳細を調べました。その結果、これらのプロセスやツールでは、パッチ状況の報告が不十分であったり、完全なデータが得られなかったり、運用が非効率であったりすることが、実際に各チームに大きな課題をもたらしていることがわかりました。また、このような課題があるために、多くの企業は、現在の脆弱性診断および修復機能を使用してITインフラおよび貴重なビジネス資産を保護することに、いまだ高い信頼性を確立できないでいることがわかりました。

以下は、主な調査結果の一部です。

パッチ/脆弱性対策が不足している
通常、セキュリティチームは、定期的に脆弱性スキャンを行い、主に脆弱性発見の観点から現在のセキュリティ体制を報告します。そして、IT運用チームは、特定された脆弱性に対処するために、すべてのビジネス・クリティカルなマシンにセキュリティ・パッチを適用する責任を負います。しかし、残念なことに、時間の経過とともに実行されたすべてのパッチ適用作業や、適用されたパッチによって脆弱性がどのように修正されたかを、包括的かつ累積的に把握できるデータは、通常ありません。お客様はHCLに対し、脆弱性の修正に焦点を当てたITインフラ全体の完全かつタイムリーなパッチ状況を把握できなければ、組織の全体的なリスクレベルやパッチ適用の効果を評価することは困難であると述べています。

脆弱性対策の優先順位が低い
HCLでは、セキュリティチームが作成した脆弱性データにIT部門がアクセスできないという話をよく聞きます。また、仮にアクセスできたとしても、発見された脆弱性を必要なセキュリティパッチに結びつけるためのデータがありません。このようなデータのギャップと、2つのチームが使用するツールの統合がなされていないため、IT運用部門がセキュリティパッチを適用しても、どのような脆弱性が修正されるのか、したがってパッチ適用が全体のセキュリティ態勢にどのような影響を与えるのか、正確に把握することができないのです。

今日のIT環境では、多数のマシンが存在し、各マシン上のソフトウェアスタック全体（仮想マシン、OS、ミドルウェア、アプリケーションなど）に適用すべきパッチが常に多数存在します。ITセキュリティチームと運用チームが協力して、「最も危険な」脆弱性（マルウェアに悪用された場合に最大の被害をもたらす可能性のある脆弱性）に優先的に対処することで、修復効果を最適化することがますます重要になっています。これにより、組織全体のセキュリティ態勢をタイムリーに高めることができ、コスト削減にもつながります。

コンプライアンスの証明が難しい
多くの法規制や企業のセキュリティポリシーでは、深刻度の高いセキュリティパッチを比較的短期間で適用することが求められています。例えば、PCI DSS（Payment Card Industry Data Security Standard）では、適用可能な重要なセキュリティパッチをリリースから1ヶ月以内にインストールすることが求められています。しかし、セキュリティパッチがいつリリースされたのか、そのパッチが各マシンにいつ適用されたのか、すべてのマシンにパッチが適用されたのかなど、必要な情報をすべて収集するのは、コンプライアンスチームにとって、通常、手作業で時間のかかる作業です。コンプライアンスチームは、規制や企業ポリシーの監査においてコンプライアンスをより効果的に証明するために、これらのデータをより自動的な方法で収集し、報告する必要があるとHCLに語っています。

パッチポスチャーレポートに求められるもの
これらの課題に対処するためには、独立したツールとして、または脆弱性管理、パッチ管理、コンプライアンスに焦点を当てた既存のソリューションの中に組み込まれた機能として、パッチポスチャーレポートを提供するソリューションを探します。パッチ状況報告の主な目的は、ITセキュリティチームとオペレーションチームが、脆弱性の特定、パッチ管理、およびコンプライアンスのタスクをより適切に実行できるようにすることです。より具体的には、以下のような機能を提供する必要があります。

セキュリティ管理者またはIT運用管理者が、すべてのマシンに適用されるすべてのパッチの現在の状況と過去の傾向を把握し、いつでも完全なリスク状況を把握したり、パッチ作業の効率性を評価したりすることができること。
IT運用担当者は、適用可能なすべてのパッチを重大度や現在の修復状況に基づいてソート／フィルタリングし、パッチ適用の優先順位付けを行うことで、セキュリティ体制の改善に最大限の効果を発揮することができます。
コンプライアンス担当者は、セキュリティパッチがいつリリースされ、各マシンに適用されたかを追跡・報告することで、規制や組織のポリシーへの準拠をより効果的に示すことができます。
ここでは、パッチ・ポスチャー・レポート・ツールが提供すべき具体的な機能について詳しく見ていきましょう。

包括的なパッチポスチャー評価
パッチポスチャーレポートは、ITオペレーションマネージャーがパッチ適用の効率性を評価し、セキュリティオペレーションセンター(SOC)マネージャーがパッチ適用によって関連する脆弱性がどのように修正されたかを評価するのに役立ちます。最新かつ包括的な情報を提供するためには、ほぼリアルタイムでパッチ適用状況のデータを入手できる必要があります。報告されるべき具体的なデータの種類は以下の通りです。

各パッチについて、修正されたすべてのマシン、（該当するすべてのマシンの中での）修正の割合、およびデータが時間の経過とともにどのように変化したか（過去の傾向）。
各マシンについて、適用されたすべてのパッチ、（適用されたすべてのパッチのうちの）修復率、およびデータが時間の経過とともにどのように変化したか（ヒストリカルトレンド）。
異なる責任を負う様々なチームに利益をもたらすために、姿勢データは以下のような複数のビューで表示する必要があります。

各マシンに適用可能なすべてのパッチを表示するマシン単位のビュー。
類似したマシンのグループに適用されるすべてのパッチを表示するマシングループごとのビュー（例：すべてのWindowsサーバー）。
特定のパッチが適用されるすべてのマシンを表示するパッチごとのビュー
すべてのマシンに適用されるすべてのパッチを表示する「集約されたポスチャー」ビュー
このような包括的なパッチポスチャーデータがあれば、セキュリティ管理者やIT運用管理者は、次のようなよくある質問に素早く答えることができます。

特定のパッチがまだ適用されていないマシンは何か（例えば、WannaCryのような悪質なマルウェアに悪用される脆弱性を修正することができる重要なセキュリティパッチの場合など）。
ビジネスに不可欠なサーバに適用されるすべてのパッチの現在の修正状況はどうなっているか？
まだ適用されていないパッチの数が最も多いマシンの上位10台は何ですか？

2.修復タスクの優先順位付け
完全なパッチポスチャーに加えて、データのフィルタリングやソート機能を備えたツールがあれば、IT運用担当者は次の修復の優先順位を効率的に決定することができます。フィルタリングやソートが可能なデータには次のようなものがあります。

パッチの深刻度（通常、深刻度の高いパッチを最初に適用する必要があります）。
パッチがリリースされた時期（通常、特にコンプライアンス上、古いパッチを早く適用する必要があります。）
パッチが優先されているかどうか（より新しい、優先されているパッチを適用することで、パッチ適用の総作業量を大幅に減らすことができます。）
パッチを適用できるマシンの数（より広範囲に適用できるパッチを適用することで、全体のポスチャーに大きな影響を与えることができる
現在の修復状況（修復率が低いと、セキュリティへの影響が大きくなる可能性があります）。
パッチ管理には通常、マシンのオフライン保守（パッチ適用）が可能な時期などの追加要素を考慮する必要があり、マシンの所有者との調整が必要となります。しかしながら、完全なパッチポスチャーと効率的なフィルタリング/ソート機能により、ITセキュリティチームとオペレーションチームは、より多くの情報に基づいてパッチの優先順位を決定することができ、より効果的に脆弱性を修正することができます。

3.パッチコンプライアンスのデモ
前述したように、セキュリティパッチに関する規制や企業ポリシーに準拠するためには、通常、非常に面倒なデータの追跡が必要となります。というのも、コンプライアンスの専門家は通常、監査の際に以下の質問に答えられる必要があるからです。

ベンダーがパッチをリリースしたのはいつですか？
ベンダーからパッチがリリースされたのはいつですか？それは該当する各マシンにいつ適用されましたか？
パッチがリリースされてから適用されるまでの経過時間は、規制やポリシーの要件を超えていたか？
このようなデータを自動的に追跡・保存し（パッチ管理ツールやパッチアクションログとの統合を意味する場合もあります）、コンプライアンス担当者が監査をパスするために活用できる関連レポートを作成できるツールの使用を検討してください。また、パッチ適用に関する過去の傾向データは、ITセキュリティおよび運用チームによる時系列での進捗状況を示すことができる点も重要です。場合によっては、100％のコンプライアンスが達成されていなくても、この過去のトレンドデータは、コンプライアンスの達成に向けた組織の継続的な進歩を示すのに役立つかもしれません（それによって、潜在的な罰金や影響を回避することができます）。

リスクを特定し、コストを削減し、コンプライアンスを実証するには、パッチポスチャーレポートが鍵となります。
要約すると、多くの組織は、パッチや脆弱性の状況を完全に把握し、脆弱性の修正を優先させ、コンプライアンスを効果的に実証することに依然として苦労しています。これは主に、既存の脆弱性発見ソリューションやパッチ管理ソリューションのデータ不足や機能不足が原因です。パッチ・ポスチャー・レポーティングは、このブログで紹介されている機能を必要としているITオペレーションチームやセキュリティチームに提供することで、これらのギャップを解消します。これにより、これらのチームや組織は、より効果的にセキュリティリスクを特定して軽減し、運用コストを削減し、ポリシーや規制に準拠していることを証明することができます。

詳細については、https://www.hcljapan.co.jp/software/products/bigfix/ をご覧いただくか、無料トライアルをお申し込みください。

Discussion