リスクベースの脆弱性管理に関する実務家の見解：必要とされる人員、プロセス、テクノロジー (日本語)

従来の脆弱性管理からリスクベースのアプローチに移行するのは、新しいテクノロジーだけでなく、既存のプロセスや手順にまで変化を伴うパラダイムシフトと言えます。その変化をどのように開始したらよいか、概要を手短にご説明します。

脆弱性管理は、時に延々と続くイタチごっこのようです! 脆弱性を 1 つ修正したかと思うと、数個が別のところに首を出す、といった具合に、脆弱性の数はうなぎ登りに増えていくので、従来の脆弱性管理 (VM) 手法では追いついていけず、最も重要なリスクの対処もできません。

従来の VM ツールの問題は、まず、効率がよくないことです。伝統的な、オンプレミスのIT環境でしか評価できず、定期スキャンは変化し続けている脅威環境を反映していません。また、どの脆弱性を先に修正するかを決定できるコンテキストがありません。 

もちろん、この非効率な状況は一夜にして起きたわけではなく 1 つのことに由来しているわけでもありません。 企業は、徐々に、あちこちに生じてきた変化の蓄積に適応するのが遅れているのです。幸いにも、今は適切なツールやベストプラクティスがあるので、現代のアタックサーフェスの要求に応えることのできる VM プログラムに迅速に移行できます。

事後対応型から事前実行型に - リスクベースの脆弱性管理のライフサイクル

基本的に、割り込み型で、処理ミスが多発しやすい非常に後手対応型の VM プログラムから、先行対応型で戦略的なアプローチに転換して、効率と効果を最大に引き出すことを目指す必要があります。言い換えれば、事後処理モードから脱却して、もっとも危険になりうる脆弱性に重点を置くのです。では、どのようにしたら達成できるのでしょうか。 多機能ツールに投資して、さらに、企業の VM 方針と手順を更新して変化し続けれるサイバー脅威に太刀打ちできるようにする必要があります。

Tenableでは、企業で採用するプロセスを 5 段階のライフサイクルとして捉えます。

リスクベースの VM は、単に脆弱性を検知して評価するだけでなく、各々の脆弱性のコンテキスト全体を理解して効果的に優先順位を付けます。そして適切なアクションを選択し、主要メトリクスを計算し、業界の基準と比較します。企業が得られる多くの利点のうちから、次にいくつか紹介します。 

• 貴重なセキュリティと IT リソースに優先順位を付ける
• チームの作業効率を最適化する
• ビジネスリスクを削減する
• 脆弱性管理プログラム経費を最小限にする
• セキュリティレポーティングを改善する
• 経営執行部の信頼を構築する

アタックサーフェスの全領域で事業必須サービスを発見する

リスクベースの脆弱性戦略の最初のステップは、時間をとって、事業環境を真に理解することから始まります。それは、事業に不可欠なサービスやアプリケーションを特定して優先し、それらの所有者とほかのステークホルダーを特定し、既存のセキュリティと適用されている IT ポリシーとプロセスを評価することです。

このステップにはツールは必ずしも必要ではありませんが、組織内の全部門の協力 – 特に事業の必須資産、アプリケーション、サービスの所有者の協力が必要です。スキャンの実行、パッチの適用、その他のセキュリティ対策を講じるには、事前に所有者から重要資産のアクセス許可を得ることが必要です。また、各重要サービスの可用性が損なわれないように、スケジュールを調整することが必要です。

ネットワークを頻繁にスキャンして盲点を排除する

次に、資産をすべて充分に評価します。そのためには新しいスキャナーが必要です。伝統的な IT ネットワークの範囲を超えて、アタックサーフェス全体、クラウド上の資産、オペレーショナルテクノロジー (OT)、コンテナ―環境も精査できる機能が必要です。 ウェブアプリスキャナーが統合されていることも重要です。なぜなら、企業機密データの多くがアプリ内に存在するかアプリを通っているので、アプリケーション層が主要なアタックベクトルになっているからです。

しかし、ツールのアップグレードだけでは不十分です。セキュリティ関連のプロセスも見直す必要があります。ネットワーク内のスキャンのカバレッジは十分ですか? スキャナーの目の届かない資産があれば、そこに重大な脆弱性が存在している場合、リスクになります。また、スキャンの頻度も十分かどうか確認する必要があります。 レガシーの VM 手法を使用している多くの企業では、月 1 回以下の頻度でスキャンが実行されているようですが、 そうすると、古い、すでに有効でない情報に基づいて修正が判断されていることになります。脅威環境は本来、動的な性質を持っているので、セキュリティインテリジェンスも同じように動的なければなりません。

