脆弱性管理のベストプラクティストップ8

脆弱性管理のベストプラクティス

組織のシステムに存在する脆弱性が多ければ多いほど、攻撃者がアクセスしてビジネス、従業員、および顧客に損害を与える機会が増えます。

脆弱性管理プロセスを設計および実装する際には、次のベスト プラクティスを考慮してください。

#1.定期的な脆弱性スキャンの実行

脆弱性スキャナー は、アプリケーション内の潜在的な脆弱性やその他のセキュリティリスクを特定するために使用される自動化ツールです。 スキャンは自動化され、スケジュール設定できるため、セキュリティ・チームにとって追加のオーバーヘッドは最小限に抑えられます。

組織は、脆弱性スキャンを実行する必要があります。

• 一定の間隔で: セキュリティチームは、脆弱性スキャンを一定の頻度(毎日、毎週など)でスケジュールする必要があります。 これは、発見された、または環境に導入された新しい脆弱性を特定するのに役立ちます。
• 新しいソフトウェアについて: 新しいアプリケーションをデプロイする前と後に、ソフトウェアの脆弱性をスキャンする必要があります。 これにより、組織の環境に新たなセキュリティリスクが持ち込まれないようにすることができます。
• 新たな脆弱性が発表された場合 Log4Jのような一部の脆弱性は、即時の対応が必要です。 新しい重大な脆弱性が発表された場合、組織はアドホック脆弱性スキャンを実行して、そのリスクエクスポージャーを判断する必要があります。

脆弱性評価プログラムを設計する際には、さまざまな脆弱性の可視性を考慮することも重要です。理想的には、脆弱性スキャンは企業ネットワークの外部と内部の両方から、さまざまな特権レベル (未認証、認証済みユーザー、管理者) で実行されます。

#2.パッチを迅速に適用する

ソフトウェア製造業者は、自社製品の 1 つに新たな脆弱性が見つかった場合、それを修正するためのパッチを開発して発行します。 パッチが発表され、リリースされると、サイバー犯罪者は数時間以内にそのパッチをスキャンし、悪用し始める可能性があります。

組織は、できるだけ早くパッチを適用することを計画する必要があります。 パッチ適用戦略の主な要素には、次のようなものがあります。

• パッチの優先順位付け: 一部のパッチは重大な脆弱性に対処し、他のパッチは価値の高いIT資産に影響を与える可能性があります。 パッチ適用は、組織がサイバーリスクにさらされる潜在的な影響を最大化するために、優先順位を付ける必要があります。
• パッチテスト: 理想的には、管理者は、パッチを運用システムに展開する前に、現実的な環境でパッチをテストします。 これにより、パッチの有効性を検証し、新たなセキュリティ問題が発生しないようにすることができます。
• 自動ロールアウト: 通常、組織には適用するパッチが多数あり、一部のパッチは多数のシステムに影響を与える可能性があります。 自動パッチ適用ワークフローは、パッチを大規模かつ効果的に適用するために不可欠です。
• アップデートの検証: 更新プログラムが適用された後、パッチが適用されたシステムは脆弱性スキャナーで再度評価する必要があります。 これにより、更新プログラムが正常に適用され、新たなセキュリティ リスクが発生しなかったことが検証されます。

#3.リスクの優先順位付けの実行

ほぼすべてのアプリケーションには少なくとも1つの脆弱性が含まれているため、組織は一般的に、効果的にパッチを適用できるよりも脆弱なシステムを抱えています。 リソースと労力をどこに置くかを決定する際、セキュリティチームはパッチの優先順位付けを行う必要があります。

セキュリティチームがパッチを適用するタイミング/適用するかどうかを検討する際には、次のような点に留意してください。

• 深刻度評価: 多くの脆弱性には、問題の深刻度を示す一般的な脆弱性スコアリングシステム (CVSS) スコアが関連付けられています。 他の条件が同じであれば、重大な脆弱性は、高、中、低の脆弱性の前にパッチを適用する必要があります。
• システムの重要度: パッチは、組織にとって異なる重要度を持つシステムの脆弱性に対処する場合があります。 たとえば、組織の「主要な」データベースの脆弱性は、悪用された場合、重要度の低いシステムの重大度の高い脆弱性よりもはるかに影響が大きくなる可能性があります。
• 影響の及ぶ範囲： 脆弱性の中には、1つのシステムに存在するものもあれば、組織全体に影響を与えるものもあります。 影響を受けるシステムの数が多い脆弱性は、一部のデバイスにのみ影響する脆弱性の前にパッチを適用する必要がある場合があります。
• リソース要件: Windows OS のアップデートなど、一部のパッチは自動化されるように設計されていますが、その他のパッチは手動のビジネス操作が必要です。 パッチの影響は、パッチを適用するために必要な労力と比較検討する必要があります。

