Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Webサービス事業会社におけるEDRの検討と導入の事例 /falcon2019
Search
Masayoshi Mizutani
November 22, 2019
Technology
1
690
Webサービス事業会社におけるEDRの検討と導入の事例 /falcon2019
Masayoshi Mizutani
November 22, 2019
Tweet
Share
More Decks by Masayoshi Mizutani
See All by Masayoshi Mizutani
汎用ポリシー言語Rego + OPAと認可・検証事例の紹介 / Introduction Rego & OPA for authorization and validation
mizutani
1
410
Ubieにおけるセキュリティ課題管理の自動化 / ubie-sec-issue-automation
mizutani
0
740
Trivy + Regoを用いたパッケージ脆弱性管理 /trivy-rego
mizutani
7
4.2k
リモートワークを支える 社内セキュリティ基盤の構築と運用 /secueiry-for-wfh
mizutani
0
660
SOARによるセキュリティ監視業務の効率化とSecOps /soar-and-secops
mizutani
1
1k
Amazon Athena を使った セキュリティログ検索基盤の構築 /seclog-athena
mizutani
5
2.7k
AWS re:Inforce recap 2019
mizutani
1
4.2k
スケーラブルなセキュリティ監視基盤の作り方 /techconf2019-mizutani
mizutani
3
3.1k
Webサービス事業会社におけるEDRの検討と導入の事例 /falconday201812
mizutani
3
2.3k
Other Decks in Technology
See All in Technology
Dojo 20240830 COBOL to Java on Z
ichikawayasuhisa
0
240
HolidayJp.jl を作りました
mrkn
0
110
contenteditableと向き合う
kikuchikakeru
2
140
ことばをそろえる / Bridging the Terminology Gap
amaotone
5
1k
Dive Deep in Cloud Run: Automatic Base Image update
aoto
PRO
0
900
日経電子版から始まった内製開発の現在地と向き合っている課題/inhouse
nishiuma
0
230
SHIFTの課題と目指したい組織像 / 20240827 Rinto Ikenoue
shift_evolve
0
140
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
2
130
Bidirectional Quadratic Voting Leveraging Issue-Based Matching
kentaro
2
170
エンジニア採用を起点に取り組む組織の改善活動と課題、中長期のタスク管理/ #HRmethod
nishiuma
4
3.3k
エンジニア向け会社紹介資料
caddi_eng
15
250k
LLMに日本語テキストを学習させる意義
ksaito
13
3.4k
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.8k
What the flash - Photography Introduction
edds
67
11k
How to Ace a Technical Interview
jacobian
275
23k
The Cult of Friendly URLs
andyhume
76
5.9k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
22
1.7k
Raft: Consensus for Rubyists
vanstee
135
6.5k
The World Runs on Bad Software
bkeepers
PRO
64
11k
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.1k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Practical Orchestrator
shlominoach
185
10k
The Pragmatic Product Professional
lauravandoore
30
6.2k
Transcript
Webサービス事業会社における EDRの検討と導入の事例 クックパッド株式会社 水谷正慶
本日のトピック •EDR導入のきっかけ •PoCの評価項目と評価結果 •CrowdStrike Falconの導入 •CrowdStrike Falconの運用 •今後の展望
講演者自己紹介 •水谷 正慶 (@m_mizutani) •クックパッド株式会社 (2017.11〜) ‣ 技術部セキュリティグループ グループ長 ‣
セキュリティ監視基盤の設計・構築・運用を主に担当 •前職ではSOCアナリストやSIEMに関する研究開発など
None
None
None
None
None
クックパッドでセキュリティをやる意味 •新しい事業やサービスの改善をするにあたって多くの 変化が起きるが、同時に問題が起こりやすくなる •事業になるべく影響を与えずに、事前に問題を防ぐ& 問題があっても対応できる体制を整える必要がある
EDR導入のきっかけ
社内環境 •MacBook (macOS): 500台 •Surface Pro 4 / Laptop (Windows
10): 80台 •OSは原則として最新のバージョンを使用 •エンジニア・デザイナ・総合職に関わらず原則MacBookを支給 ‣ エンジニア・デザイナで全体の4割強 •WindowsはActive Directoryでアカウント管理 (Azure AD Joinに移行中) •macOSはローカルユーザのみ(ディレクトリ管理していない) •恵比寿オフィスの社内ネットワークにはPaloAltoのNGFWを導入
Falcon以前の製品選定 •Falcon以前に利用していたアンチウイルスの選定基準 ‣ macOS / Windows両対応 ‣ WindowsよりもmacOSでの機能面 ‣ 特に開発環境でのオーバーヘッドが低いことを重視
‣ オンプレミスの管理サーバを必要としないこと •APIやログの保存などは重視していなかった ‣ 製品から提供されるコンソールをそのまま使用 ‣ 定期的にデータをエクスポート(csv)し、手作業で集計
Falcon以前の導入製品における課題 (1/2) 1. 開発環境を含め、社内環境はほぼmacOSに揃えている ‣ Windowsに比べ、macOSのサポートが貧弱な製品が多い ‣ macOSのアップグレードへの対応が遅かった • iOSアプリ開発などでOSのアップグレードが必要
‣ iOS SimulatorなどXcode関連でfalse positiveが度々発生 • 複数台から突然大量のアラートが発生することもあった
Falcon以前の導入製品における課題 (2/2) 2. アラートに含まれる情報が不足していた ‣ ファイルシステム上の活動のみ(パスやファイルハッシュ) ‣ 追跡調査できずにインシデントをクローズすることが度々 3. 通信イベントの監視を行いたい
‣ ファイルに対する監視だけでは不十分 • どのような経路で該当ファイルがドロップされたのか、外部との通信は存在したか、な どの追跡を行いたい ‣ NGFWなどの通信ログと突合して詳細な分析をしたい
PoCの評価項目と評価結果
評価にあたって •PoC実施前に、予め必要項目を提示 ‣ 最低限出来て欲しい機能と、これが出来ると嬉しい機能 ‣ 一覧を表にして共有 • いわゆる星取り表という意図ではなく、PoCでどういった点を見るのか、どのような機能 を重視しているのかを予め整理して明確化するための資料 •社内環境の説明
‣ 前述の選定要件など •PoCは検討対象の製品それぞれで1ヶ月弱
None
評価項目と結果 (1/5) 1. 負荷が十分に小さい ‣ git grepやJavaプロジェクトのビルドが遅くならないこと • 10秒程で終わるはずのコマンドが5分になってしまう •
.classファイルを監視から外すなど、微調整したことも ‣ 通信をフックして独自のローカルプロクシで監視する製品 • 遅延の他に、特定条件下でHTTPパケットが壊れる • エージェントが暴走して通信不能になることも 2. 開発環境におけるfalse positiveが少ない ‣ 開発の妨げになる・件数が多いと狼少年に 検証 項目 検証 項目
評価項目と結果 (2/5) 1. 負荷・false positiveについて ‣ エージェントを入れた端末に、実際に開発環境を一から構築 • rubyビルドやライブラリの取得、iOS/Android開発環境 •
正常に起動するか、また起動時間が長くならないか • 他の製品では環境構築自体ができないものも存在した 2. 候補がFalconにほぼ絞られてきた時点で、社内各部署のエンジニアの協力を得 て、実際の開発環境にも導入し検証 ‣ false positiveも含め問題は起きなかった 検証 結果 検証 結果
評価項目と結果 (3/5) 3. イベントの検索機能 ‣ ファイルハッシュ、IPアドレス、通信先ドメイン名などをキーに横断的に検索ができるか • アラートに含まれる情報を用いて周辺イベントを調査 • 検索結果に対してpermanent
linkを作成できると嬉しい • APIによるイベントの取得 • コンソールで出来ることがAPIで提供されているか - アラート情報もAPIで取得したい - 時間あたりの回数制限にも注意が必要 検証 項目
評価項目と結果 (4/5) 4. ログの転送 ‣ コンソールで得られる情報がそのままログとして外部から取得できるか • httpsなど標準的な暗号通信経路で取得したい • 保存先がクラウド環境なので、syslogは厳しい
‣ ログはs3に保存して永続化 • 監査にも対応できるよう年単位で保持しておきたい ‣ ログ出力のタイミング • 転送可能になるまで時間がかからないものが望ましい 検証 項目
評価項目と結果 (5/5) 3. イベントの検索・APIについて ‣ コンソールの検索機能は問題なかった ‣ APIから利用できる検索機能は希望を満たすものではなかったが、転送したロ グに対して自前で検索を行う方針に転換したため、APIによる検索を必要とし なくなった
4. ログの転送 ‣ Falcon側のs3バケットに保存されたログを、Data replicatorを用いることで 任意のs3バケットにコピー可能(5分毎) 検証 結果 検証 結果
CrowdStrike Falconの導入
EDRのシステム統合における弊社の機能要件(おさらい) 1. APIでアラート(検知情報)を受け取れること ‣ 既存の弊社セキュリティ監視システムと統合する ‣ アラートの通知や対応状況の管理 2. プログラムからログの検索ができること ‣
Falconが検知したアラートについての調査 ‣ 他のセキュリティ監視装置が検知したアラートの調査
全体のアーキテクチャ概要
イベントログの取り込み詳細 SQS+S3から直接ログを ダウンロード 全てのログをまずS3バケット に保存して可用性確保 検索を効率的にするためファイル形式を 変換して別バケットに保存 OSSであるGraylog + Elasticsearchで
直近のログをインタラクティブに検索 長期的に保存された ログの検索に利用 https://github.com/m-mizutani/aws-falcon-data-forwarder
None
イベントログの取り込み設計のポイント (1/2) •Falconの S3 + SQS というログの出力方法を活用 ‣ 他製品だとsyslogで転送する形式が多かったが障害発生時のリカバリ対応が困難と いう問題があった
‣ Falcon側のS3に一定期間ログが保存されているので転送のやり直しが容易・弊社 側で流量の調整が可能 ‣ S3に保存してから各種処理をする既存の仕組みとの相性が良かった •弊社環境へ転送した際もまずはS3に格納する ‣ S3の可用性&スケーラビリティの高さ、価格の安さを活用
イベントログの取り込み設計のポイント (2/2) •短期的なログはGraylogに格納して他のログも含めた横断的検索を実現 ‣ ログ種別に応じて1週間〜1ヶ月程度 ‣ 高速でinteractiveな横断的ログ検索が可能 • 例)C&CサーバのIPアドレスでログ抽出し通信が発生していたかなど確認 •
例)アラートに関連したユーザ名でログ抽出しアラート前後の行動を把握 •Athenaで長期保存されているログの検索 ‣ GraylogはDB(ストレージ)が高価なので長期的な検索はS3を利用 ‣ 監査的な利用およびインシデント発生時の追跡用
検知情報(アラート)の取り込み詳細 EventStream APIは長時間HTTPのセッション を維持する必要があるためコンテナ上で ツール (falconstream※1) を使用 イベントと同様にまずは S3バケットに集約 イベントの中から
アラートの抽出 アラートに関連する情報 を内部・外部のデータか ら検索しアラートに付与 自動的にリスク判定を実施した後、エン ジニアが対応すべき案件を起票・通知 https://github.com/m-mizutani/falconstream
検知情報(アラート)の取り込み設計ポイント •共通したアラート対応基盤を利用する ‣ Falcon以外のアラートも共通のインターフェースで扱える •対応開始までの時間差を許容できるかの検討 ‣ アラートが発生してから発報されるまで4〜5分遅延がある ‣ 自社内の対応スピードと照らし合わせて許容範囲と判断 •自動化できる部分はなるべく自動化する
‣ 検出されたIPアドレスやドメイン名の調査などは自動的に実行 ‣ 調査のための時間を短縮し、人間の時間を有効に使う
CrowdStrike Falconの運用
対応フロー •アラート管理システムからSlackに通知 ‣ 担当者への通知&チームへの共有 •担当者が調査 ‣ 一部情報は自動的に取得されてGithub EnterpriseのIssueに書き込み ‣ Graylogなどを使って担当者がアラートを調査
‣ 調査結果や進捗をIssueにコメントし、対応完了したらCloseする
Slack上で初動対応とGHEへの記録
今後の展望
今後の展望 •独自ルールの開発と運用 ‣ 社内環境にあわせた脅威検知 •IoC情報の検索 ‣ 取り込んだログを使ってIoC情報を検索する ‣ 後から判明するIoC情報も多いため時間差での対応が必要
None