SIEMのログ連携はどこで完了？監視開始前の受入テストと担当分担

SIEMの画面で「接続済み」と表示された。その時点で、監視を始められるでしょうか。

判断するには、調べたい操作が記録され、その情報を検索でき、必要な検知と担当者への連絡まで動くことを確認します。ログが届いたという事実だけでは、どこまで監視できるかは決まりません。

ヤグラの導入相談でも、監視元の設定変更や検知ルールの追加、その作業を誰が進めるかが論点になりました。この記事では、こうした相談から整理した、監視開始の合否を判断する確認表を紹介します。

SIEMの役割や仕組みを先に確認したい方は、SIEMとはをご覧ください。

最初に「何を調べられるようにするか」を決める

接続する製品名の一覧だけでは、必要なログを選び切れません。まず、担当者が答えたい問いを短く書きます。

たとえば「管理者権限の変更があったとき、誰が、誰に、どの権限を付けたか確認したい」という問いです。この場合は、権限変更の記録と、その操作をした人・対象者・時刻・変更内容を結び付ける情報が必要になります。

ここまで決めると、監視元で対象の記録が有効か、取得用の権限で読めるか、SIEM上で必要な項目が欠けていないかを具体的に確認できます。「接続したが、欲しい操作が記録されていなかった」という手戻りを減らすための順序です。

たとえばAWS CloudTrailのデータイベントは、証跡やイベントデータストアで既定では記録されず、追加料金がかかります。S3オブジェクトへの操作など、調べたいイベントの設定を確認しましょう。AWS公式ドキュメント

受入テストを6段階に分ける

受入テストは、導入した仕組みが予定どおり使えるか確かめる作業です。以下はヤグラが提案する整理例です。対象製品や監視目的に合わせ、必要な項目を選んで使ってください。

実施前に、各項目の期待結果と許容範囲を決めます。たとえば到着までの許容時間、必須の項目、今回の対象外を明記します。実施後は、実際の結果と「合格・未合格・未確認」の判定を証拠と一緒に記録してください。単にイベントが一件届いたことと、予定した条件を満たしたことを分けて判断できます。

役割ごとに別の人を置く必要はありません。兼務する場合も、どの段階の確認を引き受けるかを明確にします。外部の運用会社が関わる場合は、社内と委託先のどちらが設定変更・調査・判断を担うかも記入します。

この確認表は、すべての攻撃を検知できることを証明するものではありません。実施した対象・条件について、どこまで動作を確認したかを残すための表です。

時刻と対象を、元の記録までたどる

画面に値が表示されていても、それが元イベントのどの値か分からなければ調査で迷います。イベントの発生時刻と取り込み時刻、操作したアカウントと操作対象のアカウントを区別して確認します。

特に複数のシステムをまたぐ調査では、時刻のずれや、同じ端末・利用者を異なる名前で扱うことが判断に影響します。任意のサンプルを眺めるだけでなく、実施時刻と対象が分かる確認用の操作を一つ選ぶと、元ログと取り込み後の表示を照合しやすくなります。

ACSCなどが共同で公表したログ管理の指針も、収集対象・監視方法・保存期間・責任分担を方針に含めることや、時刻の整合を扱っています。上の表はその考え方と導入相談の論点を、受入作業に落とし込んだものです。イベントログと脅威検知の指針

検知結果だけでなく、担当者の受領まで確かめる

テスト用アラートが出た後、その通知を誰が見るかも確認します。担当者が実際に受け取り、根拠を開き、必要な記録先に残せるところまで一巡させます。

この段階で、AIやルールの判定と、業務上の正当性の確認を分けます。権限変更を検知できても、それが予定された作業かどうかは、申請や作業予定を持つ担当者への確認が必要な場合があります。調査結果の生成だけを、対応完了と扱わないことが大切です。

テストは、利用環境に合った承認済みの操作やテスト用イベントで行います。通知の確認と、実際のアカウント停止・端末隔離などの実行は、分けて計画します。

保存済みログの再投入や通知先へのテスト送信で確認できるのは、実際に通過させた工程です。それだけでは、監視元が新しいイベントを記録し、転送できることまで確認したことにはなりません。段階1と2も含めて確かめる場合は、対象・時刻が分かる操作の記録を元システムから追い、確認した範囲を残します。

確認表の記入例：権限変更の監視を始める場合

次は考え方を示す架空例で、顧客の構成や導入実績ではありません。

あるチームが、管理者権限の変更を監視対象にします。テスト用アカウントの権限を、決めた時間に管理者が変更しました。元システムには記録があり、SIEMにも届きましたが、調査画面では「操作した人」と「変更された人」の区別がつきません。

