2021 年 12 月、待望の VMware NSX-T Version3.2 がリリースとなり、2020 年に買収した Lastline 社の技術を統合して、データセンタやクラウドの仮想環境におけるセキュリティ機能の強化を実現しました。
新しく追加された機能の中には、フル システム エミュレーションという独自のアーキテクチャと、一般的利用されるハイパーバイザー アーキテクチャのハイブリッドで実装したサンドボックスや、Network Detection and Response（以下、「 NDR 」という）も含まれており、エンドユーザーであるお客様や MSSP 様のセキュリティ運用を効率化できるようになりました。
さらに、Gartner 社が提唱している、SOC Visibility Triad では、SOC 運用を効率化する 3 つの要素、つまり「 SOC 運用の三種の神器」として、「 SIEM/SOAR 」「 NDR 」「 Endpoint Detection & Response（以下、「 EDR 」という）」が提唱されており、これらを API で結合して運用することで、より効率的な SOC 運用が可能としています。
VMware での仮想環境におけるセキュリティ対策は、NDR として「VMware NSX-T Firewall with Advanced Threat Prevention（以下、「 NSX-T FW w/ATP 」という）」を、EDR として「 Carbon Black Cloud Workload（以下、「 CBCW 」という）」を提供しており、現在、開発を進めている eXtended Detection & Response（以下、「 XDR 」という）への第一弾として、NSX-T FW w/ ATPの分散ファイアウォールとCarbon Black Cloud Workloadのインテグレーション機能の提供を開始ました。本ブログではそのインテグレーションの概要とその検証結果を共有したいと思います。
VMware の EDR には、Agent をエン ドポイントにインストールして利用する Carbon Black Cloud（以下、「 CBC 」という）と、vSphere 上に EDR の機能を実装した仮想環境用の CBCW があり、今回は後者と NSX-T のセキュリティ機能とのインテグレーションを紹介します。
NSX-T のセキュリティライセンスは、ご利用になられる機能ごとにライセンスが分かれており、この検証で利用する NSX-T では「 NSX Distributed Firewall（以下、「 NSX-T DFW 」という」）」のライセンスを利用します。なお、本ブログを執筆している2022年2月2日現在の NSX-T のライセンス詳細については、こちらのブログをご覧ください。
[ 動作概要 ]
まず、紹介させていただくソリューションをイメージしていただくために、本ブログで行う検証の動作概要をお伝えしたいと思います。
vSphere 環境に、NSX-T と CBCW をインストールして NSX-T DFW と CBCW を有効化、CBCW は vSphere, NSX-T, CBC と接続して環境を整えておきます。
あるワークロードが悪性のファイルをダウンロードして、そのファイルを展開すると CBC がその脅威を検出してアラートをあげます。
その際、その悪性ファイルが水平方向（東西方向）に展開するラテラル ムーブメントが発生するリスクがあります。昨今の高度なサイバー攻撃や標的型攻撃、標的型ランサムウェア攻撃などで多く利用されている攻撃の一つであるため、非常にリスクが高いです。そのリスクを軽減するために、インシデントレスポンスの初期対応として当該ワークロードを一旦隔離します。
隔離するポリシーとしては、完全に隔離してしまうと、その後のフォレンジックなどの追加の調査に支障をきたしてしまうため、今回は完全隔離ではなく、CBC からのアクセスのみ許可し、それ以外は全て拒否、というポリシーを適用します。
制限付きの隔離をすれば、CBC からの調査も可能になりますので、ライブ レスポンスなどで調査し、悪性ファイルを駆除して、その他の脅威がないかをチェック、安全性が確認できれば復旧する、というシナリオです。
Figure1 : 動作概要
[ 構成と使用したソフトウェアバージョン ]
検証した構成は次の構成図のようになっています。
Figure2 : 検証構成図（概要）
使用したソフトウェアバージョンは以下の通りです。
- vSphere : 7.0.2
- NSX-T : 3.1.3
- Carbon Black Workload VA : 1.1.2
[ 注意事項 ]
本インテグレーションを利用するにあたって、以下の注意事項がございますのでご注意ください。
- N-VDS で利用すること：次のスクリーンショットの場所でご確認ください（CBCW の次期バージョンで VDS に対応予定）
- CBCW はバージョン 1.1.2 以上を利用すること
Figure3 : NSX-T での N-VDS 設定の確認画面
それでは、設定をしていきたいと思います。
[ 設定 ]
まず、CBC の管理コンソールで NSX-T との接続と連携に必要な API のアクセスレベルを追加します。
詳細の設定方法はこちらのドキュメントをご覧ください。
Figure4 : Carbon Black Cloud での API アクセスレベル設定画面（抜粋）
次に、新たに作成した API アクセスレベルにAPIキーを追加します。
ここで生成される API ID と API シークレットキーは CBCW の設定で使用します。
また、お取り扱いには十分ご注意ください。
Figure5 : Carbon Black Cloud での API キー追加設定画面（抜粋）
Figure6 : Carbon Black Cloud での API キー認証画面（抜粋）
CBCW、CBC, vSphere, NSX-T との接続を行いますが、その時に NTP サーバの設定を推奨されますので、NTP サーバの設定も行います。
Figure7 : Carbon Black Cloud Workload での NTP サーバ設定画面（抜粋）
Figure8 : Carbon Black Cloud Workload から各コンポーネントを接続設定画面（抜粋）
ここまで設定が完了すると、CBCW から NSX-T にグループ設定と分散ファイアウォール設定が自動的にプッシュされます。プッシュされるグループ名と、分散ファイアウォールで設定されるポリシー名が同じ名前で管理しやすくなっています。
Figure9 : NSX-T のインベントリのグループ設定画面（抜粋）
Figure10 : NSX-T の分散ファイアウォールに自動的に設定が反映された画面（抜粋）
デフォルトで自動的に設定される分散ファイアウォールのポリシーは以下の通りになります。
- CB-NSX-Isolate
このポリシーを適用されたら、完全隔離となって、全ての通信がドロップします。なお、この設定変更は不可となっています。 - CB-NSX-Quarantine
このポリシーを適用されたら、CBC との通信だけを許可するために、CBC 宛のトラフィックと、DHCP によるアドレスの取得や DNS による名前解決、IPv6 の Neighbor Discovery で近隣探索など、CBC へアクセスするために必要な最低限のプロトコルと宛先のみが許可され、それ以外の全ての通信がドロップとなります。なお、この設定変更は不可となっています。 - CB-NSX-Custom
このポリシーはDefaultでは、CB-NSX-Isolateと同じですが、設定変更が可能になっており、カスタムで自由に設定することができます。
今回の検証では、CB-NSX-Quarantine を利用しようと思いましたが、せっかくなのでこの CB-NSX-Custom を使って、CB-NSX-Quarantine と同じ設定を行なってみたいと思います。
Figure11 : NSX-T 分散ファイアウォールのコンテキスト プロファイル設定画面（抜粋）
Figure12 : NSX-T 分散ファイアウォールのカスタムで設定を追加した画面（抜粋）
設定作業はこれで完了しましたので、ここからは動作確認をしていきたいと思います。
[ 動作確認 ]
今回は、Windows 10 のホストを2台準備し、それぞれ、「 Win10-SEU01 」と「 Win10-SEU02 」というマシン名のワークロードとして利用し、「 Win10-SBU02 」が悪性ファイルをダウンロードして展開するシナリオとします。
まず、インベントリのグループやタグに何も割り当てていない、それぞれのワークロードにもタグが割り当てられていないことを確認します。
Figure13 : NSX-T インベントリのグループ設定での確認画面（抜粋）
Figure14 : NSX-T インベントリのタグ設定での確認画面（抜粋）
Figure15 : NSX-T インベントリの各仮想マシンでのタグ設定確認画面（抜粋）
次に、「 Win10-SBU02 」はインターネットへのアクセスが可能であることを確認します。
ここでは、VMware NSX-T の Web サイトと、インターネット上への ICMP で疎通を確認しています。
Figure16 : Win10-SBU02 の疎通確認のスクリーンショット（抜粋）
今回は、擬似的に eicar （アンチウイルス ソフトウェアの応答をテストするための公開されているファイル）のファイルを使用して検証を進めたいと思います。
eicar のサイトにアクセスをして、この archive ファイルを、わかりやすいようにデスクトップにダウンロードします。
Figure17 : Win10-SBU02 で「 eicar_com.zip 」のダウンロードを実行（抜粋）
archive ファイルをデスクトップ上に展開します。
Figure18 : Win10-SBU02 で「 eicar_com.zip 」を展開（抜粋）
展開しました。
Figure19 : Win10-SBU02 で「 eicar_com.zip 」をデスクトップに展開完了（抜粋）
展開してすぐ、CBCW からアラートが出ました。一秒遅れのように見えますが、展開した瞬間にアラートが出てきました。
Figure20 : Carbon Black Workload での検出画面（抜粋）
それでは、詳細調査のため、CBC でアラートを確認すると、どのプロセスで、どのような危険度で、なぜ検出したかがわかりますが、「 REMEDIATION 」を見ると、CBC の機能で隔離もできますが、より柔軟な隔離をネットワークで実行するには、ここにある「 Applying NSX Tag 」を選択することでNSX-T とのインテグレーションによる隔離を実行できます。
Figure21 : Carbon Black Cloud での検出結果の詳細確認①（抜粋）
Figure22 : Carbon Black Cloud での検出結果の詳細確認②（抜粋）
「 Applying NSX Tag 」を選択すると、どのTagを割り当てるかの選択を求められます。今回は、「 CB-NSX-Custom 」を選択します。
Figure23 : Carbon Black Cloud で NSX Tag の適用画面（抜粋）
適用されると、このように「 Status 」の横にこのような表示になり、「 Restricted by NSX tag 」とNSX-tag で制限されていることがわかります。
Figure24 : Carbon Black Cloud で NSX Tag の適用後の画面（抜粋）
もう一度、NSX-T で分散ファイアウォールの設定を確認すると、CBC にはアクセスできるがそれ以外はアクセスできないことを再確認します。
Figure25 : NSX Tag が適用されたポリシーを NSX-T で再確認（抜粋）
「インベントリ」→「グループ」を確認すると、先ほどまでどのワークロードもグループメンバーではありませんでしたが、「 Win10-SBU-02 」がメンバーとして割り当てられています。
Figure26 : NSX Tag適用後、NSX-Tでインベントリのグループで該当ワークロードが正しく適用されているか確認（抜粋）
「インベントリ」→「仮想マシン」を確認しても、「 Win10-SBU02 」にタグが付けられ、割りてられているタグを確認すると「 CB-NSX-Custom 」になっています。
Figure27 : NSX Tag 適用後、NSX-T でインベントリの仮想マシンで該当ワークロードが正しくタグを適用されているか確認（抜粋）
「インベントリ」→「タグ」も確認してみると、確かに「 CB-NSX-Custom 」が「 WIn10-SBU02 」に割り当てられていることがわかります。
Figure28 : NSX Tag 適用後、NSX-T でインベントリのタグで、該当ワークロードが正しくタグを適用されているか確認（抜粋）
「 Win10-SBU02 」でインターネットへのコネクティビティがなくなっていることを確認しました。これで他のワークロードにラテラル ムーブメントなどの横方向（東西方向）への展開を防御できる状態になりました。
Figure29 : NSX Tag 適用後、Win10-SBU02 がインターネットへのアクセスができなくなったことを確認
「 Win10-SBU02 」が隔離されている間に、フォレンジック調査などを実施します。ここでは、eicar を悪性ファイルとしていますので、該当する検体を探すと、デスクトップに2つの該当ファイルが確認できました。
Figure30 : Carbon Black Cloud からライブ レスポンスで確認（抜粋）
CBCの「ライブ レスポンス」では、このようにリモートからファイルの削除もできますので、今回は削除します。
Figure31 : Carbon Black Cloud からライブ レスポンスで悪性ファイルを駆除（抜粋）
「 Win10-SBU02 」のデスクトップから「 eicar_com.zip 」と「 eicar.com 」が駆除されていることが確認できます。
Figure32 : Win10-SBU02 から悪性ファイルが駆除されたことを確認（抜粋）
安全が確認できたら、隔離したワークロードを元のネットワークに戻します。
該当ワークロードである「 Win10-SBU02 」のサブメニューから「 Remove NSX Tags 」を選択し、実行するだけで全てのタグを取り除くことができます。
Figure33 : Carbon Black Cloud で NSX Tag を元に戻す（抜粋）
実行すると、タグが取り除かれたことが確認できます。
Figure34 : Carbon Black Cloud で NSX Tag を元に戻したことを確認（抜粋）
念の為、NSX-T のインベントリでも、タグが取り除かれていることを確認します。
Figure35 : NSX-T インベントリのグループ設定で NSX Tag が解除されたことを確認画面（抜粋）
Figure36 : NSX-T インベントリのタグ設定で NSX Tag が解除されたことを確認画面（抜粋）
Figure37 : NSX-T インベントリの仮想マシン設定で NSX Tag が解除されたことを確認画面（抜粋）
タグが取り除かれていることを確認できましたので、「 Win10-SBU02 」でも疎通を確認して、復旧できていることを確認できました。
Figure38 : Win10-SBU02 でインターネットへの疎通確認画面
[ 最後に ]
これからのセキュリティ運用には、これまで通り、検出能力の高さも重要ですが、「正しく検出」して「対処する」または「対処するために必要な十分な情報を提供する」が運用効率を左右する大きなポイントになってきます。
そのセキュリティを実行するポイントとして、ネットワークとエンドポイントの両方が、それぞれ補完し合う関係性にあるため、これらをAPIを使ってインテグレーションして利用したり、自動化を進めることでより大きな効果が期待できます。
ヴイエムウェアでは、これらを統合してXDR（ eXtended Detection and Response ）の提供を目指して現在、開発を進めていますので、今後のヴイエムウェアのセキュリティソリューションにご期待ください。
