NetScaler ADCとGatewayの脆弱性情報、利用企業が確認する対象

NetScaler ADCとGatewayの脆弱性情報、利用企業が確認する対象。この記事は2026年10月21日に確認できた公式情報を起点に、NetScaler ADCとGatewayの脆弱性情報、利用企業が確認する対象という疑問に答えるための確認手順を整理します。自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

脆弱性対象製品とバージョンの確認方法

対象範囲の正確な特定手順

対象となる NetScaler ADC と Gateway のバージョンを特定する際は、まず社内にある資産管理表と照らし合わせて、製品名とリリース番号が記載されているか確認します。管理表に情報がない場合は、実際に稼働している機器の管理画面で現在のバージョンを確認し、その画面を記録として残すように依頼してください。

取得したバージョン情報を、JPCERT/CC が公表している脆弱性対象リストと比較し、対象かどうかを判断します。

判断結果を共有する際は、製品名・現在のバージョン・対象か否か・備考といった項目を一覧にまとめ、システム管理者にメールで報告し、承認を得るプロセスを踏むとよいでしょう。

担当者に確認すべき具体的な質問例

1. 資産管理表に NetScaler の製品名とリリース番号は記載されていますか。記載がない場合、どのようにバージョン情報を取得すればよいか教えてください。
2. 現在稼働中の機器のバージョンを確認した画面のスクリーンショットは取得できましたか。取得方法と保存場所を教えてください。
3. 取得したバージョンを JPCERT/CC の対象リストと照合した結果、対象となるかどうかの判定はできましたか。判定が難しい場合は、どの情報が不足しているか教えてください。
4. 判定結果をまとめた一覧はどの形式で作成し、誰にどのように共有すればよいか、手順を確認してください。

このように、実際に確認できた情報と不足している情報を整理して担当者に質問すれば、対象範囲の特定が正確に行えるはずです。

本手順は、JPCERT/CC が提示する対象バージョンとの照合を行うことを目的とし、実施は組織の資産管理プロセスに従ってください。

例外的な構成の取り扱い指針

FIPS モードやカスタムビルド、サードパーティ製プラグインが導入されている環境は、標準的なバージョン照合だけでは脆弱性の有無を判断できません。まず、管理コンソールの「System > Settings > Security」から FIPS 有効状態を確認し、スクリーンショットで記録します。

次に、カスタムビルドの場合は、ビルド番号やパッチレベルが製品リリースノートに記載されているかを確認し、提供元提供の「カスタムビルド対応表」と照合します。例外構成がある場合は、提供元の公式ドキュメントで提示されている対応策を確認してください。

この指針に従うことで、例外構成が見落とされて攻撃対象になるリスクを低減できます。また、例外が多い場合は、定期的に提供元へ問い合わせて最新の対応情報を取得し、文書化された例外リストを更新するサイクルを設定します。

照合結果の文書化と承認フロー

照合が完了したら、結果を「脆弱性対象確認報告書」として文書化します。報告書の構成は、①対象製品一覧、②バージョン照合結果、③例外構成の有無、④次工程（パッチ適用・調査）の担当者、⑤承認サイン欄、の5 部分です。報告書の作成・承認は、組織の既定のフローに従い、適切な場所に保存して次工程へ引き継いでください。

このフローは、誰がいつ何を確認したかを明確に残すことで、内部監査や外部監査時の説明責任を果たすだけでなく、誤った対象外判定が後に判明した際の追跡も容易にします。

修正プログラム適用の実務フロー

パッチ適用前のテスト項目一覧

本番環境へパッチを適用する前に、テスト環境で必ず実施すべき項目を一覧化します。テストは、提供元が提供する機能・性能・セキュリティの検証ガイドラインに従って実施してください。テスト結果はスプレッドシートに「項目」「期待結果」「実測結果」「合格/不合格」の形で記録し、担当者が署名します。

テスト項目は、パッチ適用によるサービス停止リスクを最小化するために、必ず実施し、合格しない項目があれば本番適用を保留し、原因究明と修正を行います。テスト完了後は、テスト報告書を情報セキュリティ部門に提出し、承認を得て本番適用フェーズへ移行します。

適用失敗時のロールバック手順

パッチ適用中にエラーが発生した場合は、事前に取得したバックアップイメージを用いてロールバックを実施します。バックアップ取得と復元は、提供元が示す手順書に基づき実施し、作業記録を残すことが推奨されます。復元作業は、必ず二名以上の担当者が同席し、作業記録をリアルタイムで共有ドキュメントに記載します。

