WinCollect デプロイメントの計画

Windows IT グループおよび QRadar® グループと協力して、以下の質問に回答し、 WinCollect デプロイメントを計画します。

どの Windows エンドポイントからデータを収集する必要がありますか?

  • Windows オペレーティング・システムとは何ですか?
  • これらは「高重要度」サーバーですか。 高重要度サーバーの場合、通常、1 秒あたりに生成されるイベント数 (EPS) は高い値になり、サーバーの重要度も高くなります (ドメイン・コントローラーや Web サーバーなど)。
  • このエンドポイントに WinCollect エージェントをインストールすることは許可されていますか?
  • このエンドポイントには、より多くの構成変更が必要ですか。
    • POS デバイスは、通常 EPS は低く、更新もほとんど必要ありません。
    • ドメイン・コントローラーは、頻繁な構成変更が必要になる可能性があります (例えば、イベント・フィルターを変更して、どのイベント ID を収集するかを構成するなど)。
重要: WinCollect は、Microsoft によって End Of Life に移行された Windows のバージョンではサポートされません。 ソフトウェアの延長サポート終了日が過ぎていても、製品が期待どおりに機能することがあります。 ただし、 IBM®® は、古いオペレーティング・システムの WinCollect の問題を解決するためのコードや脆弱性の修正は行いません。

これらのエンドポイントはどこに置かれているか。

  • エンドポイントはすべて同じ地域にありますか。または地域をまたがって分散していますか。
  • それらのエンドポイントは同じドメイン、または子ドメインにありますか。またはネットワーク外にありますか。
  • それらの見通しはどの範囲ですか。
    • それらのエンドポイントは、どのコンソール、イベント・コレクター、またはイベント・プロセッサーを表示できますか。

どのようなデータを収集する必要があるか。

  • どのようなイベント・ログを収集する必要があるか。 標準の Windows ログ (アプリケーション、システム、セキュリティー) とは別に、Powershell や Sysmon などのアプリケーションやサービスのログからのデータが必要ですか? アプリケーション・ログおよびサービス・ログは、XPath を WinCollect エージェントに提供することによって収集されます。
    • XPath 照会は、Windows イベント・ログからカスタマイズ・イベントを取得するために使用する構造化 XML 式です。
  • イベント・ログに加えて収集することが望ましいログとして、以下のいずれかを指定します。
    • IIS
    • IAS
    • ISA
    • DHCP
    • DNS デバッグ
    • Exchange
    • NetApp
    • Juniper SBR
    • ファイル・フォワーダー (汎用ログ・ファイル・フォワーダー)
    ヒント: これらのログは、ローカル・エージェントまたはリモート・エージェントによって収集できます。

EPS はどの程度増えるか。

  • エンドポイントで生成されることになる EPS はどの程度ですか。
  • この EPS の処理には、イベント・プロセッサーまたはイベント・コレクターがいくつ必要になりますか。
    • ライセンスが交付されているイベント/秒 (EPS) はいくつか。
    • イベント・プロセッサーおよびイベント・コレクターが収集する EPS のレートはどの程度ですか。
  • エンドポイントで生成されることになる EPS の平均値とピーク値はどの程度ですか。
    • エンドポイントのピーク EPS を見積もることが重要です。 イベント・コレクターの処理能力が 40,000 EPS あるとして、午前 8 時に従業員が一斉にログインした場合、この EPS は 80,000 に急上昇するでしょうか。 する場合、それが続く期間はどれだけでしょうか。 これらのスパイクは QRadar アプライアンスで処理できますか? それとも、1 つ以上のイベント・コレクターに負荷を分散させる必要がありますか?
ヒント: EPS を制御するためのオプションの 1 つは、エージェントを特定の EPS にスロットルすることです。そのため、エージェントは、何を収集するかに関係なく、特定の数のイベントのみを送信します。 この場合、エージェントは超過になったイベントを EPS レートが減少するまでディスクにバッファリングします。 こうすることによって、イベント・コレクターに送信される可能性のある合計 EPS が、どの時点においても限定されます。 このオプションを選択する場合は、各エンドポイントで生成される EPS レートを把握する必要があります。 例えば、このサーバーでは 5 から 10 の EPS レートで送信できるため、ドメイン・コントローラーの EPS を 2 にスロットルしようとはしないはずです。 これを行うと、エージェントが送信するイベント数が常に、このサーバーが送信できる数を下回る状態になります。
エンドポイントで生成される可能性のある EPS の推定ボリュームを下表に示します。 これらのレートは、次のような要因によって変動します。
  • サーバー（ドメイン・コントローラー）と通信しているエンドポイントがいくつあるか
  • 構成されている監査ログのレベル
  • インストールされ、イベントを生成しているアプリケーションの数
