記録から分かったことと、
確認が必要なこと。

遮断の数は社内アドレスを送信元とする21027/UDPのdeny/drop/block記録数です。攻撃回数・障害回数・一意セッション数ではありません。CPUは記録された観測点の値であり、瞬間的な負荷すべてを示しません。高負荷対策の前後比較・効果を示す資料ではありません。

1　何が記録されていたか

同じポートへの探索通信が繰り返し遮断されています。保存した設計記録では、このポートは社内で使うファイル同期の探索に用いられています。通信の用途を照合することで、遮断を一律に外部からの攻撃として扱わず、必要な通信かどうかを確認する対象として整理できます。

2　事実・判断・次の確認

3　集計の意味も確かめる

通信量を読む際には、同じ接続の累積値を繰り返し加算していないかを確認します。今回の参考例では、元の通信量集計に確認事項が残るため、端末別・国別の通信量グラフを掲載していません。

目的：何を見つけるために、どんな情報が必要か

内部端末から既知の悪性な宛先への通信を見つけるため、通信記録を脅威情報の一覧と照合します。この照合に使う情報源の構成が適切かを見直し、配信元ごとに実際に取得された内容を確かめました。

最初の問題は、取得の失敗を知らせる自動警告では見つかっていませんでした。必要な情報が得られているかを、調査の目的に照らして確かめたことで分かりました。

一つの配信元で、判定用データが得られていなかった

脅威情報の配信元の一つは、配信終了の案内文を返していました。通信は成功するため、取得失敗や更新停滞だけを調べる仕組みでは検出できない状態でした。他の配信元のデータは読み込めており、脅威情報全体の停止とは区別しています。

対処：情報源の見直しと、読み込み状況の確認を追加

判定用のデータが得られない配信元は構成から外しました。情報を取得できたかに加え、判定に使うデータを読み込めているかを確かめるため、配信元ごとの読み込み件数チェック、件数不足の警告、日々の内訳表示を追加しました。新しく加える配信元についても、読み取り処理を検証しました。

もう一つの不具合：新しいCSVも、そのままでは読めなかった

新しい配信元のCSVでは、区切り文字の後の空白と引用符の扱いが合わず、有効データが0件になる問題が起きました。追加した件数チェックが警告を出したため、読み取り処理を修正しました。

対処と確認：警告が出ること、修正後に読めること

報告する判断

「通信に成功した」という表示だけで、判定機能が正常とは結論づけません。情報源と読み込み結果を見直す必要があると整理し、対処後はデータと警告の両方を確認します。この事例は、監視自体の不具合に気づくための確認も運用に組み込む価値を示しています。

項目数は保存JSONの要素数です。台数や一意のプロセス数ではありません。falseは収集時の署名確認結果であり、悪性の証拠でも、実際に署名が存在しないことの確定でもありません。

1　精査で見つかった食い違い

自動分析文は「未署名のプロセスはない」としていました。一方、保存された入力には署名確認結果がfalseの項目があります。そのため、この判定をそのまま「正常」「調査不要」として扱うことはできません。

2　次に確認すること

• 署名の確認方法と、結果が取得できなかった場合の扱い。
• 対象ファイルの署名・発行元・起動元と、業務での用途。
• 接続先の記録と、対象日時に実行されていた内容。

保存された収集JSONと照合した値です。「正常」は、その時点の確認対象と設定された基準による判定です。サーバー全体や将来の稼働を保証するものではありません。

事実・変化・推定・推奨確認

確認した記録の抜粋