結局のところ、組織はすべての脆弱性にパッチを適用するわけではありません(おそらくそうすべきではありません)。なぜなら、各脆弱性は他の場所でより有益に使用される可能性のあるリソースを消費するためです。 パッチを適用する内容とタイミングの決定は、以下によってもたらされる脅威に基づいて行う必要があります。

• 特定の脆弱性
• 組織のリスク許容度

#4.システム構成の管理

一部の脆弱性は、アプリケーションコードのエラーによって作成されます。 たとえば、SQLインジェクションとバッファオーバーフローの脆弱性は、安全なコーディングのベストプラクティスに従わなかったことが原因です。 ただし、アプリケーションがデプロイおよび構成されるときに、他の脆弱性が発生します。

新しいセキュリティの脆弱性は、次の方法で導入される可能性があります。

• 脆弱なパスワード
• デフォルト設定の使用

組織は、すべての企業アプリケーションとシステムに対して安全なベースライン構成を定義し、使用を強制することで、これを管理できます。 このベースラインの使用は、定期的な監査と構成管理システムを通じて実施する必要があります。

#5.脅威インテリジェンスの活用

脅威インテリジェンスは、組織が直面する可能性が最も高い脅威とサイバー攻撃キャンペーンに関する洞察を提供します。 同じ業界、管轄区域、または規模の他の組織が特定の脅威の標的になっている場合、あなたのビジネスも標的にされる可能性があります。

脅威インテリジェンスは、脆弱性の修復と軽減の取り組みに優先順位を付けるために非常に貴重です。 活発に悪用されている脆弱性には、可能であればすぐにパッチを適用する必要があります。

パッチを適用できない場合、組織は監視と利用可能な予防措置を実装して、悪用のリスクを減らす必要があります。

#6.インシデント対応との統合

脆弱性管理とインシデント対応は、関連し、補完的な取り組みです。

理想的には、脆弱性管理は、セキュリティリスクが悪用される前に排除することで、インシデント対応の必要性をなくします。 ただし、常にそうであるとは限りません。

組織がサイバー攻撃を受けた場合、脆弱性管理データにアクセスすることで、インシデント対応プロセスを迅速化できます。 インシデント対応チーム (IRT) が組織のシステムに特定の脆弱性が存在することを認識している場合、根本原因の分析と修復作業が促進される可能性があります。

一方、インシデント対応からのインテリジェンスは、脆弱性の修復作業にも情報を提供できます。

インシデント対応者は、未知の脆弱性を特定したり、管理されていない脆弱性が活発に悪用されていることに気付くかもしれません。 このデータは、セキュリティ チームがリスクの高い脆弱性に対処し、リスクの優先順位を更新して、今後同様のインシデントが発生しないようにするのに役立ちます。

#7.継続的な改善を受け入れる

脆弱性管理は、ほとんどの組織にとって継続的なプロセスです。 新しい脆弱性は毎日発見され、開示されているため、ほとんどのセキュリティチームは、評価すべき脆弱性と適用すべきパッチのバックログを常に抱えています。

脆弱性を完全に排除することはおそらく選択肢にないため、セキュリティチームは、脆弱性管理プログラムを長期的に改善することに集中する必要があります。

考慮すべきメトリクスには、次のようなものがあります。

• 運用システムに到達する脆弱性の数。
• 新しい脆弱性を特定するための平均時間。
• 脆弱性にパッチを適用する平均時間。
• 重大または重大度の高い脆弱性にパッチを適用する平均時間。
• 運用システムの脆弱性の総数。

#8. コンプライアンス要件の検討

企業は、セキュリティおよび脆弱性管理プログラムを開発する際に、さまざまな規制と標準を考慮する必要があります。 悪用された脆弱性は、機密データが侵害される一般的な方法であり、企業はこれらのリスクを管理する必要があります。

パッチ管理の計画とプロセスを定義する際、セキュリティチームは、さまざまなシステムによって処理されるデータの種類と、その規制への影響を考慮する必要があります。

たとえば、コンプライアンス要件により、一部のシステムをパッチ適用プロセスで優先する必要がある場合があります。