攻撃者視点で考えるDetection Engineering

EDR や SIEM などのセキュリティ製品を導入していても、なぜ攻撃が成功してしまうのか。
Red Team テストを実施するだけでは、なぜ監視・検知力が上がらないのか。
本資料では、「攻撃者視点で考える Detection Engineering」を軸に、従来の対策の限界と、次に取り組むべき継続的なパープルチーム演習、検知ロジックの設計について解説します。

Transcript

1. 攻撃者視点で考える Detection Engineering 2026/06/11 Ruslan Sayfiev なぜCSF準拠・EDR導⼊・Red Team演習だけでは侵害を⽌めきれないのか Interop Tokyo 2026
2. ⾃⼰紹介 Ruslan Sayfiev / サイフィエフ ルスラン Principal Consultant / Red Team Architect ̶ Fujitsu Uvance Wayfinders OSEE OSCE3 OSCP GXPN 略歴 「Red Teamテスト＝防御態勢再設計の起点」を軸に、重要資産を 守り抜く防御変⾰を推進 15年以上にわたり、オフェンシブセキュリティ領域に従事。300件を 超える実戦プロジェクトを経験し、国内における関連サービスの⽴ち 上げ・運⽤をリード Red Teamを単なる侵⼊検証にとどめず、攻撃者視点とビジネスリス クに基づく防御態勢・検知設計・対応⼒の再設計を⽀援 2026年より富⼠通 Uvance Wayfinders に参画し、実戦的なサイ バー抵抗⼒の構築と新たな実践型セキュリティサービスの創出を推進 専⾨分野 ・Red Teaming / Adversary Simulation ・ペネトレーションテスト ・Exploit開発 / リバースエンジニアリング ・脆弱性リサーチ (CVE発⾒実績あり) ・Offensive R&D / ツール開発 ・Detection Engineeringとの連携設計 ・OffSec公式トレーナー (CODE BLUE) LinkedIn: https://www.linkedin.com/in/ruslan-sayfiev/ X: @cryptopeg
3. Red Team 攻撃者の視点で、 最⼤のビジネスリスクにつながる攻撃経路を実証する 攻撃経路 / 防御ギャップ / ビジネスインパクト Threat Hunting / 脅威ハンティング 仮説をもとに、 まだアラート化されていない脅威の痕跡を探す 仮説検証 / 痕跡探索 / 新しい検知候補 Detection Engineering 攻撃シナリオをもとに、 次に同じ攻撃が来た時に気づける仕組みを設計する ログ設計 / 検知ロジック / アラート品質 / 対応設計 Purple Team 攻撃と防御を同じ場で検証し、 検知・対応・防御を改善する 検知検証 / チューニング / プレイブック改善 ⽤語の定義と概念整理︓似ているが、役割が違う それぞれ役割は異なるが、攻撃者視点の防御⼒を⾼める上で、どれも重要である
4. 対策の有無ではなく、「攻撃の流れ」が⾒えているか EDRがある ≠ 攻撃全体が⾒える EDRは端末の可視化に強い。 しかし、認証・SaaS・VPN・権限悪 ⽤は範囲外になりやすい。 Red Team演習 ≠ 次回は気づける 演習はスナップショット。 設計・検知・運⽤を変えなければ、 同じギャップが残る。 CSF準拠 ≠ 攻撃経路を⽌められる フレームワークはベースライン。 ⾃社固有の攻撃経路は別途設計する 必要がある。 よくある誤解
5. フレームワークはベースライン。⾃社の攻撃経路は別途設計が必要。 CSF が提供するもの • ⼀般的な管理策の指針 • リスク分類の枠組み • セキュリティ成熟度の評価軸 • コンプライアンス対応の基盤 CSFだけでは具体化できないこと • ⾃社固有の攻撃経路 • 必要なログソースの優先順位 • どこで攻撃者を⽌めるべきか • 検知ルールの具体的な設計 なぜCSF準拠だけでは⼗分ではないのか CSFをベースに、⾃社固有の重要資産・攻撃経路・検知要件を具体化する必要がある
6. 演習はその時点のスナップショット。攻撃⾯は毎⽇変わる Red Team演習は継続的に安全を保証するものではない • ビジネスリスクはスコープに強く依存する • 報告書で終わると、効果は残らない • 個別の脆弱性を修正しても、攻撃経路や設計上の問題は残りうる • 修正できない問題でも、監視・検知は設計できる • 新しいSaaSや例外設定により、攻撃⾯は変わり続ける • 攻撃者の⼿法も変わるため、検知も継続的に更新が必要 なぜRed Team演習だけでは⼗分ではないのか 重要なのは、演習結果を環境設計・運⽤・検知設計に変換すること
7. 攻撃は端末だけで完結しない。認証・SaaS・VPN/ZTNA・権限の可視化が必要。 EDRの主な可視範囲は 端末 認証 IdP / AD データアクセス SaaS / DB / ファイルサーバ 接続 VPN / ZTNA / SASE 横展開 ネットワーク / 端末 / サーバ 権限悪⽤ IdP / AD / PAM なぜEDRがあっても侵害されるのか EDR (回避されても)で⾒えない攻撃経路を他のログソースと相関して確認する仕組みが必要
8. ログを集めることと、攻撃を検知できることは違う Level 1: 製品導⼊ Level 2: ログ統合 Level 3: Detection Engineering
9. 攻撃者モデルをそろえる Initial Access Broker 漏洩・弱い認証情報 リモートアクセス(VPN) フィッシング 外部公開サービス Ransomware Operator 短期間（最⼤影響） データ窃取 暗号化 業務停⽌ APT 標的型・⻑期侵⼊ ゼロデイ攻撃 ステルス・OPSEC 複数回の試⾏ 内部犯罪 正規アクセス 検知が極めて難しい ・「誰を想定するか」を明確にする ・攻撃者モデルごとに、必要なログソースと検知粒度は異なる ・内部犯罪の対策には正規操作のベースライン化が必要 攻撃者によって、狙い⽅も必要な検知も変わる Detection Engineering視点
10. 外から会社はどう⾒えるか 攻撃者は「⼊⼝」を探して、外から⾒える情報だけで攻撃計画を作れる 公開情報 ドメイン/サブドメイン IdP/SSO VPN/ZTNA/SASE SaaS/外部サービス 採⽤情報(製品・スキルセット等) 導⼊事例(製品情報)/技術記事(プロセス等) グループ・⼦会社(同ネットワーク) サプライチェーン/パートナー企業 社員情報/メールアドレス Detection Engineering視点 ・外部公開資産を継続的に棚卸しする ・IdP / VPN / SaaS など「⼊⼝」のログを優先的に確認する ・外から⾒える攻撃経路を、検知シナリオに変換する
11. 攻撃シナリオ︓複数の防御ギャップがつながると 何が起きるか このシナリオは、複数の実務経験と⼀般的な防御ギャップを基に構成したシナリオです。
12. ⼩さな例外、過剰共有された情報、⾒えていないログがつながると、攻撃経路になる 攻撃シナリオ ︓全体概要 OSINT 認証情報漏洩 情報収集 外部監視 → 2 3 IdP/SSO 設定不備 IdPログ → M365リソース 内部情報収集 M365監査ログ 5 → リモートアクセス 設定不備 VPN/SASEログ → 7 特権アカウント AD / 特権操作ログ 業務影響への道 前提︓仮定した防御状況 • EDR︓導⼊済み • IdP︓MFA / アクセス条件付きポリシー導⼊済み • リモートアクセス︓ID/PW + MFA（形式上はMFA） 1 2 3 4 5
13. 攻撃シナリオ①︓認証情報漏洩が攻撃の起点になる 漏洩情報と推測可能なパスワードパターンから、有効な認証情報が特定される OSINT 攻撃者の⾏動 ・漏洩DBから、認証情報を発⾒（デフォルトパスワー ドに類似したもの、使い回しのもの） ・パスワードスプレー攻撃⽤のリストを構築 ・有効なアカウントを発⾒ よくある防御ギャップ ・漏洩情報の継続的な監視がされていない ・デフォルトや推測可能なパスワードの使⽤ ・パスワードスプレー攻撃の検知閾値が設定されていない ・失敗ログインを監視していない ・多数の失敗 → 1件の成功 ・珍しいコンテキストからの初回ログイン Detection Engineering視点 ・漏洩情報の定期的なモニタリングと、該当アカウントの迅速なリセット ・IdPログから短時間の複数認証失敗を検知するルールを設計 ・同⼀IPからの複数アカウントへのログイン試⾏を相関検知
14. 攻撃シナリオ②︓信頼された条件は抜け道になる 例外ルールでアクセス条件付きポリシーを回避し、M365リソースに不正アクセス IdP / SSO 攻撃者の⾏動 ・アクセス条件付きポリシーの判定条件を分析 ・特定のデバイスを偽装することでアクセス条件付き ポリシーを回避 ・MFA回避でM365リソースへのアクセスに成功 よくある防御ギャップ ・アクセス条件付きポリシーがUser-Agentなどの容易に 偽装可能な条件に依存 ・デバイス準拠状態やカスタムパラメータの検証不⾜ ・ポリシー回避の試⾏をログとして記録・監視していない Detection Engineering視点 ・IdPログから想定外のIPアドレス、User-AgentやOS情報を検知するルールを設計 ・⾒慣れない Client ID / App IDやMFAが要求されない許可のログインパターンを検知 ・ アクセス条件付きポリシーの判定結果（許可/拒否）を定期的にレビューし、例外パターンを発⾒ ・同⼀ユーザの異なるデバイスプロファイルからのアクセスを相関検知
15. 攻撃シナリオ③︓M365は攻撃者の地図になる 過剰に共有されたドキュメントから、内部システムの構成と認証情報が漏れる M365リソース 攻撃者の⾏動 ・外部サービスの情報を発⾒ ・平⽂で記載された認証情報を発⾒ ・リモートアクセスや内部環境に関連する情報を発⾒ よくある防御ギャップ ・機密情報を含むドキュメントが全社員に公開されている ・認証情報がドキュメント内に平⽂で記載されている ・SharePointやOneDrive上の⼤量ファイルアクセスが監 視されていない Detection Engineering視点 ・M365監査ログから短時間の⼤量ファイルアクセスを検知 ・DLP（情報漏洩防⽌）でパスワード・証明書を含むドキュメントを検出 ・SharePointやOneDriveの共有範囲を定期的に棚卸し、過剰共有を発⾒
16. 攻撃シナリオ④︓正規接続は正規ユーザを意味しない 取得した証明書と認証情報でVPN接続が確⽴され、内部ネットワークへ侵⼊ リモートアクセス 攻撃者の⾏動 ・取得した情報元にリモートアクセスを確⽴ ・デバイス準拠やカスタムパラメータの検証がなく、 接続に成功 ・攻撃者の端末から内部ネットワークへ直接アクセス が可能に よくある防御ギャップ ・デバイスポスチャ（準拠状態）チェックがない ・証明書とパスワードの「形式上のMFA」が実質的に機能 しない ・新規デバイスからのVPNやSASE接続が監視・アラート 化されていない Detection Engineering視点 ・VPNやSASEログから未登録デバイス・新規デバイスの接続を検知 ・証明書のシリアル番号と発⾏元を照合し、想定外の証明書を検出 ・ VPNやSASE 接続元のIP/地理情報とユーザの通常パターンを⽐較 ・証明書はCAだけでなくCN（Common Name）でも検証し、想定外の値は検知する
17. 攻撃シナリオ⑤︓業務影響への最短経路 特権アカウントを使⽤し、全システムへのアクセスが可能に 特権アカウント 攻撃者の⾏動 ・特権アカウントでADに認証成功 ・全ドメインリソースへのアクセス権を掌握 よくある防御ギャップ ・特権アカウントに関する情報が過剰に共有されている ・特権アカウントの認証成功がアラートにならない ・特権アカウントのパスワードローテーションが実施され ていない Detection Engineering視点 ・特権アカウントの認証は、すべてアラート対象として設計する ・ADログから新規デバイス/IPからの特権ログオンを即時検知 ・リモートアクセス→特権認証の時間的相関で、攻撃チェーンを可視化
18. 改めて、なぜEDRがあっても侵害されるのか EDR は重要。しかし、攻撃経路全体を⾒るには他のログソースとの相関が必要 攻撃ステップ ログソース EDRだけでは不⼗分な理由 パスワードスプレー攻撃 IdPログ クラウド認証イベントは端末外で発⽣する アクセス条件付きポリシー回避 IdPログ クラウド認証イベントは端末外で発⽣する M365リソース探索 M365監査ログ クラウド上の操作イベントは端末ログだけでは追えない リモートアクセス VPN / SASEログ 攻撃者の端末に EDRがない ドメイン管理者権限の悪⽤ AD / 特権操作ログ 認証成功だけではアラートになりにくい 攻撃のステップによって確認すべきログソースは異なる
19. 改めて、なぜRed Team演習だけでは⼗分ではないのか 演習結果を継続的な検知・運⽤に変換しないと、ギャップが残る Red Team は「侵⼊できること」を⽰す。Detection Engineering は「次回は気づけること」を作る。 Red Team テスト実施 報告書 受領 指摘事項を 対応 攻撃 シナリオの レビュー 必要なログ/ テレメトリ の再定義 検知 ロジックの 作成 テスト/ チューニング Red Team Detection Engineering
20. まとめ CSF、EDR、Red Team演習はいずれも重要です。 しかし、それぞれ単独では攻撃経路全体を⾒切れません。 今⽇のポイント • CSFはベースラインを⽰すが、⾃社固有の攻撃経路までは具体化しない • EDRは端末を可視化するが、認証・SaaS・VPN・権限悪⽤までは⾒切れない • Red Teamは攻撃経路を明らかにするが、結果を運⽤に落とし込まなければ継続的な防御⼒に はならない • 攻撃者は、⼩さな例外・過剰共有・⾒えていないログをつなげて攻撃経路を作る 重要な考え⽅ 必要なのは、個別の対策を増やすことだけではなく、攻撃シナリオをもとに、必要なログ・検知・ 相関・運⽤を設計することです。