Falconを活かした インシデントレスポンスとの向き合い方

ファルコミ Meetup登壇資料（2025/5/30）

Transcript

1. Falconを活かした インシデントレスポンスとの向き合い方 1
2. 1. はじめに 2. Falcon Device ControlによるUSBデバイス制御 3. Spotlightによる脆弱性管理 4. ワークフローを用いたEOS・RFMの検知 5. FalconPyを活用したEDR導入対象の管理 6. 今後のロードマップ 7. 総括 構成
 2
3. はじめに 3
4. ▪ 自己紹介 1. はじめに 
 4 株式会社アカツキ 安永 貴之 ▪ 普段の業務内容 ◦ 主にコーポレートセキュリティに関 する業務を実施 ◦ インシデントレスポンス ▪ Falcon利用歴 ◦ 前職で4年、現職で2年ほど ◦ 計６年弱くらい
5. ▪ アカツキでは日常的にEDRが発するアラートの分析や利用者へのヒアリ ングに加えて、EDRの正常性に重きを置いたチェックの仕組みを作り運 用しています ▪ 具体的には以下の取り組みを行っています ◦ Falcon Device ControlによるUSBデバイス制御 ◦ Spotlightによる脆弱性管理 ◦ ワークフローを用いたEOS・RFMの検知 ◦ FalconPyを活用したEDR導入対象の管理 ▪ 前提として個人端末・サーバいずれもEDRを導入するセキュリティポリ シーに則って運用しています 1. はじめに 
 5
6. Falcon Device Controlによる USBデバイス制御 6
7. ▪ Falcon Device Controlとは？ ◦ USBデバイスに関して、接続された際に取得できる情報を基に接続 や実行の可否を制御できる機能 ◦ 製品固有のシリアルナンバーだけでなく、ベンダーIDやプロダクトID も併せて取得できるため、特定メーカーや特定製品のみ利用可能と いったような制御も ◦ 逆に特定メーカーの製品のみ制限をかけることも可能 ▪ 例えば... • 製造段階時からマルウェアが混入していたケースなどもメー カー単位でフルブロックする等 2. Falcon Device ControlによるUSBデバイス制御 7
8. ▪ ダッシュボード例 ◦ USBデバイスに関わるものは全て検出されて列挙 2. Falcon Device ControlによるUSBデバイス制御 8
9. ▪ アカツキでは会社貸与しているデバイスを許可対象とし、Mass Storage に分類されているデバイスのみをコントロールの対象と している ◦ 書き込み・読み込み・USBから直接実行の３パターンを制御 できる ◦ ホワイトリスト運用で読み込み・書き込みの２つを許可 ◦ その他のデバイス（私物など）に関しては読み込みのみ可能 ▪ 分類を複数持つデバイスもあるが、同一デバイスでも制限をかけた機能 部分にのみ影響がある 2. Falcon Device ControlによるUSBデバイス制御 9
10. ▪ IT Service部と連携し、USBデバイス貸与申請のチケットが作成されたタ イミングで例外登録を実施 ◦ 貸与前に一度接続し、ブロックログからデバイスのシリアル ナンバーを取得し例外登録する ◦ 事業規模や貸与の頻度によってオペレーションが増加するので情シ ス部門との連携は必須 2. Falcon Device ControlによるUSBデバイス制御 
 10
11. Spotlightによる脆弱性管理 11
12. ▪ Spotlightとは？ ◦ Discover(資産管理機能)のオプション ◦ 脆弱性スキャナを含んだ管理機能 ◦ サポートされているCVEを起点にダッシュボード上から 脆弱なホストを洗い出せる ▪ 早いものだとCVEが公開されてから2営業日以内には サポートされている印象 ◦ ホストグループがそのまま利用できるため、優先度の高い アセットを事前に分類しておくと対応しやすい 3. Spotlightによる脆弱性管理 
 12
13. ▪ CVEベースとホストベースの表示を切り替えて活用 ▪ ホスト表示にすると対象に含まれている脆弱性の総数判別に役立つ ◦ 長期間アップデートが放置されたホストを優先的に発見できる ▪ CVE表示にするとリリースされたばかりの脆弱性の影響範囲が判別しや すい 3. Spotlightによる脆弱性管理 
 13
