セキュリティログ分析の実務

ログは嘘をつかないが、解釈を間違えると組織が疲弊します。現場で効くのは“とれるログを全部集める”ではなく、“守る範囲で起きうる攻撃を、運用で回る粒度で検知する”ことです。サーバ監視の延長線上にありつつも、設計の一手で成果が大きく変わります。

最初に決めるのは「何を検知して、どこまで深追いするか」

最初に決めるのはSLOとカバレッジです。例として、MTTDは「本番サーバへの異常ログインは10分以内」、MTTRは「重大度Highは2時間以内に一次封じ込め」を目安にします。対象は攻撃面から優先度付けします。

優先順位の付け方

• 外部公開サーバ（WAF/リバースプロキシ/SSH/RDP）
• 特権アカウントと自動化トークン（CI/CD、サービスアカウント）
• データ持ち出し面（S3等オブジェクトストレージ、DB、共有ストレージ）

検知テーマは「認証回り」「横展開」「データ外送」に分け、まず高精度ルールから開始します。精度（Precision）が0.8を切ると現場は回らなくなりがちなので、はじめはRecallよりPrecisionを優先します。重大度は“影響×確度×復旧コスト”でランク付けし、一次対応の深さ（調査粒度、封じ込め手順）まで決めておきます。

ログ収集と正規化：後で泣かないための型作り

収集は“少なくともこれ”を押さえます。認証（Linux auth.log/Windows Security）、ネットワーク境界（WAF/NGFW/ロードバランサ）、エンドポイント（EDR）、クラウド制御面（CloudTrailなど）、DNS/プロキシが基本ラインです。NTPで時刻同期は必須、タイムゾーンはUTCで統一します。

正規化の最低項目

• @timestamp、host、env（prod/dev）、user、src_ip、dst_ip、action、result（success/fail）、request_id
• 可能ならgeoip、asn、asset_criticality（資産重要度）をエンリッチ

スキーマはElastic Common SchemaやOCSFのいずれかに揃えると相関が楽になります。取込時にフィールド名を合わせ、例外は変換ルールで吸収します。保持は“Hot/Warm/Cold”の3階層で、Hotは7〜14日、Warmは90日、Coldは1年など。検索要件と法規を満たしつつ、コスト予測を月次で回します。個人情報や外部IPはハッシュ化や末尾マスク（例：IPの最後のオクテットを0）でプライバシー配慮も忘れずに。

相関・検知ロジックの作り方とチューニング

ルールは“説明可能”を第一にします。ブラックボックス的な異常検知は便利ですが、一次対応で説明がつかないと止まります。次のような構成が現場で強いです。

即効性の高いルール例

• 不可能移動（Impossible Travel）：同一アカウントが短時間に遠距離から成功ログイン
• 失敗の直後に成功：同一IPから5分以内に複数失敗→成功（リスト型攻撃の兆候）
• サービスアカウントの夜間認証：営業時間外の成功ログイン
• 管理端末以外からの特権操作：許可された端末タグ以外でのsudo/RoleAssume

相関は“スライディングウィンドウ×閾値”が基本です。たとえば「5分間に同一IPから失敗10回以上」や、「24時間で特権昇格3回以上」など。ベースラインも作ります。ユーザーごとの通常AS/国/時間帯を日次で更新し、逸脱を検知します。脅威インテリジェンス（ボットネットASや既知悪性IP）を毎日取り込み、イベントにASN/レピュテーションを付与して精度を上げます。

検知の実装はSigmaで記述しておくと、ElasticsearchやSplunk等に移植しやすいです。クエリ化や翻訳には生成AIを補助利用します。たとえばChatGPTでSPLからKQLへの変換のたたき台を作り、Claudeで長大な監査ログの要約を得て、CopilotでNginxパーサのPythonスニペットを補完、Geminiで例外条件（社内VPNやヘルスチェックIP）をクエリに追加する、といった使い方です。最終判断は人が行い、根拠と抑止条件はルールに必ずコメント化します。

チューニングと運用

• バックテスト：直近30日のログでアラート数と真陽性率を測定
• サプレッション：ヘルスチェックIP/監視用ユーザー/社内VPN ASNはホワイトリスト管理
• 運用指標：1アナリストあたりの1時間の処理可能アラート数を上限に逆算してルールを調整
• 一次対応の標準化：各ルールに即時封じ込め条件（アカウント無効化/Firewall一時遮断）とエビデンス採取手順を紐付け

インシデントはチケットに自動起票し、タイムライン（検知→トリアージ→封じ込め→復旧）を記録します。ポストモーテムで「誤検知理由」「必要なメタデータ」「新規サプレッション」を見直し、次週のルールに反映します。

身近な企業活用例：EC中堅「スカイカート」社の失敗と再起

業種：EC（自社サイト）／規模：従業員180名・インフラはAWS中心。状況：ALBアクセスログ、CloudTrail、Linux syslogをSIEMに集約。導入初月は1日300件のアラートでアナリスト2名が疲弊し、重大な資格情報詐取を見逃しました。失敗要因は、社内VPNと監視のヘルスチェックIPを除外せず、“不可能移動”が毎日誤検知していたこと、サービスアカウントの夜間実行（バッチ）が異常扱いになっていたことです。

改善では、まず資産台帳に「env/重要度/許可端末タグ」を追記し、ログに自動付与。ASNとGeoIPをエンリッチして“社内VPNのASN”をホワイトリスト化。サービスアカウントは運用時間帯を明示し、その範囲外はHighではなくMediumに格下げ。さらに「失敗→成功」ルールにレピュテーション要素を掛け合わせ、「悪性ASNかつ5分以内に失敗8回以上→成功」でのみHighにしました。クエリ化はChatGPTとGeminiでKQL/SPLの下書きを作り、Claudeで長大なCloudTrailイベントの差分要約を実施。CopilotでLambdaの正規化コードを素早く整備しました。

結果、アラートは1日80件に減少、真陽性率は12％→46％、MTTDは平均38分→9分へ。2カ月後、海外のBulletproof ASNからのリスト型攻撃を検知し、WAFルール自動適用で遮断。売上影響を出さずに済みました。以降は週次でサプレッションとベースライン更新を回す運用が定着しています。

セキュリティログ分析は、サーバ監視運用の「リソースと死活」の隣に「ふるまいと相関」を置く作業です。収集の型、説明できる検知、回る運用という三点を押さえれば、監視チームがそのまま一次防御の要になります。サーバ監視運用事業としての強み—24/7の目と定常オペレーション—を生かすほど、検知は静かに、しかし確実に効きます。