私は最近これについて考えています。彼らは同じものですか?または、後者はパッチの管理だけではありませんか?
違いを見つけるために、これらのタイプの管理が実際に最初に行うことを見てみましょう。
パッチ管理
パッチ管理には、ソフトウェアの変更の計画、取得、テスト、およびインストールが含まれます。これは、オペレーティングシステム、ドライバー、アプリケーションソフトウェア、アプライアンスのファームウェアなど、どのような種類のソフトウェアでもかまいません。パッチは、脆弱性を修正するために必ずしもインストールされる必要はありませんが、そうすることができます。多くの場合、バグを修正したり、ソフトウェアを最新バージョンに更新したりするために提供されます。中規模または大規模な組織(通常、パッチ管理がある場所)では、多数のシステムにパッチを展開するために使用される特別なソフトウェアソリューションがあります。例を挙げましょう: [〜#〜] wsus [〜#〜] はそのようなソフトウェアです。
脆弱性管理
以下 wikipedia 脆弱性管理は:
特にソフトウェアにおける「脆弱性の特定、分類、修正、緩和の周期的実践」。
追加したいのは、脆弱性はソフトウェアだけでなく、ハードウェアにも存在する可能性があり、プロセスや、ドア(弱いロックなど)や窓などの「物理的な世界」に関連するものにも存在する可能性がありますあなたのオフィスで。しかし、典型的な脆弱性管理はこれらのことを処理しませんが、それは可能です。これは組織によって異なります。
ISO 27000の次の定義も参照してください。
脆弱性
1つ以上の脅威によって悪用される可能性のあるアセットまたはコントロールの弱点
ソフトウェアの脆弱性は、多くの場合、パッチのインストールによって解消されます。これが、脆弱性管理がパッチ管理の一部であると言う人がいる理由です。私はそうは言わないでしょう、そしてここに理由があります:時々、システムを操作しなければならないシナリオがあり、それらは修正できない脆弱性を持っています。たとえば、非常に古いオペレーティングシステムでサーバーを実行することを望んでいる顧客がいるとします。管理者がこの顧客が重要であると考える場合、場合によってはこれらの脆弱性の存在を受け入れることを選択せざるを得ず、パッチを適用できない可能性があります。このサーバーを何らかの方法で保護するには、他のコントロールをインストールする必要があります。これは、脆弱性の「管理」の一部になります。 (さらに簡単な例は、パッチがない場合があります。)
結論
パッチと脆弱性管理は同じように聞こえますが異なります。パッチ管理は、いくつかの異なる理由でインストールする必要があるソフトウェアのパッチ、更新、修正を扱います。これらのパッチのロールアウトは事前に計画する必要があり、どのマシンがいつパッチを必要とするかを知る必要があります。 (数千台のデスクトップPCを操作する場合、この作業は思ったよりもはるかに困難です。)
脆弱性管理は、(主に)ソフトウェアのセキュリティ(場合によっては安全)の問題のみを扱います。多くの場合、これらの問題はパッチで解決できますが、常にそうであるとは限りません。脆弱性はあらゆる種類のシステムに存在する可能性があり、さまざまな戦略を駆使して排除することができます。管理者は、ファイアウォールポリシー、ネットワークセットアップの変更、新しいハードウェアの購入、従業員のトレーニングなどを行うことができます。パッチを使用して脆弱性を無期限に修正することは、ほとんどの場合非常に優れたソリューションですが、常に可能であるとは限りません。
パッチを適用するとき、パッチがベンダーの製品の既知の脆弱性を修正することを望みますが、ソフトウェアベンダーが独自の製品の脆弱性管理を行っていることに依存しています。
ただし、全体的な脆弱性管理は、組織のソフトウェアパッケージに修正を適用しただけではありません。それはその一部ですが、すべてではなく、ほとんどではありません。
脆弱性管理は、組織のITシステムの弱点を特定、分類、定量化、および軽減する継続的な方法です。ソフトウェアの誤動作は、システムにアクセスするために悪用されることがよくありますが、ソフトウェアのバグを悪用せずに組織のITシステムに違反する方法はたくさんあります。
それらはたくさん重なりますが、それらは間違いなく同じではありません。
脆弱性管理ははるかに重要な活動であり、パッチ適用は脆弱性を管理するための可能な活動の1つだと考えています。この意味で、脆弱性管理にはパッチ(またはパッチ管理)よりも多くの機能があります。ほとんどの場合、これはセキュリティ専門家によって管理されます。利用可能なパッチでカバーされていない脆弱性がしばしば見られます。
理想的には、アクティビティとしてのパッチは、パッチが修正する脆弱性に基づいて優先順位を付ける必要があります。ただし、最も基本的な成熟レベルでは、IT管理者が実行する独立したアクティビティである傾向があります。このような場合、既知の脆弱性に関連しないパッチが表示されることがあります(おそらく、セキュリティに関連しない欠陥を修正する-または単に日常的な活動)。