Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
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
730
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
520
Ubieにおけるセキュリティ課題管理の自動化 / ubie-sec-issue-automation
mizutani
0
790
Trivy + Regoを用いたパッケージ脆弱性管理 /trivy-rego
mizutani
7
4.3k
リモートワークを支える 社内セキュリティ基盤の構築と運用 /secueiry-for-wfh
mizutani
0
680
SOARによるセキュリティ監視業務の効率化とSecOps /soar-and-secops
mizutani
1
1.1k
Amazon Athena を使った セキュリティログ検索基盤の構築 /seclog-athena
mizutani
5
2.8k
AWS re:Inforce recap 2019
mizutani
1
4.2k
スケーラブルなセキュリティ監視基盤の作り方 /techconf2019-mizutani
mizutani
3
3.2k
Webサービス事業会社におけるEDRの検討と導入の事例 /falconday201812
mizutani
3
2.3k
Other Decks in Technology
See All in Technology
深層学習のリペア技術の最新動向と実際 / DNN Repair Techniques for AI Performance Alignment for Safety Requirements
ishikawafyu
0
490
PostgreSQL Conference Japan 2024 A4 Comparison of column-oriented access methods
nori_shinoda
0
150
Classmethod_regrowth_2024_tokyo_security_identity_governance_summary
hiashisan
0
590
【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案
hianraku9498
0
590
EthernetベースのGPUクラスタ導入による学びと展望
lycorptech_jp
PRO
0
590
TimeTreeが経た3つの転換点 ー プロダクト成長過程でその時、その瞬間、何を考えてたか
ysmtysts
1
3.6k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
52k
宇宙最速のランチRecap LT会(開発者ツール&運用監視編)
nnydtmg
1
180
長年運用されているサービスの主要データ移行をサービス停止せず安全にリリースしました
phayacell
2
180
ドメインロジックで考えるテスタビリティ
leveragestech
1
280
Explain EXPLAIN
keiko713
10
2.7k
イノベーショントークから見るクラウド運用の未来を振り返ってみた
nyankotaro
0
330
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
33
3k
Designing for humans not robots
tammielis
250
25k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Documentation Writing (for coders)
carmenintech
65
4.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
480
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Building Adaptive Systems
keathley
38
2.3k
A Tale of Four Properties
chriscoyier
157
23k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
780
We Have a Design System, Now What?
morganepeng
51
7.3k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
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