Skip navigation
Log in to create and rate content, and to follow, bookmark, and share content with other members.

アップグレード ガイド11.5：アップグレード後のタスク

Document created by RSA Information Design and Development Employee on Dec 7, 2020•Last modified by RSA Information Design and Development Employee on Dec 7, 2020
Version 2Show Document
  • Comment • 0
  • View in full screen mode
 

11.5にアップグレードした後、NetWitness Platformのユーザ インタフェースではいくつかの新機能が有効になります。管理タスクは右上隅にアイコンとして統合され、管理、構成、通知、ジョブ、ユーザ環境設定が一か所にまとめられました。次の図は、新しい最上位のナビゲーション メニューを示しています。
最上位メニュー

デフォルトのホームページは、スプリングボードです。設定を変更して、ホーム ページを別のビューにすることができます。詳細については、『NetWitness Platformスタート ガイド』の「NetWitness Platformの基本ナビゲーション」を参照してください。

ご使用のホストのタスクを完了してください。

全般

（オプション）NAT経由のIPアドレスを構成する

NW Serverホストに接続するためにNAT経由のIPアドレスを必要とするホスト（VLCなど）がある場合は、次の手順でホスト構成を更新する必要があります。

  1. コンソールまたはSSHを使用して、NAT経由のIPアドレスの使用が必要なホストにログインします。
  2. 次のコマンドを実行します。
    nw-manage --enable-nat-usage
  3. NW ServerのNAT IPアドレスを設定するため、次の手順を実行します。
    1. コンソールまたはSSHを使用して、NW Serverにログインします。
    2. 次のコマンドを実行します。
      nw-manage -update-host --host-id <UUID of NW Server> --ipv4-public <NAT IP of NW Server>

      3. 注： nw-manage --list-hostsを実行すると、ホストのUUIDと現在のNAT IPアドレスを確認できます。

（オプション - ウォームスタンバイ ホストの場合のみ）ウォームスタンバイ ホストのセカンダリIPアドレスを登録する

次の手順を実行する前に、ウォームスタンバイ サーバを11.5にアップグレードしておく必要があります。

  1. コンソールまたはSSHを使用して、NW Serverにログインします。
  2. 次のコマンドを実行します。
    nw-manage --add-nws-secondary-ip --ipv4 <ip address of Warm/Standby Server>

    3. 注： フェールオーバー時に他のホストからアクセスできるように、ウォームスタンバイ サーバにNAT経由のIPアドレス（IPv4パブリック）が必要な場合は、次のコマンドを実行してNAT IPアドレスも登録する必要があります：nw-manage --add-nws-secondary-ip --ipv4 <NAT-based IP address of Warm Standby Server>

  3. 次のコマンドを実行して、ウォームスタンバイ ホストのIPアドレスの値が正しいことを確認します。
    nw-manage --get-nws-secondary-ip

/etc/hosts.userから古いホスト エントリーを削除する

NW Serverホストまたはコンポーネント ホストをアップグレードした後で、/etc/hosts.userファイルの内容を確認し、使われていない古いホスト エントリーが含まれていないか確認します。/etc/hosts.userファイルには、NetWitness Platformによって管理されていないシステムやユーザが追加したエントリーが含まれます。ただし、/etc/hosts.userのエントリーは、NetWitness Platformが生成するホスト マッピングとマージされ、/etc/hostsを作成および更新するために使用されます。NetWitness Platformが生成するマッピングとの競合を回避し、IPアドレスの変更による接続エラーの発生を回避するため、NetWitness PlatformホストのループバックIPアドレス以外のエントリーが/etc/hosts.userに含まれている場合は、削除することを推奨します。

/etc/hosts.userを更新した後で、次のコマンドを実行してシステムをリフレッシュする必要があります。
nw-manage --refresh-host --host-key <ID, IP, hostname or display name of host>

DNSサーバを再構成する

デフォルトでは、11.4以前のバージョンからアップグレードされたコンポーネント ホストには、NW Serverと同じシステムDNSサーバが構成されます。このコンポーネント ホストで別のシステムDNSアドレスが必要な場合の手順については、『システム メンテナンス ガイド』の「ホスト ネットワーク構成の変更」を参照してください。

サービスの再起動、データ収集、データ集計の確認

サービスが再起動され、データを収集していることを確認します（これは、自動開始が有効になっているかどうかによって異なります）。

