ServiceNow の Tenable 統合のパフォーマンスチューニングのヒントSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 概要 次のような Tenable ソースから大量の脆弱性データをインポートする際に、パフォーマンス上の問題が確認されています。 Tenable.io Assets IntegrationTenable.io Fixed Vulnerabilities IntegrationTenable.io Open Vulnerabilities Integration 問題 1) データ処理の遅延 → 大規模なデータセットをインポートする場合、大幅な遅延が発生する可能性があります。 → 例えば、Vulnerability Integration Run レコードの Import Queue Wait Time が数時間（例: 4～12 時間）になる場合があります。 → これは主に、データ処理が Vulnerability Import Templates によって管理されているためです。デフォルトでは 5 個のテンプレートのみがアクティブですが、インスタンスの能力およびノードの可用性に応じて 15 または 20 まで拡張できます。テンプレート数を増やすことで並列処理が可能になり、全体的な待機時間を短縮できます。 → テンプレート数を増やす方法については、KB0995644 を参照してください。 → プロセスが取得されるまでの待機時間が長い場合は、データソース数を増やしてください。インポート待機時間が長い場合、統合処理が starvation 状態になっているため、データソース数を増やすことを推奨します。 → ワーカースレッドを待機しているキューエントリが増えている場合は、インフラストラクチャに応じてデータプロセッサ数を増やすことを推奨します。 → データソース数を増やす方法の詳細については、KB0995003 を参照してください。 → ノード構成を確認するには、<instance url>/sys_cluster_state_list.do?sysparm_query= にアクセスし、インスタンスで利用可能なプライマリノード数を確認します（Node Type = Generic Primary）。 2) 添付ファイルの最大サイズが原因で統合が失敗する → 受信した添付ファイルが許可されたサイズ制限を超えた場合にも失敗が発生します。デフォルトの sys_attachment.max_size は 1024 MB ですが、この制限を増やすことは推奨されません。 → 統合ジョブの chunk_size パラメーターを 500 から 200、またはそれ未満の値に減らしてください。 → これにより、大きな添付ファイルをより効率的に処理できます。特に、インスタンスが頻繁に大きなペイロードを受信する場合に有効です。 3) Tenable.io 統合で「Job exceeded processing time and was forced to complete status」エラーが発生する → 該当する統合パラメーターの offset 値を 100 に設定する必要があります。これにより問題が解決されます。 → サンプル統合 URL: https://instance.service-now.com/nav_to.do?uri=sn_sec_int_impl.do?sys_id=xxxx 4) 検出結果は存在するが、Vulnerability Item フィールドが空であるため VIT が関連付けられない、または作成されない → 検出作成時刻付近のシステムログを確認してください。 → 作成ロジックを処理する Script Include「Detectionbase」の processVI 関数を確認してください。 → 関連するエラーがないかノードログを確認してください。 → 除外ルールを確認してください（新しい検出結果が除外ルールの条件を満たす場合、ルールは検出結果に関連付けられますが、VIT は作成されません）。 https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-response/concept/exclusion-rules 5) 遅い Vulnerability Rules を確認する → Tenable インポート実行中、関連する Vulnerability Rules は脆弱性データのインポート後に実行されます。代表的な Vulnerability Rules は次の 3 つです。 Vulnerability Risk Rules（table: sn_vul_calc_risk.LIST）Vulnerability Assignment Rules（table: sn_vul_assignment_rule.LIST）Vulnerability Group Rules（table: sn_vul_grouping_rule.LIST） → 以下の手順で Tenable Integration Run レコードのボトルネック箇所を確認できます。 (a) table sn_vul_integration_run.LIST を開き、該当する Tenable Integration Run レコードを開きます。 または → メニュー Tenable Vulnerability Integration > Primary Integrations に移動し、Tenable Integrations レコード（例: Tenable.io Open Vulnerabilities Integration）を開きます。その後、[Vulnerability Integration Runs] タブで Tenable Integration Run レコードを確認できます。 (b) 「Vulnerability Integration Process」のリストビューに次のフィールドが存在しない場合は追加します。 Assignment rules timeGroup rules timeRisk rules time → 「Import queue processing time」、「VI creation time」、「CI lookup time」などのフィールドも追加できます。これらは、どこでパフォーマンス低下が発生しているかを診断するのに役立つ追加の処理情報を提供します。 → これにより、Qualys データ処理中のボトルネック箇所を把握できます。 → 特定の Assignment Rule で処理が遅い場合は、そのルールを無効化して Tenable 統合を再実行してください。 → 複数の Assignment Rules がすべて遅い場合は、以下のオプションを試してください。 (a) Business Rule「Run assignment rules」を無効化し、Qualys 統合を再実行します。 (b) すべての Assignment Rules と Group Rules を非アクティブにして初回インポートを再実行します。これにより、すべての Vulnerability Items が最初にインポートされます。その後、これらのルール（Group Rules + Assignment Rules）を有効にし、各ルールの [Apply Changes] ボタンをクリックします。これにより、インスタンス内の既存の Vulnerability Items にルールが適用され、初回インポート時の負荷を軽減できます。 → 初回インポート完了後は、後続のインポートで処理される差分の新規レコード数が少なくなるため、より高速に処理されます。 → Vulnerability Rules がカスタマイズされていることが判明した場合は、ロジックをさらに確認するため、開発チームを関与させるタスクを起票してください。 6) 遅いクエリまたはスクリプトを確認する → 遅いスクリプトは sys_script_pattern.LIST テーブルから検索でき、遅いクエリは sys_query_pattern.LIST テーブルから検索できます。 → [Average execution time (ms)] フィールドおよび [Execution count] フィールドから、Tenable インポート中に最も頻繁に実行され、かつ遅い Business Rule、データベースクエリ、スクリプトなどを確認できます。 → localhost ログ内で、脆弱性関連テーブル（テーブル名が sn_vul_ で始まる）上で実行されている遅い Business Rule がないか確認することもできます。 → 遅い Business Rule またはクエリが見つかった場合は、まず以下の基本的な確認を実施してください。根本原因が依然として不明な場合は、Performance チームを関与させるタスクを起票してください。 (a) OOTB（Out-Of-The-Box）インスタンスと比較して、脆弱性テーブルに不足しているインデックスがないか確認します。 (b) その Business Rule に、最適化可能な負荷の高いデータベースクエリやスクリプトロジックがないか確認します。 7) Tenable Attachment の評価時間を増やす → Tenable インポート中、脆弱性データは実際には Tenable Scanner から取得され、XML 添付ファイルとして table sn_vul_ds_import_q_entry.LIST に保存されます。 → 添付ファイルの評価時間は、Script Include「VulnerabilityDSAttachmentManager」でデフォルト 3600 秒（60 分）に設定されています。 → 処理上の問題が発生し、処理時間を超過した場合、以下のエラーメッセージが sn_vul_ds_import_q_entry レコードの「processing notes」フィールドに出力されます。 → Error, "Job exceeded processing time and was forced to complete status" → この場合、大量の Tenable データを処理するため、以下の手順で評価時間を延長できます。 (a) インスタンス上で次の Script Include を開きます（URL 内の <instance_name> は実際のインスタンス名に置き換えてください）。 https://<instance_name>.service-now.com/nav_to.do?uri=sys_script_include.do?sys_id=aa1b81669f31020034c6b6a0942e7014 (b) デフォルトでハードコードされている 3600 秒の制限値を増やします（変数 _MAX_PROC_TIME_S: 3600）。 → Script Include「VulnerabilityDSAttachmentManager」のタイムアウト値を変更した後は、別の Script Include「VulnerabilityIntegrationUtils」の同じ値も変更する必要があります。 ーーーーーーーーーー 次のような Tenable ソースから大量の脆弱性データをインポートすると、パフォーマンスの問題が確認されています。 Tenable.io 資産統合Tenable.io の修正された脆弱性統合Tenable.io のオープンな脆弱性統合 問題1)データ処理の遅延-->大規模なデータセットをインポートする場合、大幅な遅延が発生する可能性があります。-->たとえば、脆弱性統合実行レコードのインポートキュー待機時間は数時間 (4〜12 時間など) にすることができます。-->これは主に、データ処理が脆弱性インポートテンプレートによって管理されるためです。デフォルトでは 5 つのテンプレートのみがアクティブですが、インスタンスの機能とノードの可用性に基づいて 15 または 20 にスケールアップできます。テンプレートの数を増やすと並列処理が可能になり、全体的な待ち時間が短縮されます。-->テンプレート数を増やす方法については、「KB0995644」を参照してください。-->プロセスが取得されるのを待機時間が長い場合は、データソースを増やします。インポート待ち時間が長い場合は、統合が枯渇しているため、データソースを増やすことをお勧めします。--> ワーカースレッドを待機しているキューエントリが増える場合は、インフラストラクチャに基づいてデータプロセッサの数を増やすことをお勧めします。-->データソース数を増やす方法の詳細については、「KB0995003」を参照してください。-->ノード構成を確認するには、/ sys_cluster_state_list.do?sysparm_query= に移動して、インスタンスで利用可能なプライマリノードの数を確認します (ノードタイプ = 汎用プライマリ) 2) 添付ファイルの最大サイズが原因で統合に失敗する-->受信添付ファイルが許容サイズ制限を超えた場合にも失敗が発生します。デフォルトの sys_attachment.max_size は 1024 MB ですが、この制限を増やすことはお勧めしません。-->統合ジョブのchunk_sizeパラメーターを 500 から 200 以下の値に減らします。-->これは、特にインスタンスが大きなペイロードを頻繁に受信する場合に、大きな添付ファイルをより効率的に処理するのに役立ちます。3) Tenable.io 統合で「ジョブが処理時間を超え、ステータスを完了させられました (Job exceeded processing time and was was forced to complete status)」というエラーが発生する-->それぞれの統合パラメータオフセットの値を 100 に設定する必要があるため、問題は解決します。-->サンプル統合 URL: https://instance.service-now.com/nav_to.do?uri=sn_sec_int_impl.do?sys_id=xxxx4) 検出は存在しますが、検出されたアイテムの [脆弱性一致アイテム] フィールドが空であるため、VIT は関連付けられていないか、作成されません。-->検出作成時刻の前後のシステムログを確認します。-->作成ロジックを処理する「Detectionbase」スクリプトインクルードの processVI 関数を確認してください。-->ノードログに関連するエラーがないか確認します。-->除外ルールを確認します (新しい検出が除外ルールの条件を満たす場合、ルールは検出に関連付けられますが、VIT は作成されません)。https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-response/concept/exclusion-rules.5) 遅い脆弱性ルールを確認する-->Tenable インポートの実行中、関連する脆弱性ルールは脆弱性データのインポート後に実行されます。以下に、代表的な脆弱性ルールを 3 つ紹介します。-脆弱性リスクルール (テーブル:sn_vul_calc_risk。リスト)-脆弱性アサインルール(テーブル:sn_vul_assignment_rule。リスト)-脆弱性グループルール(表:sn_vul_grouping_rule。リスト)-->以下の手順に従って、Tenable 統合実行レコードのボトルネックがどこにあるかを確認できます(a) テーブル sn_vul_integration_runを開きます。リスト 対応する Tenable 統合実行レコードを開きますまたは-->メニューに移動 Tenable 脆弱性統合 >プライマリ統合で、Tenable 統合レコード (オープンな脆弱性統合など Tenable.io) を開くと、[脆弱性統合実行] タブで Tenable 統合実行レコードを確認できます(b)以下のフィールドがない場合は、[脆弱性統合プロセス] のリストビューに追加します-アサインルール時間-グループルール時間-リスクルール時間-->[インポートキュー処理時間]、[VI 作成時間]、[CI ルックアップ時間] などの他のフィールドを追加して、速度低下の発生場所を診断するのに役立つ処理情報を提供することもできます。-->これは、Qualys データの処理中に速度が低下している場所を知るのに役立ちます。-->特定のアサインルールで処理が遅い場合は、それを無効にして Tenable 統合を再実行してください。-->複数のアサインルールがすべて遅い場合は、以下のオプションを試してください。(a) ビジネスルール「アサインルールの実行」を無効にし、Qualys 統合を再実行します。(b) すべてのアサインルールとグループルールを非アクティブとしてマークし、初期インポートを再実行します。これにより、すべての脆弱性一致アイテムが初めてインポートされます。その後、これらすべてのルール(グループ+アサインルール)を有効にし、これらのルールの[変更を適用]ボタンをクリックします。これにより、インポートされた脆弱性一致アイテム (インスタンスに存在する) にルールが適用され、初期インポート時の作業負荷が軽減されます。-->後続のインポート以降に初期インポートが完了すると、デルタ新しいレコードの数が少なくなり、処理が速くなります。-->いずれかの脆弱性ルールがカスタマイズされていることが判明した場合は、ロジックをさらに確認するために開発チームを関与させるタスクを作成してください。6) 遅いクエリやスクリプトを確認する-->遅いスクリプトは sys_script_patternから検索できます。LISTテーブルと遅いクエリーはsys_query_patternから検索できます。LIST テーブル。-->[平均実行時間 (ミリ秒)] フィールドと [実行回数] フィールドから、Tenable のインポート中にどのビジネスルール、データベースクエリ、スクリプトなどが最も頻繁に実行され、実行速度が遅いかがわかります。-->localhost ログ内の脆弱性テーブル (テーブル名が「sn_vul_」で始まる) で実行されている遅いビジネスルールがないかどうかを確認することもできます。-->遅いビジネスルールまたはクエリが見つかった場合は、まず以下の基本的なチェックを完了し、根本原因がまだ不明な場合は、パフォーマンスチームを関与させてさらにチェックするタスクを起こします。(a) OOTB (Out-Of-The-Box) インスタンスと比較して、脆弱性テーブルに欠落しているインデックスがないか確認します(b) そのビジネスルールで最適化できる重いデータベースクエリまたはスクリプトロジックがあるかどうかを確認します7) Tenable アタッチメントの評価時間を長くする-->Tenable のインポート中に、脆弱性データは実際に Tenable スキャナーから取得され、XML 添付ファイルとしてテーブル sn_vul_ds_import_q_entry に保存されます。リスト。-->スクリプトインクルード「VulnerabilityDSAttachmentManager」では、添付ファイルの評価時間はデフォルトで 3600 秒 (60 分) に設定されています。-->処理時間を超えると処理に問題が発生した場合、「sn_vul_ds_import_q_entry」レコードの「処理メモ」欄に以下のエラーメッセージが出力されます。-->Error, "Job exceeded processing time and was forced to complete status"-->この場合、以下の手順に従って評価時間を長くして、大量の Tenable データを処理できます。(a)インスタンスで以下のスクリプトインクルードを開きます (URL 内のインスタンス名に置き換えます)https://<instance_name>.service-now.com/nav_to.do?uri=sys_script_include.do?sys_id=aa1b81669f31020034c6b6a0942e7014 (b)デフォルトのハードコード制限の 3600 秒を増やす (変数_MAX_PROC_TIME_S:3600)-->スクリプトインクルード「VulnerabilityDSAttachmentManager」のタイムアウト値を変更した後、別のスクリプトインクルード「VulnerabilityIntegrationUtils」の同じ値も変更する必要があります。