このとき、段階2は確認できても、段階3と4は未完了です。ルールを増やす前に、元イベントの項目と表示の対応を修正し、同じ条件で再確認します。修正後に検知と通知が動いたら、社内窓口が正規の作業予定と照合できるかを確かめます。

「問題なし」の一言で終えず、対象範囲と未確認の条件を残すと、運用を引き継ぐ人も判断できます。

ログが止まったときと、設定が変わったときも決める

初日に動いた接続を、その後も同じ条件で使えるとは限りません。取得権限の失効、接続先の変更、記録形式の変更などがあったとき、再確認する担当を決めます。

ここで注意したいのは、「しばらくログが来ていない」ことと「取り込みが壊れた」ことが同じではない点です。操作があったときだけ記録する対象なら、何も起きていない可能性もあります。取得処理の結果、通常の発生頻度、監視元の状態などを組み合わせて判断します。

次の3点を運用の引継ぎに含めておくと、停止後の確認が進めやすくなります。

• 何を手掛かりに、取得の異常や遅れを知るか。

• 元システムと連携部分を誰が確認し、誰へ連絡するか。

• 復旧後、欠けた期間のログを取得できるか、できない場合に何を記録するか。

保存してある期間と、すぐに検索できる期間が異なる場合も、調査担当者へ伝えます。過去の確認が必要になったとき、誰がどこから取得するのかまで分かる状態にしておきます。

停止・遅延・記録欠損を切り分ける確認順序

異常通知を受けたら、連携名、対象ログ、最後に届いた時刻、確認した期間を記録します。次はヤグラが提案する切り分け手順です。

1. 元の記録を確かめる。対象期間に操作があったか、その操作が監視元に記録されているかを確認します。操作がない場合、件数ゼロだけで収集障害とは判定しません。記録設定や対象範囲の変更も確認します。

2. 到着と中身を分けて確かめる。元の記録があるのに届かなければ、取得権限、取得処理のエラー、転送経路を順に確認します。届いていても遅い場合は、発生時刻と取り込み時刻の差を調べます。届いた記録の必須項目が欠けている場合は、形式変更や項目の対応を確認します。

3. 影響範囲を共有する。対象のログに依存する検知ルール・調査と、確認できない期間を明記します。その期間にアラートがないことを、安全だった根拠にはしません。

Microsoft Sentinelには収集状態を確認するワークブックとSentinelHealthテーブルがあります。ただしSentinelHealthの対応コネクタは限定され、利用には正常性監視の有効化が必要です。コネクタの状態だけで完了とせず、必要なデータが検索できるかも照合します。Microsoft公式：データコネクタの正常性監視

復旧は「新しいログが届いた」で終えない

復旧後は、欠けた期間の再取得可否、検索結果、検知ルールの対象期間を確認します。遅れて届いたログがルールの検索期間から外れると、保存されても検知されないことがあります。検索期間を広げる場合は、同じイベントから通知が重複しないかも確認してください。Microsoft公式：取り込み遅延と定期分析ルール

例えば「09:00〜09:40の権限変更ログを取得できなかった」という架空の障害では、新しいログの到着、該当40分の再取得、必要な再調査の完了を別々に記録します。再取得できない部分は、欠損期間・影響する調査・代替証拠・判断担当者を残します。時刻は説明用で、一律の停止判定基準や復旧目標ではありません。

運用記録には、対象ログ／最終正常時刻／影響期間／原因と対処／再取得の結果／検知・重複の確認結果／未確認事項／担当者と次回確認時刻を残すと、引継ぎ時の判断をそろえやすくなります。

一つの対象で一巡させてから、監視範囲を広げる

すべてのログソースを同時に仕上げようとすると、未完了の作業が見えにくくなります。まず、重要なシステムと調査の問いを一つ選び、記録から受領までを確認します。その結果をもとに、対象を追加したときに共通で使える設定と、個別に必要な作業を分けます。

標準の連携機能で容易に収集を始められる環境もあります。その場合も、確認を複雑にするための表にせず、自社に必要な監視が成立しているかを短く確かめるために使ってください。

ヤグラに相談する際は、監視したいシステムの一覧に加えて、「何を調べたいか」「いま確認できている段階」「残っている作業の担当」を整理すると、必要な支援の範囲を具体的に話せます。AI SOCの導入・運用について

ログの受入確認を終えたら、調査品質や運用負荷を比較するためのAI SOCのPoC評価項目と記入式チェックリストも活用できます。