M-Trends 2026を読む：22秒と14日が示すSOC再設計

M-Trends 2026を読む：22秒と14日が示すSOC再設計 解説・基礎
2026.05.29
この記事は約5分で読めます。

このテーマを取り上げる理由

Mandiant M-Trends1 2026（Mandiantによる年次インシデント調査レポート）の数字から、自社のSOCで即時対応へ上げる条件と、追跡に必要なログ保持期間を見直せます。なかでも2025年データで目を引くのは、次段攻撃への引き渡し時間の中央値が22秒、グローバルの潜伏期間2中央値が14日だった点です。

この数字は、SOC運用に対して厳しい問いを投げています。低リスクに見えるアラートを翌日見る運用でよいのか、90日ログで長期潜伏を追えるのか、外部通知に頼らず内部検知できているのか、という問いです。

注目データ

M-Trends 2026で、実務者がまず見るべき数字は次の4つです。

  • 22秒: 2025年の Time to Hand-Off3 の中央値です。初期アクセスから次の攻撃者・工程へ移る速度が極端に短くなっています。
  • 14日: 2025年のグローバル潜伏期間中央値です。2023年の10日、2024年の11日から上昇しています。
  • 52%: 2025年の内部検知割合です。外部通知に頼る状態から、内部で見つける方向へ少しずつ移っています。
  • 32%: 初期感染ベクターに占める脆弱性悪用の割合です。6年連続でトップです。

数字を単体で眺めるより、自社の検知・対応時間と比べることが重要です。平均値ではなく、中央値や分布を見ると、運用の限界が見えやすくなります。

22秒が示すこと

22秒という数字は、SOCが「後で確認する」前提の運用を取りにくくなったことを示します。特に、認証情報の窃取、脆弱性悪用、外部公開システムへの侵入では、初期イベントから横展開やデータ探索までが短時間で進む可能性があります。

ここで大切なのは、すべてのアラートを即時対応にすることではありません。低インパクトに見えるアラートでも、外部公開資産、特権アカウント、IDプロバイダー、VPN、EDR停止、PowerShell実行などと組み合わさった場合に優先度を上げる設計です。

14日の潜伏期間をどう読むか

潜伏期間中央値14日は、検知が悪化したという単純な話ではありません。攻撃者通知、内部検知、外部通知の比率や、長期潜伏型の事案が混ざるためです。M-Trends 2026では、内部検知の中央値は9日、外部通知は25日と整理されています。

実務上は、ログ保持と検索性が問題になります。Mandiantのメモでは、BRICKSTORMバックドア事案の平均潜伏期間が393日とされており、90日ログだけでは追えない事案があります。外部公開資産や特権IDを扱うシステムは、SOCと基盤運用担当がEDR、ID、クラウド監査ログ、プロキシ、DNSの保持期間を確認し、ログ種別、保持期間、検索責任者を台帳へ記録します。

脆弱性悪用32%への対応

初期感染ベクターで脆弱性悪用が32%という数字は、パッチ管理が依然として中核であることを示します。ただし、単に「早くパッチを当てる」だけでは現場は動きません。外部公開、悪用観測、認証不要、既知攻撃コード、業務重要度を組み合わせ、即時対応、次回メンテナンス、経過監視のどこへ置くかを決めます。

CISA KEV4、ベンダーアドバイザリ、EDR検知、資産台帳をつなげると、対応順序が作りやすくなります。ただし、CISA KEVやBOD 22-01の期限は米国連邦文民行政機関、いわゆるFCEBに対する直接義務です。民間企業や日本企業にはそのまま法的義務として及ぶものではなく、悪用実績のある脆弱性を優先するための実務指標として使うのが適切です。特に外部公開システムは、棚卸しの遅れがそのまま初動の遅れになります。

一枚要約

  • M-Trends 2026は、22秒の次段攻撃、14日の潜伏期間、内部検知52%、脆弱性悪用32%を示しています。
  • 自社への影響は、SOCの優先度設計、ログ保持、脆弱性対応順序、外部公開資産管理に及びます。
  • まず高リスク資産と高リスクアラートの組み合わせを定義し、24時間以内に動くルールへ落とします。

今日着手できる3アクション

  • EDRまたはSIEMで、過去30日の外部公開サーバー関連アラートを抽出します。Splunkなら index=edr (asset_exposure=internet OR tag=internet_facing) earliest=-30d | stats count by signature,severity,host のように集計します。
  • クラウド監査ログの保持期間を確認します。AWSなら CloudTrail Lake または S3 保管設定を確認し、CLIでは aws cloudtrail describe-trails と aws cloudtrail get-event-selectors --trail-name TRAIL_NAME を実行します。公式手順は https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html を参照します。
  • CISA KEVと自社資産を突合する運用を決めます。CISA KEV Catalogは https://www.cisa.gov/known-exploited-vulnerabilities-catalog です。まず外部公開資産に対して、cve, product, internet_facing, owner, target_date, legal_scope の6列で対応表を作り、legal_scope には「FCEB直接義務ではないが優先対応指標」など自社の位置づけを書きます。

AI×セキュリティの観点

攻撃者の自動化が進むほど、SOC側もアラートの優先度付けにAI支援を使いたくなります。ただし、AIが要約したアラートをそのまま信じると、重要な前後関係を落とす恐れがあります。M-Trendsの数字を踏まえるなら、AIは一次判断の代替ではなく、関連ログの要約、類似事案検索、対応手順の提示に限定し、最終判断を証跡へ戻せる形にします。

用語ミニ解説

  1. 潜伏期間: 攻撃者が環境内に侵入してから検知されるまでの期間です。 ↩
  2. Time to Hand-Off: 初期アクセスなどの後、次の攻撃者や攻撃工程へ引き渡されるまでの時間です。 ↩
  3. CISA KEV: CISA Known Exploited Vulnerabilities Catalog の略で、実際に悪用が確認された脆弱性のカタログです。 ↩

参考リンク

コメント

タイトルとURLをコピーしました