表 1. エンドポイントの標準的な EPS レート
エンドポイント・タイプ 平均 EPS ピーク EPS
従業員のエンドポイント (デスクトップとラップトップ) 0.005 0.05
Windows ドメイン・サーバー 5 - 10 350
Web サーバー (IIS、Apache) 5 - 10 350
Windows DNS サーバー 0.5 5
データベース・サーバー 0.5 10
ヒント: エンドポイントで生成される EPS のサンプルを取得することをお勧めします。

管理対象構成をインストールするのか、スタンドアロン構成をインストールするのか。

WinCollect エージェントは、 QRadarによって管理されている環境にスタンドアロン・エージェントとしてインストールすることも、その両方を組み合わせてインストールすることもできます。

管理

WinCollect エージェントは、 QRadarによって管理されます。 コードの更新および構成変更は、 QRadar コンソールによって、Windows エンドポイントにインストールされているエージェントに提供されます。 このオプションでは、Windows エンドポイントと QRadarの間のポート 8413 を介した TCP 通信が必要です。 お客様は、 QRadar コンソールでログ・ソースを追加することによって、エージェントが収集するデータを管理します。

エージェントは、 QRadarに syslog データを送信するために、ポート 514 UDP または TCP へのアクセスも必要とします。 管理対象の制限を超えない小規模なデプロイメントでは、お客様は通常、 WinCollect コードおよび構成の変更の制御を維持するために管理対象インストールを選択します。

現在の QRadar 管理の制限
QRadarを使用して WinCollect エージェントおよび関連するログ・ソースを管理する場合の推奨限度は、コンソール/管理対象ホストごとに 500 エージェントです。 例えば、管理対象モードで 1,200 のエンドポイントに WinCollect をインストールするには、コンソールとイベント・コレクター/プロセッサーの間でエンドポイントを分割します。
  • 200 エンドポイント - コンソール
  • 500 エンドポイント - イベント・プロセッサー/コレクター 1
  • 500 エンドポイント - イベント・プロセッサー/コレクター 2

スタンドアロン

スタンドアロン・インストールでは、 WinCollect エージェントは QRadarによって管理されません。 エージェントと QRadar との間の通信は、ポート 514 を介した TCP/UDP を介してのみ行われます。 これらのエージェントをアップグレードする場合、エージェントを再インストールするか、パッチ・インストーラーを使用してコードを更新します。 現在、パッチ・インストーラーは、コード更新および WinCollect 構成コンソールを含む、 IBM によって提供される別個のインストールです。

構成を変更するには、 WinCollect 構成コンソール GUI ツールをインストールするか、エージェントの構成を直接変更する必要があります。 大規模なデプロイメントの場合、通常お客様はスタンドアロンのインストール方式を選択します。これにより、BigFix か Microsoft System Center Configuration Manager を使用してインストールと構成を制御できます。

構成変更はテンプレートを使用して行えますので、ファイル・ディレクトリーを編集せずに Agent-Config.xml に対して変更を加えることができます。 詳しくは、「 https://www.ibm.com/community/qradar/2019/03/14/wincollect-7-2-8-stand-alone-change-configuration-with-templates/」を参照してください。

注: WinCollect 構成コンソール GUI には .NET 3.5が必要です。

イベントをどのように収集するか。

ローカル収集

サポートされる最大 EPS: 5,000 EPS

WinCollect エージェントは、管理対象構成またはスタンドアロン構成のいずれかでエンドポイントにインストールされ、ローカル・エンドポイントから Windows イベント・ログを収集します。 この収集方式は、使用頻度の高い、またはリソース量に制限のある Windows ホスト (例えば、ドメイン・コントローラー) で使用できます。 通常、ドメイン・コントローラーのイベント/秒 (EPS) レートはメンバー・サーバーより高くなります。

また、資格情報の管理や、エンドポイントがオンラインになるときのエンドポイントの追加や除去に煩わされたくない場合にも、ローカル収集を使用できます。 エンドポイントがネットワークに追加されたら、手動で、または BigFix または Microsoft System Center Configuration Manager (SCCM) ソリューションを使用して、エンドポイントにエージェントをインストールする必要があります。 新しいエンドポイントのデプロイ時にエージェントが稼働状態になるよう、エージェントをマスター・イメージに組み込むこともできます。
注: WinCollect エージェントがローカル・ホストからイベントを収集する場合、イベント収集サービスは、ローカル・システム・アカウントの資格情報を使用してイベントを収集および転送します。