資産の重要度と攻撃者の行動に基づいて脆弱性を優先順位付けする

アタックサーフェス全領域の脆弱性をすべて可視化できるようになったら、それらをビジネスリスクのコンテキストの観点から理解して、データを基に修正作業の優先順位付けに活用します。そのためには、スキャナーからくる脆弱性データを、その他の基本的なコンテキストの要素 (影響を受けている資産の事業における重要度、現在と将来の攻撃者の行動状況の把握、その他) とともに分析できる VM プラットフォームが必要です。 

もちろん、このようなデータすべてを分析するのは一人の手に負える仕事ではありません。ですから、VM プラットフォームは自動化と機械学習が可能なもので、正確な判断が秒単位で計算できることが必要です。

優先順位付けの戦略を調整していく過程で、各資産の評価時間を適切に設定して、事業サービスの中断を最小限にとどめることと、妥当なサービスレベルの内容合意 (SLA) を達成することが確保できるようにしてください。この項目は、事業環境とパッチ適用枠のために決められた合意内容について時間をとって理解する、という、最初のステップで行った作業に結びつきます。そもそも、事業が被るコストよりも修正によって得られる利点が小さければ、SLA の達成には意味がありません。

重大な脆弱性を修正または緩和する

最も優先順位の高い脆弱性がどれか決定したら、次に VM プラットフォームを欠陥追跡システムとしっかり統合させて、 IT に欠陥通知を直接送信できるようにします。通知は、何をどのように修正すべきか、なぜ優先対応が必要なのかを明記したものです。自動チケット発行システムを使えば、このプロセス全体の効率が最大化できます。双方向にコミュニケーションをとり、IT 側からスキャンを起動して修正の検証ができるようにします。

何もかも修正することは無理、ということを念頭に置いてください。すべてを修正しようとすることは、必ずしもセキュリティリソースの賢い使い方ではありません。それよりも、優先度の高い脆弱性の修正効果と影響を 1 つひとつ確認することがよいでしょう。修正は実行可能でしょうか? 不可能な場合、さらされる脅威を無効にする緩和策が導入されていますか? 単にリスクを容認して、何もアクションを取らないという選択肢が事業の観点から許容できますか? リスクの容認は、脆弱性が重要でない資産であれば適切な場合があります。また修正によって、資産で動作している必須プロセスが壊れる危険がある場合には必要になります。

多くの場合、対応策の実行の前に各資産の所有者の合意をとっておくことが必要です。そして、修正作業を実行したあとには、その効果を検証してから次の脆弱性に対応するのが正解です。

セキュリティの進捗を測定して伝達する

最後に、豊富なレポ―トと分析ツールを用いて、チームの修正実績を効果的に伝えること - 経営幹部にチームの責任者であるあなたの実力をアピールして、信頼を維持すること - が必要です。ツールの他に、組織内の様々なセキュリティグループと協力して、共通のダッシュボードを構築して、一貫したレポート機能を確立させることも必要です。 また、経営幹部と相談して、レポートの時期と頻度を設定する必要があります。

ここで修正する脆弱性は、上述のステップにもあったように、どちらかというとテクノロジーではなく、人に関係するものです。企業の最も重要な KPI が何であるか判断して、どのチームも共通した内容のレポートを発行できるようにし、複数の責任範囲を網羅したもの、あるいは会社全体の報告書として簡単にまとめられるようにして、CISO が役員会に明確な進捗報告ができるようにします。

リスクベースの脆弱性管理こそ、現代のセキュリティ戦略の基礎

正しく実装されたリスクベースの VM 戦略は、修正業務に優先順位を付けることができるので、最も重要な資産と危険な脆弱性を先に重点的に対処することに役立ちます。その結果、最小の努力で最大のリスクを減らすことができ、限られたセキュリティリソースを最も効率よく活用することができます。それによって新たに得られる効率の改善で、最も熟練したリソースをもっと戦略的な取り組みに回すことが可能になるでしょう。

このような枠組みを実際に導入する方法についてはこのホワイトペーパーをご一読ください。基本構想 : リスクベースの脆弱性管理