Webサービス事業会社におけるEDRの検討と導入の事例 /falcon2019

Transcript

1. Webサービス事業会社における EDRの検討と導入の事例 クックパッド株式会社 水谷正慶
2. 本日のトピック •EDR導入のきっかけ •PoCの評価項目と評価結果 •CrowdStrike Falconの導入 •CrowdStrike Falconの運用 •今後の展望
3. 講演者自己紹介 •水谷 正慶 (@m_mizutani) •クックパッド株式会社 (2017.11〜) ‣ 技術部セキュリティグループ グループ長 ‣ セキュリティ監視基盤の設計・構築・運用を主に担当 •前職ではSOCアナリストやSIEMに関する研究開発など
9. クックパッドでセキュリティをやる意味 •新しい事業やサービスの改善をするにあたって多くの 変化が起きるが、同時に問題が起こりやすくなる •事業になるべく影響を与えずに、事前に問題を防ぐ＆ 問題があっても対応できる体制を整える必要がある
10. EDR導入のきっかけ
11. 社内環境 •MacBook (macOS): 500台 •Surface Pro 4 / Laptop (Windows 10): 80台 •OSは原則として最新のバージョンを使用 •エンジニア・デザイナ・総合職に関わらず原則MacBookを支給 ‣ エンジニア・デザイナで全体の4割強 •WindowsはActive Directoryでアカウント管理 (Azure AD Joinに移行中) •macOSはローカルユーザのみ(ディレクトリ管理していない) •恵比寿オフィスの社内ネットワークにはPaloAltoのNGFWを導入
12. Falcon以前の製品選定 •Falcon以前に利用していたアンチウイルスの選定基準 ‣ macOS / Windows両対応 ‣ WindowsよりもmacOSでの機能面 ‣ 特に開発環境でのオーバーヘッドが低いことを重視 ‣ オンプレミスの管理サーバを必要としないこと •APIやログの保存などは重視していなかった ‣ 製品から提供されるコンソールをそのまま使用 ‣ 定期的にデータをエクスポート(csv)し、手作業で集計
13. Falcon以前の導入製品における課題 (1/2) 1. 開発環境を含め、社内環境はほぼmacOSに揃えている ‣ Windowsに比べ、macOSのサポートが貧弱な製品が多い ‣ macOSのアップグレードへの対応が遅かった • iOSアプリ開発などでOSのアップグレードが必要 ‣ iOS SimulatorなどXcode関連でfalse positiveが度々発生 • 複数台から突然大量のアラートが発生することもあった
14. Falcon以前の導入製品における課題 (2/2) 2. アラートに含まれる情報が不足していた ‣ ファイルシステム上の活動のみ（パスやファイルハッシュ） ‣ 追跡調査できずにインシデントをクローズすることが度々 3. 通信イベントの監視を行いたい ‣ ファイルに対する監視だけでは不十分 • どのような経路で該当ファイルがドロップされたのか、外部との通信は存在したか、な どの追跡を行いたい ‣ NGFWなどの通信ログと突合して詳細な分析をしたい
15. PoCの評価項目と評価結果
16. 評価にあたって •PoC実施前に、予め必要項目を提示 ‣ 最低限出来て欲しい機能と、これが出来ると嬉しい機能 ‣ 一覧を表にして共有 • いわゆる星取り表という意図ではなく、PoCでどういった点を見るのか、どのような機能 を重視しているのかを予め整理して明確化するための資料 •社内環境の説明 ‣ 前述の選定要件など •PoCは検討対象の製品それぞれで1ヶ月弱
18. 評価項目と結果 (1/5) 1. 負荷が十分に小さい ‣ git grepやJavaプロジェクトのビルドが遅くならないこと • 10秒程で終わるはずのコマンドが5分になってしまう • .classファイルを監視から外すなど、微調整したことも ‣ 通信をフックして独自のローカルプロクシで監視する製品 • 遅延の他に、特定条件下でHTTPパケットが壊れる • エージェントが暴走して通信不能になることも 2. 開発環境におけるfalse positiveが少ない ‣ 開発の妨げになる・件数が多いと狼少年に 検証 項目 検証 項目
19. 評価項目と結果 (2/5) 1. 負荷・false positiveについて ‣ エージェントを入れた端末に、実際に開発環境を一から構築 • rubyビルドやライブラリの取得、iOS/Android開発環境 • 正常に起動するか、また起動時間が長くならないか • 他の製品では環境構築自体ができないものも存在した 2. 候補がFalconにほぼ絞られてきた時点で、社内各部署のエンジニアの協力を得 て、実際の開発環境にも導入し検証 ‣ false positiveも含め問題は起きなかった 検証 結果 検証 結果
20. 評価項目と結果 (3/5) 3. イベントの検索機能 ‣ ファイルハッシュ、IPアドレス、通信先ドメイン名などをキーに横断的に検索ができるか • アラートに含まれる情報を用いて周辺イベントを調査 • 検索結果に対してpermanent linkを作成できると嬉しい • APIによるイベントの取得 • コンソールで出来ることがAPIで提供されているか - アラート情報もAPIで取得したい - 時間あたりの回数制限にも注意が必要 検証 項目
21. 評価項目と結果 (4/5) 4. ログの転送 ‣ コンソールで得られる情報がそのままログとして外部から取得できるか • httpsなど標準的な暗号通信経路で取得したい • 保存先がクラウド環境なので、syslogは厳しい ‣ ログはs3に保存して永続化 • 監査にも対応できるよう年単位で保持しておきたい ‣ ログ出力のタイミング • 転送可能になるまで時間がかからないものが望ましい 検証 項目
22. 評価項目と結果 (5/5) 3. イベントの検索・APIについて ‣ コンソールの検索機能は問題なかった ‣ APIから利用できる検索機能は希望を満たすものではなかったが、転送したロ グに対して自前で検索を行う方針に転換したため、APIによる検索を必要とし なくなった 4. ログの転送 ‣ Falcon側のs3バケットに保存されたログを、Data replicatorを用いることで 任意のs3バケットにコピー可能(5分毎) 検証 結果 検証 結果
23. CrowdStrike Falconの導入
24. EDRのシステム統合における弊社の機能要件（おさらい） 1. APIでアラート（検知情報）を受け取れること ‣ 既存の弊社セキュリティ監視システムと統合する ‣ アラートの通知や対応状況の管理 2. プログラムからログの検索ができること ‣ Falconが検知したアラートについての調査 ‣ 他のセキュリティ監視装置が検知したアラートの調査
25. 全体のアーキテクチャ概要
26. イベントログの取り込み詳細 SQS+S3から直接ログを ダウンロード 全てのログをまずS3バケット に保存して可用性確保 検索を効率的にするためファイル形式を 変換して別バケットに保存 OSSであるGraylog + Elasticsearchで 直近のログをインタラクティブに検索 長期的に保存された ログの検索に利用 https://github.com/m-mizutani/aws-falcon-data-forwarder
28. イベントログの取り込み設計のポイント (1/2) •Falconの S3 + SQS というログの出力方法を活用 ‣ 他製品だとsyslogで転送する形式が多かったが障害発生時のリカバリ対応が困難と いう問題があった ‣ Falcon側のS3に一定期間ログが保存されているので転送のやり直しが容易・弊社 側で流量の調整が可能 ‣ S3に保存してから各種処理をする既存の仕組みとの相性が良かった •弊社環境へ転送した際もまずはS3に格納する ‣ S3の可用性＆スケーラビリティの高さ、価格の安さを活用
29. イベントログの取り込み設計のポイント (2/2) •短期的なログはGraylogに格納して他のログも含めた横断的検索を実現 ‣ ログ種別に応じて1週間〜1ヶ月程度 ‣ 高速でinteractiveな横断的ログ検索が可能 • 例）C&CサーバのIPアドレスでログ抽出し通信が発生していたかなど確認 • 例）アラートに関連したユーザ名でログ抽出しアラート前後の行動を把握 •Athenaで長期保存されているログの検索 ‣ GraylogはDB（ストレージ）が高価なので長期的な検索はS3を利用 ‣ 監査的な利用およびインシデント発生時の追跡用
30. 検知情報（アラート）の取り込み詳細 EventStream APIは長時間HTTPのセッション を維持する必要があるためコンテナ上で ツール (falconstream※1) を使用 イベントと同様にまずは S3バケットに集約 イベントの中から アラートの抽出 アラートに関連する情報 を内部・外部のデータか ら検索しアラートに付与 自動的にリスク判定を実施した後、エン ジニアが対応すべき案件を起票・通知 https://github.com/m-mizutani/falconstream
31. 検知情報（アラート）の取り込み設計ポイント •共通したアラート対応基盤を利用する ‣ Falcon以外のアラートも共通のインターフェースで扱える •対応開始までの時間差を許容できるかの検討 ‣ アラートが発生してから発報されるまで4〜5分遅延がある ‣ 自社内の対応スピードと照らし合わせて許容範囲と判断 •自動化できる部分はなるべく自動化する ‣ 検出されたIPアドレスやドメイン名の調査などは自動的に実行 ‣ 調査のための時間を短縮し、人間の時間を有効に使う
32. CrowdStrike Falconの運用
33. 対応フロー •アラート管理システムからSlackに通知 ‣ 担当者への通知＆チームへの共有 •担当者が調査 ‣ 一部情報は自動的に取得されてGithub EnterpriseのIssueに書き込み ‣ Graylogなどを使って担当者がアラートを調査 ‣ 調査結果や進捗をIssueにコメントし、対応完了したらCloseする
34. Slack上で初動対応とGHEへの記録
35. 今後の展望
36. 今後の展望 •独自ルールの開発と運用 ‣ 社内環境にあわせた脅威検知 •IoC情報の検索 ‣ 取り込んだログを使ってIoC情報を検索する ‣ 後から判明するIoC情報も多いため時間差での対応が必要