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
インシデントレスポンスのライフサイクルを廻すポイントってなに / Pinpoints of I...
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Tkay
April 11, 2024
Technology
1.7k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
インシデントレスポンスのライフサイクルを廻すポイントってなに / Pinpoints of Incidentresponse Lifecycle for Operation
Tkay
April 11, 2024
More Decks by Tkay
See All by Tkay
生成AIでセキュリティ運用を効率化する話
sakaitakeshi
0
1.1k
Splunk Experience Day 2025 - Splunk Federated Search for S3 ✕ AWS連携
sakaitakeshi
0
680
セキュリティ運用って包括的にできていますか?SaaSを使って次のステップへ / Comprehensive Cyber Security Operations for Cloud Services Using SaaS
sakaitakeshi
0
1k
Showcase2023_進化し続けるサイバーセキュリティ脅威を防ぐSaaSソリューション.pdf
sakaitakeshi
0
2.1k
Akiba-dot-SaaS-ExtraHop
sakaitakeshi
1
770
AKIBA-dot-SaaS-Cloudflare-ZeroTrust
sakaitakeshi
0
1.2k
Other Decks in Technology
See All in Technology
スタートアップにAmazon EKSは早すぎる? マルチプロダクト戦略を加速する Platform Engineeringの実践 / Is Amazon EKS Too Soon for Startups? Practical Platform Engineering to Accelerate a Multi-Product Strategy
elmodev09
0
300
日本 Fintech 未来予測レポート 2027〜2028年(手動編集版)
8maki
1
2.4k
[AWS Summit Japan 2026]迷っているあなたへ_小さな一歩が、やがて自分を助けてくれる
sh_fk2
1
140
「勝手に広まる」人気 AI エージェントを爆速で作ろう!(AWS Summit Japan 2026講演資料)
minorun365
PRO
5
1.8k
アジャイルな経理と Claude Code と経営の未来
kawaguti
PRO
3
160
10年間のブログ発信を振り返って見えたWebアプリケーションエンジニアとしての軌跡
stefafafan
0
160
【Snowflake Summit 2026 Recap!!】Snowflake Summit Deep Dive: Security & Governance
civitaspo
1
260
ロボティクスの技術 / Robotics Technology
ks91
PRO
0
110
200個のGitHubリポジトリを横断調査したかった
icck
0
140
2026TECHFRESH畢業分享會 - Lightning Talk - 打造精準高效的 MCP 設計模式與測試實務
line_developers_tw
PRO
0
1.3k
20260619 私の日常業務での生成 AI 活用
masaruogura
1
230
Lightning近況報告
kozy4324
0
180
Featured
See All Featured
Building Applications with DynamoDB
mza
96
7.1k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
150
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
560
Embracing the Ebb and Flow
colly
88
5.1k
Mind Mapping
helmedeiros
PRO
1
250
Being A Developer After 40
akosma
91
590k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
200
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
590
Agile that works and the tools we love
rasmusluckow
331
21k
Thoughts on Productivity
jonyablonski
76
5.2k
Transcript
インシデントレスポンス のライフサイクルを 廻すポイントってなに? ~ インシデントレスポンスで組織のセキュリティを 底上げ しよう ~ 1
2 ⾃⼰紹介 酒井 剛(Takeshi Sakai) • アライアンス事業部 テックG • セキュリティ系SaaS製品
Sumo Logic、Cloudflare Zero Trust • 2022年4⽉⼊社 • 前職では、EDR/CloudSWG導⼊、CSIRT • Nagios/Cacti、インフラエンジニア • 趣味:ケーキ作り(前前職パティシエ) 、キャンプ • 本⽇のスイーツ:タルト‧マルグリット (仏語 マーガレットの意、お花のタルト)
3 アジェンダ • なぜ、インシデントレスポンスなのか? • インシデントレスポンスを実施していくうえでのポイント ココ
4 (サイバー)セキュリティ対策って どんなことやっていますか? セキュリティについて悩んでいる。。。
5 セキュリティについて悩んでいる。。。 資産管理 認証 アクセス制御 脆弱性対策 マルウェア対策 (アンチウィルス製品) 経路の暗号化 データの暗号化
ネットワークのセグメント ⼈的ミスへの対応 セキュリティポリシーの策定
6 セキュリティにおける予防と発⾒ セキュリティの考え⽅は⼤きく分けて2種類 予防 と 発⾒
7 セキュリティにおける予防と発⾒ = 攻撃者が侵⼊する前に未然に防ぐ、ビジネスへの 悪影響(リスク)が起こらないようにするための 取り組み = 侵⼊が発⽣した場合に検知し、閉じ込め、取り除 き、元の状態へ戻すための取り組み 予防的対策 発⾒的対策
識別 ID 防御 PR 検知 DE 対応 RS 復旧 RC セキュリティフレームワークから⾒る全体像 8 未然に防ぐことを中⼼に考えられている 侵⼊後の検知‧対応‧復旧にも着眼点を置いている 予防的対策
発⾒的対策 ISO 27001 NIST CSF1.1 ※NIST CSF2.0では新たに統治 (Govern) が増えている = インシデントレスポンス
9 ⽇本政府においても、NIST CSF の考え⽅が取り⼊れられ、標準的な考え⽅になっている が、まだまだこれからという企業も少なくない https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c3 1-0f06fca67afc/a84dbb17/20230411_resources_standard_guidelines_guideline_05.pdf https://www.mod.go.jp/atla/cybersecurity.html セキュリティフレームワークから⾒る全体像
10 なぜ?インシデントレンスポンス? ニューノーマルな時代 • インターネットサービス利⽤の拡⼤ (パブリッククラウドサービス、リモートワーク、オンライン会議) • 攻撃者の標的はインターネットへ→攻撃対象の拡⼤と防御側の複雑化 攻撃の⾼度化(Advanced Percistent
Threat) • フィッシング攻撃 (MFA疲労、宅配業者を装うSMS、詐欺サイト) • ゼロデイ脆弱性をついた攻撃
11 なぜ?インシデントレンスポンス? ニューノーマルな時代 • インターネットサービス利⽤の拡⼤ (パブリッククラウドサービス、リモートワーク、オンライン会議) • 攻撃者の標的はインターネットへ→攻撃対象の拡⼤と防御側の複雑化 攻撃の⾼度化(Advanced Percistent
Threat) • フィッシング攻撃 (MFA疲労、宅配業者を装うSMS、詐欺サイト) • ゼロデイ脆弱性をついた攻撃 予防だけで完全に防ぐことは不可能 侵⼊を前提に対策をとる必要がある 理由1
12 なぜ?インシデントレンスポンス? インシデントレスポンスとは? • インシデントを早期に特定し、ビジネス損失が発⽣する前に防ぐ • インシデント発⽣後に、素早く回復し、ビジネス損失を可能な限 り⼩さくする • 発⽣したインシデントを振り返り、修正する(適切な予防処置、
検出メカニズム) 継続してセキュリティを運⽤することで 組織のセキュリティを底上げする 理由2
13 アジェンダ • なぜ、インシデントレスポンスなのか? • インシデントレスポンスを実施していくうえでのポイント ココ
NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 14 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備
Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
15 ライフサイクルを廻すポイント 準備段階が⾮常に重要 準備がおろそかだと おいしいケーキは作れない
NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 16 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備
Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
17 So, what? (何を準備するのか?) PPT People Process Technology = (⼈ プロセス
技術) を準備する
18 People(⼈)を準備する • 継続的な⼈材育成 ◦ セキュリティの資格を取る(AWSなら SCS-C02) ◦ 侵⼊後を想定した、シミュレーションやワークショップを通じて継 続的に教育を実施
19 • AWS Security Workshop ◦ https://workshops.aws/categories/Security • おすすめ ◦
Detect, investigate and respond to security scenarios ▪ Level: 300、Categories: Security, Management and Governance, Identity and Compliance ◦ Detecting Ransomware using AWS Services ▪ Level: 300、Categories: Security, Threat Detection ◦ AWS Incident Response Playbooks Workshop ▪ Level: 400、Categories: Incident Response, Security People(⼈)を準備する
20 • JP CERT/CC ログ分析トレーニング ◦ 調査に必要なログ設定 (Windows、プロキシ) ◦ 攻撃⼿法の理解
◦ 攻撃パターン毎のログの分析ポイント People(⼈)を準備する https://jpcertcc.github.io/log-analysis-training/ https://github.com/JPCERTCC/log-analysis-training/blob/master/Material/log-analysis_handson -with-note.pdf
21 People(⼈)を準備する 痛みのピラミッド http://detect-respond.blogspot.com/2013/03/ the-pyramid-of-pain.html 攻撃⼿法は簡単に変えれない
22 Process(プロセス)を準備する • プロセスモデルを採⽤する ◦ 例:NIST インシデント対応サイクル、SANS PICERLモデル • インシデント対応計画やプレイブックを作成する
◦ インシデント対応フローの作成 ◦ トリアージ(インシデントの優先度)と対応⽅針 ◦ 想定されるインシデントの調査⽅法や軽減策
23 • プロセスモデルを採⽤する ◦ 例:NIST インシデント対応サイクル ▪ 準備、検知‧分析、隔離‧根絶‧回復、事後分析 ◦ 例:SANS
PICERLモデル ▪ Prepare、Identification、Containment、 Eradication、Recovery、Lessons Learn https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf https://www.sans.org/media/score/504-incident-response-cycle.pdf Process(プロセス)を準備する
24 Process(プロセス)を準備する • プロセスモデルを採⽤する ◦ 例:NIST インシデント対応サイクル、SANS PICERLモデル • インシデント対応計画やプレイブックを作成する
◦ インシデント対応フローの作成 ◦ トリアージ(インシデントの優先度)と対応⽅針 ◦ 想定されるインシデントの調査⽅法や軽減策
25 インシデント対応フローの作成(例) • JP CERT/CC インシデントハンドリング マニュアル ◦ インシデント発⽣から収束までの共 通フローを作成する
◦ ステークホルダー、コミュニケー ションパス ◦ 各イベントの発⽣タイミング https://www.jpcert.or.jp/csirt_material/operation_phase.html Process(プロセス)を準備する
26 トリアージ(インシデントの優先度)と対応⽅針 Process(プロセス)を準備する 重大度 判断例 対応方針 重大 取引先、顧客、ユーザーなど影響が広範囲。 機密情報が持ち出されている、公開サー バーが乗っ取られている
直ちにエスカレーション、関連部署と連 携、社外公表 高 マルウェア感染、不審な通信が断続的に継 続 直ちにエスカレーション、関連部署と連携 中 マルウェア感染の疑い、通信は NW機器で遮 断されていて限定的 インシデント対応チーム内で対応、エスカ レーション、月次レポート等で共有 低 マルウェア感染前に駆除、脅威の未然防止、 スキャン行為のみ、外からの通信遮断できて いるなど インシデント対応チーム内で対応、エスカ レーション無し、月次レポート等で共有
27 想定されるインシデントの調査⽅法や軽減策 • AWSのプレイブックテンプレート(aws-customer-playbook-framework) ◦ 例:IAM認証情報の漏洩 ▪ 検知 - GuardDutyの検知、AWSコストの不⾃然な増加、IAMロールの作成等イベント...
▪ 分析 - GuardDuty‧Security Hub‧Detectiveの情報、CloudTrailの ConsoleLogin‧AssumeRole‧RunInstancesなどのイベントの調査... ▪ 隔離 - IAMユーザーの無効化、IAMアクセスキーのバックアップと無効化... ▪ 根絶 - 漏洩したIAM認証情報から作成されたリソースの削除、⾒覚えのないサービスの削 除、脆弱性スキャンの実施... ▪ 回復 - 正常なバックアップデータからリストア、新規アカウント上でのシステムの再構 築... ▪ 事後分析 - 事後分析のための振り返りを開催、インシデントの内容、最初に気づいたの は、影響の範囲、機能したものしなかったもの... https://github.com/aws-samples/aws-customer-playbook-framework Process(プロセス)を準備する
28 Technology(技術)を準備する • 分析‧アラートのためのログを準備する ◦ ここで準備できていないログ以外には、侵⼊後の⾏動に関する可視 性は無くなる。必要ないログは取る必要はないが、必要なログは何 かを定義し、設定しておく。⇒ ログは真実の源 •
デジタルフォレンジック ◦ 証跡(ログ、スナップショット、物理ハードディスク)の保全 ◦ アウトソースが可能なよう準備しておく
29 • 分析‧アラートのためのログを準備する ◦ 調査のためのログを選択 AWS: CloudTrail、GuardDuty、Security Hub、VPC Flow Logs、Route
53 リゾルバクエリログ ⼀般: DNS、プロキシ、Windowsイベントログ、EDR、IDS ◦ 分析観点では数ヶ⽉は保存しておく(半年以上) ◦ アラートが発⽣するようにしておく ◦ ログ分析する仕組みを⽤意する CloudWatch Logs Insights、Amazon Athena、Amazon OpenSearch Service、 SIEM ログの管理‧分析‧可視化において統合されて使いやすい 検知ルールや相関分析により効率よく対応できる Technology(技術)を準備する
30 • 分析‧アラートのためのログを準備する ◦ ここで準備できていないログ以外には、侵⼊後の⾏動に関する可視 性は無くなる。必要ないログは取る必要はないが、必要なログは何 かを定義し、設定しておく。 • デジタルフォレンジック ◦
証跡(ログ、スナップショット、物理ハードディスク)の保全 ◦ アウトソースが可能なよう準備しておく Technology(技術)を準備する
NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 31 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備
Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 32 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備
Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
33 事後分析 • 発⽣したインシデントのレビューを開催 ◦ 関係するステークホルダーを招集する ◦ インシデントに気付いたのはどの時点だったか ◦ インシデントのアラートを発⽣させたのは何か
◦ インシデント対応の中で機能したものは何か、しなかったものは何か ◦ インシデント識別にかかる時間を短縮するために何が有効か ◦ インシデント再発を防ぐ予防策はあるか ◦ 対策を⾏うためにどの程度時間が必要か、プランを⽴てる ⼈‧プロセス‧技術 の何を改善する必要があったのか (レビューをもとに準備や予防対策へ)
34 まとめ • 予防的対策+発⾒的対策 ◦ 予防だけでは防げない、侵⼊を前提としたセキュリティを • ライフサイクルは準備が⼤事 ◦ ⼈‧プロセス‧技術
• ログは真実の源 ◦ 必要なログを選択、適切なツールを使って分析を • 事後分析もしっかり、セキュリティ全体を底上げする
35