14. ▪ 脆弱性の対応優先度づけで見るポイント ◦ CVEベースでは... ▪ Exploit statusを見て脆弱性が攻撃に利用されているか判別 ▪ Productで対象がメジャーな製品かを確認 ◦ ホストベースでは... ▪ Internet exposureを見て外部公開されているホストかを判別 3. Spotlightによる脆弱性管理 
 14
15. ▪ ホスト毎にこれまでのパッチ適用履歴や再起動待ちといったステータスが 確認できる 3. Spotlightによる脆弱性管理 
 15
16. ワークフローを用いた EOS・RFMの検知 16
17. ▪ EOSとRFMについて ◦ EOS(end of support)：サポート切れ ◦ RFM(reduced functionality mode)：機能制限モード ◦ いずれの状態もEDRとして正常動作をしない ◦ 特にRFMにおいてはハートビートのみの動作となるため、 すぐに何らかの対応が必要 ▪ なぜ発生する？ • センサーがユーザモードとカーネルモードいずれの動作も要 件を満たしていないため • “sudo /opt/CrowdStrike/falconctl -g --rfm-reason“ 4. ワークフローを用いたEOS・RFMの検知 
 17
18. ▪ ワークフローからサーチクエリをスケジュールし、該当ホストがいれば Slackへ通知 4. ワークフローを用いたEOS・RFMの検知 
 18
19. ▪ Slackへの通知例 ◦ AmazonLinuxは更新頻度が高いので常に最新バージョンを利用し ていると常にRFMで運用している状態になりがち ◦ Patch Tuesday直後のWindowsもRFMになる 4. ワークフローを用いたEOS・RFMの検知 
 19
20. FalconPyを活用した EDR導入対象の管理 20
21. ▪ FalconPyとは？ ◦ Pythonスクリプトで動作するSDK、無料で利用可能 ◦ FalconのAPI操作に特化している ◦ JSONでデータを取得できるため、データの加工・操作も 含めて他ツールとの連携が行いやすい 5. FalconPyを活用したEDR導入対象の管理 
 21
22. ▪ アカツキでの活用例 ◦ Public IPが設定されていてEDRが入っていないホストを 洗い出す目的で利用 ▪ 攻撃対象領域になりうる ▪ EDR未インストールだとWeb上のダッシュボードから 存在確認ができない 5. FalconPyを活用したEDR導入対象の管理 
 22 os version check 
 Host data
 Host ID
 comparison
 notice

23. ▪ Slackへの通知例 ◦ 各プロジェクトのサーバ管理者グループへ自動で通知 ◦ これを起点にしてPublic IPを無効化してもらうかEDRを入れてもらう か打診する 5. FalconPyを活用したEDR導入対象の管理 
 23
24. 今後のロードマップについて 24
25. ▪ Falcon Device Control部分 ◦ Bluetoothの制御機能も追加されたので悪用方法と予防策を考えて 運用設計していく ◦ Enhanced file metadata collectionを利用し情報持ち出しにも対応 させる ▪ Spotlight部分 ◦ サポート対象の脆弱性が追加された際に通知を出すように改良し、 即応性を向上させる ▪ FalconPy部分 ◦ 外部から取得したIoCを自動で取り込み適用する仕組みづくり 6. 今後のロードマップについて 
 25
26. 総括 26
27. ▪ EDRを用いても100％全てのインシデントを防ぐことはできない ▪ 常日頃からインシデントのきっかけになりうる穴を塞いでいくことが重要 ◦ そのためにも... ▪ 致命的な脆弱性が適切に封じ込めできているか ▪ 外部からのマルウェア持ち込みが防止できているか ▪ カバレッジを認識しておく ◦ 前提として ▪ 必要なホストにEDRが導入されているか ▪ EDRの機能は正常に動作しているか ▪ 古いセンサーバージョンがサポート切れでないか 7. 総括 
 27
28. ▪ 一般的には他のソリューションと組み合わせをしないと適切な管理ができ なかった ◦ 資産管理ソフトや脆弱性管理サービスなど ▪ 端末にインストールしたエージェント一つの機能で包括的に管理 できるのはとてもコスパが良い ▪ メジャーな機能以外のオプション部分にも目を向けると、組織で よくある困りごとへの解決策になりうる ◦ 多層防御の観点も忘れず、ご利用は計画的に ▪ EDRバイパスに対する回避策がどの程度効いているかリスト化されてる と嬉しい ◦ 皆さんどうやって検証してますか？ 7. 総括 
 28
29. ご清聴ありがとうございました 29