必要に応じて、次のサービスでデータの収集と集計を再開します。

  • Decoder
  • Log Decoder
  • Broker
  • Concentrator
  • Archiver

ネットワーク収集の開始

  1. NetWitness Platformメニューで、（管理）＞［サービス］に移動します。
    ［サービス］ビューが表示されます。
  2. Decoderサービスを選択します。

  3. （アクション）で、［表示］＞［システム］を選択します。

  4. ツールバーでをクリックします。

ログ収集の開始

    1. NetWitness Platformメニューで、（管理）＞［サービス］に移動します。
      ［サービス］ビューが表示されます。
    2. Log Decoderサービスを選択します。
    3. （アクション）で、［表示］＞［システム］を選択します。
    4. ツールバーでをクリックします。

    • 集計の開始

    1. NetWitness Platformメニューで、（管理）＞［サービス］を選択します。

      ［サービス］ビューが表示されます。

    2. Concentrator、Broker、Archiverの各サービスに対して、以下の手順を実行します。

      1. サービスを選択します。
      2. （アクション）で、［表示］＞［構成］を選択します。
      3. ツールバーでをクリックします。

    Event Stream Analysis（ESA）

    注： 混在モードは、NetWitness Platformバージョン11.5以降のESAホストではサポートされていません。NetWitness Server、ESAプライマリ ホスト、ESAセカンダリ ホストがすべて、同じNetWitness Platformバージョンである必要があります。

    ESAに必要なアップグレード後のタスクはありません。ESAのトラブルシューティングについては、「ESAトラブルシューティング情報」を参照してください。

    Endpoint、UEBA、Liveコンテンツ ルールのサポートを追加する場合は、ESA Correlationサービスのmulti-valuedパラメータおよびsingle-valuedパラメータを更新して、必要なメタ キーをすべて追加する必要があります。アップグレード中にこれらの調整を行う必要はありません。後で都合のよいタイミングで調整を行うことができます。詳細と手順については、『ESA構成ガイド』の「必須の複数値および単一値のメタ キーに合わせてESAルールを更新」を参照してください。

    新ヘルス モニタ

    注： 11.5の新ヘルス モニタは、11.4.x.xの次世代ヘルス モニタ（ベータ）を置き換えます。

    Liveを使用して新ヘルス モニタのコンテンツを導入する

    バージョン11.4.x.xから11.5にアップグレードした後、新ヘルス モニタのコンテンツは更新されていません。最新（デフォルト）のコンテンツを使用するには、NetWitness Liveサービスを使用してコンテンツを導入する必要があります。

    注： NetWitness Liveサービスからコンテンツを導入すると、既存のコンテンツが上書きされるため、導入前に11.4.x.xのヘルス モニタ コンテンツのコピーを作成しておくことを推奨します。

    1. NetWitness Platform UIにログインします。

    2. （構成）＞［LIVEコンテンツ］をクリックします。

    3. ［検索条件］パネルの［リソース タイプ］で以下を選択します。

      • Health and Wellness Dashboards
      • Health and Wellness Monitors

    4. ［検索］をクリックします。

    5. ［一致するリソース］ビューで、導入するリソースの左側にあるチェックボックスをオンにします。

    6. ［一致するリソース］パネルのツールバーで、をクリックします。

    7. ［導入ウィザード］＞［リソース］タブで、［次へ］をクリックします。

    8. ［サービス］タブで、Metrics Serverサービスを選択します。

    9. ［次へ］をクリックします。

    10. ［導入］をクリックします。
      ［導入］ページが表示されます。選択したサービスにリソースが正常に導入されると、進捗バーが緑色に変わります。

    11. ［閉じる］をクリックします。

    （オプション）サービス構成ドキュメントの新ヘルス モニタ ホストのUUIDを更新する

    nw-shellからset-config APIを使用して新ヘルス モニタのサービスを構成し、NetWitness Platformのバージョンを11.4.x.xから11.5にアップグレードする場合は、新ヘルス モニタがインストールされているホストのIPをUUIDに更新する必要があります。

    1. SSHでNetWitness Serverに接続します。

    2. 次のコマンドを使用して、新ヘルス モニタがインストールされているホストのUUIDを確認します。
      orchestration-cli-client --list-hosts

      このコマンドは、NetWitness Platformホストと各ホストのUUIDを一覧表示します。新ヘルス モニタがインストールされているホストのUUIDを記録しておきます。

    3. 次のコマンドを使用して、set-configが呼び出されるサービスを特定します。
      mongo localhost/metrics-server -u deploy_admin -p <deployment_password> --authenticationDatabase admin --eval 'db.metric_config.find({ "createdBy": { $ne: "system" }})'
      このコマンドは、set-configが呼び出されるサービスの構成ドキュメントを一覧表示します。

    注： サービスのドキュメントが表示されない場合は、アップグレードの前にサービスが構成されていないことを意味するため、残りのステップを無視して構いません。

    1. 構成ファイルのサービス ドキュメントの「host」フィールドのIPアドレスを、新ヘルス モニタがインストールされているホストのUUIDに置き換えます。
      たとえば、次のようにホストのIPアドレスをUUIDに変更します。

    "host" : “e086511c-121c-4e66-95a3-e87e27b12acb”

    1. 次のコマンドを使用して、nw-shellにログインします。
      nw-shell
    2. 次のコマンドを使用して、metrics-serverサービスに接続します。
      connect --service metrics-server

    3. ログイン コマンドを入力します。
      login

    4. adminのユーザ名とパスワードを入力します。
    5. /rsa/metrics/elastic/set-configに移動し、次のコマンドを使用して構成ファイルを呼び出します。
      invoke --file /<absolute_path_of_service_config_file>

    （オプション）新ヘルス モニタをアンインストールする

    新ヘルス モニタをアンインストールするには、次の手順を実行します。

    1. NetWitness Serverホストのバックアップを作成します。詳細については、『NetWitnessリカバリ ツール ユーザ ガイド』の「災害復旧（バックアップとリストアの手順）」を参照してください。

      nw-recovery-tool --export --dump-dir /some/folder --category AdminServer --category Search

      注： NetWitness Serverに新ヘルス モニタがインストールされていない場合は、新ヘルス モニタがインストールされているホストのバックアップを作成する必要があります。

    2. インストールまたはアップグレードが進行中でないことを確認し、NetWitness Serverホスト上のOrchestration Serverを停止します。

      systemctl stop rsa-nw-orchestration-server

    3. 新ヘルス モニタのサービス カテゴリー（「Search」）をホストから削除します。

      1. SSHでNetWitness Serverに接続します。

      2. 次のコマンドを使用して、新ヘルス モニタがインストールされているホストの詳細を取得します。
        mongo localhost/orchestration-server -u deploy_admin -p <deploy_admin-password> --authenticationDatabase admin --eval 'db.host.find({ "installedServices": /.*Search.*/i })'

        出力例

        { "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8", "hostname" : "10.10.10.11", "ipv4" : "10.10.10.11", "ipv4Public" : "", "displayName" : "adminserver", "version" : { "major" : 11, "minor" : 5, "servicePack" : 0, "patch" : 0, "snapshot" : false, "rawVersion" : "11.5.0.0" }, "lastFailedRefreshAttempt" : NumberLong(0), "refreshAttemptDelayFactor" : 0, "thirdParty" : false, "installedServices" : [ "Search", "AdminServer" ], "meta" : { "node-zero" : true }, "_class" : "com.rsa.asoc.orchestration.host.HostEntity" }

      3. installedServicesから「Search」を削除します。

      重要： 他のカテゴリー名は削除しないでください。

      1. <LIST-OF-CATEGORIES-EXCEPT-SEARCH>は、前の手順で取得した既存の全インストール済みサービス（「Search」以外）をカンマで区切って二重引用符で囲んだリストに置き換えます。
        mongo localhost/orchestration-server -u deploy_admin -p <deploy_admin-password> --authenticationDatabase admin --eval 'db.host.update({ "_id" : "<hw-node-uuid>" },{$set: {"installedServices" : [ <LIST-OF-CATEGORIES-EXCEPT-SEARCH> ]}})'

        例
        mongo localhost/orchestration-server -u deploy_admin -p netwitness --authenticationDatabase admin --eval 'db.host.update({ "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8" },{$set: {"installedServices" : [ "AdminServer" ]}})'

        出力例

        MongoDB shell version v4.0.19

        connecting to: mongodb://localhost:27017/orchestration-server?authSource=admin&gssapiServiceName=mongodb

        Implicit session: session { "id" : UUID("04e32380-347e-4b7d-a63e-a094536d7242") }

        MongoDB server version: 4.0.19

        WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })

      2. 更新されたホスト レコードのinstalledServices から「Search」カテゴリーが削除されていることを確認します。

        mongo localhost/orchestration-server -u deploy_admin -p <deploy_admin-password> --authenticationDatabase admin --eval 'db.host.find({ "_id" : "<hw-node-uuid>" })'

        例

        mongo localhost/orchestration-server -u deploy_admin -p netwitness --authenticationDatabase admin --eval 'db.host.find({ "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8" })'

      注： 不整合があると、回復不能なエラーが発生する可能性があります。

      出力例

      { "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8", "hostname" : "10.10.10.11", "ipv4" : "10.10.10.11", "ipv4Public" : "", "displayName" : "adminserver", "version" : { "major" : 11, "minor" : 5, "servicePack" : 0, "patch" : 0, "snapshot" : false, "rawVersion" : "11.5.0.0" }, "lastFailedRefreshAttempt" : NumberLong(0), "refreshAttemptDelayFactor" : 0, "thirdParty" : false, "installedServices" : [ "AdminServer" ], "meta" : { "node-zero" : true }, "_class" : "com.rsa.asoc.orchestration.host.HostEntity" }

    4. 新ヘルス モニタ サービスを停止します。

      systemctl stop rsa-nw-metrics-server elasticsearch opendistro-performance-analyzer kibana

    5. 新ヘルス モニタ サービスを無効にします。

    systemctl disable rsa-nw-metrics-server elasticsearch opendistro-performance-analyzer kibana

    1. 次のコマンドを使用して、新ヘルス モニタ パッケージをアンインストールします。

      yum erase -y rsa-nw-metrics-server opendistroforelasticsearch opendistroforelasticsearch-kibana

      注： rsa-nw-shell（Metrics Serverとともにインストールされる）は共有パッケージであるため、削除しないでください。

    2. 構成フォルダまたはファイルを削除します。
      • /etc/netwitness/metrics-server
      • /etc/netwitness/platform/elasticsearch
      • /etc/netwitness/platform/nodeinfo/metrics-server
      • /etc/netwitness/platform/nodeinfo/elasticsearch-open-distro
      • /etc/netwitness/platform/nodeinfo/kibana-open-distro
      • /etc/systemd/system/rsa-nw-metrics-server.service.d
      • /etc/systemd/system/elasticsearch.service.d
      • /etc/pki/nw/service/bootstrap/metrics-server.completed
      • /etc/pki/nw/service/rsa-nw-metrics-server-cert.pem
      • /etc/pki/nw/service/rsa-nw-metrics-server.chain
      • /etc/pki/nw/elastic
      • /etc/pki/nw/kibana
      • /var/log/netwitness/metrics-server
      • /var/log/kibana
      • /etc/collectd.d/rsa-metrics-server.conf
      • /etc/logrotate.d/kibana
      • /etc/elasticsearch
      • /etc/kibana
      • /var/lib/elasticsearch
      • /var/lib/kibana
      • /var/netwitness/elasticsearch

    3. NetWitness ServerでOrchestration Serverを起動します。
      systemctl start rsa-nw-orchestration-server

    4. 新ヘルス モニタを installedServiceから登録解除します。

      1. metrics-server、elasticsearch-open-distro、kibana-open-distroのサービスIDを見つけます

        注： 正しいホストのサービスIDを探してください。UEBAホストではelasticまたはkibanaの登録を解除しないでください。

        orchestration-cli-client --list-services | grep <hw-node-IP-address>

        出力例

        ID=50082d04-320c-4ce2-8379-00f38ae2d1df, NAME=metrics-server, HOST=192.168.1.2:7018, TLS=true

        ID=530ff46a-8793-4e8e-be9c-742193d1705a, NAME=elasticsearch-open-distro, HOST=192.168.1.2:9200, TLS=true

        ID=4bad6ea8-e3a4-46ab-a342-34356bea65bb, NAME=kibana-open-distro, HOST=192.168.1.2:5601, TLS=true

        ... (other services) ...

      2. 前述のコマンドで返されたmetrics-server、elasticsearch-open-distro、およびkibana-open-distro（新ヘルス モニタ ホストに関連づけられている）のサービスIDを削除します。

        orchestration-cli-client --remove-service --id <metrics-server-service-id>

        orchestration-cli-client --remove-service --id <elasticsearch-open-distro-service-id>

        orchestration-cli-client --remove-service --id <kibana-open-distro-service-id>

      3. サービスが削除されたことを確認します。

        orchestration-cli-client --list-services | grep <hw-node-IP-address>

    5. UEBAを除くすべてのホストで、metricbeatを停止して無効にします。

      systemctl stop metricbeat

      systemctl disable metricbeat

      注： UEBAのないNetWitness Platformの場合、saltを使用してすべてのホストでmetricbeatを停止および無効化できます。
      salt '*' cmd.run 'systemctl stop metricbeat && systemctl disable metricbeat'

    6. （オプション） - （同じホストか他のホストかにかかわらず）新ヘルス モニタを再インストールしない場合は、metricbeatパッケージと構成を削除することもできます。
      1. アンインストールするパッケージ：
        metricbeat
      2. アンインストールするサービス構成：

        • /etc/metricbeat

        • /var/log/metricbeat

        • mongo account

        • systemd configuration

    1. 新ヘルス モニタホストをリフレッシュします。
      nw-manage --refresh-host --host-key <node-ip>
      新ヘルス モニタ サービスがインストールまたは実行されておらず、metricbeatサービスが新ヘルス モニタホストでアクティブになっていないことを確認してください。

    2. 新ヘルス モニタを別のホストに再インストールしない場合は、UIホスト（NetWitness ServerホストとAnalyst UI）をリフレッシュしてNGNIXを更新する必要があります。

      nw-manage --refresh-host --host-key <node-ip>

    注： 新ヘルス モニタをアンインストールした後で、新ヘルス モニタを再びインストールする場合は、『導入ガイド』の「新ヘルス モニタ」を参照してください。

    Investigate

    （オプション - カスタム ロールの場合のみ）カスタム ユーザ ロールのinvestigate-server権限の調整

    バージョン11.5にアップグレードした後、［調査］ビューを使用するアナリスト（およびその他）の標準提供ユーザ ロールでは、investigate-server.event.filter権限が有効になりますが、カスタム ユーザ ロールの権限はアップグレード プロセスでは有効になりません。この権限が有効になっていないカスタム ユーザ ロールを割り当てられたユーザには、［イベントの絞り込み］パネルが表示されません。このパネルは、メタデータをドリルダウンできる11.5の新しいパネルです。

    注： バージョン11.3.x.x以前からアップグレードする場合、［調査］ビューを使用するアナリストの標準提供ユーザ ロールでは、バージョン11.4で追加された別の3つの権限も有効になりますが、カスタム ユーザ ロールの権限はアップグレードプロセスでは有効になりません。これらの権限を持たないカスタム ユーザ ロールを割り当てられたユーザ には、［調査］メニューに［ナビゲート］ビューと［レガシー イベント］ビューが表示されません。カスタム ユーザ ロールで有効にする必要がある3つの権限は次のとおりです。
    investigate-server.columngroup.read、investigate-server.metagroup.read、investigate-server.profile.read

    ユーザ ロールの権限を有効にするには、次の手順を実行します。

    1. （管理）＞［セキュリティ］に移動し、［ロール］タブをクリックします。
    2. 編集する必要があるカスタム ユーザ ロールを選択し、（編集アイコン）をクリックします。
    3. ［ロールの編集］ダイアログで、次の4つの権限が有効になっていることを確認します。
      investigate-server.event.filter
      investigate-server.columngroup.read
      investigate-server.metagroup.read
      investigate-server.profile.read
    4. ［保存］をクリックして、変更内容を保存します。カスタム ユーザ ロールを割り当てられたアナリストがNetWitness Platformにログインすると、変更が有効になります。

    Respond

    これらのタスクは、ESAプライマリ ホストを11.5にアップグレードした後で実行する必要があります。

    注： NW Server（Respond Serverサービスを含む）をアップグレードした後、ESAプライマリ ホストを11.5にアップグレードするまで、Respond Serverサービスは自動的に再有効化されません。Respondのアップグレード後のタスクは、Respond Serverサービスがアップグレードされ、有効な状態になってから実行する必要があります。

    （オプション）Respondサービスの統合ルール スキーマのカスタム キーをリストアする

    注： インシデント統合ルール スキーマを手動でカスタマイズしていない場合は、このタスクを実行する必要はありません。

    11.xのgroupBy句で使用するためにvar/lib/netwitness/respond-server/data/aggregation_ rule_schema.jsonファイルにカスタム キーを追加した場合は、/var/lib/netwitness/respond-server/data/aggregation_rule_schema.jsonファイルを変更して、自動バックアップ ファイルからカスタム キーを追加します。

    バックアップ ファイルは/var/lib/netwitness/respond-server/dataにあり、次の形式になります。
    aggregation_rule_schema.json.bak-<time of the backup>

    （オプション）カスタマイズされたRespondサービスの正規化スクリプトをリストアする

    注： アラート正規化スクリプトを手動でカスタマイズしていない場合は、このタスクを実行する必要はありません。
    この手順は、11.3.xから11.5へのアップグレードに適用されます。11.4から11.5.xにアップグレードする場合、カスタマイズは個別のcustom_normalizeスクリプト ファイルに追加され、アップグレード中に上書きされることはありません。このため、正規化スクリプト ファイルはバックアップされません。

    カスタマイズの内容がバージョン更新により上書きされるのを防ぐため、NetWitness Platform 11.4以降では、カスタム正規化スクリプト ファイルを利用できます。カスタム ロジックはcustom_normalize_<alert type>.jsファイルに追加します。

    1. /var/lib/netwitness/respond-server/scripts.bak-<timestamp>ディレクトリにあるバックアップされたRespondサーバの正規化スクリプトからカスタム ロジックを取り出します。<timestamp>はバックアップが完了した時刻です。
      data_privacy_map.js
      normalize_alerts.js
      normalize_core_alerts.js
      normalize_ecat_alerts.js
      normalize_ma_alerts.js
      normalize_ueba_alerts.js
      normalize_wtd_alerts.js
      utils.js

    2. /var/lib/netwitness/respond-server/scriptsディレクトリにある11.4以降の新しいスクリプト ファイルを編集して、バックアップ ファイルから取得したロジックを追加します。正規化スクリプトをカスタマイズする場合は、custom のプレフィックスが付いた正規化ファイルに追加します。
      data_privacy_map.js
      custom_normalize_alerts.js
      custom_normalize_core_alerts.js
      custom_normalize_ecat_alerts.js
      custom_normalize_ma_alerts.js
      custom_normalize_ueba_alerts.js
      custom_normalize_wtd_alerts.js
      utils.js

      たとえば、custom_normalize_core_alerts.jsは、ESA用のカスタム ロジックを追加するための正規化スクリプトです。このjavaスクリプト ファイルには、パラメータにheaders、rawAlert、normalizedAlertを持つ関数「normalizeAlert」があります。変数「normalized」は、正規化されたイベントのリストが埋め込まれたイミュータブルなコピー オブジェクトです。そのため、イベントに対してカスタム メタ キーを構成している場合は、「normalized.events」を反復的に処理して、適切なメタ キーに「rawAlert.events」オブジェクトから値を取得する必要があります。次にサンプル コードを示します。

       

      normalizeAlert = function (headers, rawAlert, normalizedAlert) {

      // normalizedAlert is the immutable copy of ootb normalizer alert, make sure you use

      // normalized object to update/set the values in your scripts

      var normalized = Object.assign(normalizedAlert);

      var custom_events;

      if(normalized.events !== undefined) {

      custom_events = normalized.events;

       

      } else {

      custom_events = new Array([]);

       

      }

      for (var i = 0; i < rawAlert.events.length; i++) {

      custom_events[i].legalentity=Utils.stringValue(rawAlert.events[i].isgs_legalentity);

      custom_events[i].companycode=Utils.stringValue(rawAlert.events[i].isgs_companycode);

       

      }

       

      if(normalized.events === undefined){

      normalized.events = custom_events;

      }

      return normalized;

      };


      また、normalize_alerts.jsなど、標準提供のRespond正規化スクリプト ファイルを参照することもできます。詳細については、『NetWitness Respond構成ガイド』の「カスタムRespondサーバ アラート正規化の構成」を参照してください。

    リファレンスLog Decoder

    すべての機能を利用するには、リファレンスLog Decoderが11.5以降である必要があります。リファレンスLog Decoderをセットアップしていない場合は、このタスクを実行する必要はありません。詳細については、『ログ パーサ カスタマイズ ガイド』を参照してください。

    Windows Log Collector

    Windows Log CollectorのUUIDを更新する

    11.5へのアップグレード後、お使いの環境に構成されている各Windows Log Collectorに対して、NW Serverで次のコマンドを実行します。

    wlc-cli-client --update-to-uuid --host <WLC host address>

    User Entity Behavior Analytics

    重要： すべてのUEBA環境では、アップグレード プロセスを完了するために追加の手順が必要となります。11.3.0.0から11.3.2.0、さらに11.5.0.0にアップグレードする場合は、11.5.0.0にアップグレードする前に、『アップグレード ガイド（11.3.2.0）』に記載されたUEBAの手順を実行する必要があります。

    注： 11.4.xから11.5.0.0にアップグレードする場合は、現在の処理スキーマを更新しない限り、過去28日間についてUEBAシステムを再実行する必要はありません。11.4.xより前のバージョンから11.5.0.0にアップグレードすると、UEBAシステムは自動的に再実行します。

    1. （仮想マシンの場合のみ）VMのAirflow並列処理を更新します。
      UEBAシステムがVMで実行されている場合は、UEBAホストでrootとして次のコマンドを実行して、Airflowの並列処理を64に更新します。

      sed -i "s|parallelism = 256|parallelism = 64|g" /var/netwitness/presidio/airflow/airflow.cfg

    2. UEBAマシンから次のコマンドを使用して、UEBA構成を更新します。
      python /var/netwitness/presidio/airflow/venv/lib/python2.7/site-packages/presidio_workflows-1.0-py2.7.egg/presidio/resources/rerun_ueba_server_config.py

    1. （オプション）次のスクリプトを使用して、UEBA処理スキーマを更新します。

      python /var/netwitness/presidio/airflow/venv/lib/python2.7/site-packages/presidio_workflows-1.0-py2.7.egg/presidio/utils/airflow/reset_presidio.py script.

      UEBA開始日を現在の日付より28日前に設定することを推奨します。TLSデータの処理を予定しているUEBAシステムの場合は、開始日が現在の日付より14日以上前の日付に設定されていることを確認する必要があります。

      詳細については、『UEBA構成ガイド』の「reset-presidioスクリプト」を参照してください。

    2. AirflowのDAGアップグレードを実行します。

      • Airflowのメイン ページhttps://<UEBA-host-name>/adminに移動します。

      • adminのユーザ名とパスワードを入力します。

      • presidio_upgarde_dag_from_<previous_version> to_11.5.0.0で［Play］をクリックします。

        注： アップグレード中は、DAGアップグレード行の横に緑色の丸が表示されます。アップグレード プロセスが正常に完了した場合は、明るい緑色の円が緑色に変わります。アップグレード プロセスが失敗した場合は、明るい緑色の円が赤に変わります。

    3. 適切な「Boot Jar Pools」スロットを設定します。

      • 物理アプライアンス：spring_boot_jar_poolスロットの値を18に更新します。

      • 仮想アプライアンス：spring_boot_jar_poolおよびretention_spring_boot_jar_poolスロットの値を5に更新します。
        「Spring Boot Jar Pools」スロットを更新するには、Airflowのメイン ページに移動し、最上部のバーにある［Admin］タブをタップして、［Pools］をタップします。
      1. Airflow UIにアクセスするには、https://<UEBA_host>/adminに移動して認証情報を入力します。
        ユーザ：admin
        パスワード：導入管理者のパスワード
      1. プールの鉛筆マークをクリックして、スロットの値を更新します。

     

    • spring_boot_jar_pool を編集して、スロットの数量を5に更新します。

       

      ライセンス

      アップグレード後、使用量を計算するための統計情報が更新されるため、以前のライセンスのパケット データ使用量は削除されます。混在モードの場合、Decoderは古い計算に基づいてデータを送信するため、取得される統計情報は正確ではありません。Decoderはパケット書き込みバイト数を送信せず、処理された収集バイト数も異なります。

     

    You are here
    Table of Contents > アップグレード後のタスク

    Attachments

      Outcomes

        Visibility: RSA NetWitness Logs & Network 11.x Documentation (Japanese)7 Views
        Last modified on Dec 7, 2020 6:06 AM
        Ratings:

          Recommended Content

          Incoming Links