ロールバックが完了したら、失敗原因を分析し、再適用の可否を判断します。原因がパッチ自体の不具合であれば提供元へ問い合わせ、回避策がある場合はその手順を追加で実施します。失敗履歴はインシデント管理システムに登録し、次回の適用計画に反映させます。

適用完了後の検収基準と担当者

パッチ適用が無事に完了したら、検収フェーズに移ります。検収は、提供元が提供する適用確認項目に従い、サービスが正常に稼働していることを確認してください。検収は、システム管理者が実施し、結果を検収チェックリストに記入したうえで、情報セキュリティ部門長の最終承認を得ます。

検収完了後は、検収報告書を PDF 化し、社内のコンプライアンスフォルダに保存します。また、検収結果を踏まえて、次回の脆弱性対応計画に反映させるため、改善点や教訓を「振り返りシート」にまとめ、定例ミーティングで共有します。これにより、同様の脆弱性が再度出た際に迅速かつ確実に対応できる体制が整います。

侵害有無調査の具体的チェック項目

ログ解析で見るべき指標

ログ解析は、侵害の有無を判断する最初の防衛ラインです。まず、NetScaler ADC と Gateway のアクセスログとエラーログを時系列で抽出し、通常トラフィックと比較して異常なリクエストパターンを探します。

具体的には、短時間に大量の接続が集中する「スキャン的」なアクセスや、未承認の IP アドレスからの DTLS ハンドシェイク失敗が頻発していないかを確認します。次に、エラーログに記録された「NSPPE プロセス異常終了」や「SSL ハンドシェイクエラー」の頻度が急増している場合、脆弱性の悪用が試みられた可能性があります。

これらの指標は、SIEM でのアラート設定や手動検索クエリとして事前にテンプレート化しておくと、調査開始時に迅速に抽出できます。

調査の際は、ログの保存期間とタイムスタンプの正確性を確認し、証拠保全の観点からオリジナルファイルを改変せずにコピーを作成します。さらに、抽出したログはハッシュ値（SHA‑256）を計算し、改ざん防止のために内部の証拠保管システムへ格納します。

担当者は、ログ抽出結果をレポートにまとめ、異常が検出された場合は即座にインシデント対応チームへ責任者への連絡するフローを遵守してください。

設定ファイルの不審変更検出

設定ファイルの整合性を確認することは、攻撃者が不正なコードやリダイレクトを仕込む前兆を見逃さないための重要な手順です。ただし、ハッシュ値だけで変更の正当性を判断できない場合があります。まず、現在の設定と過去に適用したパッチや設定変更の記録を照合し、変更がいつ、誰によって行われたかを担当者に確認してください。

その際に必要なのは、変更管理システムに残っているログや、実際に変更が行われた日時と担当者の記録です。

変更が正当なものかどうかを判断できない場合は、推測で対象外とせず「不明」として残す方が安全です。担当者には、以下の点を具体的に質問するとよいでしょう。
・最近の設定変更やパッチ適用の履歴はどこに保管されているか。
・その履歴に記載された変更日時と実施者は誰か。
・変更管理システムのログと実際の設定ファイルの差分を比較する手順はあるか。

これらの情報が揃えば、正当な変更かどうかを客観的に判断でき、不要なロールバックや誤った対応を防げます。法的な義務や特定の部署・承認フローは、社内で別途確認してください。

例外的な構成（FIPS モードやカスタムビルド）では、標準ハッシュと差異が生じやすいため、事前に例外リストを作成し、許容範囲を明示しておくことが必要です。検出結果は、変更点を箇条書きで整理し、担当者の署名と承認を得た上で、変更管理台帳に記録します。これにより、後日監査が求められた際にも、誰がいつ何を変更したかを明確に示すことができます。

IOC確認と証拠保全の手順

現在、Mandiant と Google の脅威インテリジェンス情報を参考に、実際のシステムに不審な痕跡が残っていないか確認することが推奨されています。

確認すべきポイントとしては、システムの一時領域に不審なファイルが作成されていないか、実行権限が不自然に設定された実行ファイルが存在しないか、そして通常では見られないプロセスが動作していないか、という点が挙げられます。

これらはログや設定ファイルの内容を調べることで把握できますが、具体的にどの項目をどのように確認すべきかは、担当者が管理している環境や運用手順によって異なります。

