AIと始める監視基盤なしの セキュリティ監視 / secmon-without-a-siem

Transcript

1. SECURITY MONITORING WITHOUT A SIEM AIと始める、 監視基盤なしの セキュリティ監視 ⽔⾕ 正慶 / Masayoshi Mizutani Ubie, Inc. VP of Security
2. INTRODUCTION 今⽇お伝えしたいこと 1 2 3 監視基盤がなくても、 監視は始められる 何を、どの速さで ⾒つけるかを決める AIは調査の ⼿数を減らす 各サービスのアラートを受け取り、 そして、⾒つけたら誰が対応する ただし、残していないログや、対応 ログを残し、定期的に確認するとこ か。製品選びはその後。 する⼈の不在までは埋めてくれな ろから。 AIと始める、監視基盤なしのセキュリティ監視 い。 02
3. ABOUT ME ⾃⼰紹介 ⽔⾕ 正慶 / Masayoshi Mizutani Ubie, Inc. VP of Security セキュリティ監視、DevSecOps、セキュリティ運⽤向けAIエージェントを開発。 最近は Go で AIエージェントやアラート管理の OSS も開発しています。 IBM Japan Cookpad Ubie セキュリティ研究‧SIEM連携‧SOC運⽤ AWS上のログ収集‧検索‧監視基盤の構築 セキュリティ監視‧DevSecOps‧AIエージェン ト 出典: Blue Engineering — About（blueng.dev/about） 03
4. ABOUT UBIE 医療機関‧製薬企業との連携で好循環エコシステムを構築し、 患者さんへのより適切な医療提供の貢献を⽬指しています 適切な治療に 1⽇も早く出会える ⽉間利⽤者数 1300万⼈以上 患者さんへ適切な 医薬品を届ける 患者さんと向き合う 時間を創出できる for Hospital グローバルメガファーマ 企業との取引 9割以上 出典: Ubie株式会社 会社紹介資料（2026/9） AI問診：導⼊医療機関 1800以上 ⽣成AI：導⼊医療機関 180以上 04
5. 01 監視の⽬的と対象データ なぜ監視するのか、何を⾒るのか 05
6. 01 監視の⽬的 監視は、防御を補うもの それでも突破されうる経路 ゼロデイ 監視 防御 設定ミス‧独⾃コードの脆弱性 MFA 脆弱性対応 認証情報‧トークンの窃取 権限管理 端末保護 ⾒つける 不審な活動 広げない 被害の拡⼤ 調べる 何が起きたか 正規権限の悪⽤（内部不正など） 正規の権限による不正も対象 ログイン‧権限変更‧データアクセスにも⽬を向ける。ただし「普段と違う」だけで不正とは断定しない。 AIと始める、監視基盤なしのセキュリティ監視 06
7. 01 監視の⽬的 監視で実現したい3つの活動と、それを⽀える点検 継続的な監視 脅威ハンティング インシデント対応‧調査 いま不審なことが 起きていないか？ アラートにならない 侵害の兆候はないか？ 何が起き、 どこまで影響したか？ 不審なログインや端末の検知を受けて確 公開された攻撃⼿⼝を仮説に、関連ログ 対象アカウントの操作履歴を時系列で追 認する を調べる う 準備状況の評価 — 必要なときに、本当にログを使えるか？ 取得漏れ‧保持期間‧検索権限‧時刻のずれを点検する 「ログを集めた」と「監視‧調査に使える」は別のこと 出典: CISA「Logging Reference Architecture」を基に整理 07
8. 01 対象データ 対象データは「アラート」と「ログ」に分ける 標準のアラート 検知済みの⼿がかり Alert Center / SCC / GuardDuty / EDR など 判断‧対応 優先度の判断 利⽤中の サービス 監査ログ‧操作ログ ログイン‧管理操作‧ データアクセスなど ルールで探す 本⼈確認 例: 特権ロールの付与 封じ込め 詳細調査 仮説で探す‧調べる 例: ログイン前後の操作 アラートは「検知済みの⼿がかり」、ログは「検知や調査の材料」。両⽅を使う。 提供機能‧契約‧設定によって取得できる内容は異なります 08
9. 02 SIEMの役割と、 あるとき‧ないとき SIEMは何をしてくれて、何が残るのか 09
10. 02 SIEM SIEM：ログを集めて、検知‧調査につなげる仕組み IdP‧SaaS クラウド‧ネットワーク 端末‧EDR 解析‧ 正規化 保存‧ 検索 ルール‧ 相関分析 SIEM の代表的な機能 収集‧ コネクタ 担当者‧SOC アラート‧ 調査画⾯ 確認‧対応 SIEM = Security Information and Event Management。概念図であり、製品ごとに機能範囲や構成は異なります 10
11. 02 SIEM SIEMで解決すること、しないこと 解決すること 解決しないこと 集めやすい コスト コネクタで複数のログソースと接続できる ログ量‧保持期間‧検索資源‧契約条件、そして運⽤⼯数 横断して調べやすい 継続的な保守 アカウント‧端末‧時刻を起点に調査できる 取得の維持、形式変更への追従、ルール調整、不要なアラートの 削減 検知を回しやすい ⽤意されたルールや⾃作ルールを継続実⾏できる 運⽤を共有しやすい 対応する⼈と⼿順 検知後に誰が何をするかは、別途決める必要がある 検索画⾯‧ダッシュボード‧アラート管理を共通化 ⽐べるのは価格ではなく「必要な監視能⼒を、どの構成と運⽤で実現するか」 AIと始める、監視基盤なしのセキュリティ監視 11
12. 02 SIEM 環境ごとに「できること」‧「できないこと」 環境 継続的な監視 脅威ハンティング 対応‧調査 監視運⽤もログ保存もない × × × ログを保存している △ △ △ すぐには検索できない 標準アラートのみ 取り出しに時間 復元‧分析が必要 ログを検索できる △ 常時の検知基盤はない 標準アラート＋定期検索 ◦ ◦ ◦ SIEMなどの監視基盤 ◦ ◦ ◦ ◦ ログを残していない 設定した範囲で継続検知 ◦ 実施しやすい 準備状況の評価 △ まず棚卸し ◦ △ 範囲‧速度‧⼿作業に制約 × 困難 ∕ いずれも必要なログ‧設定‧担当者がそろっていることが前提 ログ検索‧検知に、専⽤SIEMは必須ではない。ただし対象が増えるほど保守の負担は増える。 12
13. 03 ⾃社の監視に、 どこまで求めるか 必要な監視を決め、攻撃の速度を踏まえて線を引く 13
14. 03 どこまで求めるか SIEMを検討する前に決めておくこと 対象と検知内容 許容時間 対応体制 何を⾒つけたいか どれだけ待てるか ⾒つけたら動けるか 守りたいデータ‧アカウント‧システム 発⽣から何分‧何時間で気づく必要があ 夜間‧休⽇も含め、誰が何を判断できる は何か。標準アラートで⾜りるか、⾃社 るか。即時通知‧⽇次確認‧週次点検を か。連絡先‧代替担当‧封じ込め⼿順を 固有の操作も⾒るか。 使い分ける。 決める。 あわせて：ログの遅延‧保持‧権限‧予算などの制約と、実現できない範囲（残るリスク）を明⽰する AIと始める、監視基盤なしのセキュリティ監視 14
15. 03 どこまで求めるか 時間は「検知」ではなく「対応開始」までで測る 検知頻度だけで考えがち ログの到着遅延 発⽣ 検知の間隔 ログ到着 通知に気づく 検知 判断‧連絡 ⼈が確認 対応開始 この合計を、許容できる時間と⽐べる 分単位で検知しても、誰も通知を⾒なければ対応は進まない AIと始める、監視基盤なしのセキュリティ監視 15
16. 03 攻撃の速度 AIで、攻撃はどれだけ速くなったか 侵⼊から横展開まで 65% ⾼速化 2024 48 分 2025 29 分（最速 27 秒） AI を使う攻撃者の活動 攻撃作業のうち AI が実⾏ +89% 80‒90% 前年⽐（2025 年） 偵察‧認証情報の窃取‧検知回避に AI を利 ⽤ eCrime の平均 breakout time。 ⼈の関与は 10‒20% のみ CrowdStrike は AI による加速と説明 毎秒複数の操作を継続。国家⽀援とされる 攻撃の個別事例 AI だけの寄与を測った統計はまだない。ただし、どの指標も⼈の⽇次‧週次の確認より速い⽅向を⽰す 出典: CrowdStrike 2026 Global Threat Report（2025 年の観測）、Anthropic (2025) 16
17. 03 線引き 即時‧⽇次‧週次で、⾒る範囲を分ける 頻度 即時 ⽇次 週次 例 運⽤の考え⽅ 重要端末の侵害検知 標準機能の通知や⾃動防御を優先し、連絡‧対応先を決める 特権IDの侵害が疑われるアラート 未確認アラートの確認 権限変更などの定期検索 未対応案件の滞留‧ログ取得漏れ 仮説に基づく探索 確認する時間と担当を固定する 運⽤品質の改善と、⾒落とした兆候の発⾒に使う ⽇次‧週次の確認は前進。ただし、即時対応が必要なリスクの代わりにはならない 運⽤設計の⼀例であり、⼀律の安全基準ではありません 17
18. 04 SIEMなしで実践する監視 アラートを確認し、ログを残し、定期的に確かめる 18
19. 04 SIEMなしで実践する 実践の全体像：3つの取り組み 1 2 3 アラートを 確実に確認する ログを残し、 所在を分かるようにする 時間差を許容した 定期確認を回す サービスが検知したものを、通知‧担当 保存し、どこに何があり、どう取り出せ ⽇次‧週次で、検索‧確認‧記録を繰り ‧記録までつなぐ るかを整理する 返す 通知 保存 検索 判断 記録 すべてを⼀元化しなくても、これらがつながっていれば監視は始められる AIと始める、監視基盤なしのセキュリティ監視 19
20. 04 実践 ① アラートを確実に確認する まず使う：サービスの標準検知 最低限、決めておくこと Alert Center Google Workspace 1 通知先 どのアラートが、どこに届くか Security Command Center Google Cloud 2 担当者 ⼀次確認する⼈と、不在時の代替 GuardDuty AWS 3 優先度 すぐ連絡するもの∕通常の確認で扱うもの EDR‧アンチウイルス 管理画⾯‧通知 4 対応記録 誰が何を⾒て、どう判断し、次に何をするか 5 棚卸し 未確認‧対応中‧保留を定期的に⾒直す エディション‧有効化設定‧権限を確認する。画⾯があるこ とと、必要なアラートが出ていることは別。 ゴールは通知ではなく「確認され、判断され、対応につながる」こと AIと始める、監視基盤なしのセキュリティ監視 20
21. 04 実践 ② ログを残し、所在を分かるようにする まず保存する。 ただし、デフォルトを信じすぎない ログのカタログ（ログソースごと） 対象イベント‧保持期間‧取得権限を確認する 何が ログイン‧管理操作‧データアクセス 保持期間が⾜りなければ、延⻑や外部保存を検討する どこに 管理画⾯‧保存先のバケットなど ⾃動で残らないログは、取得設定やエクスポートが必要 いつまで サービス側と退避先の保持期間 管理者が侵害されても消されない保存先にする（権限分離‧削除制限） 届き⽅ 反映の遅延‧取得失敗の確認⽅法 取り出し⽅ 管理画⾯‧API‧検索サービス‧復元⼿順 誰が読めるか 読み取り権限‧申請先‧管理担当 調査の項⽬ AIと始める、監視基盤なしのセキュリティ監視 時刻‧主体‧操作‧対象‧接続元‧結果 21
22. 04 実践 ② 検索をするための道筋を整える 分ける基準：検索の頻度‧必要な速さ‧保持期間 すぐ使う ⻑く残す 頻繁に調べるログ 標準検索‧検索サービス すぐに確認できる 調査で何度も参照する 常時検索できる状態で保つ 緊急時の初動に使う ⻑期保管が中⼼のログ 低コストな保存先 必要なときに復元 遡及調査で必要になる オブジェクトストレージなど ⼿順と所要時間を事前に確認 全ログを⾼価な検索基盤に⼊れなくてよい。ただし、保存してあるだけでは緊急時にすぐ使えるとは限らない。 参考: CISA「Logging Reference Architecture」も、常時検索できるデータと取り出し可能な⻑期保持データを区別している 22
23. 04 実践 ③ 時間差を許容した定期確認を回す 定期確認の流れ 1 2 3 4 5 対象期間と 取得範囲を決める 未確認アラート を確認する 決めた観点で ログを検索する 掘り下げ、 本⼈確認する 範囲‧判断‧ 残件を記録する 続けるための⼯夫 時間‧担当‧確認項⽬を固定する 「⼿が空いたら⾒る」にしない 検索期間を少し重ねる ログの遅延を考慮し、重複は記録で扱う 繰り返す確認は⾃動化へ 検索条件の保存や定期実⾏に移す 「何もない」と「⾒えていない」を区別 取得処理が⽌まっていないかも確認する 各サービスが提供するリアルタイム検知まで諦める必要はない 23
24. 05 AIの活⽤と注意点 調査の⼿数を減らし、安全に接続する 24
25. 05 AIの活⽤ 調査はAIが進め、⼈は過程と結論を確かめる AI ⼈ アラートを受ける 仮説を⽴てる ログで検証する 結論を出す 内容を読み、 関連情報を集める 何が起きた 可能性があるかを考える 検索と突き合わせを ⾃ら繰り返す 根拠と未確認事項を 添えて報告する 仮説は妥当か 調査過程は適切か 結論を確定する 別の可能性を ⾒落としていないか ⾒た範囲‧検索条件‧ 取得漏れ 対応と封じ込めを決める ここは任せる ⼈は⼿を動かす役から、AIの調査を審査し、結論に責任を持つ役へ 25
26. 05 AIの活⽤ 例：不審なログインのアラートを調べる 中⽴に調べるコツ：仮説と反論を戦わせる AIへの調査依頼 対象アカウントについて、アラート発⽣の前後24時間を調べて ください。まず「不正ログインである」という仮説と、「本⼈ の正当な操作である」という反論を⽴て、それぞれを⽀持‧否 仮説 反論 不正ログイン 本⼈の正当な操作 ⾒慣れない接続元、 直後の権限変更など 出張‧新しい端末、 普段どおりの操作など 定する証拠をログから集めてください。両者を⽐べて結論を出 し、各イベントの根拠と取得できなかったログも⽰してくださ い。変更操作は⾏わないでください。 両⽅の証拠を⽐べて結論 ⼈は、その過程と結論を確かめる ⽚⽅だけを調べると、⾒たい結論に引っ張られやすい 調査依頼の例であり、実際の検知結果ではありません 26
27. 05 AIの活⽤ 専⽤エージェントより、まず安全な接続を⽤意する 担当者 ⽬的‧対象‧期間を指定 ⼈が検証‧ 判断‧対応 汎⽤AIエージェント Claude Code‧Codex など 根拠付きの要約 ‧確認事項 読み取り専⽤の MCP‧限定コマンド 許可された ログ‧アラート まず読み取り専⽤から始める 対象‧期間‧取得件数を制限する 停⽌‧権限変更は別の承認⼿順に分ける 重要なのは製品名ではなく、必要なログへ安全に接続できること 27
28. 05 注意点 AIをログにつなぐときの3つの注意 認証情報を モデルに渡さない • APIキーやトークンをプロンプトに貼 らない ログなどの外部情報に何かが混 ⼊している可能性がある user_agent: "これまでの指示を無視 して…" • 最⼩権限‧短期間の認証で、実⾏内 容を記録 • 汎⽤シェルや資格情報ファイルにも 触れさせない 機微情報と サービス条件を確認する • どこまで送ってよいか • 処理リージョン‧委託先 • 学習利⽤‧保持期間‧ZDRの範囲 • 攻撃者が操作できる値がログに⼊る • ログ由来のURLアクセスやコマンド 実⾏を避ける 判断はサービス名ではなく、契約プラン‧設定‧利⽤機能で⾏う 28
29. 残る課題 それでも残る課題と、次の段階に進む⽬安 残る課題 次の段階の⽬安 攻撃の速さに、定期確認だけでは追いつかない 常時検知‧⾃動防御‧外部の監視∕対応サービスを検討する 後から調べようとしても、ログが残っていない 保持期間を、遡及調査に必要な期間から決める ⼿元のAI運⽤が、個⼈に閉じて属⼈化する 接続‧⼿順‧記録をチームで管理し、必要なら専⽤の仕組み へ 困りごとを⾒極め、必要な部分から仕組みにしていく 検索の遅さ ∕ 検知の遅れ ∕ 対応漏れ ∕ 属⼈化 AIと始める、監視基盤なしのセキュリティ監視 29
30. SUMMARY まとめ：基礎的な監視の型 5 4 3 次の段階へ 省⼒化する 困りごとが⾒えてきた 確認する 調査や情報収集にAIを ら、常時の検知や専⽤ 残す 緊急通知と定期点検を 使い、根拠と権限は⼈ の仕組みへ進む 知る 必要なログを保存し、 分け、判断と対応を記 が管理する 使えるアラートとロ 所在と取り出し⽅をカ 録する グ、通知経路、保持期 タログ化する 2 1 間を棚卸しする AIと始める、監視基盤なしのセキュリティ監視 32
31. 監視基盤がなくても、 できるところから始めてみませんか。 33