リモート収集

サポートされる最大 EPS: 500 のリモート・エンドポイント全体で、合計 2,500 イベント

WinCollect エージェントは、 管理対象構成またはスタンドアロン構成のいずれかで エンドポイントにインストールされ、ローカル・エンドポイントおよび 1 つ以上のリモート・エンドポイントから Windows イベント・ログを収集します。 リモート収集の場合、リモート・イベント・ログへのアクセス権限を持つユーザーのログイン資格情報を入力する必要があります。 他の Windows エンドポイント・システムをリモートでポーリングする WinCollect エージェントは、以下のリモート・ポートにアクセスする必要があります。
表 2. リモート収集に使用されるポート
ポート プロトコル 使用法
135 TCP Microsoft エンドポイント・マッパー
137 UDP NetBIOS ネーム・サービス
138 UDP NetBIOS データグラム・サービス
139 TCP NetBIOS セッション・サービス
445 TCP Windows 共有を使用するファイル転送のための Microsoft ディレクトリー・サービス
49152-65535 TCP TCP/IP 用のデフォルトの動的ポート範囲
ヒント: Windows サーバーによっては、TCP 用に異なるデフォルトの動的範囲が設定されている場合があります。 サーバーのデフォルトの範囲を確認するには、以下のコマンドを使用します。
netsh int ipv4 show dynamicport tcp
注: Mセブン・プロトコルはポート 445 を使用します。 NETBIOS のポート (137 から 139) は、ホスト名の解決に使用できます。 WinCollect エージェントが MSEVEN6 を使用してリモートのイベント・ログをポーリングする場合、リモート・コンピューターとの最初の通信はポート 135 (動的ポートマッパー) を通じて行われ、ここで接続が動的ポートに割り当てられます。 動的ポートのデフォルトのポート範囲は、ポート 49152 からポート 65535 です。 これらの動的ポート上でのトラフィックを許可するには、ポーリング対象の Windows サーバーで以下の 2 つのインバウンド・ルールを有効化し、許可します。
  • リモート イベントのログ管理 (RPC)
  • リモート イベント ログ管理 (RPC-EPMAP)
MSEVEN6 プロトコルでは、リモート・コンピューター上のライブおよびバックアップの両方のイベント・ログからイベントを読み取るための RPC メソッドが公開されています。 このプロトコルは元々 Windows Vista 用に提供されたもので、MSEVEN に代わるプロトコルです。
リモート・ポーリング時のチューニング考慮事項
リモート・ポーリング用のプロファイルのチューニングについては、 ログ・ソースのイベント・レートおよびチューニング・プロファイルを参照してください。

Windows Event Forwarding (WEF)

WinCollect エージェントは、標準装備の Microsoft 関数 Windows Event Forwarding (WEF) を使用できます。 WEF は、組織内のデバイス上の操作可能イベント・ログ (つまり、セキュリティー・イベント・ログ) または管理イベント・ログ (つまり、Sysmon イベント・ログ) を読み取り、選択したイベントを Windows イベント・コレクター (WEC) サーバーに転送します。 WEC サーバーに WinCollect エージェントをインストールして、転送されたイベント・ログから収集することができます。 これらの転送されたイベントを QRadarに送信する前に、エージェントはそれらのイベントをパッケージ化して、各エンドポイントから直接送信されたように表示されるようにします。 QRadar Windows イベント・コレクター (WEC) サーバーにログを送信するエンドポイントごとに、ログ・ソースを自動的に作成します。
ヒント: WinCollect V7.2.9 以降では、すべてのイベントを単一のログ・ソースに送信するように指定できます。
WEF のハイライト:
  • WEC サーバーとの間でイベントをプッシュ/プルできる
  • GPO によって構成可能
  • Windows リモート管理 (Kerberos) を使用して、中間者を防止します。
  • 特定のイベント・ログとイベント ID をターゲットとすることが推奨される (Xpath を使用)
  • イベントは 1 つの中央イベント・ログ・ファイル (EVTX ファイル) に収集され、WinCollect がそのファイルをポーリングできる
Windows イベント転送について詳しくは、以下を参照してください。