そこで、担当者に次のような質問をして確認してください。

• 現在のシステムで、過去に一時領域にファイルを作成した履歴や権限変更の記録は残っていますか。
• 標準的なログや設定ファイルに、権限が変更された実行ファイルや不審なプロセスの実行履歴が記録されているか。
• これまでに実施した調査や監視の結果、上記のような痕跡が見つからなかった旨の報告書やメモはありますか。

これらの質問は、実際に痕跡が残っているかどうかを判断するために必要な情報を明確にする目的があります。証拠が存在しないことを推測で結論付けず、確認できた事実と未確認の項目を区別して記録すれば、後続の調査や報告において情報の抜け漏れを防げます。担当者から得られた回答を一覧にまとめ、確認済みと未確認を明示すれば、調査の進捗が分かりやすくなります。

検出された IOC は、スクリーンショットやコマンド出力を含む証拠パッケージとして保存し、ハッシュで保全します。証拠は改ざん防止のため、書き込み禁止のストレージにコピーし、担当者と上長の承認を得たうえで、インシデント対応レポートに添付します。

IOC の有無が確認できたら、結果を「有り」または「無し」の判定としてまとめ、次のステップ（例：フォレンジック解析や追加パッチ適用）の指示を明確に記載します。

社内体制と役割分担の明確化

担当者別の確認責任範囲

脆弱性対応では、ネットワーク、アプリケーション、運用の各部門が明確な責任範囲を持つことが成功の鍵です。ネットワーク担当は、外部からのアクセス経路とファイアウォール設定の確認、特に DTDTLS ポートの開放状況をチェックします。

アプリケーション担当は、NetScaler の仮想サーバー設定や認証ポリシーの整合性を検証し、カスタムスクリプトやリダイレクト設定に不審な変更がないかを確認します。運用担当は、ログ収集・保管プロセスとパッチ適用手順の実行を管理し、変更管理システムへの記録漏れがないかを監視します。

各担当は、週次で進捗報告を行い、全体のステータスを統括するセキュリティリーダーに責任者への連絡するフローを設定します。

役割分担表は、社内 Wiki などで常に最新状態を保ち、担当者が異動した場合は速やかに更新します。また、緊急時には代替担当者を事前に指定し、連絡網を整備しておくことで、担当不在による対応遅延を防止します。責任範囲が明確になることで、調査結果のレビューや承認プロセスがスムーズに進み、再発防止策の策定も効率化されます。

見落としリスクと対策例

過去の見落とし事例として、ログ保存期間がデフォルトの 30 日に設定されたままで、攻撃の痕跡が削除されていたケースがあります。対策としては、重要ログの保存期間を 90 日以上に延長し、定期的にバックアップを外部ストレージへコピーする手順を標準化します。

別の例では、FIPS モードで動作している環境でハッシュ比較を行わずに設定変更を許容していたため、改ざんが検知できなかったケースがあります。ここでは、例外リストを作成し、FIPS 環境に関する設定確認は、提供元の公式ドキュメントを参照してください。

さらに、チェックリストに「変更管理システムへの記録有無」を必ず確認する項目を入れ、未記録の変更があれば即座にアラートを上げる仕組みを導入します。

これらの対策は、内部監査は、組織の監査基準に基づき実施し、必要な記録を残してください。見落としが発覚した場合は、原因分析レポートを作成し、再発防止策として手順書の改訂や担当者への再教育を実施します。

定期レビューと改善サイクル

対応後の見直しでは、対象の特定、提供元への照会、更新の依頼、接続の確認で、どこに時間がかかったかを確認します。通常の接続が戻ったことだけで、過去の不審な利用の調査まで完了したとは扱いません。

次の注意情報が出たときに使えるよう、機器の一覧と保守窓口を更新します。見直しの頻度は、自社の利用状況と変更の発生に合わせて決めてください。続報で調査すべき点が増えた場合に、誰が内容を確認して対応表へ反映するかも明確にします。

改善サイクルの一環として、チェックリストや手順書のバージョン管理を徹底し、変更履歴を残すことで、過去の決定根拠を追跡可能にします。また、レビューで抽出された課題は、次回のパッチ適用計画やテストケースに組み込むことで、同様の問題が再発しないようにします。

最終的に、定期レビューの結果を経営層へ報告し、必要なリソースや予算の確保を依頼することで、組織全体のセキュリティ成熟度を段階的に向上させます。